From: Tejun Heo <htejun@gmail.com>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Georgi Chulkov <g.chulkov@jacobs-university.de>,
linux-kernel@vger.kernel.org, linux-ide@vger.kernel.org,
Mark Lord <liml@rtr.ca>
Subject: Re: ATA device reset, shoud I be concerned?
Date: Mon, 21 Jan 2008 16:56:14 +0900 [thread overview]
Message-ID: <4794501E.90306@gmail.com> (raw)
In-Reply-To: <20080115113552.75731bf8@lxorguk.ukuu.org.uk>
Alan Cox wrote:
>>> [ 9031.028000] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2
>>> frozen
>>> [ 9031.028000] ata1.00: cmd c8/00:08:90:ca:ce/00:00:00:00:00/e0 tag 0 cdb 0x0
>>> data 4096 in
>>> [ 9031.028000] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4
>>> (timeout)
>
> We got bored of waiting for the drive to respond to our request. I still
> think we have the timeouts too short or are accounting queue time
> somewhere we shouldn't as there a few other examples where we don't allow
> long enough for a drive to retry out and fail with a media error on a bad
> sector.
Hmm.. That's not what I hear from Mark and vendor contacts. They say
30secs is more than enough. I actually am thinking about reducing it to
15secs (not for FLUSH of course) as many SFF controllers report
transmission failure as timeouts. Of course, if we're ticking the timer
while the command is not in flight, that's a bug. If there are cases
where 30 secs isn't enough, can you please point me to those reports?
Thanks.
--
tejun
next prev parent reply other threads:[~2008-01-21 7:56 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-13 22:19 ATA device reset, shoud I be concerned? Georgi Chulkov
2008-01-15 10:54 ` Andrew Morton
2008-01-15 11:35 ` Alan Cox
2008-01-21 7:56 ` Tejun Heo [this message]
2008-01-21 13:02 ` Alan Cox
2008-01-21 13:14 ` Tejun Heo
2008-01-21 14:14 ` Alan Cox
2008-01-21 14:31 ` Tejun Heo
2008-01-21 14:33 ` Tejun Heo
2008-01-21 16:44 ` Alan Cox
2009-08-27 2:40 ` Robert Hancock
2009-08-27 3:07 ` Jeff Garzik
2009-08-27 8:37 ` Alan Cox
2008-01-21 16:47 ` Alan Cox
2008-01-21 17:02 ` Tejun Heo
2008-01-21 17:27 ` Alan Cox
2008-01-22 0:31 ` Tejun Heo
2008-01-22 1:31 ` Bartlomiej Zolnierkiewicz
2008-01-22 1:36 ` Tejun Heo
2008-01-22 2:08 ` Tejun Heo
2008-01-22 1:39 ` Alan Cox
2008-01-22 20:29 ` Georgi Chulkov
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=4794501E.90306@gmail.com \
--to=htejun@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=g.chulkov@jacobs-university.de \
--cc=liml@rtr.ca \
--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;
as well as URLs for NNTP newsgroup(s).