Re: spin_lock error in arch/i386/kernel/time.c on APM resume

[Pavel Machek <pavel@ucw.cz>]

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!