|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Xen-unstable: xen panic RIP: dpci_softirq
Monday, November 17, 2014, 9:43:47 PM, you wrote: > . snip.. >> > # cat /proc/interrupts |grep eth >> > 36: 384183 0 xen-pirq-ioapic-level eth0 >> > 63: 1 0 xen-pirq-msi-x eth1 >> > 64: 24 661961 xen-pirq-msi-x eth1-rx-0 >> > 65: 205 0 xen-pirq-msi-x eth1-rx-1 >> > 66: 162 0 xen-pirq-msi-x eth1-tx-0 >> > 67: 190 0 xen-pirq-msi-x eth1-tx-1 >> > Is that a similar distribution of IRQ/MSIx you end up having? >> >> These are when they are still active and assigned to dom0 (and not owned by >> pci-back) or in the guest ? > In the guest. >> >> I attached my /proc/interrupts for both dom0 as guest 16 with all guests >> running >> (on a Xen from before the dpci changes). >> With the devices passed through I only see one line with the IRQ of a >> PCI soundcard passed through to a PV guest: >> 22: 38959 0 0 0 0 0 >> xen-pirq-ioapic-level xen-pciback[0000:03:06.0] >> >> All the other devices passed through (to HVM guests) are not visible in >> /proc/interrupts of dom0. > Right. >> >> In the guest i do get these: >> 23: 35 0 0 0 xen-pirq-ioapic-level >> uhci_hcd:usb3 >> 40: 13440077 0 0 0 xen-pirq-ioapic-level >> cx25821[1], cx25821[1] > That is a bit odd. You have two 'request_irq' off this sole device, which > would > imply that there are _two_ devices which are using the same interrupt line. > But how is that possible when your device: > 0a:00.0 Multimedia video controller: Conexant Systems, Inc. Device 8210 > Flags: bus master, fast devsel, latency 0, IRQ 47 > Memory at fe200000 (64-bit, non-prefetchable) [size=2M] > Capabilities: [40] Express Endpoint, MSI 00 > Capabilities: [80] Power Management version 3 > Capabilities: [90] Vital Product Data > Capabilities: [a0] MSI: Enable- Count=1/1 Maskable- 64bit+ > Capabilities: [100] Advanced Error Reporting > Capabilities: [200] Virtual Channel > Kernel driver in use: pciback > Has only one IRQ! What is the name of this device? Perhaps I've another one > that > is similar to this. Could you attach Well it's a videograbber .. with also one port for audio (not used) that registers with alsa. I can have a look if i can disable the audio part and see if it makes a difference, i don't use it anyway. > a) 'lspci -vvvv' from your guest please? Attached > b) The the full 'dmesg' from your guest? Attached > c) the /var/log/xen/qemu-dm-XXX ? Hmm, you are using qemu-xen so it won't log > that much information. Could you try 'qemu-traditional' or would that > mess up with XHCI? Attached, it contains some info (since i enabled debugging already) but most about MSI-X and not much about the legacy irq case though ... I don't think traditional will mess up XHCI, it's also worth a try. When looking at the driver /drivers/media/pci/cx25821 it's also clear why it doesn't enable MSI, though the card would support it according to lspci, the drivers lacks support (when i grep for MSI). Also the driver seems to have an parameter to do irq debugging .. no idea how hard that will flood logs, but it's also worth a try :-) cx25821-video.c:47:MODULE_PARM_DESC(irq_debug, "enable debug messages [IRQ handler]"); > In regards to your other question: > Hi Konrad, > Here is the xl dmesg output with this patch (attached with debug-key > i and M > output). What i don't get .. is that d16 and d17 each have a device > passed through > that seems to be using the same pirq 87 ? > Those are per guest. They are the MSI values after 84 or so. Hrrm yes i had found that already :-) All those (legacy) irq, msi, gsi, vector, pirq numbers can be a bit mind boggling .. what corresponds to what where and when. > Back to your crash: > d16 OK-softirq 458msec ago, state:1, 52039 count, [prev:ffff83054ef283e0, > next:ffff83054ef283e0] ffff83051b95fd28MACH_PCI_SHIFT MAPPED_SHIFT > GUEST_PCI_SHIFT PIRQ:0 > d16 OK-raise 489msec ago, state:1, 52049 count, [prev:0000000000200200, > next:0000000000100100] ffff83051b95fd28MACH_PCI_SHIFT MAPPED_SHIFT > GUEST_PCI_SHIFT PIRQ:0 > d16 ERR-poison 561msec ago, state:0, 1 count, [prev:0000000000200200, > next:0000000000100100] ffff83051b95fd28MACH_PCI_SHIFT MAPPED_SHIFT > GUEST_PCI_SHIFT PIRQ:0 > d16 Z-softirq 731msec ago, state:3, 3 count, [prev:ffff83054ef283e0, > next:ffff83054ef283e0] ffff83051b95fd28MACH_PCI_SHIFT MAPPED_SHIFT > GUEST_PCI_SHIFT PIRQ:0 > domain_crash called from io.c:938 > Domain 16 reported crashed by domain 32767 on cpu#5: > All of it point to the legacy interrupt - that is the on that starts at Xen > IRQ 47 (guest IRQ 40): > io.c:550: d16: bind: m_gsi=47 g_gsi=40 dev=00.00.6 intx=0 > IRQ: 47 affinity:02 vec:d1 type=IO-APIC-level status=00000030 in-flight=1 > domain-list=16: +47(P-M), > which looks OK. OK, i still don't get why the output of debug-key 'i' reports +47 as pirq here instead of the guest value (g_gsi of for this legacy interrupt which is 40 ?), like it does when it's a MSI with the PIRQ ? > I am puzzled by the driver binding twice to the same interrupt, but perhaps > that > is just a buggy driver. Doesn't that happen more often like with integrated USB controllers ? 17: 4 0 0 0 0 0 xen-pirq-ioapic-level ehci_hcd:usb1, ehci_hcd:usb2, ehci_hcd:usb3 18: 4385 0 0 0 0 0 xen-pirq-ioapic-level ohci_hcd:usb4, ohci_hcd:usb5, ohci_hcd:usb6, ohci_hcd:usb7 And on host boot (with still some extra printk's): [ 12.773709] xen: registering gsi 18 triggering 0 polarity 1 [ 12.773731] xen: --> pirq=18 -> irq=18 (gsi=18) [ 12.773749] pci 0000:00:12.0: ?!?!? acpi_pci_irq_enable: PCI INT A -> GSI 18 (level, low) -> IRQ/rc 18 [ 12.848820] pci 0000:00:12.2: calling quirk_usb_early_handoff+0x0/0x6f0 [ 12.848942] xen: registering gsi 17 triggering 0 polarity 1 [ 12.848957] xen: --> pirq=17 -> irq=17 (gsi=17) [ 12.848975] pci 0000:00:12.2: ?!?!? acpi_pci_irq_enable: PCI INT B -> GSI 17 (level, low) -> IRQ/rc 17 [ 12.849120] pci 0000:00:13.0: calling quirk_usb_early_handoff+0x0/0x6f0 [ 12.849236] xen: registering gsi 18 triggering 0 polarity 1 [ 12.849240] Already setup the GSI :18 [ 12.849245] pci 0000:00:13.0: ?!?!? acpi_pci_irq_enable: PCI INT A -> GSI 18 (level, low) -> IRQ/rc 18 [ 12.925464] pci 0000:00:13.2: calling quirk_usb_early_handoff+0x0/0x6f0 [ 12.925583] xen: registering gsi 17 triggering 0 polarity 1 [ 12.925589] Already setup the GSI :17 [ 12.925593] pci 0000:00:13.2: ?!?!? acpi_pci_irq_enable: PCI INT B -> GSI 17 (level, low) -> IRQ/rc 17 [ 12.925748] pci 0000:00:14.5: calling quirk_usb_early_handoff+0x0/0x6f0 [ 12.925863] xen: registering gsi 18 triggering 0 polarity 1 [ 12.925868] Already setup the GSI :18 [ 12.925872] pci 0000:00:14.5: ?!?!? acpi_pci_irq_enable: PCI INT C -> GSI 18 (level, low) -> IRQ/rc 18 [ 13.002145] pci 0000:00:16.0: calling quirk_usb_early_handoff+0x0/0x6f0 [ 13.002264] xen: registering gsi 18 triggering 0 polarity 1 [ 13.002269] Already setup the GSI :18 [ 13.002273] pci 0000:00:16.0: ?!?!? acpi_pci_irq_enable: PCI INT A -> GSI 18 (level, low) -> IRQ/rc 18 [ 13.078814] pci 0000:00:16.2: calling quirk_usb_early_handoff+0x0/0x6f0 Attachment:
dmesg-guest.txt Attachment:
lspci-guest.txt Attachment:
qemu-dm-guest.txt _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |