On Mon, Sep 3, 2012 at 4:26 PM, Bjørn Mork <bj...@mork.no> wrote: > Suspending an open usbnet device results in constant > rescheduling of usbnet_bh. > > commit 65841fd5 "usbnet: handle remote wakeup asap" > refactored the usbnet_bh code to allow sharing the > urb allocate and submit code with usbnet_resume. In > this process, a test for, and immediate return on, > ENOLINK from rx_submit was unintentionally dropped. > > The rx queue will not grow if rx_submit fails, > making usbnet_bh reschedule itself. This results > in a softirq storm if the error is persistent. > rx_submit translates the usb_submit_urb error > EHOSTUNREACH into ENOLINK, so this is an expected > and persistent error for a suspended device. The > old code tested for this condition and avoided > rescheduling. Putting this test back. > > Cc: <sta...@vger.kernel.org> # v3.5 > Cc: Ming Lei <ming....@canonical.com> > Cc: Oliver Neukum <oneu...@suse.de> > Signed-off-by: Bjørn Mork <bj...@mork.no> > --- > Sorry for not noticing this before, but commit 65841fd5 > makes usbnet autosuspend completely unusable. The device > is suspended fine, but burning one CPU core at full load > uses a tiny bit more power making the power saving > negative...
I am wondering how you can reproduce the issue. usbnet_terminate_urbs is called inside usbnet_suspend to consume all URBs and SKBs, and rx_alloc_submit can't be called during the period because of !netif_device_present(). Once usbnet_terminate_urbs and netif_device_attach() are completed, who will schedule tasklet to trigger rx_alloc_submit? > > I hope this can go into 3.6 and 3.5-stable ASAP. It is > a hard to notice regression, but all the same a serious > one. Thanks, -- Ming Lei -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
