linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Russell King <rmk+lkml@arm.linux.org.uk>
To: "Michael K. Edwards" <medwards.linux@gmail.com>
Cc: Jose Goncalves <jose.goncalves@inov.pt>,
	Frederik Deweerdt <deweerdt@free.fr>,
	akpm@linux-foundation.org, linux-kernel@vger.kernel.org
Subject: Re: Serial related oops
Date: Mon, 19 Feb 2007 21:31:52 +0000	[thread overview]
Message-ID: <20070219213151.GJ27370@flint.arm.linux.org.uk> (raw)
In-Reply-To: <f2b55d220702191324s17c9cc87xc581a9beba2644f8@mail.gmail.com>

On Mon, Feb 19, 2007 at 01:24:17PM -0800, Michael K. Edwards wrote:
> On 2/19/07, Russell King <rmk+lkml@arm.linux.org.uk> wrote:
> >On Mon, Feb 19, 2007 at 12:37:00PM -0800, Michael K. Edwards wrote:
> >> What we've seen on our embedded ARM is that enabling an interrupt that
> >> is shared between multiple UARTs, at a stage when you have not set up
> >> all the data structures touched by the ISR and softirq, can have
> >> horrible consequences, including soft lockups and fandangos on core.
> >
> >Incorrect.  We have:
> >
> >1. registered an interrupt handler at this point.
> >2. disabled interrupts (we're under the spin lock)
> 
> setup_irq() is where things go wrong, at least for us, at least on
> 2.6.16.x.  Interrupts are not disabled at the point in request_irq()
> when the interrupt controller is poked to enable the IRQ source.  If
> you're lucky, and you're on an architecture where the UART interrupt
> is properly level-triggered, and the worst thing that happens when you
> attempt to service an interrupt that isn't yours is that it stays on,
> then you get a soft lockup with two or three recursive __irq_svc hits
> in the backtrace.  If you're not lucky you do a fandango on core.

That should not happen if your interrupt handling is correct - okay, you
might get an interrupt at that point, but while servicing that interrupt
the source will be disabled on the interrupt controller.

You should _never_ _ever_ get recusive interrupts for the same interrupt
source.  Ever.  If you do, your platforms interrupt handling is seriously
buggy.

> But its context is not.  Shared IRQ lines are a _problem_.  You cannot
> safely enable an IRQ until all devices that share it have had their
> ISRs installed, unless you can absolutely guarantee at a hardware
> level that the unitialized ones cannot assert the IRQ line.

Linux assumes that all interrupt sources on a shared IRQ line are
disabled at the point in time when the kernel boots.  When a device
is to be used, an interrupt handler is installed and then the kernel
will enable the interrupt on the device, not before.

We follow that rule in the 8250 driver - in fact, when we initialise
we ensure that interrupts are disabled on any devices we find.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

  reply	other threads:[~2007-02-19 21:32 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-20 13:29 Serial related oops Frederik Deweerdt
2007-02-19 13:45 ` Russell King
2007-02-20 14:24   ` Frederik Deweerdt
2007-02-19 14:35     ` Russell King
2007-02-20 14:48       ` Frederik Deweerdt
2007-02-19 15:05         ` Russell King
2007-02-19 16:29           ` Jose Goncalves
2007-02-19 16:42             ` Russell King
2007-02-19 17:54               ` Jose Goncalves
2007-02-19 20:37                 ` Michael K. Edwards
2007-02-19 20:51                   ` Russell King
2007-02-19 21:24                     ` Michael K. Edwards
2007-02-19 21:31                       ` Russell King [this message]
2007-02-19 22:16                         ` Michael K. Edwards
2007-02-19 23:20                           ` Russell King
2007-02-20  0:04                             ` Michael K. Edwards
2007-02-20  0:21                               ` Russell King
2007-02-20  2:17                                 ` Michael K. Edwards
2007-02-24  2:46                             ` Michael K. Edwards
2007-02-19 21:23                 ` Russell King
2007-02-21 14:13                   ` Jose Goncalves
2007-02-21 14:55                     ` Jose Goncalves
2007-02-21 22:53                     ` Frederik Deweerdt
2007-02-21 23:05                     ` Russell King
2007-02-22  0:34                       ` Michael K. Edwards
2007-02-22  8:54                         ` Russell King
2007-02-22 15:07                           ` Jose Goncalves
2007-02-22 16:56                             ` Russell King
2007-02-22 17:24                               ` jose.goncalves
2007-02-22  5:57                       ` H. Peter Anvin
2007-02-22  7:39                         ` Frederik Deweerdt
2007-02-22  8:52                         ` Russell King
2007-02-22 15:02                       ` Jose Goncalves
2007-02-22 17:03                         ` Russell King
2007-02-22 17:21                           ` jose.goncalves
2007-02-22 17:32                           ` Paul Fulghum
2007-03-01 13:33                           ` Jose Goncalves
2007-03-01 15:10                             ` Russell King
2007-03-01 15:24                               ` Jose Goncalves
     [not found] <fa.0IigYYV566ZB0kBHCj88jOEJx1s@ifi.uio.no>
     [not found] ` <fa.IE91N03KQO01UZbOdcF6HewOdYc@ifi.uio.no>
2007-02-20  2:48   ` Robert Hancock
2007-02-20  4:59     ` Michael K. Edwards
2007-02-20  5:18       ` Robert Hancock

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=20070219213151.GJ27370@flint.arm.linux.org.uk \
    --to=rmk+lkml@arm.linux.org.uk \
    --cc=akpm@linux-foundation.org \
    --cc=deweerdt@free.fr \
    --cc=jose.goncalves@inov.pt \
    --cc=linux-kernel@vger.kernel.org \
    --cc=medwards.linux@gmail.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;
as well as URLs for NNTP newsgroup(s).