[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.1.10.0809021652160.5436@nehalem.linux-foundation.org>
Date: Tue, 2 Sep 2008 18:49:58 -0700 (PDT)
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Thomas Gleixner <tglx@...utronix.de>
cc: Larry Finger <Larry.Finger@...inger.net>,
LKML <linux-kernel@...r.kernel.org>,
"Rafael J. Wysocki" <rjw@...k.pl>,
Alok Kataria <akataria@...are.com>,
Michael Buesch <mb@...sch.de>
Subject: Re: Regression in 2.6.27 caused by commit bfc0f59
On Wed, 3 Sep 2008, Thomas Gleixner wrote:
>
> Except for the couple of exceptions, where the readout of the old PIT
> timer is broken. See arch/x86/kernel/i8253.c:pit_read()
Well, the VIA problem, for example, is not an issue if you just make it do
the maximum timeout (ie count down from zero), which is what you want
_anyway_ in order to get the maximum range.
So that one is simply avoided by just programming the timer to count the
maximum possible range.
However, the counter latching itself does seem to stop the counting until
it is read, which is rather irritating. It means that you can't just latch
and read in a tight loop. An while I actually have a patch that works very
well for me, it depends on not latching, which is not strictly correct
either.
So yeah, I suspect using the current code and trying to just see when it
isn't reliable (and the "max time" seems good for that) is probably the
best option.
Linus
--
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