[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

  • To: "Christophe Saout" <christophe@xxxxxxxx>
  • From: "Ian Pratt" <m+Ian.Pratt@xxxxxxxxxxxx>
  • Date: Thu, 5 Oct 2006 05:02:20 +0100
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Wed, 04 Oct 2006 21:02:49 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: Acbn+kLU06yv6ZihQ4muP8z1kulBrAAOFeiQ
  • Thread-topic: [Xen-devel] KernelBUGatarch/x86_64/mm/../../i386/mm/hypervisor.c:197

> The good news is that we were able to fix this problem by changing
> settings concerning "memory holes". There were two settings "hardware
> memory hole" and "software memory hole" that "enable software/hardware
> remapping around memory hole", whatever that is. They were both turned
> on by default, and I just turned them off. I didn't see any downsides
> except that I'm unable to crash the machine any more. It's surviving
> stress tests for several hours now without crashes.
> 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,
> 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.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.