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>
To: Badari Pulavarty <pbadari(a)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