From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:59915) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T25i9-0006yR-TG for qemu-devel@nongnu.org; Thu, 16 Aug 2012 15:26:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T25i8-0000DM-R0 for qemu-devel@nongnu.org; Thu, 16 Aug 2012 15:26:29 -0400 Received: from mx1.redhat.com ([209.132.183.28]:61054) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T25i8-0000CB-IY for qemu-devel@nongnu.org; Thu, 16 Aug 2012 15:26:28 -0400 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q7GJQRk5016537 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 16 Aug 2012 15:26:27 -0400 Message-ID: <502D4961.3060300@redhat.com> Date: Thu, 16 Aug 2012 21:26:25 +0200 From: Gerd Hoffmann MIME-Version: 1.0 References: <502A78D9.6050003@redhat.com> <502CF9BB.8020107@redhat.com> In-Reply-To: <502CF9BB.8020107@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] 2 issues with qemu-master / 1.2 ehci code List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Hans de Goede Cc: "qemu-devel@nongnu.org" Hi, > Ok, I've managed to significantly narrow this down, this is caused > by ehci_fill_queue() adding packets to the queue with different > qtdaddr values then the first one already queued up, this is of > course more or less fully expected, Yes. > but does trigger the assert in question ... Hmm. ehci_fill_queue() should neither change EHCIQueue->qtdaddr nor EHCIPacket->qtdaddr of the first packet queued up. Also processing the transfer descriptors later on should happen in the same order the EHCIPacket's are queued up, so there should be no mismatch either. I can see how a buggy guest could trigger this assert() by mucking with the TD queue after setting the active flag on the TDs, but I think it is unlikely to be the cause as this behavior violates the ehci specs. > I can get things working by turning ehci_fill_queue() into a nop... > Investigating this further. But if you've any insights they would be > appreciated. I'm thinking this may be caused by packets completing > out of order, which could be caused by the special handling of some > ctrl commands ... usbredir wouldn't see multiple parallel inflight requests per endpoint unless you explicitly enable this using usb_ep_set_pipeline(). Doing that on bulk endpoints should give you a nice performance boost for usb sticks. Doing it on the control endpoint is asking for trouble ;) Can you turn on all ehci tracepoints & send me a log? cheers, Gerd