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]

Date:	Wed, 11 Mar 2009 14:59:22 +0300
From:	Michael Tokarev <mjt@....msk.ru>
To:	Andreas Herrmann <andreas.herrmann3@....com>
CC:	Mika Tiainen <mikat@....fi>, linux-kernel@...r.kernel.org
Subject: Re: Slow clock on AMD 740G chipset

Andreas Herrmann wrote:
> 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

Same here, also on 740G, but on other 2 machines with 780G
it also happens.

>> 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.

And adjtimex helped me on all 3 machines.
Running it in self-calibrate mode (that 70 sec thing)
plus running ntpd was enough for me for now.

What's interesting is that some time ago it worked just fine,
and, which is even more interesting, windows on this very
hardware shows quite good time stability (WITHOUT setting
the time using [s]ntp, its ntp client is disabled).

[]
> 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

Well, sorta.  Given the amount of hardware that exposes this
behavour, AND the fact that it worked fine with previous
kernels (I think it was ok with 2.6.26), AND that windows
works just fine, it's not "calibration of your system"
question anymore.  It's now kernel bug question... ;)

BTW, the same Gigabyte GA-MA74GM-S2H mobo is here.
Other motherboards that exposes the same issue here:

   M3A78-EM (Asus, AMD780G)
   M3A-H/HDMI (Asus, AMD780G)

It never happened (so far) on M2N-SLI DELUXE (also Asus,
nVidia MCP55) and on M2N-VM DVI (nVidia MCP67).

/mjt
--
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/