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,
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);
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
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
