Re: sata_sil data corruption, possible workarounds

[bl0 <bl0-052@playker.info>]

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