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 4b959cb1 for ; Tue, 21 Jan 2020 20:28:27 +0000 (UTC) Received: by minnie.tuhs.org (Postfix, from userid 112) id 539859C205; Wed, 22 Jan 2020 06:28:26 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 047279C200; Wed, 22 Jan 2020 06:27:36 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=fail reason="signature verification failed" (1024-bit key; unprotected) header.d=ccc.com header.i=@ccc.com header.b="YSj/0Dwp"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 69B179C200; Wed, 22 Jan 2020 06:27:33 +1000 (AEST) Received: from mail-qk1-f169.google.com (mail-qk1-f169.google.com [209.85.222.169]) by minnie.tuhs.org (Postfix) with ESMTPS id DE0B99C1FF for ; Wed, 22 Jan 2020 06:27:31 +1000 (AEST) Received: by mail-qk1-f169.google.com with SMTP id v195so3969770qkb.11 for ; Tue, 21 Jan 2020 12:27:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ccc.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1fmD01CSXAwiCAeuLe9HngMha8uo7MUS1MCxxtqjfh8=; b=YSj/0Dwpeyntmgr/oLrz/WcklUy+DcPrgd7rd4THs/SjO+DordONrUCUTY590boAZZ HAQhFEmyF0WEH9RwT8MBKV+FaeVh6TTgVDEFGex3X0UeBjXpvZ+rdKEMAFHqQH4TAEws NdFMPsOgRBZILEVWbifXn7E6t2zh5LZHYcCmE= 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=1fmD01CSXAwiCAeuLe9HngMha8uo7MUS1MCxxtqjfh8=; b=tRe/cG9V6y3hsFOyIGOuW+CB5Jt7U8EBkZqirMQnal8Sq0oSmH1CTHsAzu3/E8Bi6G hoNige6Z+V2FC4pYeUreua4/lzwItK3jLPvTyVAu+gFKd0Gu/D0HeVF8OteVrJa08W7X eN+ONJIAbCudP93E7PS/1b9wx43dus3cfb8vwFfgDThs+bRFS6M/oqOEt0q/CacxFkrB 8TjyFE+FaIJsCykw9kTnLTJ809xifnOW9F9F88jWg9B4GQ+TQDX+2nnBoR/YJ/2l2hOd 0nwdg6Avz8ojwSGgIkGRGkMs7EZN7aWcNjBal4rPgY1pwephBg+E0/rC2MVexezCzSC7 TXxg== X-Gm-Message-State: APjAAAWwUJxxPyYywdClf+iJIsT4J7u+0eOPVg7KV5dwX1ZTeBluH8A8 Q/HmpKTvYlpdJ7Zs3WH6euAwXysFsJIXQCn5TrnS3fjeuafPZg== X-Google-Smtp-Source: APXvYqyLXrqQpJrI1AkqZZVraKxtw31q9a6tQk0EzdjHXwAJmsmIw1BE541Jr9TJZlCsXq7wOQSiF0XVaEvXHXt5iXo= X-Received: by 2002:ae9:c003:: with SMTP id u3mr6270266qkk.133.1579638450772; Tue, 21 Jan 2020 12:27:30 -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: Clem Cole Date: Tue, 21 Jan 2020 15:27:04 -0500 Message-ID: To: Warner Losh Content-Type: multipart/alternative; boundary="000000000000bb7207059cac3cd5" 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" --000000000000bb7207059cac3cd5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 1982, the dual-processor MC500/DP originally with 68000s upgraded to 010's shortly after they became available[see below] 1984, the 16 Processor MC5000/700 using '020 [the 500 was renamed the MC5000/500 and a single processor MC5000/300 was also introduced. In the /700 and /300 design the fixor was unneeded and the base 020 serviced it's own faults]. FWIW: Purdue VAX predates the 500/DP, but was a one-off that George made. The Sequent MP box would be about 3 or 4 years later. Through the RTU 2.x, the OS originally ran Purdue VAX-like [*Goble/Marsh: I= SCA '82: Proceedings of the 9th annual symposium on Computer Architecture: "A Dual Processor VAX 11/780", **Pages 291=E2=80=93298*] in all interrupts and= system calls went to a 'master' and the second MPU/CPU board ran as a 'slave' ( *i.e.* user-mode code). By RTU 3.0 ~12 mons later, full locks were done and each processor could service anything. Note each CPU/MPU board had processor two chips on it, the executor and fixor but the board was really not a multiprocessor - the second chip was literally just running kernel code to service the page fault. Thus (not including the other 68000's processors in graphics or I/O boards) the 500/DP had either 4 68000's or 2 68010 & 2 68000's in it when it had two CPU or two MPU boards in the backplane. The idea was originally proposed for the Z8000 by Forest Baskett at an early Asilomar conference. The formal citation is: Forest Baskett: "*Pascal and Virtual Memory in a Z8000 or MC68000 based Design Station*," COMPCON 80, Digest of Papers, pp 456-459, IEEE Computer Society, Feb. 25, 1980. On Tue, Jan 21, 2020 at 2:14 PM Warner Losh wrote: > > > 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 proce= ssor >>> that was a different processor revision, the wrong state was returned. >>> >>> Will may remember this, but Masscomp issues strick orders to the FE tha= t >>> 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 o= n >>> 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 hand= led >>> and fixed the fault so the 68000 never actually saw fault in the origi= nal >>> 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 actuall= y >>> fault and do something else while the fixor corrected the fault. But t= he >>> key is that when the fault was repaired, another executor on a differen= t >>> MPU board could be the processor that 'returned' from the fault. That >>> ended up being a no-no. >>> >> --000000000000bb7207059cac3cd5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
1982, the dual-processor MC500/DP originally with 68000= s upgraded to 010's shortly after they became available[see below]
1984, the 16 Processor MC5000/700 using '020 [the 500 was renamed t= he MC5000/500 and a single processor MC5000/300 was also introduced.=C2=A0 = In the /700 and /300 design the fixor was unneeded and the base 020 service= d it's own faults].

FWIW: Purdue VAX predates the = 500/DP, but was a one-off that George made.=C2=A0 =C2=A0The Sequent MP box = would be about 3 or 4 years later.

Through the RTU 2.= x, the OS originally ran Purdue VAX-like [Goble/= Marsh:=C2=A0ISCA = 9;82: Proceedings of the 9th annual symposium on Computer Architecture: &qu= ot;A <= span class=3D"gmail_default">Dual Processor VAX 11/780",=C2=A0Pages 291= =E2=80=93298]=C2=A0in all interrupts and system calls wen= t to a 'master'=C2=A0 and the second MPU/CPU board ran as a 'sl= ave' (i.e. user-mode code). By RTU 3.0 ~12 mons later, full lock= s were done and each processor could service anything.


Note each CPU/MPU board had processor two chips on it, the ex= ecutor and fixor but the board was really not a multiprocessor - the second= chip was literally just running kernel code to service the page fault.=C2= =A0 Thus (not including the other 68000's processors in graphics or I/O= boards) the 500/DP had either 4 68000's or 2 68010 & 2 68000's= in it when it had two CPU or two MPU boards in the backplane.=C2=A0 The id= ea was originally proposed for the Z8000 by Forest Baskett at an early Asil= omar conference.=C2=A0 =C2=A0The formal citation is:=C2=A0Forest Baskett: "Pascal and Virtual Mem= ory in a Z8000 or MC68000 based Design Station,&q= uot; COMPCON 80, Digest of Papers, pp 456-459, IEEE Computer Society, Feb. = 25, 1980.

On Tue, Jan 21, 2020 at 2:14 PM Warner Losh <imp@bsdimp.com> wrote= :


On Tue, Jan 21, 2020, 11:46 AM Clem Cole <clemc@ccc.com> wrote:
=
sorry...=C2=A0 =C2=A0 all MPU boar= ds 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 <= ;clem= c@ccc.com> wrote:


On Tue, Jan 21, 2020 at 12:18 PM Jon Stei= nhart <jon@fourwinds.com> wrote:
My memory is very 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>
--000000000000bb7207059cac3cd5--