On Sun, 15 Jul 2007, Dave Jones wrote:
> Hi folks,
> Given the potential power savings USB_SUSPEND offers, we'd
> like to turn this on in Fedora kernels, however there still
> seems to be quite a few devices out there that seem to have issues.
> (Notably printers it seems).
Scanners too. Plus a smorgasbord of other random devices.
> For our development kernels, we're
> just shipping stuff as-is, so that we can find out about these
> devices, but for our release kernels (ie, updates for Fedora 6 & 7),
> we came up with the idea of eanbling CONFIG_USB_SUSPEND=y, but
> change it so that it defaults to disabled by means of the following
> patch..
>
> --- linux-2.6.22.noarch/drivers/usb/core/usb.c~ 2007-07-10
> 12:18:12.000000000 -0400
> +++ linux-2.6.22.noarch/drivers/usb/core/usb.c 2007-07-10
> 12:18:20.000000000 -0400
> @@ -52,7 +52,7 @@ static int nousb; /* Disable USB when bu
> struct workqueue_struct *ksuspend_usb_wq;
>
> #ifdef CONFIG_USB_SUSPEND
> -static int usb_autosuspend_delay = 2; /* Default delay value,
> +static int usb_autosuspend_delay = 0; /* Default delay value,
> * in seconds */
> module_param_named(autosuspend, usb_autosuspend_delay, int, 0644);
> MODULE_PARM_DESC(autosuspend, "default autosuspend delay");
Ooh! Don't do that. Starting in 2.6.22, setting the delay to 0 means
"autosuspend as soon as possible". (It was different in 2.6.21.) The
variable now needs to be set to -1 to prevent autosuspending. This is
explained in Documentation/ABI/testing/sysfs-bus-usb and
Documentation/kernel-parameters.txt.
> It seemed to have the desired effect of not enabling this feature, but
> making it available for those who want to try changing it, but there
> seems to be a side-effect that would also appear if someone were
> to insmod usb-core with usb_autosuspend_delay=0
>
> During boot I now see several of these traces..
> usb 5-1.4: new high speed USB device using ehci_hcd and address 6
> usb 5-1.4: configuration #1 chosen from 1 choice
> WARNING: at drivers/usb/core/driver.c:1192 usb_autopm_do_device() (Not
> tainted)
>
> Call Trace:
> [<ffffffff811acf2c>] usb_autopm_do_device+0x6e/0xf1
> [<ffffffff811ad339>] usb_suspend_both+0x212/0x229
> [<ffffffff811acf97>] usb_autopm_do_device+0xd9/0xf1
> [<ffffffff811ac1a6>] usb_set_configuration+0x3fb/0x42e
> [<ffffffff811b359b>] generic_probe+0x1a6/0x1f3
> [<ffffffff81194147>] driver_probe_device+0xff/0x17c
> [<ffffffff811941c4>] __device_attach+0x0/0x5
> [<ffffffff81193386>] bus_for_each_drv+0x40/0x72
> [<ffffffff81194265>] device_attach+0x79/0x90
> [<ffffffff811932f2>] bus_attach_device+0x2a/0x7e
> [<ffffffff81192019>] device_add+0x3cb/0x611
> [<ffffffff811a776e>] usb_new_device+0xab/0xf6
> [<ffffffff811a8462>] hub_thread+0x7f1/0xc0a
> [<ffffffff81050169>] trace_hardirqs_on+0x12f/0x153
> [<ffffffff81257d90>] thread_return+0x88/0x117
> [<ffffffff810465da>] autoremove_wake_function+0x0/0x2e
> [<ffffffff811a7c71>] hub_thread+0x0/0xc0a
> [<ffffffff81046498>] kthread+0x47/0x73
> [<ffffffff8125a14b>] trace_hardirqs_on_thunk+0x35/0x37
> [<ffffffff8100aa28>] child_rip+0xa/0x12
> [<ffffffff8100a13c>] restore_args+0x0/0x30
> [<ffffffff81046321>] kthreadd+0x117/0x13c
> [<ffffffff81046321>] kthreadd+0x117/0x13c
> [<ffffffff81046451>] kthread+0x0/0x73
> [<ffffffff8100aa1e>] child_rip+0x0/0x12
>
> which corresponds to the
>
> WARN_ON(udev->pm_usage_cnt < 0);
>
> in usb_autopm_do_device()
> I'm suspecting logic is underflowing here causing this.
Yes, that's what it means. I'm puzzled as to how this could occur; let
me try some tests. What types of devices give rise to these warnings?
> Before I dig deeper, are there other side-effects of changing
> this default ?
The differences between setting usb_autosuspend_delay to -1 and turning
off CONFIG_USB_SUSPEND:
Setting the default delay to -1 allows users to enable
autosuspend on a per-device basis. For that matter, you
might want to add a line to the hub driver, to enable
autosuspend for hubs by default.
It adds more code to the kernel (obviously).
It changes the way suspend-to-RAM behaves: individual USB
devices get suspended as opposed to suspending an entire
bus all at once. In theory this shouldn't matter.
I can't think of anything else at the moment.
Alan Stern
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
