public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* Re: athlon 64 dual core tsc out of sync
@ 2006-02-04 20:24 Albert Cahalan
  2006-02-05  1:00 ` Lee Revell
  2006-02-05  5:06 ` Alistair John Strachan
  0 siblings, 2 replies; 15+ messages in thread
From: Albert Cahalan @ 2006-02-04 20:24 UTC (permalink / raw)
  To: linux-kernel, s0348365, rlrevell, safemode

Alistair John Strachan writes:
> On Saturday 04 February 2006 19:03, Lee Revell wrote:
>> On Fri, 2006-02-03 at 21:10 -0500, Ed Sweetman wrote:

>>> I know this has been gone over before, and I am aware of
>>> the possible fix being the use of the pmtmr.
>>>
>>> My question is, if there is support builtin to the kernel for more than
>>> one timer, and we know that no timer but the pmtimer is reliable on a
>>> dual core system, why doesn't the startup of the kernel choose the
>>> pmtimer based on if it detects the system is a dual core proc with smp
>>> enabled?   And if the pmtimer doesn't fix this sync issue, is there a
>>> fix out there?   Currently with 2.6.16-rc1-mm5 the non-customized boot
>>> args to the kernel results in these messages.
>>
>> Excellent question.  What's the status of this bug?  It's a
>> showstopper for a ton of people on the JACK list...
>
> As Andi has recounted many times already, pmtmr is now the
> default on x86-64 if it's built in. I'm sure you can confirm
> this from the sources.

That's unhelpful unless you are suggesting that Linux no
longer supports running the 32-bit kernel on 64-bit hardware.
If that is the case, it ought to detect the incompatibility
and refuse to boot.

My clock was going about 1.414 times as fast as it ought to.
Why that looks like the square root of two I don't know.

There have been far too many other problems with i386 timekeeping as well.
Really, it's crazy to not use the pmtmr if the pmtmr is available. The next
best choice would be HPET. After that, pre-SMM systems should count clock
ticks and post-SMM systems should read the RTC or PIT registers. Until we
accept this, we'll always be suffering clock problems.

^ permalink raw reply	[flat|nested] 15+ messages in thread
* athlon 64 dual core tsc out of sync
@ 2006-02-04  2:10 Ed Sweetman
  2006-02-04 19:03 ` Lee Revell
                   ` (2 more replies)
  0 siblings, 3 replies; 15+ messages in thread
From: Ed Sweetman @ 2006-02-04  2:10 UTC (permalink / raw)
  To: linux-kernel

I know this has been gone over before, and I am aware of the possible 
fix being the use of the pmtmr.

My question is, if there is support builtin to the kernel for more than 
one timer, and we know that no timer but the pmtimer is reliable on a 
dual core system, why doesn't the startup of the kernel choose the 
pmtimer based on if it detects the system is a dual core proc with smp 
enabled?   And if the pmtimer doesn't fix this sync issue, is there a 
fix out there?   Currently with 2.6.16-rc1-mm5 the non-customized boot 
args to the kernel results in these messages.

Losing some ticks... checking if CPU frequency changed.
warning: many lost ticks.
Your time source seems to be instable or some driver is hogging interupts
rip default_idle+0x2d/0x60


cpufreq is enabled of course.  

^ permalink raw reply	[flat|nested] 15+ messages in thread

end of thread, other threads:[~2006-02-05 23:12 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-02-04 20:24 athlon 64 dual core tsc out of sync Albert Cahalan
2006-02-05  1:00 ` Lee Revell
2006-02-05  1:45   ` Albert Cahalan
2006-02-05  2:08     ` Lee Revell
2006-02-05  3:02       ` Ed Sweetman
2006-02-05  5:08         ` Alistair John Strachan
2006-02-05  2:24     ` Lee Revell
2006-02-05  5:06 ` Alistair John Strachan
  -- strict thread matches above, loose matches on Subject: below --
2006-02-04  2:10 Ed Sweetman
2006-02-04 19:03 ` Lee Revell
2006-02-04 19:52   ` Alistair John Strachan
2006-02-04 21:55     ` Ed Sweetman
2006-02-04 19:16 ` Lee Revell
2006-02-05 16:32 ` Andi Kleen
2006-02-06  1:12   ` Ed Sweetman

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox