GRUB4DOS detects only half of my RAM
#1
Posted 14 June 2011 - 07:43 PM
I've tried booting some images to RAM that exceeded 2GB and grub4dos returned that the image was too bog to fit in memory(error #28). I later noticed that the RAM displayed on the top line in grub4dos states that I only have 1762MB of memory. My system has 4GB of RAM and am running XP x64 and Win7 x64 which both detect all of my memory. Besides I have no issues concernig RAM anywhere else. Can anyone shed any light on how to fix this. I'm using the latest build 0.4.4. of grub4dos. I even tried chenall's 0.4.5b build with no change.
Some help please.
#2
Posted 15 June 2011 - 12:18 AM
this is one GUESS - it might have to do with 32 bit "signed" arithmetic, where the max numbers areHi,
I've tried booting some images to RAM that exceeded 2GB and grub4dos returned that the image was too bog to fit in memory(error #28). I later noticed that the RAM displayed on the top line in grub4dos states that I only have 1762MB of memory. My system has 4GB of RAM and am running XP x64 and Win7 x64 which both detect all of my memory. Besides I have no issues concernig RAM anywhere else. Can anyone shed any light on how to fix this. I'm using the latest build 0.4.4. of grub4dos. I even tried chenall's 0.4.5b build with no change.
Some help please.
Postive value: (2 ^ (n -1)) -1 Negative value: - 2 ^ (n-1)and where we have 32 bits to work with...so we get
Max positive value: 2147483647 Max negative value: - 2147483648Or about 2GB give or take a bit for the loader itself...
Another GUESS is what type of "filesystem" are you trying to read from? Maybe you are seeing something related to the internal file system limitations?
Only sure way to know would be to dig into all the code (which is available on-line in a web viewable SVN repository)
#3
Posted 15 June 2011 - 01:20 AM
The NEW code repository is located here:this is one GUESS - it might have to do with 32 bit "signed" arithmetic, where the max numbers are
Postive value: (2 ^ (n -1)) -1 Negative value: - 2 ^ (n-1)and where we have 32 bits to work with...so we getMax positive value: 2147483647 Max negative value: - 2147483648Or about 2GB give or take a bit for the loader itself...
Another GUESS is what type of "filesystem" are you trying to read from? Maybe you are seeing something related to the internal file system limitations?
Only sure way to know would be to dig into all the code (which is available on-line in a web viewable SVN repository)
http://code.google.c...all/source/list
#4
Posted 15 June 2011 - 07:54 AM
Sorry I should have provided more info on my system configuration. I am running a two disk RAID0 (2x320GB) with multiple partitions and all of them are NTFS. Hope someone can provide me with some directions, thanks.
#5
Posted 15 June 2011 - 08:13 AM
Some more info on my system(don't know if it helps). I have an Alienware M17x(R1) with the latest BIOS(ver. A07).
#6
Posted 15 June 2011 - 08:45 AM
The conventional memory is 616K, that probably means the RAID card consumes part of that for the RAID Firmware.
Posting whole output of displaymem here will be good.
#7
Posted 15 June 2011 - 11:04 AM
Here is the displaymem output:
EISA Memory BIOS Interface is present
Address Map BIOS Interface is present
Lower memory: 616K, Upper memory (to first chipset hole: 1832704K)
[Address Range Descriptor entries immediately follow (values are 64-bit)]
Usable RAM: Base Address: 0x0 X 4GB + 0x0,
Length: 0x0 X 4GB + 0x9a000 bytes
Reserved: Base Address: 0x0 X 4GB + 0x9a000,
Length: 0x0 X 4GB + 0x6000 bytes
Reserved: Base Address: 0x0 X 4GB + 0xd0000,
Length: 0x0 X 4GB + 0xc000 bytes
Reserved: Base Address: 0x0 X 4GB + 0xe0000,
Length: 0x0 X 4GB + 0x20000 bytes
Usable RAM: Base Address: 0x0 X 4GB + 0x100000,
Length: 0x0 X 4GB + 0x6fdc0000 bytes
Reserved: Base Address: 0x0 X 4GB + 0x6fec0000,
Length: 0x0 X 4GB + 0x11000 bytes
Reserved: Base Address: 0x0 X 4GB + 0x6fed1000,
Length: 0x0 X 4GB + 0x2000 bytes
Reserved: Base Address: 0x0 X 4GB + 0x6fed3000,
Length: 0x0 X 4GB + 0x2d000 bytes
Reserved: Base Address: 0x0 X 4GB + 0x6ff00000,
Length: 0x0 X 4GB + 0x10000000 bytes
Reserved: Base Address: 0x0 X 4GB + 0x7ff00000,
Length: 0x0 X 4GB + 0x100000 bytes
Reserved: Base Address: 0x0 X 4GB + 0xe0000000,
Length: 0x0 X 4GB + 0x10000000 bytes
Reserved: Base Address: 0x0 X 4GB + 0xfec00000,
Length: 0x0 X 4GB + 0x10000 bytes
Reserved: Base Address: 0x0 X 4GB + 0xfee00000,
Length: 0x0 X 4GB + 0x1000 bytes
Reserved: Base Address: 0x0 X 4GB + 0xfff80000,
Length: 0x0 X 4GB + 0x80000 bytes
Usable RAM: Base Address: 0x1 X 4GB + 0x0,
Length: 0x0 X 4GB + 0x80000000 bytes
Hope this helps.
BTW I noticed that the uppermem command doesn't work in grub4dos, maybe that could've solved something. I crunched some numbers and came with something close to the number of MB that grub reports. If grub is detecting only one stick of memory which is 2048MB, and let's say that the sata/RAID firmware takes up 256MB (which windows 7 reports is the difference between the total and usable memory) the number of MBs left is 1792 which is pretty close to grub's number. Don't know if this means anything.
#8
Posted 15 June 2011 - 01:59 PM
grub4dos-0.4.5b-2010-06-21 is one year old build, please try latest at http://code.google.c...ub4dos-chenall/ instead.I've tried the 0.4.4. 31-Mar-2009 build and the grub4dos-0.4.5b-2010-06-21 from chenall.
Here is the displaymem output:
EISA Memory BIOS Interface is present
Address Map BIOS Interface is present
Lower memory: 616K, Upper memory (to first chipset hole: 1832704K)
[Address Range Descriptor entries immediately follow (values are 64-bit)]
Usable RAM: Base Address: 0x0 X 4GB + 0x0,
Length: 0x0 X 4GB + 0x9a000 bytes
Reserved: Base Address: 0x0 X 4GB + 0x9a000,
Length: 0x0 X 4GB + 0x6000 bytes
Reserved: Base Address: 0x0 X 4GB + 0xd0000,
Length: 0x0 X 4GB + 0xc000 bytes
Reserved: Base Address: 0x0 X 4GB + 0xe0000,
Length: 0x0 X 4GB + 0x20000 bytes
Usable RAM: Base Address: 0x0 X 4GB + 0x100000,
Length: 0x0 X 4GB + 0x6fdc0000 bytes
Reserved: Base Address: 0x0 X 4GB + 0x6fec0000,
Length: 0x0 X 4GB + 0x11000 bytes
Reserved: Base Address: 0x0 X 4GB + 0x6fed1000,
Length: 0x0 X 4GB + 0x2000 bytes
Reserved: Base Address: 0x0 X 4GB + 0x6fed3000,
Length: 0x0 X 4GB + 0x2d000 bytes
Reserved: Base Address: 0x0 X 4GB + 0x6ff00000,
Length: 0x0 X 4GB + 0x10000000 bytes
Reserved: Base Address: 0x0 X 4GB + 0x7ff00000,
Length: 0x0 X 4GB + 0x100000 bytes
Reserved: Base Address: 0x0 X 4GB + 0xe0000000,
Length: 0x0 X 4GB + 0x10000000 bytes
Reserved: Base Address: 0x0 X 4GB + 0xfec00000,
Length: 0x0 X 4GB + 0x10000 bytes
Reserved: Base Address: 0x0 X 4GB + 0xfee00000,
Length: 0x0 X 4GB + 0x1000 bytes
Reserved: Base Address: 0x0 X 4GB + 0xfff80000,
Length: 0x0 X 4GB + 0x80000 bytes
Usable RAM: Base Address: 0x1 X 4GB + 0x0,
Length: 0x0 X 4GB + 0x80000000 bytes
Hope this helps.
BTW I noticed that the uppermem command doesn't work in grub4dos, maybe that could've solved something. I crunched some numbers and came with something close to the number of MB that grub reports. If grub is detecting only one stick of memory which is 2048MB, and let's say that the sata/RAID firmware takes up 256MB (which windows 7 reports is the difference between the total and usable memory) the number of MBs left is 1792 which is pretty close to grub's number. Don't know if this means anything.
Usable RAM: Base Address: 0x0 X 4GB + 0x0, = 0x000000000(630,784 bytes)
Length: 0x0 X 4GB + 0x9a000 bytes
Reserved: Base Address: 0x0 X 4GB + 0x9a000, = 0x00009a000(24,576 bytes Reserved)
Length: 0x0 X 4GB + 0x6000 bytes
Reserved: Base Address: 0x0 X 4GB + 0xd0000, = 0x0000d0000(49,152 bytes Reserved)
Length: 0x0 X 4GB + 0xc000 bytes
Reserved: Base Address: 0x0 X 4GB + 0xe0000, = 0x0000e0000(131,072 bytes Reserved)
Length: 0x0 X 4GB + 0x20000 bytes
Usable RAM: Base Address: 0x0 X 4GB + 0x100000, = 0x000100000(1,876,688,896 bytes, The memory that Grub4DOS can see)
Length: 0x0 X 4GB + 0x6fdc0000 bytes
Reserved: Base Address: 0x0 X 4GB + 0x6fec0000, = 0x06fec0000(69,632 bytes Reserved)
Length: 0x0 X 4GB + 0x11000 bytes
Reserved: Base Address: 0x0 X 4GB + 0x6fed1000, = 0x06fed1000(8,192 bytes Reserved)
Length: 0x0 X 4GB + 0x2000 bytes
Reserved: Base Address: 0x0 X 4GB + 0x6fed3000, = 0x06fed3000(184,320 bytes Reserved)
Length: 0x0 X 4GB + 0x2d000 bytes
Reserved: Base Address: 0x0 X 4GB + 0x6ff00000, = 0x06ff00000(268,435,456 bytes Reserved)
Length: 0x0 X 4GB + 0x10000000 bytes
Reserved: Base Address: 0x0 X 4GB + 0x7ff00000, = 0x07ff00000(1,048,576 bytes Reserved)
Length: 0x0 X 4GB + 0x100000 bytes
(0x80000000 - 0xe0000000, 1,610,612,736 bytes not described in the memory map, maybe remapped in the last entry of memory map?)
Reserved: Base Address: 0x0 X 4GB + 0xe0000000, = 0x0e0000000(268,435,456 bytes Reserved)
Length: 0x0 X 4GB + 0x10000000 bytes
Reserved: Base Address: 0x0 X 4GB + 0xfec00000, = 0x0fec00000(65,536 bytes Reserved)
Length: 0x0 X 4GB + 0x10000 bytes
Reserved: Base Address: 0x0 X 4GB + 0xfee00000, = 0x0fee00000(1,024 bytes Reserved)
Length: 0x0 X 4GB + 0x1000 bytes
Reserved: Base Address: 0x0 X 4GB + 0xfff80000, = 0x0fff80000(524,288 bytes Reserved)
Length: 0x0 X 4GB + 0x80000 bytes
Usable RAM: Base Address: 0x1 X 4GB + 0x0, = 0x100000000(2,147,483,648 bytes, as PAE is not supported/enabled? in Grub4DOS, such area may not be used by Grub4DOS)
Length: 0x0 X 4GB + 0x80000000 bytes
There may be an option not to remap the memory to upper area in BIOS.
Edited by roytam1, 15 June 2011 - 02:09 PM.
#9
Posted 15 June 2011 - 06:32 PM
Lower memory: 616K, Upper memory (to first chipset hole: 1832704K)
Here is your problem. Your BIOS seems to have mapped something at this point. grub4dos can only use contiguous memory (memory with no gaps).
Try running Windows and use Device Manager to view the memory map - see what is mapped there. Also check BIOS for options around VGA memory, etc.
#10
Posted 15 June 2011 - 06:40 PM
EISA Memory BIOS Interface is present
Address Map BIOS Interface is present
Lower memory: 616K, Upper memory (to first chipset hole: 1832704K)
[Address Range Descriptor entries immediately follow (values are 64-bit)]
Usable RAM: Base: 0x0, Length: 0x9A000
Reserved: Base: 0x9A000, Length: 0x6000
Reserved: Base: 0xD0000, Length: 0xC000
Reserved: Base: 0xE0000, Length: 0x20000
Usable RAM: Base: 0x100000, Length: 0x6FDC0000
Reserved: Base: 0x6FEC0000, Length: 0x11000
Reserved: Base: 0x6FED1000, Length: 0x2000
Reserved: Base: 0x6FED3000, Length: 0x2D000
Reserved: Base: 0x6FF00000, Length: 0x10000000
Reserved: Base: 0x7FF00000, Length: 0x100000
Reserved: Base: 0xE0000000, Length: 0x10000000
Reserved: Base: 0xFEC00000, Length: 0x10000
Reserved: Base: 0xFEE00000, Length: 0x1000
Reserved: Base: 0xFFF80000, Length: 0x80000
Usable RAM: Base: 0x100000000, Length: 0x80000000
Seems there might be something to the PAE issue. Though it seems strange that grub4dos wouldn't support it as it is somewhat common. Is there a way to enable PAE or change the memory mapping procedure in grub4dos?
#11
Posted 15 June 2011 - 06:48 PM
#12
Posted 15 June 2011 - 07:04 PM
#13
Posted 15 June 2011 - 07:06 PM
This looks like the "smoking gun"...Without PAE and given that PCI/PCIe uses memory mapped IO may just mean that without it, access to the rest of the "ram" is disabled ...Lot of good (but complex) info on wikipedia and other places on the complexities of memory addressing as the X86 chips evolved from the early chips to the "386" level and beyond...Usable RAM: Base Address: 0x1 X 4GB + 0x0, = 0x100000000(2,147,483,648 bytes, as PAE is not supported/enabled? in Grub4DOS, such area may not be used by Grub4DOS)
#14
Posted 15 June 2011 - 07:11 PM
#15
Posted 16 June 2011 - 12:09 AM
GRUB4DOS can only use contiguous memory range for each RAM drive.
Even with PAE support, your largest block is 2GB.
You may create a RAM drive in the 2GB block and another drive in the remaining block.
#16
Posted 16 June 2011 - 09:18 AM
Steve here are the System Board memory addresses:
FEC00000-FEC00FFF
FED00000-FED00FFF
FEE00000-FEEFFFFF
FFC00000-FFFFFFFF
Not sure if anything further can be deduced from that.
Is there anyway to make the memory mapping contiguous?Maybe through BIOS modding?Or might there be a way to make grub4dos detect memory in another way to support noncontiguous memory?If not can someone recommend another bootloader which can load disk images into RAM?
#17
Posted 16 June 2011 - 09:58 AM
#18
Posted 16 June 2011 - 10:36 AM
1 user(s) are reading this topic
0 members, 1 guests, 0 anonymous users