Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!burl!ulysses!mhuxj!ihnp4!zehntel!hplabs!sri-unix!rbbb@RICE.ARPA From: rbbb@RICE.ARPA Newsgroups: net.unix-wizards Subject: Re: 750 tbuf error revisited - help with micropatch? Message-ID: <12589@sri-arpa.UUCP> Date: Tue, 2-Oct-84 02:20:13 EDT Article-I.D.: sri-arpa.12589 Posted: Tue Oct 2 02:20:13 1984 Date-Received: Fri, 5-Oct-84 05:45:15 EDT Lines: 51 From: David ChaseThis sounds vaguely like DEC field service bullshit to me. (pardon me while I dig out my magic hat, VMS release notes, and 750 processor description manual) There is a "classic" 750 tbuf error bug, and it is not (to my knowledge) fixed by upgrading the microcode. The symptoms of this bug are: 1) if you can figure out the machine check information, it claims that BOTH tbufs are in error 2) the machine check stack is badly confused 3) the 750 passes diagnostics (usually) This bug was fixed by swapping out boards till we got it right. The line to use on your FE's if "well, if our board's not broken, what does it hurt you to swap?" My officemate claims that there is no way that this bug could be fixed with microcode, and that it is caused by a timing problem between memory, datapath, and translation buffer. I also know that microcode rev 94 does not have this bug, and rev 94 does NOT need the patchable control store. We have rev 94 in 6 750s, and everything works fine. To find your microcode rev, type "E/I/L 3E" to the console microcode. This will get the SID in hex, formatted as SS00MMHH. The MM digits are the microcode rev; interpret them as decimal or hex to get a number close to 94. Other microcode facts: All revs greater than 94 need the PCS option, and thus need to load the microcode from TU58 or elsewhere. The minimum rev for 750s with CI750 from VMS 4.0 on will be 97; as of 3.7, a warning message will be printed. I get the feeling that the later microcode fixes deal with things like fixup after exceptions and CI garbage. The microcode upgrades may be loaded by a running machine (though it won't be possible to boot from CI750 unless it is loaded from TU58). For VMS, this is accomplished by using a dummy device driver WDA0 whose only function is to reload the microcode at system boot and after power failures (if you have battery backup on your memory). This means that it should be possible for Unix, too, given sufficient informed hacking. If anyone knows anything more about the what the various microcode revs fix, or about the workings of WDA0, please let me know so I don't misinform people. I'm about to go tromping through the fiche looking for WDDRIVER, but it is an "optional" device driver, so it may not be there. drc