From: Tejun Heo <htejun@gmail.com>
To: Tejun Heo <htejun@gmail.com>
Cc: Jon K Hellan <hellan@acm.org>,
linux-ide@vger.kernel.org,
Carlos Pardo <Carlos.Pardo@siliconimage.com>,
Jeff Garzik <jgarzik@pobox.com>
Subject: Re: sata_sil.c, 3512 and SIL_QUIRK_MOD15WRITE
Date: Fri, 24 Feb 2006 16:26:40 +0900 [thread overview]
Message-ID: <43FEB530.2070908@gmail.com> (raw)
In-Reply-To: <43FEB413.7060800@gmail.com>
Tejun Heo wrote:
> Jon K Hellan wrote:
>
>>On Thu, 2006-02-23 at 16:19 +0900, Tejun Heo wrote:
>>
>>
>>
>>>Can you try the following patch? It's a kind of long shot.
>>
>>
>>Long shot? Seems to work. I didn't see any lockups during the 12 hours I
>>tested. The bug normally shows up in less than 1 hour. Out of curiosity,
>>what does the patch do?
>>
>
>
> Hello, Jon.
>
> Hmmm... it's a pending workaround for 3114's R_ERR on DMA activate FIS
> errata, which goes like...
>
> * 3. SiI 3114 R_ERR on DMA activate FIS errta workaround
> *
> * Errata:
> * During DMA write operations with a data length greater than 8
> * Kbytes, a PRD entry fetch that occurs at the same time that a
> * DMA Activate FIS is received may cause the SiI3114 to falsely
> * indicate that the DMA Activate FIS has an illegal FIS Type.
> * This may cause the Sil3114 to send an R_EER in response to the
> * DMA Active FIS.
> *
> * Workaround:
> * By configuring bit[1:0] of the SFISCfg register to accept FIS
> * types other than the standard SATA defined FIS types, the
> * SiI3114 is prevented from falsely setting the illegal FIS Type
> * indicator, thus preventing the improper RERR response. The
> * default value of the SFISCfg register is 0x1040_1555. To
> * implement this workaround, the SFISCfg register should be set to
> * a value of 0x1040_1554.
> *
> * This workaround is applied during controller initialization in
> * sil_init_one().
> *
>
> So, you're confirming that this workaround fixes your lockup on 3152 for
> both ST3200822AS and SP2504C, right?
>
> Carlos, can you confirm this? It seems like 3512 shares this errata with
> 3114.
>
Jeff, once Carlos confirms this. I think this should go into 2.6.16.
3114/3512 lock up is certainly a bothering regression. I'll redo the
patch after Carlos's confirmation.
Thanks.
--
tejun
next prev parent reply other threads:[~2006-02-24 7:25 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-22 18:03 sata_sil.c, 3512 and SIL_QUIRK_MOD15WRITE Jon Kåre Hellan
2006-02-23 2:07 ` Tejun Heo
2006-02-23 3:35 ` Jeff Garzik
2006-02-23 3:52 ` Tejun Heo
2006-02-23 3:58 ` Jeff Garzik
2006-02-23 6:59 ` Jon K Hellan
2006-02-23 7:19 ` Tejun Heo
2006-02-24 7:08 ` Jon K Hellan
2006-02-24 7:21 ` Tejun Heo
2006-02-24 7:26 ` Tejun Heo [this message]
2006-02-24 8:33 ` Jon Kåre Hellan
2006-02-24 18:07 ` Jon K Hellan
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=43FEB530.2070908@gmail.com \
--to=htejun@gmail.com \
--cc=Carlos.Pardo@siliconimage.com \
--cc=hellan@acm.org \
--cc=jgarzik@pobox.com \
--cc=linux-ide@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.