>... mtx next causes a SCSI bus reset and returns an error
>status although the next tape was loaded. ...
I don't see a SCSI bus reset in the following. Just an error return.
Did you really mean a reset (which is pretty serious)?
>[root@amanda ~]# mtx -f /dev/sg4 next
>Unloading Data Transfer Element into Storage Element 4...done
>Loading Storage Element 5 into Data Transfer Element...mtx: Request
>Sense: 70 00 02 00 00 00 00 14 00 00 00 00 04 00 00 00 00 00 00 00
FYI, this translates to:
00-70: the current (as compared to a deferred) error is being reported
01-00: blah
02-02: the sense key is 2 (not ready)
03-00: blah
04-00: blah
05-00: blah
06-00: blah
07-14: additional sense length
08-00: blah
09-00: blah
10-00: blah
11-00: blah
12-04: additional sense code (ASC)
13-00: additional sense code qualifier (ASCQ)
.....: blah
The sense key/ASC/ASCQ triple usually has a mapping table in the hardware
documentation. For my robot (which is probably close enough in this
case), it says "logical unit is not ready, cause not reportable".
>mtx: MOVE MEDIUM from Element Address 6 to 1 Failed
>
>The error says the move failed, but in fact address 6 is loaded right
>now.
I know zip about mtx, but the basic driver code for my robot (akin to
mtx) did not have sufficient timeouts to allow for "long" movements.
Cranking them up (from 30 seconds to 90 or so, as I recall) made my life
a **whole** lot better :-).
When watching the box, how long does it take to do a complete movement,
i.e. unload one tape, put it away, put the next one in the drive and
wait for it to go ready? Are there tweakable timeouts in mtx, either
the source or command line?
What happens if you rewind the tape first? What about unloading it?
Maybe mtx isn't taking the extra time needed to get the old tape out
before doing the next one into account?
Are some of the tapes misbehaving when loaded? For instance, it
takes about 60 seconds to load a DLT drive. But if it doesn't like the
catalogue at the front of the tape (like when it's brand new?), it works
really, really hard to make sure it's never going to be able to read it,
all of which takes a while.
As I said, this is all pure guesswork.
>"Jonathan F. Dill"
John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
