[Crash-utility] crash-4.0-4.3 and linux-2.6.22.1-20.fc7

[Dave Anderson]

> Using the latest F7 kernel and crash I'm getting the following
> error:
> 
> WARNING: cannot read linux_banner string
> 
> crash: /usr/lib/debug/lib/modules/2.6.22.1-20.fc7/vmlinux and /dev/crash do not match!
> 
> I've tried both crash and crash -f with no luck.
> 
> I've search the mailing list and was unable to find any
> thing talked about this problem... So I'm thinking this
> may not be a known problem... If it is, please let me know
> otherwise does anybody have idea what the problem could be?
> 
> tia,
> 
> steved.
> 

This elephant still remains in the room...

I can reproduce it with a 2.6.21-1.3194.fc7 kernel, which
I believe has 2.6.22 stuff backported to it.

What's happening is that the x86 kernel's base virtual address
space has changed, such that instead of starting at the traditional
addresses of 0xc0100000 or 0xc0400000, it now begins at 0xc1000000.

However, the physical address of unity-mapped kernel virtual
addresses is no longer calculated with a trivial subtracting
of the kernel virtual base address.  So for example, the
"linux_banner" address causing the "do not match" session
failure is at 0xc1206000, which I've determined is actually
located at physical address 0x606000.  So the traditional
x86 VTOP() operation no longer works, the wrong physical
memory is read, and the crash session is terminated.

But when I kludge up a temporary virtual-to-physical translator
that does translate 0xc1206000 into 0x606000, things "work" OK
for all kernel symbol-based addresses, but it does not work for
non-kernel-symbol unity-mapped addresses, such as those returned
by kmalloc().

Presumably this has something to do with changes for kexec/kdump
and/or relocatable x86 kernels (?), but I'm not clear on that yet,
nor how VTOP operations should be done properly.

So until further notice, crash no longer works on 2.6.22-era
x86 kernels.

Dave