[opensuse-kernel] continuous flow of: btusb_intr_complete: hci0 urb ffff8800b553e980 failed to resubmit (1)
Hi,
since a few days (probably since the update to 2.6.37-rc), i'm getting those all the time when using my Bluetooth mouse:
[280800.710274] btusb_intr_complete: hci0 urb ffff8800b553e980 failed to resubmit (1) [280800.711255] btusb_bulk_complete: hci0 urb ffff88003b01de40 failed to resubmit (1) [280800.712234] btusb_bulk_complete: hci0 urb ffff880130bae500 failed to resubmit (1) [280810.713221] btusb_intr_complete: hci0 urb ffff88012be0ce00 failed to resubmit (1) [280810.714203] btusb_bulk_complete: hci0 urb ffff8800532f9540 failed to resubmit (1) [280810.715209] btusb_bulk_complete: hci0 urb ffff88003b13af00 failed to resubmit (1) [280814.713273] btusb_intr_complete: hci0 urb ffff880045756d80 failed to resubmit (1) [280814.714293] btusb_bulk_complete: hci0 urb ffff880035d1bec0 failed to resubmit (1) [280814.715285] btusb_bulk_complete: hci0 urb ffff88003b13ac00 failed to resubmit (1) [280821.713412] btusb_intr_complete: hci0 urb ffff8801293cf0c0 failed to resubmit (1) [280821.714431] btusb_bulk_complete: hci0 urb ffff88003b13ac00 failed to resubmit (1) [280821.715432] btusb_bulk_complete: hci0 urb ffff880035d1bec0 failed to resubmit (1) [280835.707273] btusb_intr_complete: hci0 urb ffff8800a83a6c80 failed to resubmit (1) [280835.708233] btusb_bulk_complete: hci0 urb ffff8801292986c0 failed to resubmit (1) [280835.709269] btusb_bulk_complete: hci0 urb ffff880078654f00 failed to resubmit (1)
Has this something to do with runtime power management? It seems like it's always 3 messages about 2 or 3 seconds after the last mouse movement.
On Tue, 30 Nov 2010 11:10:22 +0100 Stefan Seyfried stefan.seyfried@googlemail.com wrote:
Hi,
since a few days (probably since the update to 2.6.37-rc), i'm getting those all the time when using my Bluetooth mouse:
[280835.709269] btusb_bulk_complete: hci0 urb ffff880078654f00 failed to resubmit (1)
Has this something to do with runtime power management? It seems like it's always 3 messages about 2 or 3 seconds after the last mouse movement.
And indeed, "echo on > /sys/bus/usb/drivers/btusb/4-2:1.0/power/control" makes it go away. However, is this a good idea? And is "auto" for that feature a good idea if it leads to constant syslog spamming? Or are those "failed to resubmit" messages mere debug output and thus should not be logged at all unless some debugging option is chosen?
On Tue, 30 Nov 2010, Stefan Seyfried wrote:
since a few days (probably since the update to 2.6.37-rc), i'm getting those all the time when using my Bluetooth mouse:
[280835.709269] btusb_bulk_complete: hci0 urb ffff880078654f00 failed to resubmit (1)
Has this something to do with runtime power management? It seems like it's always 3 messages about 2 or 3 seconds after the last mouse movement.
And indeed, "echo on > /sys/bus/usb/drivers/btusb/4-2:1.0/power/control" makes it go away. However, is this a good idea? And is "auto" for that feature a good idea if it leads to constant syslog spamming? Or are those "failed to resubmit" messages mere debug output and thus should not be logged at all unless some debugging option is chosen?
Runtime power management has been turned on by default in 2.6.37-rc (it has been off by default in previous kernels) for btusb driver. So that's why you have not seen it with older kernels, and why turning autosuspend off fixes it again.
Looks like the completion handler is run only after the device has been suspended already. Adding Oliver, who originally wrote the autosuspend support for this driver.
Oliver, any immediate ideas?
Am Dienstag, 30. November 2010, 11:18:05 schrieb Stefan Seyfried:
Or are those "failed to resubmit" messages mere debug output and thus should not be logged at all unless some debugging option is chosen?
If they are ever triggered by anything but autosuspend the device has just sopped working, so they were originally very justified. If autosuspend becomes default, they should be made into true debug output.
Regards Oliver
Am Dienstag, 30. November 2010, 11:18:05 schrieb Stefan Seyfried:
On Tue, 30 Nov 2010 11:10:22 +0100 Stefan Seyfried stefan.seyfried@googlemail.com wrote:
Hi,
since a few days (probably since the update to 2.6.37-rc), i'm getting those all the time when using my Bluetooth mouse:
[280835.709269] btusb_bulk_complete: hci0 urb ffff880078654f00 failed to resubmit (1)
Has this something to do with runtime power management? It seems like it's always 3 messages about 2 or 3 seconds after the last mouse movement.
And indeed, "echo on > /sys/bus/usb/drivers/btusb/4-2:1.0/power/control" makes it go away. However, is this a good idea? And is "auto" for that feature a good idea if it leads to constant syslog spamming? Or are those "failed to resubmit" messages mere debug output and thus should not be logged at all unless some debugging option is chosen? --
Hi,
as no good dead goes unpunished, here's a patch to test.
Thanks Oliver
From 5667a03459b9b4b5cb33259115b57626bcc4ccf3 Mon Sep 17 00:00:00 2001 From: Oliver Neukum oliver@neukum.org Date: Tue, 30 Nov 2010 14:34:47 +0100 Subject: [PATCH] Bluetooth:btusb: Fix log spamming due to autosuspend
If a device is autosuspend an inability to resubmit URBs is to be expected. Fix it by checking the error return.
Signed-off-by: Oliver Neukum oneukum@suse.de --- drivers/bluetooth/btusb.c | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c index ab3894f..eb2ca82 100644 --- a/drivers/bluetooth/btusb.c +++ b/drivers/bluetooth/btusb.c @@ -238,7 +238,7 @@ static void btusb_intr_complete(struct urb *urb) usb_anchor_urb(urb, &data->intr_anchor);
err = usb_submit_urb(urb, GFP_ATOMIC); - if (err < 0) { + if (err < 0 && err != -EPERM) { BT_ERR("%s urb %p failed to resubmit (%d)", hdev->name, urb, -err); usb_unanchor_urb(urb); @@ -322,7 +322,7 @@ static void btusb_bulk_complete(struct urb *urb) usb_mark_last_busy(data->udev);
err = usb_submit_urb(urb, GFP_ATOMIC); - if (err < 0) { + if (err < 0 && err != -EPERM) { BT_ERR("%s urb %p failed to resubmit (%d)", hdev->name, urb, -err); usb_unanchor_urb(urb); @@ -411,7 +411,7 @@ static void btusb_isoc_complete(struct urb *urb) usb_anchor_urb(urb, &data->isoc_anchor);
err = usb_submit_urb(urb, GFP_ATOMIC); - if (err < 0) { + if (err < 0 && err != -EPERM) { BT_ERR("%s urb %p failed to resubmit (%d)", hdev->name, urb, -err); usb_unanchor_urb(urb);
On Tue, 30 Nov 2010 14:39:57 +0100 Oliver Neukum oneukum@suse.de wrote:
as no good dead goes unpunished, here's a patch to test.
No need to test, the patch is obviously wrong ;-) (I tested it anyway, just for fun, and it leads to 100% CPU usage and hard lockup shortly afterwards).
err = usb_submit_urb(urb, GFP_ATOMIC);
- if (err < 0) {
- if (err < 0 && err != -EPERM) { BT_ERR("%s urb %p failed to resubmit (%d)", hdev->name, urb, -err); usb_unanchor_urb(urb);
you are forgetting the usb_unanchor_urb for the -EPERM case here.
From 9cd3d383b5b172b78e7887b38f9b30acfb469d52 Mon Sep 17 00:00:00 2001 From: Stefan Seyfried seife+kernel@b1-systems.com Date: Tue, 30 Nov 2010 17:46:23 +0100 Subject: [PATCH] btusb: Fix log spamming due to autosuspend
If a device is autosuspended an inability to resubmit URBs is to be expected. Check the error code and only log real errors.
Signed-off-by: Stefan Seyfried seife+kernel@b1-systems.com --- drivers/bluetooth/btusb.c | 9 ++++++--- 1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c index ab3894f..d323c1a 100644 --- a/drivers/bluetooth/btusb.c +++ b/drivers/bluetooth/btusb.c @@ -239,7 +239,8 @@ static void btusb_intr_complete(struct urb *urb)
err = usb_submit_urb(urb, GFP_ATOMIC); if (err < 0) { - BT_ERR("%s urb %p failed to resubmit (%d)", + if (err != -EPERM) + BT_ERR("%s urb %p failed to resubmit (%d)", hdev->name, urb, -err); usb_unanchor_urb(urb); } @@ -323,7 +324,8 @@ static void btusb_bulk_complete(struct urb *urb)
err = usb_submit_urb(urb, GFP_ATOMIC); if (err < 0) { - BT_ERR("%s urb %p failed to resubmit (%d)", + if (err != -EPERM) + BT_ERR("%s urb %p failed to resubmit (%d)", hdev->name, urb, -err); usb_unanchor_urb(urb); } @@ -412,7 +414,8 @@ static void btusb_isoc_complete(struct urb *urb)
err = usb_submit_urb(urb, GFP_ATOMIC); if (err < 0) { - BT_ERR("%s urb %p failed to resubmit (%d)", + if (err != -EPERM) + BT_ERR("%s urb %p failed to resubmit (%d)", hdev->name, urb, -err); usb_unanchor_urb(urb); }
Am Dienstag, 30. November 2010, 17:59:46 schrieb Stefan Seyfried:
On Tue, 30 Nov 2010 14:39:57 +0100 Oliver Neukum oneukum@suse.de wrote:
as no good dead goes unpunished, here's a patch to test.
No need to test, the patch is obviously wrong ;-) (I tested it anyway, just for fun, and it leads to 100% CPU usage and hard lockup shortly afterwards).
err = usb_submit_urb(urb, GFP_ATOMIC);
- if (err < 0) {
- if (err < 0 && err != -EPERM) { BT_ERR("%s urb %p failed to resubmit (%d)", hdev->name, urb, -err); usb_unanchor_urb(urb);
you are forgetting the usb_unanchor_urb for the -EPERM case here.
<censored>. Thank you. Please submit upstream.
Regards Oliver
On Tue, 30 Nov 2010 18:33:52 +0100 Oliver Neukum oneukum@suse.de wrote:
Am Dienstag, 30. November 2010, 17:59:46 schrieb Stefan Seyfried:
you are forgetting the usb_unanchor_urb for the -EPERM case here.
<censored>. Thank you. Please submit upstream.
Ok. I'll add your signed-off-by. Is Greg upstream or should this go through the bluetooth list? It "feels" rather urgent and the bluetooth list is usually a good way to slow things down to a crawl :-)
Am Dienstag, 30. November 2010, 20:48:09 schrieb Stefan Seyfried:
On Tue, 30 Nov 2010 18:33:52 +0100 Oliver Neukum oneukum@suse.de wrote:
Am Dienstag, 30. November 2010, 17:59:46 schrieb Stefan Seyfried:
you are forgetting the usb_unanchor_urb for the -EPERM case here.
<censored>. Thank you. Please submit upstream.
Ok. I'll add your signed-off-by. Is Greg upstream or should this go through the bluetooth list? It "feels" rather urgent and the bluetooth list is usually a good way to slow things down to a crawl :-)
You can try Greg. I am unsure whether he'll take it.
Regards Oliver
On Tue, Nov 30, 2010 at 09:00:17PM +0100, Oliver Neukum wrote:
Am Dienstag, 30. November 2010, 20:48:09 schrieb Stefan Seyfried:
On Tue, 30 Nov 2010 18:33:52 +0100 Oliver Neukum oneukum@suse.de wrote:
Am Dienstag, 30. November 2010, 17:59:46 schrieb Stefan Seyfried:
you are forgetting the usb_unanchor_urb for the -EPERM case here.
<censored>. Thank you. Please submit upstream.
Ok. I'll add your signed-off-by. Is Greg upstream or should this go through the bluetooth list? It "feels" rather urgent and the bluetooth list is usually a good way to slow things down to a crawl :-)
You can try Greg. I am unsure whether he'll take it.
It needs to go through the bluetooth maintainer, right? That's not me, sorry.
greg k-h
On Tue, 30 Nov 2010, Greg KH wrote:
you are forgetting the usb_unanchor_urb for the -EPERM case here.
<censored>. Thank you. Please submit upstream.
Ok. I'll add your signed-off-by. Is Greg upstream or should this go through the bluetooth list? It "feels" rather urgent and the bluetooth list is usually a good way to slow things down to a crawl :-)
You can try Greg. I am unsure whether he'll take it.
It needs to go through the bluetooth maintainer, right? That's not me, sorry.
Unfortunately, Marcel (and Bluetooth tree as a whole) is not really the most lively entity on the earth these days, so to say.
I'd suggest CCing Andrew Morton on it as well. He's likely to pick it up in case "normal" way through maintainer fails (which is very likely here).
Am Dienstag, 30. November 2010, 11:10:22 schrieb Stefan Seyfried:
since a few days (probably since the update to 2.6.37-rc), i'm getting those all the time when using my Bluetooth mouse:
[280800.710274] btusb_intr_complete: hci0 urb ffff8800b553e980 failed to resubmit (1) [280800.711255] btusb_bulk_complete: hci0 urb ffff88003b01de40 failed to resubmit (1) [280800.712234] btusb_bulk_complete: hci0 urb ffff880130bae500 failed to resubmit (1) [280810.713221] btusb_intr_complete: hci0 urb ffff88012be0ce00 failed to resubmit (1) [280810.714203] btusb_bulk_complete: hci0 urb ffff8800532f9540 failed to resubmit (1) [280810.715209] btusb_bulk_complete: hci0 urb ffff88003b13af00 failed to resubmit (1) [280814.713273] btusb_intr_complete: hci0 urb ffff880045756d80 failed to resubmit (1) [280814.714293] btusb_bulk_complete: hci0 urb ffff880035d1bec0 failed to resubmit (1) [280814.715285] btusb_bulk_complete: hci0 urb ffff88003b13ac00 failed to resubmit (1) [280821.713412] btusb_intr_complete: hci0 urb ffff8801293cf0c0 failed to resubmit (1) [280821.714431] btusb_bulk_complete: hci0 urb ffff88003b13ac00 failed to resubmit (1) [280821.715432] btusb_bulk_complete: hci0 urb ffff880035d1bec0 failed to resubmit (1) [280835.707273] btusb_intr_complete: hci0 urb ffff8800a83a6c80 failed to resubmit (1) [280835.708233] btusb_bulk_complete: hci0 urb ffff8801292986c0 failed to resubmit (1) [280835.709269] btusb_bulk_complete: hci0 urb ffff880078654f00 failed to resubmit (1)
Has this something to do with runtime power management? It seems like it's always 3 messages about 2 or 3 seconds after the last mouse movement.
Most likely it is power management. I'll make a patch to remove them.
Regards Oliver
-
Greg KH -
Jiri Kosina -
Oliver Neukum -
Stefan Seyfried