[643] in linux-scsi channel archive
Re: SCSI tape drive sense key `Blank Check'
daemon@ATHENA.MIT.EDU (Kai Makisara)
Sat Sep 30 15:29:17 1995
Date: Sat, 30 Sep 1995 17:28:15 +0200 (EET)
From: Kai Makisara <makisara@abies.metla.fi>
Reply-To: Kai.Makisara@metla.fi
To: Ian Jackson <iwj10@cus.cam.ac.uk>
Cc: linux-scsi@vger.rutgers.edu
In-Reply-To: <m0syzyH-0002Z0Z@chiark.al.cl.cam.ac.uk>
On Sat, 30 Sep 1995, Ian Jackson wrote:
> What does this mean ?
>
> chiark:~> tar vvtf /dev/st0
> tar: Read error on /dev/st0: I/O error
> tar: At beginning of tape, quitting now
> chiark:~>
>
> Sep 30 12:07:18 chiark kernel: st0: Block limits 1 - 16777215 bytes.
> Sep 30 12:07:18 chiark kernel: st0: Mode sense. Length 11, medium 0, WBS 20, BLL 8
> Sep 30 12:07:18 chiark kernel: st0: Density 13, tape length: 0, drv buffer: 2
> Sep 30 12:07:18 chiark kernel: st0: Block size: 16384, buffer size: 32768 (2 blocks).
> Sep 30 12:07:18 chiark kernel: st0: Error: 28000002, cmd: 8 1 0 0 2 0 Len: 32768
> Sep 30 12:07:18 chiark kernel: Current error st0: sense key Blank Check
> Sep 30 12:07:18 chiark kernel: st0: Sense: f0 0 8 0 0 0 2 a
> Sep 30 12:07:18 chiark kernel: st0: Tape error while reading.
> Sep 30 12:07:18 chiark kernel: st0: Rewinding tape.
>
This means that the drive has encountered tape it "thinks" is blank while
trying to read it.
> I had to uncomment the #define DEBUG at the top of st.c. Before I did
> that I didn't get any kernel messages at all, which seems distinctly
> unhelpful.
>
The tape driver messages are not too voluminous unless DEBUG is nonzero.
The sense data related to the normal operating conditions with tape is not
written out. The advantage is that log space is not wasted. However, the
messages would probably be useful until you get to know the subtle way
Unices tend to use to signal different tape conditions.
You should get a BLANK CHECK message when the tape is at the end of written
data. The "Unix way" to report this to the user is to return zero bytes
for two consecutive reads. So, the kernel message would be redundant.
> The problem only happens some of the time. I don't think I've had it
> happen immediately after putting a tape in; however, I've had it
> happen if the first thing I did after putting a tape in was an `mt -f
> setblk 16384'. The problem also seems to be more likely to occur if
I tried this with my drive and the behaviour of tar was the same. In my
case the reason for the I/O error was that the block size 16384 did not
match the block size on the tape. This may also be your problem although
your drive reports it in a rather peculiar way.
...
> I've also found that sometimes I can get the st driver to refuse even
> to attempt to access the drive, saying `No tape' without flashing the
> drive's activity light. This tends to happen if I insert a cartride
> and try to use it before the drive is really ready.
>
The driver ALWAYS sends a TEST UNIT READY command when the device is
opened (unless the device is already used by another process or a tape
buffer can't be found; in these cases the error code will be EBUSY).
The tape/no tape status is decoded from the sense data returned by this
command. For some reason your drive light does not show this.
Kai
