On Wednesday 19 December 2012 04:44, Robert Hancock wrote: > On 12/18/2012 09:23 AM, bl0 wrote: >> Do you think something should be done about it in the linux sata_sil >> driver? For a lack of a better solution, here is my suggestion. There is >> already one option 'slow_down' for problematic disks. Another option, for >> example 'cache_line_workaround', could be added for problematic >> motherboards. If enabled, the most straightforward way is to set cache >> line size to 0 and not worry about the fifo_cfg register. If someone else >> confirms that it solves the problem for them, this option could be >> enabled automatically if certain motherboard chipset is detected. > > We'd have to somehow narrow down which chipsets were involved, which > might be a hard task. Do you have an idea of how much the performance is > hurt by these workarounds? If it's not a lot, it might make sense to do > it by default. After setting cache line size to 0, write speed as shown by 'dd if=/tmpfs/testfile of=/dev/sdc9 bs=1M count=256' goes down from about 45 MB/s to 17 MB/s. Personally I don't care about performance, reliability and data safety are more important to me. The other workaround is to increase cache line size to 64 bytes, if necessary, and set fifo_cfg to 0. No difference in performance measured. This workaround is more of a hit or miss. It seems to contradict that code commit made back in 2005, which was also about data corruption. In the worst case, what solves data corruption problem on some motherboards might introduce this problem on some other motherboards. -- 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
