> OK, here are a few TSC readings of a 6x86MX machine, using Rafael
> Reilova's neat code (slightly modified, see attached source). You can
> see that all counts are > 2^32, which means the top 32 bits are _not_
> affected by Suspend states (the kernel going idle).
>
> [root@lw2l /root]# ./test
> This is a 6x86MX with Suspend on Halt enabled
> 5528048284543 TSC reading at 1 second intervals.
> 5528049109927 TSC reading at 1 second intervals.
> 5528049854185 TSC reading at 1 second intervals.
> 5528050448925 TSC reading at 1 second intervals.
> 5528051464460 TSC reading at 1 second intervals.
> This is a 6x86MX with Suspend on Halt disabled
> 5528239392036 TSC reading at 1 second intervals.
> 5528427321392 TSC reading at 1 second intervals.
> 5528615251937 TSC reading at 1 second intervals.
> 5528803178887 TSC reading at 1 second intervals.
> 5528991108384 TSC reading at 1 second intervals.
> [root@lw2l /root]#
>
> There has to be another explanation for the divide by zero oops.
>From the readings your took I conclude the machine did not do a suspend to
disk, just a suspend-on-halt (which stoppped the TSC). _Only_ during
Suspend-To-Disk the entire processor status is written to disk and
everything is turned off. When the system recovers from the S-T-D, it
will reload the register information, but (unfortuantly) cant load the
upper 32 bits of the TSC. --> whoppa; the problem...
> > I'll believe you there. *BUT* this needs to be documented in big red
> > letter somewhere: DON'T SUSPEND-ON-HALT.
Suspend to halt != Suspend to disk
Met vriendelijke groet,
Pauline Middelink
-- PGP Key fingerprint = DE 6B D0 D9 19 AD A7 A0 58 A3 06 9D B6 34 39 E2 For more details look at my website http://www.polyware.nl/~middelin- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu