This message is from the T13 list server.
Pat
"But I have seen the command block arrive corrupted. With the right
kind of corruption,
the host can wrongly think it saw a device cut a transfer short
without error."
If you are having corrupted command blocks, then what you are talking about
is NOT the answer to your problem. Since the op code could be corrupted,
you could end up formatting a device!
I have never heard of command block corruption on otherwise functioning
systems (since this information is usually transferred at PIO mode 0 speed -
if that will not get through then what will?). But if this is really a
problem, then raise it so that people can address it would a proper
solution.
Jim
-----Original Message-----
From: Pat LaVarre [mailto:[EMAIL PROTECTED]]
Sent: Monday, December 17, 2001 1:43 PM
To: [EMAIL PROTECTED]
Subject: RE: [t13] to UDma from SwDma - for a 16-bit Ide Dma engine?
This message is from the T13 list server.
> "Eschmann, Michael K" <[EMAIL PROTECTED]>
> 12/14/01 04:28PM
> under a variety of conditions),
> the interrupt status is ok,
> but the host doesn't know the exact transfer count.
Then you do see what I see?
When an Ide Dma receiver of clocks shuts the transfer down before the Ide
Sender of clocks would have shut the transfer down, the host can't know how
many bytes the device would have agreed to transfer, if only the device had
as much control as Pio offers it.
> no host should be attempting a mind-...game
> by trying to set the drive up to write more to the [media]
> than the host is really ready to do.
> ...
> Some folks have toyed with the idea of
> sending the drive a "big" transfer,
> then only setting up PRD's that represent a portion of it;
> I suggest against doing this.
Can you elaborate?
Streaming more data per command than fits in physical memory is exactly what
any bridge does if the people who buy the bridge are too cheap to pay for
enough buffer to hold all the data of any command. (I think just enough
buffer is 32MiB for 48-bit Ata at 0.5KiB/block: enough to be uncommon in
devices.)
Back when the host is a PC, isn't a stream larger than physical memory
exactly what we want to, say, erase a whole disk, at max speed?
Once upon a time Ata even included the command xE9 WriteSame to transfer the
bytes of a block only once but then use them to erase a long series of
Lba's?
> When a drive is just not going to send any more
> (ATAPI is the biggest offender,
> with Mode Sense and Inquiry's being a big target,
> as well as some data transfers ...
Yes.
> Some devices will terminate requests early,
> but this is either flow control,
> or completion when the drive interrupts.
> When a drive completes in error, it tells us
> (unless there is some "secret society" thing I don't know of)
> via the status register of the error.
This happens often enough to have inspired a tradition of checking for this
in qualification tests ...
I don't myself know of a shipping device that without error cuts block
read/write short of its interpretation of the command block ...
But I have seen the command block arrive corrupted. With the right kind of
corruption, the host can wrongly think it saw a device cut a transfer short
without error.
> under a variety of conditions),
> the interrupt status is ok,
> but the host doesn't know the exact transfer count.
> Either way, we can deal with the problem
> in higher-level software that parses the data stream
> to get the return data (in the Mode Sense and Inquiry cases).
Ouch.
Because some kinds of data includes enough redundancy to complain more or
less gently of wrong byte counts, we shouldn't care that in AtapiDma we
can't count bytes accurately?
Pat LaVarre
Subscribe/Unsubscribe instructions can be found at www.t13.org.
Subscribe/Unsubscribe instructions can be found at www.t13.org.
