On Sat, Oct 2, 2021 at 5:42 PM BALATON Zoltan <balaton@eik.bme.hu> wrote:
I'm also not sure where's the problem (maybe we have multiple problems).
It also does not work with an emulated usb-audio device but that also
doesn't work with EHCI so it may have a problem by itself (UHCI also seems
to be broken on its own so it does not even work as much as OHCI and
EHCI). You've also said it worked with pass through with a different
device so maybe this only happens with some devices or some sequence of
things these devices are doing. Only allowing one async packet in OHCI
instead of allowing one per endpoint is just a guess that could cause
delays in processing other packets but eventually it should go through
unless one async packet never completes and blocks all later ones or the
delays introduced by this limitaion causes things to go in a way that
guests don't expect and thus fail.
After some sifting through the logs, I my interpretation of our issue is
this:
Too many pending is referring to endpoint 0 when something is not
completed. Qemu permantly checks endpoint 4 for hid activity, skips when no
interrupt occurs. You can see both intermittently in the 1st log below.
Too many pending refers to qemu not being able to fully read/get the device
descriptors from boot. The too many pending is "solved", with a click on a
hid button. That leads to async complete, after which the only activity is
to check for interrupts from the hid devices.
However, as the descriptors from endpoint 0 are not fully read from boot,
endpoint 1 (the actual audio stream) is not available.
Unplugging/plugging the usb device in combination with some hid interrupts
(me pushing the volume button) can sometimes reload the configuration
correctly, so endpoint 1 becomes available and sound can be played through
it.