[Eug-lug] Random freezes

Neil Parker nparker at lyl.llx.com
Mon Jan 8 23:05:42 PST 2007


Martin Kelly wrote,
>Nothing in /var/log/messages or dmesg... I don't think it's the kernel, 
>thankfully.

It might also be worthwhile to look in /var/log/Xorg.0.log, and possibly
/var/log/syslog.

>Yeah, I wasn't able to do Ctrl+Alt+F6 to get to a virtual tty. Is X able 
>to free that up?
>
>I just switched to amarok and I'm not getting crashes anymore. I'm 
>thinking it might've been XMMS's fault. I'd heard it was buggy, but 
>crashing a whole system? Also, I've been using XMMS for almost a year 
>and never had the problem... weird.

Just because you can't switch virtual TTYs doesn't mean the whole system
is locked up...it might be just your X server that's locked up.  X
disables normal keystroke processing and does all the raw scancode
processing (including handling the VT-switching keys) itself, so if X
locks up, you're stuck with no way to switch to another virtual terminal.

I've had X lock up on me a few times.  In my case it was usually due to
video hardware flakiness (helpful hint:  never put an NVidia card into
a motherboard with an ALi 1541 chipset), but sometimes applications can
trigger bugs that cause X to freeze or crash.

When this happens, it may be possible to recover if you've left yourself
some other way to log in.  If your computer is on a network, you can run
sshd or telnetd, and then when trouble strikes you can ssh or telnet in
from some other computer on the network.  On my system I have a cable
running from my serial port to another computer, where I can use kermit to
log in.

Once you're in, the easiest way to clear up the problem may be to do a
clean reboot ("sudo shutdown -r now").  If you're feeling cleverer, a
frozen X server might be fixable by "kill -9"ing it.

               - Neil Parker


More information about the EUGLUG mailing list