Re: How to go about debuging a system lockup?

[Lennart Sorensen <lsorense@csclub.uwaterloo.ca>]

On Thu, Nov 16, 2006 at 09:49:06PM +0100, Jesper Juhl wrote:
> Well, I have a few ideas that are hopefully useul.
> 
> - If you have not done so already, then go in to the "Kernel Hacking"
> section of the kernel configuration and enable some (all?) of the
> debug options and see if that produces anything that will help you
> track down the problem.

I enabled the things that sounded useful.  I will try enabling the rest.

> - You could enable 'magic sysrq' and see if you can manage to get a
> backtrace with it when it hangs (see Documentation/sysrq.txt) (ohh and
> raise the console log level so you get all messages, including debug
> ones).

Yeah I did that.  No response to sysrq (at least not on the serial
console.  Maybe I should get a keyboard connector put on.)  Normally we
run without VGA/keyboard/etc, and just serial console.  Of course the
serial console requires working interrupts.  Not sure about the keyboard
driver.

> - You could also try kdb (http://oss.sgi.com/projects/kdb/) or kgdb
> (http://kgdb.linsyssoft.com/). That might help you pinpoint the
> failure.

Can I run that remotely somehow?  I never really looked at kdb or kgdb
before.

> See also : http://kerneltrap.org/node/112
> 
> - If you have (or can identify) an older, working, kernel version and
> you are confident that you can reproduce the problem reliably, then
> doing a git bisection search starting with your newest "known good"
> and oldest "known bad" kernel versions, should help you pinpoint the
> commit causing the breakage.

I don't know of a good version yet.  I so far don't know if there ever
was one.  This could even be a bug in the PCI hardware, or the way the
BIOS on this system on a board configured the PCI controller.  Maybe I
should go back and try a 2.4 kernel.

> Hope some of that helps :)

Well hopefully.

--
Len Sorensen