Bug 165373 - Kernel can't automatically handle Memory Hole Remapping
Summary: Kernel can't automatically handle Memory Hole Remapping
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 3
Hardware: i686
OS: Linux
medium
high
Target Milestone: ---
Assignee: Dave Jones
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-08-08 17:48 UTC by Joshua Rosen
Modified: 2015-01-04 22:21 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-08-26 07:12:27 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Joshua Rosen 2005-08-08 17:48:06 UTC
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.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 07:12:27 UTC
Please report this to the upstream maintainer, at linux-kernel.org



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