This message is from the T13 list server.
Pat,
> 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.........
Jeff was actually referring to my post about having suggested many many
moons ago that we should consider adding a bit or bits into the IDENT to
specify what type of device it was, beit SATA, SATA w/Bridge, PATA, etc. I
pretty much got abused and mocked for even suggesting that the 100%
transparency of SATA could even possibly somewhere down the road maybe not
be 100%. Anyway, having a little experience in the Disk Drive world over
the years I had seen situations where we implented commands from the spec
and we had the foresight to add a secret enable/disable bit in the secret
config sector of the drives and had on occaision actually had to disable a
command because it didnt quite work correctly. Of course these were always
due to FIRMWARE BUGS and not hardware :-). That has nothing to do with this
issue, but I needed to vent that......Anyway, I think I even might have said
something like "better safe then sorry" because just maybe down the road
someone might actually want to know if it is a SATA or PATA device.
Bottom line, it never got discussed at committee level, at least T13, it
may have been discussed in SATA group. Jeff was just looking for feedback
on his workaround idea. I guess he suggested better late then never on the
bit.
gary laatsch
----- Original Message -----
From: "Pat LaVarre" <[EMAIL PROTECTED]>
To: "Jeff Garzik" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Wednesday, September 01, 2004 9:24 AM
Subject: Re: [t13] [RFC] detecting PATA device behind SATA bridge
> 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
>
>
