Messages in this thread | | | Date | Wed, 31 May 2006 16:29:09 -0700 | From | Martin Bligh <> | Subject | Re: 2.6.17-rc5-mm1 |
| |
> 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/
| |