Re: [Xen-devel] KernelBUGatarch/x86_64/mm/../../i386/mm/hypervisor.c:197

[Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>]

On 5/10/06 5:02 am, "Ian Pratt" <m+Ian.Pratt@xxxxxxxxxxxx> wrote:

>> The BIOS help also says that the "hardware memory hole" only works on
>> REV E0 processors, so perhaps this configures some weird mapping that
>> Xen doesn't understand? Anyway, I'll stick with this setting now,
> given
>> that it just works.
> 
> Glad it works for you, but I wish we understood what was going on a bit
> more. It may be that the bios is just borked and the e820 map it gives
> xen misses some regions that it steals for other purposes. It would be
> pretty surprising if Xen had bugs in its e820 code.
> 
> It might be interesting to post the xm dmesg output with the two
> different BIOS settings to see if there's anything unusual about the
> e820 map. Might be worth comparing against what Linux prints too.

Older Opterons couldn't remap DRAM around the I/O memory region. That
limitation went away some time ago though, and I expect dual-core chips
should all have a memory controller that support DRAM remapping.

The issue here is more likely that the BIOS is basket case. You might try
upgrading the BIOS and see if that helps. The downside of software memory
hole appears to be that remapped RAM accesses are apparently 'emulated',
which doesn't sound fast! And if you specify no hole at all, you will lose
around 512MB of memory.

Look around on Google for complaints about "hardware memory hole" causing
problems for people. There are plenty! You seem unlucky that your issue is
as hard to reproduce as it is. Many people can't even boot.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel