Problems with SCSI tape... kernel related?

Glenn Lamb (g-lamb@pacbell.net)
Wed, 14 Apr 1999 15:40:29 -0700 (PDT)


(cc'ing the st.c author)

Relevant details first:
kernel: vanilla 2.2.5 (no ac patches)
distrib: redhat 5.2 with 2.2 enhancements
tape drive: exabyte 8500 (Sun)
scsi: advansys

Ok, I'm having a somewhat weird problem. Easiest way to show you is
cut-and-paste (output indented to make it easier to read):

--- (cut here) ---
# mt -t /dev/nst0 eod
# mt -t /dev/nst0 status
File number=3, block number=0, partition=0.
Tape block size 1024 bytes. Density code 0x15 (EXB-8500 or QIC-1000).
Soft error count since last status=0
General status bits on (89010000):
EOF EOD ONLINE IM_REP_EN
# mt -t /dev/nst0 bsfm 2
/dev/nst0: Input/output error
# mt -t /dev/nst0 status
File number=3, block number=0, partition=0.
Tape block size 1024 bytes. Density code 0x15 (EXB-8500 or QIC-1000).
Soft error count since last status=0
General status bits on (89010000):
EOF EOD ONLINE IM_REP_EN
--- (cut here) ---

The first command goes to the end of the tape, the second is supposed
to go to the beginning of the file before your current position. The
two commands together are supposed to move me to the beginning of the
last file on the tape (so I can do a verify of what I just backed up)

Now here comes the weird part. If I don't use the -t option, but in-
stead use the TAPE environment variable or make a softlink to /dev/nst0
from /dev/tape, it works:

--- (cut here) ---
# ln -s /dev/nst0 /dev/tape
# mt eod
# mt status
SCSI 2 tape drive:
File number=3, block number=0, partition=0.
Tape block size 1024 bytes. Density code 0x15 (EXB-8500 or QIC-1000).
Soft error count since last status=0
General status bits on (89010000):
EOF EOD ONLINE IM_REP_EN
# mt bsfm 2
# mt status
SCSI 2 tape drive:
File number=2, block number=0, partition=0.
Tape block size 1024 bytes. Density code 0x15 (EXB-8500 or QIC-1000).
Soft error count since last status=0
General status bits on (81010000):
EOF ONLINE IM_REP_EN
--- (cut here) ---

As you can see, it went back one file (from file 3 to file 2), just what
it was supposed to do.

The problem _only_ happens when the tape is at EOD. If there are files
on the tape past my current point, the bsfm command will work fine.

Obviously this problem isn't a showstopper... I will use an environment
variable or a soft-link to get around it. I'm just curious to what the
problem is; whether it's with mt or with the kernel. Here's the kernel
debugging info from st.o when I try 'mt -t /dev/nst0 bsfm 2':

--- (cut here) ---
Apr 14 15:28:23 rook kernel: st0: Block limits 1 - 245760 bytes.
Apr 14 15:28:23 rook kernel: st0: Mode sense. Length 16, medium 86, WBS 10, BLL 8
Apr 14 15:28:23 rook kernel: st0: Density 15, tape length: 696f90, drv buffer: 1
Apr 14 15:28:23 rook kernel: st0: Block size: 1024, buffer size: 32768 (32 blocks).
Apr 14 15:28:23 rook kernel: st0: Spacing tape backward over 0 filemarks.
Apr 14 15:28:23 rook kernel: st0: Spacing tape forward over 1 filemarks.
Apr 14 15:28:23 rook kernel: st0: Error: 28000002, cmd: 11 1 0 0 1 0 Len: 0
Apr 14 15:28:23 rook kernel: Current error st09:00: sense key Blank Check
Apr 14 15:28:23 rook kernel: Additional sense indicates End-of-data detected
--- (cut here) ---

Now the output from 'ln -s /dev/nst0 /dev/tape; mt eod; mt bsfm 2'

--- (cut here) ---
Apr 14 15:29:25 rook kernel: st0: Block limits 1 - 245760 bytes.
Apr 14 15:29:25 rook kernel: st0: Mode sense. Length 16, medium 86, WBS 10, BLL 8
Apr 14 15:29:25 rook kernel: st0: Density 15, tape length: 696f90, drv buffer: 1
Apr 14 15:29:25 rook kernel: st0: Block size: 1024, buffer size: 32768 (32 blocks).
Apr 14 15:29:25 rook kernel: st0: Spacing tape backward over 2 filemarks.
Apr 14 15:29:26 rook kernel: st0: Spacing tape forward over 1 filemarks.
--- (cut here) ---

I can give 'strace's of the output of mt barfing after it gives the ioctl
call in the first example, but not in the second. The filename that is
opened and the ioctl delivered are the same in both instances, however.

So, does anyone know wtf is going on?

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/