Re: sata suspend resume ...

[Hugh Dickins <hugh@veritas.com>]

On Wed, 19 Apr 2006, Matt Mackall wrote:
> On Wed, Apr 19, 2006 at 11:50:55PM +0100, Hugh Dickins wrote:
> > 
> > Yes, the only reservation I have about your patch, entirely unrelated to
> > this resume issue, is that those systems which "hwclock -w" on shutdown
> > (do they on suspend too? haven't looked) will slowly tend to lose time.
> 
> If they weren't already using NTP, they were losing time anyway.

But considerably more slowly, I thought; but I could well be wrong,
it's not something I've thought a great deal about.

> > I tend to assume that it's not anything subtle, just that something
> > there needs a delay which it accidentally happened to get (most of
> > the time) from the CMOS reading, and with that gone now falls over.
> 
> I'm puzzled by 1 second not being enough. The former code should have
> taken between 1+e and 2 seconds, so I'd think mdelay(1000) would work.

You're assuming that resume worked on this before: not all the time.

This laptop is new to me, with several different issues in the
suspend to RAM area (e.g. the MSI business just fixed in -rc2).
I've not had it resuming reliably until just now: so I think that
with 2.6.16 (where I started out) it would (modulo other issues)
resume successfully when the former code worked out at 2 seconds,
but not when it worked out at 1 second.

One of the few things I'm sure of is that mdelay(1000) proved to be
not enough; maybe even mdelay(2000) is not enough, and I just haven't
yet hit a case which would show that.

Hugh
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/