Ok. This is all very nice, however, after starting to read a block
(PIO), it is impossible to signify "error". So if the data transfer
over the IDE bus ends up with a parity error, this can no longer be
flagged. No go.
If after starting to DMA a block, the interrupt happens before the end
of the block, and the HPT has the whole block transferred from the
drive (that means a 2K buffer on the chip!) then there is no
performance win: the chipset has had to wait for the full transfer,
and still the OS may need exactly the last byte of that block, so you
still need to wait for the DMA "complete". It could've started the DMA
in the mean while, most likely filling gaps on the bus.
If the HPT doesn't buffer the whole block (which I find most likely),
then it will have the same problem as with PIO: it can no longer flag
a transfer as "broken" once it has flagged it as "almost done".
In short, this is NOT a feature that is generally useful. If you know
you're sequentially reading a stream from the disk, and if real-time
requirements are MUCH more important than the validity of the data,
and if you know your disk outpaces the read-process, then this is a
useful feature. Too many ifs. This is not a feature that an OS like
Linux can use.
The conclusion must be that the feature MUST be turned off.
Roger.
-- ** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2137555 ** *-- BitWizard writes Linux device drivers for any device you may have! --* ------ Microsoft SELLS you Windows, Linux GIVES you the whole house ------
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/