From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.6 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.2 Received: from minnie.tuhs.org (minnie.tuhs.org [45.79.103.53]) by inbox.vuxu.org (OpenSMTPD) with ESMTP id 1d9876bf for ; Tue, 21 Jan 2020 19:15:40 +0000 (UTC) Received: by minnie.tuhs.org (Postfix, from userid 112) id 17EF79C215; Wed, 22 Jan 2020 05:15:35 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 3AE9B9C24D; Wed, 22 Jan 2020 05:15:05 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=bsdimp-com.20150623.gappssmtp.com header.i=@bsdimp-com.20150623.gappssmtp.com header.b="Maob8CrE"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 910649C284; Wed, 22 Jan 2020 05:15:03 +1000 (AEST) Received: from mail-qk1-f180.google.com (mail-qk1-f180.google.com [209.85.222.180]) by minnie.tuhs.org (Postfix) with ESMTPS id 0E8AF9C270 for ; Wed, 22 Jan 2020 05:14:58 +1000 (AEST) Received: by mail-qk1-f180.google.com with SMTP id c16so3880729qko.6 for ; Tue, 21 Jan 2020 11:14:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rGeiJTmFI7LFl9U8ClAvCUCnnsR8oFrxmW++s4p3v84=; b=Maob8CrE9zfR1HOWyCUi0XocPFPxWb1vKpl23wCcKWx9CnUyBuhKG2xJUy6AuUrfVz fROEbxc5daOM5Q0n+47QhxWuIWeQ/ISzlJKEvL+nV8ct21/3TjrrAKIELBmFQzA6flNw uCH4R3mvSe8nuDOa1DHGHUR+vJyq6Xb+8mq+usOsg2PcvNoJS9gzXZL9rA1u71ItJBBu MCZQ0JtPTXom38DQMO3UzqYcI5YNZFHu4ne/ON5lxBTiCxtlWFf4pl1y5xDBxRnP2ff7 KJ0xoFv2dPXVde2fhyIoPpnyU1sRI+A2tPxH06S4Ha60087IfRQIqqNXSxRUyTzTG5PS CZaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rGeiJTmFI7LFl9U8ClAvCUCnnsR8oFrxmW++s4p3v84=; b=RXPSnEmORNq+kAx2k7FQoGkQ3Lk5p8pcmIKeidEas8MQbLgLj5o82D4eLQnXOARzZX H70mgSLUAzKFf//Q8DVyfeghSCetMtgIX/L6cCVounzzeXEvtzzYRhJBhi8MD935k7WI gGgYnEinchFU1xKLzrq7k84X6TA/Ixjt+YxKG7+nOXlpzLeZQW2c4hncxpVjqncxsz/4 YZ1j8lNWbhbAITBAwha+TKUFqeJWSPtt8iUpF3dNwDWQxCDK/wkqc/UzMQZaKdbYD1RV REnCel9+Wm1CWFrQNRp1KJ2c0xpqTHTjGSDURaxSN9FTg4kuTTgtXfEZgQSqRFkUHm6d AWug== X-Gm-Message-State: APjAAAVyNepVA7SHPJatdOZnSvXtreQYL+jS3Qfq8nTqR7vpO2cdroFI V+YT7AYDzhiu8kOiKwLa4rLXeBkPlinPJMJq6hmRzQ== X-Google-Smtp-Source: APXvYqyopMOEPFAruEYwgNV6gGMldkRmEZOgiE/7K22oEHH9jowvYSBsskoLuuttTmcHPZPayUNLDk44IRqJc9kIeBU= X-Received: by 2002:a05:620a:94f:: with SMTP id w15mr5965470qkw.380.1579634096961; Tue, 21 Jan 2020 11:14:56 -0800 (PST) MIME-Version: 1.0 References: <20200117195908.GF15253@ancienthardware.org> <20200118035051.GC481935@mit.edu> <20200118041913.GB67053@eureka.lemis.com> <20200119024900.GA15860@mit.edu> <20200119031225.GI67053@eureka.lemis.com> <20200119035808.GK67053@eureka.lemis.com> <20200119132551.GC15860@mit.edu> <20200120180432.GJ28686@mcvoy.com> <202001201946.00KJk5er3071186@darkstar.fourwinds.com> <7wk15l70u3.fsf@junk.nocrew.org> <202001211717.00LHHaxP3280983@darkstar.fourwinds.com> In-Reply-To: From: Warner Losh Date: Tue, 21 Jan 2020 12:14:45 -0700 Message-ID: To: Clem Cole Content-Type: multipart/alternative; boundary="00000000000039ac0a059cab39b7" Subject: Re: [TUHS] Early Linux and BSD X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: The Unix Heritage Society mailing list Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" --00000000000039ac0a059cab39b7 Content-Type: text/plain; charset="UTF-8" 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. >> > --00000000000039ac0a059cab39b7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Jan 21, 2020, 11:46 AM Clem Cole <clemc@ccc.com> wrote:
sorry...=C2=A0 =C2= =A0 all MPU boards had to be the revi= sion but we may have done the same with the CPU boards.

When d= id Masscomp ship their first MP system?

Warner

<= div class=3D"gmail_quote">
<= div class=3D"gmail_quote">
On Tue, Jan= 21, 2020 at 1:43 PM Clem Cole <clemc@ccc.com> wrote:

On Tue, = Jan 21, 2020 at 12:18 PM Jon Steinhart <jon@fourwinds.com> wrote:<= br>
My memory is ver= y very very fuzzy on this.=C2=A0 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 fi= rst MP UNIX box, ran into this problem early on.=C2=A0 Different processor = stepping had different internal microcode state on the stack after an IRQ.= =C2=A0 If you resumed with a processor that was a different processor revis= ion, the wrong state was returned.

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

Moto fixed that with the 020 an= d later devices as more people made MP systems.



=C2=A0
... =C2=A0just heard grumbles from other folks about = it.
Probably me ...=C2=A0 it took me, tjt and Terr= y Hayes about 3-4 weeks to figure out that problem.=C2=A0=C2=A0 = It was not originally documented, other than to state on certain faults X b= ytes of reserved information was pushed on the stack.=C2=A0 =C2=A0

BTS: I don't remember, but it ma= y have started with the 68010.=C2=A0 =C2=A0Becuase=C2=A0before that, the &#= 39;executor' was wait stated and the fixor handled and fixed the fault = so the 68000 never actually saw=C2=A0 fault in the original Masscomp CPU bo= ard.=C2=A0 =C2=A0The "MPU" board was the same board with a couple= of PAL's changed and an 68010 as the executor.=C2=A0 =C2=A0It was allo= wed to actually fault and do something else while the fixor=C2=A0corrected = the fault.=C2=A0 But the key is that when the fault was repaired, another e= xecutor on a different MPU board could be the processor that 'returned&= #39; from the fault.=C2=A0 =C2=A0That ended up being a no-no.
<= /div>
--00000000000039ac0a059cab39b7--