Age | Commit message (Collapse) | Author | Files | Lines |
|
probe_irq_off() is disfunctional as the local nr_irqs is referenced
instead of the global one for the for_each_irq_desc() iterator.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
|
|
Use for_each_irq_desc[_reverse] for all the iteration loops.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
|
|
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
|
|
Revert the dynarray changes. They need more thought and polishing.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
|
|
Remove the leftover of sparseirqs.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
|
|
This code is not ready, but we need to rip it out instead of rebasing
as we would lose the APIC/IO_APIC unification otherwise.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
|
|
For the non sparse irq case an inline function is perfectly fine.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
|
|
when SPARSE_IRQ is not used, should still use irq_desc->lock
Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
|
|
caused by
commit a532e19680ada3b8579b81e67e76d3ebd19c340f
Author: Yinghai Lu <yhlu.kernel@gmail.com>
Date: Wed Aug 20 20:46:25 2008 -0700
x86: sparse_irq needs spin_lock in allocations
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
|
|
Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com>
Cc: Yinghai Lu <yhlu.kernel@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
|
|
Steven Noonan reported a boot hang when using irqpoll and
CONFIG_HAVE_SPARSE_IRQ=y.
The irqpoll loop needs to be updated to not iterate from 1 to nr_irqs
but to iterate via for_each_irq_desc(). (in the former case desc can
be NULL which crashes the box)
Reported-by: Steven Noonan <steven@uplinklabs.net>
Tested-by: Steven Noonan <steven@uplinklabs.net>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
|
|
Change the IRQ affinity in the process context when the IRQ is disabled.
Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Signed-off-by: Shaohua Li <shaohua.li@intel.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
|
|
Extraneous call to irq_to_desc().
Signed-off-by: Dean Nelson <dcn@sgi.com>
Cc: Yinghai Lu <yhlu.kernel@gmail.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
|
|
fix non-sparseirq architectures.
Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
|
|
Suresh Siddha noticed that we should have a spinlock around it.
Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
|
|
-tip testing found this lockdep splat:
[ 0.000000] Initializing CPU#0
[ 0.000000] found new irq_desc for irq 0
[ 0.000000] INFO: trying to register non-static key.
[ 0.000000] the code is fine but needs lockdep annotation.
[ 0.000000] turning off the locking correctness validator.
[ 0.000000] Pid: 0, comm: swapper Not tainted 2.6.27-rc3-tip-00191-g98ccb89-dirty #1
[ 0.000000] [<c0153c22>] register_lock_class+0x3d2/0x400
[ 0.000000] [<c0104d87>] ? mcount_call+0x5/0xa
[ 0.000000] [<c0154f3a>] __lock_acquire+0x22a/0x5d0
[ 0.000000] [<c0104d87>] ? mcount_call+0x5/0xa
[ 0.000000] [<c0155351>] lock_acquire+0x71/0xa0
[ 0.000000] [<c016d61f>] ? set_irq_chip+0x3f/0x90
[ 0.000000] [<c070f148>] _spin_lock_irqsave+0x58/0x90
[ 0.000000] [<c016d61f>] ? set_irq_chip+0x3f/0x90
[ 0.000000] [<c016d61f>] set_irq_chip+0x3f/0x90
[ 0.000000] [<c016d7e0>] ? handle_level_irq+0x0/0xe0
[ 0.000000] [<c016da1a>] set_irq_chip_and_handler_name+0x1a/0x40
[ 0.000000] [<c0a396c1>] init_ISA_irqs+0x51/0xa0
[ 0.000000] [<c0a4a365>] pre_intr_init_hook+0x25/0x30
[ 0.000000] [<c0a39723>] native_init_IRQ+0x13/0x370
[ 0.000000] [<c015569c>] ? lock_release+0xcc/0x1d0
[ 0.000000] [<c0104d87>] ? mcount_call+0x5/0xa
[ 0.000000] [<c070dc22>] ? __mutex_unlock_slowpath+0x92/0x110
[ 0.000000] [<c070dcad>] ? mutex_unlock+0xd/0x10
[ 0.000000] [<c0135f62>] ? cpu_maps_update_done+0x12/0x20
[ 0.000000] [<c06c6743>] ? register_cpu_notifier+0x23/0x30
[ 0.000000] [<c011e8ae>] init_IRQ+0xe/0x10
[ 0.000000] [<c0a357a5>] start_kernel+0x1c5/0x340
[ 0.000000] [<c0a35280>] ? unknown_bootoption+0x0/0x210
[ 0.000000] [<c0a3506b>] i386_start_kernel+0x6b/0x80
[ 0.000000] =======================
[ 0.000000] found new irq_desc for irq 1
[ 0.000000] found new irq_desc for irq 2
[ 0.000000] found new irq_desc for irq 3
this:
static void init_one_irq_desc(struct irq_desc *desc)
{
memcpy(desc, &irq_desc_init, sizeof(struct irq_desc));
#ifdef CONFIG_TRACE_IRQFLAGS
lockdep_set_class(&desc->lock, &irq_desc_lock_class);
#endif
}
should be unconditional.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
|
|
This has been deprecated for years, the user space irqbalanced utility
works better with numa, has configurable policies, etc...
Signed-off-by: Yinghai Lu <yhlu.kernel@gmai.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
|
|
so later don't need compare with -1U
Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
|
|
change names:
irq_desc() ==> irq_desc_alloc
__irq_desc() ==> irq_desc
Also split a few of the uses in lowlevel x86 code.
v2: need to check if desc is null in smp_irq_move_cleanup
Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
|
|
So we could remove some duplicated calling to irq_desc
v2: make sure irq_desc in init/main.c is not used without generic_hardirqs
Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
|
|
remove irq limit checks - nr_irqs is dynamic and we expand anytime.
v2: fix checking about result irq_cfg_without_new, so could use msi again
v3: use irq_desc_without_new to check irq is valid
Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
|
|
There are a handful of loops that go from 0 to nr_irqs and use
get_irq_desc() on them. These would allocate all the irq_desc
entries, regardless of the need for them.
Use the smarter for_each_irq_desc() iterator that will only iterate
over the present ones.
v2: make sure arch without GENERIC_HARDIRQS work too
Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
|
|
add an irq_desc accessor that will not allocate any sparse entry
but returns failure if there's no entry present.
Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
|
|
based on Eric's patch ...
together mold it with dyn_array for irq_desc, will allcate kstat_irqs for
nr_irq_desc alltogether if needed. -- at that point nr_cpus is known already.
v2: make sure system without generic_hardirqs works they don't have irq_desc
v3: fix merging
v4: [mingo@elte.hu] fix typo
[ mingo@elte.hu ] irq: build fix
fix:
arch/x86/xen/spinlock.c: In function 'xen_spin_lock_slow':
arch/x86/xen/spinlock.c:90: error: 'struct kernel_stat' has no member named 'irqs'
Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
|
|
fix:
[ 10.631533] calling yenta_socket_init+0x0/0x20
[ 10.631533] Yenta: CardBus bridge found at 0000:15:00.0 [17aa:2012]
[ 10.631533] Yenta: Using INTVAL to route CSC interrupts to PCI
[ 10.631533] Yenta: Routing CardBus interrupts to PCI
[ 10.631533] Yenta TI: socket 0000:15:00.0, mfunc 0x01d01002, devctl 0x64
[ 10.731599] BUG: unable to handle kernel NULL pointer dereference at 00000040
[ 10.731838] IP: [<c0c95b5f>] _spin_lock_irq+0xf/0x20
[ 10.732221] *pde = 00000000
[ 10.732741] Oops: 0002 [#1] SMP
[ 10.733453]
[ 10.734253] Pid: 1, comm: swapper Tainted: G W (2.6.27-rc3-tip-00173-gd7eaa4f-dirty #1)
[ 10.735188] EIP: 0060:[<c0c95b5f>] EFLAGS: 00010002 CPU: 0
[ 10.735523] EIP is at _spin_lock_irq+0xf/0x20
[ 10.735523] EAX: 00000040 EBX: 00000000 ECX: f6e04c90 EDX: 00000100
[ 10.735523] ESI: 000000df EDI: f6e04c90 EBP: f7867df0 ESP: f7867df0
[ 10.735523] DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
[ 10.735523] Process swapper (pid: 1, ti=f7867000 task=f7870000 task.ti=f7867000)
[ 10.735523] Stack: f7867e04 c0155fbd 00000000 00000000 f6e04c90 f7867e5c c0c6e319 c0f6a074
[ 10.735523] f6e04c90 000017aa 00002012 c112b648 f791f240 c112b5e0 f7867e44 c010440b
[ 10.735523] f791f240 f791f29c c112b8ec f791f240 00000000 f7867e5c c048f893 03c0b648
[ 10.735523] Call Trace:
[ 10.735523] [<c0155fbd>] ? probe_irq_on+0x3d/0x140
[ 10.735523] [<c0c6e319>] ? yenta_probe+0x529/0x640
[ 10.735523] [<c010440b>] ? mcount_call+0x5/0xa
[ 10.735523] [<c048f893>] ? pci_match_device+0xa3/0xb0
[ 10.735523] [<c048fc1e>] ? pci_device_probe+0x5e/0x80
[ 10.735523] [<c0515423>] ? driver_probe_device+0x83/0x180
[ 10.735523] [<c0515594>] ? __driver_attach+0x74/0x80
[ 10.735523] [<c0514b69>] ? bus_for_each_dev+0x49/0x70
[ 10.735523] [<c051528e>] ? driver_attach+0x1e/0x20
[ 10.735523] [<c0515520>] ? __driver_attach+0x0/0x80
[ 10.735523] [<c05150d3>] ? bus_add_driver+0x1a3/0x220
[ 10.735523] [<c048fb60>] ? pci_device_remove+0x0/0x40
[ 10.735523] [<c05157f4>] ? driver_register+0x54/0x130
[ 10.735523] [<c048fe2f>] ? __pci_register_driver+0x4f/0x90
[ 10.735523] [<c11e9419>] ? yenta_socket_init+0x19/0x20
[ 10.735523] [<c0101125>] ? do_one_initcall+0x35/0x160
[ 10.735523] [<c11e9400>] ? yenta_socket_init+0x0/0x20
[ 10.735523] [<c01391a6>] ? __queue_work+0x36/0x50
[ 10.735523] [<c013922d>] ? queue_work_on+0x3d/0x50
[ 10.735523] [<c11a2758>] ? kernel_init+0x148/0x210
[ 10.735523] [<c11a2610>] ? kernel_init+0x0/0x210
[ 10.735523] [<c01043f3>] ? kernel_thread_helper+0x7/0x10
[ 10.735523] =======================
[ 10.735523] Code: 10 38 f2 74 06 f3 90 8a 10 eb f6 5d 89 c8 c3 8d b6 00 00 00 00 8d bc 27 00 00 00 00 55 89 e5 e8 a4 e8 46 ff fa ba 00 01 00 00 90 <66> 0f c1 10 38 f2 74 06 f3 90 8a 10 eb f6 5d c3 90 55 89 e5 53
as auto-probing wants to iterate over existing irqs.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
|
|
irq_desc[]
add CONFIG_HAVE_SPARSE_IRQ to for use condensed array.
Get rid of irq_desc[] array assumptions.
Preallocate 32 irq_desc, and irq_desc() will try to get more.
( No change in functionality is expected anywhere, except the odd build
failure where we missed a code site or where a crossing commit itroduces
new irq_desc[] usage. )
v2: according to Eric, change get_irq_desc() to irq_desc()
Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
|
|
fix:
Building modules, stage 2.
MODPOST 458 modules
ERROR: "nr_irqs" [drivers/serial/8250.ko] undefined!
Signed-off-by: Ingo Molnar <mingo@elte.hu>
|
|
Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
|
|
at this point nr_irqs is equal NR_IRQS
convert a few easy users from NR_IRQS to dynamic nr_irqs.
v2: according to Eric, we need to take care of arch without generic_hardirqs
Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
|
|
|
|
Genirq hasn't previously recorded the trigger type used by any given IRQ,
although some irq_chip support has done so. That data can be useful when
troubleshooting. This patch records it in the relevant irq_desc.status
bits, and improves consistency between the two driver-visible calls
affected:
- Make set_irq_type() usage match request_irq() usage:
* IRQ_TYPE_NONE should be a NOP; succeed, so irq_chip methods
won't have to handle that case any more (many do it wrong).
* IRQ_TYPE_PROBE is ignored; any buggy out-of-tree callers
might need to switch over to the real IRQ probing code.
* emit the same diagnostics (from shared utility code)
- Their kerneldoc now reflects usage:
* request_irq() flags include IRQF_TRIGGER_* to specify
active edge(s)/level ... docs previously omitted that
* set_irq_type() is declared in <linux/irq.h> so callers
should use the (bit-equivalent) IRQ_TYPE_* symbols there
Also: adds a warning about shared IRQs that don't end up using the
requested trigger mode; and fix an unrelated "sparse" warning.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
|
|
|
|
This patch clarifies usage of irq_chip->startup() callback:
1. The "if (startup) startup(); else enabled();" code in setup_irq()
is unnecessary, as startup() falls back to enabled() via
default callbacks, set by irq_chip_set_defaults().
2. When using set_irq_chained_handler() the startup() was never called,
which is not good at all... Fixed. And again - when startup() is not
defined the call will fall back to enable() than to unmask() via
default callbacks.
Signed-off-by: Pawel Moll <pawel.moll@st.com>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
|
|
When DEBUG_SHIRQ is selected, a spurious IRQ is issued before
the setup_irq() initializes the desc->depth. An IRQ handler may
call disable_irq_nosync(), but then setup_irq() will overwrite
desc->depth, and upon enable_irq() we'll catch this WARN:
------------[ cut here ]------------
Badness at kernel/irq/manage.c:180
NIP: c0061ab8 LR: c0061f10 CTR: 00000000
REGS: cf83be50 TRAP: 0700 Not tainted (2.6.27-rc3-23450-g74919b0)
MSR: 00021032 <ME,IR,DR> CR: 22042022 XER: 20000000
TASK = cf829100[5] 'events/0' THREAD: cf83a000
GPR00: c0061f10 cf83bf00 cf829100 c038e674 00000016 00000000 cf83bef8 00000038
GPR08: c0298910 00000000 c0310d28 cf83a000 00000c9c 1001a1a8 0fffe000 00800000
GPR16: ffffffff 00000000 007fff00 00000000 007ffeb0 c03320a0 c031095c c0310924
GPR24: cf8292ec cf807190 cf83a000 00009032 c038e6a4 c038e674 cf99b1cc c038e674
NIP [c0061ab8] __enable_irq+0x20/0x80
LR [c0061f10] enable_irq+0x50/0x70
Call Trace:
[cf83bf00] [c038e674] irq_desc+0x630/0x9000 (unreliable)
[cf83bf10] [c0061f10] enable_irq+0x50/0x70
[cf83bf30] [c01abe94] phy_change+0x68/0x108
[cf83bf50] [c0046394] run_workqueue+0xc4/0x16c
[cf83bf90] [c0046834] worker_thread+0x74/0xd4
[cf83bfd0] [c004ab7c] kthread+0x48/0x84
[cf83bff0] [c00135e0] kernel_thread+0x44/0x60
Instruction dump:
4e800020 3d20c031 38a94214 4bffffcc 9421fff0 7c0802a6 93e1000c 7c7f1b78
90010014 8123001c 2f890000 409e001c <0fe00000> 80010014 83e1000c 38210010
That trace corresponds to this line:
WARN(1, KERN_WARNING "Unbalanced enable for IRQ %d\n", irq);
The patch fixes the problem by moving the SHIRQ code below the
setup_irq().
Unfortunately we can't easily move the SHIRQ code inside the
setup_irq(), since it grabs a spinlock, so to prvent a 'real'
IRQ from interfere us we should disable that IRQ.
p.s. The driver in question is drivers/net/phy/phy.c.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Cc: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
|
|
Conflicts:
arch/x86/kernel/genapic_64.c
include/asm-x86/kvm_host.h
Signed-off-by: Ingo Molnar <mingo@elte.hu>
|
|
Switch /proc/irq/*/smp_affinity , /proc/irq/default_smp_affinity to
seq_files.
cat(1) reads with 1024 chunks by default, with high enough NR_CPUS, there
will be -EINVAL.
As side effect, there are now two less users of the ->read_proc interface.
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Cc: Paul Jackson <pj@sgi.com>
Cc: Mike Travis <travis@sgi.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
While I'm glad to finally see the hole fixed whereby passing an invalid
IRQ trigger type to request_irq() would be ignored, the current diagnostic
isn't quite useful. Fixed by also listing the trigger type which was
rejected.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Acked-by: Uwe Kleine-König <Uwe.Kleine-Koenig@digi.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
Conflicts:
include/asm-x86/dma-mapping.h
include/asm-x86/namei.h
include/asm-x86/uaccess.h
Signed-off-by: Ingo Molnar <mingo@elte.hu>
|
|
Use WARN() instead of a printk+WARN_ON() pair; this way the message
becomes part of the warning section for better reporting/collection.
Signed-off-by: Arjan van de Ven <arjan@linux.intel.com>
Cc: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
Replace a printk+WARN_ON() by a WARN(); this increases the chance of the
string making it into the bugreport (ie: it goes inside the
---[ cut here ]--- section)
Signed-off-by: Arjan van de Ven <arjan@linux.intel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
Conflicts:
include/asm-x86/i8259.h
include/asm-x86/msidef.h
Signed-off-by: Ingo Molnar <mingo@elte.hu>
|
|
Replace a printk+WARN_ON() by a WARN(); this increases the chance of the
string making it into the bugreport (ie: it goes inside the
---[ cut here ]--- section)
Signed-off-by: Arjan van de Ven <arjan@linux.intel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
Conflicts:
drivers/pci/dmar.c
Signed-off-by: Ingo Molnar <mingo@elte.hu>
|
|
set_type returns an int indicating success or failure, but up to now
setup_irq ignores that.
In my case this resulted in a machine hang:
gpio-keys requested IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING, but
arm/ns9xxx can only trigger on one direction so set_type didn't touch
the configuration which happens do default to a level sensitiveness and
returned -EINVAL. setup_irq ignored that and unmasked the irq. This
resulted in an endless triggering of the gpio-key interrupt service
routine which effectively killed the machine.
With this patch applied setup_irq propagates the error to the caller.
Note that before in the case
chip && !chip->set_type && !chip->name
a NULL pointer was feed to printk. This is fixed, too.
Signed-off-by: Uwe Kleine-König <Uwe.Kleine-Koenig@digi.com>
Cc: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
Since 15a647eba94c3da27ccc666bea72e7cca06b2d19 set_irq_wake returned -ENXIO
if another device had it already enabled. Zero is the right value to
return in this case. Moreover the change to desc->status was not reverted
if desc->chip->set_wake returned an error.
Signed-off-by: Uwe Kleine-König <Uwe.Kleine-Koenig@digi.com>
Acked-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Russell King <rmk@arm.linux.org.uk>
Cc: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
|
|
|
|
When we disable a screaming irq we never see it again. If the irq
line is shared or if the driver half works this is a real pain. So
periodically poll the handlers for screaming interrupts.
I use a timer instead of the classic irq poll technique of working off
the timer interrupt because when we use the local apic timers
note_interrupt is never called (bug?). Further on a system with
dynamic ticks the timer interrupt might not even fire unless there is
a timer telling it it needs to.
I forced this case on my test system with an e1000 nic and my ssh
session remained responsive despite the interrupt handler only being
called every 10th of a second.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
|
|
Generic infrastructure for migrating the irq from the process context in the
presence of CONFIG_GENERIC_PENDING_IRQ.
This will be used later for migrating irq in the presence of
interrupt-remapping.
Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
Cc: akpm@linux-foundation.org
Cc: arjan@linux.intel.com
Cc: andi@firstfloor.org
Cc: ebiederm@xmission.com
Cc: jbarnes@virtuousgeek.org
Cc: steiner@sgi.com
Signed-off-by: Ingo Molnar <mingo@elte.hu>
|
|
In http://bugzilla.kernel.org/show_bug.cgi?id=9580 it was pointed out
that the desc->chip checks are extraneous. In fact these are left
overs from early development and can be removed safely.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
|