"Magenheimer, Dan (HP Labs Fort Collins)" <dan.magenheimer@xxxxxx> wrote:
> It won't work for NUMA machines, but we can worry about that later.
> In the meantime, domU is much much more stable. I doubt that
> this is the "last bug" we will find affecting domU stability,
> but it was a tough one. Thanks very much to Matt for isolating
> the problem!
Hi Dan, Hi All,
sorry for the fishing-for-clues nature of this post.
I've been scratching my head for a while over oopses in the vbd, and
this afternnon my colleague Yamahatta-san pointed me in the direction of
your post, which I had previously missed.
I am seeing a oops in the loopback layer because of accessing memory off
the end of the world, as your problem description talks about. However,
I am still seeing the same problem with your fix.
In a nutshell, the end of memory seems to be at 0x000000007f00000
(XEN) domain mem: type=2, attr=0x8,
range=[0x0000000008000000-0x0000000008100000) (1MB)
(XEN) domain mem: type=13, attr=0x8,
range=[0x0000000008100000-0x000000000820000 0) (1MB)
(XEN) domain mem: type=7, attr=0x8,
range=[0x0000000008200000-0x0000000027000000) (494MB)
(XEN) domain mem: type=7, attr=0x8,
range=[0x000000007e000000-0x000000007f000000) (16MB)
(XEN) domain mem: type=12, attr=0x8000000000000001,
range=[0x00000ffffc000000-0x 0000100000000000) (64MB)
Howver, I have
Virtual mem_map starts at 0xa0007fffff90c000
And the loopback code ends up trying to access a0007fffff93eea0, which
is off the end of the world. I strongly suspect this is a direct result
of me having NUMA enabled.
As its the end of the day (well the hacking part of it anwyay), before
seeing if the box can be booted without NUMA enabled I thought I'd ask
if this is indeed the cause of the problem. And for some indication of
how difficult it might be to fix.
--
Horms
_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel
|
Home