Re: [git pull?] clocksource: ACPI pmtmr bugfixes [Was: Re: ACPI PM-Timer on K6-3 SiS5591: Houston...]

[Andrew Morton <akpm@linux-foundation.org>]

On Mon, 18 Aug 2008 21:35:17 +0200
Dominik Brodowski <linux@dominikbrodowski.net> wrote:

> Hi Andrew,
> 
> On Mon, Aug 18, 2008 at 12:19:24PM -0700, Andrew Morton wrote:
> > >   git://git.kernel.org/pub/scm/linux/kernel/git/brodo/pcmcia-2.6.git clocksource
> > > 
> > > Dominik Brodowski (2):
> > >       acpi_pm.c: use proper read function also in errata mode.
> > >       acpi_pm.c: check for monotonicity
> > > 
> > >  drivers/clocksource/acpi_pm.c |   50 +++++++++++++++++++++++-----------------
> > >  1 files changed, 29 insertions(+), 21 deletions(-)
> > 
> > A bare git URL is somewhat user-unfriendly.
> 
> uh, sorry about that.
> 
> > : commit b985f0517e31c1204b5aafb94f86202948f00e16
> > : Author: Dominik Brodowski <linux@dominikbrodowski.net>
> > : Date:   Sun Aug 10 21:24:21 2008 +0200
> > : 
> > :     acpi_pm.c: use proper read function also in errata mode.
> > :     
> > :     When acpi_pm is used in errata mode (three reads instead of one), also the
> > :     acpi_pm init functions need to use three reads instead of just one.
> > 
> > hm, why?  Was there some observeable problem which this change improved?
> 
> Indeed: on all affected hardware (some Intel ICH4, PIIX4 and PIIX4E chipsets)
> there's about a 4.2% chance that initialization of the ACPI PMTMR fails. On
> those chipsets, we need to read out the timer value at least three times to
> get a correct result, for every once in a while (i.e. within a 3 ns window
> every 69.8 ns) the read returns a bogus result. During normal operation we
> work around this issue, but during initialization reading a bogus value may
> lead to -EINVAL even though the hardware is usable.

That would be useful stuff for the changelog.

> > :     acpi_pm.c: check for monotonicity
> > :     
> > :     Expand the check for monotonicity by doing ten tests instead of one.
> > 
> > Why?
> 
> Indeed: http://lkml.org/lkml/2008/8/10/77 -- quote:
> "Result: catastrophic timer behaviour (a large backwards skip is possible),"
> 
> The current check for monotonicity is way too weak. And at least on one
> system out there PMTMR is unuseable, but the current check fails.

yeah, that does look like 2.6.27 material.  And possibly 2.6.26.x and
2.6.25.x?

> > I guess this file falls under Thomas's git-hrt tree.  I can queue the
> > patches up and spam Thomas with them, but I'm at a bit of a loss
> > regarding their priority due to the above questions.
> 
> That would be great, thanks.

Could I trouble you to resend them as plain-old-patches, with full
changelogs along with your thoughts about the suitablity for
2.6.2[5678].x please?

I could attempt to put all that together here, but I'd probably end up
with something inappropriate.

Thanks.