Ming Lei <ming.lei@xxxxxxxxxxxxx> writes:
> On Mon, Sep 3, 2012 at 4:26 PM, Bjørn Mork <bjorn@xxxxxxx> wrote:
>
>> 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.
That's easy:
- Take any usbnet device supporting remote wakeup (and of course with a
minidriver supporting it as well),
- enable autosuspend,
- ip link set dev ethX/usbX/wwanX up
And watch ksoftirqd/X use 100% of one of your CPU cores.
I'd very much like to hear the details if you are unable to reproduce
the bug using this simple test.
> 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().
Huh???? We do support suspending a USB device while the network device
is up and running. That's the whole idea here, isn't it? I.e.
netif_device_present() is *expected* to be true while the USB device is
suspended.
> Once usbnet_terminate_urbs and netif_device_attach() are
> completed, who will schedule tasklet to trigger rx_alloc_submit?
That's a good question. It sure would be nice if that never happened
without waking the device first. But there are just too many call sites
for me to follow:
bjorn@nemi:/usr/local/src/git/linux$ grep tasklet_schedule drivers/net/usb/usbnet.c
tasklet_schedule(&dev->bh);
* but tasklet_schedule() doesn't. hope the failure is rare.
tasklet_schedule (&dev->bh);
tasklet_schedule(&dev->bh);
tasklet_schedule(&dev->bh);
tasklet_schedule (&dev->bh);
tasklet_schedule (&dev->bh);
tasklet_schedule (&dev->bh);
tasklet_schedule (&dev->bh);
tasklet_schedule (&dev->bh);
tasklet_schedule (&dev->bh);
And I do believe the code before your change demonstrated that the
original authors had the same view. There was an explicit exception for
just this case, and I do assume that was put there for a good
reason. usbnet_bh() will be called while the device is suspended, and we
must avoid making it reschedule itself in this case.
Anyway, the ENOLINK test was there. You removed it with no explanation
whatsoever. It is *your* call to verify and explain to us why this test
is unnecessary, not mine.
Bjørn
--
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
