Thanks a lot Alan for your help. On Wed, Oct 30, 2013 at 9:38 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > > 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. Yes, I had concluded the same at the end of the day. Hopefully, will have solution tomorrow. Regards Pratyush > > > 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 majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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
