This strange behavior has started happening after 5.2.1 kernel update. I use KDE Plasma with Wayland. I use Dell XPS 9350 laptop.
Every few minutes of usage, nothing new will be drawn on the screen. In every way the computer will appear to have frozen because no input will cause the screen to update. But that’s deceiving, because the OS itself continues to work, it’s just that no changes are being drawn on the screen.
Here’s how I can tell and recover: I can press buttons like caps lock and adjust monitor backlight level. But most tellingly, I can launch applications or keep typing, but again with no changes immediately visible, until I close the laptop lid, let the screen turn off, and open it again. Then I can see the changes since it froze, and it works again for few more minutes, until it repeats the “freezing” symptom again.
In the logs I don’t see anything suspicious up until I close the lid. It looks like this:
Jul 28 00:55:06 localhost.localdomain systemd-logind[1196]: Lid closed.
Jul 28 00:54:01 localhost.localdomain plasmashell[3168]: qt.qpa.wayland.backingstore: Delivering update request through fallback timer, ma>
Jul 28 00:53:35 localhost.localdomain dbus-daemon[1118]: [system] Activation via systemd failed for unit 'dbus-org.freedesktop.resolve1.se>
Jul 28 00:53:35 localhost.localdomain dbus-daemon[1118]: [system] Activating via systemd: service name='org.freedesktop.resolve1' unit='db>
Jul 28 00:53:34 localhost.localdomain plasmashell[3168]: qt.qpa.wayland.backingstore: Delivering update request through fallback timer, ma>
Jul 28 00:51:27 localhost.localdomain dbus-daemon[1118]: [system] Activation via systemd failed for unit 'dbus-org.freedesktop.resolve1.se>
Jul 28 00:51:27 localhost.localdomain dbus-daemon[1118]: [system] Activating via systemd: service name='org.freedesktop.resolve1' unit='db>
Jul 28 00:50:52 localhost.localdomain plasmashell[3168]: qt.qpa.wayland.backingstore: Delivering update request through fallback timer, ma>
Jul 28 00:50:52 localhost.localdomain plasmashell[3168]: qt.qpa.wayland.backingstore: Delivering update request through fallback timer, ma>
Jul 28 00:50:52 localhost.localdomain kdeinit5[3139]: Service ":1.168" unregistered
I haven’t tried other DEs, or reverting to the previous kernel yet. I’ll try those and report back. But in the meantime, if anyone has any insight, it would be much appreciated.
I had been running the Plasma/Wayland setup for months before this, and only saw this screen draw freezing very recently.
Here is the summary of things I tried so far:
KDE/Plasma on Wayland: PROBLEM
KDE/Plasma on X11: PROBLEM
FVWM2 on X11: NO problem
This leads me to guess there might have been a driver or some other low level update recently, possibly with 5.2.1 Kernel (or maybe even Qt), that when KDE/Qt use some fancy HW accelerated compositing results in this symptom. I can even run the same KDE and Firefox apps in my fvwm2 session with no such freezing issues. I personally like fvwm2 and, in a weird way, glad to be forced to use it again, but that aside, it would be good to find and fix the problem. I’ll try even more things and report back - maybe previous Kernel, and disabling fancy effects in KDE.
Hi, I have similar problem with 5.2.1, 5.2.2 and 5.2.4 from kernel:stable. But in my case problem exists even in sddm from the beginning, and continues in KDE Plasma (X, not wayland), screen is updated from time to time. Problem also exists in TTY (even when X is stopped), actually in TTY it’s even worse. Here is my bugreport, HW — Intel HD 530: https://bugzilla.opensuse.org/show_bug.cgi?id=1143139
The Dell XPS 9350 has Intel Iris 540 graphics. I don’t use any special drivers. It’s a default Tumbleweed install.
Anyway, I think I got a bit more insight, which might be related.
First of all, fvwm2 also experienced the problem with the kernel 5.2.1, it just took a lot longer - hours (instead of minutes with KDE).
Secondly, I booted with kernel 5.1.16 and I don’t have any issues, including with KDE Plasma/Wayland!
Finally, another thing I noticed with 5.2 kernel, which might be related to this symptom, is that if I run
$ sudo smartctl -a /dev/nvme0
...
Error Information Log Entries: 2,887
Error Information (NVMe Log 0x01, max 64 entries)
Num ErrCount SQId CmdId Status PELoc LBA NSID VS
0 2887 0 0x0002 0x4004 0x000 0 0 -
1 2886 0 0x000e 0x4004 0x000 0 0 -
I see the “Error Information Log Entries” count increasing pretty frequently, maybe 1 every few mins. This, also happened less frequently with fvwm2/X11 on Kernel 5.2; and doesn’t happen at all on Kernel 5.1. So possibly a Kernel storage layer regression in 5.2 causes this? That’s the best guess I have so far, an I think I’m staying on 5.1 for now.
Do you have an NVMe SSD by any chance? Have you noticed journalctl logs like these being more frequent or its numbers increasing at a higher pace after the upgrade to 5.2.1?
Jul 28 08:53:36 localhost.localdomain smartd[1113]: Device: /dev/nvme0, number of Error Log entries increased from 2877 to 2882
I switched to using my NVIDIA card (I’ve been using the Intel IGFX), and while I was using mousepad (I’ve been using GEdit) everything froze when I did undo->redo->undo.
The music continued playing in the background until the song was over, but then it didn’t play the next song.
I didn’t have persistent logging enabled, so I can’t say what the problem really was.
CTRL+Alt+F1 and Ctrl+Alt+Delete and the front power button didn’t do anything, so I was forced to use the switch on the power supply.
Wow, this is indeed it! I didn’t even know what PSR was until now. Panel Self Refresh is apparently a SoC/GPU power saving optimization, first demoed by Intel in 2011, when a display monitor has its own framebuffer that doesn’t require GPU to be fully awake when the contents on the screen are static - i.e. it refreshes the display from its own buffer at whatever frequency it operates, instead of making the GPU do the same work. Theoretically, the GPU can be cut off from the display and the display could maintain that same static buffer on screen on its own.
So, if there was a bug in the PSR implementation, it would make sense if it might result in symptoms like these - stuttering or not refreshing the screen at all, while the rest of the computer appears to continue to run. I searched and found a similar report for Arch too, ending up in this same suggestion.
To be clear, to fix temporarily, you need to add
i915.enable_psr=0
kernel parameter during boot. To do so:
reboot
on grub boot screen, press e for edit
this will bring up an editor
find the first line that starts with linux or linuxefi
at the end of that line add the above boot parameter
press ctrl-x to continue booting
You’d have to do this after every reboot. Alternatively, one could permanently add it via YaST or editing and applying grub configuration manually (but remember to remove it once it’s fixed so you get some bonus power savings).
Finally, it looks like the bug fix is in for kernel 5.2.8.