[TUHS] Early Linux and BSD

Clem Cole clemc at ccc.com
Wed Jan 22 04:43:10 AEST 2020


On Tue, Jan 21, 2020 at 12:18 PM Jon Steinhart <jon at fourwinds.com> wrote:

> My memory is very very very fuzzy on this.  I seem to recall that microcode
> state was pushed onto a stack in certain cases,

State, not the code.

In fact, Masscomp having built the first MP UNIX box, ran into this problem
early on.  Different processor stepping had different internal microcode
state on the stack after an IRQ.  If you resumed with a processor that was
a different processor revision, the wrong state was returned.

Will may remember this, but Masscomp issues strick orders to the FE that
all CPU boards had to be the revision.  You could not just swap a CPU
board, they had to go as sets. It was a real bummer.

Moto fixed that with the 020 and later devices as more people made MP
systems.





> ...  just heard grumbles from other folks about it.
>
Probably me ...  it took me, tjt and Terry Hayes about 3-4 weeks to figure
out that problem.   It was not originally documented, other than to state
on certain faults X bytes of reserved information was pushed on the stack.


BTS: I don't remember, but it may have started with the 68010.
 Becuase before that, the 'executor' was wait stated and the fixor handled
and fixed the fault so the 68000 never actually saw  fault in the original
Masscomp CPU board.   The "MPU" board was the same board with a couple of
PAL's changed and an 68010 as the executor.   It was allowed to actually
fault and do something else while the fixor corrected the fault.  But the
key is that when the fault was repaired, another executor on a different
MPU board could be the processor that 'returned' from the fault.   That
ended up being a no-no.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200121/3f2cd2ee/attachment.html>


More information about the TUHS mailing list