Date: Wed, 10 Dec 1997 11:29:21 -0500 From: Ken Key <key@cs.utk.edu> To: freebsd-mobile@freebsd.org Cc: key@cs.utk.edu Subject: APM suspend/resume and the "calltodo" timer list. Message-ID: <199712101629.LAA13982@duncan.cs.utk.edu>
next in thread | raw e-mail | index | archive | help
Hi Folks, looking at the -STABLE and -CURRENT and -PAO (at least of 971201) apm code, I noticed that nothing updates the calltodo timer list when a laptop resumes from a suspend. This means that applications sleeping on, say, a select timer don't fire when the resume occurs after the timer should have fired and won't fire for timer_time + suspend_time rather than the intended timer_time. The particular application that caused me to investigate this was the DHCP client, which was stuck on the select() timer even though the lease had expired. While I could just whack on the application code to detect clock-warpage, this struck me as a general class of problem. I've modified the apm_default_resume() code to call into kern_clock.c and fixup the timer entries on calltodo. Thus, when the next hardclock() call occurs, it'll tripp running softclock and the timers that expired during the suspend will fire. I've done some minimal testing on my system and haven't detected any problems thus far. I'm soliciting the mobile community at large for suggestions of things I may not have thought about that this might negatively effect in the OS. The worst I have come up with is just that the system potentially could become very busy at startup time running all the expired timers that have collapsed together. I haven't noticed this thus far on my tp560, but I won't claim having performed an exhaustive analysis. If nothing bad comes up in this testing, I'll post my patch. Thanks for your input, Ken Key (key@cs.utk.edu)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199712101629.LAA13982>