Date: Wed, 11 Mar 2009 11:05:25 +0100
From: Andreas Herrmann <andreas.herrmann3@amd.com>
To: Mika Tiainen <mikat@iki.fi>
CC: linux-kernel@vger.kernel.org
Subject: Re: Slow clock on AMD 740G chipset
Message-ID: <20090311100525.GE20716@alberich.amd.com>
References: <874ozu2hcl.fsf@divinity.mikat.iki.fi> <20090310101807.GD20716@alberich.amd.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
In-Reply-To: <20090310101807.GD20716@alberich.amd.com>
User-Agent: Mutt/1.5.16 (2007-06-09)
Content-Transfer-Encoding: 8BIT
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2560
Lines: 63

On Tue, Mar 10, 2009 at 11:18:07AM +0100, Andreas Herrmann wrote:
> On Tue, Jan 20, 2009 at 04:16:10PM +0200, Mika Tiainen wrote:
> > 
> > Hi,
> > 
> > I built a new machine with Gigabyte GA-MA74GM-S2H motherboard that ntpd
> > can't keep synced. Could this be a kernel bug or is it a hardware
> > problem?
> > 
> > Installed with Debian 2.6.27 kernel and currently running a self built
> > 2.6.28.1, both have the problem. It's falling behind over 2s/15min:
> > 
> > Jan 19 22:08:23 aeon ntpd[31468]: time reset +2.226349 s
> > Jan 19 22:24:11 aeon ntpd[31468]: time reset +2.185085 s
> > Jan 19 22:40:08 aeon ntpd[31468]: time reset +2.308958 s
> > Jan 19 22:56:23 aeon ntpd[31468]: time reset +2.253836 s
> > Jan 19 23:13:03 aeon ntpd[31468]: time reset +2.291917 s
> > Jan 19 23:28:14 aeon ntpd[31468]: time reset +2.091014 s
> > Jan 19 23:43:47 aeon ntpd[31468]: time reset +2.209660 s
> > Jan 19 23:59:09 aeon ntpd[31468]: time reset +2.150145 s
> > Jan 20 00:15:44 aeon ntpd[31468]: time reset +2.256261 s
> > Jan 20 00:31:47 aeon ntpd[31468]: time reset +2.253873 s
> > 
> > I have tried different clocksources. The machine defaults to hpet,
> > acpi_pm makes no difference and

> That's annoying but I can't really help you with this. Maybe using
> adjtimex as described in section 9.1.6 in
> http://support.ntp.org/bin/view/Support/KnownHardwareIssues is an
> option for you.

BTW, I've played little bit with the adjtimex tool. Verifying the
tick value (with adjtimex --tick) is most probable the solution
for your. Manual calibration is described here
http://support.ntp.org/bin/view/Support/ManualCalibration

Adapting the tick value I managed that time on my test system fell
behind ntp-time by 20 seconds within some minutes. And the other way
round it worked, too.

So it's "mere a question" of calibration on your system. AFAIK
you have to increase the tick value to not fall behind ntp-time, e.g.
increasing tick value from 10000 to 10025

# adjtimex --tick 10025


Regards,
Andreas

-- 
Operating | Advanced Micro Devices GmbH
  System  | Karl-Hammerschmidt-Str. 34, 85609 Dornach b. M?nchen, Germany
 Research | Gesch?ftsf?hrer: Jochen Polster, Thomas M. McCoy, Giuliano Meroni
  Center  | Sitz: Dornach, Gemeinde Aschheim, Landkreis M?nchen
  (OSRC)  | Registergericht M?nchen, HRB Nr. 43632


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/