From patchwork Thu Jun 28 14:55:28 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jan Kiszka X-Patchwork-Id: 167893 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id 311BDB6FF5 for ; Fri, 29 Jun 2012 00:55:57 +1000 (EST) Received: from localhost ([::1]:57522 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SkG8Q-0007gw-Ee for incoming@patchwork.ozlabs.org; Thu, 28 Jun 2012 10:55:54 -0400 Received: from eggs.gnu.org ([208.118.235.92]:43186) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SkG8E-0007gO-LM for qemu-devel@nongnu.org; Thu, 28 Jun 2012 10:55:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SkG85-0007tV-MG for qemu-devel@nongnu.org; Thu, 28 Jun 2012 10:55:42 -0400 Received: from thoth.sbs.de ([192.35.17.2]:19631) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SkG85-0007p6-CT for qemu-devel@nongnu.org; Thu, 28 Jun 2012 10:55:33 -0400 Received: from mail1.siemens.de (localhost [127.0.0.1]) by thoth.sbs.de (8.13.6/8.13.6) with ESMTP id q5SEtStf027032; Thu, 28 Jun 2012 16:55:29 +0200 Received: from mchn199C.mchp.siemens.de ([139.25.109.49]) by mail1.siemens.de (8.13.6/8.13.6) with ESMTP id q5SEtSKp016975; Thu, 28 Jun 2012 16:55:28 +0200 Message-ID: <4FEC7060.2010304@siemens.com> Date: Thu, 28 Jun 2012 16:55:28 +0200 From: Jan Kiszka User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Erik Rull References: <4FE4953F.50404@siemens.com> <4FE58C97.5050606@rdsoftware.de> <4FE58F2D.1010307@web.de> <4FEB65E5.1060908@rdsoftware.de> <4FEC5D1B.6040307@siemens.com> In-Reply-To: <4FEC5D1B.6040307@siemens.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) X-Received-From: 192.35.17.2 Cc: Gerd Hoffmann , qemu-devel Subject: Re: [Qemu-devel] usb_packet_complete: Assertion ... failed X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org Sender: qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org 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 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);