x86: Regression in 3.6.4, bisected to "Exclude E820_RESERVED regions..."

DISCUSSION Alexander Holler 2 participants 8 messages Oct 29, 2012 – Oct 30, 2012

Subsystems (2)

x86 x86 MM

lore

Share & tools

lore

Alexander Holler

author

2012-10-29 10:23 UTC #0 lore raw

Hello,

I've just bisected a problem with 3.6.4.

I had to revert commit 54ce8ce298f382a06186cb4672ad6aa090b050b6 (1bbbbe779aabe1f0768c2bf8f8c0a5583679b54a in mainline), otherwise my box didn't boot.

I can't provide any output, because I don't see if that commit is applied. ;)

Here is the start of the dmesg with the memory map (with the above commit reverted):

-------------

[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Linux version 3.6.4-00001-gcccc924 ([email protected]) (gcc version 4.7.2 20120921 (Red Hat 4.7.2-2) (GCC) ) #258 SMP Mon Oct 29 11:08:32 CET 2012
[    0.000000] Command line: ro root=/dev/sdb2 rootfstype=ext4 enforcing=0 cgroup_disable=memory vga=0x346 video=vesafb:mtrr:3,ywrap radeon.modeset=0
[    0.000000] KERNEL supported cpus:
[    0.000000]   AMD AuthenticAMD
[    0.000000] e820: BIOS-provided physical RAM map:
[    0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009e7ff] usable
[    0.000000] BIOS-e820: [mem 0x000000000009e800-0x000000000009ffff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000000e0000-0x00000000000fffff] reserved
[    0.000000] BIOS-e820: [mem 0x0000000000100000-0x000000009d7cafff] usable
[    0.000000] BIOS-e820: [mem 0x000000009d7cb000-0x000000009dd6afff] reserved
[    0.000000] BIOS-e820: [mem 0x000000009dd6b000-0x000000009dd7afff] ACPI data
[    0.000000] BIOS-e820: [mem 0x000000009dd7b000-0x000000009e0e6fff] ACPI NVS
[    0.000000] BIOS-e820: [mem 0x000000009e0e7000-0x000000009e669fff] reserved
[    0.000000] BIOS-e820: [mem 0x000000009e66a000-0x000000009e66afff] usable
[    0.000000] BIOS-e820: [mem 0x000000009e66b000-0x000000009e870fff] ACPI NVS
[    0.000000] BIOS-e820: [mem 0x000000009e871000-0x000000009ec8ffff] usable
[    0.000000] BIOS-e820: [mem 0x000000009ec90000-0x000000009eff3fff] reserved
[    0.000000] BIOS-e820: [mem 0x000000009eff4000-0x000000009effffff] usable
[    0.000000] BIOS-e820: [mem 0x00000000fec00000-0x00000000fec00fff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000fec10000-0x00000000fec10fff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000fed00000-0x00000000fed00fff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000fed40000-0x00000000fed44fff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000fed80000-0x00000000fed8ffff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000ff000000-0x00000000ffffffff] reserved
[    0.000000] BIOS-e820: [mem 0x0000000100001000-0x00000001beffffff] usable
[    0.000000] NX (Execute Disable) protection: active
[    0.000000] DMI 2.7 present.
[    0.000000] DMI: System manufacturer System Product Name/F2A85-M, BIOS 5103 09/19/2012
[    0.000000] e820: update [mem 0x00000000-0x00000fff] usable ==> reserved
[    0.000000] e820: remove [mem 0x000a0000-0x000fffff] usable
[    0.000000] No AGP bridge found
[    0.000000] e820: last_pfn = 0x1bf000 max_arch_pfn = 0x400000000
[    0.000000] MTRR default type: uncachable
[    0.000000] MTRR fixed ranges enabled:
[    0.000000]   00000-9FFFF write-back
[    0.000000]   A0000-BFFFF write-through
[    0.000000]   C0000-CFFFF write-protect
[    0.000000]   D0000-E7FFF uncachable
[    0.000000]   E8000-FFFFF write-protect
[    0.000000] MTRR variable ranges enabled:
[    0.000000]   0 base 000000000000 mask FFFF80000000 write-back
[    0.000000]   1 base 000080000000 mask FFFFE0000000 write-back
[    0.000000]   2 base 00009F000000 mask FFFFFF000000 uncachable
[    0.000000]   3 disabled
[    0.000000]   4 disabled
[    0.000000]   5 disabled
[    0.000000]   6 disabled
[    0.000000]   7 disabled
[    0.000000] TOM2: 00000001bf000000 aka 7152M
[    0.000000] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
[    0.000000] e820: update [mem 0x9f000000-0xffffffff] usable ==> reserved
[    0.000000] e820: last_pfn = 0x9f000 max_arch_pfn = 0x400000000
[    0.000000] initial memory mapped: [mem 0x00000000-0x1fffffff]
[    0.000000] Base memory trampoline at [ffff880000098000] 98000 size 24576
[    0.000000] Using GB pages for direct mapping
[    0.000000] init_memory_mapping: [mem 0x00000000-0x9effffff]
[    0.000000]  [mem 0x00000000-0x7fffffff] page 1G
[    0.000000]  [mem 0x80000000-0x9effffff] page 2M
[    0.000000] kernel direct mapping tables up to 0x9effffff @ [mem 0x1fbfe000-0x1fffffff]
[    0.000000] init_memory_mapping: [mem 0x100000000-0x1beffffff]
[    0.000000]  [mem 0x100000000-0x17fffffff] page 1G
[    0.000000]  [mem 0x180000000-0x1beffffff] page 2M
[    0.000000] kernel direct mapping tables up to 0x1beffffff @ [mem 0x9effe000-0x9effffff]
[    0.000000] ACPI: RSDP 00000000000f0490 00024 (v02 ALASKA)

...
-------------

If I can help more, just ask.

Regards,

Alexander

Don't ask me, why some lines are twice there. I assume it's because I have earlycon and earlyprintk enabled in the command line. I've never used the serial before to debug a kernel on x86, I just have experience debugging ARMs using the serial. ;)

Regards,

Alexander

Greg Kroah-Hartman

2012-10-29 16:59 UTC #2 lore raw

Quoted 9 lines · Alexander Holler

Am 29.10.2012 11:22, schrieb Alexander Holler:
Quoted 8 lines
Hello,
I've just bisected a problem with 3.6.4.
I had to revert commit 54ce8ce298f382a06186cb4672ad6aa090b050b6 (1bbbbe779aabe1f0768c2bf8f8c0a5583679b54a in mainline), otherwise my box didn't boot.

Quoted 5 lines

Quoted 2 lines
I can't provide any output, because I don't see if that commit is applied. ;)
That sentence missed an 'any'. But I've now attached a serial, here is the output:

Thanks for this, it should be fixed in the next 3.6.y release, we needed to add two more commits from upstream:

	844ab6f993b1d32eb40512503d35ff6ad0c57030
	f82f64dd9f485e13f29f369772d4a0e868e5633a

If you apply those two, and it doesn't solve the problem for you, please let us know.

thanks,

greg k-h

Alexander Holler

author

2012-10-29 18:11 UTC #3 lore raw

Am 29.10.2012 17:59, schrieb Greg Kroah-Hartman:

Quoted 16 lines · Alexander Holler

Quoted 9 lines
Am 29.10.2012 11:22, schrieb Alexander Holler:
Quoted 8 lines
Hello,
I've just bisected a problem with 3.6.4.
I had to revert commit 54ce8ce298f382a06186cb4672ad6aa090b050b6 (1bbbbe779aabe1f0768c2bf8f8c0a5583679b54a in mainline), otherwise my box didn't boot.
Quoted 5 lines
Quoted 2 lines
I can't provide any output, because I don't see if that commit is applied. ;)
That sentence missed an 'any'. But I've now attached a serial, here is the output:

Quoted 6 lines

Thanks for this, it should be fixed in the next 3.6.y release, we needed to add two more commits from upstream:
	844ab6f993b1d32eb40512503d35ff6ad0c57030
	f82f64dd9f485e13f29f369772d4a0e868e5633a
If you apply those two, and it doesn't solve the problem for you, please let us know.

They don't applied cleanly, but after fixing the conflicts it seem's to work.

Of course, I don't know the difference with applying those two commits or reverting the commit in 3.6.4, but I assume it's better to add the two instead of reverting the one (I'm currently to lazy to read and understand the commit-messages). ;)

Thanks,

Alexander

Greg Kroah-Hartman

2012-10-29 18:32 UTC #4 lore raw

Quoted 24 lines · Alexander Holler

Am 29.10.2012 17:59, schrieb Greg Kroah-Hartman:
Quoted 16 lines · Alexander Holler
Quoted 9 lines
Am 29.10.2012 11:22, schrieb Alexander Holler:
Quoted 8 lines
Hello,
I've just bisected a problem with 3.6.4.
I had to revert commit 54ce8ce298f382a06186cb4672ad6aa090b050b6 (1bbbbe779aabe1f0768c2bf8f8c0a5583679b54a in mainline), otherwise my box didn't boot.
Quoted 5 lines
Quoted 2 lines
I can't provide any output, because I don't see if that commit is applied. ;)
That sentence missed an 'any'. But I've now attached a serial, here is the output:
Quoted 6 lines
Thanks for this, it should be fixed in the next 3.6.y release, we needed to add two more commits from upstream:
	844ab6f993b1d32eb40512503d35ff6ad0c57030
	f82f64dd9f485e13f29f369772d4a0e868e5633a
If you apply those two, and it doesn't solve the problem for you, please let us know.

Quoted 2 lines

They don't applied cleanly, but after fixing the conflicts it seem's to work.

The conflict was in the printk, right? I fixed that up in the 3.4 stable tree.

Quoted 4 lines

Of course, I don't know the difference with applying those two commits or reverting the commit in 3.6.4, but I assume it's better to add the two instead of reverting the one (I'm currently to lazy to read and understand the commit-messages). ;)

Fixing problems is good :)

greg k-h

Alexander Holler

author

2012-10-29 19:54 UTC #5 lore raw

Am 29.10.2012 19:32, schrieb Greg Kroah-Hartman:

Quoted 25 lines · Alexander Holler

Quoted 24 lines
Am 29.10.2012 17:59, schrieb Greg Kroah-Hartman:
Quoted 22 lines · Alexander Holler
Quoted 9 lines
Am 29.10.2012 11:22, schrieb Alexander Holler:
Quoted 8 lines
Hello,
I've just bisected a problem with 3.6.4.
I had to revert commit 54ce8ce298f382a06186cb4672ad6aa090b050b6 (1bbbbe779aabe1f0768c2bf8f8c0a5583679b54a in mainline), otherwise my box didn't boot.
Quoted 5 lines
Quoted 2 lines
I can't provide any output, because I don't see if that commit is applied. ;)
That sentence missed an 'any'. But I've now attached a serial, here is the output:
Thanks for this, it should be fixed in the next 3.6.y release, we needed to add two more commits from upstream:
	844ab6f993b1d32eb40512503d35ff6ad0c57030
	f82f64dd9f485e13f29f369772d4a0e868e5633a
If you apply those two, and it doesn't solve the problem for you, please let us know.

Quoted 5 lines

Quoted 2 lines
They don't applied cleanly, but after fixing the conflicts it seem's to work.
The conflict was in the printk, right? I fixed that up in the 3.4 stable tree.

No, I've come up with that on top of 3.6.4:

-----------------

arch/x86/mm/init.c +29 ~~-25~~

index ab1f6a9..d7aea41 100644
@@ -35,40 +35,44 @@ struct map_range {
 	unsigned page_size_mask;
 };
 
-static void __init find_early_table_space(struct map_range *mr, unsigned long end,
-					  int use_pse, int use_gbpages)
+/*
+ * First calculate space needed for kernel direct mapping page tables to cover
+ * mr[0].start to mr[nr_range - 1].end, while accounting for possible 2M and 1GB
+ * pages. Then find enough contiguous space for those page tables.
+ */
+static void __init find_early_table_space(struct map_range *mr, int nr_range)
 {
-	unsigned long puds, pmds, ptes, tables, start = 0, good_end = end;
+	int i;
+	unsigned long puds = 0, pmds = 0, ptes = 0, tables;
+	unsigned long start = 0, good_end;
 	phys_addr_t base;
 
-	puds = (end + PUD_SIZE - 1) >> PUD_SHIFT;
-	tables = roundup(puds * sizeof(pud_t), PAGE_SIZE);
-
-	if (use_gbpages) {
-		unsigned long extra;
-
-		extra = end - ((end>>PUD_SHIFT) << PUD_SHIFT);
-		pmds = (extra + PMD_SIZE - 1) >> PMD_SHIFT;
-	} else
-		pmds = (end + PMD_SIZE - 1) >> PMD_SHIFT;
+	for (i = 0; i < nr_range; i++) {
+		unsigned long range, extra;
 
-	tables += roundup(pmds * sizeof(pmd_t), PAGE_SIZE);
+		range = mr[i].end - mr[i].start;
+		puds += (range + PUD_SIZE - 1) >> PUD_SHIFT;
 
-	if (use_pse) {
-		unsigned long extra;
+		if (mr[i].page_size_mask & (1 << PG_LEVEL_1G)) {
+			extra = range - ((range >> PUD_SHIFT) << PUD_SHIFT);
+			pmds += (extra + PMD_SIZE - 1) >> PMD_SHIFT;
+		} else {
+			pmds += (range + PMD_SIZE - 1) >> PMD_SHIFT;
+		}
 
-		extra = end - ((end>>PMD_SHIFT) << PMD_SHIFT);
+		if (mr[i].page_size_mask & (1 << PG_LEVEL_2M)) {
+			extra = range - ((range >> PMD_SHIFT) << PMD_SHIFT);
 #ifdef CONFIG_X86_32
-		extra += PMD_SIZE;
+			extra += PMD_SIZE;
 #endif
-		/* The first 2/4M doesn't use large pages. */
-		if (mr->start < PMD_SIZE)
-			extra += mr->end - mr->start;
-
-		ptes = (extra + PAGE_SIZE - 1) >> PAGE_SHIFT;
-	} else
-		ptes = (end + PAGE_SIZE - 1) >> PAGE_SHIFT;
+			ptes += (extra + PAGE_SIZE - 1) >> PAGE_SHIFT;
+		} else {
+			ptes += (range + PAGE_SIZE - 1) >> PAGE_SHIFT;
+		}
+	}
 
+	tables = roundup(puds * sizeof(pud_t), PAGE_SIZE);
+	tables += roundup(pmds * sizeof(pmd_t), PAGE_SIZE);
 	tables += roundup(ptes * sizeof(pte_t), PAGE_SIZE);
 
 #ifdef CONFIG_X86_32

@@ -86,7 +90,7 @@ static void __init find_early_table_space(struct map_range *mr, unsigned long en
 	pgt_buf_top = pgt_buf_start + (tables >> PAGE_SHIFT);
 
 	printk(KERN_DEBUG "kernel direct mapping tables up to %#lx @ [mem

%#010lx-%#010lx]\n",
- end - 1, pgt_buf_start << PAGE_SHIFT,
+ mr[nr_range - 1].end - 1, pgt_buf_start << PAGE_SHIFT,
(pgt_buf_top << PAGE_SHIFT) - 1);
}

@@ -267,7 +271,7 @@ unsigned long __init_refok init_memory_mapping(unsigned long start,
* nodes are discovered.
*/
if (!after_bootmem)
- find_early_table_space(&mr[0], end, use_pse, use_gbpages);
+ find_early_table_space(mr, nr_range);

for (i = 0; i < nr_range; i++)
ret = kernel_physical_mapping_init(mr[i].start, mr[i].end,
-----------------

Quoted 1 line

Fixing problems is good :)

At least better than creating them. ;)

Regards,

Alexander

Greg Kroah-Hartman

2012-10-29 23:01 UTC #6 lore raw

Quoted 26 lines · Alexander Holler

Am 29.10.2012 19:32, schrieb Greg Kroah-Hartman:
Quoted 25 lines · Alexander Holler
Quoted 24 lines
Am 29.10.2012 17:59, schrieb Greg Kroah-Hartman:
Quoted 22 lines · Alexander Holler
Quoted 9 lines
Am 29.10.2012 11:22, schrieb Alexander Holler:
Quoted 8 lines
Hello,
I've just bisected a problem with 3.6.4.
I had to revert commit 54ce8ce298f382a06186cb4672ad6aa090b050b6 (1bbbbe779aabe1f0768c2bf8f8c0a5583679b54a in mainline), otherwise my box didn't boot.
Quoted 5 lines
Quoted 2 lines
I can't provide any output, because I don't see if that commit is applied. ;)
That sentence missed an 'any'. But I've now attached a serial, here is the output:
Thanks for this, it should be fixed in the next 3.6.y release, we needed to add two more commits from upstream:
	844ab6f993b1d32eb40512503d35ff6ad0c57030
	f82f64dd9f485e13f29f369772d4a0e868e5633a
If you apply those two, and it doesn't solve the problem for you, please let us know.

Quoted 7 lines

Quoted 5 lines
Quoted 2 lines
They don't applied cleanly, but after fixing the conflicts it seem's to work.
The conflict was in the printk, right? I fixed that up in the 3.4 stable tree.
No, I've come up with that on top of 3.6.4:

Really? That's odd.

Can you test out 3.6.5-rc1 and see if that works properly for you or not? It should have all of the fixes in it already.

thanks,

greg k-h

Alexander Holler

author

2012-10-30 01:53 UTC #7 lore raw

Am 30.10.2012 00:01, schrieb Greg Kroah-Hartman:

Quoted 2 lines

Can you test out 3.6.5-rc1 and see if that works properly for you or not? It should have all of the fixes in it already.

Just in time before I receive my new "memory layout" which might not have the problem with 3.6.4. ;)

3.6.5-rc1 booted just fine, thanks a lot.

Regards,

Alexander