A E Lawrence wrote:
> Jens Pall wrote:
> >
> > 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).
>
> Sorry, I am not enough of an expert to interpret those results. If using
> the wrong tape causes the scsi bus to lock, I guess that the firmware is
> badly broken.
>
> BTW, I had not appreciated that this was an *external* drive. I think
> getting a good scsi transmission line is much harder in that case. And I
> can't remember whether the Adaptec sorts out the problem of attaching a
> narrow device to a wide connector. Do you terminate the unused upper 8
> bits at the end of the cable? Or maybe you can tell the Adaptec not to
> drive or sense the upper lines...
Oh, I see.. sorry :). I wasn't clear enough about that. It is an external drive.
What I did was to move the tape and controller to a Windows machine and tested it
there.
Alas, I got the same mysterious hang. Now that was strange. I was beginning to think,
as
you say, that the external cable might be the problem. My next thought was to connect
the drive to the internal 50 pin bus, but I didn't have a 50 pin cable. I then thought
that it wouldn't hurt to take a close look at the external cable. I unplugged it and
examined the connectors. What I found was that one pin in the centronics plug was bent.
Trying to straighten it out broke it halfway of, so I guess I'll have to get a new
cable. This just proves again the old saying: Check your cables!
>
>
> That said it sounds like firmware/software woes. I think that Kai
> Makisara reads the list and he is the best person to advise.
> Of course, there may be known problems with that drive? Have you checked
> http://www.linuxtapecert.org/ ? But the site is still under construction
> and wasn't working yet when I looked yesterday. Tim Jones is building it
> in his spare time.
>
> Sorry not to be more help, but at leat you have now gathered a lot of
> diagnostics.. :-)
>
Well, thanks a lot for your help. I really appreciate it. I'll be in touch if a new
cable works.
Jens
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
