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.8 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,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 91d6fbc0 for ; Tue, 21 Jan 2020 18:44:05 +0000 (UTC) Received: by minnie.tuhs.org (Postfix, from userid 112) id DE1A09C20B; Wed, 22 Jan 2020 04:44:04 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 529F69C1FF; Wed, 22 Jan 2020 04:43:44 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=pass (1024-bit key; unprotected) header.d=ccc.com header.i=@ccc.com header.b="Q6Kw5agW"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 827809C14A; Wed, 22 Jan 2020 04:43:41 +1000 (AEST) Received: from mail-qt1-f169.google.com (mail-qt1-f169.google.com [209.85.160.169]) by minnie.tuhs.org (Postfix) with ESMTPS id D54FB9C14A for ; Wed, 22 Jan 2020 04:43:37 +1000 (AEST) Received: by mail-qt1-f169.google.com with SMTP id k40so3473751qtk.8 for ; Tue, 21 Jan 2020 10:43:37 -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=2D4APry5XSf0ksDtP7ATPNRxldy8/Hxz9lZw18uQ4B4=; b=Q6Kw5agWdu67v1OHVsiT0tSxyMHgM7rgxKw/DeBCAW2Pr65q4IOZba1dOB7jFe3rfN SKrMb1EcpdJx0UPCT8zvBMIdGYlQfFQzhQ78Yqwc2h+eaBOQb/BeXCFj5AS/O7xR4oDG 7no2KU44Twpn7iOCTjAKI7pV2Cw6+4Jhd8q0A= 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=2D4APry5XSf0ksDtP7ATPNRxldy8/Hxz9lZw18uQ4B4=; b=BNlfBQLBedVsBRRq5ov/RWrcQOPxbtOI4lwh/HzO2TA3N7qVM4ihW96ZXymKvZ4ZsG umhB+hmWAl90BOEkt/7k7Lw6cqA1SwbIb+dZG4xA512h/HvsmJ1TK8NeHtZmdvPfpO6g N7uNL2evGwvYYoSCj835o/AYTgG1MNDpO4iVE3F0SOeqDDZ4ugoFjOyftMEkOZUyo6IH 5eyG/4Y8F7YwGPHeWfkrsIhITEek91YNkSdEuWUGhPTv3+LgPA7n4Xa6/cbximtYhemZ unjSRjGsr5UB9qMHk/Fz9IEYG3doJ2lChte/VC8Ias+zuSfOqLx2xo4yDiSPS8cFttdQ /RwA== X-Gm-Message-State: APjAAAVgZHMl7zOHtRi4V+lO3SLqba903a/WMBisokQXHJ945zp++nFn gu5AlaFYxHejfx2eZ+YGPdtAjjtJPFfQoXQnYn1dwZ4omwU= X-Google-Smtp-Source: APXvYqyNTeBKwRUaYmxTiV9l64/sKrPS8P2X+NmLab0kvepGok//ZROkC/IwxWT8rIXibBAMsjuA5xrGDZLiJpCj2UI= X-Received: by 2002:ac8:1c23:: with SMTP id a32mr5903287qtk.119.1579632216833; Tue, 21 Jan 2020 10:43:36 -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: <202001211717.00LHHaxP3280983@darkstar.fourwinds.com> From: Clem Cole Date: Tue, 21 Jan 2020 13:43:10 -0500 Message-ID: To: Jon Steinhart Content-Type: multipart/alternative; boundary="0000000000002916b9059caac9ea" 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" --0000000000002916b9059caac9ea Content-Type: text/plain; charset="UTF-8" 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. --0000000000002916b9059caac9ea Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Jan 21, 2020 at 12:1= 8 PM Jon Steinhart <jon@fourwinds.c= om> wrote:
State, = not the code.

In fact, Masscomp having built the first= MP UNIX box, ran into this problem early on.=C2=A0 Different processor ste= pping had different internal microcode state on the stack after an IRQ.=C2= =A0 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=C2=A0to the 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 tha= t with the 020 and later devices as more people made MP systems.

<= /div>


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

BTS: I don't = remember, but it may have started with the 68010.=C2=A0 =C2=A0Becuase=C2=A0= before that, the 'executor' was wait stated and the fixor handled a= nd fixed the fault so the 68000 never actually saw=C2=A0 fault in the origi= nal Masscomp CPU board.=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 allowed to actually fault and do something else while the = fixor=C2=A0corrected the fault.=C2=A0 But the key is that when the fault wa= s repaired, another executor on a different MPU board could be the processo= r that 'returned' from the fault.=C2=A0 =C2=A0That ended up being a= no-no.
--0000000000002916b9059caac9ea--