External Display Hard Lockup #109
Labels
Comments
|
I can confirm that I'm experiencing the same issue. The system locks up completely when attempting to drag a window after reattaching the HDMI cable, and a hard reboot is required to recover. System Information:
|
|
Does anyone have any logs they can share? Also, a user plugin should never be able to crash the desktop environment in my opinion, but it can, and I had to add a lot of workarounds in the past to prevent crashes like these on Wayland. But in this case I don't have any idea what could be causing this. I don't have have a second monitor to test, so all help is welcome! |
gerritdevriese
added
help wanted
|
Unfortunately, its hard to obtain logs because the system is in a completely frozen state. Where would the logs be? I may be able to see if ssh server still works during the lockup. |
|
Here are the journal entries from the moment the HDMI cable for the external monitor was detached and reattached, and a window was dragged, causing the DE to freeze completely. Systemd Journal |
|
In the journal, this line
suggests it being a kernel bug, so I searched around and found this relevant bug report Window drag causes "Pageflip timed out! This is a kernel bug" , which eventually leads to kwin_wayland_drm: Pageflip timed out! This is a kernel bug. At this point, it seems like an upstream issue to me, but the people there are still investigating, so not 100% sure |
|
Hi, any updates? |
|
Just adding that I am experiencing this as well. I am on CachyOS. I have similar logs as posted by @asmj1108 right before the freeze there are a bunch of these repeating: More info:
Hopefully this can get fixed! This is an absolutely excellent script and precisely what i was looking from after moving to Gnome from KDE. I used the TilingShell extension, and this one you've made is super close to that. Assuming this issue gets fixed, I have a few feature requests I can drop here, and also happy to support (as I did TilingShell!) |
|
I experience the same issue. OS: openSUSE Tumbleweed I run a triple monitor setup, two are 1440p and one is 4k. The specific thing that causes my system to lock is changing the scaling setting on the 4k display. After doing this, attempting to move a window results in a lock. Changing the scaling on either of the 1440p displays does not trigger the bug. It does not matter if I change the 4k scaling from 100% to 75% or 125% or 200%. I don't feel like testing it again to verify, but I'm reasonably certain it also is caused by changing from 100% to 200% and then back to 100% as this is the typical scenario I encountered the bug in. With KZones enabled, without triggering the bug by changing scaling, moving a Window produces these logs: Systemd logs
Moving a Window and also moving the mouse to the top of the screen to make the dropdown for selecting a layout show or moving the mouse to the drop point of a specific zone produces the same log, except the GL_INVALID_OPERATION message will be shown more. In the first case of moving a Window without touching any of the KZones areas with the mouse, the GL_INVALID_OPERATION message shows exactly 3 times. When touching a KZones area, the message shows a variable number of times, something like 30-60 times. When the bug is triggered and the system locks, these logs are produced: Systemd log
The only thing I notice in common with the above logs is the line: Can anyone else who is experiencing this issue test only changing scaling settings and see if they can trigger it? |
|
I've been playing around with this a bit. (Un)fortunately I actually haven't seen the issue in a while so if it's still present it's pretty inconsistent. I'm on Arch kernel 6.12.8-arch1-1 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
I have plasma6 enabled with Wayland on NixOS and have tried the following on Solus Linux as well. This issue does not occur on X11 plasma 6 or plasma 5.
The below steps causes a full hard display lockup that requires a hard reboot (press and hold power button). I've observed that the processes continue running in the background (e.g. audio from video continues playing) even while the display, mouse, and keyboard (not even caps/num lock work) are completely frozen. Sysrq commands also do not function in this state.
To Reproduce
Expected behavior
No hard lockup
System information (please complete the following information):
Additional context
Initially reported as a KDE bug. Ref https://bugs.kde.org/show_bug.cgi?id=494619
The text was updated successfully, but these errors were encountered: