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

[Gerd Hoffmann <kraxel@redhat.com>]

On 08/15/12 13:22, Hans de Goede wrote:
> Hi,
> 
> On 08/14/2012 06:12 PM, Hans de Goede wrote:
>> Hi,
>>
>> While testing qemu-master I've encountered 2 problems caused by the
>> ehci changes
>> made since 1.1:
>>
>> 1) Newly plugged in devices don't get recognized by the guest
>> This seems to be a case of no interrupt getting generated while it
>> should, doing lsusb in a linux
>> guest makes the device show up (after the lsusb, so its there in a
>> second lsusb run)
> 
> I've been looking into this one and I think I know what is going on, the
> problem is caused by
> the "ehci: implement Interrupt Threshold Control support" patch:
> http://www.kraxel.org/cgit/qemu/commit/?h=usb.57&id=7efc17af9a08839a05771541959696875e06cf99
> 
> 
> What happens is that since neither the async, nor the periodic schedule
> are enabled the
> frame-timer is not running, and during the attaching of the device the
> Port Change Events
> (PCD) status bit should get raised multiple times due to port resets,
> etc. But after the
> first call to commit_irq, usbsts_frindex contains frindex + 1 (in case
> of a linux guest),
> so commit_irq turns into a nop and the guest never sees any of the PCD
> interrupts other then
> the first.
> 
> Part of the problem is that the Interrupt Threshold Control support
> patch delays all
> interrupts, which it should not, according to the EHCI spec section 4.15
> (ehci-r10.pdf
> page 115), the following irqs should not be delayed: Port Change Events
> (PCD),
> Frame List Rollover (FLR), and Host System Error (HSE). So we need to
> change the code
> to not delay these. Once that is done I expect the attach problem I've
> been seeing
> to magically go away.

Makes sense.

>> 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.

Could be QH revalidation not being careful enougth (see commit
9bc3a3a216e2689bfcdd36c3e079333bbdbf3ba0)

> I've not made any progress with this one yet. kraxel, any chance you
> could join #spice
> on gimpnet so we can discuss this one interactively ?

Busy debugging ehci live migration issues and I'd prefer to finish that
first.

cheers,
  Gerd