usb suspend backtraces.

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).  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");

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.
Before I dig deeper, are there other side-effects of changing
this default ?

Thanks,

	Dave

-- 
http://www.codemonkey.org.uk

-------------------------------------------------------------------------
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