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] [day] [month] [year] [list]
Date:	Thu, 30 Apr 2009 16:17:23 -0700
From:	David Rees <drees76@...il.com>
To:	Michael Tokarev <mjt@....msk.ru>
Cc:	Mika Tiainen <mikat@....fi>,
	Andreas Herrmann <andreas.herrmann3@....com>,
	linux-kernel@...r.kernel.org
Subject: Re: Slow clock on AMD 740G chipset

On Fri, Apr 24, 2009 at 6:45 PM, David Rees <drees76@...il.com> wrote:
> On Tue, Mar 24, 2009 at 10:34 AM, Michael Tokarev <mjt@....msk.ru> wrote:
>> To refresh what has been said.  Several people observed slow clock
>> on their - mostly AMD 780g, 740g and 690g-based systems with 2.6.28
>> 2.6.27 kernels.  Slow to a point when ntpd wasn't successful to
>> keep up with the drift.  It has been said that the motherboards are
>> flaky or something and that the clocks has to be calibrated, for
>> which there are known procedures available (adjtimex).  Which helped.
>> Before the "calibration" the clock were off by ~15 minutes per day.
>
> This is really weird.  I earlier posted to the thread saying things
> were fine on a Fedora 10 2.6.27.9-159.fc10.x86_64 kernel.
>
> Then mysteriously after a machine reboot to install new hardware[1] on
> March 27th on kernel 2.6.27.19-170.2.35.fc10.x86_64 (previous running
> kernel was the same), the clock started running slow to the tune of
> ntpd resetting the time every 15-18 minutes forward about 2.3 seconds.
>
> Fast forward to today (now running 2.6.29.1-30.fc10.x86_64) and the
> clock is still running slow.
>
> I don't know - my system (GA-MA74GM-S2 mobo) is still broken.
>
> [1] So the hardware I installed was a SATA SSD (OCZ Vertex). Ever
> since then, the clock has been running fast.  Previously, the only
> thing on the SATA bus was a DVD drive - it has two IDE drives, one
> plugged in on board and the other into a Promise IDE card.
>
> When doing so, the sata ports are now running in AHCI mode instead of
> native mode.  I'll have to try switching later.

Another update.  Two nights ago I set the SATA ports in IDE mode to
try to flash the OCZ Vertex to the latest firmware 1370, previously
running 1275 (The flash failed as the flashing utility could not
detect the drives in the system).  Clock still ran slow.  Last night,
I succeeded in flashing the drive after putting it in another system.

Since then, the clock has been keeping time very well - at least it's
not losing 2-3 seconds every 15 minutes.

So is it possible for a SATA drive to somehow affect the speed of the clock?

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ