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 -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility
