From: Thomas Gleixner <tglx@linutronix.de>
To: Robin Holt <holt@sgi.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>,
linux-kernel@vger.kernel.org, Ingo Molnar <mingo@kernel.org>
Subject: Re: Full dynticks needs evtdesc set before marking cpu online.
Date: Mon, 13 May 2013 16:04:45 +0200 (CEST) [thread overview]
Message-ID: <alpine.LFD.2.02.1305131602090.2863@ionos> (raw)
In-Reply-To: <20130513135948.GF3658@sgi.com>
On Mon, 13 May 2013, Robin Holt wrote:
> On Mon, May 13, 2013 at 03:03:55PM +0200, Thomas Gleixner wrote:
> > On Mon, 13 May 2013, Robin Holt wrote:
> >
> > > On Mon, May 13, 2013 at 11:21:00AM +0200, Thomas Gleixner wrote:
> > > > On Wed, 8 May 2013, Robin Holt wrote:
> > > >
> > > > > Thomas,
> > > > >
> > > > > We are seeing failures booting medium sized machines which I think is
> > > > > a change in expectations that dyntick put on x86's start_secondary.
> > > > >
> > > > > During boot of cpus, we see an occassional panic in tick_do_broadcast at
> > > >
> > > > http://lkml.indiana.edu/hypermail/linux/kernel/1305.0/01818.html
> > > >
> > > > Will hit Linus tree soon.
> > >
> > > I think this is really due to a sequence in start_secondary. The cpu
> > > has been marked as online, but its evtdesc has not been initialized.
> > > I sent a followup to this with a hack/patch.
> >
> > No, the real issue is that I messed up the cpumask conversion in the
> > broadcast code, i.e. using alloc instead of zalloc, which allocated
> > nonzeroed memory for the cpumasks, so any random bit set will crash
> > the machine. Your patch is just papering over the issue.
>
> I believe I understand now. What would be the downside of moving
> the initialization to before marking the cpu online? It seems like a
> reasonable this to expect as well in spite of it not being the right
> fix to the other bug.
Yes, we can move it, but its not a required thing that the tick device
is setup befor onlining.
Thanks,
tglx
next prev parent reply other threads:[~2013-05-13 14:04 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-08 23:57 Robin Holt
2013-05-12 20:16 ` Frederic Weisbecker
2013-05-13 9:21 ` Thomas Gleixner
2013-05-13 12:55 ` Robin Holt
2013-05-13 13:03 ` Thomas Gleixner
2013-05-13 13:59 ` Robin Holt
2013-05-13 14:04 ` Thomas Gleixner [this message]
2013-05-13 14:31 ` Robin Holt
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.LFD.2.02.1305131602090.2863@ionos \
--to=tglx@linutronix.de \
--cc=fweisbec@gmail.com \
--cc=holt@sgi.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
/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
Powered by JetHome