chris@umcp-cs.UUCP (Chris Torek) (10/13/85)
Your problem with the mysterious hangs is almost surely the infamous UDA50 microcode bug. After the system hangs, open up the Unibus box and take a look at the UDA50 lights. They will be stuck in an odd state (normal state is a little ripple down four LEDs, and another four blinking between 1010 and 1000, or something like that). I surmise that the problem is caused by sending MSCP GTUNT commands to the controller faster than it can handle them. I think this was the old timing bug that DEC `fixed' long ago, and that the timing window was merely tightened down to the point where 780s no longer invoked it---but 785s are faster. A `quick hack' fix is to put a DELAY(1000) (more or less; 1000 seems to work but is likely higher then necessary) under the `case M_OP_GTUNT|M_OP_END' in /sys/vaxuba/uda.c$udrsp(). The right way to fix the the problem is to stop hammering GTUNT commands at the UDA50; they are necessary only because the driver is not using the appropriate Unibus resource allocation protocols. Indeed, this last is the source of another problem with the UDA50 driver: it causes frequent data-late errors on RK07s, as it ignores the Unibus lock normally granted to transfers on RK disks. Someday, when my input event queue drops back below the high water mark, I shall fix that. . . . -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@mimsy.umd.edu