linux-kernel - Re: [REGRESSION] resume takes 10s longer due to e1b6eb3 (Bluetooth: Increase HCI reset timeout ...)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 21 Nov 2011 17:25:06 +0200
From:	Johan Hedberg <johan.hedberg@...il.com>
To:	Tomáš Janoušek <tomi@...i.cz>
Cc:	Szymon Janc <szymon@...c.net.pl>,
	"Gustavo F. Padovan" <padovan@...fusion.mobi>,
	Marcel Holtmann <marcel@...tmann.org>,
	linux-bluetooth@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [REGRESSION] resume takes 10s longer due to e1b6eb3 (Bluetooth:
 Increase HCI reset timeout ...)

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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/