Re: kern/55965: st(4) on adaptec fails to 'mt erase'

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

The following reply was made to PR kern/55965; it has been noted by GNATS.

From: Manuel Bouyer <bouyer%antioche.eu.org@localhost>
To: Hauke Fath <hauke%Espresso.Rhein-Neckar.DE@localhost>
Cc: gnats-bugs%netbsd.org@localhost, kern-bug-people%netbsd.org@localhost, gnats-admin%netbsd.org@localhost
Subject: Re: kern/55965: st(4) on adaptec fails to 'mt erase'
Date: Sat, 30 Jan 2021 23:43:50 +0100

 On Sat, Jan 30, 2021 at 11:30:27PM +0100, Hauke Fath wrote:
 > At 22:39 Uhr +0100 30.01.2021, Manuel Bouyer wrote:
 > >> Funky... With timeout bumped to 60s, an 'mt erase' returns after 35s, which
 > >
 > >And did you get the timeout message from the kernel ?
 > 
 > No, not that time... But the next command (the 'mt status') then errored
 > out like below.
 > 
 > >> the drive audibly spent mounting the tape. Then - nothing, no tape running
 > >> for erase.
 > >>
 > >> An 'mt status' then leads to a
 > >>
 > >> [ 1433.8827963] st0(ahc0:0:5:0):  DEFERRED ERROR, key = 0x3
 > >> [ 1433.8827963] st0(ahc0:0:5:0):  Check Condition on CDB: 0x00 00 00 00
 > >>00 00
 > >> [ 1433.9128026]     SENSE KEY:  Media Error
 > >> [ 1433.9128026]      ASC/ASCQ:  ASC 0x80 ASCQ 0x01
 > >> [ 1433.9128026] st0: mount error (sense key=3) - terminating mount session
 > >
 > >that looks like a red flag; did you try with another tape ?
 > 
 > I did, and also with the other drive in the case. I can happily dd(1) data
 > to and from the tape, though, and suspect the above might be the drive
 > getting confused about the aborted erase.
 > 
 > Next, I went all out, and increased the timeout in scsipi_prevent() to 4
 > hours (four). Now the drive is happily running the tape, presumably erasing
 > away.
 > 
 > That's a workaround. But mt is hanging there, whereas st.c says erase is an
 > asynchronous operation? And why would the operation be governed by the
 > scsipi_prevent() timeout? Isn't that a bit overly generic, when it has to
 > accommodate any and all devices?
 
 Hum. I've not looked at the code but maybe the erase is started and
 the ioctl returns. Then mt exists, causing the device from being
 closed. This causes scsipi_prevent() from being called, and this
 command waits for the erase to complete.
 
 Baybe you should use /dev/ernst0 instead of rst0 ?
 
 -- 
 Manuel Bouyer <bouyer%antioche.eu.org@localhost>
      NetBSD: 26 ans d'experience feront toujours la difference
 --