On 02/12/13 15:38, Jan Kiszka wrote: > Hi, > > was just debugging a memory corruption of my USB driver inside QEMU - > and so far only there: > > I have a queue registered with the UHCI controller on an input endpoint > that continuously generates data. At some point my driver decides to > stop reading and removes the QH (with a lot of TDs attached) from the > schedule. The driver waits for the next frame, then releases the QH and > its TDs. > > QEMU apparently takes a "few" more frames to consider this queue dead. > In the meantime, it seems to happily fill the TD buffers with data. But > those buffers are long returned to the guest pool of free memory, > causing corruptions there.
Try setting QH_VALID to 1. That should fix it, but has a high chance to break iso transfers. I guess we'll need different QH_VALID values depending on transfer type. Hans? Agree? > I'm wondering now if I'm (again) using the UHCI in an unorthodox way (at > least I stopped doing multi-queues per endpoint), still must have a > subtle bug in the guest, or if this is a fundamental problem of QEMU's > UHCI model. Unorthodox probably as this didn't pop up before with any other guest. But I think uhci emulation is at fault this time. How to you wait for the next frame? I hope using the frame number register? I guess this is with usb-host? cheers, Gerd
