dyer@spdcc.COM (Steve Dyer) (12/28/89)
Well, as several people said, the Exabyte 8mm cartridge unit
works out of the box on the DECStation 3100 with Ultrix 3.1,
provided you have the dip switches set correctly (and possibly,
a late-model Exabyte with uptodate ROMs.) For the record, my
dip switch settings as recommended by Exabyte tech support are:
(SW3 ON--even byte disconnect, SW4 ON--no busy enable,
SW5 ON--variable block mode on power up.) Everything else is set to off.
I've been using it now for most of the evening, and I've
seen a few glitches which I'd like to compare with other
people's experience:
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?
--
Steve Dyer
dyer@ursa-major.spdcc.com aka {ima,harvard,rayssd,linus,m2c}!spdcc!dyer
dyer@arktouros.mit.edu, dyer@hstbme.mit.edudyer@spdcc.COM (Steve Dyer) (12/29/89)
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