04 May, 2014
1 commit
-
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
13 Nov, 2013
1 commit
-
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
11 Dec, 2012
1 commit
-
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
13 Jan, 2012
1 commit
-
module_param(bool) used to counter-intuitively take an int. In
fddd5201 (mid-2009) we allowed bool or int/unsigned int using a messy
trick.It's time to remove the int/unsigned int option. For this version
it'll simply give a warning, but it'll break next kernel version.Signed-off-by: Rusty Russell
29 Nov, 2011
1 commit
-
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
03 Nov, 2011
1 commit
-
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
03 Jun, 2011
2 commits
-
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 -
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
29 Mar, 2011
2 commits
-
Signed-off-by: Thomas Gleixner
-
Sigh, I'm overworked.
Signed-off-by: Thomas Gleixner
28 Mar, 2011
1 commit
-
We really need these flags for some of the interrupt chips. Move it
from internal state to irq_data and provide proper accessors.Signed-off-by: Thomas Gleixner
Cc: David Daney
19 Feb, 2011
15 commits
-
Use wrappers to keep them away from the core code.
Signed-off-by: Thomas Gleixner
-
That's the right data structure to look at for arch code.
Accessor functions are provided.
irqd_is_per_cpu(irqdata);
irqd_can_balance(irqdata);Coders who access them directly will be tracked down and slapped with
stinking trouts.Signed-off-by: Thomas Gleixner
-
Keep status in sync until all users are fixed.
Signed-off-by: Thomas Gleixner
-
Keep status in sync until all abusers are fixed.
Signed-off-by: Thomas Gleixner
-
We need to maintain the flag for now in both fields status and istate.
Add a CONFIG_GENERIC_HARDIRQS_NO_COMPAT switch to allow testing w/o
the status one. Wrap the access to status IRQ_INPROGRESS in a inline
which can be turned of with CONFIG_GENERIC_HARDIRQS_NO_COMPAT along
with the define.There is no reason that anything outside of core looks at this. That
needs some modifications, but we'll get there.Signed-off-by: Thomas Gleixner
-
No users outside of core.
Signed-off-by: Thomas Gleixner
-
No users outside.
Signed-off-by: Thomas Gleixner
-
Signed-off-by: Thomas Gleixner
-
Handle IRQ_DISABLED consistent.
Signed-off-by: Thomas Gleixner
-
Create irq_disable/enable and use them to keep the flags consistent.
Signed-off-by: Thomas Gleixner
-
With the chip.end() function gone we might run into a situation where
a poll call runs and the real interrupt comes in, sees IRQ_INPROGRESS
and disables the line. That might be a perfect working one, which will
then be masked forever.So mark them polled while the poll runs. When the real handler sees
IRQ_INPROGRESS it checks the poll flag and waits for the polling to
complete. Add the necessary amount of sanity checks to it to avoid
deadlocks.Signed-off-by: Thomas Gleixner
-
No point in running concurrent pollers which confuse each other by
setting PENDING.Signed-off-by: Thomas Gleixner
-
There is no point in polling disabled lines.
percpu does not make sense at all because we only poll on the cpu
we're currently running on. Also polling per_cpu interrupts is racy as
hell. The handler runs without locking so we might get a huge
surprise.If the timer interrupt needs polling, then we wont get there anyway.
Signed-off-by: Thomas Gleixner
-
try_one_irq() contains redundant code and lots of useless checks for
shared interrupts. Check for shared before setting IRQ_INPROGRESS and
then call handle_IRQ_event() while pending. Shorter version with the
same functionality.Signed-off-by: Thomas Gleixner
-
We cannot walk the action chain unlocked. Even if IRQ_INPROGRESS is
set an action can be removed and we follow a null pointer. It's safe
to take the lock there, because the code which removes the action will
call synchronize_irq() which waits unlocked for IRQ_INPROGRESS going
away.Signed-off-by: Thomas Gleixner
04 Oct, 2010
3 commits
-
This option covers now the old chip functions and the irq_desc data
fields which are moving to struct irq_data. More stuff will follow.Pretty handy for testing a conversion, whether something broke or not.
Signed-off-by: Thomas Gleixner
Reviewed-by: Ingo Molnar -
Wrap the old chip functions disable() and shutdown() until the
migration is complete and the old chip functions are removed.Signed-off-by: Thomas Gleixner
Cc: Peter Zijlstra
LKML-Reference:
Reviewed-by: H. Peter Anvin
Reviewed-by: Ingo Molnar -
Convert all references in the core code to orq, chip, handler_data,
chip_data, msi_desc, affinity to irq_data.*Signed-off-by: Thomas Gleixner
Reviewed-by: Ingo Molnar
15 Dec, 2009
1 commit
-
Convert locks which cannot be sleeping locks in preempt-rt to
raw_spinlocks.Signed-off-by: Thomas Gleixner
Acked-by: Peter Zijlstra
Acked-by: Ingo Molnar
08 Dec, 2009
1 commit
-
Conflicts:
kernel/irq/chip.c
06 Dec, 2009
1 commit
-
* 'irq-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
genirq: Fix spurious irq seqfile conversion
genirq: switch /proc/irq/*/spurious to seq_file
irq: Do not attempt to create subdirectories if /proc/irq/ failed
irq: Remove unused debug_poll_all_shared_irqs()
irq: Fix docbook comments
irq: trivial: Fix typo in comment for #endif
04 Dec, 2009
1 commit
-
This patch was generated by
git grep -E -i -l 'couter' | xargs -r perl -p -i -e 's/couter/counter/'
Signed-off-by: Uwe Kleine-König
Signed-off-by: Jiri Kosina
08 Nov, 2009
1 commit
-
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/0x30other info that might help us debug this:
1 lock held by swapper/0:
#0: (kernel/irq/spurious.c:21){+.-...}, at: []
run_timer_softirq+0x1a9/0x315stack 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/0x20The 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
04 Nov, 2009
1 commit
-
commit 74296a8ed added this function for debug purposes, but it was
never used for anything. Remove it.Signed-off-by: Thomas Gleixner
04 Aug, 2009
1 commit
-
It's wrong (the parm takes no arguments) and compile-time wiped
away anyway (due to !MODULE).Signed-off-by: Jiri Slaby
LKML-Reference:
Signed-off-by: Ingo Molnar
17 Jan, 2009
1 commit
-
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
26 Dec, 2008
1 commit
-
Impact: cleanup
all for_each_irq_desc() usage point have !desc check.
then its check can move into for_each_irq_desc() macro.Signed-off-by: KOSAKI Motohiro
Acked-by: Yinghai Lu
Signed-off-by: Ingo Molnar
08 Dec, 2008
1 commit
-
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
16 Oct, 2008
1 commit
-
Signed-off-by: Thomas Gleixner