The multi-function device makes me suspicious even if it's not the problem.If rmmod of the "virtual USB" controller driver happens to disablethe IRQ for the entire device, I would consider this a bug in either thedevice design or device firmware. But this probably isn't the case.

And as expected, after the rmmod, dmesg shows:ACPI: PCI interrupt for device 0000:01:04.2 disabled...

So I think your original statement is probably right.Since the hpilo driver never registered an interrupt handler, it'sprobably polling the device (maybe via user space) and would notbe affected by rmmod'ing the USB driver. But the converse is not true.

This initially seems to be an ACPI bug. It's calling acpi_unregister_gsi()without checking if this GSI is shared with another device.Which then calls iosapic_unregister_intr(gsi) and we can no longer determinewhich device asked for the IRQ to be disabled.

The same problem exists with disable_irq() : only takes a globalIRQ# and no additional identifying information to prevent disablinga shared IRQ. So I'm not sure if this is a bug with ACPI or designflaw in generic IRQ APIs. Ingo?