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:	Tue, 10 Mar 2009 11:18:07 +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, 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

Hi, 

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.

> tsc is even slower, seems to be about
> half speed to realtime.

This is due to TSC not being P- or C- state invariant.  I.e. TSC
frequency changes when processor P-state (frequency) or C-state
(e.g. C2, C3 or C1E) changes. On AMD K8 TSC is not a reliable
clocksource. (This has changed with AMD family 10h CPUs).

> When i set current_clocksource to jiffies the
> clock stopped completely and I had to reboot.

That's odd. I tried it on a test machine - it didn't hang but time
doesn't change anymore and I can't even modify the clocksource
afterwards.

So obviously there is a kernel bug when jiffies are used for
clocksource.


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/