Re: [Qemu-devel] EHCI USB regression in 1.2.0 - ehci_state_fetchqtd() asserting

[Johannes Stezenbach <js@sig21.net>]

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