From: Thomas Gleixner <tglx@linutronix.de>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
"linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>,
Borislav Petkov <bp@alien8.de>, Ken Xue <Ken.Xue@amd.com>,
Marc Zyngier <marc.zyngier@arm.com>
Subject: Re: [PATCH] pinctrl/amd: Use regular interrupt instead of chained
Date: Sun, 4 Jun 2017 15:49:40 +0200 (CEST) [thread overview]
Message-ID: <alpine.DEB.2.20.1706041544540.2813@nanos> (raw)
In-Reply-To: <CACRpkdbkEnLpZtLKz+x6FLQZTdsyxKsFexFa_UQwNxgZJGDExQ@mail.gmail.com>
On Mon, 29 May 2017, Linus Walleij wrote:
> On Tue, May 23, 2017 at 11:23 PM, Thomas Gleixner <tglx@linutronix.de> wrote:
>
> > The AMD pinctrl driver uses a chained interrupt to demultiplex the GPIO
> > interrupts. Kevin Vandeventer reported, that his new AMD Ryzen locks up
> > hard on boot when the AMD pinctrl driver is initialized. The reason is an
> > interrupt storm. It's not clear whether that's caused by hardware or
> > firmware or both.
> >
> > Using chained interrupts on X86 is a dangerous endavour. If a system is
> > misconfigured or the hardware buggy there is no safety net to catch an
> > interrupt storm.
> >
> > Convert the driver to use a regular interrupt for the demultiplex
> > handler. This allows the interrupt storm detector to catch the malfunction
> > and lets the system boot up.
> >
> > This should be backported to stable because it's likely that more users run
> > into this problem as the AMD Ryzen machines are spreading.
> >
> > Reported-by: Kevin Vandeventer
> > Link: https://bugzilla.suse.com/show_bug.cgi?id=1034261
> > Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
>
> Patch applied for fixes.
>
> Hm, I wonder if there is a bunch of other x86 drivers that should just
> request the IRQ?
For sanity reasons I think so. chained interrupts are fine if you have
bootloader, device tree and kernel under control. Once BIOS/UEFI comes into
play the user is helpless against this kind of wreckage. We'll get that
same joy with ARM64 sooner than later.
Thanks,
tglx
next prev parent reply other threads:[~2017-06-04 13:49 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-23 21:23 [PATCH] pinctrl/amd: Use regular interrupt instead of chained Thomas Gleixner
2017-05-26 4:51 ` Shah, Nehal-bakulchandra
2017-05-26 6:48 ` Thomas Gleixner
2017-05-26 9:33 ` Shah, Nehal-bakulchandra
2017-05-26 9:57 ` Borislav Petkov
2017-06-19 16:13 ` Borislav Petkov
2017-06-20 9:22 ` Thomas Gleixner
2017-06-20 9:29 ` Borislav Petkov
2017-05-29 11:55 ` Linus Walleij
2017-06-04 13:49 ` Thomas Gleixner [this message]
2017-06-20 12:28 ` Borislav Petkov
2017-06-21 16:37 ` Linus Walleij
2017-06-21 17:01 ` Borislav Petkov
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.20.1706041544540.2813@nanos \
--to=tglx@linutronix.de \
--cc=Ken.Xue@amd.com \
--cc=bp@alien8.de \
--cc=linus.walleij@linaro.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marc.zyngier@arm.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