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.