Re: Zip 100 ATAPI not working, "qc timeout" and "failed to clear UNIT ATTENTION"

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

 



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




[Index of Archives]     [Linux Filesystems]     [Linux SCSI]     [Linux RAID]     [Git]     [Kernel Newbies]     [Linux Newbie]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Samba]     [Device Mapper]

  Powered by Linux