http://bugzilla.opensuse.org/show_bug.cgi?id=1188954 http://bugzilla.opensuse.org/show_bug.cgi?id=1188954#c1 --- Comment #1 from Felix Miata --- Behavior remains the same with 5.13.4 kernel, and with omission of non-essential cmdline options. -- You are receiving this mail because: You are the assignee for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1188954 http://bugzilla.opensuse.org/show_bug.cgi?id=1188954#c3 Felix Miata changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(mrmazda@earthlink | |.net) | --- Comment #3 from Felix Miata --- Created attachment 851463 --> http://bugzilla.opensuse.org/attachment.cgi?id=851463&action=edit Xorg.0.log booted without radeon.cik_support=0 amdgpu.cik_support=1 (In reply to Stefan Dirsch from comment #2)

Not sure why you want to enable Sea Islands (CIK) support in amdgpu kernel driver. I doubt it gets sufficient testing.

10 months ago it (A10-7850K) worked at each boot just fine, as it does now once xdm is restarted. I have another Kaveri that still does work just fine, without need to restart xdm first thing after booting: # cat inxi-tw20210730.txt # pinxi -SCzy System: Kernel: 5.12.13-1-default x86_64 bits: 64 Desktop: Trinity R14.0.10 Distro: openSUSE Tumbleweed 20210730 Machine: Type: Desktop Mobo: ASRock model: FM2A88X Extreme6+ serial: <filter> UEFI: American Megatrends v: P4.20 date: 01/13/2016 CPU: Info: Quad Core model: AMD PRO A8-8650B R7 10 Compute Cores 4C+6G bits: 64 type: MCP cache: L2: 2 MiB Speed: 1396 MHz min/max: 1400/3200 MHz Core speeds (MHz): 1: 1396 2: 1392 3: 1397 4: 1381 # pinxi -Gazy Graphics: Device-1: AMD Kaveri [Radeon R7 Graphics] vendor: ASRock driver: amdgpu v: kernel alternate: radeon bus-ID: 00:01.0 chip-ID: 1002:1313 class-ID: 0300 Display: x11 server: X.Org 1.20.12 driver: loaded: amdgpu unloaded: fbdev,modesetting,vesa alternate: ati display-ID: :0 screens: 1 Screen-1: 0 s-res: 1920x1200 s-dpi: 120 s-size: 406x254mm (16.0x10.0") s-diag: 479mm (18.9") Monitor-1: DisplayPort-0 res: 1920x1200 hz: 60 dpi: 94 size: 519x324mm (20.4x12.8") diag: 612mm (24.1") OpenGL: renderer: AMD KAVERI (DRM 3.40.0 5.12.13-1-default LLVM 12.0.1) v: 4.6 Mesa 21.1.5 direct render: Yes # systemd-analyze Startup finished in 9.750s (firmware) + 23.795s (loader) + 1.952s (kernel) + 2.480s (initrd) + 3.207s (userspace) = 41.185s multi-user.target reached after 3.145s in userspace # dmesg | grep amdgpu [ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz root=LABEL=zd8p07stw noresume ipv6.disable=1 net.ifnames=0 mitigations=auto consoleblank=0 radeon.cik_support=0 amdgpu.cik_support=1 video=1024x768@60 video=1440x900@60 5 [ 0.019636] Kernel command line: BOOT_IMAGE=/boot/vmlinuz root=LABEL=zd8p07stw noresume ipv6.disable=1 net.ifnames=0 mitigations=auto consoleblank=0 radeon.cik_support=0 amdgpu.cik_support=1 video=1024x768@60 video=1440x900@60 5 [ 6.559662] [drm] amdgpu kernel modesetting enabled. [ 6.559836] amdgpu: Topology: Add APU node [0x0:0x0] [ 6.559894] fb0: switching to amdgpudrmfb from EFI VGA [ 6.560540] amdgpu 0000:00:01.0: vgaarb: deactivate vga console [ 6.560775] amdgpu 0000:00:01.0: amdgpu: Trusted Memory Zone (TMZ) feature not supported [ 6.577972] amdgpu 0000:00:01.0: amdgpu: Fetched VBIOS from ROM BAR [ 6.577978] amdgpu: ATOM BIOS: 113-SPEC-102 [ 6.578227] amdgpu 0000:00:01.0: amdgpu: VRAM: 1024M 0x000000F400000000 - 0x000000F43FFFFFFF (1024M used) [ 6.578231] amdgpu 0000:00:01.0: amdgpu: GART: 1024M 0x000000FF00000000 - 0x000000FF3FFFFFFF [ 6.578343] [drm] amdgpu: 1024M of VRAM memory ready [ 6.578347] [drm] amdgpu: 3072M of GTT memory ready. [ 6.586607] [drm] amdgpu: dpm initialized [ 6.861924] amdgpu 0000:00:01.0: amdgpu: SE 1, SH per SE 1, CU per SH 8, active_cu_number 6 [ 7.037007] fbcon: amdgpudrmfb (fb0) is primary device [ 7.490778] amdgpu 0000:00:01.0: [drm] fb0: amdgpudrmfb frame buffer device [ 7.525260] [drm] Initialized amdgpu 3.40.0 20150101 for 0000:00:01.0 on minor 0

I suggest to use radeon kernel module (default). Then possibly with "radeon" DDX, but "modesetting" should be fine as well, then using Mesa driver for acceleration via Glamor. If this fails as well, we can discuss again.

In comment #0 my last sentence would seem to have covered this. Anyway: # inxi -SCMzy System: Kernel: 5.13.4-1-default x86_64 bits: 64 Desktop: Trinity R14.0.10 Distro: openSUSE Tumbleweed 20210730 Machine: Type: Desktop Mobo: ASUSTeK model: A88X-PRO v: Rev X.0x serial: <filter> UEFI: American Megatrends v: 2603 date: 03/10/2016 CPU: Info: Quad Core model: AMD A10-7850K Radeon R7 12 Compute Cores 4C+8G bits: 64 type: MCP cache: L2: 2 MiB Speed: 1689 MHz min/max: 1700/3700 MHz Core speeds (MHz): 1: 1689 2: 1700 3: 1699 4: 1695 # inxi -Gazy Graphics: Device-1: AMD Kaveri [Radeon R7 Graphics] vendor: ASUSTeK driver: radeon v: kernel alternate: amdgpu bus-ID: 00:01.0 chip-ID: 1002:130f class-ID: 0300 Display: x11 server: X.Org 1.20.12 driver: loaded: modesetting unloaded: fbdev,vesa alternate: ati display-ID: :0 screens: 1 Screen-1: 0 s-res: 1920x1200 s-dpi: 120 s-size: 406x254mm (16.0x10.0") s-diag: 479mm (18.9") Monitor-1: DP-1 res: 1920x1200 hz: 60 dpi: 94 size: 519x324mm (20.4x12.8") diag: 612mm (24.1") OpenGL: renderer: AMD KAVERI (DRM 2.50.0 5.13.4-1-default LLVM 12.0.1) v: 4.5 Mesa 21.1.5 direct render: Yes # systemd-analyze Startup finished in 5.901s (firmware) + 22.155s (loader) + 1.645s (kernel) + 2.238s (initrd) + 3.324s (userspace) = 35.265s multi-user.target reached after 3.306s in userspace I checked BIOS and found IOMMU was disabled. After enabling, dmesg got very noisy using drm.debug=0x1e log_buf_len=1M, with the following repeated about 20 times: [ 8.376985] [drm:amdgpu_atombios_encoder_dpms [amdgpu]] encoder dpms 37 to mode 3, devices 00000001, active_devices 00000000 [ 8.387861] [drm:dce_v8_0_program_watermarks [amdgpu]] force priority to high [ 8.388035] [drm:dce_v8_0_program_watermarks [amdgpu]] force priority to high [ 8.388330] [drm:dce_v8_0_program_watermarks [amdgpu]] force priority to high [ 8.388484] [drm:dce_v8_0_program_watermarks [amdgpu]] force priority to high [ 8.388663] [drm:dce_v8_0_program_watermarks [amdgpu]] force priority to high [ 8.388817] [drm:dce_v8_0_program_watermarks [amdgpu]] force priority to high -- You are receiving this mail because: You are the assignee for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1188954 http://bugzilla.opensuse.org/show_bug.cgi?id=1188954#c5 --- Comment #5 from Stefan Dirsch --- So things are simply working with default "radeon" kernel driver. No idea what's remaining here. -- You are receiving this mail because: You are the assignee for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1188954 http://bugzilla.opensuse.org/show_bug.cgi?id=1188954#c7 --- Comment #7 from Stefan Dirsch --- Ok. If it fails only during initial X startup, this looks like a timing issue, i.e. kernel module is not being initialized in time before X gets started. Maybe amdgpu kernel module is missing from initrd, but radeon is (since it's the default driver), i.e. adding amdgpu to initrd may help (if it's really missing). I can't say anything about other Linux distros. They may use completely different kernel versions and patches for them. On openSUSE amdgpu DDX is being used when "amdgpu" kernel module is being loaded. There should be no need to configure it when the package xf86-video-amdgpu is being installed. I still don't understand why you want to use "amdgpu" drvier with your hardware though. -- You are receiving this mail because: You are the assignee for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1188954 http://bugzilla.opensuse.org/show_bug.cgi?id=1188954#c9 --- Comment #9 from Stefan Dirsch --- I don't know why neither amdgpu, nor radeon, nor i915 being added to initrd of your system. Looks like there is no timing issue with radeon with not existing in initrd - in contrary to amdgpu driver. "modesetting" X driver is supposed to work with any hardware with working DRM/modestting kernel driver. -- You are receiving this mail because: You are the assignee for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1188954 http://bugzilla.opensuse.org/show_bug.cgi?id=1188954#c12 --- Comment #12 from Felix Miata --- Created attachment 851587 --> http://bugzilla.opensuse.org/attachment.cgi?id=851587&action=edit Xorg.0.log.old; dmesg; journalctl -b Happens in Intel Kaby Lake too: # lspci -nnk | grep VGA 00:02.0 VGA compatible controller [0300]: Intel Corporation HD Graphics 630 [8086:5912] (rev 04) # inxi -Sy | grep istro Distro: openSUSE Tumbleweed 20210805 Again, no automatic restart was attempted. I must run systemctl restart xdm to get the greeter open. 30 of these are in dmesg: [ 5.131236] i915 0000:00:02.0: [drm:intel_hdmi_set_edid [i915]] HDMI GMBUS EDID read failed, retry using GPIO bit-banging [ 143.509712] i915 0000:00:02.0: [drm:intel_hdmi_set_edid [i915]] HDMI GMBUS EDID read failed, retry using GPIO bit-banging That made me think maybe hardware issue, so I connected a different display, but no joy. -- You are receiving this mail because: You are the assignee for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1188954 http://bugzilla.opensuse.org/show_bug.cgi?id=1188954#c14 Felix Miata changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fbui@suse.com --- Comment #14 from Felix Miata --- Since hosts ab250, asa88 & gb250 where this reproduces are all running TDM, which a forum responder suggested might be at fault, on comment #0 host asa88 I did a fresh minimal/KDE (no-recommends) install of TW20210810, without NetworkManager, without Wicked, with systemd-networkd, without sddm, without lightdm, with xdm. This bug reproduces randomly on it. In 11 successive reboots: 1-success 2-success 3-failure 4-success 5-success 6-success 7-failure 8-failure 9-failure 10-failure 11-failure Example failure stats (from #3 above): # systemd-analyze Startup finished in 5.768s (firmware) + 7.100s (loader) + 1.846s (kernel) + 2.102s (initrd) + 3.486s (userspace) = 20.304s graphical.target reached after 3.477s in userspace # systemd-analyze critical-chain ... graphical.target @3.477s ������multi-user.target @3.477s ������kbdsettings.service @1.007s +2.469s ������basic.target @996ms ������sockets.target @996ms ������telnet.socket @995ms ������sysinit.target @987ms ������systemd-update-utmp.service @958ms +28ms ������systemd-tmpfiles-setup.service @927ms +28ms ������local-fs.target @924ms ������usr-local.mount @876ms +48ms ������systemd-fsck@dev-disk-by\x2dlabel-tvgp04usrlcl.service @663ms +204ms ������local-fs-pre.target @650ms ������systemd-tmpfiles-setup-dev.service @630ms +17ms ������kmod-static-nodes.service @556ms +55ms ������systemd-journald.socket ������system.slice ������-.slice The following is from #11 above: # systemd-analyze blame | head -n22 2.521s kbdsettings.service 1.902s systemd-random-seed.service 1.541s sshd.service 1.140s dracut-initqueue.service 659ms initrd-switch-root.service 638ms chronyd.service 471ms smartd.service 396ms issue-generator.service 304ms user@0.service 303ms initrd-parse-etc.service 182ms systemd-fsck@dev-disk-by\x2dlabel-tvgp04usrlcl.service 179ms systemd-fsck@dev-disk-by\x2dlabel-tvgp06pub.service 179ms systemd-fsck@dev-disk-by\x2dlabel-tvgp05home.service 178ms systemd-udevd.service 137ms systemd-networkd.service 100ms display-manager.service 100ms systemd-logind.service 92ms systemd-udev-trigger.service 82ms apparmor.service 63ms sound-extra.service 62ms systemd-tmpfiles-clean.service 61ms modprobe@drm.service Without radeon.cik_support=0 amdgpu.cik_support=1 on cmdline I managed success on 11 straight boots, so it seems amdgpu.ko.xz simply doesn't get loaded as fast/soon as radeon.ko.xz. I started a forum thread about this in June: https://forums.opensuse.org/showthread.php/555514-boots-too-fast-for-Xorg-to... -- You are receiving this mail because: You are the assignee for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1188954 http://bugzilla.opensuse.org/show_bug.cgi?id=1188954#c16 Dean Martin changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |deano_ferrari@hotmail.com --- Comment #16 from Dean Martin --- (In reply to Felix Miata from comment #15)

Using systemd-networkd instead of wicked or networkmanager makes the (~6s) difference between KMS module finishing loading soon enough or not.

This is from an xdm startup failing using systemd-networkd: # journalctl -b -o short-monotonic -u display-manager.service -u systemd-modules-load.service -g St -- Journal begins at Sat 2021-01-16 18:26:29 EST, ends at Sat 2021-08-14 16:50:47 EDT. -- [ 3.849113] asa88 systemd[1]: Stopped Load Kernel Modules. [ 6.231843] asa88 systemd[1]: Starting X Display Manager... [ 7.383982] asa88 display-manager[651]: Starting service tdm [ 7.384359] asa88 systemd[1]: Started X Display Manager.

This is from an xdm startup succeeding using wicked: # journalctl -b -o short-monotonic -u display-manager.service -u systemd-modules-load.service -g St -- Journal begins at Fri 2021-08-13 23:33:06 EDT, ends at Sat 2021-08-14 17:38:24 EDT. -- [ 3.731005] localhost systemd[1]: Stopped Load Kernel Modules. [ 13.312481] asa88 systemd[1]: Starting X Display Manager... [ 13.411758] asa88 display-manager[1013]: Starting service xdm [ 13.412175] asa88 systemd[1]: Started X Display Manager.

All my systems are configured with static IP, without IPV6 enabled, and without resolvconf of any kind enabled.

It looks like the summary should be:

display-manager.service starts too soon when using systemd-networkd or using systemd-networkd instead of wicked or networkmanager results in systemd-modules-load.service functionally finishing after display-manager.service starts

That is what using early KMS (module added to initrd) may help with, as Stefan Dirsch already mentioned back in comment #7. -- You are receiving this mail because: You are the assignee for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1188954 http://bugzilla.opensuse.org/show_bug.cgi?id=1188954#c18 --- Comment #18 from Dean Martin --- (In reply to Felix Miata from comment #17)

I don't want to force early via including graphics modules in initrd.

One of the Shaman Penguins on the forum thread provided a workaround I can use until the real offender can be isolated and possibly dealt with:

# systemctl cat display-manager.service ... # /etc/systemd/system/display-manager.service.d/override.conf [Unit] After= systemd-udev-settle.service Requires=systemd-udev-settle.service

Your choice of display-manager is TDM. Have you tested other display-managers for this behaviour? -- You are receiving this mail because: You are the assignee for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1188954 http://bugzilla.opensuse.org/show_bug.cgi?id=1188954#c20 Felix Miata changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |tiwai@suse.com --- Comment #20 from Felix Miata --- Still happening on the comment #17 TW host running Tiwai's simpledrm kernel, and no workarounds engaged: # rpm -qa | egrep 'gdm|sddm|lightdm|kdm|tdm|xdm' xdm-1.1.12-17.2.x86_64 # inxi -Sy System: Host: asa88 Kernel: 5.16.3-4.gc7377e3-default x86_64 bits: 64 Desktop: KDE Plasma 5.23.5 Distro: openSUSE Tumbleweed 20220130 # inxi -Gayz Graphics: Device-1: AMD Kaveri [Radeon R7 Graphics] vendor: ASUSTeK driver: amdgpu v: kernel alternate: radeon bus-ID: 00:01.0 chip-ID: 1002:130f class-ID: 0300 Display: x11 server: X.Org 1.21.1.3 compositor: kwin_x11 driver: loaded: amdgpu unloaded: modesetting alternate: ati,fbdev,vesa display-ID: :0 screens: 1 Screen-1: 0 s-res: 1920x1200 s-dpi: 120 s-size: 406x254mm (16.0x10.0") s-diag: 479mm (18.9") Monitor-1: HDMI-A-0 res: 1920x1200 hz: 60 dpi: 94 size: 519x324mm (20.4x12.8") diag: 612mm (24.1") OpenGL: renderer: AMD KAVERI (DRM 3.44.0 5.16.3-4.gc7377e3-default LLVM 13.0.0) v: 4.6 Mesa 21.3.4 direct render: Yes # -- You are receiving this mail because: You are the assignee for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1188954 http://bugzilla.opensuse.org/show_bug.cgi?id=1188954#c22 --- Comment #22 from Felix Miata --- Happens on fresh installation of 15.4 beta with KDM3 on Kaby Lake host gb250: # pinxi -GISaz System: Kernel: 5.14.21-150400.19-default arch: x86_64 bits: 64 compiler: gcc v: 7.5.0 parameters: BOOT_IMAGE=/boot/vmlinuz root=LABEL=<filter> noresume ipv6.disable=1 net.ifnames=0 mitigations=auto consoleblank=0 video=1440x900@60 5 Desktop: KDE v: 3.5.10 tk: Qt v: 3.3.8c info: kicker wm: kwin vt: 7 dm: KDM Distro: openSUSE Leap 15.4 Beta Graphics: Device-1: Intel HD Graphics 630 vendor: Gigabyte driver: i915 v: kernel ports: active: HDMI-A-1 empty: DP-1, DP-2, HDMI-A-2, HDMI-A-3 bus-ID: 00:02.0 chip-ID: 8086:5912 class-ID: 0300 Display: x11 server: X.Org v: 1.20.3 driver: X: loaded: modesetting unloaded: fbdev,vesa alternate: intel gpu: i915 display-ID: :0 screens: 1 Screen-1: 0 s-res: 1920x1200 s-dpi: 120 s-size: 406x254mm (15.98x10.00") s-diag: 479mm (18.85") Monitor-1: HDMI-A-1 mapped: HDMI-1 model: NEC EA243WM serial: <filter> built: 2011 res: 1920x1200 hz: 60 dpi: 94 gamma: 1.2 size: 519x324mm (20.43x12.76") diag: 612mm (24.1") ratio: 16:10 modes: max: 1920x1200 min: 640x480 OpenGL: renderer: Mesa Intel HD Graphics 630 (KBL GT2) v: 4.6 Mesa 21.2.4 direct render: Yes Info:...Shell: Bash v: 4.4.23 running-in: konsole pinxi: 3.3.15-3 # ls -1 /sys/class/drm/ card0 card0-DP-1 card0-DP-2 card0-HDMI-A-1 card0-HDMI-A-2 card0-HDMI-A-3 renderD128 version # systemd-analyze critical-chain ... graphical.target @2.993s ������multi-user.target @2.993s ������kbdsettings.service @866ms +2.126s ������basic.target @853ms ������sockets.target @852ms ������telnet.socket @852ms ������sysinit.target @842ms ������systemd-update-utmp.service @829ms +9ms ������systemd-tmpfiles-setup.service @716ms +110ms ������local-fs.target @709ms ������usr-local.mount @692ms +14ms ������systemd-fsck@dev-disk-by\x2dlabel-pi3p04usrlcl.service @648ms +37ms ������local-fs-pre.target @625ms ������systemd-tmpfiles-setup-dev.service @590ms +33ms ������kmod-static-nodes.service @511ms +51ms ������systemd-journald.socket ������system.slice ������-.slice -- You are receiving this mail because: You are the assignee for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1188954 http://bugzilla.opensuse.org/show_bug.cgi?id=1188954#c24 Felix Miata changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |sndirsch@suse.com Flags| |needinfo?(sndirsch@suse.com | |) --- Comment #24 from Felix Miata --- Created attachment 862373 --> http://bugzilla.opensuse.org/attachment.cgi?id=862373&action=edit systemd-analyze blame This 475 line attachment is from today's fresh installation. I spent all day yesterday and the first hours of today beating my head against this wall with this PC's previous 15.4, an upgrade from 15.3 many moons ago then ending with kernel-default-5.14.21-150400.22.1 as latest kernel, then three separate attempts to upgrade from 15.3 again, before deciding on a fresh start. (In reply to Stefan Dirsch from comment #7)

Ok. If it fails only during initial X startup, this looks like a timing issue, i.e. kernel module is not being initialized in time before X gets started. Maybe amdgpu kernel module is missing from initrd, but radeon is (since it's the default driver), i.e. adding amdgpu to initrd may help (if it's really missing).

On 15.4 post-kernel-default-5.14.21-150400.22.1, the Kaveri [Radeon R7 Graphics] chip-ID: 1002:130f PC is stubbornly refusing to load a kernel graphics module before X tries its first start on each boot. XDM won't auto restart, so I get either solid black screen, or a tty1 login prompt, depending on what linu line parameters are used, and/or which display drivers are configured, and/or whether I have validly reconfigured dracut for graphics module loading, and/or I've blacklisting of radeon in /etc/modulesload.d/. # systemd-analyze critical-chain ... graphical.target @4.227s ������multi-user.target @4.226s ������kbdsettings.service @2.171s +2.055s ������basic.target @2.154s ������sockets.target @2.154s ������telnet.socket @2.154s ������sysinit.target @2.148s ������systemd-backlight@backlight:acpi_video0.service @3.476s +7ms ������system-systemd\x2dbacklight.slice @3.271s ������system.slice ������-.slice Questions: 1-How do I guarantee earliest possible loading of whatever kernel graphics module is needed or wanted, whether radeon or amdgpu? Is force_drivers+=" amdgpu " in a file of any name in /etc/dracut.conf.d/ sufficient to ensure loading amdgpu comes first? Solely? Is omit_drivers+=" radeon " needed as well? 2-Does initrd by default include whatever blacklisting is contained in /etc/modprobe.d/? Is "blacklist radeon" in any file in this directory sufficient? Do filenames here need to end in .conf to be utilized? 3-Could a delay of first X start on custom want or after existence of /dev/dri/card0: in /usr/lib/systemd/system/display-manager.service work? Shouldn't that already be happening? Googling early graphics loading has been getting me nothing but *NVidia* and/or Youtubes. :( 15.3 & TW are behaving perfectly using only amdgpu, without any heroics, on same PC. -- You are receiving this mail because: You are the assignee for the bug.

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

http://bugzilla.suse.com/show_bug.cgi?id=1188954 http://bugzilla.suse.com/show_bug.cgi?id=1188954#c29 --- Comment #29 from Felix Miata --- Created attachment 866300 --> http://bugzilla.suse.com/attachment.cgi?id=866300&action=edit Xorg.0.log from TW20230412 w/ SDDM/Plasma Host fi965 is another victim, currently TW20230412 on an old PCIe Radeon HD 8570 / R5 430 OEM R7 240/340 Radeon 520 OEM 1002:6611. It has two discrete installations. One with KDM3/KDE3, the other with SDDM/Plasma, both suffering. From the SDDM: # dmesg | grep aile [ 30.152899] platform regulatory.0: Direct firmware load for regulatory.db failed with error -2 [ 30.152906] cfg80211: failed to load regulatory.db # journalctl -b | grep aile Apr 13 21:37:28 fi965 systemd-vconsole-setup[167]: Failed to import credentials, ignoring: No such file or directory Apr 14 01:38:21 fi965 kernel: platform regulatory.0: Direct firmware load for regulatory.db failed with error -2 Apr 14 01:38:21 fi965 kernel: cfg80211: failed to load regulatory.db Apr 14 01:38:48 fi965 nscd[790]: 790 stat failed for file `/etc/services'; will try again later: No such file or directory # grep /dev/dr /var/log/Xorg.0.log [ 1486.092] (II) xfree86: Adding drm device (/dev/dri/card1) [ 1486.098] (II) Applying OutputClass "AMDgpu" to /dev/dri/card1 [ 1486.106] (EE) open /dev/dri/card0: No such file or directory [ 1486.106] (II) Applying OutputClass "AMDgpu" options to /dev/dri/card1 # grep /dev/dr /var/log/Xorg.0.log.old [ 619.557] (II) xfree86: Adding drm device (/dev/dri/card1) [ 619.697] (II) Applying OutputClass "AMDgpu" to /dev/dri/card1 [ 619.795] (EE) open /dev/dri/card0: No such file or directory [ 619.806] (II) Applying OutputClass "AMDgpu" options to /dev/dri/card1 # Absent vtty or remote login for systemctl restart xdm, post-grub activity ends with login prompt on vtty1. -- You are receiving this mail because: You are the assignee for the bug.