This message is from the T13 list server.
Jeff G:
...suggested we add a SATA/PATA bit to ID Device. Glad you managed to find a way ...
It's not too late to poke the device vendors to add such a bit.........
If a bridge vendor touched my proposed "this is a SATA device" feature bit, then I will consider my proposal a failure.
Bridges should be as transparent as possible.
The 'sata device' feature bit should directly reflect the underlying device.
Define the bit for me again?
I must have misunderstood. I thought you wanted an op xEC/A1 "IDENTIFY" bit for the bridge from SATA/SATAPI to PATA/PATAPI to say the bridge was present, and therefore likely not totally transparent. I was saying that doesn't work well because the people experienced enough to know to admit they may have gotten the transparency wrong are the very same people likely to have got the transparency right enough.
Define the bit for me again?
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.
It is specific to two bridge+controller combinations. The bridge by itself isn't a problem, nor are the controllers in question, nor are other bridge+controller combinations.
Then bridging per se is not the issue.
"The controller" gets us from PCI to SATA/SATAPI, yes? Somehow that happens at the FIS level in a way that confuses the bridge, just as it might but has not yet confused an underlying FIS device?
Does the failure have some regularity to it that you could test for?
Yes. One user's setup is completely unusable without my workaround.
I mean to ask, in software can we probe to discover and recover when in fact we do have a bridge+controller combination that doesn't support more than xFF blocks per CDB? Do we have to run all old devices slowly?
For example, can you easily penalise old SATA only, and not also old SATAPI?
I do not penalize SATA at all. This does not appear to occur on devices or controllers with a hardwired bridge (so far anyway).
Lost me somehow, sorry. The test I saw you suggest was a test of "IDENTIFY" data. That test penalises any old device that fails that test, no matter how many bridges do or do not exist between host and disk?
I mean to ask are you suggesting such a test for only xEC "IDENTIFY" data or also for xA1 "IDENTIFY" data?
one of my pet theories is that the problem is _too many bridges_ ... underlying device.
Is "the underlying device" an observable concept?
In our age of multiple chips in one package, we cannot know a truly transparent bridge is present?
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.
I would rather just deprecate Parallel ATA completely, and push vendors to use non-bridged native solutions. ;-)
FIS-based, bay-bee...
I trust you are aware of how volume customers shaving profit margins out of drives leads drive vendors to design one native drive to sell cheaply and then pay to add a bridge to any of the many too many less well adopted ways of connecting drives.
Pat LaVarre
