linux-kernel - Re: 2.6.23 boot failures on x86-64.

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20071029194311.GE1650@redhat.com>
Date:	Mon, 29 Oct 2007 15:43:11 -0400
From:	Dave Jones <davej@...hat.com>
To:	Andi Kleen <ak@...e.de>
Cc:	Linux Kernel <linux-kernel@...r.kernel.org>,
	Martin Ebourne <fedora@...urne.me.uk>,
	Zou Nan hai <nanhai.zou@...el.com>,
	Suresh Siddha <suresh.b.siddha@...el.com>, stable@...nel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: 2.6.23 boot failures on x86-64.

On Mon, Oct 29, 2007 at 08:03:09PM +0100, Andi Kleen wrote:

 > >  > It's probably the usual "nobody tests sparsemem at all" issue.
 > > 
 > > We've been using SPARSEMEM in Fedora for a *long* time.
 > > So long in fact, I forget why we moved away from DISCONTIGMEM, so there's
 > > a significant number of users using that configuration for some time.
 > 
 > Supposedly you wanted a slower kernel that needs more memory? 
 > 
 > Ok I wasn't aware of that. I tended to get sparsemem reports usually
 > at least 1-2 releases after the fact, so it looked like it was undertested.

Looking at cvs history, I can't figure out what the reasoning was,
but every Fedora (and RHEL5) kernel since 2006/07/05 has been that way.

Curious how no-one noticed either of the side-effects you mention.
 
 > >  > But if allocating bootmem >4G doesn't work on these systems
 > >  > most likely they have more problems anyways. It might be better
 > >  > to find out what goes wrong exactly.
 > > Any ideas on what to instrument ?
 > 
 > See what address the bootmem_alloc_high returns; check if it overlaps
 > with something etc.
 > 
 > Fill the memory on the system and see if it can access all of its memory.

Martin, as you have one of the affected systems, do you feel up to this?

	Dave

-- 
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/