![]() | |||||||||||||
Messages in this thread |
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/ | ||||||||||||
| Last update: 2006-04-20 01:29 [from the cache] ©2003-2008 | |||||||||||||