Adrian Lawrence wrote:
> Jens Pall writes:
>
> > > Check also cat /proc/scsi/scsi.
> > >
> > > Since your drive is reacting to /dev/st0, it sounds as if these entries will
> > > be ok. What does mt status give? That might have to be
> > > mt -f /dev/st0 status .
> > > Check that you have at least mt-st v. 0.05b. The earlier
> > > version had a bug which stopped things working if the -f flag was used.
> >
> > /var/log/syslog says:
> >
> > May 14 20:05:27 phoenix kernel: st: bufsize 32768, wrt 30720, max buffers 4,
> > s/g segs 16.
> > May 14 20:05:27 phoenix kernel: Detected scsi tape st0 at scsi0, channel 0, id
> > 4, lun 0
> >
> > dmesg produces:
> >
> > (scsi0) <Adaptec AHA-294X Ultra SCSI host adapter> found at PCI 10/0
> > (scsi0) Wide Channel, SCSI ID=7, 16/255 SCBs
> > (scsi0) Downloading sequencer code... 419 instructions downloaded
> > scsi0 : Adaptec AHA274x/284x/294x (EISA/VLB/PCI-Fast SCSI) 5.1.10/3.2.4
> > <Adaptec AHA-294X Ultra SCSI host adapter>
> > scsi : 1 host.
> > Vendor: Seagate Model: STT8000N Rev: 3.22
> > Type: Sequential-Access ANSI SCSI revision: 02
> > (scsi0:0:4:0) Synchronous at 10.0 Mbyte/sec, offset 15.
> >
> > cat /proc/scsi/scsi produces:
> >
> > Attached devices:
> > Host: scsi0 Channel: 00 Id: 04 Lun: 00
> > Vendor: Seagate Model: STT8000N Rev: 3.22
> > Type: Sequential-Access ANSI SCSI revision: 02
> >
> > I would say that all this looks pretty promising. The hostadapter is detected
> > correctly and the tape is found.
> >
> > mt --version produces:
> >
> > GNU mt version 2.4.2
> >
> > (is mt-st something else or is that a package you are referring to?)
>
> Ah. Sounds as if you do need mt-st. I got mind from a redhat rpm package:-
>
> --------------------------------------------------------------------
> Name : mt-st Distribution: Manhattan
> Version : 0.5 Vendor: Red Hat Software
> Release : 1 Build Date: Thu Jul 23 13:28:07 1998
> Install date: Thu Nov 19 12:38:12 1998 Build Host: porky.redhat.com
> Group : Utilities/System Source RPM: mt-st-0.5-1.src.rpm
> Size : 65614 License: BSD
> Packager : Andrea Borgia <[EMAIL PROTECTED]>
> Summary : Control magnetic tape drive operation (mt)
> Description :
> The mt program can be used to perform many operations on tapes,
> including rewind, eject, skipping files and blocks, etc.
> /bin/mt
> /sbin/stinit
> /usr/doc/mt-st-0.5
> /usr/doc/mt-st-0.5/COPYING
> /usr/doc/mt-st-0.5/README
> /usr/doc/mt-st-0.5/README.stinit
> /usr/doc/mt-st-0.5/mt-st-0.5.lsm
> /usr/doc/mt-st-0.5/stinit.def.examples
> /usr/man/man1/mt.1
> /usr/man/man8/stinit.8
> --------------------------------------------------------------------
> I guess that you will find a tarball on any sunsite mirror. I think mt-st is
> gnu mt which some additions.
>
Ok, I'll try that.
>
> > With no tape in the drive, mt -f /dev/st0 status, produces:
> >
> > mt: /dev/st0: No medium found
> >
> > No lockup.
> >
> > If I try, mt -f /dev/st0 status, with a tape in the drive, I get:
> >
> > drive type = Generic SCSI-2 tape
> > drive status = 1157628416
> > sense key error = 0
> > residue count = 0
> > file number = 0
> > block number = 0
> > Tape block size 512 bytes. Density code 0x45 (unknown).
> > Soft error count since last status=0
> > General status bits on (41010000):
> > BOT ONLINE IM_REP_EN
>
> Well, I am no expert but it sounds very much as if all the software is working,
> at least at the driver level.
>
> If mt-st doesn't solve your problems, then I suggest that you might look at the
> hardware. However there is one further test that you might do if mt-st
> doesn't help. There is a #define debug or some such in the st driver.
> Recompile the kernel/st-modules with that switch on and see whether the
> messages in your system log throw any light on the problem. You may need a
> real expert to interpret the results if it is not obvious. One problem is that
> the SCSI specifications leave many things open for tape devices. If you still
> have problems, mail to the list again for help. Kai (st driver author) will
> probably reply if things get hairy.
> But I expect that it is something simple, maybe as simple as getting mt-st.
>
> > One thing I noticed though was that after a reboot and I hadn't used the tape
> > at all the following appeared in the log:
> >
> > May 14 06:42:42 phoenix syslogd 1.3-3#26: restart.
> > May 14 06:42:59 phoenix /USR/SBIN/CRON[464]: (mail) CMD (runq)
> > May 14 07:03:00 phoenix /USR/SBIN/CRON[468]: (mail) CMD (runq)
> > May 14 07:23:00 phoenix /USR/SBIN/CRON[472]: (mail) CMD (runq)
> > May 14 07:43:00 phoenix /USR/SBIN/CRON[476]: (mail) CMD (runq)
> > May 14 08:03:00 phoenix /USR/SBIN/CRON[480]: (mail) CMD (runq)
> > May 14 08:09:59 phoenix kernel: SCSI host 0 abort (pid 28) timed out -
> > resetting
> > May 14 08:09:59 phoenix kernel: SCSI bus is being reset for host 0 channel 0.
> > May 14 08:10:01 phoenix kernel: (scsi0:0:4:-1) Unexpected busfree, LASTPHASE =
> > 0xa0, SEQADDR = 0x9e
> > May 14 08:23:00 phoenix /USR/SBIN/CRON[484]: (mail) CMD (runq)
>
> Maybe the tape drive didn't see a reset at reboot time. I guess Doug or one of
> the SCSI experts will be able to explain that. It doesn't sound as if it is
> the main problem, but I might be wrong.
>
> Hope this helps. You have done a search on all the archives and dejanews? I
> think that tis sort of thing has come up before, and if you tape really
> ignore a reset, it will have been reported before? Tim Jones will know,
> but let's try to avaoid taking up his time if the answer is somewhere out
> there already :-)
Yes, I searched some archives and dejanews, but found nothing relating to my
problem. One post talked about having used a STT28000 drive successfully (albeit
with a 2.0.36 kernel), so this is clearly some kind of setup or driver problem (as
you might guess :).
Jens
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
