Bug 165373 - Kernel can't automatically handle Memory Hole Remapping
Kernel can't automatically handle Memory Hole Remapping
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
3
i686 Linux
medium Severity high
: ---
: ---
Assigned To: Dave Jones
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-08-08 13:48 EDT by Joshua Rosen
Modified: 2015-01-04 17:21 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-08-26 03:12:27 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Joshua Rosen 2005-08-08 13:48:06 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050720 Fedora/1.0.6-1.1.fc3 Firefox/1.0.6

Description of problem:
Athlon 64 systems with Nforce chipsets, at least the MSI K8N Neo2 and Neo4s, can't recognize more than 3.5G of RAM unless the Memory Hole Remapping option is turned on in the BIOS. When this option is enabled the BIOS moves the last gigabyte above 4G. However when this option is enabled the kernel will panic unless there is a mem= on the bootline. The FC3 installer panics for this reason, the simple work around for that is to disable the Memory Hole Remapping option when doing an install. For 4G A64 systems the kernel options line in grub.conf must be set to mem=5G (note that's 5G not 4G),

kernel /boot/vmlinuz-2.6.11.12BigMem ro root=LABEL=/ mem=5G rhgb quiet

The kernel should be able to handle 4G of RAM without a mem= argument,please report this to the appropriate kernel maintainer. In the mean time you need to put something into your installer to work around the problem.

Version-Release number of selected component (if applicable):
All kernels including the latest 2.6.13.rc3

How reproducible:
Always

Steps to Reproduce:
1.Set Memory Hole Remapping in BIOS
2.
3.
  

Actual Results:  Kernel will panic unless you have a mem= on the options line.

Expected Results:  kernel should handle memory hoisting without assistance.

Additional info:

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)
Comment 1 Dave Jones 2005-08-26 03:12:27 EDT
Please report this to the upstream maintainer, at linux-kernel@vger.kernel.org

Note You need to log in before you can comment on or make changes to this bug.