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.
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
/*