Hi Tomáš, On Fri, Nov 18, 2011, Tomáš Janoušek wrote: > while testing the 3.2-rc kernel, I experienced that resume takes 10 seconds > more than usual, and bisected this to be caused by e1b6eb3 (Bluetooth: > Increase HCI reset timeout in hci_dev_do_close). > > My hardware is Lenovo ThinkPad T420, model number 4178-A3G, with a Broadcom > Bluetooth adapter (I'm attaching the relevant part of lsusb). > > The relevant portion of dmesg is: > [ 76.502818] usb 1-1.4: reset full-speed USB device number 4 using ehci_hcd > [ 76.588225] btusb 1-1.4:1.0: no reset_resume for driver btusb? > [ 76.591870] btusb 1-1.4:1.1: no reset_resume for driver btusb? > [ 86.565269] PM: resume of devices complete after 10486.220 msecs > > My resume scripts did contain a hciconfig hci0 down followed by up, because > on my previous notebook (and the kernel I used at the time) it was needed for > BT to work after suspend. On this hardware, however, none of that is needed. > Bluetooth after suspend works regardless of whether that patch is applied or > not, and I believe it would wait indefinitely if given large enough timeout. > > Aside from reverting the patch, doing the following before suspend also works > around the issue: > echo disable > /proc/acpi/ibm/bluetooth It might be worth to try out the two patches I just sent to linux-bluetooth for HCI command failure tracking. They make sure that failures are properly caught which should help avoid triggering the timeout in certain scenarios (and yours might be one of them). Johan -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
