----- "Dave Anderson" <anderson@xxxxxxxxxx> wrote: > ----- "Simon Kagstrom" <simon.kagstrom@xxxxxxxxxxxxxx> wrote: > > > Hi! > > > > I'm having problems getting kdumps from my relocatable kernel (2.6.31-8) > > working with crash on a IA-32 board. I use makedumpfile to generate a > > compressed dump, and when I try to load it with crash I get > > > > ./crash vmlinux vmcore --reloc=0x100000 > > crash: invalid kernel virtual address: 98 type: "present" > > WARNING: cannot read cpu_present_map > > crash: invalid kernel virtual address: 908bd975 type: "online" > > WARNING: cannot read cpu_online_map > > crash: cannot determine base kernel version > > crash: vmlinux and vmcore do not match! > > > > specifying --reloc also fails: > > > > ./crash vmlinux vmcore --reloc=0x100000 > > crash: seek error: kernel virtual address: c01a2108 type: "cpu_possible_mask" > > > > > > So I started looking into the code and found something which looks like > > a typo in relocate() (patch below). Changing this makes crash work for me. > > Actually it's not a typo -- your patch would presumably break with all kernels > that have a CONFIG_PHYSICAL_START is greater than CONFIG_PHYSICAL_ALIGN, which > is what the patch was written to handle. > > What are your kernel's CONFIG_PHYSICAL_START and CONFIG_PHYSICAL_ALIGN > values? Does crash work with your kernel on the live system? > > Anyway, I believe that the fix would require support for supplying a > negative --reloc value. On the other hand, if the config values were the other way around, the problem didn't use to show up -- at least according to list item "1)" below in the changelog: 4.0-4.5 - Addresses FC7/upstream x86 kernels that have been configured such that the vmlinux symbol values do not match their relocated values when loaded. If CONFIG_PHYSICAL_START contains a value that is greater then CONFIG_PHYSICAL_ALIGN, then this mismatch occurs. Since the crash utility and its embedded gdb have always expected that the compiled-in kernel symbol addresses are "real", the virtual to physical translation fails, leading to an initialization-time failure with the message: "crash: vmlinux and /dev/crash do not match!" (/dev/mem or the dumpfile name may replace /dev/crash). To deal with this issue, there are several alternatives: 1) Configure the kernel with CONFIG_PHYSICAL_START less than or equal to CONFIG_PHYSICAL_ALIGN. Having done that, there is no problem; the resultant vmlinux file will be loaded at the address for which it was compiled, which has always been the case. 2) Since /proc/kallsyms uses the same format as a System.map file, and since it reflects the relocated symbol addresses, it can be placed on the crash command line as if it were a System.map file. (Note that the System.map file created by these relocated kernels contains the same "wrong" symbol values as the vmlinux file from which it was created.) 3) On a live system that has /proc/kallsyms (i.e., the kernel was configured with CONFIG_KALLSYMS), this version of the crash utility will replace/patch the vmlinux symbol values with those seen in /proc/kallsyms. The relocation value will be displayed as a WARNING message during initialization. 4) On a dumpfile, the relocation will not be performed automatically as on a live system. It will require the addition of the /proc/kallsyms on the command line, or if run on a different host, a copy of the crashed system's /proc/kallsyms may be used. 5) Alternatively on a dumpfile, a new command line option has been created to specify the relocation amount. For example, if a kernel was configured with a CONFIG_PHYSICAL_START value of 16MB and a CONFIG_PHYSICAL_ALIGN of 4MB, that results in a relocation of 12MB. To specify that, enter "crash --reloc=12m ..." on the command line. (Recall that if crash is run on the live system, a WARNING message will specify the relocation amount.) Using /proc/kallsyms or a --reloc=[size] as a command line argument is similar to using a System.map file, in that it results in the loss of the use of line number debug data. (anderson@xxxxxxxxxx) I wonder if you can use the unpatched crash, but supply a --reloc value that will cause a wrap-around to the correct value? Dave > > > > > Great tool by the way, leaves you longing for the next kernel panic > > ;-) > > > > // Simon > > > > --- orig-crash-4.1.2/symbols.c 2009-12-09 21:37:40.000000000 +0100 > > +++ crash-4.1.2/symbols.c 2009-12-17 16:03:24.000000000 +0100 > > @@ -671,7 +671,7 @@ relocate(ulong symval, char *symname, in > > break; > > } > > > > - return (symval - kt->relocate); > > + return (symval + kt->relocate); > > } > > > > /* > > -- > Crash-utility mailing list > Crash-utility@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/crash-utility -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility