Ubuntu

What does a hard freeze with blinking caps lock and scroll lock leds mean?

Asked by Nazo

Every now and then, seemingly completely at random, Ubuntu completely freezes on me. I don't know if it is hardware or what because it's too random (and last I checked my hardware passed stability tests) and because when it freezes it will not respond to mouse or keypresses, so I can't even as much as get to a console... Since I'm on a laptop with no hidden resseses for tiny reset buttons that I could locate so far, the only solution for me has been to pull the power cord (no battery.) It won't even respond if I hold the power button for > 4 seconds... Twice now these hard freezes have become bad enough to force me to reinstall as the filesystem became too currupted to boot again. I've since resorted to keeping almost nightly images of the partiton so I won't have to reinstall anymore.

I think the problem has been specific to 7.04 final for me. I've tried so many things that I admit that I'm loosing track, but I think the beta I tried before I realized that the "stable" version is out did not have any problems other than software for me.

Every single time it does this, I can see two LEDs blinking -- the caps lock and scroll lock. I can only assume that this must be intentional and maybe has some meaning that might help lead me to figuring out just what is causing this. Does it mean anything other than "system has crashed"?

Question information

Language:
English Edit question
Status:
Solved
For:
Ubuntu Edit question
Assignee:
No assignee Edit question
Solved by:
Jörn Dreyer
Solved:
Last query:
Last reply:
Revision history for this message
Best Jörn Dreyer (j.dreyer) said : 		#1

As stated in linux/drivers/input/serio/i8042.c of the kernel source the blinking leds simply indicate a kernel panic:
/*
 * i8042_panic_blink() will flash the keyboard LEDs and is called when
 * kernel panics. Flashing LEDs is useful for users running X who may
 * not see the console and will help distingushing panics from "real"
 * lockups.
 *
 * Note that DELAY has a limit of 10ms so we will not get stuck here
 * waiting for KBC to free up even if KBD interrupt is off
 */
That is all I found out (starting from google -> http://kerneltrap.org/node/355 -> grep the source for panic_blink). Comments welcome.

Revision history for this message
Nazo (nazosan) said : 		#2

Thanks Jörn Dreyer, that solved my question.

Revision history for this message
Nazo (nazosan) said : 		#3

Hmm, thanks. So the LEDs don't really mean anything useful, but it does at least tell me that in every single case it is a kernel panic and not a hardware lockup (though I suspected as much since I can't see how it would have flashing LEDs were the hardware to freeze unless it were some proprietary BIOS implemented response to something.)

I guess then I need to go about solving this another way. Since I've managed to get it installed and it's not running live, are there any persistant logs that might have some note of what at least happened just before the kernel panicked? Since I posted this question originally, I have since narrowed the problem down a bit and now believe it to be sound related -- I first noticed when it seemed to freeze far more frequently while I was listening to an online radio station. I plugged in an external soundcard and tried to switch everything I could find to defaulting to using it instead of the onboard SPU and since then the lockups have gone down from a frequency of approximately two or three times a day to approximately one every one or two days. The problem was a bit too random to be sure, but certainly it's suspicious. Of course it still occurs, so I haven't completely narrowed it yet (then again, it is true that I can't figure out how to 100% disable the onboard SPU, so it may well be that something else is using it still -- or perhaps just having the driver running is enough, I'm just not sure with so little information to go on.) Perhaps there might be some log that would more directly answer this question?