Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!husc6!seismo!decuac!cvl!mimsy!chris
From: chris@mimsy.UUCP
Newsgroups: comp.unix.wizards,comp.unix.questions
Subject: Re: Versatec downs UNIBUS under 4.3bsd
Message-ID: <5749@mimsy.UUCP>
Date: Tue, 10-Mar-87 13:01:35 EST
Article-I.D.: mimsy.5749
Posted: Tue Mar 10 13:01:35 1987
Date-Received: Thu, 12-Mar-87 23:37:50 EST
References: <120@asuvax.UUCP>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 32
Keywords: versatec unibus
Xref: utgpu comp.unix.wizards:1308 comp.unix.questions:1331

In article <120@asuvax.UUCP> system@asuvax.UUCP (Marc Lesure) writes:
>uba0: uba error sr=3000002<UBSTO> fmer=0 fubar=760514
[etc., but with different fubar's]
>uba0: too many zero vectors (5001 in <2 sec)

UBSTO is Slave Time Out.  Zero vectors are devices asking for
interrupt service, then not writing a vector.  This sounds like a
hardware problem, but:

>If I boot under our old 4.2 disk, the versatec runs fine.

You might look at the probe routine in the 4.2 and 4.3 drivers,
and see if you are using different vectors.  Also make sure your
4.2 and 4.3 /sys/conf/PICKLE files list the same `vector's.  We
had an unmodified V80 on a 780, so I listed

	device vp0 at uba? csr 0177510 vector vpintr vpintr

and made sure vpprobe() set cvec to the first vector (I forget
whether this required any changes).

>uba0: reset dz0 dz1 dz2 dz3 vp0 lp0 dmf0 dmf1 dmf2 dmf3
>
>This will knock lp0, the dz's, and the dmf's offline, but vp0 will continue
>to print.

Bizarre.  There are some bugs in the 4.3 uba reset code (but no
more than there are in the 4.2 uba reset code), but none of the
ones I know about quite explain this.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690)
UUCP:	seismo!mimsy!chris	ARPA/CSNet:	chris@mimsy.umd.edu