Re: 2.6.17-rc5-mm1

[Martin Bligh <mbligh@google.com>]

> Martin, is the box still somewhat operational after such a crash? If yes 
> then we could use my crash-tracer to see the kernel function call 
> history leading up to the crash:
>
>   http://redhat.com/~mingo/lockdep-patches/latency-tracing-lockdep.patch
>
> just apply the patch, accept the offered Kconfig defaults and it will be 
> configured to do the trace-crashes thing. Reproduce the crash and save 
> /proc/latency_trace - it contains the execution history leading up to 
> the crash. (on the CPU that crashes) Should work on i386 and x86_64.
>
> the trace is saved upon the first crash or lockdep assert that occurs on 
> the box. (but you'll have lockdep disabled, so it's the crash that 
> matters)
>
> if the box dies after a crash then there's a possibility to print the 
> execution history to the serial console - but that takes around 10-15 
> minutes even on 115200 baud. If you want/need to do this then edit 
> kernel/latency.c and change "trace_print_at_crash = 0" to 
> "trace_print_at_crash = 1".
>
> (btw., the tracer has another neat feature as well: if a kernel crashes 
> or triple faults (and reboots) early during bootup, then the tracer can 
> be configured to print all function calls to the serial console, via 
> early_printk() - right when the function calls happen. I debugged 
> numerous nasty boot-time bugs via this. To set it, change 
> "print_functions = 0" to "print_functions = 1" in kernel/latency.c.)

Looks cool, but we'll have to beg the IBM guys to run it, I don't have
access to that box anymore. Dumping to serial console would be cool,
even if it's slow (the test boxes all have that logged).

M.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/