]> git.hungrycats.org Git - linux/commitdiff
[PATCH] ia64: bug w/ shared interrupts
authorAlex Williamson <alex.williamson@hp.com>
Mon, 26 Apr 2004 07:13:52 +0000 (00:13 -0700)
committerDavid Mosberger <davidm@tiger.hpl.hp.com>
Mon, 26 Apr 2004 07:13:52 +0000 (00:13 -0700)
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.

arch/ia64/kernel/iosapic.c

index 1ac07020d8f6afe0c476414f6474b3e7cdec839b..9db13ac60c978aef33557f281c57aa3d554cf7fb 100644 (file)
@@ -648,6 +648,16 @@ void
 iosapic_enable_intr (unsigned int vector)
 {
        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
        /*