Re: [Xen-ia64-devel] translate_domain_mpaddr error message

[Tristan Gingold <Tristan.Gingold@xxxxxxxx>]

Le Mardi 07 Mars 2006 16:00, Alex Williamson a Ãcrit :
> On Tue, 2006-03-07 at 06:53 -0800, Magenheimer, Dan (HP Labs Fort
>
> Collins) wrote:
> > I have seen them for a long time on one of my machines
> > so I don't think it is related to your recent SMP work.
> > I suspected they are a result of programming some MMIO
> > device but never tracked it down.
>
>    I've seen them too.  I haven't tracked them down either, but my guess
> was they might have something to do w/ playing with the EFI RTC.
Thanks.

Meanwhile I have also tracked it.
This appear when hwclock is run at boot time.  Since translate_domain_mpaddr 
is called only in metaphysical, it is not called enough.  One of the only 
place is EFI_GETTIMEOFAY.

However, it doesn't always appear.  You can run hwclock many times without the 
message.

The bogus address is in fact inside the stack.  So it is not that bogus.
And it is not bogus at all given the memmap:
(XEN) translate_domain_mpaddr: out-of-bounds dom0 mpaddr 0x7e91fde0!

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)

So I think the last granule is sometimes used for the stack, and this granule
doesn't belong to dom0_start .. dom0_start+dom0_size.
The test does not stand anymore.

We could either remove it or wait for VP.

Hops this is correct.
Tristan.


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