Comment 78 for bug 107115

Might as well add to the chatter here: Hardy/8.04; fglrx 8.47.3 on an AMD 690G-based system:

01:05.0 VGA compatible controller: ATI Technologies Inc RS690 [Radeon X1200 Series] (prog-if 00 [VGA controller])
        Subsystem: Foxconn International, Inc. Unknown device 0c8d
        Flags: bus master, fast devsel, latency 64, IRQ 18
        Memory at f0000000 (64-bit, prefetchable) [size=128M]
        Memory at feaf0000 (64-bit, non-prefetchable) [size=64K]
        I/O ports at d000 [size=256]
        Memory at fe900000 (32-bit, non-prefetchable) [size=1M]
        Capabilities: <access denied>

...switching users and then attempting to "log out" of the new session results in a black screen, frozen keyboard, and the Xorg process eating ~100% CPU. Turned off desktop effects for both accounts with the same result.

Killing Xorg remotely thankfully restarts it and renders the system usable again. At that point, switching consoles with the keyboard reveals no display corruption either.

The following snippets may be helpful. I'm not sure of the timing of the gdm error, that may be when I killall -9'd Xorg remotely.

auth.log:
Aug 9 21:47:38 badger gdm[8859]: pam_unix(gdm:session): session closed for user XXXXXX

syslog:
Aug 9 21:47:39 badger kernel: [496062.682675] [fglrx] interrupt source 10000000 successfully disabled!
Aug 9 21:47:39 badger kernel: [496062.682682] [fglrx] enable ID = 0x00000001
Aug 9 21:47:39 badger kernel: [496062.682685] [fglrx] Receive disable interrupt message with irqEnableMask: 10000000; dwIRQEnableId: 00000001
Aug 9 21:47:39 badger kernel: [496062.704524] [fglrx:firegl_lock_free] *ERROR* lock was not held by 37! (*lock=0x80000001)
Aug 9 21:47:39 badger kernel: [496062.704537] [fglrx:firegl_unlock] *ERROR* firegl_lock_free failed!
Aug 9 21:47:39 badger kernel: [496062.988780] [fglrx:firegl_lock_free] *ERROR* lock was not held by 1! (*lock=0x00000000)
Aug 9 21:47:39 badger kernel: [496062.988794] [fglrx:firegl_unlock] *ERROR* firegl_lock_free failed!
Aug 9 21:50:27 badger gdm[27731]: WARNING: gdm_slave_xioerror_handler: Fatal X error - Restarting :0

For users looking to recover without a complete reboot, you will probably need to run your sshd at a higher priority to be able to ssh in when a process like Xorg is hogging 100% CPU. To achieve this:
1. in /etc/init.d/ssh, add a --nicelevel ${SSHD_NICELEVEL:-0} option to the call to start-stop-daemon in the start case.
     (Or skip the :- and initialize SSHD_NICELEVEL=0 at the top of the file.)
2. in /etc/default/ssh, define SSHD_NICELEVEL=-12.

This will keep you from waiting hours for the cryptographic negotiation to find CPU time. Remember that all ssh login shells will inherit the meanness (so nice your processes if you're sharing the machine).