On Thu, 13 Sep 2012, Ajay Gupta wrote: > Hi Sarah > > On Thu, Sep 13, 2012 at 2:37 AM, Sarah Sharp > <sarah.a.sharp@xxxxxxxxxxxxxxx> wrote: > > On Wed, Sep 12, 2012 at 03:36:39PM +0530, Ajay Gupta wrote: > >> Hi, > >> > >> I am using v3.5 kernel and running a test where I disconnect a SS MSC > >> device while a big file is being written to it. I am also watching the > >> lsusb output in parallel. Expectation is that SS MSC device should > >> immediately disappear from lsusb output but sometime I see that SS MSC > >> is listed for 30 seconds and then only disappears. Log is copied > >> below. > >> > >> Looking further into the issue shows that in failing case an URB is > >> not given back by XHCI driver and so SCSI layer unlinks it after > >> 30second of timeout. This URB was actually given to XHCI host > >> controller and a disconnect happens while packet transfer was in > >> progress. I looked at XHCI driver and could not find request being > >> aborted by driver (in xhci_free_dev() fn) before issuing disable slot > >> or reset device command. What is expectation in this scenario? > > > > The expectation is that the mass storage driver should have aborted any > > URBs in its disconnect function before xhci_free_dev() is called. I > > believe all USB drivers are required to do this. If that assumption > > isn't true, then, yes, I need to revisit any place that xHCI rings get > > freed. It's not that simple. > I think your assumption is correct and same has been discussed by Alan at > http://marc.info/?l=linux-usb&m=134382746009339&w=2could As discussed in that thread, the real requirement is that the host controller should complete URBs with an error if the device has disconnected (and therefore isn't sending any handshake packets). > Alan suggested to add logic inside host controller driver to unlink > all URBs at disconnect. No, that's not what I suggested. I said that transfers should be aborted when the controller hardware detects that the device fails to send handshake packets. > This is required as either SCSI or storage layer doesn't know if > device is unplugged or > unbounded. > > Another solution could be to add some kind of flag notifying to SCSI > layer of device > disconnect or unbound and so SCSI layer shouldn't wait for 30 seconds if it's > disconnect. Both of those solutions are inappropriate. > >> Is it > >> XHCI driver responsibility to abort and giveback all the request (as > >> in EHCI using endpoint_disable()) > >> Why XHCI > >> driver doesn't have an endpoint_disable() implemented as done for > >> other controller? > > > > The xHCI driver just works differently than EHCI. It's not a > > requirement to implement the endpoint disable function, AFAIK. From > > what I remember, the endpoint disable function was supposed to be used > > before switching alternate interface settings, but it was called too > > late to be of much use to the xHCI bandwidth functions. So I created > > new bandwidth functions and ignored the endpoint disable functions. > > Maybe Alan can explain what the requirements about the endpoint disable > > function are? THe endpoint_disable function doesn't have to do anything as far as usbcore is concerned. It is a callback; it gives the HCD a chance to deallocate any internal data structures associated with the endpoint. When endpoint_disable is called there shouldn't be any URBs queued for the endpoint. The core guarantees this by preventing new URBs from being accepted, unlinking all existing URBs, and then waiting for them to complete. > endpoint_disbale is also called from usbcore layer in disconnect path. > > > > >> OR host controller hardware should > >> abort and post an error completion event for each request? > > > > If the host controller hardware was in the middle of a transfer when the > > device was disconnected, and that caused the transfer to timeout, then, > > yes, the host should return an event with a transfer error and halt the > > event ring, as described in the xHCI 1.0 spec, section 4.10.2.3. Even > > if the host wasn't strictly speaking in the middle of a transfer during > > the disconnect, the endpoint ring should remain on the host's schedule > > as long as the xHCI driver didn't issue a stop endpoint command. I > > would expect that the transfer would timeout the next time it was > > executed from the schedule. If by "timeout" you mean fail under the "3 strikes" rule, then yes, this is what should happen. 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
