On Thursday 13 January 2005 7:01 am, Alan Stern wrote: > On Thu, 13 Jan 2005, Vladimir Trukhin wrote: > > > Well, it seems I've found the source of this problem. > > Today I checked usb traffic on Windows side using SnoopyPro tool > > ... > > But g_file_storage driver always sends only one packet. So all further > > communication on the bus are frozen since Windows has sent the 2nd data > > request untill the timeout occurs. After timeout and the failed response > > from the device Windows sends usb reset. > > Actually g_file_storage does queue two packets. Here's an extract from > your own log: > > <7>g_file_storage gadget: SCSI command: READ FORMAT CAPACITIES; Dc=10, > Di=252; Hc=10, Hi=252 > <7>g_file_storage gadget: bulk-in, length 0: > <7>udc: ep1in-bulk queue req c03d34a0, len 0 buf c03ec000 > <7>udc: wrote ep1in-bulk 0 bytes/L/S 0 left c03d34a0 > > That's the first packet; it has length 0. > > <7>g_file_storage gadget: bulk-in set halt > <7>udc: ep1in-bulk halt > > Then the endpoint is halted.
And wierdness can easily ensue ... especially after writing a zero length packet on that rather quarrelsome hardware. One useful experiment might be disabling the call to halt that endpoint, to see if that makes MS-Windows happier. > <7>g_file_storage gadget: sending command-failure status > <7>g_file_storage gadget: sense data: SK x06, ASC x29, ASCQ x00; info x0 > <7>g_file_storage gadget: bulk-in, length 13: > <7> 0: 55 53 42 53 d0 65 60 81 fc 00 00 00 01 > <7>udc: ep1in-bulk queue req c03d3520, len 13 buf c03f0000 > <7>udc: wrote ep1in-bulk 13 bytes/L/S 0 left c03d3520 > <7>udc: ep2out-bulk queue req c03d34e0, len 64 buf c03ec000 > > That's the second packet (CSW, length 13). But maybe it isn't getting > sent because the endpoint is still halted. Does the pxa2xx driver receive > a CLEAR-HALT request? Windows should send one before asking for the > second bulk-in packet. Maybe the driver isn't clearing the halt and > sending the second queued packet correctly. The USB_CLEAR_FEATURE for ENDPOINT_HALT is handled directly by the PXA 25x hardware ... as a rule, every such bit of automagic on that chip hides some amount of trouble. There were numerous undocumented errata in those areas, on top of a bad design. At this point in time (you said there were about three seconds of delay?) it'd be useful to see what /proc/driver/udc says about what happened to that 13 byte CSW. > > Therefore, I guess, the problem is somewhere in the logic which handles > > "READ FORMAT CAPACITIES" processing in file_storage.c. Especially since > > Linux never sends this command (That's why we have correct work with Linux). > > Tomorrow I'll try to find where it happens and let you know about results. > > No, the processing in g_file_storage is correct. The problem lies in > synchronizing the halt and the clear-halt among the gadget driver, the > udc driver, and the host. And the PXA chip's UDC hardware. I seem to remember having more than one problem with handling endpoint halts on that hardware, including several cases where they weren't properly set or cleared. - Dave ------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
