On Wed, 30 Oct 2013, Pratyush Anand wrote:
> I am using dwc3 driver. I my case kernel version is even a bit old
> 3.3, but dwc3 patches are almost updated. I am using g_mass_storage.
>
> >
> > Why don't you try running an up-to-date kernel, like 3.11, instead?
>
> Yaa, I am trying to upgrade my kernel to 3.12.RC5.
>
> To me, it seems more like a mass storage layer issue rather than
> peripheral layer. I do not have any expertize of mass storage
> internals, so meanwhile I am providing few more inputs, if some expert
> from mass storage can give any advice.
I think you have found a bug in the dwc3 driver.
> Please see attached snapshot of lecroy capture for a failing and
> passing error recovery test. Transfer 10 is a BULK IN transfer, in
> which SBSU Tag, Residue and status is expected. I see that Verbatim
> usb3.0 disk passes here, while Linux g_mass_storage stalls.
>
> I am also providing usbcv log, if that tells something...
>
> INFO Start time: Wed Oct 30 11:54:06 2013
> INFO Configuring device, set configuration = 0x1
> INFO NOTE: It is expected the device has reset the data toggles on all Bulk
> endpoints after the above SetConfiguration call
> INFO Setting device interface, interface number = 0x0 and alternate setting
> = 0x0
> INFO NOTE: It is expected the device has reset the data toggles on all Bulk
> endpoints after the above SetInterface call
> INFO Issuing Get Max LUN request
> INFO Max LUN value = 0
> INFO Issue CBW with invalid signature
At this point, the IGNORE_BULK_OUT bit in g_mass_storage gets set:
/*
* The Bulk-only spec says we MUST stall the IN endpoint
* (6.6.1), so it's unavoidable. It also says we must
* retain this state until the next reset, but there's
* no way to tell the controller driver it should ignore
* Clear-Feature(HALT) requests.
*
* We aren't required to halt the OUT endpoint; instead
* we can simply accept and discard any data received
* until the next reset.
*/
wedge_bulk_in_endpoint(fsg);
set_bit(IGNORE_BULK_OUT, &fsg->atomic_bitflags);
> INFO Issuing invalid CBW
> INFO CBW successful
> INFO Issuing CSW 2 times, CSW should stall in every case
> INFO Issuing CSW 1
> INFO Issuing CSW 2
> INFO Retrieving status on CSW endpoint
> INFO CSW endpoint status = 0x1
> INFO CSW endpoint stalled
> INFO Clearing stalled CSW endpoint
> INFO Issuing CSW 2 times, CSW should stall in every case
> INFO Issuing CSW 1
> INFO Issuing CSW 2
> INFO Issuing CBW 2 times, CBW should either stall or return success
> INFO Issuing CBW 1
> INFO CBW successful
> INFO Issuing BOT MSC Reset, reset should always succeed
At this point, because the IGNORE_BULK_OUT bit is set, g_mass_storage
issues a usb_ep_clear_halt() call for the bulk-in (CSW) endpoint.
This tells the dwc3 driver to change the endpoint's status back to 0:
if (test_and_clear_bit(IGNORE_BULK_OUT,
&common->fsg->atomic_bitflags))
usb_ep_clear_halt(common->fsg->bulk_in);
> INFO Retrieving status on CBW endpoint
> INFO CBW endpoint status = 0x0
> INFO Retrieving status on CSW endpoint
> INFO CSW endpoint status = 0x1
But the status is still set to 1. Clearly this is a bug in dwc3.
> ERROR CSW endpoint status returned STALL after BOT MSC Reset
>
> FAIL (5.5.4) The device must support the Bulk-Only Mass Storage Reset.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
