linux-kernel - Re: AMD Quad Core clock problem?

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: <47FFD3F3.50107@redhat.com>
Date:	Fri, 11 Apr 2008 17:11:15 -0400
From:	Chris Snook <csnook@...hat.com>
To:	Marc Perkel <mperkel@...oo.com>
CC:	linux-kernel@...r.kernel.org
Subject: Re: AMD Quad Core clock problem?

Marc Perkel wrote:
> --- Chris Snook <csnook@...hat.com> wrote:
> 
>> Marc Perkel wrote:
>>> I was just wondering if there were any known
>> issues
>>> with AMD quad core phenom clock drift problems?
>> I';m
>>> running a 2.6.24 kernel and it's losing time. I
>>> remember the first dual core AMD chips had a lot
>> of
>>> clock issues.
>>>
>>> If this is something new let me know what
>> information
>>> to check and post to this list.
>> When reporting clock problems, please post dmesg. 
>> This has all the 
>> interesting timekeeping-related log messages from
>> the kernel.  Please 
>> also describe the drift quantitatively.
>>
>> -- Chris
>>
> 
> OK - thanks Chris.
> 
> The drift is small. It loses a few seconds every hour.
> And it might not be kernel related. I just remembered
> the early dual core days when this took months to get
> right. I'm running several dual core computers and the
> only one drifting is the quad. All are running the
> same OS and kernel.

With the older chips, each core had its own TSC, which caused 
synchronization problems.  The Barcelona generation chips (including 
your Phenom) have a constant frequency TSC on the northbridge, so they 
should be immune to these problems.

If it's steadily losing a few seconds every hour, it's probably just 
slightly mis-calibrated hardware.  ntp should fix this right up.  If the 
drift is more extreme than ntp can correct for, or the drift keeps 
changing, or time is jumping around, that is definitely something that 
could be a bug.

> hpet clockevent registered
> TSC calibrated against HPET
> Marking TSC unstable due to TSCs unsynchronized

It's possible that in future kernels we'll be a few clock cycles more 
accurate in calibrating this on Barcelona chips, but calibration is only 
as good as the standard of comparison.  There will always be hardware 
that's slightly off, so run ntp, or use a nightly ntpdate cronjob.  If 
your time starts drifting drastically or jumping around, please yell 
really loud.

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