Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760117Ab2J2Q6a (ORCPT ); Mon, 29 Oct 2012 12:58:30 -0400 Received: from mail.kernel.org ([198.145.19.201]:34755 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751486Ab2J2Q61 (ORCPT ); Mon, 29 Oct 2012 12:58:27 -0400 Date: Mon, 29 Oct 2012 09:58:23 -0700 From: Greg Kroah-Hartman To: Jacob Shin Cc: Ben Hutchings , Mark Lord , Yinghai Lu , Willy Tarreau , stable@vger.kernel.org, Linus Torvalds , Linux Kernel , "H. Peter Anvin" Subject: Re: Regression from 3.4.9 to 3.4.16 "stable" kernel Message-ID: <20121029165823.GA6614@kroah.com> References: <508E002B.4090200@teksavvy.com> <20121029064643.GE574@1wt.eu> <508E913D.2080104@teksavvy.com> <1351521658.13356.7.camel@deadeye.wl.decadent.org.uk> <20121029144722.GA23217@jshin-Toonie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20121029144722.GA23217@jshin-Toonie> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4173 Lines: 105 On Mon, Oct 29, 2012 at 09:47:22AM -0500, Jacob Shin wrote: > On Mon, Oct 29, 2012 at 02:40:58PM +0000, Ben Hutchings wrote: > > On Mon, 2012-10-29 at 10:22 -0400, Mark Lord wrote: > > > On 12-10-29 02:46 AM, Willy Tarreau wrote: > > > > On Mon, Oct 29, 2012 at 12:03:55AM -0400, Mark Lord wrote: > > > >> My server here runs the 3.4.xx series of "stable" kernels. > > > >> Until today, it was running 3.4.9. > > > >> Today I tried to upgrade it to 3.4.16. > > > >> It hangs in setup.c. > > > >> > > > >> I've isolated the fault down to this specific change > > > >> that was made between 3.4.9 and 3.4.16. > > > >> Reverting this change allows the system to boot/run normally again. > > > >> > > > >> > > > >> --- linux-3.4.9/arch/x86/kernel/setup.c 2012-08-15 11:17:17.000000000 -0400 > > > >> +++ linux-3.4.16/arch/x86/kernel/setup.c 2012-10-28 13:36:33.000000000 -0400 > > > >> @@ -927,8 +927,21 @@ > > > >> > > > >> #ifdef CONFIG_X86_64 > > > >> if (max_pfn > max_low_pfn) { > > > >> - max_pfn_mapped = init_memory_mapping(1UL<<32, > > > >> - max_pfn< > > >> + int i; > > > >> + for (i = 0; i < e820.nr_map; i++) { > > > >> + struct e820entry *ei = &e820.map[i]; > > > >> + > > > >> + if (ei->addr + ei->size <= 1UL << 32) > > > >> + continue; > > > >> + > > > >> + if (ei->type == E820_RESERVED) > > > >> + continue; > > > >> + > > > >> + max_pfn_mapped = init_memory_mapping( > > > >> + ei->addr < 1UL << 32 ? 1UL << 32 : ei->addr, > > > >> + ei->addr + ei->size); > > > >> + } > > > >> + > > > >> /* can we preseve max_low_pfn ?*/ > > > >> max_low_pfn = max_pfn; > > > >> } > > > > > > > > For the record, it is this commit introduced in 3.4.16 : > > > > > > > > commit efd5fa0c1a1d1b46846ea6e8d1a783d0d8a6a721 > > > > Author: Jacob Shin > > > > Date: Thu Oct 20 16:15:26 2011 -0500 > > > > > > > > x86: Exclude E820_RESERVED regions and memory holes above 4 GB from direct mapping. > > > > > > > > commit 1bbbbe779aabe1f0768c2bf8f8c0a5583679b54a upstream. > > > > > > > > On systems with very large memory (1 TB in our case), BIOS may report a > > > > reserved region or a hole in the E820 map, even above the 4 GB range. Exclude > > > > these from the direct mapping. > > > > > > > > [ hpa: this should be done not just for > 4 GB but for everything above the legacy > > > > region (1 MB), at the very least. That, however, turns out to require significant > > > > restructuring. That work is well underway, but is not suitable for rc/stable. ] > > > > > > > > Signed-off-by: Jacob Shin > > > > Link: http://lkml.kernel.org/r/1319145326-13902-1-git-send-email-jacob.shin@amd.com > > > > Signed-off-by: H. Peter Anvin > > > > Signed-off-by: Greg Kroah-Hartman > > > > > > > > Willy > > > > > > > > > Thanks, Willy. > > > > > > I've also now downloaded linux-3.7.0-rc3, and it boots/runs without need for patching. > > > So there's a fix somewhere in between that perhaps could also get backported to -stable. > > > > Might well be: > > > > commit 1f2ff682ac951ed82cc043cf140d2851084512df > > Author: Yinghai Lu > > Date: Mon Oct 22 16:35:18 2012 -0700 > > > > x86, mm: Use memblock memory loop instead of e820_RAM > > > > However I'm not sure that this loop is correct either. Yinghai, does > > your version definitely iterate in increasing pfn order? If not then > > the max_pfn_mapped assignment must be conditional. > > Hi, I believe these two commits in mainline should fix Alexander's failing > machien: > > 844ab6f993b1d32eb40512503d35ff6ad0c57030 > f82f64dd9f485e13f29f369772d4a0e868e5633a > > This thread has some more details: > > https://lkml.org/lkml/2012/10/21/157 > > Sorry, and thanks! Thanks, I've queued these up now. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/