Hi John, Dominik,
On Tue, 2005-03-29 at 14:11 -0800, john stultz wrote:
> 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.
Sorry for the late follow up. Unfort
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 w
On Wed, Mar 30, 2005 at 12:02:11AM +0200, Olivier Fourdan wrote:
> Hi,
>
> 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
Hi,
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
Hi all
Following my own thread, I found the following error in dmesg:
PM-Timer running at invalid rate: 33% of normal - aborting.
I found that interesting because 33% is 1/3 and the clock runs exactly
3x faster than normal...
A bit of search on google gave me several links to posts from oth
5 matches
Mail list logo
