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

[Niklas Cassel <cassel@kernel.org>]

On Wed, Jan 08, 2025 at 02:42:13PM +0100, Niklas Cassel wrote:
> Hello Philip,
> 
> On Wed, Jan 08, 2025 at 12:52:50PM +0000, Philip Pemberton wrote:
> > I'm trying to connect an old Iomega Zip 100 ATAPI to a B550-chipset Ryzen
> > system, to exchange files with an even older system. The Gigabyte B550 AORUS
> > ELITE AX V2 rev1.3 motherboard doesn't have any PATA ports, so I'm using a
> > SATA to PATA adapter.
> > 
> > Sadly it will not work in the B550 system (Kernel 6.8.0-51-generic x86_64,
> > Linux Mint 21.3 based on Ubuntu 22.04). When I have the Zip drive connected,
> > I get the following in dmesg and the sd device never appears:
> > 
> > ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
> > ata3.00: ATAPI: IOMEGA  ZIP 100       ATAPI, 12.A, max PIO3, CDB intr,
> > DMADIR
> > ata3.00: applying bridge limits
> > ata3.00: configured for PIO0
> > ata3.00: qc timeout after 5000 msecs (cmd 0xa0)
> > ata3.00: failed to clear UNIT ATTENTION (err_mask=0x5)
> > 
> > I've included a more complete dmesg at the bottom of this message.
> > 
> > I currently have the following in the kernel command line:
> >   libata.atapi_dmadir=1
> > libata.force=3.00:atapi_dmadir,dump_id,nodmalog,noncq,pio0
> > 
> > I started with only having the DMADIR option as suggested in this old patch
> > from LKML:
> >   https://lkml.org/lkml/2013/6/18/933
> > 
> > With "atapi_dmadir=1" and DMADIR forced, I have the same messages in the
> > kernel log - except obviously none of the other "horkage" messages or the
> > ATA IDENTIFY dump, and I think the "xfer mask" starts at a higher speed.
> > 
> > 
> > The BIOS can see and access the Zip drive fine, as can Windows.
> > 
> > I've also tried the same setup (SATA bridge) in a Pentium 4 PCI+AGP machine
> > I had sitting around. Admittedly this isn't much of a test as it was running
> > a much older and 32bit OS (Knoppix 7.2, kernel 3.9.6) but the sd device
> > appeared and the drive could be accessed fine.
> 
> Did you specify anything on the kernel command line when using kernel 3.9.6 ?
> 
> FWIW, commit e771451c0a83 ("libata: make ata_exec_internal_sg honor DMADIR")
> was first included in v3.10.1, so even if you did specify it on the kernel
> command line on kernel 3.9.6, it wouldn't have any effect on internal commands
> (e.g. IDENTIFY).

I take that back... the commit did exist in 3.9.6, but with a different SHA1:

commit 27a8de81bf1a476a3df6dd548c4925aa87689c92
Author: Vincent Pelletier <plr.vincent@gmail.com>
Date:   Sat May 18 18:44:04 2013 +0200

    libata: make ata_exec_internal_sg honor DMADIR
    
    commit e771451c0a831d96a7c14b0ca8a8ec671d98567b upstream.


Kind regards,
Niklas