memtest86+: does not work: wouldn't fit into memory

[Debian Bug Importer]

Automatically imported from Debian bug report #319837 http://bugs.debian.org/319837

[Debian Bug Importer (debzilla)]

Automatically imported from Debian bug report #319837 http://bugs.debian.org/319837

[Debian Bug Importer (debzilla)]

Message-Id: <email address hidden>
Date: Mon, 25 Jul 2005 12:49:04 +0800
From: Paul Wise <email address hidden>
To: Debian Bug Tracking System <email address hidden>
Subject: memtest86+: does not work: wouldn't fit into memory

--=-PmmF0wBHtb85WNKyJBCk
Content-Type: multipart/mixed; boundary="=-EQSWwmPSJyzEJVhKwHqN"

--=-EQSWwmPSJyzEJVhKwHqN
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

Package: memtest86+
Version: 1.60-1
Severity: grave
Justification: renders package unusable

When I boot the memtest86+ entry, I get a message like this:

"Error 28: Selected item cannot fit into memory"

pabs@chianamo:~$ ls -lh /boot/
total 26M
-rw-r--r-- 1 root root 44K 2005-05-16 16:17 config-2.4.27-2-k7
-rw-r--r-- 1 root root 59K 2005-06-21 11:22 config-2.6.11-1-k7
-rw-r--r-- 1 root root 60K 2005-07-21 07:13 config-2.6.12-1-k7
-rw-r--r-- 1 root root 55K 2005-05-19 17:01 config-2.6.8-2-k7
drwxr-xr-x 3 root root 448 2005-07-22 13:19 grub/
-rw-r--r-- 1 root root 3.9M 2005-05-26 09:38 initrd.img-2.4.27-2-k7
-rw-r--r-- 1 root root 4.5M 2005-07-04 19:29 initrd.img-2.6.11-1-k7
-rw-r--r-- 1 root root 4.7M 2005-07-22 13:19 initrd.img-2.6.12-1-k7
-rw-r--r-- 1 root root 4.4M 2005-05-25 15:13 initrd.img-2.6.8-2-k7
-rw-r--r-- 1 root root 97K 2005-06-28 05:29 memtest86+.bin
-rw-r--r-- 1 root root 520K 2005-05-16 16:45 System.map-2.4.27-2-k7
-rw-r--r-- 1 root root 819K 2005-06-21 13:07 System.map-2.6.11-1-k7
-rw-r--r-- 1 root root 850K 2005-07-21 08:40 System.map-2.6.12-1-k7
-rw-r--r-- 1 root root 824K 2005-05-19 17:28 System.map-2.6.8-2-k7
-rw-r--r-- 1 root root 844K 2005-05-16 16:45 vmlinuz-2.4.27-2-k7
-rw-r--r-- 1 root root 1.2M 2005-06-21 13:07 vmlinuz-2.6.11-1-k7
-rw-r--r-- 1 root root 1.3M 2005-07-21 08:39 vmlinuz-2.6.12-1-k7
-rw-r--r-- 1 root root 1.1M 2005-05-19 17:28 vmlinuz-2.6.8-2-k7

pabs@chianamo:~$ cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 6
model : 8
model name : AMD Athlon(TM) XP 1700+
stepping : 1
cpu MHz : 1469.921
cache size : 256 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca =
cmov pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow
bogomips : 2908.16

I presume the error comes from grub. I'm using grub with the debian
automagical stuff. My filesystem is reiserfs. Please let me know if
there is any other info you need. I attached my /boot/grub/menu.lst

-- System Information:
Debian Release: unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.12-1-k7
Locale: LANG=3DC, LC_CTYPE=3DC (charmap=3DANSI_X3.4-1968)

-- no debconf information

--=-EQSWwmPSJyzEJVhKwHqN
Content-Description:
Content-Disposition: inline; filename=menu.lst
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: base64

IyBtZW51LmxzdCAtIFNlZTogZ3J1Yig4KSwgaW5mbyBncnViLCB1cGRhdGUtZ3J1...

[Yann Dirson (dirson)]

# Automatically generated email from bts, devscripts version 2.9.5
 # it does not impact the majority of users
severity 319837 important

[Debian Bug Importer (debzilla)]

Message-Id: <E1EB5yl-0001Z0-Ig@nan92-1-81-57-214-146>
Date: Fri, 2 Sep 2005 09:28:50 +0200
From: Yann Dirson <email address hidden>
To: <email address hidden>
Subject: severity of 319837 is important

# Automatically generated email from bts, devscripts version 2.9.5
 # it does not impact the majority of users
severity 319837 important

[Matt Zimmerman (mdz)]

Have seen other reports of this as well, confirming

[Paul Wise (Debian) (pabs)]

found 319837 1.65-1
forwarded 319837 http://forum.x86-secret.com/showthread.php?p=91223#post91223
thanks

This bug still occurs in the latest version in sid/etch. It would be
nice if it could be fixed for the etch release. Also, I forwarded this
bug upstream for you.

--
bye,
pabs

http://wiki.debian.org/PaulWise

[Paolo Ornati (ornati)]

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://lxr.linux.no/source/Documentation/i386/boot.txt

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 ...

[Paolo Ornati (ornati)]

As a workaround for the memory-testers that cannot wait, just boot it
from a floppy:

1) insert a Floppy
2) cat /boot/memtest86/memtest.bin > /dev/fd0
3) boot from floppy

This will bypass GRUB and overwrite a bit of these "reserved" memory
regions... I don't think this is a problem (it isn't on my machine).

Another source that tells that some of these regions can be overwritten
without problems is the memtest86 README:
 zless /usr/share/doc/memtest86-3.2/README.gz

Probably these tables (etc) are only used by an OS... but since we only
run memtest there's no problem at all.

--
 Paolo Ornati
 Linux 2.6.20-rc2 on x86_64

[Paul Wise (Debian) (pabs)]

owner 215367 !
owner 282313 !
owner 308433 !
owner 322688 !
owner 337074 !
owner 378112 !
submitter 195121 !
submitter 226101 !
submitter 240595 !
submitter 240601 !
submitter 267243 !
submitter 267372 !
submitter 282313 !
submitter 283958 !
submitter 284711 !
submitter 286177 !
submitter 288165 !
submitter 290457 !
submitter 296114 !
submitter 296588 !
submitter 297321 !
submitter 298842 !
submitter 303093 !
submitter 306287 !
submitter 306290 !
submitter 306752 !
submitter 311535 !
submitter 312058 !
submitter 312288 !
submitter 312289 !
submitter 314215 !
submitter 314746 !
submitter 316331 !
submitter 316895 !
submitter 317855 !
submitter 318712 !
submitter 318773 !
submitter 318898 !
submitter 319317 !
submitter 319447 !
submitter 319837 !
submitter 320127 !
submitter 320287 !
submitter 320294 !
submitter 320431 !
submitter 320432 !
submitter 321274 !
submitter 321572 !
submitter 321908 !
submitter 321911 !
submitter 322663 !
submitter 322688 !
submitter 322698 !
submitter 323509 !
submitter 323529 !
submitter 323556 !
submitter 323943 !
submitter 324089 !
submitter 324214 !
submitter 324950 !
submitter 326868 !
submitter 327431 !
submitter 328216 !
submitter 328217 !
submitter 329047 !
submitter 329072 !
submitter 329171 !
submitter 329176 !
submitter 329889 !
submitter 329925 !
submitter 330480 !
submitter 331040 !
submitter 331176 !
submitter 331601 !
submitter 332930 !
submitter 332938 !
submitter 333331 !
submitter 333642 !
submitter 333757 !
submitter 335648 !
submitter 336149 !
submitter 336589 !
submitter 337074 !
submitter 337477 !
submitter 337516 !
submitter 337518 !
submitter 337975 !
submitter 338098 !
submitter 338415 !
submitter 339582 !
submitter 340265 !
submitter 340550 !
submitter 340551 !
submitter 340782 !
submitter 340798 !
submitter 340802 !
submitter 340830 !
submitter 340831 !
submitter 340832 !
submitter 341417 !
submitter 342192 !
submitter 343137 !
submitter 343403 !
submitter 343870 !
submitter 344117 !
submitter 345617 !
submitter 347200 !
submitter 347202 !
submitter 347510 !
submitter 347687 !
submitter 348029 !
submitter 348448 !
submitter 348494 !
submitter 349647 !
submitter 350972 !
submitter 350973 !
submitter 350974 !
submitter 350975 !
submitter 350976 !
submitter 351019 !
submitter 351372 !
submitter 352009 !
submitter 353251 !
submitter 353665 !
submitter 353734 !
submitter 353818 !
submitter 354763 !
submitter 354931 !
submitter 355083 !
submitter 355358 !
submitter 355537 !
submitter 355613 !
submitter 355666 !
submitter 355957 !
submitter 356652 !
submitter 356653 !
submitter 356668 !
submitter 356978 !
submitter 357610 !
submitter 358599 !
submitter 358795 !
submitter 358815 !
submitter 358966 !
submitter 359049 !
submitter 359353 !
submitter 360305 !
submitter 362694 !
submitter 363243 !
submitter 363244 !
submitter 363247 !
submitter 363453 !
submitter 364841 !
submitter 364843 !
submitter 364846 !
submitter 364851 !
submitter 364854 !
submitter 364901 !
submitter 365133 !
submitter 365141 !
submitter 365299 !
submitter 365479 !
submitter 365680 !
submitter 365965 !
submitter 365966 !
submitter 367048 !
submitter 368158 !
submitter 368733 !
submitter 368810 !
submitter 368815 !
submitter 369...

[Rajeev V. Pillai (rajeev-v-pillai)]

I've managed to boot both memtest86 (v3.2) and memtest86+
(v1.65 and v1.70) using grub by following the steps below:

1. Use the ELF executable version of memtest (file memtest)
   instead of the zImage i.e. directly bootable version
   (file memtest.bin).

2. Apply the patch below which changes the load address of
   the ELF executable from 0x10000 to 0x100000. Otherwise,
   grub complains: "Error 7: Loading below 1MB is not supported"

3. Make the binaries as usual by typing `make'.

4. Load the ELF executable memtest like this:

   title Memtest86+ v1.70
       root (hd0,2) # Change this for your setup
       kernel --type=netbsd /boot/memtest

Cheers,
Rajeev

------ Start of Patch ------
diff -urN memtest86+-1.70.orig/memtest.lds memtest86+-1.70/memtest.lds
--- memtest86+-1.70.orig/memtest.lds 2005-09-11 23:47:15.000000000
+0530
+++ memtest86+-1.70/memtest.lds 2006-04-06 11:16:22.089703648 +0530
@@ -3,7 +3,7 @@

 ENTRY(_start);
 SECTIONS {
- . = 0x10000;
+ . = 0x100000;
        _start = . ;
        .data : {
                *(.data)
------ End of Patch ------

____________________________________________________________________________________
Looking for earth-friendly autos?
Browse Top Cars by "Green Rating" at Yahoo! Autos' Green Center.
http://autos.yahoo.com/green_center/

[Paul Wise (Debian) (pabs)]

# Automatically generated email from bts, devscripts version 2.9.27
found 319837 1.70

[Paul Wise (Debian) (pabs)]

clone 319837 -1
reassign -1 memtest86
retitle -1 memtest86: does not work: wouldn't fit into memory
thanks

This bug is also present in memtest86. I've also confirmed that the
patch works for memtest86+, the patch submitter says it is working for
memtest86 too.

--
bye,
pabs

http://wiki.debian.org/PaulWise

[Andrew Brampton (a-brampton)]

This problem still occurs on version 2.01. However the patch suggested
a year ago still works. Perhaps the patch can be taken on by the
memtest86+ developers.

[Paul Wise (Debian) (pabs)]

Version: 2.01-1

Both memtest86 and memtest86+ in sid work for me now.

--
bye,
pabs

http://wiki.debian.org/PaulWise

[Emilio Gallego (egallego-babel)]

reopen 319837
thanks

Hi all!

I'm afraid this bug is not fixed for me, as I keep getting the

"Error 28: Selected item cannot fit into memory"

both with stock memtest86+ and with patched one (lds patch).

I'm running Lenny.

Versions:

ii memtest86+ 2.01-1 thorough real-mode memory tester
ii grub 0.97-47 GRand Unified Bootloader (Legacy version)

Hardware: HP xw6400

iomem:

00000000-00097fff : System RAM
00098000-0009ffff : reserved
000a0000-000bffff : Video RAM area
000c0000-000cddff : Video ROM
000d0800-000d51ff : Adapter ROM
000e8000-000effff : pnp 00:0f
000f0000-000fffff : System ROM
00100000-7ffc2e3f : System RAM
  00100000-002ba032 : Kernel code
  002ba033-0037561f : Kernel data
  003ba000-0041d57f : Kernel bss
7ffc2e40-7fffffff : reserved
e0000000-efffffff : reserved
  e0000000-e7ffffff : PCI MMCONFIG 0
f0000000-f81fffff : PCI Bus 0000:40
  f0000000-f7ffffff : 0000:40:00.0
  f8000000-f801ffff : 0000:40:00.0
f8400000-f8403fff : 0000:00:1b.0
  f8400000-f8403fff : ICH HD audio
f8404000-f84043ff : 0000:00:1d.7
  f8404000-f84043ff : ehci_hcd
f8404400-f84047ff : 0000:00:1f.2
  f8404400-f84047ff : ahci
f9000000-fb1fffff : PCI Bus 0000:40
  f9000000-f9ffffff : 0000:40:00.0
    f9000000-f9ffffff : nvidia
  fa000000-faffffff : 0000:40:00.0
fb200000-fd6fffff : PCI Bus 0000:10
  fb200000-fb9fffff : PCI Bus 0000:1e
    fb400000-fb6fffff : PCI Bus 0000:1f
      fb600000-fb60ffff : 0000:1f:00.0
        fb600000-fb60ffff : tg3
  fd601000-fd601fff : 0000:10:00.3
    fd601000-fd601027 : shpchp
fe000000-fe01ffff : pnp 00:0e
fe600000-fe6fffff : pnp 00:0e
fe700000-fe7003ff : pnp 00:0e
fec00000-ffffffff : reserved
  fed00000-fed003ff : HPET 0

[Paul Wise (Debian) (pabs)]

# Automatically generated email from bts, devscripts version 2.10.35
found 319837 2.01-1

[Adrian Bridgett (adrian-bridgett)]

Not sure why this has been automatically marked as closed - the
changelog mentions nothing.

I had the same issue when I upgraded my PC from 2GB to 4GB.

I followed the workaround and that worked fine. I think this is
worthy of a package with tweaked memtest ELF file and preferably also
a grub entry. I fear that more and more people will be hitting this
problem as they upgrade old boxes to 4GB (pretty sure that's the cause
for me).

Adrian
--
Email: <email address hidden> -*- GPG key available on public key servers
Debian GNU/Linux - the maintainable distribution -*- www.debian.org

[Sebastian Kapfer (caci)]

This is still in hardy. The pre-built ISO image from the upstream website works as expected.

[David Balažic (xerces8)]

I see this with Ubuntu 9.04.

When I select Memtest86+ in the boot menu, I get Error 28: Selected item cannot fit into memory

Tell if more details are needed.

[Felix Zielcke (fzielcke)]

Does this also happen if you boot it with grub2?

[David Balažic (xerces8)]

grub2 did not work on my system, I tried the 9.10 alpha release (dunno which one,it was a month ago).
Don't remember details.
memtest from the livedCD boot menu works, on the other hand.

[Juan Sebastián Marulanda (juanchito2006)]

The issue has persisted for me as of Karmic Alpha 6, in GRUB 2.

[Mantas Kriaučiūnas (mantas)]

AFAIK this bug occurs in computers with more than 1 GB RAM, sometimes bug appears when you add more RAM. I guess, that another reason can be installation of memtest in big hard disks, when memtest86+.bin file is placed not in first partition.

According to email from Debian bugreport this bug can be fixed by using ELF executable version of memtest86 and one-line patch:

From: "Rajeev V. Pillai" <email address hidden>
To: <email address hidden>
Subject: memtest86+: does not work: wouldn't fit into memory [PATCH]
Date: Mon, 5 Feb 2007

I've managed to boot both memtest86 (v3.2) and memtest86+ (v1.65 and v1.70) using grub by following the steps below:

1. Use the ELF executable version of memtest (file memtest)
   instead of the zImage i.e. directly bootable version (file memtest.bin).
2. Apply the patch below which changes 1 line - the load address of
   the ELF executable from 0x10000 to 0x100000. Otherwise,
   grub complains: "Error 7: Loading below 1MB is not supported"
3. Make the binaries as usual by typing `make'.
4. Load the ELF executable memtest like this:

   title Memtest86+ v1.70
       root (hd0,2) # Change this for your setup
       kernel --type=netbsd /boot/memtest

[Martin Wimmer (martin-wimmer)]

Confirming this Problem

Karmic 64bit
4GB RAM
Using LVM for all but the boot partition
As I upgraded from jaunty I still hab grub 1

[Adrian Bridgett (adrian-bridgett)]

FYI I've just tested the new 4.00-2.1 packages and neither the .bin
nor the elf work for me.

bin fails with error: too small lower memory (0x99100 > 0x97c00)
elf (booting as knetbsd) fails with error: Address 0x0 is out of range

elf patched as per Rajeev's notes fails in the same way.

currently I'm running v2 patched as per Rajeev's notes.

4GB core2 duo desktop box FWIW.

Adrian
--
bitcube.co.uk - Expert Linux infrastructure consultancy
Puppet, Debian, Red Hat, Ubuntu, CentOS

[Rajeev V. Pillai (rajeevvp)]

Seeing that this bug is still troubling people, I thought I would
chime in on what does work.

Memtest86+ v4.00 loads and works just fine with GRUB 0.97 on my
machine which is an Asus A7M266-VM motherboard with an Athlon 2 GHz
CPU and 1.2GB RAM. I had to change the load address as described in my
workaround email, though. That original workaround, I posted to the
forum on memtest.org and then to the Debian bug tracker. The forum
was reorganized and the original thread lost. So it looks like
the Debian bug tracker is now the primary source for new information.

Adrian, can you tell me if memtest86+ v4.00 will load with grub 0.97
and/or will load if you reduce the amount of memory on your system?
Both memtest86 and memtest86+ have to be fixed to boot normally with
GRUB, but, we can try to see until then, if workarounds are possible.

BTW, Chris Brady's memtest v3.5 will load on my system with the same
workaround, but it will hang soon after. That might be an unrelated
problem.

gcc-4.x used to be a problem when it came to building from source, as the
memtest.org website said, but it is no longer so with memtest86+ v4.0.
This version I compile using gcc-4.4.2 and it runs all the tests just
fine.

Rajeev

[Graham Inggs (ginggs)]

I have a couple of machines that developed this problem after upgrading from Karmic to Lucid Beta 2.
Lucid 64bit, Intel Core2 Duo, 1GB RAM.

[Graham Inggs (ginggs)]

Running memtest from Lucid livecd works perfectly.
I too am still using grub(1).

[Tech2010 (technologyresearch2010)]

I have this problem with memtest86+.bin and grub1 one under Lucid. Memtest86+.bin is from March 2010.

[Burt P. (pburt0)]

Still exists in Maverick. Also, maverick adds two more memtest options to grub, experimental multiboot, that are also broken, but in a different way; they only see 640K of memory. Anyway, regular memtest still fails to load, new memtest loads but only sees 640K. Now four broken options in default grub menu.

[Graham Inggs (ginggs)]

MIght be fixed in LP: #560839.