On Monday 07 January 2013 05:11, Robert Hancock wrote: > On 12/20/2012 02:54 AM, bl0 wrote: >> 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. > > Yeah, cutting performance by 2/3rds is fairly bad though. Yes, it's probably not a good thing to do by default for everyone. >> 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. > > That's possible, which is why I suspect that someone from Silicon Image > would have to confirm a possible fix - might be hard to get their > attention about this old chipset.. I still recommend, for a start, a kernel module option, along with a message in dmesg. (If you haven't seen it yet, the code diff in my last message shows a possible way to do this.) -- 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
