© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
0e1f616
(Get the code!)
Unfortunately, I think this was never resolved. On upgrading karmic to lucid, the problem re-emerged, even though I was using the Option "DRI" "false" workaround.
I've been suffering lockups/crashes at about the same frequency, every 2-3 hours say, for several months (except when I use Windows, which is very tempting - there's a additional and probably separate problem that lucid never resumes successfully from hibernate or suspend.)
Again, the lockups are most common when scrolling in Firefox or switching between windows (as if it's a DMA/timing thing?). Again, there's often a corruption of the scroll bar visible either side of the slider, and the bottom 10% of the window hasn't scrolled. However, what happens next differs from the problem as in hardy-jaunty with DRI true. At approximately equal frequency it may be one of:
a) The cursor is still moving but the screen not updating (eg I have system monitor in the top panel and it stops). CPU usage is not particularly high. The only thing I can do in Gnome is click on the buttons on the taskbar to minimise applications, and Gnome will redraw the desktop background correctly. I can use Ctrl+Alt+F1 to switch to a text console and reboot cleanly. I've tried taking a screenshot of this state, but it has been saved as a distorted PNG.
b) There is a complete freeze: the corruption in the Firefox window may be visible, but the cursor won't move. Even Alt+SysRq+E keys won't work and I have to manually power-cycle.
c) As b, but the screen blanks after a fraction of a second, and remains blank. I know in this situation Alt+SysRq won't do anything.
With a different Xorg configuration (I may have changed AccelMethod, plus there have been some xorg driver upgrades) I've also seen X/gdm crash and restart after a):
(II) Sleep Button: Close
(II) UnloadModule: "evdev"
(II) Power Button: Close
(II) UnloadModule: "evdev"
ddxSigGiveUp: Closing log
I got a backtrace from a) but never uploaded it, as it wasn't very revealing:
#0 0x00daa422 in __kernel_vsyscall ()
#1 0x0040b93d in ___newselect_
#2 0x080a3f77 in WaitForSomething (pClientsReady=
#3 0x080721b0 in Dispatch () at ../../dix/
#4 0x08066d7a in main (argc=8, argv=0xbfc3a6d4, envp=0xbfc3a6f8) at ../../dix/