diff mbox

usb_packet_complete: Assertion ... failed

Message ID 4FEC7060.2010304@siemens.com
State New
Headers show

Commit Message

Jan Kiszka June 28, 2012, 2:55 p.m. UTC 
On 2012-06-28 15:33, Jan Kiszka wrote:
> On 2012-06-27 21:58, Erik Rull wrote:
>> Jan Kiszka wrote:
>>> On 2012-06-23 11:29, Erik Rull wrote:
>>>> Jan Kiszka wrote:
>>>>> Hi Gerd,
>>>>>
>>>>> I'm getting
>>>>>
>>>>> qemu/hw/usb/core.c:410: usb_packet_complete: Assertion
>>>>> `((&ep->queue)->tqh_first) == p' failed.
>>>>>
>>>>> with a passed-through USB headset (UHCI controller). This was with
>>>>> current QEMU git head. Known issues? Anything I can do to debug it?
>>>>>
>>>>> Jan
>>>>>
>>>>
>>>> Hi all,
>>>>
>>>> I get this with another USB 1.1 hardware (running via UHCI) as well.
>>>> Some weeks ago it was fine.
>>>> @Jan: If you go back some weeks, this should work (begin of April was
>>>> definitvely ok).
>>>
>>> Interesting, will try to bisect if it's a regression. Don't have the
>>> hardware here, will try next week.
>>>
>>>> How long does it take to get the headset fully detected
>>>> in your guest so that you can use the hardware? My USB 1.1 HW takes ~ 60
>>>> seconds to work, after that everything is fine - during that I see
>>>> several USB resets on the host (dmesg).
>>>
>>> I don't see other problems so far. The device is quickly recognized and
>>> appears to work fine otherwise. But as the assert hit frequently, I was
>>> not able to test in details.
>>>
>>> Thanks,
>>> Jan
>>>
>>
>> Hi Jan,
>>
>> did you do the bisect already? If you have the culprit, I would try the
>> version on my side as well if it fails, too.
> 
> There is no culprit as I can only choose between "assertion" and
> "doesn't work": commit 96dd9aac37d30f3425088f81523942e67b2d03ac
> (usb-host: rewrite usb_linux_update_endp_table) made the Plantronics USB
> headset I'm testing here usable, but it didn't address the reason for
> the assert - or introduced it.

FWIW,


allows me to use the device. Didn't see any other problems so far, but
maybe subtle corruptions are going on now. There are just a few

husb: out of buffers for iso stream

and messages like

husb: 5 iso urbs finished at once

once in a while.

What I also so in the trace is that the USB core apparently stumbled as
a request that took very long too complete finally returned, and then
the assertion triggered over this request.

Jan

Comments

Gerd Hoffmann July 2, 2012, 11:05 a.m. UTC | #1 
Hi,

> What I also so in the trace is that the USB core apparently stumbled as
> a request that took very long too complete finally returned, and then
> the assertion triggered over this request.

Can I get such a trace please?  usb_host_req_* and usb_host_urb_*
enabled should show all interesting information.  Oh, and replacing the
assert which triggers with a tracepoint (or just a fprintf in case you
use the stderr tracer) would be nice, so I can see how qemu continues
after the assert().

A request taking a while shouldn't be a issue.  Requests for a specific
endpoint shouldn't be reordered though, and this seems to happen here.

thanks,
  Gerd
diff mbox

Patch

diff --git a/hw/usb/core.c b/hw/usb/core.c
index 0e02da7..f4e4bbf 100644
--- a/hw/usb/core.c
+++ b/hw/usb/core.c
@@ -407,7 +407,6 @@  void usb_packet_complete(USBDevice *dev, USBPacket *p)
     int ret;

     usb_packet_check_state(p, USB_PACKET_ASYNC);
-    assert(QTAILQ_FIRST(&ep->queue) == p);
     usb_packet_set_state(p, USB_PACKET_COMPLETE);
     QTAILQ_REMOVE(&ep->queue, p, queue);
     dev->port->ops->complete(dev->port, p);