The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Clem Cole <clemc@ccc.com>
To: Jon Steinhart <jon@fourwinds.com>
Cc: The Unix Heritage Society mailing list <tuhs@tuhs.org>
Subject: Re: [TUHS] Early Linux and BSD
Date: Tue, 21 Jan 2020 13:43:10 -0500	[thread overview]
Message-ID: <CAC20D2OY1SPzeLaDvigY7=WhL=BiEqPo8XebZ5yWd2jAgjM0sA@mail.gmail.com> (raw)
In-Reply-To: <202001211717.00LHHaxP3280983@darkstar.fourwinds.com>

[-- Attachment #1: Type: text/plain, Size: 1679 bytes --]

On Tue, Jan 21, 2020 at 12:18 PM Jon Steinhart <jon@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.

[-- Attachment #2: Type: text/html, Size: 3319 bytes --]

  parent reply	other threads:[~2020-01-21 18:44 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-17 16:01 [TUHS] On the origins of Linux - "an academic question" Arrigo Triulzi
2020-01-17 16:53 ` Warner Losh
2020-01-17 17:08   ` Arrigo Triulzi
2020-01-17 17:25 ` Brantley Coile
2020-01-17 19:59 ` Arno Griffioen
2020-01-18  3:50   ` Theodore Y. Ts'o
2020-01-18  4:19     ` [TUHS] Early Linux and BSD (was: On the origins of Linux - "an academic question") Greg 'groggy' Lehey
2020-01-18 15:25       ` Larry McVoy
2020-01-18 16:19         ` reed
2020-01-19  2:49       ` Theodore Y. Ts'o
2020-01-19  3:12         ` Greg 'groggy' Lehey
2020-01-19  3:47           ` [TUHS] Early Linux and BSD Warren Toomey
2020-01-19  3:51             ` Greg 'groggy' Lehey
2020-01-19  3:58           ` [TUHS] Early Linux and BSD (was: On the origins of Linux - "an academic question") Greg 'groggy' Lehey
2020-01-19 13:25             ` Theodore Y. Ts'o
2020-01-19 13:48               ` Clem Cole
2020-01-20  3:32               ` Greg A. Woods
2020-01-20  3:51                 ` George Michaelson
2020-01-20  3:59                   ` [TUHS] Early Linux and BSD Jon Forrest
2020-01-20 17:19                   ` [TUHS] Early Linux and BSD (was: On the origins of Linux - "an academic question") Clem Cole
2020-01-20 17:49                     ` Warner Losh
2020-01-20 19:00                       ` Clem Cole
2020-01-20 18:04                     ` Larry McVoy
2020-01-20 18:09                       ` David Barto
2020-01-20 18:34                         ` [TUHS] Early Linux and BSD Arthur Krewat
2020-01-20 19:18                       ` [TUHS] Early Linux and BSD (was: On the origins of Linux - "an academic question") Clem Cole
2020-01-20 19:46                         ` Jon Steinhart
2020-01-20 20:15                           ` Clem Cole
2020-01-21  6:58                           ` [TUHS] Early Linux and BSD Lars Brinkhoff
2020-01-21 14:30                             ` Clem Cole
2020-01-21 17:17                             ` Jon Steinhart
2020-01-21 17:22                               ` Warner Losh
2020-01-21 17:25                                 ` Jon Steinhart
2020-01-21 18:43                               ` Clem Cole [this message]
2020-01-21 18:44                                 ` Clem Cole
2020-01-21 19:14                                   ` Warner Losh
2020-01-21 20:27                                     ` Clem Cole
2020-01-22  0:14                       ` [TUHS] Early Linux and BSD (was: On the origins of Linux - "an academic question") Greg A. Woods
2020-01-21  0:44                     ` Bakul Shah
2020-01-20 19:09                 ` Theodore Y. Ts'o
2020-01-20 19:51                   ` Clem Cole
2020-01-20 23:04                   ` Greg A. Woods
2020-01-21  0:13                     ` Warner Losh
2020-01-21 23:45                       ` Greg A. Woods
2020-01-18 15:30     ` [TUHS] On the origins of Linux - "an academic question" Larry McVoy
2020-01-17 23:11 ` Andrew Warkentin
2020-01-17 23:20   ` Rob Pike
2020-01-17 23:38     ` Brantley Coile
2020-01-18  0:23 ` Wesley Parish

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAC20D2OY1SPzeLaDvigY7=WhL=BiEqPo8XebZ5yWd2jAgjM0sA@mail.gmail.com' \
    --to=clemc@ccc.com \
    --cc=jon@fourwinds.com \
    --cc=tuhs@tuhs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).