Bug 32393 - X-server locks itself up refusing any more user input
Summary: X-server locks itself up refusing any more user input
Status: RESOLVED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: Server/General (show other bugs)
Version: 7.5 (2009.10)
Hardware: x86-64 (AMD64) Linux (All)
: high blocker
Assignee: Xorg Project Team
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-12-14 08:55 UTC by Elmar Stellnberger
Modified: 2011-10-11 07:35 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:


Attachments
just one of all those crash logs ... (131.33 KB, text/plain)
2010-12-14 08:59 UTC, Elmar Stellnberger
no flags Details
another Xorg.log (131.68 KB, text/plain)
2010-12-14 09:03 UTC, Elmar Stellnberger
no flags Details
versions of xorg-packages (2.90 KB, text/plain)
2010-12-14 09:05 UTC, Elmar Stellnberger
no flags Details
... and finally last but not least my xorg.conf (if it should be of any value here) (9.63 KB, text/plain)
2010-12-14 09:06 UTC, Elmar Stellnberger
no flags Details
Xorg.0.log of event queue overflow #2 DRI=off + kernelmodesetting (126.58 KB, text/x-log)
2011-01-05 14:09 UTC, Elmar Stellnberger
no flags Details
Xorg.0.log of event queue hang #3 (140.90 KB, text/plain)
2011-01-10 05:26 UTC, Elmar Stellnberger
no flags Details
total event queue overflow #4 (119.87 KB, text/x-log)
2011-01-23 12:57 UTC, Elmar Stellnberger
no flags Details
event queue overflow directly after startup #4 (109.87 KB, text/x-log)
2011-01-23 12:58 UTC, Elmar Stellnberger
no flags Details
event queue overflow #5 (136.02 KB, text/x-log)
2011-01-31 13:50 UTC, Elmar Stellnberger
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Elmar Stellnberger 2010-12-14 08:55:18 UTC
Just a while after starting the X-server sometimes at bootup othertimes some time later the input processing hangs itself unexpiably up: No more keyboard input is accepted, not even switching to another terminal. The mouse is moving delayed and in rather hulkingly coarse steps. Any mouse button presses will be intransigently and fully ignored.
  Working with vim and elinks in text console mode the only thing that can bring me out of that breamfish-subsistence is probably a proper downgrade of X to the openSUSE`s standard update repo (where 3d accelaration crashes). The remarkable thing about it is that everything goes on as normal - the background music continues to play and the mouse continues to move. Yet there is no other escape than Alt-PrintScr-S/U/B which is in effect not much better than unplugging the power supply.
Comment 1 Elmar Stellnberger 2010-12-14 08:59:50 UTC
Created attachment 41108 [details]
just one of all those crash logs ...
Comment 2 Elmar Stellnberger 2010-12-14 09:03:15 UTC
Created attachment 41109 [details]
another Xorg.log
Comment 3 Elmar Stellnberger 2010-12-14 09:05:15 UTC
Created attachment 41110 [details]
versions of xorg-packages
Comment 4 Elmar Stellnberger 2010-12-14 09:06:18 UTC
Created attachment 41111 [details]
... and finally last but not least my xorg.conf (if it should be of any value here)
Comment 5 Peter Hutterer 2010-12-14 20:01:12 UTC
driver stuck, reassigning to radeon.

[   868.149] [mi] EQ overflowing. The server is probably stuck in an infinite loop.
Comment 6 Michel Dänzer 2010-12-15 03:28:29 UTC
AFAICT there are two problems:

* A GLX/DRI crash which looks like bug 28181 (which btw shouldn't happen with KMS)

* xorg_backtrace_gdb() forking and hanging. AFAIK this hasn't landed upstream yet, so it's an openSUSE issue => NOTOURBUG.
Comment 7 Elmar Stellnberger 2010-12-15 04:33:19 UTC
* A GLX/DRI crash which looks like bug 28181 (which btw shouldn't happen with
KMS)
-> KMS is uf. no option for me: It fully garbels my screen, though reported for long I am no more in hope for a resolution (no answer there)

* xorg_backtrace_gdb() forking and hanging. AFAIK this hasn't landed upstream
yet, so it's an openSUSE issue => NOTOURBUG.
-> How to report? Is it perhaps a gdb bug? I have not got any answer on my last 12 openSUSE bug reports. Perhaps you would have better luck!

* Why does it hang? Switching the vt needs to be kept working in some way even if it hangs. Why not have a rescue thread with a primitive but robust loop? Or do we need kernel mode vt-switching rather than the anyhow dispensable kernel mode setting?
Comment 8 Daniel Stone 2010-12-16 02:44:06 UTC
On Tue, Dec 14, 2010 at 08:01:13PM -0800, bugzilla-daemon@freedesktop.org wrote:
> driver stuck, reassigning to radeon.
> 
> [   868.149] [mi] EQ overflowing. The server is probably stuck in an infinite
> loop.

Actually, the backtrace shows it having caught a segfault in
__glXDRIDrawableDestroy -> dixLookupPrivate; it's only because of the
external-gdb patch that things begin to go wrong.  After the fork's been
made, signal delivery is not suppressed, so SIGALRM, SIGIO and friends
continue to be delivered.

At any rate, I'm fairly sure the original bug (segfault in
__glXDRIDrawableDestroy) is already fixed, and there are certainly other
bugs for it.
Comment 9 Elmar Stellnberger 2010-12-17 05:00:34 UTC
upstream report: https://bugzilla.novell.com/show_bug.cgi?id=660166
Comment 10 Matthias Hopf 2010-12-20 03:45:30 UTC
I doubt that the backtrace patch is the reason for the hang (because the script
obviously finished), but you never know.

Continuing debugging in Novell's bugzilla for now.
Comment 11 Stefan Dirsch 2010-12-27 13:44:38 UTC
https://bugzilla.novell.com/show_bug.cgi?id=660166#c5

Matthias Hopf  2010-12-27 16:56:53 UTC 

"As assumed this indicates not a hang in the backtrace generator, but rather a
LiveLock in DDC2Read and below.

I must admit though, I do not understand why the Xserver can get into this
codepath given that it already received a segfault. I guess we'll have to look
at the mi code about "EQ overflowing.".

Not a high priority, though, as the main culprit is the radeon driver in any
case."
Comment 12 Michel Dänzer 2010-12-28 00:15:19 UTC
(In reply to comment #11)
> Not a high priority, though, as the main culprit is the radeon driver in any
> case."

Rather the xserver GLX/DRI code.
Comment 13 Elmar Stellnberger 2010-12-29 04:43:37 UTC
You already know the cause; don`t you?
Most times this is yet the main part of the solution.
Unfortunately the problem in the DRI code has remained through the last updates and I can`t go on testing like this any further.
If that is not too much work I wanna ask you to approach a fix for nowadays.
Comment 14 Elmar Stellnberger 2010-12-29 04:46:57 UTC
I guess the DRI code will remain unstable for the next month or perhaps year because there is still a lot of work to do in means of a full 3D support if ever given.
Comment 15 Matthias Hopf 2010-12-29 05:33:33 UTC
(In reply to comment #12)
> (In reply to comment #11)
> > Not a high priority, though, as the main culprit is the radeon driver in any
> > case."
> 
> Rather the xserver GLX/DRI code.

I should have phrased "the main culprit is NOT the backtrace patch". :-)
Comment 16 Elmar Stellnberger 2010-12-30 09:04:56 UTC
Actually, both bugs need to be resolved (this one and the DRI bug 32744).
Comment 17 Elmar Stellnberger 2011-01-05 14:07:30 UTC
 Testing the newest available Xorg with kernel modesetting I just got another event queue overflow which resulted in a total hang bywhere not even the mouse was moving any more. Is it exactly the same problem as before?
 It has happened even without DRI (turned off) so this bug `s gonna need soon resolution nonetheminor.
Comment 18 Elmar Stellnberger 2011-01-05 14:09:09 UTC
Created attachment 41691 [details]
Xorg.0.log of event queue overflow #2 DRI=off + kernelmodesetting
Comment 19 Elmar Stellnberger 2011-01-10 05:26:53 UTC
Created attachment 41835 [details]
Xorg.0.log of event queue hang #3

 There are still such issues about the event queue although previous occasions known to trigger such crashangs seem having been improved. For the newest crashang see at Xorg.0.log of hang #3 (xorg-x11-server-7.6_1.9.3-104.2).
Comment 20 Elmar Stellnberger 2011-01-23 12:57:26 UTC
Created attachment 42348 [details]
total event queue overflow #4
Comment 21 Elmar Stellnberger 2011-01-23 12:58:15 UTC
Created attachment 42349 [details]
event queue overflow directly after startup #4
Comment 22 Elmar Stellnberger 2011-01-31 13:50:06 UTC
Created attachment 42780 [details]
event queue overflow #5

 The EventQueueOverflow-problem is here since quite a long time now. It appears under almost any kind of configuration (old/newest kernel, with or without kernel modesetting). It renders radeon`s DRI unusable since it constantly occurs a short while after booting into X.
Comment 23 Matthias Hopf 2011-02-15 02:34:13 UTC
About the Xserver backtrace patch:

It looks like the server potentially livelocks in fork() - though I'm completely baffled how this can happen (fork() is allowed in signal handlers, and doesn't allocate memory).

We're dropping the patch in SuSE for now.

The originating issue remains, though, thus not changing status.
Comment 24 benderamp 2011-02-16 13:30:56 UTC
It seems that I am suffering from this issue on opensuse 11.4 m6 with kernel/xorg update from factory. Reported the bug originally here: https://bugs.freedesktop.org/show_bug.cgi?id=33146 (it might be a duplicate of this one) and also on opensuse bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=666632

I am receiving complete hangs with enabled kms with extremely high probability during 20-30 minutes of work and also seems that have reliable a way to reproduce it with disabled kms (copy files to flash drive). Some log files are attached to the linked bugs, can provide more info if required.
Comment 25 Elmar Stellnberger 2011-02-17 14:40:28 UTC
Great! The problem has been resolved for the xorg-x11-server-7.6_1.9.3-122.1 (accompanied by xorg-x11-driver-video-7.6-180.1) as shipped by openSuSE.
There are no more event queue hangs under normal operation by radeon.
Event queue overflows as still generated by calling xrandr are non-fatal fromnowonwheres: they leave a backtrace in Xorg.0.log but that does not even disturb the operation of xrandr (Bug 31845).
Many Thanks!
Comment 26 benderamp 2011-02-18 07:27:00 UTC
I have updated from factory to the provided above versions, restarted with enabled KMS - no complete hangs so far (which really, really great already - thank's), but now relatively long freezes (for about 5-10 seconds) do happen from time to time (most likely under same conditions as system hanged before). The whole desktop freezes and stops repainting, but the mouse is moving with no lags as if everything is ok, after 5-10 seconds things continue to work (do not have to reboot). Xorg.log has the following lines after that (I did not have backtrace before):

[  1846.294] [mi] EQ overflowing. The server is probably stuck in an infinite loop.
[  1846.294] 
Backtrace:
[  1846.294] 0: /usr/bin/Xorg (xorg_backtrace+0x28) [0x491508]
[  1846.294] 1: /usr/bin/Xorg (mieqEnqueue+0x1f4) [0x490eb4]
[  1846.294] 2: /usr/bin/Xorg (xf86PostMotionEventP+0xc4) [0x47b7b4]
[  1846.294] 3: /usr/lib64/xorg/modules/input/evdev_drv.so (0x7f4bdbb6f000+0x4e05) [0x7f4bdbb73e05]
[  1846.294] 4: /usr/bin/Xorg (0x400000+0x73ad7) [0x473ad7]
[  1846.294] 5: /usr/bin/Xorg (0x400000+0x10a963) [0x50a963]
[  1846.294] 6: /lib64/libc.so.6 (0x7f4be1b6d000+0x32b50) [0x7f4be1b9fb50]
[  1846.294] 7: /lib64/libpthread.so.0 (pthread_cond_wait+0xcc) [0x7f4be174339c]
[  1846.294] 8: /usr/lib64/dri/swrast_dri.so (0x7f4bddc09000+0x1e9653) [0x7f4bdddf2653]
[  1846.294] 9: /lib64/libpthread.so.0 (0x7f4be1738000+0x6a4f) [0x7f4be173ea4f]
[  1846.294] 10: /lib64/libc.so.6 (clone+0x6d) [0x7f4be1c4052d]


I will try to use the system in this way for more time - hope will not receive complete hangs.
Comment 27 benderamp 2011-02-19 02:22:41 UTC
I have just received the freeze as described above (desktop does not repaint, keyboard does not work, but mouse moves just fine) which did not end after 10-15 seconds - had to reboot with alt+sysrq+b again.
Comment 28 Elmar Stellnberger 2011-02-22 07:08:56 UTC
Yes; this is actually what I have opened up an own report for lately: bug 3454
I have also posted some decoded backtraces for it there.
Comment 29 benderamp 2011-02-22 11:25:58 UTC
>Yes; this is actually what I have opened up an own report for lately: bug 3454

Did you really mean "bug 3454"? for me it points to the .orth file parsing issue fixed in 2006
Comment 30 Elmar Stellnberger 2011-02-22 13:48:45 UTC
pardon. No I meant Bug 34544.
Comment 31 benderamp 2011-03-22 06:33:20 UTC
I am still receiving this problem rather often. Just update xorg version to the latest from opensuse 11.4 (Name: xorg-x11-server; Version: 7.6_1.9.3) repository and received hang as usual.

Current hangs are like I had initially - complete desktop hang - mouse does not move, caps lock does not work, but alt+sysrq+b does reboot.

In 90% of cases I receive this hang on one and the same action - I have konqueror window opened with multiple tabs and http://www.indiedb.com/articles is one of them. The hang happens when I switch to the tab with this page - don't even have to press "reload" or something like that - just bring this page to top -> receive hang (or same thing if this page was on top, switched to another desktop, then back to the desktop with this page -> same hang). This will not happen from the 1st time - after reboot it opens fine, then I can mention some lags, then it can make the system look really loaded for 5-10 secs, but still does not hang, but the next time after that it would hang with 90% probability.
Comment 32 benderamp 2011-05-27 03:09:10 UTC
I have just updated kernel to 39 from opensuse factory (xorg is the same as it seems that it did not receive updates since then) and received the usual freeze of the whole desktop on indiedb.com opened in konqueror (rebooted with sysrq+b). Should I reopen this bug or create a new one?
Comment 33 Elmar Stellnberger 2011-05-27 04:33:27 UTC
 Let us reopen for resolving the backtrace-dumped-errors (bug 34544) did not ameliorate this issue. Excuses for not having attended it previously.
Comment 34 benderamp 2011-10-05 02:34:54 UTC
Hello, I have updated to kernel 3.0.4-2 if that makes sense

> rpm -qi xorg-x11-server
Name        : xorg-x11-server
Version     : 7.6_1.9.3
Release     : 158.5

xorg-x11-server 7.6_1.9.3 from opensuse factory (could not find any newer there) and still receive hangs every day.
Comment 35 Jeremy Huddleston Sequoia 2011-10-11 01:22:57 UTC
This bug has become unwieldy.

The originator reported that the original issue is resolved (comment #26).

bendercamp, please open a new bug report for your issue including your own logs.

Elmar, if you are experienceing a new issue, please open a new bug for that issue.  I am closing this bug.
Comment 36 benderamp 2011-10-11 07:35:36 UTC
>bendercamp, please open a new bug report for your issue including your own
logs.

I already have one - please, reopen or I can do it myself if that's ok:
https://bugs.freedesktop.org/show_bug.cgi?id=33146


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.