Since the update to xorg-server 1.19 in both Mageia 6 and Fedora 25, for many different users and various different drivers as can be seen in downstream bug report comments, plasma freezes. It happens right at splash screen or during normal use of the desktop. When it does appear, switching to a virtual terminal with Ctrl+Alt+Fx then back to X unfreezes it (until the next freeze). Downstream bug reports: - KDE https://bugs.kde.org/show_bug.cgi?id=373427 - Mageia https://bugs.mageia.org/show_bug.cgi?id=19869 - Fedora https://bugzilla.redhat.com/show_bug.cgi?id=1399396 It's not easy to know where the bug lies and if it's xorg's fault at all, but it's definitely a change in xorg that triggered it so help in finding out what's going on would be greatly appreciated. This particular issue is a release blocker for Mageia 6 which is due soon, and might be one for Fedora too. Has also been reproduced in OpenSUSE. I can reproduce it myself and would be glad to give any debug information or test patches.
I have done some debugging of this issue and found the following scenario as the cause of the freeze: An X_DRI2GetBuffersWithFormat request gets throttled leading to the affected client being put on the sleep queue: ProcDRI2GetBuffersWithFormat->DRI2ThrottleClient->dri2Sleep->ClientSleep Later an attempt to wake the client fails: dri2WakeClient->ClientWakeup->AttendClient->listen_to_client because listen_to_client returns FALSE (GrabInProgress != 0) resulting in mark_client_ready never being called. Consequently X_DRI2GetBuffersWithFormat never gets retried and the client (Plasma panel in this case) hangs forever waiting for the reply. It would appear that there is a problem with the handling of GrabInProgress.
Promising analysis, Arne, thanks. FWIW, the problem was bisected to commit f993091e7db8 ("os: Switch server to poll(2) [v3]") in the downstream report https://bugs.debian.org/846779 .
listen_to_client returns FALSE in this case because some other client has grabbed the X server. We should stick this client in the saved_ready_clients list in this case, but we don't have any function that does that available. Patch coming in a moment.
Created attachment 128844 [details] [review] Queue attended client to saved_ready_clients if server grab blocks execution
(In reply to Keith Packard from comment #4) > Created attachment 128844 [details] [review] [review] > Queue attended client to saved_ready_clients if server grab blocks execution Thanks, I can no longer reproduce the freeze with this patch applied
Thanks for the report and testing, fixed in Git master and the 1.19.1 release: commit 785053d033e73d2deb0ded4b97eabfd881991978 Author: Keith Packard <keithp@keithp.com> Date: Mon Jan 9 18:10:21 2017 -0800 AttendClient of grab-pervious client must queue to saved_ready_clients [v2]
*** Bug 99433 has been marked as a duplicate of this bug. ***
*** Bug 99544 has been marked as a duplicate of this bug. ***
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.