Comment 6 for bug 227062
Revision history for this message
| ramuk (kumar-yesitsme) wrote Re: [regression][solved] Error 28: Selected item cannot fit into memory | #6 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
0e1f616
(Get the code!)
Explanation to the above problem found on debian
Problem is not with Grub, it is with Memtest86 Read below. May be someone make a Patch available ASAP. because am not a Programmer
=======
=======
(Bug reported copied from http://
Message #21 received at <email address hidden> (full text, mbox):
From: Paolo Ornati <email address hidden>
To: <email address hidden>
Subject: Not really a BUG...
Date: Mon, 1 Jan 2007 13:55:05 +0100
This is not really a BUG of GRUB... it's just that BIOS tables are
getting bigger!
Memtest86(+) uses the "standard" linux kernel image format, so it it can
be loaded easily by boot loaders such as Lilo and Grub...
The format is:
512 byte of boot sector
512 * X bytes of setup (where X is usually 4)
Y bytes of kernel image
A zImage kernel will be loaded at address 0x10000 (64k) while a bzImage
will be loaded at 0x10000 (1MB).
Memtest uses the old format.
The boot loader also loads a copy of boot sector and setup sectors at
0x90000 (and then execute the setup code):
| |
0A0000 +------
| Reserved for BIOS | Do not use. Reserved for BIOS EBDA.
09A000 +------
| Stack/heap/cmdline | For use by the kernel real-mode code.
098000 +------
| Kernel setup | The kernel real-mode code.
090200 +------
| Kernel boot sector | The kernel legacy boot sector.
090000 +------
| Protected-mode kernel | The bulk of the kernel image.
010000 +------
| Boot loader | <- Boot sector entry point 0000:7C00
001000 +------
| Reserved for MBR/BIOS |
000800 +------
| Typically used by MBR |
000600 +------
| BIOS use only |
000000 +------
For the details read this:
http://
So, basically, this layout assumes that memory up to address 0x9A000 can be used.
The problem is that the newer BIOSes are reserving more and more space
in the top addresses below 640k (low memory), so this layout got
broken... and GRUB cannot do anything about it.
I hit this problem a few days ago switching from an "old" Athlon64
based system to a Core2Duo base one.
If you have an x86_64 system you shold have something like this in the
"dmesg" (it's not printed on x86 if I rember correctly, you can look at
"/proc/iomem" anyway):
[ 0.000000] BIOS-provided physical RAM map:
[ 0.000000] BIOS-e820: 0000000000000000 - 000000000008f000 (usable)
[ 0.000000] BIOS-e820: 000000000008f000 - 00000000000a0000 (reserved)
[ 0.000000] BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
[ 0.000000] BIOS-e820: 0000000000100000 - 000000003e599000 (usable)
[ 0.000000] BIOS-e820: 000000003e599000 - 000000003e5a6000 (reserved)
[ 0.000000] BIOS-e820: 000000003e5a6000 - 000000003e655000 (usable)
[ 0.000000] BIOS-e820: 000000003e655000 - 000000003e6a6000 (ACPI NVS)
[ 0.000000] BIOS-e820: 000000003e6a6000 - 000000003e6ab000 (ACPI data)
[ 0.000000] BIOS-e820: 000000003e6ab000 - 000000003e6ac000 (usable)
[ 0.000000] BIOS-e820: 000000003e6ac000 - 000000003e6f2000 (ACPI NVS)
[ 0.000000] BIOS-e820: 000000003e6f2000 - 000000003e6ff000 (ACPI data)
[ 0.000000] BIOS-e820: 000000003e6ff000 - 000000003e700000 (usable)
[ 0.000000] BIOS-e820: 000000003e700000 - 000000003f000000 (reserved)
[ 0.000000] BIOS-e820: 00000000fff00000 - 0000000100000000 (reserved)
This table is provided by the BIOS and basically tells what memory
regions can or can't be used by the system (because reserved by BIOS,
for example).
The first line tells that, on my system, the limit of usable low memory
is 8f000, which breaks the above layout assumption...
On my Athlon64 based machine (ASUS K8VSE Deluxe) it was 9FC00, and in
fact it worked.
Conclusion: memtest86 should use some other method of loading...
PS: it's a bit odd to have 1GB of memory and read that a <100k thing
"cannot fit into memory" ;)
--
Paolo Ornati
Linux 2.6.20-rc2 on x86_64
(Bug reported copied from http://
=======
=======