----- "Sharyathi Nagesh" <sharyath(a)in.ibm.com&gt; wrote: That one looks better... I understand that with the topmost pt_regs you can then start the backtrace OK. That's not what I'm referring to. What I'm talking about is bumping into another exception frame while unwinding from the topmost pt_regs. Or what happens when the crash occurs while operating on an alternate kernel stack. Just take a simple example -- what happens when you actually enter "alt-sysrq-c" on an x86_64, generating a keyboard interrupt and therefore a transition to the per-cpu IRQ stack? By the time crash-kexec() is called, you're already operating on the IRQ stack. Your code will work its way back to the top of the per-cpu IRQ stack, but then what does it do? Or suppose the task takes a page fault, lays down an exception frame, and then later BUG()'s out while attempting the handle the fault. Your code will start from the most-recently occurring exception frame, but will bump into the page fault exception during the unwind operation. Does you code properly recognize the new exception frame (and the passage through assembly-language code when that happens)? All I'm saying is basing your test results simply on instances where panic() is called or "echo c ..." was entered is the most trivial type of kernel crash -- because there's no kernel exception frame laid down until crash_kexec() gets called. That's a fairly rare occurance w/respect to typical kernel crashes. Dave