<!doctype html public "-//w3c//dtd html 4.0 transitional//en"> <html> <tt>Badari Pulavarty wrote:</tt> <blockquote TYPE=CITE><tt>On Tue, 2006-04-25 at 14:42 -0400, Dave Anderson wrote:</tt> <tt>> Badari Pulavarty wrote:</tt><tt></tt> <tt>> As far as the determination of the panic task, I'm presuming</tt> <tt>> that this was generated from a kdump dumpfile. The netdump.c</tt> <tt>> get_netdump_panic_task() function, which has a bunch of</tt> <tt>> kdump-specific code, is failing to find the panic task from the</tt> <tt>> data in the ELF header notes. Running "crash -d1 ..." will indicate</tt> <tt>> how crash is trying to determine the panic task. I don't know</tt> <tt>> whether the idle task was even the one that took the sysrq,</tt> <tt>> or whether it just defaulted to that task because it couldn't find</tt> <tt>> any other likely suspects. You'll have to debug it from your</tt> <tt>> end, starting from get_netdump_panic_task().</tt> <tt>></tt><tt></tt> <tt>I did little more digging around :)</tt><tt></tt> <tt>crash -d1 shows me</tt><tt></tt> <tt>crash: get_netdump_panic_task: crashing_cpu: 1</tt> <tt>crash: get_netdump_panic_task: failed</tt> <tt>crash: get_active_set_panic_task: failed</tt><tt></tt> <tt>Looking at get_netdump_panic_task(), there is no code to handle</tt> <tt>EM_X86_64 ? I see checks for</tt><tt></tt> <tt> if (nd->elf64->e_machine == EM_386) {</tt> <tt> ..</tt> <tt> }</tt> <tt> if (nd->elf64->e_machine == EM_PPC64) {</tt> <tt> ...</tt> <tt> }</tt> <tt></tt> <tt></tt> </blockquote> <tt>Hey -- you're right -- there's nothing EM_X86_64-specific</tt> <tt>done in that function. I don't see why something couldn't</tt> <tt>be put in place, but it's been unnecessary since the panic</tt> <tt>task would normally be found by one of the follow-up functions,</tt> <tt>i.e., in either get_active_set_panic_task(), or if that fails,</tt> <tt>the lowest common denominator function, in panic_search().</tt> <tt>Now, since after the "crash: get_active_set_panic_task: failed"</tt> <tt>message, there are no more error messages, so panic_search()</tt> <tt>must have determined that the idle thread (swapper) on cpu 0 was</tt> <tt>in fact the running task that took the sysrq. But the stack</tt> <tt>trace shows just a single "schedule()" line...</tt><tt></tt> <tt>So, can you do the following, while staying in that same context:</tt><tt></tt> <tt>crash> bt -T</tt><tt></tt> <tt>...and see if the ".crash_kexec" return address shows up</tt> <tt>anywhere in the process stack? Since that task was selected</tt> <tt>as the panic task, it should be there somewhere. And if</tt> <tt>it's there, it should be used as the starting point of the</tt> <tt>back trace. Then do this:</tt><tt></tt> <tt>crash> set debug 1</tt> <tt>crash> bt</tt> <tt>...</tt><tt></tt> <tt>What should be displayed for the panic task, prior to the back</tt> <tt>trace data, is this message from get_netdump_regs_x86_64():</tt><tt></tt> <tt> if (CRASHDEBUG(1)) {</tt> <tt> rsp = ULONG(user_regs + OFFSET(user_regs_struct_rsp));</tt> <tt> rip = ULONG(user_regs + OFFSET(user_regs_struct_rip));</tt> <tt> netdump_print("ELF prstatus rsp: %lx rip: %lx\n",</tt> <tt> rsp, rip);</tt> <tt> }</tt><tt></tt> <tt>Do you see that message?</tt><tt></tt> <tt>Dave</tt> <tt></tt> </html>