Date:	Thu, 4 Dec 2014 02:02:58 +0100 (CET)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
cc:	Dave Jones <davej@...hat.com>, Chris Mason <clm@...com>,
	Mike Galbraith <umgwanakikbuti@...il.com>,
	Ingo Molnar <mingo@...nel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Dâniel Fraga <fragabr@...il.com>,
	Sasha Levin <sasha.levin@...cle.com>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	John Stultz <john.stultz@...aro.org>
Subject: Re: frequent lockups in 3.18rc4

On Wed, 3 Dec 2014, Linus Torvalds wrote:
> On Wed, Dec 3, 2014 at 3:49 PM, Thomas Gleixner <tglx@...utronix.de> wrote:
> >
> > Bah. Would have been too simple ....
> 
> I do think you tend to trust the hpet too much.
> 
> Yes, we've had issues with people doing bad things to the tsc, but on
> the whole I really would tend to trust the internal CPU counter a
> _lot_ more than the external hpet.
> 
> So I think it's equally (if not more) likely that switching from tsc
> to hpet causes trouble, because I'd trust the tsc more than the hpet.

Given my experience I trust neither of them too much which makes it
admittedly weird to assign one as the supervisor of the other.

But yes, on newer machines the TSC tends to be halfways reliable when
you are not exposed to the never ending supply of BIOS bugs.

Though, that still does not explain the softlock watchdog issue as
that is completely independent of HPET.

But in the case that the clocksource switches to HPET it is not
completely independent because the hrtimer event programming depends
on it. But that would require the following scenario:

 hrtimer_start(timer) /* timer is first to expire timer */
     clockevents_program_event(timer->expires)
       delta = expires - ktime_get();
       evtdev->set_next_event(delta);

 So if ktime_get() returns an insane value in the past then delta can
 become large and of course nothing is going to reprogramm the clock
 event device unless there is a timer started which is earlier than
 the one which programmed the large delta.

 But ktime_get() cannot return a time which is before the last update
 of the timekeeper. It might return something in the future, but that
 would expire the timer earlier not later.

So there is something else here. If the programmed next event does not
fire _AND_ there is no earlier timer queued, then nothing which
depends on queued timers (hrtimer/timerlist) is going to be
scheduled. In the case of highres timers or nohz enabled not even the
scheduler tick on that cpu would kick in. We've seen that before and
it causes interesting failures ...

Now that machine has tsc_deadline_timer. I haven't seen bug reports
for that one yet, but it might be worthwhile to disable that for a
test.

But then that does not explain the post 3.16 issue at all.

More questions than answers, sigh.

> DaveJ, do this:
> 
> > Could you please run Ingos time-warp test on that machine for a while?
> 
> but perhaps also boot with "tsc=reliable", which _should_ get rid of
> that CLOCK_SOURCE_MUST_VERIFY, and the clocksource watchdog should do
> nothing.
> 
> Thomas? Am I misreading that?

No, that's what it is supposed to do and I actually know that it works.

Now we could also do it the other way round and boot with
"clocksource=hpet", which should show potential HPET wreckage right
away when exposed to Ingos time warp test.

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