Thread (14 messages) 14 messages, 6 authors, 2012-10-30

Re: Regression from 3.4.9 to 3.4.16 "stable" kernel

From: Ben Hutchings <hidden>
Date: 2012-10-29 14:41:21
Also in: lkml

On Mon, 2012-10-29 at 10:22 -0400, Mark Lord wrote:
On 12-10-29 02:46 AM, Willy Tarreau wrote:
quoted
On Mon, Oct 29, 2012 at 12:03:55AM -0400, Mark Lord wrote:
quoted
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<<PAGE_SHIFT);
+		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 [off-list ref]
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 [off-list ref]
    Link: http://lkml.kernel.org/r/1319145326-13902-1-git-send-email-jacob.shin@amd.com
    Signed-off-by: H. Peter Anvin [off-list ref]
    Signed-off-by: Greg Kroah-Hartman [off-list ref]

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 [off-list ref]
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.

Ben.

-- 
Ben Hutchings
Humans are not rational beings; they are rationalising beings.

Attachments

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help