Richard Gooch <rgooch@atnf.csiro.au> writes:
> Hi, all. I've been investigating the suspend/resume problems I've
> had with a Dell Inspiron 3200. After a day or so of poking and
> prodding, I've exposed what is either some broken assumptions in the
> Linux APM code or a broken Dell APM BIOS. Even if it's mainly the
> BIOS's fault, there is still a problem with clock drift. In any case,
> I've come up with a solution that is robust, and which I'd like to
> pass by other who are more intimate with the APM code than I.
I don't think anyone really wants to be intimate with the APM code. :-)
> If people are happy with my proposed solutions, I'll put together a
> shiny new patch and post it to the list.
. . .
> What I'm seeing is a sequence like:
> suspend, resume, suspend, resume.
>
> I noticed that the time between the first resume and the second
> suspend is up to and including 2 jiffies. The fix I implemented for
> this is to ignore a suspend event less than HZ jiffies (i.e. 1 second)
> after a resume event.
>
> ****PROPOSAL 1: add this to the kernel, available as a config option.
Seems like a reasonable work around.
[Removed stuff about RTC reading and reseeting the time.]
> ****PROPOSAL 2: add an ioctl() to /proc/apm so that the kernel can be
> told the offset between the system clock and the RTC.
Again, seems liek a resonable workaround. However see the patch on
my home page - I have started to add sysctls for this stuff.
Cheers,
Stephen
-- Stephen Rothwell Stephen.Rothwell@canb.auug.org.au http://www.canb.auug.org.au/~sfr/- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/