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

[Niklas Cassel <cassel@kernel.org>]

Hello Philip,

On Thu, Jan 23, 2025 at 04:19:44PM +0000, Philip Pemberton wrote:
> Hi Niklas,
> 
> I've reproduced the issue on an Intel based board (an Asus ROG Rampage
> Formula with a Q
> 
> I tested with the following Debian kernels --
> 
> vmlinuz-6.10.11+bpo-686-pae   (bookworm)
> vmlinuz-6.1.0-30-686-pae      (bookworm)
> vmlinuz-5.10.0-0.deb10.30-686 (buster)
> vmlinuz-4.19.0-27-686-pae     (buster)
> 
> This is with no libata related options on the kernel command line:
> 
> [    0.062948] Kernel command line:
> BOOT_IMAGE=boot/vmlinuz-4.19.0-27-686-pae root=/dev/nfs
> nfsroot=10.0.0.32:/mnt/zfs/debian-nfs-boot,rw ip=dhcp
> initrd=boot/initrd.img-4.19.0-27-686-pae
> 
> Here is the output from the 4.19 kernel when it tries to initialise the Zip
> drive:
> 
> > [    2.549684] scsi host0: ahci
> > [    2.550052] scsi host1: ahci
> > [    2.550260] scsi host2: ahci
> > [    2.550474] scsi host3: ahci
> > [    2.550692] scsi host4: ahci
> > [    2.550905] scsi host5: ahci
> > [    2.551061] ata1: SATA max UDMA/133 abar m2048@0xf9ffe800 port 0xf9ffe900 irq 26
> > [    2.551133] ata2: SATA max UDMA/133 abar m2048@0xf9ffe800 port 0xf9ffe980 irq 26
> > [    2.551204] ata3: SATA max UDMA/133 abar m2048@0xf9ffe800 port 0xf9ffea00 irq 26
> > [    2.551275] ata4: SATA max UDMA/133 abar m2048@0xf9ffe800 port 0xf9ffea80 irq 26
> > [    2.551346] ata5: SATA max UDMA/133 abar m2048@0xf9ffe800 port 0xf9ffeb00 irq 26
> > [    2.551417] ata6: SATA max UDMA/133 abar m2048@0xf9ffe800 port 0xf9ffeb80 irq 26
> > [    2.863069] ata1: SATA link down (SStatus 0 SControl 300)
> > [    3.041029] firewire_core 0000:05:03.0: created device fw0: GUID 001e8c0000b2df93, S400
> > [    3.175068] ata2: SATA link down (SStatus 0 SControl 300)
> > [    3.648939] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
> > [    3.651027] ata3.00: ATA-8: WDC WD1001FALS-00E3A0, 05.01D05, max UDMA/133
> > [    3.651084] ata3.00: 1953525168 sectors, multi 16: LBA48 NCQ (depth 32), AA
> > [    3.653455] ata3.00: configured for UDMA/133
> > [    3.653693] scsi 2:0:0:0: Direct-Access     ATA      WDC WD1001FALS-0 1D05 PQ: 0 ANSI: 5
> > [    4.128939] ata4: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
> > [    4.135599] ata4.00: ATAPI: IOMEGA  ZIP 100       ATAPI, 12.A, max PIO3, CDB intr
> > [    4.135671] ata4.00: applying bridge limits
> > [    4.142464] ata4.00: configured for PIO3
> > [    9.216983] ata4.00: qc timeout (cmd 0xa0)
> > [    9.217040] ata4.00: failed to clear UNIT ATTENTION (err_mask=0x5)
> > [    9.692938] ata4: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
> > [    9.706493] ata4.00: configured for PIO3
> > [   14.848995] ata4.00: qc timeout (cmd 0xa0)
> > [   14.849051] ata4.00: failed to clear UNIT ATTENTION (err_mask=0x5)
> > [   14.849107] ata4.00: limiting speed to PIO2
> > [   15.324938] ata4: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
> > [   15.338347] ata4.00: configured for PIO2
> > [   20.480928] ata4.00: qc timeout (cmd 0xa0)
> > [   20.480984] ata4.00: failed to clear UNIT ATTENTION (err_mask=0x5)
> > [   20.481039] ata4.00: disabled
> > [   20.956939] ata4: SATA link up 1.5 Gbps (SStatus 113 SControl 300)

I little bit weird that we see link up after it has been disabled.

I assume that the device is unusable at this point?


> 
> The messages are the same (albeit with different timings) on every kernel up
> to and including 6.10.11+bpo-686-pae.
> 
> I can try and go back earlier if it would help.
> 
> If it helps any (see my previous message for more), the ata_piix driver on
> an Intel ICH5 Northbridge + 82801EB Southbridge (Aopen EZ65 board) seems to
> work fine on the exact same kernels (literally the same binaries).
> 
> 32/64 bit seems not to be a contributing factor as the AMD B550 machine is
> fully 64-bit (userspace and kernel) and boots via UEFI.

It seems to me that you have found out that your "SATA to PATA adapter + Zip
drive" works fine on recent kernels (v6.10) with the ata_piix driver, but not
with the ahci driver on that same kernel version.

This does suggest to me that there is some bug in the ATAPI specific code in
the ahci driver.

This makes me a little bit surprised, since ahci is usually the most well
tested driver. I'm quite sure that people have CD/DVD ATAPI devices working
with the ahci drivers, so in order to get to the root of this issue, you would
probably need to debug the ahci driver.

I wonder which bug there could be in the ahci driver that allows it to work
with a lot of ATAPI devices, but not your "SATA to PATA adapter + Zip drive".

Did you try using the same mode as the ata_piix machine? e.g. PIO0/PIO3/DMA.

You didn't paste the dmesg from the ata_piix driver.
Did it have ", DMADIR" as part of the string that prints the device?
i.e.
"[    4.135599] ata4.00: ATAPI: IOMEGA  ZIP 100       ATAPI, 12.A, max PIO3, CDB intr"



Kind regards,
Niklas