On 31.03.2010, at 00:27, Kenni Lund 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. > > 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 easiest thing coming to mind is to unplug the ivtv card for now. It's really only to verify that the patch does something useful :-). Alex-- 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
