NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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

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

From: Hauke Fath <hauke%Espresso.Rhein-Neckar.DE@localhost>
To: Manuel Bouyer <>
Cc: Hauke Fath <hauke%Espresso.Rhein-Neckar.DE@localhost>,,,
Subject: Re: kern/55965: st(4) on adaptec fails to 'mt erase'
Date: Sat, 30 Jan 2021 23:30:27 +0100

 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
 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?
 "It's never straight up and down"     (DEVO)

Home | Main Index | Thread Index | Old Index