Re: athlon 64 dual core tsc out of sync

[Alistair John Strachan <s0348365@sms.ed.ac.uk>]

On Saturday 04 February 2006 20:24, Albert Cahalan wrote:
> 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.

To be fair, the original poster made no indication that he wasn't running a 
64bit kernel. It's obvious from subsequent posts that he isn't.

While I agree pmtmr is sensible on the X2, unlike on x86-64, x86 supports the 
clock= option for overriding the default.

It's really only installing new distros that might be problematic (in which 
case maybe they can patch the kernel to use pmtmr?).

-- 
Cheers,
Alistair.

'No sense being pessimistic, it probably wouldn't work anyway.'
Third year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.