750 tbuf error revisited - help with micropatch?

[rbbb at RICE.ARPA]

From:  David Chase <rbbb at RICE.ARPA>

This 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