Hi,
On 08/14/2012 06:12 PM, Hans de Goede wrote:
Hi,
<snip>
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
