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

[Johannes Stezenbach]

Hi Hans,

On Mon, Oct 08, 2012 at 01:27:28PM +0200, Hans de Goede wrote:
> On 10/02/2012 05:26 PM, Shawn Starr wrote:
> >
> >Reopening this issue with usb-host stalling now
> >
> >ehci warning: guest updated active QH
> >USBDEVFS_DISCARDURB: Invalid argument
> >USBDEVFS_DISCARDURB: Invalid argument
> >husb: leaking iso urbs because of discard failure
> >
> >
> >Now with qemu-XXX-1.2.0-12.fc18.x86_64
> >
> >if I have webcam open, it will stall and not resume. This is with usb-host
> >directly.
> >
> >Shall I enable debugging again?
> 
> Hmm, this likely is caused by too high latencies in your system,
> which are caused in turn I believe by you running an F-18 kernel which
> has various debugging options enabled inside the kernel which can
> cause significant latencies. I've spend 1.5 days tracing this very
> same issue down in the past. So please first of all make sure that you're
> running a kernel without debugging options enabled, either the latest
> F-18 build from koji:
> http://koji.fedoraproject.org/koji/buildinfo?buildID=358570
> 
> or an F-17 kernel, almost all the F-18 "rc" kernels have debugging enabled
> and thus cause significant latency issues.
> 
> If you can reproduce this with a kernel without the debugging options,
> then we can investigate this further.

By changing the kernel, don't you just make the issue harder to reproduce?
I mean Linux isn't real-time so any kernel can show latency spikes
and it's a show-stopper if iso transfers stall instead of just
dropping some packets.

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?


Johannes