[lkml]   [2006]   [May]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 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:
> 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).


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2006-06-01 01:32    [W:0.140 / U:1.312 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site