linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Pavel Machek <pavel@ucw.cz>
To: Bernard Blackham <bernard@blackham.com.au>
Cc: Shaw <shawv@comcast.net>, linux-kernel@vger.kernel.org
Subject: Re: Screwy clock after apm suspend
Date: Tue, 11 Jan 2005 01:14:26 +0100	[thread overview]
Message-ID: <20050111001426.GF1444@elf.ucw.cz> (raw)
In-Reply-To: <20050110174804.GC4641@blackham.com.au>

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!

  reply	other threads:[~2005-01-11  0:20 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-01-07 18:08 Screwy clock after apm suspend Shaw
2005-01-09 22:47 ` Pavel Machek
2005-01-10  2:15   ` Alex Romosan
2005-01-10  7:28   ` Shaw
2005-01-10  7:44     ` bernard
2005-01-10 10:57       ` Pavel Machek
2005-01-10 17:48         ` Bernard Blackham
2005-01-11  0:14           ` Pavel Machek [this message]
2005-01-11  1:10             ` Nigel Cunningham
2005-01-11  3:12               ` Pavel Machek
2005-01-11  1:16             ` Bernard Blackham
2005-01-11  3:21               ` Pavel Machek
2005-01-11 12:36               ` Mikael Pettersson
2005-01-11 13:10                 ` Pavel Machek
2005-01-11 14:15                   ` Mikael Pettersson
2005-01-11 20:18                     ` Pavel Machek
2005-01-11  3:13             ` Stephen Rothwell
2005-01-11  3:19               ` Pavel Machek
2005-01-11 12:32                 ` Mikael Pettersson
  -- strict thread matches above, loose matches on Subject: below --
2005-01-15 18:30 Mikael Pettersson
2005-01-16 19:47 ` Alex Romosan
2004-12-29 11:38 Mikael Pettersson
2005-01-03 17:34 ` Pavel Machek
2004-12-29  0:29 Brannon Klopfer
2004-12-29  1:18 ` Nigel Cunningham

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20050111001426.GF1444@elf.ucw.cz \
    --to=pavel@ucw.cz \
    --cc=bernard@blackham.com.au \
    --cc=linux-kernel@vger.kernel.org \
    --cc=shawv@comcast.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).