Comment # 27
on bug 1188954
from Felix Miata
I gave this more thought and reached the conclusion that at the KMS switch
point is when a kernel graphics module should load, but does not. When the
screen goes black as 1024x768 mode ends, it should then enable either the
native mode, or the cmdline video= mode. That's not been happening.
Between comments #24 & #25, I took a trip through BIOS setup and found IOMMU
disabled. I switched it to enabled, and found the bad behavior seemed to be
gone. However, after a break for sleep, on next considerable number of boots
the bad behavior was back. So I decided to forget about it and do other things
that needed doing. During that lull, I stumbled onto rd.driver.pre=amdgpu, so
on return to try to follow-up here I added it. It didn't seem to make any
difference.
Today is a new day. So far, every boot with an initrd built to include:
# lsinitrd /boot/initrd | grep drm | grep -v ^d
-rw-r--r-- 1 root root 3417336 Sep 8 13:12
lib/modules/5.14.21-150400.24.21-default/kernel/drivers/gpu/drm/amd/amdgpu/amdgpu.ko.zst
-rw-r--r-- 1 root root 301834 Sep 8 13:12
lib/modules/5.14.21-150400.24.21-default/kernel/drivers/gpu/drm/drm.ko.zst
-rw-r--r-- 1 root root 182288 Sep 8 13:12
lib/modules/5.14.21-150400.24.21-default/kernel/drivers/gpu/drm/drm_kms_helper.ko.zst
-rw-r--r-- 1 root root 8183 Sep 8 13:12
lib/modules/5.14.21-150400.24.21-default/kernel/drivers/gpu/drm/drm_ttm_helper.ko.zst
-rw-r--r-- 1 root root 22889 Sep 8 13:12
lib/modules/5.14.21-150400.24.21-default/kernel/drivers/gpu/drm/scheduler/gpu-sched.ko.zst
-rw-r--r-- 1 root root 47953 Sep 8 13:12
lib/modules/5.14.21-150400.24.21-default/kernel/drivers/gpu/drm/ttm/ttm.ko.zst
As a result of
force_drivers+=" amdgpu"
omit_drivers+="radeon"
But, a boot without such an initrd, and without rd.driver.pre=amdgpu, following
a reboot from same initrd but with rd.driver.pre=amdgpu, just behaved as
expected. The following boot, also without rd.driver.pre=amdgpu, black screened
with (EE) open /dev/dri/card0: No such file or directory yet again. Another,
with rd.driver.pre=amdgpu, also bad. Later with a no driver "forcing" initrd, I
got a black screen boot with rd.driver.pre=amdgpu, followed by a normal boot
without rd.driver.pre=amdgpu followed by a black screen boot with
rd.driver.pre=amdgpu, so I took rd.driver.pre=amdgpu out of the default boot
stanza. Next boot was black, followed by an almost black, both using an initrd
explicitly omitting radeon but not mentioning amdgpu. Then again without
changing anything, next boot was normal/as expected. I switched back to initrd
with force amdgpu & omit radeon (initrd for .24.21 #7), and got good boots >5X
in a row. There's just no rhyme or reason to whether /dev/dri/card0 appears
soon enough or not without force-amd/omit-radeon, but with is a solution that
is less than a 100% guarantee.
I think I want to see what the long-awaited next kernel version brings, but
ATM, helps seems to be something like ~97% yes.
On occasion, the "black" screen turns out to be not 100% black. Occasionally a
tty1 screen will have output, but with the brightness turned down to something
in the neighborhood of 10% or less.
FWIW, same machine has no direct I/O at all on Fedora 36 except with 5.18
kernel instead of 5.19.17, but is fine on 37:
https://bugzilla.redhat.com/show_bug.cgi?id=2130843#c1 That, this, and threads
in various forums in recent weeks makes me think something is going wrong
upstream in kernel with AMD/ATI graphics.