Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!ihnp4!zehntel!tektronix!hplabs!hao!seismo!brl-tgr!tgr!rbbb@RICE.ARPA From: rbbb@RICE.ARPA Newsgroups: net.unix-wizards Subject: Oops, tbuf errors again Message-ID: <6596@brl-tgr.ARPA> Date: Sun, 16-Dec-84 04:36:41 EST Article-I.D.: brl-tgr.6596 Posted: Sun Dec 16 04:36:41 1984 Date-Received: Wed, 19-Dec-84 00:37:53 EST Sender: news@brl-tgr.ARPA Organization: Ballistic Research Lab Lines: 20 My office-mate says that we replaced the L003 module, not the L001 module. He also says (in his dogmatic way) that several boards can cause that problem, since (in general) timing errors often show up in the tbuf. So I don't really know - I still think (unless someone will step forward and say, "no, we did that, and things got worse for us") that the best route is to get the PCS, and always run with the latest microcode. Failing that, try to convince your service droid to replace that board, and maybe others (we used the line, "look, if you say that board is fine, then how does it harm YOU to trade it for another working board?"). It is also possible that DEC came up with the microcode patches so that they could use the crufty boards, and perhaps board-swapping will no longer work so well (since you might get a crufty board). I'm tired of so many bogus hardware rumours and so much third-hand hearsay floating around on the net, and I'm sorry that I was wrong on that other message. drc