qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] 2 issues with qemu-master / 1.2 ehci code


From: Gerd Hoffmann
Subject: Re: [Qemu-devel] 2 issues with qemu-master / 1.2 ehci code
Date: Thu, 16 Aug 2012 21:26:25 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.6esrpre) Gecko/20120714 Thunderbird/10.0.6

  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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]