http://bugzilla.opensuse.org/show_bug.cgi?id=1188954 http://bugzilla.opensuse.org/show_bug.cgi?id=1188954#c27 Felix Miata <mrmazda@earthlink.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(mrmazda@earthlink | |.net) | --- Comment #27 from Felix Miata <mrmazda@earthlink.net> --- 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. -- You are receiving this mail because: You are on the CC list for the bug.