On Wed, 2005-03-30 at 00:02 +0200, Olivier Fourdan wrote:
> A quick look at the source shows that the error is triggered in
> arch/i386/kernel/timers/timer_pm.c by the verify_pmtr_rate() function.
>
> My guess is that the pmtmr timer is right and the pit is wrong in my
> case. That would explain why the clock is wrong when being based on pit
> (like when forced with "clock=pit")
Yea. From your description this is most likely the cause of the issue.
Currently the time of day is still tick-based, using the tsc/pmtmr/hpet
only for interpolating between ticks.
> Maybe, if I can prove my guesses, a fix could be to "trust" the pmtmr
> clock when the user has passed a "clock=pmtmr" argument ? Does that make
> any sense ?
Well, if you tried the time of day re-work I've been working on it would
mask the issue somewhat, but you'd still have the problem that you are
taking too many timer interrupts.
One thing you could try is playing with the CLOCK_TICK_RATE value to see
if you just have very unique hardware.
A similar sounding issue has also been reported here:
http://bugme.osdl.org/show_bug.cgi?id=3927
thanks
-john
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
