[Crash-utility] crash can not read ia64 lkcd v9 dump

[Dave Anderson]

>
>
> > > 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 (troy.heber at hp.com).  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























-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/crash-utility/attachments/20061208/84ea019e/attachment.htm>