Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/17/84; site godot.UUCP Path: utzoo!watmath!clyde!cbosgd!ihnp4!godot!bruce From: bruce@godot.UUCP (Bruce Nemnich) Newsgroups: net.unix-wizards Subject: Re: Oops, tbuf errors again Message-ID: <638@godot.UUCP> Date: Mon, 17-Dec-84 00:27:59 EST Article-I.D.: godot.638 Posted: Mon Dec 17 00:27:59 1984 Date-Received: Mon, 17-Dec-84 05:35:36 EST References: <6596@brl-tgr.ARPA> Reply-To: bruce@godot.UUCP (Bruce Nemnich) Organization: Thinking Machines, Cambridge, MA Lines: 22 Summary: The L0003 should be the board to swap, since that's where the tbuf and cache are. We had an L0003 swapping session which lasted a week or so in September, I believe. DEC accidentally shipped us an extra L0003 with some other hardware (!). I tried it out, but it was considerably worse than the one I had been running. I had DEC bring in a new one, but it would halt the machine every 8 hours or so. Finally, two boards later, I got one which performed much better than any of them. I kept that until I got rev 7. So, there is a wide range of failure rates. One of the guys installing it said the problem was caused by crosstalk between two layers of the L0003 board. One ECO (don't know which) put jumpers on the board to help but not cure the problem. The PCS microcode 98 claims to fix it by retrying after the first failure per macroinstruction, but trapping on subsequent errors. How can you have "rev 7 hardware" without the PCS? That's part of the FCO. There are two versions, one for those with the user WCS and one for those without. -- --Bruce Nemnich, Thinking Machines Corporation, Cambridge, MA ihnp4!godot!bruce, bjn@mit-mc.arpa ... soon to be bruce@godot.arpa