[Crash-utility] cannot resolve: "end_pfn" with recent rawhide kernel

[Dave Anderson]

Dave Anderson wrote:
> Jeff Layton wrote:
>> Attempting to open a core from a recent x86_64 rawhide kernel and am
>> getting this error:
>>
>>     crash: cannot resolve: "end_pfn"
>>
>> kernel 2.6.27-0.244.rc2.git1.fc10.x86_64
>> crash-4.0-7.x86_64
>>
>> The host is a FV xen guest and the core was generated with "xm
>> dump-core". Let me know if you need other info (or if I should open a
>> BZ).
>>
>> Thanks,
> 
> Please -- no bugzillas on upstream kernel issues...  Reporting them
> to this list is the way to go.
> 
> If you have the vmlinux/vmcore pair, send them to me off-line and I'll
> take a look.
> 
> As a general heads-up, there are known problems with 2.6.26 support
> as well.  Usually my army of crash developers are right on top of things
> with upstream kernels, forwarding patches to this list, but they're
> slipping lately...   ;-)
> 
> Dave

The base problem is that there is no longer an "end_pfn" symbol for
x86_64.  As a quick-and-dirty fix, I just replaced its use with
the "max_pfn" value, but doing that only opened up another Pandora's box.

In the 2.6.27 timeframe, a bunch of xen-related code got merged
into the base kernel (probably part of recent pv_ops-related stuff?),
and now crash is confused because of the existence of "xen_start_info"
symbol in the base kernel -- which it has always used to determine
whether the kernel is a xen kernel.  Now, even in baremetal, non-xen kernels,
there's a huge list of xen-specific symbols, including xen_start_info.

Anyway, I don't know when I'll get time to look at this, but for now,
let it suffice to say that the crash utility is dead-in-the-water for
2.6.27 kernels that have this xen stuff in them...

Oh yeah, FWIW, 2.6.26 kernels w/CONFIG_SLUB cause "kmem -[sS]" to
fail immediately because the venerable kmem_cache.objects counter
member no longer exists.

Shifting sands...

Dave