Xref: utzoo comp.periphs:2399 comp.sys.dec:2364 comp.unix.ultrix:2408
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!cica!tut.cis.ohio-state.edu!snorkelwacker!spdcc!dyer
From: dyer@spdcc.COM (Steve Dyer)
Newsgroups: comp.periphs,comp.sys.dec,comp.unix.ultrix
Subject: Re: Exabyte "on-line"
Summary: found and fixed
Keywords: DS3100
Message-ID: <1022@ursa-major.SPDCC.COM>
Date: 29 Dec 89 04:50:39 GMT
References: <1006@ursa-major.SPDCC.COM>
Reply-To: dyer@ursa-major.spdcc.COM (Steve Dyer)
Organization: S.P. Dyer Computer Consulting, Cambridge MA
Lines: 52

In article <1006@ursa-major.SPDCC.COM> dyer@ursa-major.spdcc.COM (Steve Dyer) writes:
>It's not clear to me how you get the unit to come "on line"
>once you insert a tape.  Only with a power cycle after inserting
>a new cartridge does the tape actually get threaded, and the
>green LED indicate "on line".  Otherwise, if you insert a 8mm
>cartridge (say, after removing an earlier one) the unit just
>sits there offline.  I must be missing something.
>
>"tar tbf 2 /dev/rmt1h ..." works fine.  "tar" with a blocksize
>of 20 (10240 bytes) causes Ultrix 3.1 to hang completely.
>I'm happy with the first, given that it works.  I am not
>familiar with the optimum blocksize for an 8mm drive.
>Is there one?  Do I end up losing a lot of tape with IRG's
>if I'm not careful?

Like many things, the answer was not at all clearcut, and much of it was
due to the peculiarities of my system.  For one reason or another, none of
which I understand, when I applied the Ultrix 3.0 --> 3.1 upgrade, my kernel
hierarchy under /sys was left in a rather messy state.  Data files created
by earlier 3.0 kernel builds hung around, and in fact, when I built a new
kernel, I wasn't really building a true 3.1 kernel, but a funny amalgam
of 3.1 binaries and 3.0 data files.  (Of course, I hadn't realized this
until today.)

One of the data files was the 3.0 scsi_data.c.  It had an entry for
the Exabyte as a "TZ88", instead of "TZxx", and its symbolic value was
NOT what was expected by the DEC 3.1 scsi driver.  Therefore, in the
routine which performs a "mode select", the Exabyte was told incorrectly,
that it shouldn't autoload a cartridge, and for that matter, it *should*
disconnect on odd bytes, even if I had set the DIP switches to do otherwise.
(I.e., instead of recognizing the Exabyte, it presumably proceeded to send
mode select data appropriate only for TK50-type drives.  Unfortunately, these
meaningless bit patterns had meaning to the Exabyte.)

This explains both the inability to get any tape to load and the drive to
go "online" for the second and all subsequent tapes I inserted, necessitating
a power cycle of the drive (which wipes out the bad mode select data.)

I manually poured through my kernel hierarchy, torching any files which,
by their date, I could associate with the original Ultrix 3.0 installation,
rebuilt a Ultrix 3.1 kernel, and now the drive comes on-line and large
data transfers no longer hang the system.

Talking to Exabyte put me on the right track, although they said that
"Ultrix 3.2" does the right thing.  Once I spoke to a few DECies and
they told me that there warn't no such thing, and they meant 3.1, I retraced
by steps through my kernel build.  Success!

-- 
Steve Dyer
dyer@ursa-major.spdcc.com aka {ima,harvard,rayssd,linus,m2c}!spdcc!dyer
dyer@arktouros.mit.edu, dyer@hstbme.mit.edu