<!doctype html public "-//w3c//dtd html 4.0 transitional//en"> <html> <blockquote TYPE=CITE><tt></tt> <tt></tt> <tt>> > Without the map.4 argument, crash doesn't complain about the file</tt> <tt>> > formats.</tt> <tt>></tt> <tt>> ...but the virtual addresses probably don't line up completely?</tt><tt></tt> <tt>Yes, it doesn't work at all, with and without a mapfile, and I guess</tt> <tt>that format changes occurred in the lkcd dump because of this message</tt><tt></tt> <tt> crash: LKCD machine specific dump header doesn't match crash version</tt> <tt> crash: traceback of currently executing threads may not work</tt><tt></tt> <tt>I'm debugging that now. But, if you have some patches already in the</tt> <tt>queue that I can try out or something like this, I would be happy. ;)</tt></blockquote> <tt>Bernhard,</tt><tt></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> <blockquote TYPE=CITE><tt></tt> <tt></tt> <tt>> > Any hints? Thanks!</tt> <tt>></tt> <tt>> Yes, the "map.4" file did not return successfully from the</tt> <tt>> is_system_map() function in symbols.c. That function sanity-checks</tt> <tt>> the first 100 entries in the file to verify that there are 3 entries</tt> <tt>> in each line, that the the first entry contains a 64-bit hexadecimal</tt> <tt>> address, and that the second field contains a single character.</tt> <tt>></tt> <tt>> For example, this is an example of a 2.4 ia64 kernel</tt> <tt>> System.map file:</tt><tt></tt> <tt>I know the format of map files. :)</tt> <tt></tt> </blockquote> <tt>Sorry -- I didn't mean to imply that you weren't... ;-)</tt> <blockquote TYPE=CITE><tt></tt> <tt>But the problem was easy to fix, see my attachment. You aggree that</tt> <tt>the string length must only be smaller. The problem occurs on IA64</tt> <tt>here.</tt><tt></tt> <tt>> What does "head -100 map.4." show?</tt><tt></tt> <tt> 000d5c59 A __crc_simple_sync_file</tt> <tt> 0013a785 A __crc_fb_create_modedb</tt> <tt> 0014bfd1 A __crc_smp_call_function</tt> <tt> 00363991 A __crc_pci_bus_read_config_byte</tt> <tt> 004142de A __crc_rwsem_downgrade_wake</tt> <tt> 0060e766 A __crc_tty_termios_baud_rate</tt> <tt> 00752358 A __crc_permission</tt> <tt> 00801678 A __crc_flush_scheduled_work</tt> <tt> [...]</tt> <tt></tt> </blockquote> <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>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>But anyway, can you send your patch again?</tt><tt></tt> <tt>Thanks,</tt> <tt> Dave</tt> <tt></tt> <tt></tt> </html>