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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
