After upgrading the kernel from 2.6.28 to 2.6.34 I noticed that lm_sensors was no longer reporting many things like fan speeds and voltages and some temperatures. After doing some research I found that since I was running an ASUS motherboard that I needed to use the ASUS ATK0110 module. After reconfiguring my kernel to include this module lm_sensors worked as expected but ntp was no longer able to sync the clock on my system and the clock would drift like it was free running. After backing out the ASUS ATK0110 module ntp starting working again. I use the new PPS support in the kernel with an Oncore UT+ reference clock. I don't know if this issue is specific to using ntp with a local reference clock or if it would also affect ntp using remote time servers. Also I have been unable to get lm_sensors to function correctly without ASUS ATK0110 loaded even with acpi_enforce_resources=no or acpi_enforce_resources=lax. Is there a work around that will allow both good time keeping and a working lm_sensors?
In case it matters my motherboard is an A8N32-SLI.
I did some testing with 2.6.36. I found the following: 1. The problem is still present. 2. The issue is not apparent when using network based time servers only. 3. When I use only the locally installed reference clock (Motorola OnCore UT+) the clock will sync perhaps 10% of the time. 4. When the clock fails to sync running ntpq -p will show that the clock is off by about 30000 to 37000 milli-seconds (more than 1/2 minute). 5. If I shut down ntp and then run ntpdate to cause the clock to jump the time to be close to correct and then restart ntp it will again report that the time is off by more than 1/2 minute most of the time. If I do this repeatedly the clock will occasionally sync. # /etc/init.d/ntpd stop * Stopping ntpd ... [ ok ] # ntpdate gps.layer42.net 15 Nov 13:57:32 ntpdate[6986]: step time server 69.36.224.15 offset -36.999505 sec # ntpdate gps.layer42.net 15 Nov 13:57:43 ntpdate[7036]: adjust time server 69.36.224.15 offset -0.002329 sec # /etc/init.d/ntpd start * Starting ntpd ... [ ok ] Office heng # ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================== xGPS_ONCORE(0) .GPS. 0 l 7 16 377 0.000 -33999. 0.034 clock.sjc.he.ne .CDMA. 1 u 68 64 3 103.085 -34042. 35.379 gps.layer42.net .GPS. 1 u 1 64 7 17.558 -33997. 64.973 # /etc/init.d/ntpd stop * Stopping ntpd ... [ ok ] Office heng # ntpdate clock.sjc.he.net 15 Nov 14:04:36 ntpdate[11753]: step time server 216.218.254.202 offset -34.013495 sec Office heng # ntpdate clock.sjc.he.net 15 Nov 14:04:47 ntpdate[11758]: adjust time server 216.218.254.202 offset 0.001764 sec Office heng # /etc/init.d/ntpd start * Starting ntpd ... # ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================== oGPS_ONCORE(0) .GPS. 0 l 13 16 377 0.000 -0.021 0.002 *clock.sjc.he.ne .CDMA. 1 u 17 64 377 12.671 1.151 0.397 +gps.layer42.net .GPS. 1 u 12 64 377 15.710 0.509 23.509 # ntptime ntp_gettime() returns code 0 (OK) time d08c32fc.4d211430 Mon, Nov 15 2010 14:30:20.301, (.301286598), maximum error 3254 us, estimated error 36 us ntp_adjtime() returns code 0 (OK) modes 0x0 (), offset -18.569 us, frequency -37.684 ppm, interval 1 s, maximum error 3254 us, estimated error 36 us, status 0x2001 (PLL,NANO), time constant 4, precision 0.001 us, tolerance 500 ppm, When it does sync the clock is not as stable (higher offsets) as it is when ATK0110 is not in use. 6. If I rebuild the kernel with out the ATK0110 module ntp works as it should and it syncs the clock very quickly with offsets less than a 5 microsecond within 15 minutes and it settles to offsets of under 1 microsecond after a few hours. Is there some workaround for this issue? I would really like to get both lm_sensors and ntp working correctly.
Also is there anything that you need from me to help resolve this issue. If so please add that info here and I will get that information back here ASAP.