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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20080205231701.220630@gmx.net>
Date:	Wed, 06 Feb 2008 00:17:01 +0100
From:	"Gerhard Pircher" <gerhard_pircher@....net>
To:	benh@...nel.crashing.org
Cc:	linux-kernel@...r.kernel.org, linuxppc-dev@...abs.org,
	mel@....ul.ie
Subject: 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 <benh@...nel.crashing.org>
> An: Gerhard Pircher <gerhard_pircher@....net>
> CC: Mel Gorman <mel@....ul.ie>, linux-kernel@...r.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@....ul.ie>
> > > An: Gerhard Pircher <gerhard_pircher@....net>
> > > CC: linux-kernel@...r.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

Download attachment "kernel-highmem.log" of type "application/octet-stream" (14093 bytes)

View attachment "kernel-nohighmem.log" of type "text/x-log" (5709 bytes)

View attachment "kernel-debugpagealloc.log" of type "text/x-log" (1101 bytes)

View attachment "kernel-pages_at_lower_pfns.log" of type "text/x-log" (43294 bytes)

View attachment "kernel-oopsmemoption.log" of type "text/x-log" (7438 bytes)

Download attachment "patch_amigaone_platform" of type "application/octet-stream" (21311 bytes)