From: Waiman Long <waiman.long@hpe.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: "Theodore Ts'o" <tytso@mit.edu>, Arnd Bergmann <arnd@arndb.de>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Scott J Norton <scott.norton@hpe.com>,
Douglas Hatch <doug.hatch@hpe.com>
Subject: Re: [PATCH] random: Fix kernel panic due to system_wq use before init
Date: Wed, 14 Sep 2016 18:15:41 -0400 [thread overview]
Message-ID: <57D9CC0D.7010608@hpe.com> (raw)
In-Reply-To: <CA+55aFyd+Yqz0uhtKCOD2k3JfSA3kGzrAw3+Nc1DQMXOdax=AQ@mail.gmail.com>
On 09/14/2016 05:06 PM, Linus Torvalds wrote:
> On Wed, Sep 14, 2016 at 12:34 PM, Waiman Long<waiman.long@hpe.com> wrote:
>> I can try, but the 16-socket system that I have at the moment takes a long
>> time (more than an hour) for one shutdown-reboot cycle. It may not be really
>> more interrupts in 4.8, it may be that the random driver just somehow run
>> very slow on my test machine as it seems to have a major rewrite in the 4.8
>> cycle.
> Looking at the random driver updates since 4.7, the only thing I see
> is that .crng_fast_load() for the chacha20 randomness. And that should
> trigger only until it's been initialized, so the cost looks like it
> should be limited.
>
> Is there some fundamental reason you think it's the random driver?
> Other than the oops? Because I'd be more inclined to suspect just some
> apic issue or something, where an actual interrupt line ends up
> screaming or whatever. Is this UV? There's also the CPU hotplug state
> machine changes etc.
Yes, it is because of the oops that I suspect the random driver may be
the cause.
> But a few rounds of bisecting should hopefully cut down on the
> suspects a lot. A *full* bisect might be 16-17 rounds, but if you can
> do just four or five rounds of bisection, that should still cut it
> down from 14k commits to "only" several hundred..
>
> Linus
Yes, I will do a few rounds to see if we can isolate the problem. In the
mean time, I will also reconfigure the system with less sockets to see
if it is reproduced in a smaller configuration.
Cheers,
Longman
next prev parent reply other threads:[~2016-09-14 22:15 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-14 19:03 [PATCH] random: Fix kernel panic due to system_wq use before init Waiman Long
2016-09-14 19:14 ` Linus Torvalds
2016-09-14 19:24 ` Waiman Long
2016-09-14 19:55 ` Tejun Heo
2016-09-14 22:26 ` Tejun Heo
2016-09-14 19:14 ` Waiman Long
2016-09-14 19:19 ` Linus Torvalds
2016-09-14 19:34 ` Waiman Long
2016-09-14 21:06 ` Linus Torvalds
2016-09-14 22:15 ` Waiman Long [this message]
2016-09-19 3:09 ` Waiman Long
2016-09-19 9:25 ` Matt Fleming
2016-09-19 12:43 ` Matt Fleming
2016-09-19 14:48 ` Waiman Long
2016-09-19 14:51 ` Matt Fleming
2016-09-19 17:09 ` Waiman Long
2016-09-20 14:04 ` Matt Fleming
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=57D9CC0D.7010608@hpe.com \
--to=waiman.long@hpe.com \
--cc=arnd@arndb.de \
--cc=doug.hatch@hpe.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=scott.norton@hpe.com \
--cc=torvalds@linux-foundation.org \
--cc=tytso@mit.edu \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.