Re: sata_sil data corruption, possible workarounds

[Robert Hancock <hancockrwd@gmail.com>]

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.

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