<!doctype html public "-//w3c//dtd html 4.0 transitional//en"> <html> <tt>Bernhard Walle wrote:</tt> <blockquote TYPE=CITE><tt>Hello,</tt><tt></tt> <tt>* Dave Anderson <anderson@redhat.com> [2006-12-08 19:37]:</tt> <tt>> I wish I could help you out, but w/respect to anything associated with</tt> <tt>> LKCD, I'm only a receptor of patches from the LKCD developers on the</tt> <tt>> list, and I personally don't do any work with them at all.</tt> <tt>></tt> <tt>> That whole ia64-specific lkcd_fix_mem.c file came from Troy Heber for</tt> <tt>> ia64 LKCD dumpfile support (troy.heber@hp.com). Troy's an active</tt> <tt>> contributor on this list, and may have a quick answer -- I'm afraid I</tt> <tt>> have no idea what it does...</tt><tt></tt> <tt>Anyway, thanks for the information!</tt><tt></tt> <tt>> Yes I agree (presuming that eventually the list turns into 64-bit</tt> <tt>> symbol values). But I don't see any attachment other than your pgp</tt> <tt>> signature?</tt><tt></tt> <tt>Sorry, I just forgot it. Here it is.</tt><tt></tt> <tt>And yes, the values are larger in the end. And also our</tt> <tt>/boot/System.map on IA64 has zero-prefixes. The map.4 file is</tt> <tt>generated by lkcd, and they simply don't use the zero prefixes. Which</tt> <tt>should not matter, IMO. So I vote for applying the attached patch.</tt> <tt></tt> </blockquote> <tt>Ah, Ok -- that makes sense now...</tt><tt></tt> <tt>And your patch is sane -- and queued for the next release.</tt> <blockquote TYPE=CITE><tt></tt> <tt>> I'd never seen those types of __crc_ absolutes, probably because</tt> <tt>> they don't show up in our kernels. The closest 2.6.5-era ia64</tt> <tt>> Red Hat kernel (2.6.5-1.358) System.map starts out like this:</tt> <tt>></tt> <tt>> a00000010010c5a0 T I_BDEV</tt> <tt>> a0000001005bd140 r __ksymtab_I_BDEV</tt> <tt>> a0000001005c6ca8 r __kstrtab_I_BDEV</tt> <tt>> a00000010030ff60 T QUIRK_LIST</tt> <tt>> a0000001005c0950 r __ksymtab_QUIRK_LIST</tt> <tt>> a0000001005cb698 r __kstrtab_QUIRK_LIST</tt> <tt>> a000000100714ff8 S ROOT_DEV</tt> <tt>> a0000001005bb020 r __ksymtab_ROOT_DEV</tt> <tt>> a0000001005c4248 r __kstrtab_ROOT_DEV</tt> <tt>> a00000010030fd00 T SELECT_DRIVE</tt> <tt>> a0000001005c0920 r __ksymtab_SELECT_DRIVE</tt> <tt>> a0000001005cb660 r __kstrtab_SELECT_DRIVE</tt> <tt>> a00000010030fde0 T SELECT_INTERRUPT</tt> <tt>></tt> <tt>> Whatever... maybe a different build CONFIG or something?</tt><tt></tt> <tt>Hm ..., I also don't understand why the /boot/System.map of the same</tt> <tt>kernel isn't identical to the map.4 file generated by klcd. In fact,</tt> <tt>map.4 is missing symbol and gdb fails to load. But even with the</tt> <tt>/boot/System.map of the right kernel, it doesn't work (i.e. backtrace</tt> <tt>is complete garbage).</tt> <tt></tt> </blockquote> <tt>I'm guessing that the backtrace of the active tasks are bogus,</tt> <tt>but all of the sleeping tasks backtraces are OK? If the LKCD</tt> <tt>dump operation does *not* force the panic task and the other</tt> <tt>currently-active tasks to drop a switch_stack on their stacks,</tt> <tt>you'll not get a backtrace. The panic task and active tasks in</tt> <tt>the netdump, diskdump and kdump facilities all run through</tt> <tt>an unw_init_running() as part of their shutdown procedures,</tt> <tt>and each cpu stores the address of it's switch_stack in its</tt> <tt>current->thread.ksp field. Then the ia64 backtrace needs no</tt> <tt>special handling between active and non-active tasks.</tt><tt></tt> <tt>I would have thought that LKCD would do the same kind</tt> <tt>of thing? If the LKCD facilility *does* do that, then</tt> <tt>it's a matter of finding the location of the switch_stack</tt> <tt>on the kernel stack.</tt><tt></tt> <tt>BTW, worst case, you can get a rough idea of what's going</tt> <tt>on by using "bt -t", which dumps all of the kernel text addresses</tt> <tt>found from just above the task_struct to the end of the stack.</tt><tt></tt> <tt>For example, here's a "echo c > /proc/sysrq-trigger" kdump,</tt> <tt>where you get a clear backtrace:</tt><tt></tt> <tt>crash> bt</tt> <tt>PID: 3235 TASK: e0000040484a0000 CPU: 0 COMMAND: "bash"</tt> <tt> #0 [BSP:e0000040484a13e8] machine_kexec at a000000100058a10</tt> <tt> #1 [BSP:e0000040484a13c8] crash_kexec at a0000001000cbea0</tt> <tt> #2 [BSP:e0000040484a13a0] sysrq_handle_crashdump at a0000001003a0680</tt> <tt> #3 [BSP:e0000040484a1350] __handle_sysrq at a00000010039fec0</tt> <tt> #4 [BSP:e0000040484a1320] write_sysrq_trigger at a0000001001e3390</tt> <tt> #5 [BSP:e0000040484a12d0] vfs_write at a000000100156800</tt> <tt> #6 [BSP:e0000040484a1258] sys_write at a000000100157350</tt> <tt> #7 [BSP:e0000040484a1258] ia64_ret_from_syscall at a00000010000c560</tt> <tt> EFRAME: e0000040484a7e40</tt> <tt> B0: 2000000000152820 CR_IIP: a000000000010620</tt> <tt> CR_IPSR: 00001213085a6010 CR_IFS: 0000000000000008</tt> <tt> AR_PFS: c000000000000008 AR_RSC: 000000000000000f</tt> <tt> AR_UNAT: 0000000000000000 AR_RNAT: 0000000000000000</tt> <tt> AR_CCV: 0000000000000000 AR_FPSR: 0009804c8a70033f</tt> <tt> LOADRS: 0000000001b80000 AR_BSPSTORE: 60000fff7fffc380</tt> <tt> B6: 2000000000218cc0 B7: a000000000010640</tt> <tt> PR: 0000000000590a41 R1: 2000000000290238</tt> <tt> R2: c000000000001fc7 R3: 60000ffffe76b6f0</tt> <tt> R8: 0000000000000001 R9: 0000000000000000</tt> <tt> R10: 0000000000000000 R11: c000000000000512</tt> <tt> R12: 60000ffffe76b6d0 R13: 200000000004f790</tt> <tt> R14: 0000000000000063 R15: 0000000000000403</tt> <tt> R16: 60000000000641ff R17: 60000ffffe76b6b0</tt> <tt> R18: 0000000000000000 R19: 6000000000064210</tt> <tt> R20: 0000000000000001 R21: 6000000000030063</tt> <tt> R22: 2000000000636e79 R23: 6000000000064200</tt> <tt> R24: 0000000000000010 R25: 0000000000000000</tt> <tt> R26: c000000000000004 R27: 000000000000000f</tt> <tt> R28: a000000000010620 R29: 00001213085a6010</tt> <tt> R30: 0000000000000008 R31: 00000000005a0a41</tt> <tt> F6: 000000000000000000000 F7: 000000000000000000000</tt> <tt> F8: 000000000000000000000 F9: 000000000000000000000</tt> <tt> F10: 000000000000000000000 F11: 000000000000000000000</tt> <tt> #8 [BSP:e0000040484a1258] __kernel_syscall_via_break at a000000000010620</tt> <tt>crash></tt><tt></tt> <tt>But if I do a "bt -t" on the same task, because the ia64 BSP area</tt> <tt>is just above the task_struct, you can see the trace in kind of a</tt> <tt>"reverse order":</tt><tt></tt> <tt>crash> bt -t</tt> <tt>PID: 3235 TASK: e0000040484a0000 CPU: 0 COMMAND: "bash"</tt> <tt> START: machine_kexec at a000000100058a10</tt> <tt> [e0000040484a12b8] ia64_ret_from_syscall at a00000010000c560</tt> <tt> [e0000040484a1308] sys_write at a000000100157350</tt> <tt> [e0000040484a1338] vfs_write at a000000100156800</tt> <tt> [e0000040484a1388] write_sysrq_trigger at a0000001001e3390</tt> <tt> [e0000040484a13b0] __handle_sysrq at a00000010039fec0</tt> <tt> [e0000040484a13d0] sysrq_handle_crashdump at a0000001003a0680</tt> <tt> [e0000040484a13e0] __handle_sysrq at a00000010039fe70</tt> <tt> [e0000040484a13f0] crash_kexec at a0000001000cbea0</tt> <tt> [e0000040484a1420] machine_kexec at a000000100058a10</tt> <tt> [e0000040484a1450] unw_init_running at a00000010000cdb0</tt> <tt> [e0000040484a1488] ia64_machine_kexec at a000000100058c60</tt> <tt> [e0000040484a14a8] ia64_handle_irq at a000000100011cd0</tt> <tt> [e0000040484a14d8] ia64_handle_irq at a000000100011c50</tt> <tt> [e0000040484a14f8] __do_IRQ at a0000001000e4120</tt> <tt> [e0000040484a1508] irq_exit at a000000100087220</tt> <tt> [e0000040484a1538] iosapic_end_level_irq at a00000010004f730</tt> <tt> [e0000040484a1550] __do_IRQ at a0000001000e4070</tt> <tt> [e0000040484a1580] do_softirq at a000000100087150</tt> <tt> [e0000040484a15c0] __do_softirq at a000000100086f90</tt> <tt> [e0000040484a1620] net_rx_action at a00000010051efc0</tt> <tt> [e0000040484a1630] e1000_check_options at a000000200965e18</tt> <tt> [e0000040484a16d0] e1000_clean at a00000020093e8e0</tt> <tt> [e0000040484a16e0] e1000_check_options at a000000200965e18</tt> <tt> [e0000040484a16f0] ip_rcv at a000000100568e40</tt> <tt> [e0000040484a1710] e1000_clean_rx_irq at a000000200944cd0</tt> <tt> [e0000040484a1770] __do_softirq at a000000100086f90</tt> <tt> [e0000040484a17c8] net_rx_action at a00000010051efc0</tt> <tt> [e0000040484a17d8] e1000_check_options at a000000200965e18</tt> <tt> [e0000040484a1880] e1000_clean at a00000020093e8e0</tt> <tt> [e0000040484a1890] e1000_check_options at a000000200965e18</tt> <tt> [e0000040484a18a0] ip_rcv at a000000100568e40</tt> <tt> [e0000040484a18c0] e1000_clean_rx_irq at a000000200944cd0</tt> <tt> [e0000040484a18f8] sync_buffer at a00000010015cb40</tt> <tt> [e0000040484a1910] io_schedule at a000000100620bd0</tt> <tt> [e0000040484a1940] __delayacct_blkio_start at a0000001000ebc70</tt> <tt> [e0000040484a19b8] io_schedule at a000000100620c00</tt> <tt> [e0000040484a78d0] machine_kexec at a000000100058a10</tt> <tt> [e0000040484a7c10] machine_kexec at a000000100058a10</tt> <tt> [e0000040484a7ca0] schedule at a00000010061f7c0</tt> <tt>crash></tt><tt></tt> <tt>But -- since the ia64 is the only processor for which you</tt> <tt>can get real, dependable, backtraces for, it would be nice</tt> <tt>if it could work for LKCD dumpfiles.</tt><tt></tt> <tt>Dave</tt> <tt></tt> <blockquote TYPE=CITE><tt></tt> <tt>But first I'll fix the header format which _is_ different in crash and</tt> <tt>our SLES9 kernel (and klcdutils), and if it then doesn't work I'll</tt> <tt>come back to the system maps.</tt><tt></tt> <tt>Thanks for your help!</tt><tt></tt> <tt>Regards,</tt> <tt> Bernhard</tt></blockquote> </html>