On Mon, 13 Oct 2008, J?rgen Keil wrote:
> On my Toshiiba Tecra S1 laptop (running post snv_100 opensolaris > bits + some of my own suspend-to-ram fixes), I frequently get a > "time of day" warning during the first S3 resume (e.g. because > "clock jumped") and that "tracking the time of day clock" will be > stopped. > > Now I just found bug 6549734: time of day tracking stopped after > suspend resume cycle > http://bugs.opensolaris.org/view_bug.do?bug_id=6549734 > which is supposed to be fixed in snv_70. > > > Do others see warnings similar to the following on resume > from S3STR ... > > WARNING: Time of Day clock error: reason [Jumped by 0x142]. -- Stopped > tracking Time Of Day clock. > > ... or is this a problem that is specific for the hardware > that I'm using? > -- This message occurs when the internal TOD differs from the OS's clock by more than 2 seconds. The thought here is that the hardware TOD is bad, as the OS has been trying to keep the hardware in sync with itself. Of course suspend/resume offers at least this 2 second delay, but has tried to compensate by adjusting with the timekeeping before it makes this test (as eluded to in the previous message). So question 1: What are the local changes? Certainly, if they are useful to the OS, we should get them incorporated as soon as possible. Question 2: what was the value of the TOD and gethrtime() before and after s/r, as well as the approximate sleep time? It is possible there are hardware issues on the S1, so it would be nice to get a handle on it. ---- Randy
