Starting with 2.6.10-rc1, date and time on my old APM-based
laptop is messed up after a resume. Specifically, Emacs and
xclock both make a huge forward leap and then stop updating
their current time displays.
The cause is the "jiffies += sleep_length * HZ;" addition
to arch/i386/kernel/time.c:time_resume() which is in conflict
with the hwlock --hctosys that the APM daemon normally does
at resume.
Preventing apmd from updating the system time does eliminate
the problems I described, but this requires kernel-version
dependent settings in user-space, which is ugly and fragile.
Just FYI. I don't have a nice solution yet.
/Mikael
Hi!
> Starting with 2.6.10-rc1, date and time on my old APM-based
> laptop is messed up after a resume. Specifically, Emacs and
> xclock both make a huge forward leap and then stop updating
> their current time displays.
>
> The cause is the "jiffies += sleep_length * HZ;" addition
> to arch/i386/kernel/time.c:time_resume() which is in conflict
> with the hwlock --hctosys that the APM daemon normally does
> at resume.
I do not understand why they interfere... time_resume should fix
system time, then userland sets it to the right value, again. Unless
these two happen in paralel (they should not), nothing bad should happen.
Can you try to suspend, wait, launch hwclock --hctosys manually?
Pavel
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
Pavel Machek writes:
> Hi!
>
> > Starting with 2.6.10-rc1, date and time on my old APM-based
> > laptop is messed up after a resume. Specifically, Emacs and
> > xclock both make a huge forward leap and then stop updating
> > their current time displays.
> >
> > The cause is the "jiffies += sleep_length * HZ;" addition
> > to arch/i386/kernel/time.c:time_resume() which is in conflict
> > with the hwlock --hctosys that the APM daemon normally does
> > at resume.
>
> I do not understand why they interfere... time_resume should fix
> system time, then userland sets it to the right value, again. Unless
> these two happen in paralel (they should not), nothing bad should happen.
>
> Can you try to suspend, wait, launch hwclock --hctosys manually?
I disabled apmd's automatic hwlock --hctosys and ran it manually
after resume + 5 seconds: no problem. I suspect that apmd runs
really early at resume and that's why it interferes with time_resume.
/Mikael
Hi!
> > > Starting with 2.6.10-rc1, date and time on my old APM-based
> > > laptop is messed up after a resume. Specifically, Emacs and
> > > xclock both make a huge forward leap and then stop updating
> > > their current time displays.
> > >
> > > The cause is the "jiffies += sleep_length * HZ;" addition
> > > to arch/i386/kernel/time.c:time_resume() which is in conflict
> > > with the hwlock --hctosys that the APM daemon normally does
> > > at resume.
> >
> > I do not understand why they interfere... time_resume should fix
> > system time, then userland sets it to the right value, again. Unless
> > these two happen in paralel (they should not), nothing bad should happen.
> >
> > Can you try to suspend, wait, launch hwclock --hctosys manually?
>
> I disabled apmd's automatic hwlock --hctosys and ran it manually
> after resume + 5 seconds: no problem. I suspect that apmd runs
> really early at resume and that's why it interferes with time_resume.
You may workaround it be sleep 1 before hwclock --hctosys, I
guess. But debugging it would be even better :-). Do we freeze
processes during apm suspend? If not, we should...
Pavel
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!