From: Rogier Wolff <R.E.Wolff@BitWizard.nl>
To: Marc Zyngier <marc.zyngier@arm.com>
Cc: Phil Elwell <phil@raspberrypi.org>,
Thomas Gleixner <tglx@linutronix.de>,
Jason Cooper <jason@lakedaemon.net>,
Rob Herring <robh+dt@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Florian Fainelli <f.fainelli@gmail.com>,
Stefan Wahren <stefan.wahren@i2se.com>,
Eric Anholt <eric@anholt.net>,
Russell King <linux@armlinux.org.uk>,
Michael Turquette <mturquette@baylibre.com>,
Stephen Boyd <sboyd@codeaurora.org>,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-rpi-kernel@lists.infradead.org, linux-clk@vger.kernel.org
Subject: Re: [PATCH v2 3/4] irqchip: Add BCM2835 AUX interrupt controller
Date: Mon, 12 Jun 2017 18:33:37 +0200 [thread overview]
Message-ID: <20170612163337.GG18236@BitWizard.nl> (raw)
In-Reply-To: <9cbf68ce-6041-3e04-8f82-8d948ab4a716@arm.com>
On Mon, Jun 12, 2017 at 05:19:03PM +0100, Marc Zyngier wrote:
> > Does Linux not notice when one calls generic_handle_irq with the number of an
> > interrupt without a handler?
>
> It is not so much that the interrupt doesn't have a handler, but that
> the device (or one of the devices) is in some sort of interrupt frenzy,
> and the driver is not able to handle this interrupt.
>
> In such a case, Linux tries to mask this interrupt, which in your case
> does exactly nothing. At this point, the system is dead.
In the old days, you had edge-triggered interrupts. That always led to
race conditions: If you handled the interrupt, the hardware might fire
an interrupt again AFTER you've checked: "nothing more to do?" and
before you have told the hardware "I've seen that interrupt". So then
you end up with hardware thinking the interrupt has been handled while
it has in fact not been handled. You can be very careful in what order
you do things, and get it almost right....
So nowadays interrupts are level triggered. That means that a device
that wants attention, but for SOME reason, thinks that it was not
properly handled will keep the interrupt line asserted, and interrupts
will keep firing.
When this happens (it's common when you're writing the device driver,
but it sometimes happens in the field when something unexpected
occurs), an interrupt storm starts. As soon as the generic handler
returns from interrupt, the hardware reenters the interrupt handler.
Without any countermeasures, the system would lock up without much
debugging options. Nowadays (since two decades or so), the Linux
kernel can disable the interrupt, print an error message and try to
continue. It won't work if other important interrupts for the system
were on the same IRQ line, but often enough, you just get a message
that an interrupt was disabled and that one peripheral will stop
working. Good opportunities for debugging the situation.
Roger.
--
** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
** Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
The plan was simple, like my brother-in-law Phil. But unlike
Phil, this plan just might work.
prev parent reply other threads:[~2017-06-12 16:33 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-12 14:25 [PATCH v2 3/4] irqchip: Add BCM2835 AUX interrupt controller Phil Elwell
2017-06-12 14:59 ` Marc Zyngier
[not found] ` <56e314db-49a9-48fa-d7d9-877bd68aadfc-5wv7dgnIgG8@public.gmane.org>
2017-06-12 15:21 ` Phil Elwell
2017-06-12 16:19 ` Marc Zyngier
2017-06-12 16:33 ` Rogier Wolff [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=20170612163337.GG18236@BitWizard.nl \
--to=r.e.wolff@bitwizard.nl \
--cc=devicetree@vger.kernel.org \
--cc=eric@anholt.net \
--cc=f.fainelli@gmail.com \
--cc=jason@lakedaemon.net \
--cc=linux-clk@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rpi-kernel@lists.infradead.org \
--cc=linux@armlinux.org.uk \
--cc=marc.zyngier@arm.com \
--cc=mark.rutland@arm.com \
--cc=mturquette@baylibre.com \
--cc=phil@raspberrypi.org \
--cc=robh+dt@kernel.org \
--cc=sboyd@codeaurora.org \
--cc=stefan.wahren@i2se.com \
--cc=tglx@linutronix.de \
/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;
as well as URLs for NNTP newsgroup(s).