tbuf par faults and 4.2bsd

[Chris Boylan]

As I said before, the problem I am having with the tbuf errors
is that the flush and return fix doesn't work too well if (as it appears)
it gets a second tbuf par error before it finishes it's work.

What's happening with our 750 is a 4 (MC750_TBPAR) in mcesr and
the thing fails to recover because it gets a second mchk 2 as
it's returning from the trap.  Since I am currently using the stock
4.2bsd ra81 driver I do not get a dump of the system when this
happens but it seems obvious that the second error is probably
another tb parity error.

This being the case, I really don't see what can be done to
fix this problem aside from fixing the source of the problem,
thus my relief that DEC is actually shipping the REV 6 upgrade.

However, the local dec people just talked to me somemore about this
fix and as they are currently distributing it, you CANNOT do
an autorestart and still load the microcode patches.  I am told there
is already one site in Minneapolis running with REV 6 and the new
micro code which they load from a diagnostic cassette and then
reboot by hand.  This brings up two questions:

What is the straight story on the DEC UEG code to reload the
control store in the unix boot cycle being worked on/released?
This sounds too good to be one or more of: free available true.

Do the patches HAVE to be loaded to run?  I'm sure not driving back
into work to reload the control store...  Our night usage is not
enough that we couldn't just run degraded until morning but I would
rather be up...

-- 

	Chris Boylan
	{mgnetp | ihnp4 | uwvax}!dicomed!boylan