This message is from the T13 list server.


Pat,

You still have not provided an example - your 4K page with an INQUIRY
command is NOT an example since it is DATA IN (over which you stated you
were not confused).

Once again, is there any evidence that there is a problem with DATA OUT
commands (and if so what is it)?  I'm willing to look at any data you
provide, even if it is not a logic analyzer trace, but you have not done
that to date - all of your examples have been DATA IN, not DATA OUT.  Once
again, I don't even see how the problem is possible - if you are seeing it
at one level I'm sure another is correcting it before it gets to the SCSI
bus.  But I'll look at what you got. 

Jim


-----Original Message-----
From: Pat LaVarre [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, January 02, 2002 1:37 PM
To: [EMAIL PROTECTED]
Subject: RE: RE: [t13] actual Scsi byte count decided how?


This message is from the T13 list server.


> > > your terminology

> > ... I'm more confident in algebra than in English ...
> > If [D = H] is the way it "has to be" ... what makes it so?

> "Mcgrath, Jim" <[EMAIL PROTECTED]> 01/02/02 02:09PM
> ... Put another way, have you ever seen a SCSI logic analyzer trace
> where H <> D on a successful command?  Anything short of that
> does not tell us ...

Ouch, ouch, ouch.  Nuts.  I still think we must not be meaning the same
things by the same words?

H is not precisely visible in an 8 bit asynchronous Scsi trace.  It is
explicitly visible in Usb/1394 trace.  H <> 0 is close to visible in an Ide
Dma trace: few hosts there DMACK- when H = 0.

When I say I have Scsi traces of H != D, by definition I'm saying that I
peeked at H somewhere out of band.

For example, suppose I allocate an aligned 4KiB physical page and ask the
i/o layer to move H = 4KiB and then settle for the x24 bytes that some Scsi
device I have moves in response to the cb x 12 0 0 0 FF 0.

Then I only know Di < Hi because I know Hi because I traced it inside the
host.  The asynchronous Scsi trace doesn't show me that my Hi = 4KiB.

The port to Atapi from Scsi breaks in the way I mean to be discussing
precisely because Atapi makes H more visible.  "Change Is Bad" in plug 'n
play: anything new I make visible I can find somebody on the other end of
the cable to trip over.

I see the workaround in Atapi Pio for making H typically not matter even
though visible, I see no corresponding workaround in Atapi Dma.

I see the standard does not mention the workaround that works in Atapi Pio.

I think the standard has to change (or people have to extend it bilaterally)
if we want a workaround to work in Atapi Dma.

Pat LaVarre


Subscribe/Unsubscribe instructions can be found at www.t13.org.
Subscribe/Unsubscribe instructions can be found at www.t13.org.

Reply via email to