Bugzilla – Bug 619034
X locks up, all input is blocked except mouse movement
Last modified: 2011-10-29 13:28:15 UTC
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.4) Gecko/20100611 SUSE/3.6.4-3.2 Firefox/3.6.4 I'm using an up-to-date install of 11.3 Factory on a Lenovo t510 laptop and at seemingly random times the X server will lock up and disallow all input. The mouse cursor still moves, but can't be clicked and keyboard input is ignored altogether. I get the error message from X: "EQ Overflowing" and the backtrace seems to imply the crash happened during an even in the synaptic driver. This makes the machine completely unusable due to the high potential for data loss since a hard reset is always necessary. I'll attach Xorg.0.log.old Thanks in advance Reproducible: Always Steps to Reproduce: 1. Use machine -- happens randomly after anywhere from 2 to 30+ minutes of use.
dup *** This bug has been marked as a duplicate of bug 597078 ***
I don't think this is a duplicate of bug 597078. The system is idle and the Xserver is not consuming the CPU. I can reproduce a problem like this without kde or gnome, or 3d effects. Start or login to X. Open two or more terminal windows. Move one of the windows. Lockup occurs. You can move the mouse but not affect focus. The window with focus does not accept keyboard input. xorg-x11-server-7.5_1.8.0-9.4.x86_64 I tried changing the output size with xrandr as noted in bug 597078, and it did not fix the problem. The only way to fix it is to restart the Xserver. I've reproduced this on two different computers with either the nouveau or the nvidia driver. Host 1: VGA compatible controller: nVidia Corporation NV41GL [Quadro FX 1400] (rev a2) Host 2: VGA compatible controller: nVidia Corporation G96 [Quadro FX 580] (rev a1)
I have a better test case. Move a window. Click in the window, no lockup. Move the window. Click in another window, lockup. Restarting the window manager seems to fix the problem. Sometimes I have to restart it a second time.
I have discovered that this bug is indeed not a duplicate. This is a Nouveau specific bug, already filed and discussed upstream, but with no fix in sight. Workarounds include passing "nomodeset" as a kernel parameter or disabling Nouveau and using the closed Nvidia driver.
Sorry, I made a typo above. The workaround is actually to pass nouveau.noaccel=1 as opposed to nomodeset. Enabling the closed driver also works.
I will test with the nvidia driver, but I thought this was independent of whether the driver was nouveau or nvidia.
(In reply to comment #4) > I have discovered that this bug is indeed not a duplicate. This is a Nouveau > specific bug, already filed and discussed upstream, but with no fix in sight. Could you please provide a link for that?
Here is the upstream bug report with workarounds and more details: http://bugs.freedesktop.org/show_bug.cgi?id=26980
I can reproduce my issue with the nvidia driver.
I did an strace of X in the hung condition, and this is what I see: select(256, [1 3 6 7 11 16 17 18 19 20 21], NULL, NULL, {595, 483000} and when I move the mouse: select(256, [1 3 6 7 11 16 17 18 19 20 21], NULL, NULL, {596, 105000}) = ? ERESTARTNOHAND (To be restarted) --- SIGIO (I/O possible) @ 0 (0) --- select(16, [12 13 14 15], NULL, NULL, {0, 0}) = 1 (in [15], left {0, 0}) read(15, "\350\316ZL\0\0\0\0005\345\4\0\0\0\0\0\2\0\0\0\1\0\0\0\350\316ZL\0\0\0\0"..., 384) = 72 rt_sigreturn(0xf79048) = -1 EINTR (Interrupted system call) setitimer(ITIMER_REAL, {it_interval={0, 20000}, it_value={0, 20000}}, NULL) = 0 setitimer(ITIMER_REAL, {it_interval={0, 0}, it_value={0, 0}}, NULL) = 0 select(256, [1 3 6 7 11 16 17 18 19 20 21], NULL, NULL, {596, 95000}) = ? ERESTARTNOHAND (To be restarted) --- SIGIO (I/O possible) @ 0 (0) --- select(16, [12 13 14 15], NULL, NULL, {0, 0}) = 1 (in [15], left {0, 0}) read(15, "\350\316ZL\0\0\0\0\363!\5\0\0\0\0\0\2\0\0\0\1\0\0\0\350\316ZL\0\0\0\0"..., 384) = 48 rt_sigreturn(0xf79048) = -1 EINTR (Interrupted system call) setitimer(ITIMER_REAL, {it_interval={0, 20000}, it_value={0, 20000}}, NULL) = 0 setitimer(ITIMER_REAL, {it_interval={0, 0}, it_value={0, 0}}, NULL) = 0 [... repeats]
In brief, limited testing, I cannot reproduce my issue with X Server 1.8.99.905 (1.9.0 RC 5).
Created attachment 382012 [details] locked up mouse event mask patch I found the fix for my issue. I think this fixes the issue reported here. I found the attached patch here: http://cgit.freedesktop.org/xorg/xserver/patch/?id=1884db430a5680e37e94726dff46686e2218d525 Subject: Revert "dix: use the event mask of the grab for TryClientEvents." Stefan let me know if you want me to open a new bug or use this one.
(In reply to comment #12) > Created an attachment (id=382012) [details] > locked up mouse event mask patch The patch is now applied to obs://X11:XOrg/xorg-x11-server and submitrequested for openSUSE:Factory (SR #45319).
Karl, does this xorg-x11-server update fix your issue?
(In reply to comment #14) > Karl, does this xorg-x11-server update fix your issue? --> http://download.opensuse.org/repositories/X11:/XOrg/openSUSE_11.3/
I haven't been able to reproduce the bug with the updated xorg. That said, I've only been able to test it with the Nouveau driver for a short while because I need graphics acceleration for my daily work.
Ok. Let's assume the issue is fixed (for factory). Otherwise please reopen.
The 19 Aug 2010 build of xorg-x11-server 7.5_1.8.0 10.3.1 did not list this bug in the changelog. When will fix this be published ?
It has been fixed for factory, not for 11.3.
When will the fix be officially published and released ?
(In reply to comment #20) > When will the fix be officially published and released ? ? I do not understand. There are no plans to fix it before openSUSE 11.4.
I've reproduced this with xorg-x11-server-7.5_1.8.0-10.3.2 running kde-4.4.4, killing kwin and restarting it recovered the mouse temporarily, for a few seconds.
(In reply to comment #22) > I've reproduced this with xorg-x11-server-7.5_1.8.0-10.3.2 running kde-4.4.4, > killing kwin and restarting it recovered the mouse temporarily, for a few > seconds. That should be xorg-x11-server-7.5_1.8.0_10.3.1
This issue just reproduced on me with xorg-x11-server-7.6_1.9.3-111.6
:-(
Rich, could you give it another try with openSUSE 11.4 final? Testing with a LiveCD should be sufficient. Thanks.
I upgraded to opensuse 11.4, I was going to anyway. I can't make it happen with an attached usb mouse. I can always make it happen with the trackpad. Also note, that I can make this happen when I use the trackpad, on the newer version as well.
Unfortunately we do not have the ressouces to address that issue still for openSUSE 11.4. Could you please test again with a current Milestone of openSUSE 12.1, whether the issue still exists and give me feedback about the result? Thanks.
Still waiting for a response for more than a month now. Please reopen once you can provide the requested feedback. Thanks.
I have updated to 12.1 RC1 and am running xorg-x11-server-7.6_1.10.4 I hope not to have it come back ... Note: I had it happen twice this week on opensuse 11.4.