Re: g_mass_storage bug ?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux