On Wed, Aug 29, 2012 at 12:31:15PM -0400, Alan Stern wrote: > On Wed, 29 Aug 2012, Sebastian Andrzej Siewior wrote: > > > Take g_ncm for instance. It enqueues a few BULK URBs on receive side and > > an INTR URB. > > You mean the host driver enqueues these things, not g_ncm, right? Exactly. > > Now we remove the g_ncm module. This starts with > > usb_gadget_disconnect() which disables the UDC. Now lets say the timer > > expires and dummy_timer() is invoked. It can't find a pair between the > > UDC endpoint and URB's address in find_endpoint() because the > > is_active() is no longer true. So we start a cleanup of URBs. > > The BULK URBs usually don't make a scene. They re-submit the complete > > queue length in BH so we have a little time in between. The INTR URB is > > more evil because usbnet's intr_complete() causes to re-submitt it > > immediately. That means we hardly do any progress and end up in a > > busy loop. > > This sounds like a possible bug in usbnet. If usbnet encounters > repeated failures while trying to communicate with a USB device, it > shouldn't continue to retry indefinitely. It should eventually give > up, and maybe do a device reset. So to interrupt the intr packets we need atleast diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c index 8531c1c..8dc3705 100644 --- a/drivers/net/usb/usbnet.c +++ b/drivers/net/usb/usbnet.c @@ -194,6 +194,7 @@ static void intr_complete (struct urb *urb) /* software-driven interface shutdown */ case -ENOENT: /* urb killed */ case -ESHUTDOWN: /* hardware gone */ + case -EPIPE: netif_dbg(dev, ifdown, dev->net, "intr shutdown, code %d\n", status); return; Oliver, what do you think? > > This patch changes the status code for URBs which can not be assigned to > > an endpoint (because the UDC is in pulldown) are now given back with > > -ESHUTDOWN. The BULK endpoints in ncm are re-submitted in batches of 10 > > in BH but the INTR URB will never be re-submitted. This gives us somes > > air to make some progress and remove the gadget. > > > > An alternative approach would be to not accept any new URBs once the > > port is not active. Something similar is already done on the UDC side. > > I don't see why either of these changes should be needed. dummy-hcd's > current behavior is the same as what you would get if you attached the > gadget to an EHCI controller and then unplugged the cable. When > ehci-hcd can't carry out a transfer because the device doesn't respond, > it returns a -EPROTO error status for the URB. We want dummy-hcd to do > the same thing. > > Similarly, when you unplug a device, ehci-hcd doesn't immediately stop > accepting URBs for that device. We accept new URBs until the hub > driver is notified about the disconnection and the device is > unregistered. > > NAK. Okay. > > Alan Stern Sebastian -- 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
