On 03.02.2024 21:06, BALATON Zoltan wrote:
It's hard to tell, I don't know EHCI but there's a TODO comment near that error so maybe there's some EHCI feature not emulated that you may need to implement in QEMU there. I guess you'd need to check the EHCI specification or the docs of the actual chip that is emulated for info on how this should work.
I'll have a look at it. Meanwhile I've added dedicated debug output and found out, that the 17th ITD only occurs occasionally. Could it be the 16 ITD limit has been arbitrarily chosen? The host machine is not particularly powerful so that buffers might fill up to a higher level than usually expected.
Also to get more debugging info to see what's happening you can add --trace enable="usb*" (or see qemu/hw/usb/trace-events for the list of trace points available that could be enabled individually) in case you were not aware of that.
Thanks for the hint. I indeed didn't know that. The audio hardware, however, is particularly time sensitive during initialization and requires a power cycle if anything appears strange to it. But I'll have a try! The refcount warning is triggered by inconsistent data structures in the EHCI driver of the Linux kernel: while the 'periodic' array encodes a structure type of 'ehci_qh' the pointer in the 'pshadow' array actually points to a structure of type 'ehci_itd'. My hunch is I'm running into a kernel race condition due to massively skewed timing conditions compared with the original bare metal hardware (where the kernel runs just fine). Christian
