Created attachment 533467 [details] busy looping xserver Description of problem: After recent fix of my reported bug 737031 I'm now experiencing busy looping Xserver. Unfortunately I do not have any exact way how to trigger this, but it already happened to me twice. I think the fix for bug 737031 introduced some regression. I'm adding backtrace from the moment the Xorg busyloops - I should note, that in this moment the server cannot be killed in other way then '-9' (thus in fact I'm back at the same moment as prior fix for bug 737031 as console is again unusable) Version-Release number of selected component (if applicable): xorg-x11-server-Xorg-1.11.99.1-1.20111109.fc17.x86_64 How reproducible: Not yet know an exact steps. Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
It might be worth to attach also this trace from Xorg.0.log: --- [mi] EQ overflowing. Additional events will be discarded until existing events are processed. Backtrace: 0: /usr/bin/X (xorg_backtrace+0x2f) [0x4635ff] 1: /usr/bin/X (mieqEnqueue+0x243) [0x555d13] 2: /usr/bin/X (0x400000+0x47183) [0x447183] 3: /usr/bin/X (xf86PostButtonEvent+0xf7) [0x48fd47] 4: /usr/lib64/xorg/modules/input/synaptics_drv.so (0x7fb82ae34000+0x221d) [0x7fb82ae3621d] 5: /usr/lib64/xorg/modules/input/synaptics_drv.so (0x7fb82ae34000+0x33cd) [0x7fb82ae373cd] 6: /usr/lib64/xorg/modules/input/synaptics_drv.so (0x7fb82ae34000+0x4df3) [0x7fb82ae38df3] 7: /usr/bin/X (0x400000+0x7f6c8) [0x47f6c8] 8: /usr/bin/X (0x400000+0xa4b6b) [0x4a4b6b] 9: /lib64/libpthread.so.0 (0x7fb82e1e0000+0xf500) [0x7fb82e1ef500] 10: /lib64/libc.so.6 (writev+0x1b) [0x7fb82cf3115b] 11: /usr/bin/X (0x400000+0x6ef5c) [0x46ef5c] 12: /usr/bin/X (0x400000+0x666f4) [0x4666f4] 13: /usr/bin/X (FlushAllOutput+0x17c) [0x466f7c] 14: /usr/bin/X (0x400000+0x33b1a) [0x433b1a] 15: /usr/bin/X (0x400000+0x22fc5) [0x422fc5] 16: /lib64/libc.so.6 (__libc_start_main+0xed) [0x7fb82ce6a73d] 17: /usr/bin/X (0x400000+0x232b1) [0x4232b1] [mi] These backtraces from mieqEnqueue may point to a culprit higher up the stack. [mi] mieq is *NOT* the cause. It is a victim. [mi] EQ overflow continuing. 100 events have been dropped. ...
It looks like the trace in comment 1 is just something which happened already many times in past - i.e. bug Bug 465884.
I've also create separate thread on lkml with kernel back trace which seems to be related to this issue as well. https://lkml.org/lkml/2011/11/21/151
Blocked on writev? How odd. What is that file descriptor pointing to?
Since I'm now using kernel 3.2/3.3 - I've not experienced such problem for quite some time - so it might have been already fixed - I guess if there will not be a similar problem within another month it might be closed as fixed with newer a kernel.
Closing per comment #5, not seen any other reports like this.