Eric Lee / smarc-ti-linux-kernel

04 May, 2014

1 commit

  • 1e77d0a1e   genirq: Sanitize spurious interrupt detection of threaded irqs ... Browse Code »
    5

    Till reported that the spurious interrupt detection of threaded
    interrupts is broken in two ways:

    - note_interrupt() is called for each action thread of a shared
    interrupt line. That's wrong as we are only interested whether none
    of the device drivers felt responsible for the interrupt, but by
    calling multiple times for a single interrupt line we account
    IRQ_NONE even if one of the drivers felt responsible.

    - note_interrupt() when called from the thread handler is not
    serialized. That leaves the members of irq_desc which are used for
    the spurious detection unprotected.

    To solve this we need to defer the spurious detection of a threaded
    interrupt to the next hardware interrupt context where we have
    implicit serialization.

    If note_interrupt is called with action_ret == IRQ_WAKE_THREAD, we
    check whether the previous interrupt requested a deferred check. If
    not, we request a deferred check for the next hardware interrupt and
    return.

    If set, we check whether one of the interrupt threads signaled
    success. Depending on this information we feed the result into the
    spurious detector.

    If one primary handler of a shared interrupt returns IRQ_HANDLED we
    disable the deferred check of irq threads on the same line, as we have
    found at least one device driver who cared.

    Reported-by: Till Straumann
    Signed-off-by: Thomas Gleixner
    Tested-by: Austin Schuh
    Cc: Oliver Hartkopp
    Cc: Wolfgang Grandegger
    Cc: Pavel Pisa
    Cc: Marc Kleine-Budde
    Cc: linux-can@vger.kernel.org
    Cc: stable@vger.kernel.org
    Link: http://lkml.kernel.org/r/alpine.LFD.2.02.1303071450130.22263@ionos

    Thomas Gleixner
     

13 Nov, 2013

1 commit

  • b39898cd4   genirq: Prevent spurious detection for unconditionally polled interrupts ... Browse Code »

    On a 68k platform a couple of interrupts are demultiplexed and
    "polled" from a top level interrupt. Unfortunately there is no way to
    determine which of the sub interrupts raised the top level interrupt,
    so all of the demultiplexed interrupt handlers need to be
    invoked. Given a high enough frequency this can trigger the spurious
    interrupt detection mechanism, if one of the demultiplex interrupts
    returns IRQ_NONE continuously. But this is a false positive as the
    polling causes this behaviour and not buggy hardware/software.

    Introduce IRQ_POLLED which can be set at interrupt chip setup time via
    irq_set_status_flags(). The flag excludes the interrupt from the
    spurious detector and from all core polling activities.

    Reported-and-tested-by: Michael Schmitz
    Cc: Geert Uytterhoeven
    Cc: linux-m68k@vger.kernel.org
    Link: http://lkml.kernel.org/r/alpine.DEB.2.02.1311061149250.23353@ionos.tec.linutronix.de

    Thomas Gleixner
     

11 Dec, 2012

1 commit

  • e716efde7   genirq: Avoid deadlock in spurious handling ... Browse Code »

    commit 52553ddf(genirq: fix regression in irqfixup, irqpoll)
    introduced a potential deadlock by calling the action handler with the
    irq descriptor lock held.

    Remove the call and let the handling code run even for an interrupt
    where only a single action is registered. That matches the goal of
    the above commit and avoids the deadlock.

    Document the confusing action = desc->action reload in the handling
    loop while at it.

    Reported-and-tested-by: "Wang, Warner"
    Tested-by: Edward Donovan
    Cc: "Wang, Song-Bo (Stoney)"
    Cc: stable@vger.kernel.org
    Signed-off-by: Thomas Gleixner

    Thomas Gleixner
     

13 Jan, 2012

1 commit

29 Nov, 2011

1 commit

  • 52553ddff   genirq: fix regression in irqfixup, irqpoll ... Browse Code »

    Commit fa27271bc8d2("genirq: Fixup poll handling") introduced a
    regression that broke irqfixup/irqpoll for some hardware configurations.

    Amidst reorganizing 'try_one_irq', that patch removed a test that
    checked for 'action->handler' returning IRQ_HANDLED, before acting on
    the interrupt. Restoring this test back returns the functionality lost
    since 2.6.39. In the current set of tests, after 'action' is set, it
    must precede '!action->next' to take effect.

    With this and my previous patch to irq/spurious.c, c75d720fca8a, all
    IRQ regressions that I have encountered are fixed.

    Signed-off-by: Edward Donovan
    Reported-and-tested-by: Rogério Brito
    Cc: Thomas Gleixner
    Cc: stable@kernel.org (2.6.39+)
    Signed-off-by: Linus Torvalds

    Edward Donovan
     

03 Nov, 2011

1 commit

  • c75d720fc   genirq: Fix irqfixup, irqpoll regression ... Browse Code »

    commit d05c65fff0 ("genirq: spurious: Run only one poller at a time")
    introduced a regression, leaving the boot options 'irqfixup' and
    'irqpoll' non-functional. The patch placed tests in each function, to
    exit if the function is already running. The test in 'misrouted_irq'
    exited when it should have proceeded, effectively disabling
    'misrouted_irq' and 'poll_spurious_irqs'.

    The check for an already running poller needs to be "!= 1" not "== 1"
    as "1" is the value when the first poller starts running.

    Signed-off-by: Edward Donovan
    Cc: maciej.rutecki@gmail.com
    Link: http://lkml.kernel.org/r/1320175784-6745-1-git-send-email-edward.donovan@numble.net
    Cc: stable@vger.kernel.org # >= 2.6.39
    Signed-off-by: Thomas Gleixner

    Edward Donovan
     

03 Jun, 2011

2 commits

  • 3a43e05f4   irq: Handle spurios irq detection for threaded irqs ... Browse Code »

    The detection of spurios interrupts is currently limited to first level
    handler. In force-threaded mode we never notice if the threaded irq does
    not feel responsible.
    This patch catches the return value of the threaded handler and forwards
    it to the spurious detector. If the primary handler returns only
    IRQ_WAKE_THREAD then the spourious detector ignores it because it gets
    called again from the threaded handler.

    [ tglx: Report the erroneous return value early and bail out ]

    Signed-off-by: Sebastian Andrzej Siewior
    Link: http://lkml.kernel.org/r/1306824972-27067-2-git-send-email-sebastian@breakpoint.cc
    Signed-off-by: Thomas Gleixner

    Sebastian Andrzej Siewior
     
  • ef26f20cd   genirq: Print threaded handler in spurious debug output ... Browse Code »

    In forced threaded mode (or with an explicit threaded handler) we only
    see the primary handler, but not the threaded handler.

    Signed-off-by: Sebastian Andrzej Siewior
    Link: http://lkml.kernel.org/r/1306824972-27067-1-git-send-email-sebastian@breakpoint.cc
    Signed-off-by: Thomas Gleixner

    Sebastian Andrzej Siewior
     

29 Mar, 2011

2 commits

28 Mar, 2011

1 commit

19 Feb, 2011

15 commits

04 Oct, 2010

3 commits

15 Dec, 2009

1 commit

08 Dec, 2009

1 commit

06 Dec, 2009

1 commit

04 Dec, 2009

1 commit

08 Nov, 2009

1 commit

  • e7e7e0c08   genirq: try_one_irq() must be called with irq disabled ... Browse Code »

    Prarit reported:
    =================================
    [ INFO: inconsistent lock state ]
    2.6.32-rc5 #1
    ---------------------------------
    inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage.
    swapper/0 [HC0[0]:SC1[1]:HE1:SE0] takes:
    (&irq_desc_lock_class){?.-...}, at: [] try_one_irq+0x32/0x138
    {IN-HARDIRQ-W} state was registered at:
    [] __lock_acquire+0x2fc/0xd5d
    [] lock_acquire+0xf3/0x12d
    [] _spin_lock+0x40/0x89
    [] handle_level_irq+0x30/0x105
    [] handle_irq+0x95/0xb7
    [] do_IRQ+0x6a/0xe0
    [] ret_from_intr+0x0/0x16
    irq event stamp: 195096
    hardirqs last enabled at (195096): [] _spin_unlock_irq+0x3a/0x5c
    hardirqs last disabled at (195095): [] _spin_lock_irq+0x29/0x95
    softirqs last enabled at (195088): [] __do_softirq+0x1c1/0x1ef
    softirqs last disabled at (195093): [] call_softirq+0x1c/0x30

    other info that might help us debug this:
    1 lock held by swapper/0:
    #0: (kernel/irq/spurious.c:21){+.-...}, at: []
    run_timer_softirq+0x1a9/0x315

    stack backtrace:
    Pid: 0, comm: swapper Not tainted 2.6.32-rc5 #1
    Call Trace:
    [] valid_state+0x187/0x1ae
    [] mark_lock+0x129/0x253
    [] __lock_acquire+0x370/0xd5d
    [] lock_acquire+0xf3/0x12d
    [] _spin_lock+0x40/0x89
    [] try_one_irq+0x32/0x138
    [] poll_all_shared_irqs+0x41/0x6d
    [] poll_spurious_irqs+0x1c/0x49
    [] run_timer_softirq+0x239/0x315
    [] __do_softirq+0x102/0x1ef
    [] call_softirq+0x1c/0x30
    [] do_softirq+0x59/0xca
    [] irq_exit+0x58/0xae
    [] smp_apic_timer_interrupt+0x94/0xba
    [] apic_timer_interrupt+0x13/0x20

    The reason is that try_one_irq() is called from hardirq context with
    interrupts disabled and from softirq context (poll_all_shared_irqs())
    with interrupts enabled.

    Disable interrupts before calling it from poll_all_shared_irqs().

    Reported-and-tested-by: Prarit Bhargava
    Signed-off-by: Yong Zhang
    LKML-Reference:
    Signed-off-by: Thomas Gleixner

    Yong Zhang
     

04 Nov, 2009

1 commit

04 Aug, 2009

1 commit

17 Jan, 2009

1 commit

  • 74296a8ed   irq: provide debug_poll_all_shared_irqs() method under CONFIG_DEBUG_SHIRQ ... Browse Code »

    Provide a shared interrupt debug facility under CONFIG_DEBUG_SHIRQ:
    it uses the existing irqpoll facilities to iterate through all
    registered interrupt handlers and call those which can handle shared
    IRQ lines.

    This can be handy for suspend/resume debugging: if we call this function
    early during resume we can trigger crashes in those drivers which have
    incorrect assumptions about when exactly their ISRs will be called
    during suspend/resume.

    Signed-off-by: Ingo Molnar

    Ingo Molnar
     

26 Dec, 2008

1 commit

08 Dec, 2008

1 commit

  • 0b8f1efad   sparse irq_desc[] array: core kernel and x86 changes ... Browse Code »

    Impact: new feature

    Problem on distro kernels: irq_desc[NR_IRQS] takes megabytes of RAM with
    NR_CPUS set to large values. The goal is to be able to scale up to much
    larger NR_IRQS value without impacting the (important) common case.

    To solve this, we generalize irq_desc[NR_IRQS] to an (optional) array of
    irq_desc pointers.

    When CONFIG_SPARSE_IRQ=y is used, we use kzalloc_node to get irq_desc,
    this also makes the IRQ descriptors NUMA-local (to the site that calls
    request_irq()).

    This gets rid of the irq_cfg[] static array on x86 as well: irq_cfg now
    uses desc->chip_data for x86 to store irq_cfg.

    Signed-off-by: Yinghai Lu
    Signed-off-by: Ingo Molnar

    Yinghai Lu
     

16 Oct, 2008

1 commit