|
I found that the best way for me to learn
about this was to play with the factory BIOS settings. The memory hole allows you to boost part
of memory above 4GB so that you have more room for I/O devices without losing
memory capacity. For example, if you had a graphics card
with 256MB of memory and 4GB of RAM installed in the machine, you cannot address
both and keep them inside 32-bits. The solution is to use registers on
the Opteron to map some of your RAM above that limit. Myles From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alan Mimms The problem occurs with 1GB, 2GB or 4GB
of memory installed for sure. I do not know about the HW memory
hole. Can you explain what that is? Alan Mimms, Senior Architect v: 509-343-3524 f: 509-343-3501 From: Lu, Yinghai
[mailto:[EMAIL PROTECTED] What’s your total RAM installed? 4G
or more. With HW memory hole enable? YH From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alan Mimms We have AMD dual Opteron hardware with AMD 8131+8111
chipsets attached. Using LinuxBIOS, we have a slight problem, that APPEARS
to be related to the last 64Kbytes of RAM. Our kboot based environment,
running in 32 bit instruction set, seems to randomly crash, and the implicated
area of memory is this last 64KB. When we run a commercial BIOS on nearly identical
hardware, we see that that BIOS has created in the E820 table an ACPI
Non-Volatile-Storage area covering this last 64KB. LinuxBIOS is NOT doing
that; LinuxBIOS is treating all of the space as simple USABLE space. In trying to figure this out, we have used the AMD HDT
tool to read the last 64KB. We (SOMETIMES) the system crashes when we
read this area using HDT. Can someone please explain what this area is for and why
it’s strange to read even using a hardware debugging tool? Is it
REALLY in use for the ACPI NVS, and can we simply tell Linux to ignore it (map
it out) by creating an entry in E820 table so it won’t be used (we
don’t use ACPI suspend/resume)? Thanks very much for any information. Alan Mimms, Senior Architect v: 509-343-3524 f: 509-343-3501 |
-- linuxbios mailing list [email protected] http://www.openbios.org/mailman/listinfo/linuxbios
