Commit d88ad34e authored by Alex Williamson's avatar Alex Williamson Committed by David Mosberger

[PATCH] ia64: bug w/ shared interrupts

I just ran into a bug introduced by the most recent iosapic.c patch.
The scenario is a builtin driver is up and running happily.  A module
loads for a devices that happens to share the same interrupt vector,
in this case a network driver.  The module calls pci_enable_device()
as it should, which eventually lands in iosapic_enable_intr().  We
then proceed to mask the interrupt and kill the device that's already
running.  As a bonus, request_interrupt() doesn't fix the problem
because we only call the startup for the interrupt handler on the
first action attached to the interrupt.

I think the best way out of this is simply to detect when an action is
already attached to a vector and leave it alone.  This also prevents
interrupts from moving to other cpus (on boxes w/o irq redirection)
for no good reason.
parent 8df2fe60
...@@ -648,6 +648,16 @@ void ...@@ -648,6 +648,16 @@ void
iosapic_enable_intr (unsigned int vector) iosapic_enable_intr (unsigned int vector)
{ {
unsigned int dest; unsigned int dest;
irq_desc_t *desc;
/*
* In the case of a shared interrupt, do not re-route the vector, and
* especially do not mask a running interrupt (startup will not get
* called for a shared interrupt).
*/
desc = irq_descp(vector);
if (desc->action)
return;
#ifdef CONFIG_SMP #ifdef CONFIG_SMP
/* /*
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment