If hyperball, from the Fedora package xscreensaver-4.18-4 is left alone running for a few hours X locks up. The screen and keyboard is locked, but I still could log in on a serial console. I then noticed that X was hogging the CPU. Below is a stacktrace of the hyperball process. (gdb) bt #0 0xb7f487a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0xb7d46a1d in ___newselect_nocancel () from /lib/tls/libc.so.6 #2 0xb7e2cfea in _XError () from /usr/X11R6/lib/libX11.so.6 #3 0xb7e2d434 in _XError () from /usr/X11R6/lib/libX11.so.6 #4 0xb7e0eb86 in XDrawLine () from /usr/X11R6/lib/libX11.so.6 #5 0x0804a624 in screenhack (d=0x98ff860, w=10485770) at hyperball.c:503 #6 0x0804b299 in main (argc=1, argv=0xbff5f514) at screenhack.c:678 #7 0xb7c9be23 in __libc_start_main () from /lib/tls/libc.so.6 #8 0x080494b1 in _start () I'm using the radeon driver
I noticed a very similar lockup, also fully reproducible, with the "starwars" screensaver from xscreensaver. This time however, the starwars prcess had exit (it wasn't there anyway), but the screen was none the less locked, showing (presumably) the last image the screensaver rendered. A backtrace of the xscreensaver process yields: #0 0x00ebd402 in __kernel_vsyscall () #1 0x004dca1d in ___newselect_nocancel () from /lib/tls/libc.so.6 #2 0x00d76f92 in _XEnq () from /usr/X11R6/lib/libX11.so.6 #3 0x00d7736e in _XRead () from /usr/X11R6/lib/libX11.so.6 #4 0x00d784cb in _XReply () from /usr/X11R6/lib/libX11.so.6 #5 0x00d60702 in XGetWindowProperty () from /usr/X11R6/lib/libX11.so.6 #6 0x08063bfc in get_overlay_visual (screen=0x988e848, transparent_pixel_ret=0xbfc3f37c) at overlay.c:91 #7 0x0805a527 in stderr_popup_timer_fn (closure=0xbfc3f7a0, id=0xbfc3f4d4) at stderr.c:214 #8 0x00b1f573 in _XtRemoveAllInputs () from /usr/X11R6/lib/libXt.so.6 #9 0x00b1f7c4 in XtAppNextEvent () from /usr/X11R6/lib/libXt.so.6 #10 0x08054ae0 in sleep_until_idle (si=0xbfc3f7a0, until_idle_p=0) at timers.c:633 #11 0x0804e4ce in main_loop (si=0xbfc3f7a0) at xscreensaver.c:1311 #12 0x0804f52f in main (argc=1, argv=0xbfc3f9d4) at xscreensaver.c:1472 #13 0x00431e23 in __libc_start_main () from /lib/tls/libc.so.6 #14 0x0804c0f1 in _start () And once again, X was using all cpu it could get hold off and wouldn't die even with a SIGKILL
reporter: ping. if you could confirm this is still an issue with one of the 6.8.99 snapshots, then you can obtain a backtrace from the server itself to see where it's stalling. see http://xorg.freedesktop.org/wiki/DebuggingTheXserver for details.
Sorry for the long delay. Yes, I still saw the problem with 6.8.99, though very rarely. Unfortunately both times it happened I didn't have any serial console available so I wasn't able to get a back trace and now I no longer have the hardware available. Maybe, if someone else is seing these issues, I can assist with debug-built packages...
I'm seeing the same bug. I'm running X from breezy (6.8.2). I tried a few times last night to get a backtrace from gdb but it caused my machine to hand and it had to to switched of at the mains. I'll try again latter and post the gdb error here if I can't work it out.
I believe I am seeing similar behavior on Debian Sid with Xorg 6.9.0 and a Radeon 9250 with 256 MB (RV-280 chipset) and the OpenGL XScreensaver package. If I run one OpenGL application (glxgears even) and then another (typically a screensaver) I get a complete screen lockup. I can reproduce this even with the xscreensaver-demo program by selecting an OpenGL saver which will run fine so long as no other OpenGL app has run before it. The screen will lock up hard once the second OpenGL saver runs, even in the preview window. The mouse may still be responsive and I've been able to log into the machine over the network, but cannot kill the xserver and can only shutdown with a hard reset. I would be happy to help by supplying any needed info. For now my workaround is removal of the OpenGL XScreensaver package. :( The reason I am just reporting this now as I bought this graphics card last week based on the success I had with 3D on a Radeon 7500 on a Thinkpad T42.
Any changes using a modern version of xorg?
No changes for me. I am running Debian Sid which I just updated this morning. I am currently running Xorg 7.0.18, libgl1-mesa-dri 6.4.1, and xscreensaver-gl 4.24 running on a RADEON 9250. On the load of a second OpenGL screensaver the screensaver will lock in a few seconds and the system will become unresponsive except for the mouse cursor (the first OpenGL saver will run fine). A hard reset is the only way to recover. glxinfo currently reports that DRI is enabled. I think the problem is chipset specific since I have an IBM Thinkpad T23 with a Savage 3D chipset and I don't experience the problems on it that I do on this desktop. DRI is also enabled on the T23. I am open to suggestions on how I can help debug this. The 3D performance looks to be quite good, but it is unusable for me at the moment.
(In reply to comment #7) > No changes for me. I am running Debian Sid which I just updated this morning. > I am currently running Xorg 7.0.18, libgl1-mesa-dri 6.4.1, and xscreensaver-gl > 4.24 running on a RADEON 9250. It would be interesting if you could try Mesa and/or DRM CVS. > On the load of a second OpenGL screensaver the screensaver will lock in a few > seconds and the system will become unresponsive except for the mouse cursor > (the first OpenGL saver will run fine). Sounds like a different issue than the one originally reported here, as that only talks about a single screensaver (that doesn't even use OpenGL). Are you running an SMP kernel? Anyway, please add your information to a more appropriate bug (e.g. bug 1280) or file a new one.
> Sounds like a different issue than the one originally reported here, as that > only talks about a single screensaver (that doesn't even use OpenGL). Are you > running an SMP kernel? Anyway, please add your information to a more appropriate > bug (e.g. bug 1280) or file a new one. Are you sure? The original reports that "hyperball" and "starwars" caused lock ups. For me it was a good number of different hacks but starwars was the one I used most often. I think all of them use OpenGL. As for the second screensaver I think he means the second time he runs the screensaver not that he is running two at the same time. I'd love to do some testing of this but the machine that has the card is currently out of action.
(In reply to comment #9) > > The original reports that "hyperball" and "starwars" caused lock ups. The original report only mentions hyperball. The second comment should have been (to) a different bug in the first place. :) > I think all of them use OpenGL. hyperball doesn't, starwars does. So it's unlikely these are both the same issue. > As for the second screensaver I think he means the second time he runs the > screensaver not that he is running two at the same time. You may be right, this should be clarified in the other bug.
I am not running SMP. What I meant by a second screensaver is in sequence, not parallel. I have noticed that it's not just a screensaver, but those are the only OpenGL apps that I have besides glxgears. I have found that if I've run glxgears, stopped it, then run an OpenGL screensaver from the xscreensaver GUI in preview mode and the lockup will occur. I will check out bug 1280 and see what I can add.
According to bug 5449, a similar issue has been fixed in current versions of the various components. Please verify for this problem as well.
Since I don't have the radeon card available anymore I can't verify the fix. I'll close the bug however but if someone else still can see the problem with recent a recent release please do reopen it. *** This bug has been marked as a duplicate of 5449 ***
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.