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

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(a)suse.de&gt; > To: Badari Pulavarty <pbadari(a)us.ibm.com&gt; > 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?