Re: [XenPPC] Overflow in decrementer restore

[Segher Boessenkool <segher@xxxxxxxxxxxxxxxxxxx>]

> The problem turned out to be that we don't sync the timebases between
> the processors.
Does this happen on JS2x?  SLOF is supposed to ensure that all
CPUs start with the timebases already synchronised.  This isn't
an OF requirement, but we do it anyway just to be nice to the OS
and everyone else.  If it happens on SLOF/JS2x, please tell me
(and show some debug output?)

> So if load_sprs() is executed on a different CPU than
> save_sprs() was, the call to mftb is bogus.
The timebases are allowed to have some *small* discrepancy between
CPUs, do you take that into account?  Say, 10 or 20 ticks or so, I
can't remember the exact number (and it doesn't matter anyway).

> The timebase_delta can
> overflow into a large unsigned value of up to 149 seconds on JS21.
149 secs is about 2**31 timebase ticks, not 2**32.  Weird.

> We are currently thinking about how best to sync the timebases.  Right
> now it looks like pulling in Linux's implementation is the best  
> option.
> Any comments would be appreciated.
We use the smp-tbsync.c Linux implementation on all 970-based platform
in Linux (except the Apple ones, heh).  So that should work fine for
Xen too, yes.

> We did have a real memory controller hang, as discussed on this  
> list in
> response to my original post.  It only occurred on Maple, where PIBS
> does not clear the HIOR for secondary CPUSs, so their first  
> exeception was
> delivered to 0xX00 + Y.
And that's an actual PIBS bug.  Please mark it as such in the code,
so you can remove it when the firmware is fixed (if that ever happens,
esp. on already-shipped systems, heh).  It's good to document _why_
the code does weird things anyway ;-)


Segher


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