Re: Laptops & CPU frequency

[john stultz]

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



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/