All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff Garzik <jeff@garzik.org>
To: Tejun Heo <tj@kernel.org>
Cc: Robert Hancock <hancockr@shaw.ca>,
	david@lang.hm, lament.email.si@gmail.com,
	IDE/ATA development list <linux-ide@vger.kernel.org>
Subject: Re: [PATCH #upstream] sata_nv: use hardreset only for post-boot probing
Date: Wed, 10 Jun 2009 11:05:51 -0400	[thread overview]
Message-ID: <4A2FCBCF.7010308@garzik.org> (raw)
In-Reply-To: <4A2F60C3.2070805@kernel.org>

Tejun Heo wrote:
> When I thought it was finally defeated, it came back with vengeance.
> The failure cases are ever more convoluted.  Now there is a single
> combination which fails boot probing - MCP5x + Intel SSD and there are
> two hotplug failure reports on different flavors where softreset fails
> to bring up the device.
> 
> Through the many bug reports after the switch to hardreset, the
> following patterns emerged.
> 
> - Softreset during boot always works.
> 
> - Hardreset during boot sometimes fails to bring up the link on
>   certain comibnations and device signature acquisition is unreliable.
> 
> - Hardreset is often necessary after hotplug.
> 
> It looks like the old behavior of preferring softreset was somehow
> pretty close to the working reset protocol although it could have lost
> a device during phy error handling by issuing hardreset.
> 
> This patch implements nv_hardreset() which kicks in only for post-boot
> (!LOADING) device probing resets.  This should be able to work around
> all known problem cases.  This isn't perfect but given the various
> hardreset quirks on these controllers, I think this is as good as it
> can get.
> 
> Tested on mcp5x (swncq), nf3 and ck804 for all both boot, warm and
> hot probing cases.
> 
> Kudos to all the bug reporters and their painful hours with these damn
> controllers.  ;-)
> 
> Signed-off-by: Tejun Heo <tj@kernel.org>
> Cc: Robert Hancock <hancockr@shaw.ca>
> Reported-by: David Lang <david@lang.hm>
> Reported-by: Samo Vodopivec <lament.email.si@gmail.com>
> ---
> Jeff, please queue for 2.6.31.  I think this should be pretty safe but
> well I've said that before several times for sata_nv already and was
> wrong, so...
> 
> Thanks.
> 
>  drivers/ata/sata_nv.c |  131 ++++++++++++++++++++++++++++++--------------------
>  1 file changed, 81 insertions(+), 50 deletions(-)

applied



  reply	other threads:[~2009-06-10 15:06 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-10  7:29 [PATCH #upstream] sata_nv: use hardreset only for post-boot probing Tejun Heo
2009-06-10 15:05 ` Jeff Garzik [this message]
2009-06-29 18:58 ` david
2009-07-08  4:17   ` Tejun Heo

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=4A2FCBCF.7010308@garzik.org \
    --to=jeff@garzik.org \
    --cc=david@lang.hm \
    --cc=hancockr@shaw.ca \
    --cc=lament.email.si@gmail.com \
    --cc=linux-ide@vger.kernel.org \
    --cc=tj@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.