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)
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.
Thanks,
Phil.
On 17/01/2025 13:37, Niklas Cassel wrote:
Hello Philip,
On Thu, Jan 09, 2025 at 03:31:05PM +0000, Philip Pemberton wrote:
(Repeating myself here, ata4 / ata_port=4 is the DVD drive; ata_port=3 is
the Zip drive)
There's quite a lot on the ATA buses, so if it helps --
ata1: Samsung 860 SSD
ata2: WD 500GB mechanical hard drive
ata3: Spare port / Zip drive
ata4: DVD writer
ata5: Not used
ata6: Not used
There are a couple of SATA disks and a SAS tape drive on an LSI SAS card but
they seem to go through the "scsi" and "mpt2sas" driver route.
Note that for ATAPI, it also looks like your SATA driver needs special support.
See e.g. libahci.c which does a bunch of extra stuff if it is an ATAPI device,
e.g.:
https://github.com/torvalds/linux/blob/v6.13-rc6/drivers/ata/libahci.c#L1699-L1702
https://github.com/torvalds/linux/blob/v6.13-rc6/drivers/ata/libahci.c#L1638-L1643
Same for the libata-sff driver:
https://github.com/torvalds/linux/blob/v6.13-rc6/drivers/ata/libata-sff.c#L2672-L2684
https://github.com/torvalds/linux/blob/v6.13-rc6/drivers/ata/libata-sff.c#L295-L297
https://github.com/torvalds/linux/blob/v6.13-rc6/drivers/ata/libata-sff.c#L687-L715
Which SATA driver are you using?
It looks like it's "ahci" or "libahci".
Are you saying that it does come up and work eventually?
When we see the "disable device" print, it is usually a sign that we have
given up, and thus remove the device.
No, it tries to connect three times, then gives up and disables the device.
Unfortunately, so far I do not think that we have enough information to
do much about this issue.
We know that the "SATA-to-PATA adatper + Zip drive" combo worked on some
other PC (that might have used another SATA HBA) with an ancient kernel.
I think my first recommendation would be to try to build an ancient kernel
on your current PC, and see if the same "SATA-to-PATA adatper + Zip drive"
combo then works. If it does work, then I think the best bet is to use
PCI passthrough and do an git bisection (which can be automated).
Or, do the opposite, see if the latest kernel with other PC still handles
the Zip drive properly, if it doesn't, then perhaps the best thing is to
to the bisection on this other PC.
You could look at this guide for inspiration:
https://github.com/floatious/qemu-bisect-doc
Kind regards,
Niklas
--
Phil.
philpem@xxxxxxxxxxxxx
https://www.philpem.me.uk/
