On Thu, Mar 09, 2000 at 01:37:47PM -0500, Boris Okun wrote:
> Borislav Deianov wrote:
> > One question (I haven't looked at your patch): can it deal gracefully
> > with suspending the machine, turning it off, then resuming? I don't
> > think that you can do that yet on SMP but I hope that you soon will
> > (ACPI or the software suspend patch).
>
> I don't think it can, and I don't think the current code can either.
There's this comment in the current code:
/*
* If we have APM enabled or the CPU clock speed is variable
* (CPU stops clock on HLT or slows clock to save power)
* then the TSC timestamps may diverge by up to 1 jiffy from
* 'real time' but nothing will break.
* The most frequent case is that the CPU is "woken" from a halt
* state by the timer interrupt itself, so we get 0 error. In the
* rare cases where a driver would "wake" the CPU and request a
* timestamp, the maximum error is < 1 jiffy. But timestamps are
* still perfectly ordered.
* Note that the TSC counter will be reset if APM suspends
* to disk; this won't break the kernel, though, 'cuz we're
* smart. See arch/i386/kernel/apm.c.
*/
That sounds good, on the other hand I can't convince myself that it's
true. In do_fast_gettimeoffset we unconditionally use last_tsc_low
which is set only in timer_interrupt. So what happens if we wake up
and call do_gettimeofday before a time interrupt happens? Can't we
overshoot by seconds because last_tsc_low is wildly wrong? Basically,
I expected to see something in apm.c that sets last_tsc_low after
suspend, and I don't.
Regards,
Borislav
-
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/
This archive was generated by hypermail 2b29 : Wed Mar 15 2000 - 21:00:16 EST