linux-ide.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tejun Heo <htejun@gmail.com>
To: Jeff Garzik <jgarzik@pobox.com>
Cc: Ethan Chen <thanatoz@ucla.edu>,
	linux-kernel@vger.kernel.org,
	Carlos Pardo <Carlos.Pardo@siliconimage.com>,
	Linux-ide <linux-ide@vger.kernel.org>
Subject: Re: SIL_QUIRK_MOD15WRITE workaround problem on 2.6.14
Date: Wed, 30 Nov 2005 14:37:44 +0900	[thread overview]
Message-ID: <438D3AA8.9030504@gmail.com> (raw)
In-Reply-To: <438D2DCC.4010805@pobox.com>

Jeff Garzik wrote:
> Tejun Heo wrote:
> 
>> [CC'ing Jeff, Carlos & linux-ide]
>>
>> Ethan Chen wrote:
>>
>>> I've got a dual Opteron 242 machine here with 2x Seagate ST3200822AS 
>>> SATA drives attached to a Silicon Image SI3114 controller, and after 
>>> upgrading to 2.6.14 from 2.6.13, it seems the SIL_QUIRK_MOD15WRITE 
>>> workaround for the sata_sil driver isn't being applied anymore. This 
>>> caused me trouble in the past before my drive was added to the 
>>> blacklist, and this message that comes up when writing (~4GBfiles to 
>>> test) files, right before the computer locks up, is the same as before:
>>> kernel: ata1: command 0x35 timeout, stat 0xd8 host_stat 0x61
>>> In the dmesg, the 'Applying Seagate errata fix' message doesn't 
>>> appear anymore as well.
>>> Finally, without the fix, write speeds are much higher as well, 
>>> before it locks up.
>>
>>
>>
>> Hello, Ethan.
>>
>> Sometime ago, Silicon Image has confirmed that 3114's and 3512's are 
>> not affected by the m15w problem - only 3112's are affected.  So, a 
>> patch has made into the tree before 2.6.14 to apply the m15w quirk 
>> selectively.
> 
> 
> Most likely, mod15write quirk was just hiding an unrelated problem. 
> mod15write often hid BIOS problems in the past which led to corruption.
> 
> Until sata_sil properly handles SATA phy / DMA errors by resetting the 
> controller and retrying the command, we won't know if its a driver 
> problem or not.
> 

Ethan confirmed that it's 1095:3114.  Arghhh....  Maybe we should keep 
m15w quirk for 3114's for the time being?  Better be slow than hang. 
Whatever bug the m15w quirk was hiding.

Carlos, can you double check that 3114's don't have the m15w issue?  It 
just seems too similar to the usual m15w lockup.

-- 
tejun

  reply	other threads:[~2005-11-30  5:37 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <438BD351.60902@ucla.edu>
2005-11-30  4:16 ` SIL_QUIRK_MOD15WRITE workaround problem on 2.6.14 Tejun Heo
2005-11-30  4:42   ` Jeff Garzik
2005-11-30  5:37     ` Tejun Heo [this message]
2005-12-02  2:01       ` Jeff Garzik
2005-12-04 16:44         ` Tejun Heo
2005-12-05 18:41           ` Jeff Garzik
2005-11-30  4:48   ` Ethan Chen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=438D3AA8.9030504@gmail.com \
    --to=htejun@gmail.com \
    --cc=Carlos.Pardo@siliconimage.com \
    --cc=jgarzik@pobox.com \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=thanatoz@ucla.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).