Re: [Crash-utility] cannot resolve: "end_pfn" with recent rawhide kernel
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