On 08/01/2025 14:05, Niklas Cassel wrote:
> Since we see that the drive name is printed, the ATAPI IDENTIFY command
> succeded (ATA_CMD_ID_ATAPI (0xA1)).
>
> The command that timed out is ATA_CMD_PACKET 0xA0, so a regular ATAPI
command.
Aha - I'd tried to debug that, but thought it was a SCSI command code,
not an ATA one.
Is there a way to find out what CDB or ATAPI packet was sent to the drive?
If necessary I can probably build a custom kernel and add some
printk()'s but I'm hoping I don't need to!
> The UNIT ATTENTION print is just from atapi_eh_clear_ua(), which
seems to be
> called by ata_eh_recover() unconditionally for ATAPI devices, because
they
> always need to clear UNIT ATTENTION after a reset:
>
https://github.com/torvalds/linux/blob/v6.8/drivers/ata/libata-eh.c#L3232-L3234
>
> But the reset is of course only triggered because a command has timed
out.
I wouldn't be surprised if the failure to clear Unit Attention turned
out to be a quirk in the Zip 100 ATAPI's ATA/ATAPI or SCSI
implementation. They were known 'in the day' to have a few bugs [1] [2].
In any case the SATA bus reset (see larger log) sequence seems to get it
talking again, though obviously it's not ideal.
FWIW, the drive I have is the ATAPI3 model variant, with 12.A firmware.
The pages I linked mention a "drive A:" mode - I tried that, but all it
did was change part of the IDENTIFY response to read "FLOPPY".
[1].
<https://web.archive.org/web/20030207213746/http://iomega.com/software/betapatch.html>
[2].
<https://web.archive.org/web/20030212130255/http://pw2.netcom.com/~deepone/zipjaz/atapi.html>
Thanks
--
Phil.
philpem@xxxxxxxxxxxxx
https://www.philpem.me.uk/
