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 > http://sourceforge.net/projects/usbsnoop/
Good idea. It always helps to see both sides of a transfer. > It shows that after getting response to "READ FORMAT CAPACITIES" command > Windows host asks for further data from ep1in-bulk. > So, Windows always asks a device to send 2 portions of data in responce > to this SCSI command. It's supposed to do that. The second portion is the CSW. (In fact, Windows is supposed to send 3 bulk-in requests. The second request has to be repeated because it receives a STALL.) > 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. <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. Or maybe the endpoint is getting halted too soon, before the first length-0 packet was sent. That would be just as bad. > Also I checked traffic with an ordinary flash-device. It always sents 2 > portions of data after getting "READ FORMAT CAPACITIES". Like I said, that's supposed to happen. > Unfortunately, SnoopyPro has no ability to convert its log-file to plain > text, so I couldn't insert this logs into the letter. > But if you want, I can send these logs in SnoopyPro's native format. > > > 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. Alan Stern ------------------------------------------------------- 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
