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

[Gerhard Pircher]

-------- Original-Nachricht --------
> Datum: Tue, 05 Feb 2008 11:06:36 +1100
> Von: Benjamin Herrenschmidt <benh at kernel.crashing.org>
> An: Gerhard Pircher <gerhard_pircher at gmx.net>
> CC: Mel Gorman <mel at csn.ul.ie>, linux-kernel at 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:
> > -------- Original-Nachricht --------
> > > Datum: Fri, 1 Feb 2008 19:11:19 +0000
> > > Von: Mel Gorman <mel at csn.ul.ie>
> > > An: Gerhard Pircher <gerhard_pircher at gmx.net>
> > > CC: linux-kernel at vger.kernel.org
> > > Betreff: Re: Commit for mm/page_alloc.c breaks boot process on my
> machine
> > 
> > > 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.

> > > 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kernel-highmem.log
Type: application/octet-stream
Size: 14092 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20080206/e29c8a1b/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kernel-nohighmem.log
Type: text/x-log
Size: 5709 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20080206/e29c8a1b/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kernel-debugpagealloc.log
Type: text/x-log
Size: 1101 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20080206/e29c8a1b/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kernel-pages_at_lower_pfns.log
Type: text/x-log
Size: 43294 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20080206/e29c8a1b/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kernel-oopsmemoption.log
Type: text/x-log
Size: 7438 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20080206/e29c8a1b/attachment-0003.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch_amigaone_platform
Type: application/octet-stream
Size: 21310 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20080206/e29c8a1b/attachment-0001.obj>