Bartlomiej Zolnierkiewicz schrieb:
On Friday 23 October 2009 16:55:59 Mikulas Patocka wrote:
On Fri, 23 Oct 2009, Bartlomiej Zolnierkiewicz wrote:
On Friday 23 October 2009 16:29:16 Mikulas Patocka wrote:
We are through this the second time and you're still not willing
neither to listen nor to read the code. We always did serialization
for CMD646, we just used hwif->chipset == ide_cmd646 (without using
IDE_HFLAG_SERIALIZE flag):
Agreed, though I wonder whether we should also provide module parameter to
disable serializing on those chipsets for people not using SSDs...
Don't do it --- disks have cache and reading from the cache is as fast as
reading from SSD (or even faster), so if there is some speed-race in the
chip, there is a possibility that the data corruption happens with disks
too --- just with lower probability.
If we don't know why the chip corrupts data, we must treat it as always
corrupting data.
I actually suspect that it is device/chipset specific interaction and not
generic problem so adding a fallback option (w/ BIG FAT WARNING) seem to
make sense..
So, why was it serialized before? I assume that either someone noticed the
corruption or someone read some datasheet noting the corruption or someone
reverse engineered some other driver and saw the serialization.
Serialization is usually needed in case of chipset not handling concurrent
data transfers on both ports. Unfortunately I don't know details for CMD646.
Guys, this is old news. CMD643 and CMD646 have a shared data path from
the PCI interface to the ATA channel ports. In a document issued by CMD,
they explain the requirement for serialization. This issue is rectified
with CMD648 and later chips.
Especially since we have never serialized on CMD643 and your patch will
be adding performance regression without even verifying that the issue
also affects this chipset..
Do you have this chip? If you were IDE maintainer, did you collect cards
with IDE chips?
I recall having CMD648 and CMD649 cards somewhere, however not earlier
chipsets.
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
