linux-kernel - Re: Slow clock on AMD 740G chipset

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20090311100525.GE20716@alberich.amd.com>
Date:	Wed, 11 Mar 2009 11:05:25 +0100
From:	Andreas Herrmann <andreas.herrmann3@....com>
To:	Mika Tiainen <mikat@....fi>
CC:	linux-kernel@...r.kernel.org
Subject: Re: Slow clock on AMD 740G chipset

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/