From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1FV7br-0002rM-SC
	for qemu-devel@nongnu.org; Sun, 16 Apr 2006 09:48:16 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1FV7bq-0002qT-5b
	for qemu-devel@nongnu.org; Sun, 16 Apr 2006 09:48:15 -0400
Received: from [199.232.76.173] (helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1FV7bq-0002qN-14
	for qemu-devel@nongnu.org; Sun, 16 Apr 2006 09:48:14 -0400
Received: from [24.93.47.43] (helo=ms-smtp-04.texas.rr.com)
	by monty-python.gnu.org with esmtp (Exim 4.52) id 1FV7cG-0000j1-VM
	for qemu-devel@nongnu.org; Sun, 16 Apr 2006 09:48:41 -0400
Received: from [192.168.0.11] (cpe-67-9-160-120.austin.res.rr.com
	[67.9.160.120])
	by ms-smtp-04.texas.rr.com (8.13.6/8.13.6) with ESMTP id k3GDmBBi001996
	for <qemu-devel@nongnu.org>; Sun, 16 Apr 2006 08:48:11 -0500 (CDT)
Message-ID: <44424B16.1040300@austin.rr.com>
Date: Sun, 16 Apr 2006 08:48:06 -0500
From: Lonnie Mendez <lmendez19@austin.rr.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [Qemu-devel] [usb][patch] anomaly with windows guests queuing an
	extra TD
Reply-To: qemu-devel@nongnu.org
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: qemu-devel@nongnu.org

  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