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.
>
I downloaded mt-st and installed it. I get the same results, i.e. the mt command
locks up.
So, my last resort is to enable debuging in the st module. By doing this I get the
following messages in syslog when I try the status command:
May 15 14:04:18 phoenix kernel: st0: Error: 28000002, cmd: 0 0 0 0 0 0 Len: 0
May 15 14:04:18 phoenix kernel: extra data not valid Current error st09:00: sense
key Unit Attention
May 15 14:04:18 phoenix kernel: Additional sense indicates Not ready to ready
transition (medium may have changed)
May 15 14:04:18 phoenix kernel: st0: Block limits 9 - 65536 bytes.
May 15 14:04:18 phoenix kernel: st0: Mode sense. Length 11, medium b6, WBS 10, BLL
8
May 15 14:04:18 phoenix kernel: st0: Density 45, tape length: 0, drv buffer: 1
May 15 14:04:18 phoenix kernel: st0: Block size: 512, buffer size: 32768 (64
blocks).
May 15 14:04:18 phoenix kernel: st0: Rewinding tape.
After I reboot to free the sleeping mt, I tried to do a mt rewind (I linked
/dev/tape to /dev/st0 as /dev/tape is mt's default device), just to try directly
what the driver is trying to do when it hangs. Syslog now got:
May 15 14:21:25 phoenix kernel: st: bufsize 32768, wrt 30720, max buffers 4, s/g
segs 16.
May 15 14:21:25 phoenix kernel: Detected scsi tape st0 at scsi0, channel 0, id 4,
lun 0
May 15 14:21:25 phoenix kernel: st: Buffer size 32768 bytes, write threshold 30720
bytes.
May 15 14:21:25 phoenix kernel: st: Allocated tape buffer 0 (32768 bytes, 1
segments, dma: 1, a: c0fb8000).
May 15 14:21:25 phoenix kernel: st: segment sizes: first 32768, last 32768 bytes.
May 15 14:21:25 phoenix kernel: st: Allocated tape buffer 1 (32768 bytes, 1
segments, dma: 1, a: c0fb0000).
May 15 14:21:25 phoenix kernel: st: segment sizes: first 32768, last 32768 bytes.
May 15 14:21:25 phoenix kernel: st0: Error: 28000002, cmd: 0 0 0 0 0 0 Len: 0
May 15 14:21:25 phoenix kernel: extra data not valid Current error st09:00: sense
key Unit Attention
May 15 14:21:25 phoenix kernel: Additional sense indicates Not ready to ready
transition (medium may have changed)
May 15 14:21:25 phoenix kernel: st0: Block limits 9 - 65536 bytes.
May 15 14:21:25 phoenix kernel: st0: Mode sense. Length 11, medium b6, WBS 10, BLL
8
May 15 14:21:25 phoenix kernel: st0: Density 45, tape length: 0, drv buffer: 1
May 15 14:21:25 phoenix kernel: st0: Block size: 512, buffer size: 32768 (64
blocks).
May 15 14:21:25 phoenix kernel: st0: Rewinding tape.
The error messages Error: 28000002 and st09:00: sense key Unit Attention don't tell
me anything. Maybe someone else can read somthing from them?
This is all done in asynchronous mode and at 10MB/s.
Is it possible that the type of the tape is wrong and causing all this? I am using
a Sony QTR-4 tape (4/8 GB).
Jens
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
