Re: [XenPPC] [PATCH] Handshake with secondary processors (take 2

If it takes more than the proposed 5 secs, why bother -- your
system is dead anyway ;-)
Hmm.. ok.. I am being parnoid, I just don't trust the FW guys toleave a processor off line that may suck :)
How SLOF make sure the processor is good? does it?


Only the service processor can completely shut down a CPU, on
our blades anyway.  So the best that SLOF can do is hope for
the best.  The secondary-CPU startup code has been engineered
to be pretty much 100% failure proof though.  And a dead CPU
won't be shown in the device tree.

I guess I'm looking for a way to decide that things are bad.


There's one way we are bad right now: we require all secondary
cpu's to be started, they are not idle but running in a spinloop
somewhere.  Cache invalidate those addresses and hell breaks
loose ;-)

Not a real problem in practice, which is why I still didn't fix it.


Segher


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

<Prev in Thread]

Current Thread

[Next in Thread>

Previous by Date:

Re: [XenPPC] [PATCH/RFC] Run C code that inits HID registers from secondary procs, Jimi Xenidis

Next by Date:

Re: [XenPPC] [PATCH/RFC] Run C code that inits HID registers from secondary procs, Segher Boessenkool

Previous by Thread:

Re: [XenPPC] [PATCH] Handshake with secondary processors (take 2), Jimi Xenidis

Next by Thread:

[XenPPC] [PATCH] Init secondary processors up to assigning r13, Amos Waterland

Indexes:

[Date] [Thread] [Top] [All Lists]

WARNING - OLD ARCHIVES

xen-ppc-devel

Re: [XenPPC] [PATCH] Handshake with secondary processors (take 2)