On Tue, Jun 11, 2002 at 11:23:23AM +0100, David Laight wrote:
> 
> There is no real reason for it to lock up. It actually (probably)
> tests your locking code slightly more thoroughly.
>

Ummm actually there are lots of reasons for it to lock up :-)  I speak
from experience here - we had a sun machine that someone accidentally
put processor modules of differing clock speeds in.  Theoretically,
the mbus (this was a SS10) is supposed to handle this.  In reality,
the machine did a hard hang after a few hours of operation and we had
to turn the power off and on again to get it's attention.

> 
> There are certain bits of code that rely on the cpu speed
> - so would need to be calibrated separately - eg the
> drvusecwait() routine of SVR4.
> 

Software is only half the story - the locking semantics of the
hardware must also handle the differing clock rates, so must the cache
snooping logic (just imagine the faster processor banging on a cache
line that the slower processor also has in cache... how does the
slower one keep up with the updates?) and so forth.  Probably the fact
that the bus speed is the same may be what is saving the situation
here.

-- 
Brett Lymn