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.. 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.. -- Bartlomiej Zolnierkiewicz -- 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
