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.)