>>> On 25.06.15 at 12:51, <li...@eikelenboom.it> wrote: > Attached is the xl-dmesg output of: > > - debug-keys M and i before guest boot > - guest boot > - debug-keys M and i after lsusb in the guest that hangs.
Interesting: (XEN) [2015-06-25 10:46:31.820] MSI-X 84 vec=aa lowest edge assert log lowest dest=00000002 mask=1/ G/1 (XEN) [2015-06-25 10:46:31.820] MSI-X 85 vec=b2 lowest edge assert log lowest dest=00000002 mask=1/ G/1 (XEN) [2015-06-25 10:46:31.820] MSI-X 86 vec=ba lowest edge assert log lowest dest=00000002 mask=1/ G/1 (XEN) [2015-06-25 10:46:31.820] MSI-X 87 vec=c2 lowest edge assert log lowest dest=00000002 mask=1/ G/1 (XEN) [2015-06-25 10:46:31.820] MSI-X 88 vec=ca lowest edge assert log lowest dest=00000002 mask=1/ G/1 I.e. they didn't get unmasked by the guest. Is that with one of our two qemu-s, or some other version? I'd be curious what the guest view of the MSI-X table entries is at that point. Can you still use the console inside the guest? If so, sufficiently verbose lspci of the device should be able to tell us (hoping that this isn't a Windows guest), or a dd of /dev/mem at the right offset. Perhaps there are also way to get at that from qemu, but I do not know how. If none of this works or provides enough insight, I guess we'd have to instrument msixtbl_write() to monitor guest writes to the mask bit. (After all that's the only place the guest_masked bit gets driven from right now.) > The not working controller is 0000:08:00.0. That information would have been useful only together with P output, but since there were no MSI-X entries before the guest started, it was pretty clear that all of them belong to the device(s) handed to it. Btw., are (XEN) [2015-06-25 10:44:26.550] traps.c:3227: GPF (0000): ffff82d0801d8282 -> ffff82d080239eec (XEN) [2015-06-25 10:44:26.550] traps.c:3227: GPF (0000): ffff82d0801d8282 -> ffff82d080239eec (XEN) [2015-06-25 10:44:26.550] traps.c:3227: GPF (0000): ffff82d0801d8282 -> ffff82d080239eec (XEN) [2015-06-25 10:44:26.550] traps.c:3227: GPF (0000): ffff82d0801d8282 -> ffff82d080239eec new? Did you ever try to figure out what they're being caused by? Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
