On 08/15/12 13:22, Hans de Goede wrote: > Hi, > > On 08/14/2012 06:12 PM, Hans de Goede wrote: >> Hi, >> >> While testing qemu-master I've encountered 2 problems caused by the >> ehci changes >> made since 1.1: >> >> 1) Newly plugged in devices don't get recognized by the guest >> This seems to be a case of no interrupt getting generated while it >> should, doing lsusb in a linux >> guest makes the device show up (after the lsusb, so its there in a >> second lsusb run) > > I've been looking into this one and I think I know what is going on, the > problem is caused by > the "ehci: implement Interrupt Threshold Control support" patch: > http://www.kraxel.org/cgit/qemu/commit/?h=usb.57&id=7efc17af9a08839a05771541959696875e06cf99 > > > What happens is that since neither the async, nor the periodic schedule > are enabled the > frame-timer is not running, and during the attaching of the device the > Port Change Events > (PCD) status bit should get raised multiple times due to port resets, > etc. But after the > first call to commit_irq, usbsts_frindex contains frindex + 1 (in case > of a linux guest), > so commit_irq turns into a nop and the guest never sees any of the PCD > interrupts other then > the first. > > Part of the problem is that the Interrupt Threshold Control support > patch delays all > interrupts, which it should not, according to the EHCI spec section 4.15 > (ehci-r10.pdf > page 115), the following irqs should not be delayed: Port Change Events > (PCD), > Frame List Rollover (FLR), and Host System Error (HSE). So we need to > change the code > to not delay these. Once that is done I expect the attach problem I've > been seeing > to magically go away.
Makes sense. >> 2) I'm hitting: >> qemu-system-x86_64: /home/hans/projects/qemu/hw/usb/hcd-ehci.c:2075: >> ehci_state_executing: Assertion `p->qtdaddr == q->qtdaddr' failed. >> When trying to redirect a microsoft lifecam, since this is a device >> with multiple interfaces >> (both uvc and usb-audio) I think it may be a case of multiple control >> requests getting submitted at the same time, >> but that is just a wild guess. Could be QH revalidation not being careful enougth (see commit 9bc3a3a216e2689bfcdd36c3e079333bbdbf3ba0) > I've not made any progress with this one yet. kraxel, any chance you > could join #spice > on gimpnet so we can discuss this one interactively ? Busy debugging ehci live migration issues and I'd prefer to finish that first. cheers, Gerd
