Re: Screwy clock after apm suspend

Re: Screwy clock after apm suspend

[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.

Thanks,
Shaw

Re: Screwy clock after apm suspend

[Pavel Machek]

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!

Re: Screwy clock after apm suspend

[Alex Romosan]

Pavel Machek <pavel@ucw.cz> 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. |

Re: Screwy clock after apm suspend

[Shaw]

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

Re: Screwy clock after apm suspend

[bernard]

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.

Re: Screwy clock after apm suspend

[Pavel Machek]

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!

Re: Screwy clock after apm suspend

[Bernard Blackham]

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.

Re: Screwy clock after apm suspend

[Pavel Machek]

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!

Re: Screwy clock after apm suspend

[Nigel Cunningham]

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

Re: Screwy clock after apm suspend

[Bernard Blackham]

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.

Re: Screwy clock after apm suspend

[Pavel Machek]

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!

Re: Screwy clock after apm suspend

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 546 bytes --]

On Tue, 11 Jan 2005 01:14:26 +0100 Pavel Machek <pavel@ucw.cz> 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                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Screwy clock after apm suspend

[Pavel Machek]

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!

Re: Screwy clock after apm suspend

[Pavel Machek]

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!

Re: Screwy clock after apm suspend

[Mikael Pettersson]

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.

Re: Screwy clock after apm suspend

[Mikael Pettersson]

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.

Re: Screwy clock after apm suspend

[Pavel Machek]

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         

Re: Screwy clock after apm suspend

[Mikael Pettersson]

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

Re: Screwy clock after apm suspend

[Pavel Machek]

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         

Re: Screwy clock after apm suspend

[Alex Romosan]

Mikael Pettersson <mikpe@csd.uu.se> writes:

> I'm no longer seeing any time jumps after resumes with the
> 2.6.11-rc1 kernel. It looks like the wall_jiffies change in
> time.c fixed the bug.

i can also confirm the that the time no longer jumps after an acpi
resume with the 2.6.11-rc1 kernel.

--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. |

Re: Screwy clock after apm suspend

[Mikael Pettersson]

On Tue, 11 Jan 2005 14:10:19 +0100, Pavel Machek wrote:
>>  > 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 no longer seeing any time jumps after resumes with the
2.6.11-rc1 kernel. It looks like the wall_jiffies change in
time.c fixed the bug.

/Mikael

Re: Screwy clock after apm suspend

[Pavel Machek]

Hi!

> >2.6.10 screws up my system clock.
> >Two kernel/hardware clock readings, before and after suspend.
> >-------------
> >plaz@gonzo:~$ date ;hwclock
> >Tue Dec 28 15:52:39 PST 2004
> >Tue Dec 28 14:54:07 2004 -0.503621 seconds
> >#suspend, resume
> >plaz@gonzo:~$ date ;hwclock
> >Tue Dec 28 16:11:58 PST 2004
> >Tue Dec 28 15:04:06 2004 -0.168262 seconds
> ...
> >I did not have this problem with 2.6.9. My machine uses APM, clock 
> >stores local time (specified in kernel config). I use PIT for 
> >timesource, as others were losing ticks when on battery power (changes 
> >CPU clock speed). Again, did _not_ have this problem with 2.6.9.
> 
> I reported this problem a while ago for 2.6.10-rc1:
> http://marc.theaimsgroup.com/?l=linux-kernel&m=110172841429272&w=2.
> At the time I thought the APM daemon's hwclock --hctosys at resume
> might be in conflict with the kernel change, but I've since disabled
> that and it didn't solve the problem.
> 
> For now, I'm using the patch below to revert the i386 time.c's
> behaviour to what it was before the broken change in 2.6.10-rc1.


Hmm, this will break time on ACPI systems :-(. Perhaps what we want is
equivalent of hwclock --hctosys here?

> --- linux-2.6.10/arch/i386/kernel/time.c.~1~	2004-12-25 12:16:17.000000000 +0100
> +++ linux-2.6.10/arch/i386/kernel/time.c	2004-12-25 23:56:19.000000000 +0100
> @@ -319,7 +319,7 @@ unsigned long get_cmos_time(void)
>  	return retval;
>  }
>  
> -static long clock_cmos_diff, sleep_start;
> +static long clock_cmos_diff;
>  
>  static int timer_suspend(struct sys_device *dev, u32 state)
>  {
> @@ -328,7 +328,6 @@ static int timer_suspend(struct sys_devi
>  	 */
>  	clock_cmos_diff = -get_cmos_time();
>  	clock_cmos_diff += get_seconds();
> -	sleep_start = get_cmos_time();
>  	return 0;
>  }
>  
> @@ -336,19 +335,16 @@ static int timer_resume(struct sys_devic
>  {
>  	unsigned long flags;
>  	unsigned long sec;
> -	unsigned long sleep_length;
>  
>  #ifdef CONFIG_HPET_TIMER
>  	if (is_hpet_enabled())
>  		hpet_reenable();
>  #endif
>  	sec = get_cmos_time() + clock_cmos_diff;
> -	sleep_length = get_cmos_time() - sleep_start;
>  	write_seqlock_irqsave(&xtime_lock, flags);
>  	xtime.tv_sec = sec;
>  	xtime.tv_nsec = 0;
>  	write_sequnlock_irqrestore(&xtime_lock, flags);
> -	jiffies += sleep_length * HZ;
>  	return 0;

-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!

Re: Screwy clock after apm suspend

[Mikael Pettersson]

On Tue, 28 Dec 2004 16:29:44 -0800, Brannon Klopfer wrote:
>2.6.10 screws up my system clock.
>Two kernel/hardware clock readings, before and after suspend.
>-------------
>plaz@gonzo:~$ date ;hwclock
>Tue Dec 28 15:52:39 PST 2004
>Tue Dec 28 14:54:07 2004 -0.503621 seconds
>#suspend, resume
>plaz@gonzo:~$ date ;hwclock
>Tue Dec 28 16:11:58 PST 2004
>Tue Dec 28 15:04:06 2004 -0.168262 seconds
...
>I did not have this problem with 2.6.9. My machine uses APM, clock 
>stores local time (specified in kernel config). I use PIT for 
>timesource, as others were losing ticks when on battery power (changes 
>CPU clock speed). Again, did _not_ have this problem with 2.6.9.

I reported this problem a while ago for 2.6.10-rc1:
http://marc.theaimsgroup.com/?l=linux-kernel&m=110172841429272&w=2.
At the time I thought the APM daemon's hwclock --hctosys at resume
might be in conflict with the kernel change, but I've since disabled
that and it didn't solve the problem.

For now, I'm using the patch below to revert the i386 time.c's
behaviour to what it was before the broken change in 2.6.10-rc1.

/Mikael

--- linux-2.6.10/arch/i386/kernel/time.c.~1~	2004-12-25 12:16:17.000000000 +0100
+++ linux-2.6.10/arch/i386/kernel/time.c	2004-12-25 23:56:19.000000000 +0100
@@ -319,7 +319,7 @@ unsigned long get_cmos_time(void)
 	return retval;
 }
 
-static long clock_cmos_diff, sleep_start;
+static long clock_cmos_diff;
 
 static int timer_suspend(struct sys_device *dev, u32 state)
 {
@@ -328,7 +328,6 @@ static int timer_suspend(struct sys_devi
 	 */
 	clock_cmos_diff = -get_cmos_time();
 	clock_cmos_diff += get_seconds();
-	sleep_start = get_cmos_time();
 	return 0;
 }
 
@@ -336,19 +335,16 @@ static int timer_resume(struct sys_devic
 {
 	unsigned long flags;
 	unsigned long sec;
-	unsigned long sleep_length;
 
 #ifdef CONFIG_HPET_TIMER
 	if (is_hpet_enabled())
 		hpet_reenable();
 #endif
 	sec = get_cmos_time() + clock_cmos_diff;
-	sleep_length = get_cmos_time() - sleep_start;
 	write_seqlock_irqsave(&xtime_lock, flags);
 	xtime.tv_sec = sec;
 	xtime.tv_nsec = 0;
 	write_sequnlock_irqrestore(&xtime_lock, flags);
-	jiffies += sleep_length * HZ;
 	return 0;
 }
 

Re: Screwy clock after apm suspend

[Nigel Cunningham]

Hi.

We've seen this problem with Suspend2 as well. One of my Suspend2 users
has looked into the problem and suggested a couple of solutions; I'll
take a look at them shortly and send a patch here as well.

Regards,

Nigel

On Wed, 2004-12-29 at 11:29, Brannon Klopfer wrote:
> 2.6.10
> Slackware 10/-current
> IBM ThinkPad 600E
> ----------------
> 
> 2.6.10 screws up my system clock.
> Two kernel/hardware clock readings, before and after suspend.
> -------------
> plaz@gonzo:~$ date ;hwclock
> Tue Dec 28 15:52:39 PST 2004
> Tue Dec 28 14:54:07 2004 -0.503621 seconds
> #suspend, resume
> plaz@gonzo:~$ date ;hwclock
> Tue Dec 28 16:11:58 PST 2004
> Tue Dec 28 15:04:06 2004 -0.168262 seconds
> ---------------------
> These are all when the comp is on without suspend (difference about the 
> same throughout).
> ----------------
> plaz@gonzo:~$ date ;hwclock
> Tue Dec 28 16:14:52 PST 2004
> Tue Dec 28 15:07:00 2004 -0.251812 seconds
> plaz@gonzo:~$ date ;hwclock
> Tue Dec 28 16:15:26 PST 2004
> Tue Dec 28 15:07:34 2004 -0.236138 seconds
> plaz@gonzo:~$ date ;hwclock
> Tue Dec 28 16:19:48 PST 2004
> Tue Dec 28 15:11:57 2004 -0.908540 seconds
> plaz@gonzo:~$
> ------------
> I did not have this problem with 2.6.9. My machine uses APM, clock 
> stores local time (specified in kernel config). I use PIT for 
> timesource, as others were losing ticks when on battery power (changes 
> CPU clock speed). Again, did _not_ have this problem with 2.6.9.
> 
> Be glad to try out patches,
> Brannon Klopfer
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
-- 
Nigel Cunningham
Cyclades Software Engineer
Canberra, Australia

http://www.cyclades.com

+61 (2) 6292 8028
+61 (417) 100 574

Screwy clock after apm suspend

[Brannon Klopfer]

2.6.10
Slackware 10/-current
IBM ThinkPad 600E
----------------

2.6.10 screws up my system clock.
Two kernel/hardware clock readings, before and after suspend.
-------------
plaz@gonzo:~$ date ;hwclock
Tue Dec 28 15:52:39 PST 2004
Tue Dec 28 14:54:07 2004 -0.503621 seconds
#suspend, resume
plaz@gonzo:~$ date ;hwclock
Tue Dec 28 16:11:58 PST 2004
Tue Dec 28 15:04:06 2004 -0.168262 seconds
---------------------
These are all when the comp is on without suspend (difference about the 
same throughout).
----------------
plaz@gonzo:~$ date ;hwclock
Tue Dec 28 16:14:52 PST 2004
Tue Dec 28 15:07:00 2004 -0.251812 seconds
plaz@gonzo:~$ date ;hwclock
Tue Dec 28 16:15:26 PST 2004
Tue Dec 28 15:07:34 2004 -0.236138 seconds
plaz@gonzo:~$ date ;hwclock
Tue Dec 28 16:19:48 PST 2004
Tue Dec 28 15:11:57 2004 -0.908540 seconds
plaz@gonzo:~$
------------
I did not have this problem with 2.6.9. My machine uses APM, clock 
stores local time (specified in kernel config). I use PIT for 
timesource, as others were losing ticks when on battery power (changes 
CPU clock speed). Again, did _not_ have this problem with 2.6.9.

Be glad to try out patches,
Brannon Klopfer