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? Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
