Bugzilla – Bug 1216575
RPi2 TW images not start into desktop environment
Last modified: 2024-02-29 17:38:02 UTC
Hello, i tried the current Tumbleweed images for the RPi2 [1,2,3,4]. At the end of the boot process there is only a black screen and not the respective desktop environment. Thanks Kasimir [1]https://download.opensuse.org/ports/armv7hl/tumbleweed/appliances/openSUSE-Tumbleweed-ARM-E20-raspberrypi2.armv7l-2023.10.11-Snapshot20231017.raw.xz [2]https://download.opensuse.org/ports/armv7hl/tumbleweed/appliances/openSUSE-Tumbleweed-ARM-LXQT-raspberrypi2.armv7l-2023.10.11-Snapshot20231017.raw.xz [3]https://download.opensuse.org/ports/armv7hl/tumbleweed/appliances/openSUSE-Tumbleweed-ARM-X11-raspberrypi2.armv7l-2023.10.11-Snapshot20231017.raw.xz [4]https://download.opensuse.org/ports/armv7hl/tumbleweed/appliances/openSUSE-Tumbleweed-ARM-XFCE-raspberrypi2.armv7l-2023.10.11-Snapshot20231017.raw.xz
Nothing has changed with the new images [1,2,3]. The U-Boot messages are displayed, the Grub menu appears, the boot messages run through and the screen remains black at the point where the desktop environment should appear. Login via ssh is possible. [1] https://download.opensuse.org/ports/armv7hl/tumbleweed/appliances/openSUSE-Tumbleweed-ARM-LXQT-raspberrypi2.armv7l-2023.10.11-Snapshot20231108.raw.xz [2] https://download.opensuse.org/ports/armv7hl/tumbleweed/appliances/openSUSE-Tumbleweed-ARM-X11-raspberrypi2.armv7l-2023.10.11-Snapshot20231108.raw.xz [3] https://download.opensuse.org/ports/armv7hl/tumbleweed/appliances/openSUSE-Tumbleweed-ARM-XFCE-raspberrypi2.armv7l-2023.10.11-Snapshot20231108.raw.xz
If I add the follow to the kernel command line, it boots up to the desktop environment: modprobe.blacklist=vc4
Created attachment 870796 [details] dmesg from Snapshot20231114 Here is the output of dmesg for https://download.opensuse.org/ports/armv7hl/tumbleweed/appliances/openSUSE-Tumbleweed-ARM-X11-raspberrypi2.armv7l-2023.10.11-Snapshot20231114.raw.xz
I can't see anything wrong in logs... Lets add some DRM experts.
Created attachment 871065 [details] dmesg from Snapshot20231127 No change with Snapshot20231127
FYI, I'm also seeing this on a RPI4b running Tumbleweed 20231129 and Gnome. modprobe.blacklist=vc4 fixes the black screen (although breaks other things, I assume). I'm not sure when it started, as I skipped multiple releases while out of town.
Issues with RPi 4b are differnt, see bsc#1217512.
Created attachment 871853 [details] dmesg from Snapshot20240111 Are there any news? The problems still exist with the Snapshot20240111.
Created attachment 871854 [details] journalctl from Snapshot20240111
Hm, I can't see any errors, display manager reports that it is runing fine, but still nothing on the HDMI output?? # systemctl status display-manager.service ● display-manager.service - X Display Manager Loaded: loaded (/usr/lib/systemd/system/display-manager.service; enabled; preset: enabled) Active: active (running) since Tue 2024-01-23 07:17:18 UTC; 3min 23s ago Process: 2024 ExecStart=/usr/lib/X11/display-manager start (code=exited, status=0/SUCCESS) Main PID: 2032 (lightdm) Tasks: 7 (limit: 1957) CPU: 3.744s CGroup: /system.slice/display-manager.service ├─2032 /usr/sbin/lightdm ├─2039 /usr/bin/Xorg.bin :0 -seat seat0 -auth /run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch └─2082 lightdm --session-child 13 20 Jan 23 07:17:17 2b11 systemd[1]: Starting X Display Manager... Jan 23 07:17:17 2b11 display-manager[2028]: /etc/vconsole.conf available Jan 23 07:17:17 2b11 display-manager[2028]: XKBLAYOUT: us Jan 23 07:17:17 2b11 display-manager[2028]: XKBLAYOUT is already set. Better don't touch X11 keyboard configuration. Jan 23 07:17:18 2b11 systemd[1]: Started X Display Manager.
Did this OpenSource Driver stack ever work on RPi2? I think things didn't improve before RPi4. :-( Reassigning and adding our DRM experts ...
It is working fine with RPi3's
Could you try to pass boot options "drm.debug=0x1e log_buf_len=16M" and get the dmesg? And we can compare with the working case on Ivan's RPi3, for example. Also, when you boot with nomodeset boot option, it'll keep working?
Created attachment 872320 [details] dmesg from Snapshot20240128 with boot options Attached is the output of dmesg with the boot options "drm.debug=0x1e log_buf_len=16M". Yes, with nomodeset boot option it works.
Thanks. Through a quick glance, I see no obvious errors; the system switches from the simple fb to vc4 around 60 secs after boot, and it probed the HDMI monitor, set up 1920x1080. Can you try with another monitor? I'm not sure whether it's a problem of the driver or the combination of the hardware.
This happens to me too. Regular Samsung monitor. I was thinking if this is some kind of crash in the login manager... but I haven't had time to look into this further. Note: this is 32 bit system.
Created attachment 872552 [details] dmesg from Snapshot20240131 with boot options on Dell screen The same thing happens on a Dell (P2213f) and an HP (E223) monitor.
Created attachment 872553 [details] dmesg from Snapshot20240131 with boot options on HP screen
After 2 weeks uptime I see this, could it be somehow related? ... [drm:vc4_bo_create [vc4]] *ERROR* Failed to allocate from GEM DMA helper: vc4-drm soc:gpu: [drm] V3D: 33420kb BOs (35) vc4-drm soc:gpu: [drm] V3D shader: 128kb BOs (31) vc4-drm soc:gpu: [drm] dumb: 4116kb BOs (5) vc4-drm soc:gpu: [drm] binner: 16384kb BOs (1) vc4-drm soc:gpu: [drm] total purged BO: 27352kb BOs (56) ...
With the current image [1] the problem still exists, the screen ultimately remains black. [1] https://download.opensuse.org/ports/armv7hl/tumbleweed/appliances/openSUSE-Tumbleweed-ARM-X11-raspberrypi2.armv7l-2024.01.16-Snapshot20240225.raw.xz