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
| 
Home