From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KwMfr-0000DH-D5 for qemu-devel@nongnu.org; Sat, 01 Nov 2008 16:02:19 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KwMfn-0000Cz-SW for qemu-devel@nongnu.org; Sat, 01 Nov 2008 16:02:18 -0400 Received: from [199.232.76.173] (port=36004 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KwMfn-0000Ct-O6 for qemu-devel@nongnu.org; Sat, 01 Nov 2008 16:02:15 -0400 Received: from hera.kernel.org ([140.211.167.34]:46936) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KwMfn-0004fu-6Y for qemu-devel@nongnu.org; Sat, 01 Nov 2008 16:02:15 -0400 Message-ID: <490CB5A6.8020203@kernel.org> Date: Sat, 01 Nov 2008 13:01:42 -0700 From: Max Krasnyansky MIME-Version: 1.0 Subject: Re: [Qemu-devel] Preliminary patch to implement ehci References: <11d301c93090$7e06d290$7a1477b0$@com> <010f01c93810$47ccb500$d7661f00$@com> <4905C997.5060801@codemonkey.ws> <01d701c93aae$af7487a0$0e5d96e0$@com> <4909EC32.1090504@codemonkey.ws> <490B7095.8030105@kernel.org> In-Reply-To: <490B7095.8030105@kernel.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: qemu-devel@nongnu.org Max Krasnyansky wrote: > Anthony Liguori wrote: >> Mark Burkley wrote: >>> Hi Anthony, >>> >>> I have ehci built against trunk now but I am seeing an issue with a >>> memory key I am using for testing. ioctl returns EPIPE (which I >>> would have thought was a STALL) to an asynchronous IN completion in >>> usb-linux.c but then this is returned as USB_RET_NAK to EHCI which >>> confuses my WinXP target because the transfer is then never >>> completed. >>> >>> Can I just check that it was intentional to return NAK for EPIPE >>> returns in asynchronous completions? If so, then I will try to >>> detect the stall in my implementation and treat differently to a >>> NAK. It's just that if I modify usb-linux.c to return >>> USB_RET_STALL on -EPIPE then it works fine. > > I just looked at the usb-linuc.c:async_complete() code and it looks like > it was intentional but I cannot remember why I wrote that way. And what > you're saying makes sense. ie It should be a STALL. In fact I think that > might fix the regression with USB storage devices that some people have > reported. > I'll play some more with this later today. I want to make sure that the > change we're talking about does not break existing devices that I > thoroughly tested as part of the usb async re-write. If everything works > as expected then we'll change it. Ok. I just tested that change (ie returning STALL instead of NAK on EPIPE) with a bunch of devices: USB serial adapter, CF card reader, USB webcam (MS VX-3000) and MS USB mouse. All that stuff was hooked up to XP-SP3 and all of them are perfectly usable at the same time. In other words here is my ACK :) I'll take a look and play with the EHCI patch later today. Thanx Max