Hi, On Mon, Oct 08, 2012 at 03:51:08PM +0200, Hans de Goede wrote: > On 10/08/2012 03:01 PM, Johannes Stezenbach wrote: > > > >There will always be a race between the call to USBDEVFS_DISCARDURB > >and the URB completing. IMHO the handling in usb_host_stop_n_free_iso() > >is buggy. How about dropping the "killed" and "free" variables and > >calling async_complete() and g_free() unconditionally? > > This race is well known already handled correctly,
You mean the message about "leaking iso urbs" is wrong? (since it will be freed later in async_completem right?) > the real problem is the > "ehci warning: guest updated active QH" message, which most likely indicates > that the guest has hit the doorbell (IAAD) in the EHCI controller, and then > has not gotten an IAA interrupt within > a certain amount of time triggering its IAAD watchdog (some real EHCI > hardware is broken wrt delivering IAA interrupt) causing us to not see > an unlinked qh as unlinked, and then later on triggering the > "warning: guest updated active QH" message. > > This is unavoidable when we get too large latencies, the ehci hardware > simple was not designed to be virtualized, anything but actually. OK, thanks for this explanation. I haven't much clue about qemu but isn't the issue that qemu delivers timer irqs to the guest (for EHCI_HRTIMER_IAA_WATCHDOG) while failing to handle the IAAD -> IAA interrupt generation? (via qemu_bh_schedule -> ehci_advance_async_state -> ehci_raise_irq, why does ehci_raise_irq() not call ehci_update_irq() for USBSTS_IAA?) If that cannot be fixed, have you tried talking to the Linux EHCI driver maintainer if the EHCI_HRTIMER_IAA_WATCHDOG timeout (10ms) can be increased or skipped entirely for non-broken hw? (Linux commit 26f953fd884ea4879 suggests it's only for VIA chips) Thanks, Johannes