This message is from the T13 list server.
hueristic:
controller is SATA, and cable is SATA, and (ata version < 5 or word-93 is non-zero)
"Word 93" I've forgotten.
In p.140 of 390 of "d1532v1r4b ATA-ATAPI-7.pdf" I see: "Hardware reset result".
Agreed, any ATA/ ATAPI device too old to report "CBLID- above ViH" else "CBLID- below ViL" etc. is old.
Does this look like a good way to detect a PATA device attached to a
SATA controller? ...
I have found two bridge/SATA-controller
combinations (not naming names) that will cause failures if the lba48
command set is used to transfer more than 256 sectors per read/write...
even when the underlying PATA devices _do_ support lba48 large transfers.
My OS driver must be able to detect a "transparent" PATA bridge in order
to limit transfers to 256 sectors.
I'd say the op xEC "IDENTIFY" data of this SATA/PATA device is incorrect. This composite device claims 48-bit support without offering 16 bits of block count. We didn't provide a way to say that in the definition of the op xEC data. Of course I hate to see compliant devices penalised merely because others do not comply.
Does the failure have some regularity to it that you could test for?
For example, can you easily penalise old SATA only, and not also old SATAPI?
I'd particularly like to see PATAPI devices thru an actually transparent SATAPI/ PATAPI bridge allowed to copy up to xFFFF LBA's per CDB. Perhaps PATAPI/ SCSI devices have more history of benefitting from and supporting more than xFF LBA's per CDB.
Pat LaVarre
P.S. I'm quick to remember this issue now because:
Subject: Re: bytes/CDB of SCSI pass thru grossly limited maybe
http://marc.theaimsgroup.com/?l=linux-scsi&m=109389004622199
https://lists.one-eyed-alien.net/pipermail/usb-storage/2004-August/ 000751.html
contemporaneously archives why I think I care, in short:
a) whole revolution delays seen in bus traces b) no limit below 2 to 4 GiB in the standard for the bus c) device developers need xFFFF blocks per CDB
