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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
