linux-ide.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tejun Heo <htejun@gmail.com>
To: Jeff Garzik <jeff@garzik.org>
Cc: Mark Lord <liml@rtr.ca>, Andi Kleen <andi@firstfloor.org>,
	Alan Cox <alan@lxorguk.ukuu.org.uk>,
	IDE/ATA development list <linux-ide@vger.kernel.org>,
	ric@emc.com
Subject: Re: Analysis of EH on Andi's dying disk and stuff to discuss about
Date: Sun, 30 Mar 2008 08:35:58 +0900	[thread overview]
Message-ID: <47EED25E.4010805@gmail.com> (raw)
In-Reply-To: <47EEB0B4.2050808@garzik.org>

Jeff Garzik wrote:
> Mark Lord wrote:
>> Tejun Heo wrote:
>> ..
>>
>>>    So, to handle the common cases better, libata EH times out resets
>>>    quickly.  The first two tries are 10 seconds each and most devices
>>>    get reset properly before it hits the end of the second reset try
>>>    even if it needs to spin up.  What takes the longest is the third
>> ..
>>
>> I think that 10 seconds timeout is just *slightly* too short.
>> There are drives here somewhere, that always fail the first attempt
>> because they take about 12 seconds to spin-up and begin communicating.
> 
> Also, ATAPI sometimes takes quite a while to respond, I've seen, when 
> media is in the driver.

The goal there was to get, say, 90% of devices in the first reset and 
then the rest of sane ones in the second reset and idiots in the third 
reset.  As long as resets don't interfere with the device preparing for 
readiness as is the case for harddrive spinning up, this works just 
fine.  If there are devices which have to restart prepping for readiness 
on each reset, this can be a problem (those fall into the idiot category).

I personally have never seen such a device yet but if there's an ATAPI 
device which doesn't respond to reset till it has spun up the media and 
recognized it, it could be a problem.  I have to say that would be a 
pretty stupid way to implement reset.  Jeff, do you remember which drive 
it was?

-- 
tejun

  reply	other threads:[~2008-03-29 23:36 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20080328093055.GA16736@basil.nowhere.org>
2008-03-29  7:16 ` Analysis of EH on Andi's dying disk and stuff to discuss about Tejun Heo
2008-03-29 15:34   ` Ric Wheeler
2008-03-29 20:49     ` Mark Lord
2008-03-29 20:53   ` Mark Lord
2008-03-29 21:12     ` Jeff Garzik
2008-03-29 23:35       ` Tejun Heo [this message]
2008-03-30  7:03       ` Andi Kleen
2008-03-30  7:33         ` Jeff Garzik
2008-03-30 11:03         ` 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=47EED25E.4010805@gmail.com \
    --to=htejun@gmail.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=andi@firstfloor.org \
    --cc=jeff@garzik.org \
    --cc=liml@rtr.ca \
    --cc=linux-ide@vger.kernel.org \
    --cc=ric@emc.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).