> On Oct 10, Kai M{kisara wrote:
>
...
> I replaced every return (-E....) by RETURN (...) and used
>
> #define RETURN(r) do { printk("--> st:RETURN %d in line %d\n",r,__LINE__); return (r); } while (0)
>
> (so line number are off by one for 2.1.125) and when trying to read
> past EOF/EOT for QIC150 I got:
> -------------------------------------------------------------------------------
> st0: Block limits 512 - 512 bytes.
> st0: Mode sense. Length 11, medium 6, WBS 10, BLL 8
> st0: Density 0, tape length: 0, drv buffer: 1
> st0: Block size: 512, buffer size: 32768 (64 blocks).
> aha1542.c: Trying device reset for target 2
> Sent BUS RESET to scsi host 1
> st0: Error: 8000002, cmd: 8 1 0 0 40 0 Len: 32768
> extra data not valid Current error st09:00: sense key Unit Attention
> Additional sense indicates Power on, reset, or bus device reset occurred
> --> st:RETURN -5 in line 217
> st0: Sense: 70 0 6 0 0 0 0 16
> st0: Tape error while reading.
> -------------------------------------------------------------------------------
>
> which is the RETURN (-EIO) at the very end of st_chk_result() in line 216.
> no other error returns show up in st.c.
>
This is actually the correct thing to return. Unit Attention sense data is
returned from the first command after the device is reset. Many drives
rewind the tape when reset and it is best to signal an error so that the
user can make sure that the tape is in the correct location.
Actually, the middle-level SCSI driver sets a flag (was_reset) so that the
tape driver does not allow any more commands until the user does something
that explicitly positions the tape to a known position.
If the drive disappears after the reset, that is a bug (somewhere).
>
> note that the `aha1542.c: Trying device reset...' shows up before any
> debug message from st.c or error in st.c
>
The driver has printed several debug messages from scsi_tape_open(). The
command attempted before reset was trying to read 64 blocks of fixed
length (512 bytes) from the tape.
Kai
-
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/