Description of problem: Shortly after dom0 becomes loaded (eg. installing a domU), I lose USB interrupts with the kernel message: rq 16: nobody cared (try booting with the "irqpoll" option) Call Trace: <ffffffff80153b30>{__report_bad_irq+48} <ffffffff80153d47>{note_interrupt+458} <ffffffff801535f2>{__do_IRQ+191} <ffffffff8011060a>{do_IRQ+65} <ffffffff8025f818>{evtchn_do_upcall+123} <ffffffff8010e665>{do_hypervisor_callback+17} <ffffffff8010a0ca>{hypercall_page+202} <ffffffff8010a0ca>{hypercall_page+202} <ffffffff8010c005>{xen_idle+124} <ffffffff8010c35c>{cpu_idle+255} <ffffffff804b47f5>{start_kernel+497} <ffffffff804b4211>{_sinittext+529} handlers: [<ffffffff80295c43>] (usb_hcd_irq+0x0/0x50) [<ffffffff80295c43>] (usb_hcd_irq+0x0/0x50) Disabling IRQ #16 This effectively kills USB. Version-Release number of selected component (if applicable): 2.6.15-1.1955_FC5hypervisor on x86_64 How reproducible: 100% Steps to Reproduce: 1. Boot 2. Do something (eg. install a domU) 3. Wait a few minutes Additional info: Was seen on 1.1948 too. Hardware is dual HT x86_64 Intel CPUs. The presence of the same USB irq handler twice on the handler list is suspicious.
Should be fixed upstream: this seems to be due to IO-APIC legacy compatibility hardware which triggers a legacy IRQ automatically on incoming IO-APIC IRQ in some circumstances. An initial upstream patch fixed it for me; a better, reworked fix has been committed to xen-unstable.hg (cset 9664).
Fixed in rawhide.