From: Tejun Heo <tj@kernel.org>
To: Jian Peng <jipeng@broadcom.com>
Cc: Robert Hancock <hancockrwd@gmail.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"jgarzik@pobox.com" <jgarzik@pobox.com>,
ide <linux-ide@vger.kernel.org>
Subject: Re: questions regarding possible violation of AHCI spec in AHCI driver
Date: Wed, 08 Dec 2010 19:24:22 +0100 [thread overview]
Message-ID: <4CFFCD56.6050608@kernel.org> (raw)
In-Reply-To: <E18F441196CA634DB8E1F1C56A50A874319FA38C43@IRVEXCHCCR01.corp.ad.broadcom.com>
Hello,
On 12/08/2010 07:14 PM, Jian Peng wrote:
> The problem happened as follow:
>
> After power up, inside ahci_init_one(), it will call ahci_power_up()
> to toggle PxCMD.SUD bit first, then HBA will send COMRESET to
> device, and device will send first D2H FIS back. Here it will call
> ahci_start_engine() to turn on PxCMD.ST to process command. In this
> case, it may run into race condition that transaction triggered by
> toggling PxCMD.SUD is not completed yet, and that is the reason why
> extra check is required by spec to guarantee that HBA already
> received FIS and in sane state.
>
> In most HBA, either staggered spin-up feature was not supported, or
> time required for transaction is less than that between two function
> calls, it may work. IMHO, this is a clear violation of spec, and not
> robust against all HBA design.
>
> The major concern is that ahci_start_engine() is used widely in EH
> and it does not return result to reflect whether ST bit was set or
> not, this may cause trouble in some cases. I am working on verifying
> those cases with different HBAs now.
I see, so it's not that the controller actually failed but you
observed the race condition. During EH, ahci_start_engine() is used
rather liberally when the driver wants the controller in working
condition. The assumption is that even if the driver tries to set ST
with the incorrect condition, the controller wouldn't go crazy where
it can't be restarted later, which _must_ be true as there's no atomic
way to check the condition and set ST.
The driver at the same time guarantees that if the whole
initialization protocol succeeds, the last ahci_start_engine() is
called after hardreset is sucessfully completed and thus all the
prerequisites are met.
So, yeap, the driver might set ST when the conditions are not met but
that can't be avoided completely anyway so the controller shouldn't go
completely bonkers for that (it's okay to fail in recoverable way) and
the driver will do the last ST setting after all the conditions are
met on the success path.
Thanks.
--
tejun
next prev parent reply other threads:[~2010-12-08 18:24 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-07 7:43 questions regarding possible violation of AHCI spec in AHCI driver Jian Peng
2010-12-08 1:54 ` Robert Hancock
2010-12-08 10:07 ` Tejun Heo
2010-12-08 18:14 ` Jian Peng
2010-12-08 18:24 ` Tejun Heo [this message]
2010-12-08 18:48 ` Jian Peng
2010-12-08 18:52 ` Tejun Heo
2010-12-08 19:49 ` Jian Peng
2010-12-08 19:55 ` Tejun Heo
2010-12-08 20:09 ` Jian Peng
2010-12-08 22:54 ` Tejun Heo
2010-12-09 1:30 ` Jian Peng
2011-01-11 18:09 ` Jian Peng
2011-01-11 18:23 ` Tejun Heo
2011-01-11 18:55 ` Jian Peng
2011-01-12 0:45 ` Harik
2011-01-12 0:51 ` Jian Peng
2011-01-19 0:51 ` Jeff Garzik
2011-01-19 0:58 ` Jian Peng
2011-01-19 23:35 ` Jian Peng
2011-01-19 23:37 ` Jian Peng
2011-04-19 21:48 ` Jian Peng
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=4CFFCD56.6050608@kernel.org \
--to=tj@kernel.org \
--cc=hancockrwd@gmail.com \
--cc=jgarzik@pobox.com \
--cc=jipeng@broadcom.com \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox