Date:	Sun, 10 Aug 2008 21:08:02 +0200
From:	Andreas Mohr <andi@...as.de>
To:	Dominik Brodowski <linux@...inikbrodowski.net>,
	Andreas Mohr <andi@...as.de>,
	LKML <linux-kernel@...r.kernel.org>,
	john stultz <johnstul@...ibm.com>,
	OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	linux-acpi@...r.kernel.org, Arjan van de Ven <arjan@...radead.org>
Subject: Re: ACPI PM-Timer on K6-3 SiS5591: Houston...

On Sun, Aug 10, 2008 at 06:29:20PM +0200, Dominik Brodowski wrote:
> Hi Andreas,
> 
> On Sun, Aug 10, 2008 at 12:17:30PM +0200, Andreas Mohr wrote:
> > Result: catastrophic timer behaviour (a large backwards skip is possible),
> > even in case we do a triple-read workaround, due to a floating bit at
> > 0x0400 (possibly caused by underclocking from 400 to 150, but whatever...).
> 
> this isn't the bug which is handled by the read-three-times-workaround.
> Instead, that handels the following PIIX4 errata:

OK, right, technically this workaround is not related to this
different bug.
And it's in fact not this triple-read which has any weakness here but rather
the init check.

> > And my system does pass the bootup PM-Timer check quite often despite
> > this severe defect (2 in 4 bootups _did_ register my defective
> > acpi_pm clocksource).
> 
> No surprise there -- it is the first time I see such an error; and it might
> actually be a bug specific to your computer's motherboard. 

Yeah, might be motherboard only, but likely still chipset-global,
since probably not too many people tried this beast with ACPI / acpi_pm even
(we're not even talking about the usual Linux ACPI 2001 blacklist limit
with this board, more like 1999, 1998 or even 1997 stoneage).

OK, dmidecode said:
        Vendor: Award Software International, Inc.
        Version: 4.51 PG
        Release Date: 07/05/99

Might be a generic Award date value in this case, but still quite stoneage.


> > I realized that in historic versions (e.g. 2.6.12) read_pmtmr()
> > encompassed the _entire_ "triple-reading due to latch bug" logic.
> > Nowadays read_pmtmr() is the raw inline version of a single inl() only!
> > However despite this large change, the initial hardware check
> > (at init_acpi_pm_clocksource()) _kept using_ the now single-read read_pmtmr()
> > as if nothing had happened.
> 
> See patch below. Is there a proper format modifier for cycle_t ?

_DAMN_ you're fast! ;)

Technically it's related to the base type of cycle_t (i.e., u64 and thus
probably "unsigned long long"), thus %llx is the format specifier
that I'd have chosen as well.

> Well, we could do something like this for sure, but I haven't seen any other
> such bug report before...

I guess I'm treading on new land here...

> > - "known good workaround" systems should provide workaround from the beginning
> => see patch below.
> > - initial timer check should then do at least 10 increment checks with
> >   10 of 10 successful
> => might do this, but currently I'm not yet convinced whether we really need
> it.

Even if it's not a systematic chipset / layout error, then I'm sure there's always
the occasional custom-broken (read: damaged) system which would need a
useful check to avoid counter-related lockups.

IMHO the current init check is too weak, it will catch the very simplest
types of problems only, and that's not a good thing.

About Arjan's suggestion to use DMI blacklisting here: not the right
method here IMHO since one could easily catch such problems generically
and thus much more reliably than maintaining an ever-growing and thus
always-incomplete blacklist collection.
Anyway, he provided important input still ;)

Andreas Mohr
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists