* Kenni Lund (kenni@xxxxxxx) wrote: > 2010/3/30 Chris Wright <chrisw@xxxxxxxxxx>: > > * Kenni Lund (kenni@xxxxxxx) wrote: > >> Client dmesg: http://pastebin.com/uNG4QK5j > >> Host dmesg: http://pastebin.com/jZu3WKZW > >> > >> I just verified it and I do get the call trace in the host (which > >> disables IRQ 19, used by the PCI USB card), exactly at the same second > > > > It looks like IRQ 19 is shared between the ehci controller and the > > ivtv tuner. What do you see in /proc/interrupts on the host (before > > you unbind and after you bind to pci stub)? > > Ahh, and even if the ivtv module is not loaded, I will still have a > shared IRQ, right? I didn't see ivtv in /proc/interrupts before, as I > unload the ivtv driver on boot in /etc/rc.local, before unbinding the > ivtv tuner and binding it to pci stub. (the ivtv tuner is normally > assigned to the same guest, but not now while testing the PCI USB > card). > > If I don't unload (and unbind/bind) the ivtv driver/tuner on boot in > /etc/local, I get the following in /proc/interrupts on a clean boot: > http://pastebin.com/SFQj58LC > > If I now unbind and bind the PCI USB card to pci stub, I get no > changes in /proc/interrupts. Sorry, I meant bind to pci_stub and launch guest. IOW, you should see kvm_assigned_{msi,msix,intx}_device (from your lspci, I'd expect intx). What's odd is a device is asserting an interrupt to a line w/ no handler acking. The IRQ 19, should have kvm handling the interrupt, in which case it'd always return IRQ_HANDLED. And for the case of shared interrupts, we won't let you start the guest with an assigned device that's sharing an interrupt. IOW, we do request_irq() w/out specifying IRQF_SHARED (meaning we want an exclusive irq). > So I suppose I'll need to get rid of this shared IRQ before I can > conclude anything on the patch in git. Hmm, is there some cleaver way > of fixing this in Linux, or do I have to fix it by changing BIOS IRQ > settings, disabling hardware and/or moving the hardware around in > various PCI slots? The way I typically work around this is simply unbinding the driver from the device in the host (and thus freeing the irq). thanks, -chris -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html