Messages in this thread | | | Date | Thu, 20 Apr 2006 00:26:27 +0100 (BST) | From | Hugh Dickins <> | Subject | Re: sata suspend resume ... |
| |
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/
| |