[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.1.10.0809020117260.3243@apollo.tec.linutronix.de>
Date: Tue, 2 Sep 2008 01:24:45 +0200 (CEST)
From: Thomas Gleixner <tglx@...utronix.de>
To: Linus Torvalds <torvalds@...ux-foundation.org>
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 Mon, 1 Sep 2008, Linus Torvalds wrote:
> On Tue, 2 Sep 2008, Thomas Gleixner wrote:
> > >
> > > Umm. Which one. The 32-bit or the 64-bit?
> >
> > The 32 bit version.
>
> So then the PIT isn't going to work on that machine. Do you have HPET?
>
> Because if so, the most obvious choice would be to say:
>
> - on old machines, the PIT is likely more reliable than PM_TIMER
>
> - on new machines, the HPET is likely more reliable than PIT
>
> and there's actually a fairly obvious place to distinguish between old and
> new: if ti has a HPET, consider it a new one.
>
> But that just means that there's never any reason to use PM_TIMER anyway,
> and the proper patch would probably be to just ignore it. No?
There is a HPET timer on that machine, but it is only available by
enforcing the address via black magic because the BIOS does advertise
it on the wrong location and the newest BIOS version does not
advertise it at all.
I have not seen a single bug report against PM timer aside of those K6
area systems, but we have
- HPETs which are not advertised at all
- HPETs which are advertised at the wrong address
- HPETs which do not count at all
- HPETs which tell us bogus operating frequencies
- HPETs which have bogus interrupt routings
So why should we rely on the HPET ?
The whole ACPI code relies pretty much on PM_TIMER and as I said
before there are no PM-TIMER related bug reports aside of those
documented K6 ones, which Alok did probably not know about and I
forgot them as well. Yeah, that's my fault.
Thanks,
tglx
--
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