[TUHS] Early Linux and BSD

[Warner Losh]

On Tue, Jan 21, 2020, 11:46 AM Clem Cole <clemc at ccc.com> wrote:

> sorry...    all *MPU* boards had to be the revision but we may have done
> the same with the CPU boards.
>

When did Masscomp ship their first MP system?

Warner

On Tue, Jan 21, 2020 at 1:43 PM Clem Cole <clemc at ccc.com> wrote:
>
>>
>>
>> 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/28941b0b/attachment.html>