> > > > > Without the map.4 argument, crash doesn't complain about the file > > > formats. > > > > ...but the virtual addresses probably don't line up completely? > > Yes, it doesn't work at all, with and without a mapfile, and I guess > that format changes occurred in the lkcd dump because of this message > > crash: LKCD machine specific dump header doesn't match crash version > crash: traceback of currently executing threads may not work > > I'm debugging that now. But, if you have some patches already in the > queue that I can try out or something like this, I would be happy. ;)
Bernhard, I wish I could help you out, but w/respect to anything associated with LKCD, I'm only a receptor of patches from the LKCD developers on the list, and I personally don't do any work with them at all. That whole ia64-specific lkcd_fix_mem.c file came from Troy Heber for ia64 LKCD dumpfile support ([EMAIL PROTECTED]). Troy's an active contributor on this list, and may have a quick answer -- I'm afraid I have no idea what it does... > > > > > Any hints? Thanks! > > > > Yes, the "map.4" file did not return successfully from the > > is_system_map() function in symbols.c. That function sanity-checks > > the first 100 entries in the file to verify that there are 3 entries > > in each line, that the the first entry contains a 64-bit hexadecimal > > address, and that the second field contains a single character. > > > > For example, this is an example of a 2.4 ia64 kernel > > System.map file: > > I know the format of map files. :) > Sorry -- I didn't mean to imply that you weren't... ;-) > > But the problem was easy to fix, see my attachment. You aggree that > the string length must only be smaller. The problem occurs on IA64 > here. > > > What does "head -100 map.4." show? > > 000d5c59 A __crc_simple_sync_file > 0013a785 A __crc_fb_create_modedb > 0014bfd1 A __crc_smp_call_function > 00363991 A __crc_pci_bus_read_config_byte > 004142de A __crc_rwsem_downgrade_wake > 0060e766 A __crc_tty_termios_baud_rate > 00752358 A __crc_permission > 00801678 A __crc_flush_scheduled_work > [...] > Yes I agree (presuming that eventually the list turns into 64-bit symbol values). But I don't see any attachment other than your pgp signature? I'd never seen those types of __crc_ absolutes, probably because they don't show up in our kernels. The closest 2.6.5-era ia64 Red Hat kernel (2.6.5-1.358) System.map starts out like this: a00000010010c5a0 T I_BDEV a0000001005bd140 r __ksymtab_I_BDEV a0000001005c6ca8 r __kstrtab_I_BDEV a00000010030ff60 T QUIRK_LIST a0000001005c0950 r __ksymtab_QUIRK_LIST a0000001005cb698 r __kstrtab_QUIRK_LIST a000000100714ff8 S ROOT_DEV a0000001005bb020 r __ksymtab_ROOT_DEV a0000001005c4248 r __kstrtab_ROOT_DEV a00000010030fd00 T SELECT_DRIVE a0000001005c0920 r __ksymtab_SELECT_DRIVE a0000001005cb660 r __kstrtab_SELECT_DRIVE a00000010030fde0 T SELECT_INTERRUPT Whatever... maybe a different build CONFIG or something? But anyway, can you send your patch again? Thanks, Dave
-- Crash-utility mailing list [email protected] https://www.redhat.com/mailman/listinfo/crash-utility
