4.2bsd uba question (too many zero v

[terryl at tekcrl.UUCP]

>Gawd - I thought I was the only person who had this problem.
>We had that here at Siemens and it turned out to be a marital problem between
>a DZ11 and the 3COM board.  In the process of moving the 3COM board to
>another slot in the backplane, I removed one DZ11 and the problem went away!
>I put the DZ11 back in (anywhere, in fact) and the problem resurfaced.  Ok,
>so I cann my DEC Field Service and they bring out another DZ.  Of course,
>they want to run diagnostics to prove that my board is bad (any board) and
>of course nothing is wrong.  I told them to just replace the ``bad'' board
>with the new one and I'll be happy.  After a while (a few hours) they simply
>agree; they do the swap and leave.  Now, I don't think that the were
>convinced that there was a problem with that DZ, so they might have put it
>back in circulation.  Maybe you got it!


     Frankly, I agree with you 100%, but would like to add a little info to
the fray: almost all of DEC's diagnostics run standalone, and check only one
device at a time. They will not find any problems associated with timings
between two or more boards, whether they are the same type or different. We
went through a similar problem here with our 750 a couple of months ago:
We had two unibus's (unibi?) on our system, along with one massbus with a
couple of eagles with Emulex's SC750 controller, and an RA81 on one unibus,
with a TU80 on the other unibus. First booted up the system with the RA81,
and then genned a system with the eagles on the massbus as root. Did a dump
of the root on the RA81 (which worked fine), but when trying to do a restor
onto one of the eagles, the system crashed with reserved operand faults.
Well, we scratched our heads and called our local support group. Luckily,
they had run into this problem before and knew what to do. The whole upshot
of this was that before the system was released to us, they ran diagnostics
for two days with no problems, BECAUSE ALL DIAGNOSTICS RUN STANDALONE testing
one device at a time. BTW, the fix was to put the massbus at a different bus
arbitration level (other than the standard) because the second unibus on a
750 is at a fixed bus arbitration level.


					Terry Laskodi
					     of
					Tektronix