In message
The Saturday 2007-12-08 at 18:39 +0100, Anders Johansson wrote:
On Saturday 08 December 2007 17:29:41 Carlos E. R. wrote:
Because of this:
<4>Marking TSC unstable due to: possible TSC halt in C2.
What is C2?
A power state. It consumes less power than the full throttle mode
Ah, ok.
Then it shouldn't be a problem. Previously (for years), the kernel said my cpu has no throtling capability. Now it is different:
<6>ACPI: CPU0 (power states: C1[C1] C2[C2]) <6>ACPI: Processor [CPU0] (supports 2 throttling states)
and current state is C2:
nimrodel:~ # cat /proc/acpi/processor/CPU0/power active state: C2 max_cstate: C8 bus master activity: 4009d011 maximum allowed latency: 6666 usec states: C1: type[C1] promotion[C2] demotion[--] latency[000] usage[00356800] duration[00000000000000000000] *C2: type[C2] promotion[--] demotion[C1] latency[090] usage[01088180] duration[00000000033109569598]
No, now is C1:
nimrodel:~ # cat /proc/acpi/processor/CPU0/power active state: C1 max_cstate: C8 bus master activity: 00000000 maximum allowed latency: 6666 usec states: *C1: type[C1] promotion[C2] demotion[--] latency[000] usage[00358448] duration[00000000000000000000] C2: type[C2] promotion[--] demotion[C1] latency[090] usage[01102595] duration[00000000033614061041]
Anyway, it uses both states and clock seem to be running good - for the time being, at least.
I don't think it is directly related to your problem, but as an example where the Linux system clock is not good enough for ntp I have a machine runing SuSE 9.3 which gains 0.28 seconds every hour on system time (nothing to do with CMOS clock!!). "ntpd" just refuses to synchronise this machine, and from the docs I gather this is expected behaviour if system time is too far out. I assumed this might be a hardware problem, perhaps an unstable or incorrect CPU clock signal. -- Roger Hayter -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org