All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mario Limonciello <mario_limonciello@dell.com>
To: "Hayes, Stuart" <Stuart_Hayes@dell.com>
Cc: jeff@garzik.org, linux-scsi@vger.kernel.org,
	James.Bottomley@HansenPartnership.com,
	linux-kernel@vger.kernel.org, linux-ide@vger.kernel.org
Subject: Re: [PATCH] libata: change drive ready wait after hard reset to 5s
Date: Mon, 02 Feb 2009 11:17:45 -0600	[thread overview]
Message-ID: <49872AB9.1010807@dell.com> (raw)
In-Reply-To: <DFEF91B22ED07447AB6AA4B237F913F9021859A8@ausx3mpc125.aus.amer.dell.com>

[-- Attachment #1: Type: text/plain, Size: 2036 bytes --]

I believe this is the reference that Stuart refers to in the ATA-6 spec:

http://www.t10.org/t13/project/d1410r3a-ATA-ATAPI-6.pdf

Here's the snippet, (p327):

"
Transition D0HR1:D0HR1: When the sample indicates that DASP- is negated
and            less than 450 ms have
elapsed since the negation of RESET-, then the device shall make a
transition to the   D0HR1: Sample_DASP-
state. When the sample indicates that DASP- is negated and greater than
450 ms          but less than 5 s have
elapsed since the negation of RESET-, then the device may make a
transition to the     D0HR1: Sample_DASP-
state.
Transition D0HR1:D0HR3: When the sample indicates that DASP- is negated
and 5 s have elapsed since the
negation of RESET-, then the device shall clear bit 7 in the Error
register and make a transition to the D0HR3:
Set_status state. When the sample indicates that DASP- is negated and
greater than 450 ms but less than 5 s
have elapsed since the negation of RESET-, then the device may clear bit
7 in the Error register and make a
transition to the D0HR3: Set_status state.
"

Hayes, Stuart wrote:
> This fixes problems during resume with drives that take longer than 1s
> to be ready.  The ATA-6 spec appears to allow 5 seconds for a drive to
> be ready.
>
> On one affected system, this patch changes "PM: resume devices took..."
> message from 17 seconds to 4 seconds, and gets rid of a lot of ugly
> timeout/error messages.
>
> Without this patch, the libata code moves on after 1s, tries to send a
> soft reset (which the drive doesn't see because it isn't ready) which
> also times out, then an IDENTIFY command is sent to the drive which
> times out, and finally the error handler will try to send another hard
> reset which will finally get things working.
>
> Sorry to send as an attachment, but my mail server will wrap text.
>
>
> Signed-off-by: Stuart Hayes <stuart_hayes@dell.com>
>
>   

-- 
Mario Limonciello
*Dell | Linux Engineering*
mario_limonciello@dell.com


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

  reply	other threads:[~2009-02-02 17:27 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-01  2:55 [PATCHSET] block,scsi,libata: implement alt_size Tejun Heo
2009-02-01  2:55 ` Tejun Heo
2009-02-01  2:55 ` [PATCH 1/3] block: add alt_size Tejun Heo
2009-02-01  2:55   ` Tejun Heo
2009-02-01  2:55 ` [PATCH 2/3] scsi: add scsi_device->alt_capacity Tejun Heo
2009-02-01  2:55   ` Tejun Heo
2009-02-01  2:55 ` [PATCH 3/3] libata: export HPA size as alt_size Tejun Heo
2009-02-01  2:55   ` Tejun Heo
2009-02-02 17:12   ` [PATCH] libata: change drive ready wait after hard reset to 5s Stuart_Hayes
2009-02-02 17:12     ` Stuart_Hayes
2009-02-02 17:17     ` Mario Limonciello [this message]
2009-02-09 21:48     ` Stuart_Hayes
2009-02-09 21:48       ` Stuart_Hayes
2009-02-01  2:59 ` [PATCHSET] dmraid: use alt_size Tejun Heo
2009-02-01  2:59 ` Tejun Heo
2009-02-01  2:59   ` Tejun Heo
2009-02-01  3:00   ` [PATCH 1/3] dmraid: set read_info to @offset by default in read_raid_dev() Tejun Heo
2009-02-01  3:00     ` Tejun Heo
2009-02-01  3:00   ` [PATCH 2/3] dmraid: add alt_size to dev_info Tejun Heo
2009-02-01  3:00     ` Tejun Heo
2009-02-01  3:01   ` [PATCH 3/3] dmraid: make nv use alt_size if available Tejun Heo
2009-02-01  3:01     ` Tejun Heo
2009-02-01  3:20 ` [PATCHSET] block,scsi,libata: implement alt_size Jeff Garzik
2009-02-01  4:14   ` Tejun Heo
2009-02-01  4:14     ` Tejun Heo
2009-04-30  1:13 ` Tejun Heo
2009-04-30  1:13 ` Tejun Heo
2009-04-30  1:13   ` Tejun Heo
2009-04-30  1:45 ` Jeff Garzik
2009-04-30  1:50   ` Tejun Heo
2009-04-30 20:00     ` Jeff Garzik
2009-04-30 21:15       ` Dan Williams
2009-04-30 21:15         ` Dan Williams
2009-05-04  8:02         ` Tejun Heo
2009-05-04  8:02           ` Tejun Heo
2009-05-04 16:48           ` Dan Williams
2009-05-05  3:28             ` Tejun Heo
2009-05-05 15:34               ` Dan Williams
2009-05-08  9:13                 ` Tejun Heo
2009-05-08 16:21                   ` Jeff Garzik
2009-05-08 16:21                     ` Jeff Garzik
2009-05-08 16:23                   ` Dan Williams

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=49872AB9.1010807@dell.com \
    --to=mario_limonciello@dell.com \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=Stuart_Hayes@dell.com \
    --cc=jeff@garzik.org \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@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.