Re: [bisected] Clocksource tsc unstable git

[Markus Trippelsdorf <markus@trippelsdorf.de>]

On 2010.11.09 at 15:39 +0100, Borislav Petkov wrote:
> On Tue, Nov 09, 2010 at 09:02:13AM -0500, Thomas Gleixner wrote:
> > > actually your board is not what concerns me, 20 ticks is still ok, more
> > > or less, but there are other machines which contain absurd values in
> > > there like 0x37ee or 0x1000 (a Broadcom chipset). We'll need to give a
> > > change like that a good run before we can be absolutely sure it doesn't
> > > break any machines.
> > 
> > If the ACPI entry is known to be flaky, shouldn't we simply err out on
> > the safe side and use 128 ticks in any case, which is not a really big
> > deal.
> 
> Yep, this is what my proposed fix does. I set it by default to 0x80 and
> the hpet detection code in acpi_parse_hpet() overrides it if it is less
> than that (and obviously a sensible value written by the BIOS).
> 
> Otherwise it issues a warning. Come to think of it, we shouldn't be
> issuing a warning because this'll scream on a very high number of
> systems, IMHO, especially older boards. Instead, we should issue it in
> dmesg during boot just in case.
> 
> The other concern I have is whether min tick of 128 would work for _all_
> possible HPET implementations - I don't know whether there are some very
> b0rked incarnations which delay HPET accesses to more than 128 cycles.
> Kinda hard to say.
> 
> So, to be more specific, here's what I have in mind:

Any update on this issue?

Borislav's patch solves the mysterious "slowdown" problem and is running
without problems for the last two weeks here. 

(And rc2 is already out. So maybe it's time to push this to Linus so
that more people have a chance to test it?)
-- 
Markus