--E7UzyiO3cWVgLa0z
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

tech-kern readers:

The following message was posted recently to tech-userlevel:

On Wed, Jul 12, 2006 at 11:50:46PM +0200, Arnaud Lacombe wrote:
> With recent change in ACPI and in time handling, I was wondering what
> should be the behaviour of uptime(1) when we start to deal with sleep (with ACPI
> S3 or APM). uptime(1) defines it as "the length of time the system has
> been up" but when the laptop goes into sleep mode, is it still considered as
> being up or not ?

This made me wonder about a parallel question for kernel internals,
regarding timecounters under similar circumstances.

I think they're mostly separate discussions, so I've set replies for
this message to tech-kern; I'll reply in a moment for the userlevel
context separately.

Timecounters rely on the assumption that the underlying counter is
monotonically increasing, wrapping predictably at a known boundary.  I
wonder what impact various kinds of suspend/resume might have on this
assumption, and what can be done to protect against bad effects.

The answer almost certainly varies according to the specific counter,
and the specific type of sleep/suspend done.  For example, I imagine
that in S1 sleep, the TSC and i8259 timecounters are probably
preserved, and maybe also in S3. The same may also be true for APM
sleeps; in fact it may be the case that in most of the permutations we
can presently reach, it's not actually an issue, if mostly by good
luck.

I can imagine at least one case where the counter values may get
lost/reset: BIOS-mediated APM suspend-to-disk, where the hardware is
fully powered off and thus lose its present state. I don't beleive
there's any way to 'restore' the TSC cycle-counter, nor that an APM
BIOS would try to even if there was.

I also expect we'll come across other cases as we expand the range of
sleep permutations we can reach.  Is the behaviour if the ACPI counter
well-defined across each of the various state transitions?

So: what can/does/should the timecounter code do to protect itself
against this issue?  I expect it's not a big deal to reset or reselect
each of the counters on a wakeup event, provided the event is
delivered, and the specific counter implementations have enough
information to know whether its necessary for this specific
event. Should we do something in preparation on suspend (perhaps
switching to a lower quality but more suspend-safe counter, or setting
flags to warn waking-up code that the counter may be invalid)?

I know there's some handling of this already, but was there a general
analysis or just specific workarounds for particular cases as they
were discovered (like not using the TSC if X or Y)?

If the underlying timecounters, and thus the bintime variables that
ultimately get shown by uptime(1), have gotten screwed up, the
userland discussion about which and how these variables should be
presented by uptime(1) is irrelevant.

--
Dan.

--E7UzyiO3cWVgLa0z
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.4 (NetBSD)

iD8DBQFEtZtJEAVxvV4N66cRAt35AJ9bxG/Dn9i+85f3ApKGPWlXayOs5ACgtzKu
7YQuwSoyrX+KaDtwz4cqY/w=
=qHYK
-----END PGP SIGNATURE-----

--E7UzyiO3cWVgLa0z--