From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:48773) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T20OK-0005lG-8a for qemu-devel@nongnu.org; Thu, 16 Aug 2012 09:45:41 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T20OE-0003gG-VH for qemu-devel@nongnu.org; Thu, 16 Aug 2012 09:45:40 -0400 Received: from mx1.redhat.com ([209.132.183.28]:8262) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T20OE-0003g0-N0 for qemu-devel@nongnu.org; Thu, 16 Aug 2012 09:45:34 -0400 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q7GDjWhQ004012 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 16 Aug 2012 09:45:32 -0400 Message-ID: <502CF9BB.8020107@redhat.com> Date: Thu, 16 Aug 2012 15:46:35 +0200 From: Hans de Goede MIME-Version: 1.0 References: <502A78D9.6050003@redhat.com> In-Reply-To: <502A78D9.6050003@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: Gerd Hoffmann Cc: "qemu-devel@nongnu.org" Hi, On 08/14/2012 06:12 PM, Hans de Goede wrote: > Hi, > > 2) I'm hitting: > qemu-system-x86_64: /home/hans/projects/qemu/hw/usb/hcd-ehci.c:2075: ehci_state_executing: Assertion `p->qtdaddr == q->qtdaddr' failed. > When trying to redirect a microsoft lifecam, since this is a device with multiple interfaces > (both uvc and usb-audio) I think it may be a case of multiple control requests getting submitted at the same time, > but that is just a wild guess. > > Some gdb output: > > (gdb) fr 4 > #4 0x00005555556c33ce in ehci_state_executing (q=0x5555566c9590) > at /home/hans/projects/qemu/hw/usb/hcd-ehci.c:2075 > 2075 assert(p->qtdaddr == q->qtdaddr); > (gdb) p q > $1 = (EHCIQueue *) 0x5555566c9590 > (gdb) p *q > $2 = {ehci = 0x5555566e58b0, next = {tqe_next = 0x5555566c23e0, tqe_prev = > 0x5555566e7188}, seen = 1, ts = 500707440673, async = 1, revalidate = 0, > qh = {next = 915959810, epchar = 1077960706, epcap = 1073741824, > current_qtd = 915964192, next_qtd = 915964384, altnext_qtd = 1, token = > 2147483720, bufptr = {865509240, 0, 0, 0, 0}}, qhaddr = 915959906, > qtdaddr = 915964192, dev = 0x555556710e10, packets = {tqh_first = > 0x55555676a440, tqh_last = 0x55555676aca8}} > (gdb) p *p > $3 = {queue = 0x5555566c9590, next = {tqe_next = 0x55555676aca0, tqe_prev = > 0x5555566c9600}, qtd = {next = 915964288, altnext = 1, token = 2147683712, > bufptr = {865509232, 0, 0, 0, 0}}, qtdaddr = 915964480, packet = {pid = > 105, ep = 0x555556711f08, iov = {iov = 0x55555676a960, niov = 1, nalloc = > 1, size = 3}, parameter = 0, result = -3, state = USB_PACKET_COMPLETE, > queue = {tqe_next = 0x55555676ace0, tqe_prev = 0x555556711f20}}, sgl = { > sg = 0x555556769940, nsg = 1, nalloc = 5, size = 3, dma = 0x0}, pid = 105, > tbytes = 3, async = EHCI_ASYNC_FINISHED, usb_status = -3} 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, but does trigger the assert in question ... 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 ... Regards, Hans