Ubuntu
xorg package

Graphics driver timeout in Linux

Asked by lpandz

In Windows, when the graphics (driver) crashes, there is a mechanism that allows for the graphics driver to recover and not take the OS down with it. I've read that there is a timer or a timeout for the graphics 'kernel' so that a graphics-crash does not result in having to reboot the machine to recover. I've seen this in action and the Windows OS stays up and running while the graphics gracefully restart and recover from a graphics crash. My question is: what is the Linux counterpart of that Windows mechanism? I've seen my Ubuntu_12.10 (with the fglrx-updates driver for the HD7770) lock up (the screen/UI) from time to time when the machine is crunching work-units using the GPU (via BOINC_v7.0.44) and I do not see Ubuntu_12.10 able to recover from the lock up, leaving me with no choice but to pull the plug. In doing the same thing under Windows7, the machine is spared from having to do that dirty re-start and I simply resume the interrupted work-units after the graphics (driver) recovers. I can safely attribute the lock up to a crashed graphics (driver) because the machine never have the lock-ups when not crunching work-units that use the GPU. Also, are instances of that graphics crash get to be handled by apport for crash reporting? Thanks.

Question information

Language:
English Edit question
Status:
Solved
For:
Ubuntu xorg Edit question
Assignee:
No assignee Edit question
Solved by:
lpandz
Solved:
Last query:
Last reply:
Revision history for this message
actionparsnip (andrew-woodhead666) said : 		#1

Press CTRL + ALT + F1 and run:

killall -u $USER

You can then log in again

Revision history for this message
lpandz (andzgod) said : 		#2

When the lock-up strikes, and there is no telling when it may strike, no inputs respond: no mouse, no keyboard. Everything frozen as if I'm starring at a painting that just happen to land on my screen. Only one choice is available: pull the plug which is painful to all: software and hardware.

Revision history for this message
lpandz (andzgod) said : 		#3

Further to posting#2:

Unless the exception to the freeze is CTRL + ALT + F1 including the subsequent/resulting screen -- and this I have to try. Please note though, that I've tried CTRL + ALT + DEL and that won't work.

Revision history for this message
Manfred Hampl (m-hampl) said : 		#4

If ctrl-alt-del and ctrl-alt-f1 do not work, still the SysRq-REISUB key sequence might be able to force a graceful shutdown, see http://en.wikipedia.org/wiki/Magic_SysRq_key#Uses

Is there anything useful in the syslogs when such freeze occurs?

Revision history for this message
lpandz (andzgod) said : 		#5

response to posting#4:

Hello Manfred Hampl (m-hampl) and thanks for the endorsed link. My machine ran into the described freeze and I next tried CTRL-ALT-DEL and CTRL-ALT-F1; and I hereby confirm that those don't work. I'll now explore the endorsed link (about SysRq-REISUB key sequence) and then I'll do a posting as a feedback about how that goes. Thanks.

Revision history for this message
lpandz (andzgod) said : 		#6

Further to posting#5

OK, the freeze struck and I did the SysReq-RIESUB key sequence in a way described at the endorsed link, and it worked to have the machine reboot, and I no longer have to pull the plug -- and to that extent my described issue is solved.

As for the matter of having in Linux/Ubuntu the capability to remain up and running despite a GPU crash/hang, I'll be experimenting with using dual graphics (one for Quantal desktop/UI and one for GPU-computing) and see where that goes as a possible way around the matter (Question #220659 ), and/or see how things develop at the AMD-fglrx driver front (Question #220494).

Thanks to actionparsnip, and Manfred Hampl for their time and assistance.