From: john stultz <johnstul@us.ibm.com>
To: Disconnect <lkml@sigkill.net>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Laptops & CPU frequency
Date: Mon, 12 Jan 2004 15:19:38 -0800 [thread overview]
Message-ID: <1073949577.28098.68.camel@cog.beaverton.ibm.com> (raw)
In-Reply-To: <1073938271.2156.10.camel@slappy>
On Mon, 2004-01-12 at 12:11, Disconnect wrote:
> On Mon, 2004-01-12 at 14:52, john stultz wrote:
> > More info please. What type of hardware is this? Could you send me your
> > dmesg for booting both with and without AC power?
>
> I had a similar problem with 2.4 (with and without acpi, speedstep, etc)
> on an Inspiron 8500. Unfortunately, Dell only gives "use speedstep"
> (boot in powersave on battery, performance on ac) and "always in lowest
> performance mode" options in the bios. (Dell, you listening? How about
> "don't use speedstep, only use [powersave/performance] mode"? Or "Boot
> in last-used mode"..)
>
> When the machine is suspended (swsusp) while on AC, it must be resumed
> on AC (and same if suspended on battery) or the kernel gets very
> confused. Time doubles (or halves), etc. No amount of arguing with
> speedstep (or acpi in general, if speedstep wasn't applied/used) will
> get it sane. (FWIW XP gets this right - hibernate XP on battery, resume
> on ac, hibernate, resume on battery, etc and it does fine.)
>
> Perhaps linux would benefit from some form of "make sure the cpu is
> doing what we think it is" knob? Something that could be triggered by
> scripts (or even swsusp/apm directly) as early in a resume as possible,
> before the miscalculation cascades into crashes. (This would be
> completely independent from speedstep or acpi, since I suspect that the
> same problems may occur independently of acpi on other machines with
> similar braindamaged bios.)
>
> Thoughts? I can do more rigorous testing and report back if needed. (I
> spent 2 days playing with it a few months ago, then gave it up as
> hopeless.)
I'm surprised that you've seen this on 2.4, as the TSC time code does
not try to compensate for lost ticks. Instead we only use the TSC value
to offset from xtime, reseting our offset each tick. So changes in cpu
frequency should only cause time inconsistencies, not time doubling.
Might something be going oddly in setting up the timer interrupt on
restore? I'd be interested in more details.
In 2.6 we do try to detect when cpufreq changes without notifying us.
However its a balancing act as the symptoms are the same as when you
have a broken PIT or lose too many interrupt. Hopefully HPET and the
ACPI PM timesource will provide more reliable time sources.
thanks
-john
next prev parent reply other threads:[~2004-01-12 23:20 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-01-11 2:56 jlnance
2004-01-11 3:17 ` Robert Love
2004-01-11 4:12 ` Valdis.Kletnieks
2004-01-11 6:16 ` Willy Tarreau
2004-01-11 10:27 ` Xavier Bestel
2004-01-11 10:33 ` Xavier Bestel
2004-01-12 16:58 ` Jerry Cooperstein
2004-01-12 21:19 ` Xavier Bestel
2004-01-12 19:52 ` john stultz
2004-01-12 20:11 ` Disconnect
2004-01-12 23:19 ` john stultz [this message]
2004-01-12 21:28 ` Xavier Bestel
2004-01-12 22:07 ` john stultz
2004-01-13 9:13 ` Xavier Bestel
2004-01-11 17:06 ` Matthew Garrett
2004-01-11 17:13 ` Robert Love
2004-01-11 17:44 ` Matthew Garrett
2004-01-11 17:54 ` Robert Love
2004-01-14 4:59 ` Dave Jones
2004-01-14 19:11 ` Daniel Gryniewicz
2004-01-14 19:17 ` Robert Love
2004-01-14 19:23 ` Daniel Gryniewicz
2004-01-15 20:42 ` Pavel Machek
2004-01-15 21:18 ` Daniel Gryniewicz
2004-01-15 22:21 ` John Bradford
2004-01-15 22:48 ` Pavel Machek
2004-01-19 17:44 ` Ducrot Bruno
2004-01-16 10:47 ` Pavel Machek
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=1073949577.28098.68.camel@cog.beaverton.ibm.com \
--to=johnstul@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lkml@sigkill.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
all inboxes | Powered by JetHome®