Screen is black after update to kernel-default;5.3.18-lp152.44

Hello,
yesterday, Oct. 3rd 2020, there was a security update to kernel-default;5.3.18-lp152.44 for openSUSE LEAP 15.2. Since then, my screen turns black during boot and remains black. In the GRUB-menu I can select the previous kernel 5.3.18-lp152.41, and all is ok. But when selecting 5.3.18-lp152.44, the screen turns black.
It is a desktop machine with KDE 5.18.5. The graphics card is a Radeon R5 230 OEM and the radeon kernel module is used.
When I boot 5.3.18-lp152.44, the system seems to work. But with a black screen. No mouse cursor visible.
From a separate laptop I can login using ssh and can check what is going on.
When I enter the password on the black screen, I can check from the laptop that the login succeeded.
I can check that my consoles for the KDE-desktop are started. But I can’t see them.
I can even press CTRL-ALT-F1 to switch to a virtual console on the black screen. I can login as root
and do a reboot on the black screen. The screen turns on when the BIOS boot screen is displayed.
When I boot kernel 5.3.18-lp152.44 using nomodeset, everything works well (beside the bad performance).
So it really seems that the screen is just turned black. But everything else is working.
Is there something I can test or configure? Some hints would be appreciated.

It is unclear - do you see anything when you switch to tty1 or you also log in blindly?

Is there something I can test or configure?

What is output of

ls -l /sys/class/drm
grep . /sys/class/drm/*/*/enabled /sys/class/drm/*/*/status

with both kernels?

Thank you for looking after this.
When switching to tty1 the screen stays black. I log in blindly and reboot blindly. The first I see again is the BIOS boot screen.

This is the output for kernel 5.3.18-lp152.41 (the good one):

spica:~ # ls -l /sys/class/drm
total 0
lrwxrwxrwx 1 root root    0 Oct  4 15:29 card0 -> ../../devices/pci0000:00/0000:00:01.0/0000:01:00.0/drm/card0
lrwxrwxrwx 1 root root    0 Oct  4 15:29 card0-DVI-D-1 -> ../../devices/pci0000:00/0000:00:01.0/0000:01:00.0/drm/card0/card0-DVI-D-1
lrwxrwxrwx 1 root root    0 Oct  4 15:29 card0-HDMI-A-1 -> ../../devices/pci0000:00/0000:00:01.0/0000:01:00.0/drm/card0/card0-HDMI-A-1
lrwxrwxrwx 1 root root    0 Oct  4 15:29 card0-VGA-1 -> ../../devices/pci0000:00/0000:00:01.0/0000:01:00.0/drm/card0/card0-VGA-1
lrwxrwxrwx 1 root root    0 Oct  4 15:29 renderD128 -> ../../devices/pci0000:00/0000:00:01.0/0000:01:00.0/drm/renderD128
lrwxrwxrwx 1 root root    0 Oct  4 15:29 ttm -> ../../devices/virtual/drm/ttm
-r--r--r-- 1 root root 4096 Oct  4 15:29 version
spica:~ # grep . /sys/class/drm/*/*/enabled /sys/class/drm/*/*/status
/sys/class/drm/card0/card0-DVI-D-1/enabled:enabled
/sys/class/drm/card0/card0-HDMI-A-1/enabled:disabled
/sys/class/drm/card0/card0-VGA-1/enabled:disabled
/sys/class/drm/card0/card0-DVI-D-1/status:connected
/sys/class/drm/card0/card0-HDMI-A-1/status:disconnected
/sys/class/drm/card0/card0-VGA-1/status:disconnected

This is the output from kernel 5.3.18-lp152.44 (the black one):

spica:~ # ls -l /sys/class/drm
total 0
lrwxrwxrwx 1 root root    0 Oct  4 15:35 card0 -> ../../devices/pci0000:00/0000:00:01.0/0000:01:00.0/drm/card0
lrwxrwxrwx 1 root root    0 Oct  4 15:35 card0-DVI-D-1 -> ../../devices/pci0000:00/0000:00:01.0/0000:01:00.0/drm/card0/card0-DVI-D-1
lrwxrwxrwx 1 root root    0 Oct  4 15:35 card0-HDMI-A-1 -> ../../devices/pci0000:00/0000:00:01.0/0000:01:00.0/drm/card0/card0-HDMI-A-1
lrwxrwxrwx 1 root root    0 Oct  4 15:35 card0-VGA-1 -> ../../devices/pci0000:00/0000:00:01.0/0000:01:00.0/drm/card0/card0-VGA-1
lrwxrwxrwx 1 root root    0 Oct  4 15:35 renderD128 -> ../../devices/pci0000:00/0000:00:01.0/0000:01:00.0/drm/renderD128
lrwxrwxrwx 1 root root    0 Oct  4 15:35 ttm -> ../../devices/virtual/drm/ttm
-r--r--r-- 1 root root 4096 Oct  4 15:35 version
spica:~ # grep . /sys/class/drm/*/*/enabled /sys/class/drm/*/*/status
/sys/class/drm/card0/card0-DVI-D-1/enabled:enabled
/sys/class/drm/card0/card0-HDMI-A-1/enabled:disabled
/sys/class/drm/card0/card0-VGA-1/enabled:disabled
/sys/class/drm/card0/card0-DVI-D-1/status:connected
/sys/class/drm/card0/card0-HDMI-A-1/status:disconnected
/sys/class/drm/card0/card0-VGA-1/status:disconnected

Beside the different time, the output is the same for both kernels.

I did some more tests. I removed the DVI-cable and used a VGA-cable. This works with both kernels. When using VGA with kernel 5.3.18-lp152.44, there is some flickering on the left edge. And some pixels on the top edge are missing. With kernel 5.3.18-lp152.41, there is no flickering on the left edge and all pixels on the top edge are visible. Could it be that with kernel 5.3.18-lp152.44, the radeon module comes with some changes in timing for the graphics card? And that leads to a non-working DVI-connection? At least for my monitor Dell U2410, using 1920x1200 pixel at 60 Hz?

HDMI-connection has the same problem as DVI-connection. Works with kernel 5.3.18-lp152.41. Not with kernel 5.3.18-lp152.44.

I guess at this point you need to open bug report. Provide dmesg output for both good and bad kernels and add the same information what works and what does not.

Are you sure you are using radeon module? Cursory google search shows similar issues with amdgpu module.

Ok, I will open a bug report

lsmod tells this:

spica:~ # lsmod | grep -E 'amdgpu|radeon'
radeon               1630208  13
i2c_algo_bit           16384  1 radeon
drm_kms_helper        229376  1 radeon
ttm                   122880  1 radeon
drm                   544768  13 drm_kms_helper,radeon,ttm

So it should be radeon.
Thank you for your help!

I have an old R7 working just fine on the .44 kernel. Maybe the display manager plays a role in this problem. Try this:

sudo update-alternatives --config default-displaymanger

If there are other display managers to select besides the current selection and console, try selecting that other and reboot. If it doesn’t help, provide us more information from a GUI terminal (e.g. konsole or gnome-terminal) about your configuration and hardware:

inxi -bay

e.g.

# inxi -bay
System:
  Host: asa88 Kernel: 5.3.18-lp152.44-default x86_64 bits: 64 compiler: gcc
  v: 7.5.0
  parameters: noresume mitigations=auto consoleblank=0
    radeon.cik_support=0 amdgpu.cik_support=1 debug rd.debug
  Desktop: IceWM 1.4.2 info: icewmtray **dm: XDM** Distro: openSUSE Leap 15.2
Machine:
  Type: Desktop Mobo: ASUSTeK model: A88X-PRO v: Rev X.0x
  serial: 140323952800121 UEFI: American Megatrends v: 2603 date: 03/10/2016
CPU:
  Info: Quad Core AMD A10-7850K Radeon R7 12 Compute Cores 4C+8G [MCP]
  arch: Steamroller speed: 1698 MHz min/max: 1700/3700 MHz
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
  Display: **server: X.Org 1.20.3 driver: modesetting** 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 3.33.0 5.3.18-lp152.44-default LLVM 9.0.1)
  v: 4.5 Mesa 19.3.4 direct render: Yes
Network:
  Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet
  vendor: ASUSTeK driver: r8169 v: kernel port: e000 bus ID: 04:00.0
  chip ID: 10ec:8168
Drives:
  Local Storage: total: 238.47 GiB used: 29.58 GiB (12.4%)
Info:...
  inxi: 3.1.07

Note above that while the kernel video driver is amdgpu, the employed DDX driver is the modesetting rather than amdgpu (which is the upstream default, and newer technology than xf86-video-*).

Something else to try is to disable the amdgpu DDX and the radeon DDX, either thus:

sudo zypper rm xf86-video-amdgpu xf86-video-ati xorg-x11-driver-video

or alternatively to removing the DDX packages, change /etc/X11/xorg.conf.d/50-device.conf (an optional file that is nothing by comments by default) to look thus:

Section "Device"
    Identifier "DefaultDevice"
	Driver	"modesetting"
EndSection

s/nothing by comments/nothing but comments/ in comment #8.

I installed TDE/TDM on same #8 host, which works just as well:

# pinxi -SGay
System:
  Host: asa88 Kernel: 5.3.18-lp152.44-default x86_64 bits: 64 compiler: gcc
  v: 7.5.0
  parameters: noresume mitigations=auto consoleblank=0
  radeon.cik_support=0 amdgpu.cik_support=1 video=1440x900@60
  Desktop: Trinity R14.0.8 tk: Qt 3.5.0 info: kicker wm: Twin 3.0 **dm: TDM**
  Distro: openSUSE Leap 15.2
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
  Display: server: **X.Org 1.20.3 driver: modesetting** 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 3.33.0 5.3.18-lp152.44-default LLVM 9.0.1)
  v: 4.5 Mesa 19.3.4 direct render: Yes

This is the output of inxi -ba running the .41-kernel. With the .44-kernel, when the screen is black, I can’t see a GUI-window, to run inxi


spica:~ # inxi -ba
System:    Host: spica Kernel: 5.3.18-lp152.41-default x86_64 bits: 64 compiler: gcc v: 7.5.0 
           parameters: BOOT_IMAGE=/boot/vmlinuz-5.3.18-lp152.41-default 
           root=UUID=604f3c2b-599d-4fc6-b93e-3674a9f83113 showopts noplymouth 
           resume=/dev/disk/by-uuid/b0dd0827-f16f-47dd-8d60-f25beb539be1 quiet mitigations=auto 
           Console: tty 1 wm: kwin_x11 dm: SDDM Distro: openSUSE Leap 15.2 
Machine:   Type: Desktop Mobo: MSI model: Z170-A PRO (MS-7971) v: 1.0 serial: GA16689445 
           UEFI [Legacy]: American Megatrends v: 1.G0 date: 11/23/2016 
CPU:       Quad Core: Intel Core i5-6500 type: MCP arch: Skylake-S speed: 3494 MHz min/max: 800/3600 MHz 
Graphics:  Device-1: Advanced Micro Devices [AMD/ATI] Caicos [Radeon HD 6450/7450/8450 / R5 230 OEM] 
           vendor: PC Partner Limited driver: radeon v: kernel bus ID: 01:00.0 chip ID: 1002:6779 
           Display: server: X.Org 1.20.3 compositor: kwin_x11 driver: ati,radeon 
           unloaded: fbdev,modesetting,vesa display ID: :0 screens: 1 
           Screen-1: 0 s-res: 1920x1200 s-dpi: 96 s-size: 508x317mm (20.0x12.5") s-diag: 599mm (23.6") 
           Monitor-1: DVI-0 res: 1920x1200 hz: 60 dpi: 94 size: 518x324mm (20.4x12.8") diag: 611mm (24.1") 
           OpenGL: renderer: AMD CAICOS (DRM 2.50.0 / 5.3.18-lp152.41-default LLVM 9.0.1) v: 3.3 Mesa 19.3.4 
           compat-v: 3.1 direct render: Yes 
Network:   Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet driver: r8169 v: kernel port: d000 
           bus ID: 03:00.0 chip ID: 10ec:8168 
           Device-2: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet vendor: Micro-Star MSI 
           driver: r8169 v: kernel port: c000 bus ID: 05:00.0 chip ID: 10ec:8168 
Drives:    Local Storage: total: 991.14 GiB used: 644.08 GiB (65.0%) 
Info:      Processes: 225 Uptime: N/A Memory: 15.59 GiB used: 1.42 GiB (9.1%) Init: systemd v: 234 runlevel: 5 
           target: graphical.target Compilers: gcc: 7.5.0 alt: 7 Shell: bash (su) v: 4.4.23 running in: konsole 
           inxi: 3.1.00

This mentions only the radeon driver.
I tried ICEwm as another window manager. But the screen turns black too. The screen turns black shortly after the message “loading initial ramdisk”. I am using noplymouth and quiet as boot options. If I drop them, I can see the startup messages. But then the screen turns black when the login-screen should appear. So I would say it is not related to the window manager. Because the decision, which window manager to use, is done on the login screen. And that one is already black.

I will create a bug report soon, because using a workaround by choosing a different driver, would not solve the real problem. The easiest way for me to use a workaround with kernel .44, would be just to use a VGA-cable instead of a DVI-cable. Its curious why the problem depends on the connector of the graphics card.

Or does it make no sense to create a bug report for an old Radeon R5 card?

Hi
I’ve not seen issues with even my Mullins R3 gpu running the amdgpu driver, I suspect you might get asked to switch to the newer driver and see if it duplicates.


cat /etc/modprobe.d/49-radeon.conf 
blacklist radeon

amdgpu.si_support=1 amdgpu.cik_support=0

This is stable Leap release. If something stops working in stable release after routine kernel update it is a bug that must be reported.

Based upon device ID, I have the exact same GPU:

# inxi -SGIay
System:
  Host: gx78b Kernel: 5.3.18-lp152.44-default x86_64 bits: 64
  parameters: root=/dev/sda15 noresume mitigations=auto consoleblank=0
  net.ifnames=0 ipv6.disable=1 vga=791 video=1024x768@60 video=1440x900@60 5
  Desktop: Trinity R14.0.8 tk: Qt 3.5.0 info: kicker wm: Twin 3.0 **dm: TDM**
  Distro: openSUSE Leap 15.2
Graphics:
  Device-1: AMD Caicos [Radeon HD 6450/7450/8450 / R5 230 OEM] vendor: Dell
  driver: radeon v: kernel bus ID: 01:00.0 chip ID: 1002:6779
  Display: **server: X.Org 1.20.3 driver: modesetting** 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 CAICOS (DRM 2.50.0 / 5.3.18-lp152.44-default LLVM 9.0.1)
  v: 3.3 Mesa 19.3.4 compat-v: 3.1 direct render: Yes
Info:...
  running in: konsole **inxi: 3.1.07**

Everything is working as expected here. I’ve highlighted above some differences between mine and yours. I suspect you could have an instant fix thus:

sudo zypper rm xf86-video-ati xorg-x11-driver-video xf86-video-r128 xf86-video-mach64
sudo zypper al xf86-video-at?

If it doesn’t work, and you’re unable to try a DisplayPort cable first, I’d put the bug on the video output component (CRTC) of the radeon kernel driver.

Radeon R5 230 is a Terascale 2 family chip, i.e. no amdgpu driver, radeon driver is preferred.
Mullins is a GCN (1.0).

To OP: try to update X11 and Mesa 3D.
Or update kernel from Kernel:stable repo.
And see what happens.

Thank you for that hint. So I don’t try amdgpu.

I did that zypper-commands. Because my graphics card has a HDMI-port instead of a DisplayPort-port, I did the tests with the HDMI-port, which also showed that problem. Unfortunately the screen turns black furthermore with .44-kernel. But I managed to get the inxi-Information by login blindly into the KDE desktop, switching blindly to root in a GUI-console and used a shell script to run inxi to redirect the output to a file. This is the result of the inxi -SGIay 80 (my inxi V 3.1.00 does not like -y without a value):

System:
  Host: spica Kernel: 5.3.18-lp152.44-default x86_64 bits: 64 compiler: gcc 
  v: 7.5.0 
  parameters: BOOT_IMAGE=/boot/vmlinuz-5.3.18-lp152.44-default 
  root=UUID=604f3c2b-599d-4fc6-b93e-3674a9f83113 showopts noplymouth 
  resume=/dev/disk/by-uuid/b0dd0827-f16f-47dd-8d60-f25beb539be1 quiet 
  mitigations=auto 
  Console: N/A wm: kwin_x11 dm: SDDM Distro: openSUSE Leap 15.2 
Graphics:
  Device-1: AMD Caicos [Radeon HD 6450/7450/8450 / R5 230 OEM] 
  vendor: PC Partner Limited driver: radeon v: kernel bus ID: 01:00.0 
  chip ID: 1002:6779 
  Display: server: X.Org 1.20.3 compositor: kwin_x11 **driver: modesetting** 
  unloaded: fbdev,vesa alternate: ati display ID: :0 screens: 1 
  Screen-1: 0 s-res: 1920x1200 s-dpi: 96 s-size: 508x317mm (20.0x12.5") 
  s-diag: 599mm (23.6") 
  Monitor-1: HDMI-1 res: 1920x1200 hz: 60 dpi: 94 size: 518x324mm (20.4x12.8") 
  diag: 611mm (24.1") 
  OpenGL: 
  renderer: AMD CAICOS (DRM 2.50.0 / 5.3.18-lp152.44-default LLVM 9.0.1) 
  v: 3.3 Mesa 19.3.4 compat-v: 3.1 direct render: Yes 
Info:
  Processes: 207 Uptime: N/A Memory: 15.59 GiB used: 569.6 MiB (3.6%) 
  Init: systemd v: 234 runlevel: 5 target: graphical.target Compilers: 
  gcc: 7.5.0 alt: 7 Shell: runxi running in: konsole inxi: 3.1.00

This now mentions the driver: modesetting as in your inxi-output.

I am on the standard openSUSE Leap 15.2 repositories plus packman repositories for video purposes. Could the packman repository be a reason for the problem?

I will try to find a kernel update from Kernel:stable repo. I already set in /etc/zypp/zypp.conf

multiversion.kernels = latest,latest-1,latest-2,latest-3,running

not to lose the working kernel.

Says who? Modesetting is upstream default DDX driver, works nice with my exact same GPU as OP’s, and with my AMD IGPs, and my AMD Oland GPU, and my Intel IGPs, and my NVidia GPUs.

But your inxi parameters show quiet and noplymouth. https://en.opensuse.org/SDB:Linuxrc says to use plymouth=0. I never have plymouth installed, so don’t know if noplymouth is valid within openSUSE. Removing quiet and disabling plymouth according to the documentation may put something to see on the screen after making a Grub selection. If that happens, and then goes black when SDDM loads, then you know it must be a SDDM problem, which you should be able to workaround with a switch to LightDM (once its installed). If it’s already installed then use YaST to switch, or from shell prompt:

sudo update-alternatives --config default-displaymanager

If you find the problem starts with SDDM, then look for .rpm files for /etc/sddm.conf and in /etc/sddm.conf.d/ that might point to something (inexplicably, given the apparent kernel cause) changed or needing change.

I am on the standard openSUSE Leap 15.2 repositories plus packman repositories for video purposes. Could the packman repository be a reason for the problem?
I don’t believe anything from packman could play a part in this.

You can try upgrading to the latest inxi thus:

sudo inxi -U

Its author has been pumping a lot of changes into it in recent months. If -U fails, you can bypass the restriction using /etc/inxi.conf, or by uninstalling it from zypper or yast, then installing directly from upstream.

https://doc.opensuse.org/documentation/leap/reference/html/book.opensuse.reference/cha-tuning-multikernel.html
https://en.opensuse.org/SDB:Keep_multiple_kernel_versions

Specify needed kernel by name (number). Otherwise you will lose it in future.

Configure the multiversion kernel feature

There are several options mentioned in /etc/zypp/zypp.conf as how to configure the multiversion kernel feature:

Comma separated list of kernel packages to keep installed in parallel, if the

above multiversion variable is set. Packages can be specified as

2.6.32.12-0.7 - Exact version to keep

I removed both noplymouth and quiet. And set LightDM as display manager. For the working kernel .41 this happens:

I see "loading initial ramdisk"
I see for about 5 seconds startup messages.
Screen turns black for some seconds.
I see more startup messages.
Login screen for LightDM appears.

For the non-working kernel .44, this happens:

I see "loading initial ramdisk"
I see for about 5 seconds startup messages.
Screen turns black and remains black.

Display manager seems not to be the reason.
In the dmesg-messages the first radeon- or drm-messages appear after about 5 seconds (only radeon/drm-related messages shown):

    5.048328] [drm] radeon kernel modesetting enabled.
    5.103459] radeon 0000:01:00.0: remove_conflicting_pci_framebuffers: bar 0: 0xc0000000 -> 0xcfffffff
    5.103460] radeon 0000:01:00.0: remove_conflicting_pci_framebuffers: bar 2: 0xdfe20000 -> 0xdfe3ffff
    5.103462] fb0: switching to radeondrmfb from VESA VGA
    5.273996] radeon 0000:01:00.0: vgaarb: deactivate vga console
    5.275735] [drm] initializing kernel modesetting (CAICOS 0x1002:0x677B 0x103C:0x90B7 0x00).
    5.275770] radeon 0000:01:00.0: No more image in the PCI ROM
    5.276245] radeon 0000:01:00.0: VRAM: 1024M 0x0000000000000000 - 0x000000003FFFFFFF (1024M used)
    5.276247] radeon 0000:01:00.0: GTT: 1024M 0x0000000040000000 - 0x000000007FFFFFFF
...

Meanwhile I changed to an older radeon card with only 1GB to hope to get around the problem. But it shows the same problem on the DVI-port. The card has a DisplayPort, which I can’t test, until I have a display port cable or adapter. No VGA-port on that card.