From: Tejun Heo <tj@kernel.org>
To: Mark Lord <liml@rtr.ca>
Cc: Stuart MENEFY <stuart.menefy@st.com>, linux-ide@vger.kernel.org
Subject: Re: [PATCH] libata: Keep shadow last_ctl up to date during resets
Date: Wed, 11 Mar 2009 22:11:22 +0900 [thread overview]
Message-ID: <49B7B87A.1020107@kernel.org> (raw)
In-Reply-To: <49B7AE6E.4010704@rtr.ca>
Mark Lord wrote:
> Tejun Heo wrote:
>> Hello,
>>
>> Stuart MENEFY wrote:
>>> libata keeps a shadow copy of the ATA CTL register (which is write
>>> only),
>>> and only writes to the hardware when the required value doesn't match
>>> the shadow. However this copy wasn't being maintained when performing
>>> reset functions. This could cause problems for the first operation after
>>> a reset when the correct value might not be written to the CTL register.
>>>
>>> This problem was observed when hotplugging a drive: the identify command
>>> was being issued with interrupts enabled, when they should have been
>>> disabled.
>>>
>>> Signed-off-by: Stuart Menefy <stuart.menefy@st.com>
>>
>> Nice catch. Maybe a nice addition would be a ata_sff_write_to_ctl()
>> or something which always does the right thing.
>>
>> Acked-by: Tejun Heo <tj@kernel.org>
> ..
>
> Mmm.. I wonder if this is severe enough to warrant backporting
> to -stable for the past couple of releases?
Yeah, I think it can be responsible for at least some of runaway IRQs
during detection on ata_piix and is likely to be a good candidate for
-stable but I think it would be better to see how it does on -rc first
for a while before pushing this -stable. sata_nv breakages very well
showed how messed up things can get with obvious fixes. :-)
Thanks.
--
tejun
next prev parent reply other threads:[~2009-03-11 13:12 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-10 11:38 [PATCH] libata: Keep shadow last_ctl up to date during resets Stuart MENEFY
2009-03-11 7:42 ` Tejun Heo
2009-03-11 12:28 ` Mark Lord
2009-03-11 13:11 ` Tejun Heo [this message]
2009-03-13 18:58 ` Jeff Garzik
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=49B7B87A.1020107@kernel.org \
--to=tj@kernel.org \
--cc=liml@rtr.ca \
--cc=linux-ide@vger.kernel.org \
--cc=stuart.menefy@st.com \
/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.