I recently noticed this message in my bootup that I don't remember
from before:
PCI: Probing PCI hardware (bus 00)
* Found PM-Timer Bug on the chipset. Due to workarounds for a bug,
* this clock source is slow. Consider trying other clock sources
------
How would this affect my clock? It says to try another
clock source, what type of clock source would it be suggesting I
use? Another chip already in the computer? It is an Intel 440BX
chipset; on an Dell motherboard. Would that be likely to have
another chip source that is compensating?
I don't notice a significant clock slowdown, but I'm running NTP,
so that could be masking the problem.
NTP values appear: to indicated smallish values for clock variance, but I'm
not sure what is "standardly" considered good or bad, so I don't have
anything
to compare to.
Relevant ntp time vars show:
leap indicator: 00
stratum: 2
precision: -20
root distance: 0.01445 s
root dispersion: 0.01372 s
jitter: 0.002335 s
stability: 58.565 ppm
broadcastdelay: 0.003998 s
---
maximum error 130449 us, estimated error 1923 us
ntp_adjtime() returns code 0 (OK)
offset 1384.000 us, frequency 74.584 ppm, interval 1 s,
maximum error 130449 us, estimated error 1923 us,
status 0x1 (PLL),
time constant 3, precision 1.000 us, tolerance 512 ppm,
--------
It seems the estimated error is .1923ms, with a precision
of 1us.
Is the clock "slowness" indicated by the
"offset 1384us, 74.584ppm @ interval 1s? I.e. do I read that
as the clock is off by 74.584ppm/s, or ~75us/sec, or do I look
at the offset of 1384us/sec, meaning off by .1384ms/s (wouldn't
that be 1384ppm?). Seems the stability is fairly low, on the
order of 58.656ppm, or about .058ms/s?
Seems like fewer questions are being answered these days than
in days past. Is this because of a change in the list focus (maybe
all the patches being submitted),
- or change in list membership, i.e. fewer people up-to-speed on
older HW,
- or increased specialization in specific kernel areas with fewer
having knowledge outside their specific domain, or
what?
It it is an ugly tradeoff between development time spent
and answering questions that might increase understanding of
people on the list (or maybe it's such common knowledge that
no one bothers to answer... dunno...
but thanks for any ideas...especially on the original issue.
Linda W.
On Wed, 2006-11-29 at 16:56 -0800, Linda Walsh wrote:
> I recently noticed this message in my bootup that I don't remember
> from before:
>
> PCI: Probing PCI hardware (bus 00)
> * Found PM-Timer Bug on the chipset. Due to workarounds for a bug,
> * this clock source is slow. Consider trying other clock sources
This basically means that your chipset has a bug which requires the ACPI
PM timer to be read three times in order to get a valid reading.
This will cause gettimeofday/clock_gettime to take longer to execute,
which is what is meant by "slow" (rather then the counter's frequency
being incorrect).
> How would this affect my clock? It says to try another
> clock source, what type of clock source would it be suggesting I
> use? Another chip already in the computer? It is an Intel 440BX
> chipset; on an Dell motherboard. Would that be likely to have
> another chip source that is compensating?
>
> I don't notice a significant clock slowdown, but I'm running NTP,
> so that could be masking the problem.
Unless you're running performance critical programs that utilize
gettimeofday/clock_gettime, you probably won't notice anything. Time
should still function properly. If you are having performance issues,
you can try using a different clocksource (the TSC is probably safe, but
not necessarily).
thanks
-john
john stultz wrote:
> On Wed, 2006-11-29 at 16:56 -0800, Linda Walsh wrote:
>
>> I recently noticed this message in my bootup that I don't remember
>> from before:
>>
>> PCI: Probing PCI hardware (bus 00)
>> * Found PM-Timer Bug on the chipset. Due to workarounds for a bug,
>> * this clock source is slow. Consider trying other clock sources
>>
>
> This basically means that your chipset has a bug which requires the ACPI
> PM timer to be read three times in order to get a valid reading.
>
> This will cause gettimeofday/clock_gettime to take longer to execute,
> which is what is meant by "slow" (rather then the counter's frequency
> being incorrect).
>
>
>> How would this affect my clock? It says to try another
>> clock source, what type of clock source would it be suggesting I
>> use? Another chip already in the computer?
Yes.
>> It is an Intel 440BX
>> chipset; on an Dell motherboard. Would that be likely to have
>> another chip source that is compensating?
>>
You can change the clock source using "clock=" kernel parameter. Please
refer to Documentation/kernel-parameters.txt file of kernel source.
>> I don't notice a significant clock slowdown, but I'm running NTP,
>> so that could be masking the problem.
>>
>
> Unless you're running performance critical programs that utilize
> gettimeofday/clock_gettime, you probably won't notice anything. Time
> should still function properly. If you are having performance issues,
> you can try using a different clocksource (the TSC is probably safe, but
> not necessarily).
>
> 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/
>
>
Thanks
Srinivasa DS
Srinivasa Ds wrote:
> You can change the clock source using "clock=" kernel parameter.
> Please refer to Documentation/kernel-parameters.txt file of kernel
> source.
---
Uh, yeah...you mean the "clock=" parameter that is
"deprecated" ? :-)
*cough*
*sigh*
thanks,
Linda
On Thu, Nov 30, 2006 at 11:39:36AM -0800, Linda Walsh wrote:
> Srinivasa Ds wrote:
> >You can change the clock source using "clock=" kernel parameter.
> >Please refer to Documentation/kernel-parameters.txt file of kernel
> >source.
> ---
> Uh, yeah...you mean the "clock=" parameter that is
> "deprecated" ? :-)
>
> *cough*
> *sigh*
"clocksource=" is the replacement.
Dominik