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). Sarah, Do you plan to add this support in XHCI driver? > >> 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. Yes, I meant the same. > >> 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. Aborting URBs from within HCD after device disconnect is appropriate. right? Ajay > >> >> 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
