DAT not working

[Jason Pinkney]

> [snip]
> 
>>> my DAT tape drive used to work with my RHL system
>>> but yesterday, I tried to read a tape and it got
>>> messed up.  At first, it seemed fine.  It started
>>> reading the tape in response to my command:
>>> % tar tf /dev/st0 > listing
>>> but it wouldn't finish and give me a prompt.  Inspection
>>> of "listing" showed that it only made it a little ways
>>> into the tar file (incomplete listing).
>>> Since then, it has been impossible to communicate with.
>>> Even after rebooting, the basic command
>>> % mt -f /dev/st0 status
>>> will either give no response and become a sleeping process
>>> that can't be killed, or it will say:
>>> /dev/st0: No such device or address
>>>
>>> Can you tell where the problem is?

> [snip]
> 
>>> Rick Stevens <rstevens at vitalstream.com>
>>>
>>> Did you change anything?  Did you upgrade to FC1 or something along
>>> those lines?
>>>
>>> The errors you show are SCSI errors.  The most common causes are bad
>>> SCSI bus termination or SCSI controller problem.
>>>
>>> If the SCSI card is a PCI card, try shutting down, opening the box and
>>> reseating the card (unscrew it, unplug it, plug it back in and screw
>>> it down again).  You'd be amazed at how many problems that solves.
>>
>>
>> Rick,
>> thanks for the suggestions.  The DAT drive is working
>> again! (I think it also needed a cleaning.)
> 
> 
> What else did you do to get it to work.  I'm needy and need closure!


Hi Rick,
I don't actually have a PCI card, but I opened up my Dell
PC anyways. I took out the internal Archive Python 6408-XXX
DAT drive (which I installed 2 years ago), dusted it off a bit, and 
reconnected it.  I also checked the connections to the adapter card 
(Adaptec SCSI Card19160).

On reboot, I gave it "mt -f /dev/st0 status" commands and it
gave the expected responses both before and after tape insertion.
Then, to make a listing of files on a tarfile on my DDS4 tape, I do:
% mt -f /dev/st0 setblk 0
% mt -f /dev/nst0 fsf 1
% tar tf /dev/nst0 > listing
I gave this last command yesterday, and it is still running!
So all is not perfect!  I'm expecting read rates of ~2 MB/s,
and this is just a listing of a 9GB tarfile.  This may have to
do with the small record size its using "tar: Record size = 1 blocks",
or my "setblk" command.  The "setblk" command is an obscure fix
that I learned from somebody for using DAT tapes on linux.  Without it,
I cannot run DDS2, or DDS3 tapes.  (My tar command probably would
have worked better without "setblk 0", but I thought it was needed
for DDS4 too at the time.)  I know that my tar command is
still working because I type "tail listing" and see new filenames.

My previous problems began when I became impatient.  During
this tar command, the tape occasionally makes noises like its
done or stopped (the orange light goes off).  But, if I leave
it alone, it will come back again on its own (at least it does
now)!  When I looked at the list and saw that only about 20
files had been generated in ~30 minutes, I thought it was
in la la land.  So I tried to kill it and eject the tape,
and it got in an even more hopeless state.  The connections
may not have had anything to do with it.
	Also, I still get the ominous error on reboot:
"kmod: failed to exec /sbin/modprobe -s -k scsi_hostadapter, errno = 2"
Any clue what this means?

What's most annoying is that a simple ^C would work to stop
a SCSI tape command in its tracks (no pun intended) on a SUN,
and it would reinitialize itself promptly.
But here it doesn't do much at all.

When this job finally ends, I'll clean the drive
again, and omit the "setblk 0" command when using DDS4.

thanks for the interest,
Jason

-- 
Dr. Jason Pinkney
Assistant Professor of Physics and Astronomy
Ohio Northern University
419-772-2740   http://www2.onu.edu/~j-pinkney