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

2006-08-12 Thread Segher Boessenkool
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 to leave a processor off line that may suck :) How SLOF make sure the processor is good? does it? Only the service processor can completely s

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

2006-08-12 Thread Jimi Xenidis
On Aug 12, 2006, at 5:31 AM, Segher Boessenkool wrote: Note that the processors on a JS20 are noticably slower to handshake than those on a JS21. I had to rid of the hard-coded 1024 timebase ticks and replace it with calculating five seconds from the timebase frequency, as the timeout logic wa

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

2006-08-12 Thread Segher Boessenkool
Note that the processors on a JS20 are noticably slower to handshake than those on a JS21. I had to rid of the hard-coded 1024 timebase ticks and replace it with calculating five seconds from the timebase frequency, as the timeout logic was firing on my JS20 blade. What should we do about CPUs

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

2006-08-11 Thread Jimi Xenidis
On Aug 10, 2006, at 10:09 PM, Amos Waterland wrote: Take two. ok, I think we need a take three... Note that the processors on a JS20 are noticably slower to handshake than those on a JS21. I had to rid of the hard-coded 1024 timebase ticks and replace it with calculating five seconds from t

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

2006-08-10 Thread Amos Waterland
Take two. Note that the processors on a JS20 are noticably slower to handshake than those on a JS21. I had to rid of the hard-coded 1024 timebase ticks and replace it with calculating five seconds from the timebase frequency, as the timeout logic was firing on my JS20 blade. Note that the SLOF i