From: Niklas Cassel <cassel@kernel.org>
To: Philip Pemberton <lists@philpem.me.uk>
Cc: linux-ide@vger.kernel.org
Subject: Re: Zip 100 ATAPI not working, "qc timeout" and "failed to clear UNIT ATTENTION"
Date: Wed, 19 Feb 2025 16:48:56 +0100 [thread overview]
Message-ID: <Z7X9aPpgBjNln9CJ@ryzen> (raw)
In-Reply-To: <9253b1b9-0f92-45ab-8b8a-44064ffa9cd9@philpem.me.uk>
Hello Philip,
On Tue, Feb 18, 2025 at 03:05:49AM +0000, Philip Pemberton wrote:
> When the function atapi_eh_clear_ua() [libata-eh.c:3294] is entered, the
> driver sends a SCSI "TEST UNIT READY" (scsicmd 0) CDB inside an ATAPI packet
> command (cmd 0xa0):
>
> [ 4.408044] ata4: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
> [ 4.408107] ata4.00: direction 2 dmadir 0
> [ 4.414687] ata4.00: ATAPI: IOMEGA ZIP 100 ATAPI, 12.A, max PIO3,
> CDB intr
> [ 4.414815] ata4.00: applying bridge limits
> [ 4.414870] ata4.00: direction 3 dmadir 0
> [ 4.415153] ata4.00: direction 2 dmadir 0
> [ 4.421662] ata4.00: configured for PIO3
> [ 4.421768] ata4.00: About to do TEST UNIT READY
> [ 4.421770] ata4.00: CDB[0] = 0x00
> [ 4.421824] ata4.00: CDB[1] = 0x00
> [ 4.421876] ata4.00: CDB[2] = 0x00
> [ 4.421929] ata4.00: CDB[3] = 0x00
> [ 4.421981] ata4.00: CDB[4] = 0x00
> [ 4.422033] ata4.00: CDB[5] = 0x00
> [ 4.422085] ata4.00: CDB[6] = 0x00
> [ 4.422138] ata4.00: CDB[7] = 0x00
> [ 4.422190] ata4.00: CDB[8] = 0x00
> [ 4.422242] ata4.00: CDB[9] = 0x00
> [ 4.422294] ata4.00: CDB[10] = 0x00
> [ 4.422347] ata4.00: CDB[11] = 0x00
> [ 4.422399] ata4.00: CDB[12] = 0x00
> [ 4.422452] ata4.00: CDB[13] = 0x00
> [ 4.422504] ata4.00: CDB[14] = 0x00
> [ 4.422556] ata4.00: CDB[15] = 0x00
> [ 4.422609] ata4.00: direction 3 dmadir 0
> [ 4.423185] ata4.00: TEST UNIT READY err_mask=1 sense_key=6
>
> This fails with err_mask=1 (AC_ERR_DEV=1, "device reported error", defined
> in libata.h). Sense key 6 is UNIT ATTENTION, per
> <https://www.t10.org/lists/2sensekey.htm>.
>
> The code then goes on to send a SCSI "REQUEST SENSE" CDB (scsicmd 0x03) in
> an attempt to clear the UNIT ATTENTION flag. It's this command which times
> out:
>
> [ 4.423239] ata4.00: CDB[0] = 0x03
> [ 4.423295] ata4.00: CDB[1] = 0x00
> [ 4.423347] ata4.00: CDB[2] = 0x00
> [ 4.423399] ata4.00: CDB[3] = 0x00
> [ 4.423452] ata4.00: CDB[4] = 0x60
> [ 4.423504] ata4.00: CDB[5] = 0x00
> [ 4.423556] ata4.00: CDB[6] = 0x00
> [ 4.423609] ata4.00: CDB[7] = 0x00
> [ 4.423661] ata4.00: CDB[8] = 0x00
> [ 4.423713] ata4.00: CDB[9] = 0x00
> [ 4.423765] ata4.00: CDB[10] = 0x00
> [ 4.423817] ata4.00: CDB[11] = 0x00
> [ 4.423870] ata4.00: CDB[12] = 0x00
> [ 4.423922] ata4.00: CDB[13] = 0x00
> [ 4.423974] ata4.00: CDB[14] = 0x00
> [ 4.424026] ata4.00: CDB[15] = 0x00
> [ 4.424079] ata4.00: direction 2 dmadir 0
> [ 9.556040] ata4.00: qc timeout after 5000 msecs (cmd 0xa0 cdb[0] 0x3)
> [ 9.556155] ata4.00: REQUEST SENSE err_mask=5 sense_key=6
If we look at code in atapi_eh_clear_ua(), it is a for loop that will run
for up to ATA_EH_UA_TRIES number of times.
For e.g. the case with your PIIX controller, it manages to clear Unit
Attention successfully on the second try.
The reason why it does not perform more than one try on your AHCI
controller is because atapi_eh_request_sense() returns AC_ERR_TIMEOUT,
which causes the code to return and not perform additional iterations/retries.
Looking at atapi_eh_request_sense(), I can see this code:
https://github.com/torvalds/linux/blob/v6.14-rc3/drivers/ata/libata-eh.c#L1545-L1553
/* is it pointless to prefer PIO for "safety reasons"? */
if (ap->flags & ATA_FLAG_PIO_DMA) {
tf.protocol = ATAPI_PROT_DMA;
tf.feature |= ATAPI_PKT_DMA;
} else {
tf.protocol = ATAPI_PROT_PIO;
tf.lbam = SCSI_SENSE_BUFFERSIZE;
tf.lbah = 0;
}
Looking at ahci.c, we can see that all boards have .flags set to:
AHCI_FLAG_COMMON
which is defined as:
AHCI_FLAG_COMMON = ATA_FLAG_SATA | ATA_FLAG_PIO_DMA |
ATA_FLAG_ACPI_SATA | ATA_FLAG_AN,
ATA_FLAG_PIO_DMA is defined as:
ATA_FLAG_PIO_DMA = (1 << 7), /* PIO cmds via DMA */
Which, IIUC, seems to mean that atapi_eh_request_sense() will use DMA even
for a port configured to use PIO.
This flag does not appear to be set for any board in the PIIX driver.
Perhaps your could try with something like:
diff --git a/drivers/ata/libata-eh.c b/drivers/ata/libata-eh.c
index 3b303d4ae37a..bc2a317c97da 100644
--- a/drivers/ata/libata-eh.c
+++ b/drivers/ata/libata-eh.c
@@ -1543,7 +1543,7 @@ unsigned int atapi_eh_request_sense(struct ata_device *dev,
tf.command = ATA_CMD_PACKET;
/* is it pointless to prefer PIO for "safety reasons"? */
- if (ap->flags & ATA_FLAG_PIO_DMA) {
+ if (0) {
tf.protocol = ATAPI_PROT_DMA;
tf.feature |= ATAPI_PKT_DMA;
} else {
To see if NOT using DMA for PIO cmds makes any difference.
>
> Back onto the PIIX the drive initialises, then there seem to be a couple of
> non-ATAPI commands:
>
> [ 4.564157] ata4.00: ATAPI: IOMEGA ZIP 100 ATAPI, 12.A, max PIO3,
> CDB intr
> [ 4.564223] ata4.00: applying bridge limits
> [ 4.564270] ata4.00: direction 3 dmadir 0
> [ 4.566480] ata4.00: direction 2 dmadir 0
Perhaps you would want to figure out what these commands are,
to know if the lack of these commands on AHCI could be related
to things not working on AHCI.
Kind regards,
Niklas
next prev parent reply other threads:[~2025-02-19 15:48 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-08 12:52 Zip 100 ATAPI not working, "qc timeout" and "failed to clear UNIT ATTENTION" Philip Pemberton
2025-01-08 13:42 ` Niklas Cassel
2025-01-08 13:45 ` Niklas Cassel
2025-01-09 11:36 ` Philip Pemberton
2025-01-08 14:05 ` Niklas Cassel
2025-01-09 7:17 ` Hannes Reinecke
2025-01-09 11:33 ` Philip Pemberton
2025-01-09 13:22 ` Niklas Cassel
2025-01-09 15:06 ` Philip Pemberton
2025-01-09 11:35 ` Philip Pemberton
[not found] ` <e1985151-c206-4be1-91c1-92eac16f6236@philpem.me.uk>
2025-01-09 12:22 ` Niklas Cassel
2025-01-09 15:31 ` Philip Pemberton
2025-01-17 13:37 ` Niklas Cassel
2025-01-23 13:19 ` Philip Pemberton
2025-01-23 16:19 ` Philip Pemberton
2025-01-24 10:03 ` Niklas Cassel
2025-02-18 3:05 ` Philip Pemberton
2025-02-19 15:48 ` Niklas Cassel [this message]
2025-02-19 16:02 ` Niklas Cassel
2025-02-19 20:04 ` Philip Pemberton
2025-02-21 1:57 ` Niklas Cassel
2025-02-21 17:08 ` Philip Pemberton
2025-02-21 17:24 ` Niklas Cassel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Z7X9aPpgBjNln9CJ@ryzen \
--to=cassel@kernel.org \
--cc=linux-ide@vger.kernel.org \
--cc=lists@philpem.me.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox