Read Capacity(16) failed when booting and writing the parition table with fdisk

[morio]

I'm seeing dmesg errors when using the ZuluIDE as a zip drive under Linux.
The ZIP drive still works but it does spit out errors on boot and when writing to the partition table with fdisk

Steps

1. Boot with "zipd-image.img" 100MB image
2. During boot this is logged in dmesg
   https://termbin.com/0pdw

[ 15.509002] ata5.01: ATAPI: IOMEGA ZIP 100, 14.A, max UDMA/16, CDB intr
[ 15.536038] scsi 4:0:1:0: Direct-Access IOMEGA ZIP 100 14.A PQ: 0 ANSI: 5
[ 15.542681] sd 4:0:1:0: Attached scsi generic sg2 type 0
[ 15.546229] sd 4:0:1:0: [sdb] Read Capacity(16) failed: Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK
[ 15.548569] sd 4:0:1:0: [sdb] Sense not available.
[ 15.555168] sd 4:0:1:0: [sdb] 196608 512-byte logical blocks: (101 MB/96.0 MiB)
[ 15.562123] sd 4:0:1:0: [sdb] Write Protect is off
[ 15.564460] sd 4:0:1:0: [sdb] Mode Sense: 00 40 00 00
[ 15.575083] sd 4:0:1:0: [sdb] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[ 15.616291] sd 4:0:1:0: [sdb] Read Capacity(16) failed: Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK
[ 15.618612] sd 4:0:1:0: [sdb] Sense not available.
[ 15.657466] sdb: sdb1
[ 15.665108] sd 4:0:1:0: [sdb] Attached SCSI removable disk

3. Also when writing the partition table to the zipdisk with fdisk I see the same error

[ 384.608423] sd 4:0:1:0: [sdb] Read Capacity(16) failed: Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK
[ 384.612147] sd 4:0:1:0: [sdb] Sense not available.
[ 384.649663] sdb: sdb1

Read Capacity(16) is a sub command of Service Action (operation code 0x9E)
I tried implementing Service Action and Read Capacity(16)
read_capacity_16.patch

but I noticed that even before I tried implementing there was no
"-- WARNING: Unsupported ATAPI command UNKNOWN_CMD" log entry

So I don't think the command is getting to the RP2040.

[PetteriAimonen]

Does the lack of ReadCapacity16 cause some actual problem, or just a warning in the log? Normally Linux should automatically fall back to the normal READ_CAPACITY without issue, and it does appear to have read the capacity correctly.

Not sure why the command wouldn't get through.