kernel panic

[jarod-ajLrJawYSntWk0Htik3J/w at public.gmane.org (Jarod Wilson)]

On Feb 15, 2011, at 1:22 AM, Tom Metro wrote:

> My laptop is crashing pretty regularly with a kernel panic after 24 to
> 48 hours of uptime. Rolling back to the last two kernel versions hasn't
> helped.
> 
> My attempts to leave the computer idle showing a virtual console also
> hasn't been too successful at revealing the cause (see prior post on
> difficulty in disabling the screen blanking feature). It did catch one,
> but most of the information had scrolled off the screen. Lots of
> "do_invalid_op" messages.
> 
> Another time I was able to catch a fragment of the log showing in a GUI
> screenlet that shows dmesg output, and that one showed "iwlagn: can't
> stop RX DMA", implicating the Intel WiFi hardware or driver. That led me
> to some suggestions to try turning up the power saving level on the
> Intel card on the theory that it is overheating. I tried that. I
> monitored the temperature via
> /sys/bus/pci/drivers/iwlagn/0000:05:00.0/temperature
> before and after the power setting change, and it always hovered around
> 67, whatever that means (67 C?). And a day later the system crashed again.
> 
> The logs saved to disk don't show anything relevant, which I guess is
> usual for a kernel panic. My recollection is that the only way to
> capture the output of a kernel panic is to capture the output of the
> serial console. Is that still true?

No. There have been other ways for quite some time. The most
common upstream-supported way is kdump, which collects an entire
vmcore (or a filtered/trimmed one) that can be analyzed. There's
also kmsg_dump now, which can output the kernel message buffer
(including the panic trace) to RAM, flash, or other target, when
appropriately configured. Its fairly new upstream though, so it
may or may not be in the kernel you're running.


-- 
Jarod Wilson
jarod-ajLrJawYSntWk0Htik3J/w at public.gmane.org