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

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

Datum: Tue, 05 Feb 2008 11:06:36 +1100
Von: Benjamin Herrenschmidt [off-list ref]
An: Gerhard Pircher [off-list ref]
CC: Mel Gorman <redacted>, linux-kernel@vger.kernel.org
Betreff: Re: Commit for mm/page_alloc.c breaks boot process on my machine

On Fri, 2008-02-01 at 21:05 +0100, Gerhard Pircher wrote:

quoted

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

quoted

Datum: Fri, 1 Feb 2008 19:11:19 +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

quoted

With this patch, early boot would use pages from lower PFNs. Without
the patch, it would use memory from higher PFNs. That is the only
real difference.

1. Is there any chance that all of your memory is not being properly
   initialised?

Do you mean uninitialized hardware? That shouldn't be a problem, since
older kernels (e.g. 2.6.19 with platform patches for arch/ppc) are
running fine.

No, it looks more to me like you aren't properly defining the available
memory somewhere, or along those lines. Are you using CONFIG_HIGHMEM ? I
think there have been some issues until recent patches from Kumar, if
you try to reserve memory in the highmem region (though that may not be
your problem).

As far as I can see, the U-boot bootwrapper enters the correct size for
the available system memory. Also the memory zone initialization looks
reasonable to me (768 MB in DMA zone and 768 MB in HIGHMEM zone - it's a
G4 machine with 1.5GB RAM).
I compiled kernels (v2.6.24) with and without highmem. The attached
logfiles (kernel-[no]highmem.log) indicate that this doesn't seem to be
the problem.
The kernel boots fine until loading INIT, if it is compiled with this
patch (IIRC commited for 2.6.24-rc2, reverted for 2.6.24):
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=5adc5be7cd1bcef6bb64f5255d2a33f20a3cf5be
(see logfile kernel-pages_at_lower_pfns.log)

Or maybe you are colliding with some of the non-coherent hacks ?

Yes, the AmigaOne platform code makes use of the non coherent DMA
implementation, but that seems to be working just fine. I compiled a
kernel without non coherent DMA support and it died during the boot
process, too.

quoted

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.

Have you tried DEBUG_PAGEALLOC ? It might fault earlier which might give
us better informations. Also, a stactrace from the oops might be useful,
along with a copy of your device-tree.

Yes, I attached the log file for a kernel compiled with DEBUG_PAGEALLOC.
But I'm afraid it doesn't contain useful information, because the log is
even more distorted.

The oops only happend when using the "mem" boot option. The
kernel-oopsmemoption.log attachment should show the stack trace.

I really wonder why the kernel log buffer gets distorted. I only
experienced this with newer kernels (>2.6.23). Note that I haven't tested
older versions (2.6.20-2.6.22).

I included the AmigaOne platform patch (device tree, setup code). The
platform setup code clears the CPU_FTR_NEED_COHERENT flag for G4 cpus and
disables the L2 cache prefetch to workaround a cpu and northbridge bug.
This workaround worked with all 2.6.x kernels so far.

Thanks!

Gerhard
-- 
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! 
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer