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.
Created attachment 41108 [details] just one of all those crash logs ...
Created attachment 41109 [details] another Xorg.log
Created attachment 41110 [details] versions of xorg-packages
Created attachment 41111 [details] ... and finally last but not least my xorg.conf (if it should be of any value here)
driver stuck, reassigning to radeon. [ 868.149] [mi] EQ overflowing. The server is probably stuck in an infinite loop.
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.
* 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?
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.
upstream report: https://bugzilla.novell.com/show_bug.cgi?id=660166
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.
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."
(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.
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.
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.
(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". :-)
Actually, both bugs need to be resolved (this one and the DRI bug 32744).
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.
Created attachment 41691 [details] Xorg.0.log of event queue overflow #2 DRI=off + kernelmodesetting
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).
Created attachment 42348 [details] total event queue overflow #4
Created attachment 42349 [details] event queue overflow directly after startup #4
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.
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.
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.
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!
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.
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.
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.
>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
pardon. No I meant Bug 34544.
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.
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?
Let us reopen for resolving the backtrace-dumped-errors (bug 34544) did not ameliorate this issue. Excuses for not having attended it previously.
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.
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.
>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.