Re: [Bugme-new] [Bug 5026] New: Kernel doesn't handle Memory Hole Remapping without a mem= option

Re: [Bugme-new] [Bug 5026] New: Kernel doesn't handle Memory Hole Remapping without a mem= option

[Andrew Morton]

bugme-daemon@kernel-bugs.osdl.org wrote:
>
> http://bugzilla.kernel.org/show_bug.cgi?id=5026
> 
>            Summary: Kernel doesn't handle Memory Hole Remapping without a
>                     mem= option
>     Kernel Version: All
>             Status: NEW
>           Severity: normal
>              Owner: akpm@osdl.org
>          Submitter: bjrosen@polybus.com
> 
> 
> Most recent kernel where this bug did not occur:2.6.13.rc3
> Distribution:Fedora Core 3
> Hardware Environment:Athlon 64 X2 4400+, MSI K8N Neo 4 (Nforce 4), 4G DDR
> Software Environment:
> Problem Description:
> 
> On Athlon 64 systems with Nforce chipsets the chipset is mapped into the upper
> part of the first 4G of physical memory space which means that the BIOS can't
> map 4G into the lower 4G of space. The BIOS on the MSI K8N motherboards (I have
> the Neo2 and the Neo4, both do the same thing) has an option called Memory Hole
> Remapping. When enabled the BIOS sees all 4G. However the Linux kernel will
> panic with this option unless there is a mem= boot option. With mem=5G the
> kernel will see all 4G of memory. With mem=4G it sees only 3G. I've tried this
> with both 32 bit highmem and 64 bit kernels, the behavior is identical. With the
> following line in grub.conf the kernel boots fine and recognizes all 4G of RAM.
> 
> kernel /boot/vmlinuz-2.6.11.12BigMem ro root=LABEL=/ mem=5G rhgb quiet
> 
> This is a bit of a kludge, the kernel ought to be able to handle memory hoisting
> automatically.
> 
> Here is the dmseg info from my system,
> Linux version 2.6.11.12BigMem (root@nimitz.bjrosen.com) (gcc version 3.4.4
> 20050721 (Red Hat 3.4.4-2)) #2 SMP Sat Aug 6 09:20:51 EDT 2005
> BIOS-provided physical RAM map:
>  BIOS-e820: 0000000000000000 - 000000000009f400 (usable)
>  BIOS-e820: 000000000009f400 - 00000000000a0000 (reserved)
>  BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
>  BIOS-e820: 0000000000100000 - 00000000bfff0000 (usable)
>  BIOS-e820: 00000000bfff0000 - 00000000bfff3000 (ACPI NVS)
>  BIOS-e820: 00000000bfff3000 - 00000000c0000000 (ACPI data)
>  BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved)
>  BIOS-e820: 00000000fec00000 - 0000000100000000 (reserved)
>  BIOS-e820: 0000000100000000 - 0000000140000000 (usable)
> user-defined physical RAM map:
>  user: 0000000000000000 - 000000000009f400 (usable)
>  user: 000000000009f400 - 00000000000a0000 (reserved)
>  user: 00000000000f0000 - 0000000000100000 (reserved)
>  user: 0000000000100000 - 00000000bfff0000 (usable)
>  user: 00000000bfff0000 - 00000000bfff3000 (ACPI NVS)
>  user: 00000000bfff3000 - 00000000c0000000 (ACPI data)
>  user: 00000000e0000000 - 00000000f0000000 (reserved)
>  user: 00000000fec00000 - 0000000100000000 (reserved)
>  user: 0000000100000000 - 0000000140000000 (usable)
> 4224MB HIGHMEM available.
> 896MB LOWMEM available.
> found SMP MP-table at 000f5300
> NX (Execute Disable) protection: active
> On node 0 totalpages: 1310720
>   DMA zone: 4096 pages, LIFO batch:1
>   Normal zone: 225280 pages, LIFO batch:16
>   HighMem zone: 1081344 pages, LIFO batch:16
> 

Does someone have time to look into this please?
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>