From: Matt Mackall <mpm@selenic.com>
To: Hugh Dickins <hugh@veritas.com>
Cc: Jeff Chua <jeffchua@silk.corp.fedex.com>,
Jeff Garzik <jeff@garzik.org>, Jens Axboe <axboe@suse.de>,
Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: sata suspend resume ...
Date: Wed, 19 Apr 2006 16:49:59 -0500 [thread overview]
Message-ID: <20060419214959.GR15445@waste.org> (raw)
In-Reply-To: <Pine.LNX.4.64.0604191659230.7660@blonde.wat.veritas.com>
On Wed, Apr 19, 2006 at 05:13:27PM +0100, Hugh Dickins wrote:
> On Wed, 19 Apr 2006, Jeff Chua wrote:
> >
> > Any change of getting suspend/resume to work on my IBM X60s notebook.
> >
> > Disk model is ...
> >
> > MODEL="ATA HTS541060G9SA00"
> > FW_REV="MB3I"
> >
> > Linux 2.6.17-rc2.
> >
> > System suspends ok. Resume ok. but no disk access after that.
>
> Not the same disk model, but I've been having similar trouble on a T43p.
>
> I was delighted to see the MSI suspend/resume fix go into 2.6.17-rc2,
> but then disappointed. A bisection found that Matt Mackall's sensible
> rc1 patch, to speed up get_cmos_time, has removed what often used to be
> a 2 second delay in resuming: things work well when I reinstate that
> delay (1 second has proved not enough). Below is the patch I'm using -
> where I've failed to resist mucking around to avoid those double calls
> to get_cmos_time, sorry: really it's just mdelay(2000) needed somewhere
> (until someone who knows puts in something more scientific).
That's interesting.
Just to be clear, with my changes we should never fire timers early.
Is the problem that we have a timer that didn't get deleted at suspend
time?
--
Mathematics is the supreme nostalgia of our time.
next prev parent reply other threads:[~2006-04-19 21:53 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-04-19 15:26 sata suspend resume Jeff Chua
2006-04-19 15:52 ` Arkadiusz Miskiewicz
2006-04-20 2:18 ` Jeff Chua
2006-04-19 16:13 ` Hugh Dickins
2006-04-19 16:56 ` Arkadiusz Miskiewicz
2006-04-19 17:08 ` Hugh Dickins
2006-04-19 21:49 ` Matt Mackall [this message]
2006-04-19 22:50 ` Hugh Dickins
2006-04-19 22:57 ` Matt Mackall
2006-04-19 23:26 ` Hugh Dickins
2006-04-20 13:25 ` Arkadiusz Miskiewicz
2006-04-20 13:47 ` Pavel Machek
2006-04-21 12:49 ` Hugh Dickins
2006-04-21 16:39 ` Pavel Machek
2006-04-21 20:44 ` Hugh Dickins
2006-04-21 20:50 ` Matt Mackall
2006-04-21 21:15 ` Pavel Machek
2006-04-21 21:36 ` Jeff Garzik
2006-04-23 12:58 ` Hugh Dickins
2006-04-29 18:06 ` Hugh Dickins
2006-04-21 23:39 ` Chris Ball
2006-04-23 12:42 ` Hugh Dickins
2006-04-23 13:52 ` Jeff Chua
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=20060419214959.GR15445@waste.org \
--to=mpm@selenic.com \
--cc=axboe@suse.de \
--cc=hugh@veritas.com \
--cc=jeff@garzik.org \
--cc=jeffchua@silk.corp.fedex.com \
--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 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.