Hi, On Wed, Sep 24, 2014 at 11:05:58AM -0400, Alan Stern wrote: > On Tue, 23 Sep 2014, Felipe Balbi wrote: > > > Hi Alan, > > > > Need your help looking over this detail here. When I run g_mass_storage > > with stall=0 everything works fine. As soon as I remove it, things go > > bonkers. > > > > Looking at the bulk-only spec, I see: > > > > "6.7.2 Hi - Host expects to receive data from the device > > > > [ ... ] > > > > The specific device requirements are: > > > > 1. The device shall receive a CBW. > > 2. When the CBW is valid and meaningful, then: > > . The device shall attempt the command. > > . [Case (6)] > > If the device intends to send dCBWDataTransferLength, then: > > The device shall send dCBWDataTransferLength bytes of > > data. > > > > The device shall set bCSWStatus to 00h or 01h. > > > > The device shall set dCSWDataResidue to zero. > > " > > > > Case (6) is when Hi == Di, looking at my logs, I have: > > > > 720 [ 286.843965] SCSI CDB: 1a 00 3f 00 c0 00 > > 721 [ 286.844000] g_mass_storage gadget: SCSI command: MODE SENSE(6); Dc=6, Di=192; Hc=6, Hi=192 > > 722 [ 286.844018] g_mass_storage gadget: bulk-in set halt > > 723 [ 286.844034] g_mass_storage gadget: sending command-failure status > > 724 [ 286.844045] g_mass_storage gadget: sense data: SK x06, ASC x29, ASCQ x00; info x0 > > > > Isn't it wrong to halt in this condition ? > > No, it's correct. SK = 6 and ASC = 0x29 means Unit Attention, Reset > Occurred. It occurs because this is the first command the gadget has > received since starting up, which certainly is a form of reset. In > effect, this is how the device tells the host that it was just powered > on. > > So the case you should be looking at is Case 5: Hi > Di. I realize the > debugging output indicates Di = 192, but that line gets written before > the driver checks for a Unit Attention condition. (The line is written > near the start of check_command() in f_mass_storage.c, and the Unit > Attention check is near the end of the same function.) The printed Di > value indicates how much data the gadget thinks the command is asking > for, not the amount of data the gadget actually intends to send. > > Therefore stalling is appropriate. Why it causes it problem for your > system is a different matter. Is your UDC hardware capable of halting > bulk endpoints? yeah, that part is just fine; I also verified with my sniffer that bulk halt is happening as it should. The problem, however, is that after that halt condition happens, host (same board has xhci too, Linux 3.17-rc5) issues a reset recovery and it all happens again. I stay in that loop for a while until it finally enumerates correctly, but when I try to write to the block device with dd, it resets again. I'll try the same test against my desktop (3.16.1) and a Mac OS X I have here, and see if the same behavior shows up. -- balbi
Attachment:
signature.asc
Description: Digital signature
