This is likely going to be a painful process getting crash to work right with these kernels again... The tss_struct hack I suggested to Solofo earlier will actually get an x86_64 session started: --- crash-4.0-4.13/x86_64.c.orig +++ crash-4.0-4.13/x86_64.c @@ -255,7 +255,7 @@ x86_64_init(int when) MEMBER_OFFSET_INIT(thread_struct_rsp, "thread_struct", "rsp"); MEMBER_OFFSET_INIT(thread_struct_rsp0, "thread_struct", "rsp0"); STRUCT_SIZE_INIT(tss_struct, "tss_struct"); - MEMBER_OFFSET_INIT(tss_struct_ist, "tss_struct", "ist"); + MEMBER_OFFSET_INIT(tss_struct_ist, "x86_hw_tss", "ist"); MEMBER_OFFSET_INIT(user_regs_struct_rip, "user_regs_struct", "rip"); MEMBER_OFFSET_INIT(user_regs_struct_rsp, but there will be numerous obstacles to overcome due to other structure related changes. Fundamental data structures that are crucial to crash have changed. Many are just name changes, but will cause "invalid structure member offset" failures like so: crash> bt 1 bt: invalid structure member offset: thread_struct_rsp FILE: x86_64.c LINE: 3645 FUNCTION: x86_64_get_sp() [./crash] error trace: 514b52 => 4d2ce8 => 4d3c3e => 4fff86 PID: 1 TASK: ffff81012fa9e7e0 CPU: 1 COMMAND: "init" 4fff86: OFFSET_verify+159 4d3c3e: x86_64_get_sp+110 4d2ce8: x86_64_get_stack_frame+107 514b52: get_netdump_regs_x86_64+798 WARNING: Because this kernel was compiled with gcc version 4.2.3, certain commands or command options may fail unless crash is invoked with the "--readnow" command line option. bt: invalid structure member offset: thread_struct_rsp FILE: x86_64.c LINE: 3645 FUNCTION: x86_64_get_sp() crash> which happens because the x86_64 thread_struct.rsp member has been renamed thread_struct.sp. Another example is the venerable pt_regs structure, which has changed many of its member names, from: struct pt_regs { long unsigned int r15; long unsigned int r14; long unsigned int r13; long unsigned int r12; long unsigned int rbp; long unsigned int rbx; long unsigned int r11; long unsigned int r10; long unsigned int r9; long unsigned int r8; long unsigned int rax; long unsigned int rcx; long unsigned int rdx; long unsigned int rsi; long unsigned int rdi; long unsigned int orig_rax; long unsigned int rip; long unsigned int cs; long unsigned int eflags; long unsigned int rsp; long unsigned int ss; } to: struct pt_regs { long unsigned int r15; long unsigned int r14; long unsigned int r13; long unsigned int r12; long unsigned int bp; long unsigned int bx; long unsigned int r11; long unsigned int r10; long unsigned int r9; long unsigned int r8; long unsigned int ax; long unsigned int cx; long unsigned int dx; long unsigned int si; long unsigned int di; long unsigned int orig_ax; long unsigned int ip; long unsigned int cs; long unsigned int flags; long unsigned int sp; long unsigned int ss; } Anyway, the same types of issues will plague x86 as well. What a pain in the ass... BTW, if anybody happens to have an x86 vmlinux/vmcore pair from a 2.6.25 kernel that they could make available to me, I'd appreciate it. Many thanks to Solofo for making the x86_64 dumpfile available to work with. Back to the drawing board... Dave