From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Mark Lord <liml@rtr.ca>
Cc: Jeff Garzik <jeff@garzik.org>, Andrew Morton <akpm@osdl.org>,
Linus Torvalds <torvalds@osdl.org>,
linux-ide@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [git patch] libata resume fix
Date: Wed, 31 May 2006 08:34:09 +1000 [thread overview]
Message-ID: <1149028449.9986.66.camel@localhost.localdomain> (raw)
In-Reply-To: <447C4718.6090802@rtr.ca>
On Tue, 2006-05-30 at 09:22 -0400, Mark Lord wrote:
> Benjamin Herrenschmidt wrote:
> > On Sun, 2006-05-28 at 16:34 -0400, Jeff Garzik wrote:
> >> Please pull from 'upstream-fixes' branch of
> >> master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
> >>
> >> to receive the following updates:
> >>
> >> drivers/scsi/libata-core.c | 1 +
> >> 1 file changed, 1 insertion(+)
> >>
> >> Mark Lord:
> >> the latest consensus libata resume fix
> >
> > If your devices are coming from poweron-reset then you will have to wait
> > up to 31 seconds :( And yes, I _did_ have such a device at one point.
>
> Not in a suspend/resume capable notebook, though.
Maybe, but 2 seconds is just "abitrary". I know some ATAPI devices (in
notebooks) that will drive the bus (and thus pollute whatever you try to
do) for way more than 2 seconds if they are reset with a CD in the
drive.
> I don't know of *any* notebook drives that take longer
> than perhaps five seconds to spin-up and accept commands.
> Such a slow drive wouldn't really be tolerated by end-users,
> which is why they don't exist.
They do, especially ATAPI.
> But I suppose people will want to suspend/resume bigger machines
> too, in which case a 10000rpm Raptor might need 15 seconds or so.
>
> We could bump up the existing timeout, I suppose.
>
> Perhaps Jeff could comment on any potential harm in libata
> for going all the way to 3100000 with the timeout?
prev parent reply other threads:[~2006-05-30 22:34 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-05-28 20:34 [git patch] libata resume fix Jeff Garzik
2006-05-29 21:34 ` Benjamin Herrenschmidt
2006-05-30 13:22 ` Mark Lord
2006-05-30 18:26 ` Linus Torvalds
2006-05-30 18:40 ` Ric Wheeler
2006-05-30 22:37 ` Benjamin Herrenschmidt
2006-05-31 6:47 ` Jens Axboe
2006-05-31 6:56 ` Benjamin Herrenschmidt
2006-05-31 22:01 ` Bill Davidsen
2006-05-30 22:34 ` Benjamin Herrenschmidt [this message]
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=1149028449.9986.66.camel@localhost.localdomain \
--to=benh@kernel.crashing.org \
--cc=akpm@osdl.org \
--cc=jeff@garzik.org \
--cc=liml@rtr.ca \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@osdl.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).