On Tue, Jan 21, 2020, 11:46 AM Clem Cole 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 wrote: > >> >> >> On Tue, Jan 21, 2020 at 12:18 PM Jon Steinhart 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. >> >