Hi!
> >>I agree. Still in all that follows, no one has addressed the apparent
> >>race described above. The reason the system reported the errors that
> >>started this thread is that the APM restore code was trying to read the
> >>cmos clock (I assume to set the xtime clock) WHILE the timer interrupt
> >>code what trying to set the cmos clock from xtime. In other words, it is
> >>destroying the time it is trying to read. I repeat "Possibly the APM
> >>code should change time_status to STA_UNSYNC on the way into the sleep."
> >>I am not sure how ntp is supposed to react to the resume but I suspect
> >>that the system time is rather out of sync...
> >
> >
> >It needs to work without NTP, too. You don't get NTP on plane (etc)
> >where suspend is most usefull.
> >
> >We have CMOS clock, it should be possible to get time from there
> >without resorting to NTP..
>
> Eh... sure, but... the bug was reported because the system was attempting
> to update the cmos clock (which it does every ~11 min.) during APM exit.
> It does this IF AND ONLY IF the system is synced to an external source as
> indicated by the STA_UNSYNC bit being cleared in the time_state. Now, I
> don't know what or how APM and NTP are supposed to play together, but I
> suspect that on entry to APM time is no longer synced, thus my comment.
>
> As to your comment, the bug would never have shown its ugly face if the
> system wasn't using NTP.
Uh, ok, you are right. We should set time to STA_UNSYNC so that we do
not write back to CMOS during/shortly after resume. I did not realize
what STA_UNSYNC means. Perhaps you have patch to do that somewhere?
;-))))
Pavel
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
