Just installed F13 on my Thinkpad T500. Found this in the logs after booting... Not sure quite what it means, nor how reproducible it is. Definitely tell me if I can do further investigation. btusb_intr_complete: hci0 urb ffff880030cb6840 failed to resubmit (1) btusb_bulk_complete: hci0 urb ffff880030cb6738 failed to resubmit (1) btusb_bulk_complete: hci0 urb ffff880030cb7bd8 failed to resubmit (1) btusb_intr_complete: hci0 urb ffff880030ce0738 failed to resubmit (1) btusb_bulk_complete: hci0 urb ffff880030ce0d68 failed to resubmit (1) btusb_bulk_complete: hci0 urb ffff880030ce1ef0 failed to resubmit (1) btusb_intr_complete: hci0 urb ffff880030ce1ad0 failed to resubmit (1) btusb_bulk_complete: hci0 urb ffff880030ce1de8 failed to resubmit (1) btusb_bulk_complete: hci0 urb ffff880030ce0a50 failed to resubmit (1) input: 00:0D:3C:BB:63:CE as /devices/virtual/input/input14 ======================================================= [ INFO: possible circular locking dependency detected ] 2.6.33.2-41.fc13.x86_64 #1 ------------------------------------------------------- events/0/9 is trying to acquire lock: (&dev->pm_mutex/1){+.+.+.}, at: [<ffffffff8134dc03>] usb_autopm_do_interface+0x3f/0xe0 but task is already holding lock: ((&data->work)){+.+...}, at: [<ffffffff8106861c>] worker_thread+0x20e/0x35f which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 ((&data->work)){+.+...}: [<ffffffff8107f827>] __lock_acquire+0xb7d/0xd2c [<ffffffff8107fab2>] lock_acquire+0xdc/0x102 [<ffffffff8106917a>] __cancel_work_timer+0xe1/0x191 [<ffffffff8106924e>] cancel_work_sync+0x10/0x12 [<ffffffffa029d7e0>] btusb_suspend+0x8b/0xdb [btusb] [<ffffffff8134da05>] usb_suspend_both+0xd8/0x297 [<ffffffff8134e713>] usb_external_suspend_device+0x43/0x5c [<ffffffff8134e787>] usb_device_autosuspend_enable+0x1a/0x1c [<ffffffffa029dec3>] btusb_probe+0x4bb/0x4f1 [btusb] [<ffffffff8134e346>] usb_probe_interface+0x155/0x20d [<ffffffff812eec2f>] driver_probe_device+0xed/0x21a [<ffffffff812eedb9>] __driver_attach+0x5d/0x81 [<ffffffff812ee013>] bus_for_each_dev+0x59/0x8e [<ffffffff812ee9b6>] driver_attach+0x1e/0x20 [<ffffffff812ee31a>] bus_add_driver+0x120/0x288 [<ffffffff812ef0c0>] driver_register+0x9e/0x10f [<ffffffff8134e034>] usb_register_driver+0xb7/0x178 [<ffffffffa02a3033>] 0xffffffffa02a3033 [<ffffffff8100207d>] do_one_initcall+0x72/0x18a [<ffffffff8108c4a6>] sys_init_module+0xd8/0x23a [<ffffffff81009c72>] system_call_fastpath+0x16/0x1b -> #0 (&dev->pm_mutex/1){+.+.+.}: [<ffffffff8107f6d1>] __lock_acquire+0xa27/0xd2c [<ffffffff8107fab2>] lock_acquire+0xdc/0x102 [<ffffffff81478bad>] __mutex_lock_common+0x4b/0x392 [<ffffffff81478fb8>] mutex_lock_nested+0x3e/0x43 [<ffffffff8134dc03>] usb_autopm_do_interface+0x3f/0xe0 [<ffffffff8134dcb7>] usb_autopm_get_interface+0x13/0x15 [<ffffffffa029e806>] btusb_work+0x3d/0xfd [btusb] [<ffffffff81068674>] worker_thread+0x266/0x35f [<ffffffff8106c5b8>] kthread+0x9a/0xa2 [<ffffffff8100aae4>] kernel_thread_helper+0x4/0x10 other info that might help us debug this: 2 locks held by events/0/9: #0: (events){+.+.+.}, at: [<ffffffff8106861c>] worker_thread+0x20e/0x35f #1: ((&data->work)){+.+...}, at: [<ffffffff8106861c>] worker_thread+0x20e/0x35f stack backtrace: Pid: 9, comm: events/0 Not tainted 2.6.33.2-41.fc13.x86_64 #1 Call Trace: [<ffffffff8107e881>] print_circular_bug+0xaf/0xbd [<ffffffff8107f6d1>] __lock_acquire+0xa27/0xd2c [<ffffffff8107fab2>] lock_acquire+0xdc/0x102 [<ffffffff8134dc03>] ? usb_autopm_do_interface+0x3f/0xe0 [<ffffffff8134dc03>] ? usb_autopm_do_interface+0x3f/0xe0 [<ffffffff81478bad>] __mutex_lock_common+0x4b/0x392 [<ffffffff8134dc03>] ? usb_autopm_do_interface+0x3f/0xe0 [<ffffffff8107221a>] ? sched_clock_cpu+0xc3/0xce [<ffffffff8107ca88>] ? trace_hardirqs_off+0xd/0xf [<ffffffff810720f1>] ? sched_clock_local+0x1c/0x82 [<ffffffff81478fb8>] mutex_lock_nested+0x3e/0x43 [<ffffffff8134dc03>] usb_autopm_do_interface+0x3f/0xe0 [<ffffffff8134dcb7>] usb_autopm_get_interface+0x13/0x15 [<ffffffffa029e806>] btusb_work+0x3d/0xfd [btusb] [<ffffffff81068674>] worker_thread+0x266/0x35f [<ffffffff8106861c>] ? worker_thread+0x20e/0x35f [<ffffffffa029e7c9>] ? btusb_work+0x0/0xfd [btusb] [<ffffffff8106ca5a>] ? autoremove_wake_function+0x0/0x39 [<ffffffff8106840e>] ? worker_thread+0x0/0x35f [<ffffffff8106c5b8>] kthread+0x9a/0xa2 [<ffffffff8107e1d8>] ? trace_hardirqs_on_caller+0x111/0x135 [<ffffffff8100aae4>] kernel_thread_helper+0x4/0x10 [<ffffffff8147ac50>] ? restore_args+0x0/0x30 [<ffffffff8106c51e>] ? kthread+0x0/0xa2 [<ffffffff8100aae0>] ? kernel_thread_helper+0x0/0x10 btusb_intr_complete: hci0 urb ffff880030cb6108 failed to resubmit (1) btusb_bulk_complete: hci0 urb ffff880030cb6f78 failed to resubmit (1) btusb_bulk_complete: hci0 urb ffff880030cb7080 failed to resubmit (1) btusb_intr_complete: hci0 urb ffff88009491a630 failed to resubmit (1) btusb_bulk_complete: hci0 urb ffff88009491b6b0 failed to resubmit (1) btusb_bulk_complete: hci0 urb ffff88009491b5a8 failed to resubmit (1) btusb_intr_complete: hci0 urb ffff88009ac60948 failed to resubmit (1) btusb_bulk_complete: hci0 urb ffff88009ac61188 failed to resubmit (1) btusb_bulk_complete: hci0 urb ffff88009ac60d68 failed to resubmit (1) btusb_intr_complete: hci0 urb ffff88005c15d9c8 failed to resubmit (1) btusb_bulk_complete: hci0 urb ffff88005c0ab5a8 failed to resubmit (1) btusb_bulk_complete: hci0 urb ffff88005c0aa738 failed to resubmit (1)
i have same problem, because of that my bluetooth mouse works badly. http://forums.fedoraforum.org/showthread.php?t=124018
I just got a bluetooth adapter for my desktop. I can pair from my laptop to my desktop, but not the other way around. I also get this output in dmesg usb 5-2.3: New USB device found, idVendor=0a5c, idProduct=2148 usb 5-2.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 5-2.3: Product: BCM92046DG-CL1ROM usb 5-2.3: Manufacturer: Broadcom Corp usb 5-2.3: SerialNumber: 000272ABCB40 Bluetooth: Core ver 2.15 NET: Registered protocol family 31 Bluetooth: HCI device and connection manager initialized Bluetooth: HCI socket layer initialized Bluetooth: Generic Bluetooth USB driver ver 0.6 usbcore: registered new interface driver btusb Bluetooth: L2CAP ver 2.14 Bluetooth: L2CAP socket layer initialized Bluetooth: BNEP (Ethernet Emulation) ver 1.3 Bluetooth: BNEP filters: protocol multicast Bluetooth: SCO (Voice Link) ver 0.6 Bluetooth: SCO socket layer initialized usb 5-2.1: input irq status -75 received usb 5-2.1: input irq status -75 received usb 5-2.1: input irq status -75 received usb 5-2.1: input irq status -75 received usb 5-2.1: input irq status -75 received usb 5-2.1: input irq status -75 received usb 5-2.1: input irq status -75 received usb 5-2.1: input irq status -75 received usb 5-2.1: input irq status -75 received usb 5-2.1: input irq status -75 received usb 5-2.1: input irq status -75 received usb 5-2.1: input irq status -75 received Bluetooth: RFCOMM TTY layer initialized Bluetooth: RFCOMM socket layer initialized Bluetooth: RFCOMM ver 1.11 usb 5-2.1: input irq status -75 received usb 5-2.1: input irq status -75 received usb 5-2.1: input irq status -75 received usb 5-2.1: input irq status -75 received usb 5-2.1: input irq status -75 received usb 5-2.1: input irq status -75 received usb 5-2.1: input irq status -75 received usb 5-2.1: input irq status -75 received usb 5-2.1: input irq status -75 received usb 5-2.1: input irq status -75 received usb 5-2.1: input irq status -75 received usb 5-2.1: input irq status -75 received btusb_intr_complete: hci0 urb ffff8801b96f1600 failed to resubmit (1) This last message I get constantly, but with different hex numbers.. kernel is uname -a Linux quad 2.6.33.6-147.fc13.x86_64 #1 SMP Tue Jul 6 22:32:17 UTC 2010 x86_64 x86_64 x86_64 GNU/Linux Fedora 13, fully up to date as of July 22, 2010
(In reply to comment #2) > I just got a bluetooth adapter for my desktop. I can pair from my laptop to my > desktop, but not the other way around. I also get this output in dmesg > > > usb 5-2.3: New USB device found, idVendor=0a5c, idProduct=2148 > usb 5-2.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3 > usb 5-2.3: Product: BCM92046DG-CL1ROM > usb 5-2.3: Manufacturer: Broadcom Corp > usb 5-2.3: SerialNumber: 000272ABCB40 > Bluetooth: Core ver 2.15 > NET: Registered protocol family 31 > Bluetooth: HCI device and connection manager initialized > Bluetooth: HCI socket layer initialized > Bluetooth: Generic Bluetooth USB driver ver 0.6 > usbcore: registered new interface driver btusb > Bluetooth: L2CAP ver 2.14 > Bluetooth: L2CAP socket layer initialized > Bluetooth: BNEP (Ethernet Emulation) ver 1.3 > Bluetooth: BNEP filters: protocol multicast > Bluetooth: SCO (Voice Link) ver 0.6 > Bluetooth: SCO socket layer initialized > usb 5-2.1: input irq status -75 received > usb 5-2.1: input irq status -75 received Other than it being about bluetooth, that is completely unrelated to the circular locking message.
Is the circular locking message still happening? Does it happen on a 2.6.34 kernel?
I'm not sure if this is the same issue: The log has the below message over and over, changing only in the Hex, but BT devices work fine if I keep Blueman Device Manager 1.21 opened as an app all the time. Sometimes after logging in the button functions of the mouse don't work (this may happen when rebooting rather that starting from a shutdown state). Jul 26 20:30:34 constellation kernel: btusb_intr_complete: hci0 urb ffff880099b1cf00 failed to resubmit (1) Jul 26 20:30:34 constellation kernel: btusb_bulk_complete: hci0 urb ffff8800853a73c0 failed to resubmit (1) Jul 26 20:30:34 constellation kernel: btusb_bulk_complete: hci0 urb ffff880099b1c480 failed to resubmit (1) Jul 26 20:31:10 constellation kernel: btusb_intr_complete: hci0 urb ffff8800761bf480 failed to resubmit (1) Jul 26 20:31:10 constellation kernel: btusb_bulk_complete: hci0 urb ffff8800761bfd80 failed to resubmit (1) Jul 26 20:31:10 constellation kernel: btusb_bulk_complete: hci0 urb ffff8800761bf6c0 failed to resubmit (1) Jul 26 20:31:25 constellation kernel: btusb_intr_complete: hci0 urb ffff880084b43180 failed to resubmit (1) Jul 26 20:31:25 constellation kernel: btusb_bulk_complete: hci0 urb ffff880084b43cc0 failed to resubmit (1) Jul 26 20:31:25 constellation kernel: btusb_bulk_complete: hci0 urb ffff880084874600 failed to resubmit (1) Jul 26 20:32:07 constellation kernel: btusb_intr_complete: hci0 urb ffff8800854ea0c0 failed to resubmit (1) Jul 26 20:32:07 constellation kernel: btusb_bulk_complete: hci0 urb ffff8800854ea300 failed to resubmit (1) Jul 26 20:32:07 constellation kernel: btusb_bulk_complete: hci0 urb ffff8800854ea000 failed to resubmit (1) I tried blacklisting the btusb driver after determining that the BT adapter was using that driver, hoping that the BT compatible package would have a different driver the adapter could use, but then the BT system didn't work at all, so un-blacklisted it. Tried un-installing and reinstalling all bluetooth packages and updated blueman from the testing repo. There are no other BT packages available in testing or rawhide to try. I am using a logitech BT mouse and Apple BT wireless keyboard only, both new in the last month and the adapter is built-in on a Apple MacBook 2.1 uname -a 2.6.33.6-147.fc13.x86_64 #1 SMP Tue Jul 6 22:32:17 UTC 2010 x86_64 x86_64 x86_64 GNU/Linux Gnome: 2.30.0 lsusb | grep Blue Bus 005 Device 003: ID 05ac:8205 Apple, Inc. Bluetooth HCI lsmod | grep bt btusb 15012 8 bluetooth 87181 14 hidp,rfcomm,sco,bnep,l2cap,btusb Updates complete as of July 26/2010 10:22 Mountain time. Could not find kernel 2.6.34 in testing or rawhide repos, but am willing to test or provide more info if anyone wants to tell me what to do.
Ok, so I added the following script to /etc/rc.local as a test just to see what happens, as the issues are somewhat similar to Bugzilla bug 570291. The script is courtesy of Sergey Kornienko. Thank you Sergey and also to Andy Lawrence, who came up with the idea in the first place (as far as I can tell). cd `readlink -f /sys/class/bluetooth/hci0` cd ../../../power/ echo on > level I haven't had the "kernel: btusb_intr_complete: hci0 urb (some variable Hex) failed to resubmit (1)" error messages for the last 3 hours. Joy, a clean messages log! Anyway this script is disabling autosuspend for the bluetooth system and was originally thought of to stop lagging BT mouse issues. I hope this helps someone else, and I'm still willing to experiment if it will help resolve the real issue.
(In reply to comment #6) > Ok, so I added the following script to /etc/rc.local as a test > > cd `readlink -f /sys/class/bluetooth/hci0` > cd ../../../power/ > echo on > level > > Thanks. Somehow it works for me too. And now i can use my bluetooth logitech m555 mouse freely.
Just a quick update; My MacBook was running all night, and so at least 14-15 hours of no error messages at this point. It seems this does really fix the issue of the error messages and erratic mouse functionality. So as stated in the bugzilla bug 570291, something should be changed in the kernel so this workaround isn't necessary. I'm glad it worked for you too Aliaric, and you are welcome. Best regards to all, Alex
Does kernel-2.6.34.6-47 work any better?
kernel 2.6.34.6-47.fc13.x86_64 problem seems to be gone. roger wells
yeah, looks like for me too.