Hi,
Just thought I'd add that I too am seeing a big time drift on my
Thinkpad (T30) without ACPI during an APM suspend w/ 2.6.10. If I can
help by testing patches, or providing any additional information,
please let me know.
Thanks,
Shaw
Hi!
> Just thought I'd add that I too am seeing a big time drift on my
> Thinkpad (T30) without ACPI during an APM suspend w/ 2.6.10. If I can
> help by testing patches, or providing any additional information,
> please let me know.
Probably code to compensate clock after ACPI suspend breaks apm case
:-(.
arch/i386/kernel/time.c, can you comment out
jiffies += sleep_length * HZ;
in timer_resume to see if it goes away?
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 <[email protected]> writes:
>> Just thought I'd add that I too am seeing a big time drift on my
>> Thinkpad (T30) without ACPI during an APM suspend w/ 2.6.10. If I can
>> help by testing patches, or providing any additional information,
>> please let me know.
>
> Probably code to compensate clock after ACPI suspend breaks apm case
> :-(.
i see problems with the clock after doing an acpi suspend. the
hardware clock is more or less okay (within a few minutes of the real
time anyway, nothing that ntp can't take care of) but the system time
is way off. this first started happening with 2.6.10-rc1. by now i've
gotten into the habit of running 'hwclock -s' by hand after each
resume. not really sure what changed and what i can do to debug/fix
this. for all it's worth i am running debian unstable.
--alex--
--
| I believe the moment is at hand when, by a paranoiac and active |
| advance of the mind, it will be possible (simultaneously with |
| automatism and other passive states) to systematize confusion |
| and thus to help to discredit completely the world of reality. |
On Sunday 09 January 2005 02:47 pm, Pavel Machek wrote:
> Probably code to compensate clock after ACPI suspend breaks apm case
>
> arch/i386/kernel/time.c, can you comment out
> jiffies += sleep_length * HZ;
>
> in timer_resume to see if it goes away?
Worked like a charm. I'm not seeing any time drift after your suggested
change.
Thanks,
Shaw
On Sun, Jan 09, 2005 at 11:28:53PM -0800, Shaw wrote:
> On Sunday 09 January 2005 02:47 pm, Pavel Machek wrote:
> > Probably code to compensate clock after ACPI suspend breaks apm case
> >
> > arch/i386/kernel/time.c, can you comment out
> > jiffies += sleep_length * HZ;
> >
> > in timer_resume to see if it goes away?
>
> Worked like a charm. I'm not seeing any time drift after your suggested
> change.
AIUI, this also means that a machine's uptime does not include time
whilst suspended. This was the behaviour prior to 2.6.10 and seems to be
more desirable as it counts the time the machine is actually running,
not just time since boot. Is there a good reason why we can't go back to
this?
Bernard.
Hi!
> > > Probably code to compensate clock after ACPI suspend breaks apm case
> > >
> > > arch/i386/kernel/time.c, can you comment out
> > > jiffies += sleep_length * HZ;
> > >
> > > in timer_resume to see if it goes away?
> >
> > Worked like a charm. I'm not seeing any time drift after your suggested
> > change.
>
> AIUI, this also means that a machine's uptime does not include time
> whilst suspended. This was the behaviour prior to 2.6.10 and seems to be
> more desirable as it counts the time the machine is actually running,
> not just time since boot. Is there a good reason why we can't go back to
> this?
I think it means very wrong system clock in ACPI state. Plus think
something wanting timeout of five minutes, then suspend one minute
after, machine sleeps for a hour.
With this approach, timeout should happen just after resume, with your
approach, it would wait 4 more minutes.
[Perhaps it needs to call lost_ticks or something like that.]
Pavel
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
On Mon, Jan 10, 2005 at 11:57:59AM +0100, Pavel Machek wrote:
> > > > arch/i386/kernel/time.c, can you comment out
> > > > jiffies += sleep_length * HZ;
> > >
> > > Worked like a charm. I'm not seeing any time drift after your suggested
> > > change.
> >
> > AIUI, this also means that a machine's uptime does not include time
> > whilst suspended. This was the behaviour prior to 2.6.10 and seems to be
> > more desirable as it counts the time the machine is actually running,
> > not just time since boot. Is there a good reason why we can't go back to
> > this?
>
> I think it means very wrong system clock in ACPI state.
So would implementing the equivalent of hwclock --hctosys keep both
ACPI & APM happy, but not include time suspended in uptime?
> Plus think something wanting timeout of five minutes, then suspend
> one minute after, machine sleeps for a hour.
>
> With this approach, timeout should happen just after resume, with your
> approach, it would wait 4 more minutes.
It does depend on whether a timer wants a delay against the wall
clock or the rest of the system. A process may be sleeping because
it's waiting for some other task to complete, or waiting for input
from the user. In these cases I claim time-whilst-hibernated should
not be counted.
Hibernating shouldn't be noticeable to the system. For example, a
popup window that came up an instant prior to suspending which is
normally on the screen for several seconds would vanish instantly
upon resuming without the user ever seeing it.
It also means that a group of timeouts that would normally occur a
large amount of time apart, will suddenly all expire the instant the
machine resumes, causing unexpected or undesirable behaviours, IMHO.
Bernard.
Hi!
> > > > > arch/i386/kernel/time.c, can you comment out
> > > > > jiffies += sleep_length * HZ;
> > > >
> > > > Worked like a charm. I'm not seeing any time drift after your suggested
> > > > change.
> > >
> > > AIUI, this also means that a machine's uptime does not include time
> > > whilst suspended. This was the behaviour prior to 2.6.10 and seems to be
> > > more desirable as it counts the time the machine is actually running,
> > > not just time since boot. Is there a good reason why we can't go back to
> > > this?
> >
> > I think it means very wrong system clock in ACPI state.
>
> So would implementing the equivalent of hwclock --hctosys keep both
> ACPI & APM happy, but not include time suspended in uptime?
I think that hwclock --hctosys is not quite straightforward operation
-- it needs to know if your CMOS clock are in local timezone or GMT,
or something like that, IIRC.
But this might work: compute difference between system and cmos time
before suspend, and use that info to restore time after suspend.
> > Plus think something wanting timeout of five minutes, then suspend
> > one minute after, machine sleeps for a hour.
> >
> > With this approach, timeout should happen just after resume, with your
> > approach, it would wait 4 more minutes.
>
> It does depend on whether a timer wants a delay against the wall
> clock or the rest of the system. A process may be sleeping because
> it's waiting for some other task to complete, or waiting for input
> from the user. In these cases I claim time-whilst-hibernated should
> not be counted.
> Hibernating shouldn't be noticeable to the system. For example, a
> popup window that came up an instant prior to suspending which is
> normally on the screen for several seconds would vanish instantly
> upon resuming without the user ever seeing it.
I disagree here.
If I do cli(); sleep(5 hours); sti();, system should survive that. If
you do cli(); sleep(5 hours); sti() but fail to compensate for lost
ticks, all sorts of funny things might happen if you are comunicating
with someone who did not sleep.
Pavel
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
Hi.
On Tue, 2005-01-11 at 11:14, Pavel Machek wrote:
> If I do cli(); sleep(5 hours); sti();, system should survive that. If
> you do cli(); sleep(5 hours); sti() but fail to compensate for lost
> ticks, all sorts of funny things might happen if you are comunicating
> with someone who did not sleep.
Wouldn't a thread that did that be fundamentally broken?
Nigel
--
Nigel Cunningham
Software Engineer, Canberra, Australia
http://www.cyclades.com
Ph: +61 (2) 6292 8028 Mob: +61 (417) 100 574
On Tue, Jan 11, 2005 at 01:14:26AM +0100, Pavel Machek wrote:
> > So would implementing the equivalent of hwclock --hctosys keep both
> > ACPI & APM happy, but not include time suspended in uptime?
>
> I think that hwclock --hctosys is not quite straightforward operation
> -- it needs to know if your CMOS clock are in local timezone or GMT,
> or something like that, IIRC.
>
> But this might work: compute difference between system and cmos time
> before suspend, and use that info to restore time after suspend.
Forgive my ignorance, but isn't this exactly what's done already?
Looking harder, in arch/i386/kernel/apm.c the system time is also
saved and restored in a very similar way to timer_suspend/resume.
Would this account for the time drift in APM mode? (sleep time being
accounted for twice?)
> > Hibernating shouldn't be noticeable to the system. For example, a
> > popup window that came up an instant prior to suspending which is
> > normally on the screen for several seconds would vanish instantly
> > upon resuming without the user ever seeing it.
>
> I disagree here.
>
> If I do cli(); sleep(5 hours); sti();, system should survive that. If
> you do cli(); sleep(5 hours); sti() but fail to compensate for lost
> ticks, all sorts of funny things might happen if you are comunicating
> with someone who did not sleep.
Then shouldn't it be fixed to compensate?
By including suspend time in jiffies, there becomes absolutely no
way for a kernel or userspace thread to measure actual usable system
time. At least if suspend time is not counted, they can use jiffies
or xtime depending on what they want to do. Making them one and the
same gives them no choice.
Bernard.
On Tue, 11 Jan 2005 01:14:26 +0100 Pavel Machek <[email protected]> wrote:
>
> I think that hwclock --hctosys is not quite straightforward operation
> -- it needs to know if your CMOS clock are in local timezone or GMT,
> or something like that, IIRC.
>
> But this might work: compute difference between system and cmos time
> before suspend, and use that info to restore time after suspend.
Which is, of course, what APM has done all along ...
--
Cheers,
Stephen Rothwell [email protected]
http://www.canb.auug.org.au/~sfr/
Hi!
> > I think that hwclock --hctosys is not quite straightforward operation
> > -- it needs to know if your CMOS clock are in local timezone or GMT,
> > or something like that, IIRC.
> >
> > But this might work: compute difference between system and cmos time
> > before suspend, and use that info to restore time after suspend.
>
> Which is, of course, what APM has done all along ...
Heh, but we need to find a way to do it without config options...
#ifdef CONFIG_APM_RTC_IS_GMT
# define clock_cmos_diff 0
# define got_clock_diff 1
#else
...no, it is actually okay, CONFIG_APM_RTC_IS_GMT is only
optimalization.
Hmm...
...and arch/i386/kernel/time.c contains copy of that code. That means
that we should kill apm.c copy and see why time.c copy sometimes does
the wrong thing.
Pavel
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
Hi!
> > If I do cli(); sleep(5 hours); sti();, system should survive that. If
> > you do cli(); sleep(5 hours); sti() but fail to compensate for lost
> > ticks, all sorts of funny things might happen if you are comunicating
> > with someone who did not sleep.
>
> Then shouldn't it be fixed to compensate?
>
> By including suspend time in jiffies, there becomes absolutely no
> way for a kernel or userspace thread to measure actual usable system
> time. At least if suspend time is not counted, they can use jiffies
> or xtime depending on what they want to do. Making them one and the
> same gives them no choice.
I do not think anyone should know about "actual usable system
time". If you do cli(); sleep(5hours); sti(), you include that in
jiffies, too. I do not see why swsusp should be handled differently.
Pavel
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
Hi!
> > If I do cli(); sleep(5 hours); sti();, system should survive that. If
> > you do cli(); sleep(5 hours); sti() but fail to compensate for lost
> > ticks, all sorts of funny things might happen if you are comunicating
> > with someone who did not sleep.
>
> Wouldn't a thread that did that be fundamentally broken?
Well, sleeping for 5 hours with interrupts off is certainly wrong
thing to do... But what swsusp does is pretty much equivalent. Machine
is unresponsive for hours...
Pavelp
--
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:
> ...and arch/i386/kernel/time.c contains copy of that code. That means
> that we should kill apm.c copy and see why time.c copy sometimes does
> the wrong thing.
We already know the difference: apm.c only updates xtime, time.c
updates both xtime and jiffies.
Bernard Blackham writes:
> Looking harder, in arch/i386/kernel/apm.c the system time is also
> saved and restored in a very similar way to timer_suspend/resume.
> Would this account for the time drift in APM mode? (sleep time being
> accounted for twice?)
No, apm.c's update to xtime is absolute, just like time.c's.
Doing both is pointless but not harmful. (I've already tried
with apm.c's xtime update commented out, but the time-warp
bug remained.)
My 0.02 SEK says it's the jiffies update that's broken.
Hia
> > Looking harder, in arch/i386/kernel/apm.c the system time is also
> > saved and restored in a very similar way to timer_suspend/resume.
> > Would this account for the time drift in APM mode? (sleep time being
> > accounted for twice?)
>
> No, apm.c's update to xtime is absolute, just like time.c's.
> Doing both is pointless but not harmful. (I've already tried
> with apm.c's xtime update commented out, but the time-warp
> bug remained.)
>
> My 0.02 SEK says it's the jiffies update that's broken.
Okay, can you
* kill jiffie update (x86-64, too)
* remove apm.c variant
* test it (or make someone test it) with apm?
I now see the drift with acpi, too :-(. I can do the acpi testing...
--
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms
Pavel Machek writes:
> Hia
>
> > > Looking harder, in arch/i386/kernel/apm.c the system time is also
> > > saved and restored in a very similar way to timer_suspend/resume.
> > > Would this account for the time drift in APM mode? (sleep time being
> > > accounted for twice?)
> >
> > No, apm.c's update to xtime is absolute, just like time.c's.
> > Doing both is pointless but not harmful. (I've already tried
> > with apm.c's xtime update commented out, but the time-warp
> > bug remained.)
> >
> > My 0.02 SEK says it's the jiffies update that's broken.
>
> Okay, can you
>
> * kill jiffie update (x86-64, too)
> * remove apm.c variant
> * test it (or make someone test it) with apm?
>
> I now see the drift with acpi, too :-(. I can do the acpi testing...
I'm away from my APM laptop until Friday, but I'll do this test then.
/Mikael
Hi!
> > > > Looking harder, in arch/i386/kernel/apm.c the system time is also
> > > > saved and restored in a very similar way to timer_suspend/resume.
> > > > Would this account for the time drift in APM mode? (sleep time being
> > > > accounted for twice?)
> > >
> > > No, apm.c's update to xtime is absolute, just like time.c's.
> > > Doing both is pointless but not harmful. (I've already tried
> > > with apm.c's xtime update commented out, but the time-warp
> > > bug remained.)
> > >
> > > My 0.02 SEK says it's the jiffies update that's broken.
> >
> > Okay, can you
> >
> > * kill jiffie update (x86-64, too)
> > * remove apm.c variant
> > * test it (or make someone test it) with apm?
> >
> > I now see the drift with acpi, too :-(. I can do the acpi testing...
>
> I'm away from my APM laptop until Friday, but I'll do this test then.
Now I recall why jiffies need to be updated: if they are not, ps
shows wrong process start times after resume.
If it causes worse problems, we may temporarily back that out, but...
Pavel
--
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms