Hi Rachita, I'm looking at an alt-sysrq-c generated crash on an x86_64 kernel, and I am seeing something similar to what you are with respect to the transition from the interrupt stack back to the process stack. Here's a "bt -a", where cpu 0 shows that it received a shutdown NMI while in the idle loop, and the transition from the NMI exception stack back to the process stack was clean. But on the cpu which took the alt-sysrq-c keyboard interrupt, the transition from the per-cpu interrupt stack back to the process stack is similar to what you're seeing: crash> bt -a PID: 0 TASK: ffffffff8034ce60 CPU: 0 COMMAND: "swapper" #0 [ffffffff80481f30] crash_nmi_callback at ffffffff8007742f #1 [ffffffff80481f40] do_nmi at ffffffff80063c2c #2 [ffffffff80481f50] nmi at ffffffff8006312f [exception RIP: mwait_idle+54] RIP: ffffffff800553b7 RSP: ffffffff80437f90 RFLAGS: 00000246 RAX: 0000000000000000 RBX: ffffffff80055381 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffffffff8034e838 RBP: 0000000000099000 R8: ffffffff80436000 R9: 000000000000003e R10: ffff810037d0c038 R11: 0000000000000048 R12: 0000000000090000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 --- <exception stack> --- #3 [ffffffff80437f90] mwait_idle at ffffffff800553b7 #4 [ffffffff80437f90] cpu_idle at ffffffff800473be PID: 0 TASK: ffff81003fe48100 CPU: 1 COMMAND: "swapper" #0 [ffff81003fe6bb40] crash_kexec at ffffffff800ab7c4 #1 [ffff81003fe6bbc8] mwait_idle at ffffffff800553b7 #2 [ffff81003fe6bc00] sysrq_handle_crashdump at ffffffff8019301f #3 [ffff81003fe6bc10] __handle_sysrq at ffffffff80192e1c #4 [ffff81003fe6bc50] kbd_event at ffffffff8018dbc1 #5 [ffff81003fe6bca0] input_event at ffffffff801e9b9f #6 [ffff81003fe6bcd0] hidinput_hid_event at ffffffff801e42cb #7 [ffff81003fe6bd00] hid_process_event at ffffffff801df66b #8 [ffff81003fe6bd40] hid_input_report at ffffffff801df9d9 #9 [ffff81003fe6bdc0] hid_irq_in at ffffffff801e0dc0 #10 [ffff81003fe6bde0] usb_hcd_giveback_urb at ffffffff801d33d8 #11 [ffff81003fe6be10] uhci_giveback_urb at ffffffff88168724 #12 [ffff81003fe6be50] uhci_scan_schedule at ffffffff88168e07 #13 [ffff81003fe6bed0] uhci_irq at ffffffff8816ac08 #14 [ffff81003fe6bf10] usb_hcd_irq at ffffffff801d3dc7 #15 [ffff81003fe6bf20] handle_IRQ_event at ffffffff80010704 #16 [ffff81003fe6bf50] __do_IRQ at ffffffff800b5238 #17 [ffff81003fe6bf58] __do_softirq at ffffffff80011c0b #18 [ffff81003fe6bf90] do_IRQ at ffffffff8006a762 --- <IRQ stack> --- #19 [ffff81003fe65e70] ret_from_intr at ffffffff8005bac9 [exception RIP: cpu_idle+149] RIP: ffffffff800473be RSP: ffffffff8042e220 RFLAGS: ffffffff80074188 RAX: ffffffffffffff16 RBX: 0000000000000000 RCX: ffffffff800553b7 RDX: 0000000000000010 RSI: 0000000000000246 RDI: ffff81003fe65ef0 RBP: ffff81003fe64000 R8: ffffffff8034e838 R9: 0000000000000001 R10: 0000000000000000 R11: 0000000000000000 R12: 000000000000003f R13: ffff810037d0c008 R14: 0000000000000246 R15: 0000000000000001 ORIG_RAX: 0000000000000018 CS: 0020 SS: 0000 bt: WARNING: possibly bogus exception frame crash> crash dutifully reports that the exception frame looks bogus because of the CS value. The end of the per-cpu interrupt stack looks like this: crash> rd -s ffff81003fe68000 2048 ... ffff81003fe6bf30: 000000000000e900 00000000000000e9 ffff81003fe6bf40: ffff810037ca4bc0 irq_desc+59708 ffff81003fe6bf50: __do_IRQ+164 __do_softirq+94 ffff81003fe6bf60: 00000000000000e9 ffff81003fe65e48 ffff81003fe6bf70: 00000000000000ff cpu_data+256 ffff81003fe6bf80: 0000000000000100 cpu_core_map+32 ffff81003fe6bf90: do_IRQ+231 ffff81003fe65e70 ffff81003fe6bfa0: mwait_idle ffff81003fe65e70 ffff81003fe6bfb0: ret_from_intr ffff81003fe65e70 ffff81003fe6bfc0: 0000000000000000 0000000000000000 ffff81003fe6bfd0: 0000000000000000 0000000000000000 ffff81003fe6bfe0: 0000000000000000 0000000000000000 ffff81003fe6bff0: 0000000000000000 0000000000000000 crash> ...hence the supposed pointer to the generating exception frame is presumed to be ffff81003fe65e70 (which is bogus). Interestingly, though, is if I do an exception frame search for that task, I do find the "real" exception frame: crash> bt -e PID: 0 TASK: ffff81003fe48100 CPU: 1 COMMAND: "swapper" KERNEL-MODE EXCEPTION FRAME AT: ffff81003fe65e48 RIP: ffffffff800553b7 RSP: ffff81003fe65ef0 RFLAGS: 00000246 RAX: 0000000000000000 RBX: 0000000000000001 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffffffff8034e838 RBP: 0000000000000000 R8: ffff81003fe64000 R9: 000000000000003f R10: ffff810037d0c008 R11: 0000000000000246 R12: ffff810037fef040 R13: 0000000000000001 R14: ffff81003fe482f0 R15: 0000000002245f5e ORIG_RAX: ffffffffffffff16 CS: 0010 SS: 0018 crash> sym ffffffff800553b7 ffffffff800553b7 (t) mwait_idle+0x36 include/asm/thread_info.h: 63 crash> and if I just grep for that address within the per-cpu interrupt stack, I see several refernces to it: crash> rd -s ffff81003fe68000 2048 | grep ffff81003fe65e48 ffff81003fe6bb30: ffff81003ac7c000 ffff81003fe65e48 ffff81003fe6bc60: 00ffffff8001c1fd ffff81003fe65e48 ffff81003fe6bce0: ffff81003ec68000 ffff81003fe65e48 ffff81003fe6bd50: ffff81003fe65e48 0000000180087720 ffff81003fe6bda0: ffff810037cb7400 ffff81003fe65e48 ffff81003fe6bdb0: ffff810037cb7550 ffff81003fe65e48 ffff81003fe6be60: ffff81003cf37488 ffff81003fe65e48 ffff81003fe6bec0: ffff81003fe65e48 ffff81003fe65e48 ffff81003fe6bed0: uhci_irq+0x13f ffff81003fe65e48 ffff81003fe6bf00: ffff81003fe65e48 ffff81003fe65e48 ffff81003fe6bf60: 00000000000000e9 ffff81003fe65e48 crash> But none of them are located at the "fixed" location of one word below the 64-byte block at the top of the interrupt stack. So I don't know what's going on in this case... I don't ever recall seeing such a bogus interrupt-to-process stack transition on any netdump or diskdump generated vmcores. And all the "test" kdump kernel dumpfiles I've used have only been generated by using "echo c > /proc/sysrq-trigger", so the crash path never went off the process stack. So without blatantly pointing the finger, I wonder whether there's something that the kexec/kdump code path does that could possibly be tinkering with the contents of the interrupt stack? I also want to try to force another crash but with all cpus forcibly running something other than the idle task, in case there's something strange about the interrupt bringing the cpu out of that "mwait" instruction? Grasping at straws a bit here... Also, that's why I'm always asking for back-trace tests that do something "real" -- instead of just having the kernel call panic(), or that do a sys_write() to /proc/sysrq-trigger to force an oops on the process stack. At least an alt-sysrq-c on the console keyboard generates an interrupt, as does your forced jprobes deal... BTW, I also note the the reading of the module unwind tables is reading invalid data, because it's being done before the non-unity-mapped address translation can even work! In other words, vmalloc addresses can only be read after vm_init() is complete. So I've added another machdep_init() argument (POST_VM) that is called just after vm_init(), and in the case of x86_64 (and x86), can call init_unwind_table(). Thanks, Dave