So the issue here is that grub has for some reason been upset by the values
returned to it by the e820 bios command, and has decided to fall back to a
simpler bios command which only tells you amount of memory up to the first
memory hole. This wouldn't necessarily affect Linux because it interrogates
the bios itself, using different code which isn't affected by this bug
(either it's a bios bug which Linux explicitly works around or is simply not
susceptible to; or it's a grub bug which Linux doesn't have).
OK, I understand now.
Thanks for the explanation.
1. Dig into why GRUB is bailing on the e820 map, and come up with a grub
patch to fix (or work around) the bug. This will require modifying,
building, installing grub, rebooting the machine, etc etc. It's a pain in
OK, I will look in to that. I have tested the latest debian grub 0.97-27
with some patches which fix BIOS e820 fixes people recommended, but
still the same.
2. Boot via a different method (basically that would mean pxe). This might
be convenient or impossible, depending on your machine's local network
3. There is no command-line option for overrding the e820 map. We could
lash one up, or I can give you a basic patch for you to fill in the blanks
with your memory map. You can then build special Xen with hardcoded map for
That would be great. I have the memory map from the vanilla linux boot, so
if you can show me where to hardcode that in, I will give it a shot. I always
compile xen from source anyway for each server.
I should add the slightly longer term (post 3.0.5) solution, which will be
that Xen can return to real mode and interrogate e820 itself. We could at
least provide this as a command-line option, even if it's not the default.
Ok, that would be useful.
Xen-devel mailing list