mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Alex Thorlton <athorlton@sgi.com>
Cc: linux-kernel@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@kernel.org>,
	John Stultz <john.stultz@linaro.org>, Russ Anderson <rja@sgi.com>,
	Dimitri Sivanich <sivanich@sgi.com>
Subject: Re: [BUG] Boot hangs at clocksource_done_booting on large configs
Date: Tue, 1 Sep 2015 22:54:27 +0200 (CEST)	[thread overview]
Message-ID: <alpine.DEB.2.11.1509012247150.15006@nanos> (raw)
In-Reply-To: <20150901173303.GE172349@asylum.americas.sgi.com>

On Tue, 1 Sep 2015, Alex Thorlton wrote:
> On Mon, Aug 31, 2015 at 11:12:12PM +0200, Thomas Gleixner wrote:
> > But they are obviously held off by something. And that something looks
> > like the timekeeper sequence lock. 
> 
> Ok.  IIRC, that lock prevents reads to the clocksource until all
> necessary write operations have finished, correct?  i.e. tk_core.seq?
> 
> I looked at that as being a possible place to get stuck in ktime_get:
> 
>         do {
>                 seq = read_seqcount_begin(&tk_core.seq);
>                 base = tk->tkr_mono.base;
>                 nsecs = timekeeping_get_ns(&tk->tkr_mono);
> 
>         } while (read_seqcount_retry(&tk_core.seq, seq));
> 
> But I don't have enough evidence to point there for sure.

Right and it might be a red herring. If the access to HPET takes long
enough for each CPU then you get into a situation where you never get
out of those timer interrupts anymore.
 
> > Your patch shifts some timing around so the issue does not happen, but
> > that's certainly not a solution.
> 
> I was fairly sure of that, but it's good to know that you agree.
> 
> I'll try and get a backtrace from a completely unmodified kernel here in
> the next few days.  Unfortunately, as mentioned, we only hit the issue
> intermittently.  I was able to reproduce pretty regularly on kernels
> from 4.0 and before, but it seems to be less common on newer kernels,
> though we definitely still manage to hit it from time to time.

Well, I doubt that backtraces will tell us much. Some moderate form of
tracing (a few tracepoints enabled) and a trace_dump(DUMP_ALL); call
before or instead of the NMI backtrace stuff might give us the really
interesting information. i.e. what the cpus have been doing for the
last second or such. The backtraces are just momentary snapshots and
not necessarily helpful.

You might have to hack the trace dump code to limit the output to a
few cpus if you don't want to wait a day or two until the information
has spilled out over serial :)

Thanks,

	tglx


      reply	other threads:[~2015-09-01 20:55 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-31 18:04 Alex Thorlton
2015-08-31 18:25 ` Alex Thorlton
2015-08-31 20:32 ` Peter Zijlstra
2015-08-31 20:55   ` Alex Thorlton
2015-08-31 21:12 ` Thomas Gleixner
2015-09-01 17:33   ` Alex Thorlton
2015-09-01 20:54     ` Thomas Gleixner [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.DEB.2.11.1509012247150.15006@nanos \
    --to=tglx@linutronix.de \
    --cc=athorlton@sgi.com \
    --cc=john.stultz@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.org \
    --cc=rja@sgi.com \
    --cc=sivanich@sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®