[Crash-utility] crash 4.0-2.8 fails on 2.6.14-rc5 (EM64T)

[Dave Anderson]

Badari Pulavarty wrote:

> > That debug output certainly seems to pinpoint the issue at hand, doesn't it?
> > Very interesting...
> >
> > What's strange is that the usage of the cpu_pda[i].data_offset by the
> > per_cpu() macro in "include/asm-x86_64/percpu.h" is unchanged.
> >
> > It's probably something very simple going on here, but I don't have
> > any more ideas at this point.
>
> This is the reply I got from Andi Kleen..
>
> -------- Forwarded Message --------
> From: Andi Kleen <ak at suse.de>
> To: Badari Pulavarty <pbadari at us.ibm.com>
> Subject: Re: cpu_pda->data_offset changed recently ?
> Date: Thu, 27 Oct 2005 16:58:54 +0200
> On Thursday 27 October 2005 16:53, Badari Pulavarty wrote:
> > Hi Andi,
> >
> > I am trying to fix "crash" utility to make it work on 2.6.14-rc5.
> > (Its running fine on 2.6.10). It looks like crash utility reads
> > and uses cpu_pda->data_offset values. It looks like there is a
> > change between 2.6.10 & 2.6.14-rc5 which is causing "data_offset"
> > to be huge values - which is causing "crash" to break.
> >
> > I added printk() to find out why ? As you can see from following
> > what changed - Is this expected ? Please let me know.
>
> bootmem used to allocate from the end of the direct mapping on NUMA
> systems. Now it starts at the beginning, often before the kernel .text.
> This means it is negative. Perfectly legitimate. crash just has to
> handle it.
>
> -Andi
>
> --

That's what I thought it looked like, although the x8664_pda.data_offset
field is an "unsigned long".  Anyway, if you take any of the per_cpu__xxx
symbols from the 2.6.14 kernel, subtract a cpu data_offset, does it come up
with a legitimate virtual address?

Dave

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/crash-utility/attachments/20051027/65b69f05/attachment.htm>