[Top][All Lists]

[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: Hans de Goede
Subject: Re: [Qemu-devel] 2 issues with qemu-master / 1.2 ehci code
Date: Wed, 15 Aug 2012 13:22:42 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120717 Thunderbird/14.0


On 08/14/2012 06:12 PM, Hans de Goede wrote:

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 

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:

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 
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 
to magically go away.

I'll go work on a patch for this after lunch.

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.

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

(note I'm of to lunch for an hour first)



reply via email to

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