kern/42214: Tape EOF logic incorrect for drive

[jpeterson275%comcast.net@localhost]

>Number:         42214
>Category:       kern
>Synopsis:       Tape EOF logic incorrect for drive
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Oct 22 21:50:00 +0000 2009
>Originator:     Jesse Peterson
>Release:        5.0
>Organization:
>Environment:
NetBSD localhost 5.0 NetBSD 5.0 (GENERIC_SDBG) #16: Thu Oct 22 10:57:57 PDT 
2009  root@localhost:/src/sys/arch/i386/compile/GENERIC_SDBG i386
>Description:
The st(4) driver persists the "at filemark" state through two read() 
calls. Expected behavior is (for one filemark):

Read data (returns read data size)
Read data (returns 0 for EOF)
Read data (returns read data after tape filemark)

However with this tape drive (see below) I get this progression:

Read data (returns read data size)
Read data (returns 0 for EOF)
Read data (returns 0 for EOF [again?])
Read data (returns read data after tape filemark)

This is a Sony SDX-420C AIT-1 drive connected via USB Bulk-Only or IEEE 1394 
SBP-2 (internally is an ATAPI drive in a FW/USB enclosure).

I'd guess that
some drives report the "at filemark" state when the last (successful) 
block was read (e.g. the /next/ block is a filemark), but this drive
seems to report "at filemark" when the drive actually is on a filemark 
(and thus, the next read request is the data after the filemark). Just
a guess, though.

The manual (which describes its ATAPI command interface of most
interest its description of the READ command) is here:
http://sony.storagesupport.com/node/394


>How-To-Repeat:
# first, setup tape:
mt rewind
dd if=/dev/urandom of=/dev/nrst0 count=1
dd if=/dev/urandom of=/dev/nrst0 count=1
mt weof

# then test
dd if=/dev/nrst0 of=/dev/null count=1
1+0 records in
1+0 records out
512 bytes transferred in 3.133 secs (163 bytes/sec)
        [Good result]
dd if=/dev/nrst0 of=/dev/null count=1
0+0 records in
0+0 records out
0 bytes transferred in 0.008 secs (0 bytes/sec)
        [Good result: Note the fmark=0x1 in debug sense data]
dd if=/dev/nrst0 of=/dev/null count=1
0+0 records in
0+0 records out
0 bytes transferred in 0.008 secs (0 bytes/sec)
        [Bad result: last read placed the tape at the end of the EOF]
dd if=/dev/nrst0 of=/dev/null count=1
1+0 records in
1+0 records out
512 bytes transferred in 3.133 secs (163 bytes/sec)
        [Should have been the last result: drive EOF state cleared with last 
call]

>Fix:
This patch fixes the problem for this tape drive. Note that this is
with fixed blocking mode: this drive doesn't seem to support
variable sized blocks. I don't know if this should be a st(4) drive
quirk or what, but this gets the expected results on this drive.

--- st.c.orig   2008-11-19 18:50:27.000000000 -0800
+++ st.c        2009-10-22 14:33:56.000000000 -0700
@@ -1214,12 +1214,8 @@
                                                continue;
                                        }
                                } else {
-                                       BUFQ_GET(st->buf_queue);
-                                       bp->b_resid = bp->b_bcount;
-                                       bp->b_error = 0;
+                                       /* clear the filemark for this read */
                                        st->flags &= ~ST_AT_FILEMARK;
-                                       biodone(bp);
-                                       continue;       /* seek more work */
                                }
                        }
                }