rr@gt-cmmsr.UUCP (01/28/87)
I am having trouble with my Cypher 920 tape drive and Emulex TC11 controller
under 4.3 BSD Unix (the problem did not show itself until I brought up 4.3)
on a VAX 11/780. The problem shows itself by giving a Bus Grant Late <BGL>
error whenever I do a tape dump or tar at 1600 bpi. Whenever I use 800 bpi,
everything works fine. DEC replaced the PE card (but not the controller card)
with the same BGL error.
Strange Happenings:
When I take the system down to single user, 1600 bpi works fine
with tar. Dump, however, complains that it runs out of tape <EOT>
after 1666 feet when it has actually run through 2300 feet.
I recompiled the 4.2 version of dump under 4.3 and tried to do a
tape dump in multiuser mode. On occasion I got through a couple
of tapes without getting the EOT error, however, I still got the
BGL error most of the time. Under single user, dump4.2 works
fine.
I only have one tape drive on my system. When I boot the generic
version of unix supplied with the 4.3 distribution, however, I get
2 drives identified (Normally, only 1 shows up):
tm0 at uba0 csr 172520 vec 224, ipl 15
te0 at tm0 slave 0
te1 at tm0 slave 1
All other devices on the system are identified with the correct
number under the generic unix.
If you have any ideas, I would appreciate the help. Thanks.
-Richard
--
Richard Robison
UUCP: rr@gt-cmmsr.UUCP
...!{akgua,allegra,hplabs,ihnp4,seismo,ulysses}!gatech!gt-cmmsr!rr
INTERNET: rr@cmmsr.gatech.edudjh@cci632.UUCP (02/02/87)
In article <31585@gt-cmmsr.GATECH.EDU>, rr@gt-cmmsr.UUCP writes: > > I am having trouble with my Cypher 920 tape drive and Emulex TC11 controller > under 4.3 BSD Unix (the problem did not show itself until I brought up 4.3) > on a VAX 11/780. The problem shows itself by giving a Bus Grant Late <BGL> > error whenever I do a tape dump or tar at 1600 bpi. Whenever I use 800 bpi, > everything works fine. DEC replaced the PE card (but not the controller card) > with the same BGL error. We also ran into the same problem here. As it turns out, the 4.3bsd uda50 driver increases the DMA Burst size from the default of 0 to 3. This causes it to hog the bus for extended periods, during which the TC-11 stretches out the Iter-Record Gap. To fix the problem change the line the reads: #define UDABURST 4 to read: #define UDABURST 2 I'm writing up a formal bug report to send to Berkeley. Dan Hazekamp Computer Consoles Inc. Rochester , NY seismo!rochester!cci632!djh
chris@mimsy.UUCP (02/07/87)
In article <908@cci632.UUCP> djh@cci632.UUCP (Daniel J. Hazekamp) writes: >... As it turns out, the 4.3bsd uda50 driver increases the DMA Burst >size from the default of 0 to 3. The default is actually 1 word. It is increased to 4 words. This raises the peak transfer rate from ~550K/s to ~750K/s. But anyway... >This causes it to hog the bus for extended periods, during which the >TC-11 stretches out the Inter-Record Gap. To fix the problem change >the line the reads: > > #define UDABURST 4 > >to read: > > #define UDABURST 2 There is an easier way, though it will not last past the next kernel recompile: % adb -w /vmunix udaburst?W 2 _udaburst: _udaburst: 0 = 2 $q % shutdown ... # fastboot If you have multiple UDA50s---why bother; actual I/O rate per drive seems to peak around 125K/s, so 4 drives will consume < 500K/s, which is below the bus rate---but if you have more than one UDA50, this will change only the first's burst rate. Add a `udaburst+4?W 2' to set uda1, and a `udaburst+8?W 2' to set uda2, and so forth. This will, however, slow down your UDA50 accesses. Perhaps a better fix is to mark the TC11 as a `bus hog' a la the RK07s. Alas, the 4.3BSD UDA50 driver ignores the bus locking protocol. A fix (or more precisely, a replacement UDA50 driver) is forthcoming. (Yes, we finally started installing 4.3 here yesterday.) (Another alternative is to move the TC11 and the UDA50 to separate Unibi, of course.) -- 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