LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: john stultz <johnstul@us.ibm.com>
To: Andi Kleen <ak@suse.de>
Cc: Ian Campbell <ijc@hellion.org.uk>, linux-kernel@vger.kernel.org
Subject: Re: PMTMR running too fast
Date: Wed, 06 Dec 2006 11:28:48 -0800	[thread overview]
Message-ID: <1165433328.6729.18.camel@localhost.localdomain> (raw)
In-Reply-To: <200612061744.47249.ak@suse.de>

On Wed, 2006-12-06 at 17:44 +0100, Andi Kleen wrote:
> >
> > > Is there a specific reason the check was removed (I couldn't see on in
> > > the archives) or was it simply overlooked? Without it I need to pass
> > > clocksource=tsc to have 2.6.18 work correctly on an older K6 system with
> > > an Aladdin chipset (will dig out the precise details if required). Would
> > > a patch to reintroduce the check be acceptable or would some sort of
> > > blacklist based solution be more acceptable?
> >
> > If I recall correctly, it was pulled because there was some question as
> > to if it was actually needed (x86_64 didn't need it) and it slows down
> > the boot time (although not by much).
> >
> > I'm fine just re-adding it. Although if the number of affected systems
> > are small we could just blacklist it (Ian, mind sending dmidecode
> > output?).
> >
> > Andi, your thoughts?
> 
> Doing a check at boot time is fine for me. Just I don't want the
> "read pmtmr three times at runtime" code anywhere near x86-64

:) This change fully disqualifies the ACPI PM if its running at the
wrong frequency, so no worries there.

> I don't think the boot time check needs DMI guarding

DMI guarding? I'm not following...

> But BTW the check is not necessarily enough -- there is at least one
> NF3 machine around where the PIT timer ticks at a wrong frequency.
> Safer would be probably to calibrate against RTC which is afaik used
> by Windows too (so it's likely to be ok)

Hmm.. I might lean towards pushing the patch closer to as it is, as
we're just restoring functionality that was there before in 2.6.17.  The
NF3 system already needs bits to correct for the PIT frequency, so it
seems that code could also correct the mach_countup() routines.

Even so, I do agree with you that moving to utilize more "widely tested"
hardware for calibration would be a good thing.

thanks
-john



  reply	other threads:[~2006-12-06 19:29 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-12-03 13:50 Ian Campbell
2006-12-04 19:19 ` john stultz
2006-12-04 19:40   ` Ian Campbell
2006-12-04 20:14     ` john stultz
2006-12-05  7:41       ` Ian Campbell
2006-12-05 19:34         ` john stultz
2006-12-06  8:14           ` Ian Campbell
2006-12-06 19:46           ` Ian Campbell
2006-12-06 16:44   ` Andi Kleen
2006-12-06 19:28     ` john stultz [this message]
2006-12-06 20:14       ` Andi Kleen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1165433328.6729.18.camel@localhost.localdomain \
    --to=johnstul@us.ibm.com \
    --cc=ak@suse.de \
    --cc=ijc@hellion.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    --subject='Re: PMTMR running too fast' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).