Hello list. I've noticed something odd going on with Windows guests
in that they will queue up and extra IN TD on a setup packet having a 32
byte data stage. So far I've seen this happen twice. Here is one
occurance:
frame 41: pid=SETUP addr=0x02 ep=0 len=8
data_out= 80 06 00 02 00 00 ff 00
ret=32
frame 42: pid=IN addr=0x02 ep=0 len=8
ret=8 data_in= 09 02 20 00 01 01 00 c0
frame 43: pid=IN addr=0x02 ep=0 len=8
ret=8 data_in= 01 09 04 00 00 02 00 00
frame 44: pid=IN addr=0x02 ep=0 len=8
ret=8 data_in= 00 00 07 05 81 03 08 00
frame 45: pid=IN addr=0x02 ep=0 len=8
ret=8 data_in= 0a 07 05 02 03 08 00 0a
frame 46: pid=IN addr=0x02 ep=0 len=8
ret=-3
A test case device that allows anyone to see the bug in action is
linked here:
http://gnome.dnsalias.net/patches/qemu-x10dev-bugged.diff (usb_add mysdev)
Here is a kind of workaround for this linked below. In the
setup_state SETUP_STATE_ACK if the packet has direction IN then it will
change setup state back to SETUP_STATE_ACK to wait for the further
queued OUT TD (ACK) and then return an appropriate value to the uhci
emulation so that it can handle the condition. At present it marks the
TD inactive and invalidates the frame. Setting an error condition
results in transfer failure and letting the frame continue without frame
invalidation results in the TD being queued several more times until the
hcd gives up and sends the OUT TD.
http://gnome.dnsalias.net/patches/qemu-usbquirk-wildtd.patch
_______________________________________________
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel