Re: Commit for mm/page_alloc.c breaks boot process on my machine

On (01/02/08 22:06), Gerhard Pircher didst pronounce:

-------- Original-Nachricht --------

quoted

Datum: Fri, 1 Feb 2008 20:25:18 +0000
Von: Mel Gorman [off-list ref]
An: Gerhard Pircher [off-list ref]
CC: linux-kernel@vger.kernel.org
Betreff: Re: Commit for mm/page_alloc.c breaks boot process on my machine

quoted

I meant uninitialised memory but I also wonder could something like this
happen if you are trying to use memory that doesn't exist. i.e. you are
trying to access more memory than you really have but you indicate later
that this is not the case.

Good question. The memory is in the physical address range from 0x00000000
to 0x60000000 (1536MB).

quoted

quoted

quoted

2. Any chance of seeing a dmesg log?

That's a little bit of a problem. The kernel log in memory doesn't show
any kernel oops, but is also fragmented (small fragments seem to have
been overwritten with 0x0).

err, that doesn't sound very healthy.

Yeah, I know. But the platform code hasn't changed much when porting it
from arch/ppc to arch/powerpc. That's why I'm a little bit lost in this
case. :-)

I'm at a bit of a loss to guess what might have changed in powerpc code
that would explain this. I've added the linuxppc-dev mailing list in
case they can make a guess.

I think you are also going to need to start bisecting searching
specifically for the patch that causes these overwrites.

quoted

quoted

Well, I can't answer this question. The kernel currently locks up when
loading the INIT program. But that is another problem (I still have to
bisect it) and doesn't seem to be related to this problem.

INIT would be the first MOVABLE allocation so it would be using memory
at the end of the physical adddress range. i.e. the crash happens when
memory towards the end and the only difference between the patch applied
and reverted is when it happens.

Oh, that sounds interesting!

quoted

Could you try booting with 16MB less memory using mem=?

I started the kernel with 512MB RAM (mem=496) and 1.5GB (mem=1520). The
kernel oopes in both cases with a "Unable to handle kernel paging request
for data address 0xbffff000", followed by a "Oops: kernel access of bad
area, sig 11" message. The end of the stack trace shows the start_here()
function.
I'm not a PowerPC expert, but if 0xbffff000 is a virtual address, then
it would be in the user program address space, right? If it is a physical
address, then it is somewhere in the unallocated PCI address space.

It's a virtual address so it depends on the value of CONFIG_KERNEL_START
as to whether this is a user program address or not.

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab

-------- Original-Nachricht --------

Datum: Mon, 4 Feb 2008 10:42:32 +0000
Von: Mel Gorman [off-list ref]
An: Gerhard Pircher [off-list ref]
CC: linux-kernel@vger.kernel.org, linuxppc-dev@ozlabs.org
Betreff: Re: Commit for mm/page_alloc.c breaks boot process on my machine

quoted

quoted

quoted

quoted

2. Any chance of seeing a dmesg log?

That's a little bit of a problem. The kernel log in memory doesn't
show any kernel oops, but is also fragmented (small fragments seem
to have been overwritten with 0x0).

err, that doesn't sound very healthy.

Yeah, I know. But the platform code hasn't changed much when porting it
from arch/ppc to arch/powerpc. That's why I'm a little bit lost in this
case. :-)

I'm at a bit of a loss to guess what might have changed in powerpc code
that would explain this. I've added the linuxppc-dev mailing list in
case they can make a guess.

Yes, I'll try to get some comments on the linuxppc-dev mailing list.

I think you are also going to need to start bisecting searching
specifically for the patch that causes these overwrites.

I think I had a similar problem with kernel v2.6.23, too and therefore
waited for kernel 2.6.24. So the problem may exist since a long time.

It's a virtual address so it depends on the value of CONFIG_KERNEL_START
as to whether this is a user program address or not.

AFAIK start_kernel() is called very early in the boot process, were no
user or kernel thread is active. I also wonder why the kernel crashes when
the mem boot option is used. Let's see what the linuxppc-dev people say.

Thanks for your help!

Gerhard

-- 
Psssst! Schon vom neuen GMX MultiMessenger gehört?
Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger

On Mon, 2008-02-04 at 23:20 +0100, Gerhard Pircher wrote:

-------- Original-Nachricht --------

quoted

Datum: Mon, 4 Feb 2008 10:42:32 +0000
Von: Mel Gorman [off-list ref]
An: Gerhard Pircher [off-list ref]
CC: linux-kernel@vger.kernel.org, linuxppc-dev@ozlabs.org
Betreff: Re: Commit for mm/page_alloc.c breaks boot process on my machine

quoted

quoted

quoted

quoted

quoted

2. Any chance of seeing a dmesg log?

That's a little bit of a problem. The kernel log in memory doesn't
show any kernel oops, but is also fragmented (small fragments seem
to have been overwritten with 0x0).

err, that doesn't sound very healthy.

Yeah, I know. But the platform code hasn't changed much when porting it
from arch/ppc to arch/powerpc. That's why I'm a little bit lost in this
case. :-)

I'm at a bit of a loss to guess what might have changed in powerpc code
that would explain this. I've added the linuxppc-dev mailing list in
case they can make a guess.

Yes, I'll try to get some comments on the linuxppc-dev mailing list.

quoted

I think you are also going to need to start bisecting searching
specifically for the patch that causes these overwrites.

I think I had a similar problem with kernel v2.6.23, too and therefore
waited for kernel 2.6.24. So the problem may exist since a long time.

quoted

It's a virtual address so it depends on the value of CONFIG_KERNEL_START
as to whether this is a user program address or not.

AFAIK start_kernel() is called very early in the boot process, were no
user or kernel thread is active. I also wonder why the kernel crashes when
the mem boot option is used. Let's see what the linuxppc-dev people say.

Can you post a fresh bug report? There's lots of details missing from
the email you forwarded.

cheers

-- 
Michael Ellerman
OzLabs, IBM Australia Development Lab

wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)

We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person

It's a virtual address so it depends on the value of CONFIG_KERNEL_START
as to whether this is a user program address or not.

Shouldn't it be PAGE_OFFSET ? I mean, CONFIG_KERNEL_START should work
on powerpc, but still...

Ben.

On (05/02/08 11:01), Benjamin Herrenschmidt didst pronounce:

quoted

It's a virtual address so it depends on the value of CONFIG_KERNEL_START
as to whether this is a user program address or not.

Shouldn't it be PAGE_OFFSET ? I mean, CONFIG_KERNEL_START should work
on powerpc, but still...

mel@arnold:~/git/linux-2.6$ grep PAGE_OFFSET include/asm-ppc/page.h
#define PAGE_OFFSET     CONFIG_KERNEL_START

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab

On Tue, 2008-02-05 at 10:23 +0000, Mel Gorman wrote:

On (05/02/08 11:01), Benjamin Herrenschmidt didst pronounce:

quoted

quoted

It's a virtual address so it depends on the value of CONFIG_KERNEL_START
as to whether this is a user program address or not.

Shouldn't it be PAGE_OFFSET ? I mean, CONFIG_KERNEL_START should work
on powerpc, but still...

mel@arnold:~/git/linux-2.6$ grep PAGE_OFFSET include/asm-ppc/page.h
#define PAGE_OFFSET     CONFIG_KERNEL_START

On powerpc sure.... but it's still dodgy I think.

Ben.