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

From: Andrew Morton
Date: Mon Aug 18 2008 - 15:52:45 EST


On Mon, 18 Aug 2008 21:35:17 +0200
Dominik Brodowski <linux@xxxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxx>
> > : 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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/