Per, On Fri, Mar 8, 2013 at 3:46 AM, Per Fransson <per.fransson.ml@xxxxxxxxx> wrote: > Hi, > >>> Are you able to test with the same GDB version that is embedded in crash? >>> >>> I'm running out of ideas (I sure hope Per figures out what is going on :-)). >> >> Thanks for that vote of confidence =o) >> >> Alas, I must confess, >> all I have is a guess >> that "dot text" is partly a mess >> ...no less >> >> /Per >> >>> Are you able to make the vmlinux/vmcore pair available to us? >>> > > Short version: > ############## > It's the compressed kernel, including decompression stub, occupying > the first 0x3ffe00 bytes of .text > > Long version: > ############# > I extracted the .text parts of the vmlinux and dump and diffed: > > vmlinux > ------- > .text: > start: 0x0081c0 = 33216 > size: 0x4a85d4 = 4883924 > dd bs=1 count=4883924 skip=33216 if=vmlinux of=vmlinux_text > > dump > ---- > .text: > start: 0xc01081c0 - 0xc0000000 + 0x94 = 1081940 > size: 0x4a85d4 = 4883924 > dd bs=1 count=4883924 skip=1081940 if=233_0128.dump of=dump_text > > First I thought I had made a mistake, because, to begin with, it's all > different, but then, after 0x3ffe00 bytes (that'd correspond to > virtual address 0xc01081c0+0x3ffe00=0xc0507fc0 in crash), it's all > identical (except for __v7_setup_stack, which for some reason is > placed in .text.) This made me run 'string' on the data in those first > 0x3ffe00 bytes of .text and they looked kind of familiar, for example: > > 3baf -- System halted > 3bc1 Attempting division by 0! > 3bdb Uncompressing Linux... > 3bf2 decompressor returned an error > 3c11 done, booting the kernel. > > and that's when I realized it was the image from > arch/arm/boot/compressed. I think you've loaded a new (capture?) > kernel at the location where the original one was loaded before > pulling out the dump. I also predict there will be a cut-off point at > virtual address 0xc0507fc0, with all the code at lower addresses being > bad and everything else being ok. > > If you need to you can probably replace those 0x3ffe00 bytes of the > dump with those from the vmlinux. Thanks for this finding! It would well explain my previous issue now! Thanks, Lei -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility