Re: usb suspend backtraces.

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/
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel