Bugzilla – Bug 1187510
Display crashes on RPI 4B with Gnome/Wayland
Last modified: 2023-01-24 06:05:10 UTC
The HDMI-connected display on my RPI 4B frequently becomes unresponsive. The system continues to run, however, and using ssh to connect and "sudo systemctl restart display-manager" will restore the display (after logging the session out, of course). These occurrences are accompanied by the following log records. Jun 16 10:14:10 rpi4a.WalkerStreet.info kernel: [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] *ERROR* [CRTC:66:crtc-3] flip_done timed out Jun 16 10:14:10 rpi4a.WalkerStreet.info kernel: [drm:drm_atomic_helper_wait_for_flip_done [drm_kms_helper]] *ERROR* [CRTC:66:crtc-3] flip_done timed out Jun 16 10:14:20 rpi4a.WalkerStreet.info kernel: [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] *ERROR* [PLANE:62:plane-3] flip_done timed out Jun 16 10:14:30 rpi4a.WalkerStreet.info kernel: [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] *ERROR* [PLANE:153:plane-25] flip_done timed out Any ideas?
Kernel issue.
Is it a recent regression? If yes, you can try older kernels from TW history repo, http://download.opensuse.org/history/
(In reply to Takashi Iwai from comment #2) > Is it a recent regression? If yes, you can try older kernels from TW > history repo, > http://download.opensuse.org/history/ This isn't particularly recent; I would think at least mid-May. Also, it's aarch64, which (I don't think) is kept in the history archives yet. I don't see it there now, anyway.
OK, then could you check the kernel in my OBS repo, e.g. home:tiwai:kernel:5.10, home:tiwai:kernel:5.11, etc? We want to narrow down the regression range.
(In reply to Takashi Iwai from comment #4) > OK, then could you check the kernel in my OBS repo, e.g. > home:tiwai:kernel:5.10, home:tiwai:kernel:5.11, etc? Here's what I've tested... kernel-default-5.9.14-1.1.gc648a46 from https://download.opensuse.org/repositories/home:/tiwai:/kernel:/5.9/ARM/ kernel-default-5.10.16-1.1.g11381f3 from https://download.opensuse.org/repositories/home:/tiwai:/kernel:/5.10/ARM/ kernel-default-5.11.16-1.1.ge06d321 from https://download.opensuse.org/repositories/home:/tiwai:/kernel:/5.11/ARM/ - I didn't experience an unresponsive display with any of these. I did, however, notice the following: - GDM runs at 100% CPU (of one CPU), although I believe I saw this not happen once under 5.9, but I haven't reproduced it. - In addition to the log records I mentioned earlier, I also get "gnome-shell[4193]: glamor: 'wl_drm' not supported" often (which, of course, may be unrelated). kernel-default-5.12.9-1.1.aarch64 and kernel-default-5.12.10-1.1.aarch64 - These are the kernels that were installed (and not cleaned up) via "zypper dup". - In addition to the symptoms from 5.9-5.11, I also get the "unresponsive display" problem. I'm currently running kernel-default-5.11.16-1.1.ge06d321. Let me know how else I can help.
Adding more people to Cc, as it's rather a regression for RPi driver.
FYI, with only a couple of hours of use, I haven't seen any display "crashes" while using the recent release of Tumbleweed for ARM (20210710 - kernel 5.13.0-1-default), although the display mysteriously wouldn't wake up this morning (in response to pressing Shift on the keyboard) until I restarted display-manager. I did get the "flip_done timed out" log messages 6-7 minutes after the system booted at 17:20 on July 13: Jul 13 17:26:38 rpi4a.WalkerStreet.info kernel: [drm:drm_atomic_helper_wait_for_flip_done [drm_kms_helper]] *ERROR* [CRTC:66:crtc-3] flip_done timed out Jul 13 17:26:38 rpi4a.WalkerStreet.info kernel: [drm:drm_crtc_commit_wait [drm]] *ERROR* flip_done timed out Jul 13 17:26:48 rpi4a.WalkerStreet.info kernel: [drm:drm_crtc_commit_wait [drm]] *ERROR* flip_done timed out Jul 13 17:26:58 rpi4a.WalkerStreet.info kernel: [drm:drm_crtc_commit_wait [drm]] *ERROR* flip_done timed out Jul 13 17:27:08 rpi4a.WalkerStreet.info kernel: [drm:drm_crtc_commit_wait [drm]] *ERROR* flip_done timed out
Does this still happen? It looks the bug bitrot after such a long time :/.
(In reply to Jiri Slaby from comment #8) > Does this still happen? It looks the bug bitrot after such a long time :/. This hasn't happened for a long time. Bugrot is definitely the right diagnosis. Thanks for following up.
Good.