Hello,
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
Kind regards,
--
Tomáš Janoušek, a.k.a. Liskni_si, http://work.lisk.in/
Hi Johan,
On Mon, Nov 21, 2011 at 05:25:06PM +0200, Johan Hedberg wrote:
> 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).
No, these don't help. :-(
--
Tomáš Janoušek, a.k.a. Liskni_si, http://work.lisk.in/
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
[ Adding linux-pm mailing list to CC as well. ]
Thanks,
Srivatsa S. Bhat
On 11/19/2011 12:10 AM, Tomáš Janoušek wrote:
> Hello,
>
> 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
>
> Kind regards,
> -- Tomáš Janoušek, a.k.a. Liskni_si, http://work.lisk.in/
>
>
> bt.txt
>
>
> Bus 001 Device 006: ID 0a5c:217f Broadcom Corp. Bluetooth Controller
> Device Descriptor:
> bLength 18
> bDescriptorType 1
> bcdUSB 2.00
> bDeviceClass 224 Wireless
> bDeviceSubClass 1 Radio Frequency
> bDeviceProtocol 1 Bluetooth
> bMaxPacketSize0 64
> idVendor 0x0a5c Broadcom Corp.
> idProduct 0x217f Bluetooth Controller
> bcdDevice 7.48
> iManufacturer 1 Broadcom Corp
> iProduct 2 Broadcom Bluetooth Device
> iSerial 3 CCAF78EC8B4F
> bNumConfigurations 1
> Configuration Descriptor:
> bLength 9
> bDescriptorType 2
> wTotalLength 216
> bNumInterfaces 4
> bConfigurationValue 1
> iConfiguration 0
> bmAttributes 0xe0
> Self Powered
> Remote Wakeup
> MaxPower 0mA
> Interface Descriptor:
> bLength 9
> bDescriptorType 4
> bInterfaceNumber 0
> bAlternateSetting 0
> bNumEndpoints 3
> bInterfaceClass 224 Wireless
> bInterfaceSubClass 1 Radio Frequency
> bInterfaceProtocol 1 Bluetooth
> iInterface 0
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x81 EP 1 IN
> bmAttributes 3
> Transfer Type Interrupt
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0010 1x 16 bytes
> bInterval 1
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x82 EP 2 IN
> bmAttributes 2
> Transfer Type Bulk
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0040 1x 64 bytes
> bInterval 1
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x02 EP 2 OUT
> bmAttributes 2
> Transfer Type Bulk
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0040 1x 64 bytes
> bInterval 1
> Interface Descriptor:
> bLength 9
> bDescriptorType 4
> bInterfaceNumber 1
> bAlternateSetting 0
> bNumEndpoints 2
> bInterfaceClass 224 Wireless
> bInterfaceSubClass 1 Radio Frequency
> bInterfaceProtocol 1 Bluetooth
> iInterface 0
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x83 EP 3 IN
> bmAttributes 1
> Transfer Type Isochronous
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0000 1x 0 bytes
> bInterval 1
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x03 EP 3 OUT
> bmAttributes 1
> Transfer Type Isochronous
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0000 1x 0 bytes
> bInterval 1
> Interface Descriptor:
> bLength 9
> bDescriptorType 4
> bInterfaceNumber 1
> bAlternateSetting 1
> bNumEndpoints 2
> bInterfaceClass 224 Wireless
> bInterfaceSubClass 1 Radio Frequency
> bInterfaceProtocol 1 Bluetooth
> iInterface 0
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x83 EP 3 IN
> bmAttributes 1
> Transfer Type Isochronous
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0009 1x 9 bytes
> bInterval 1
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x03 EP 3 OUT
> bmAttributes 1
> Transfer Type Isochronous
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0009 1x 9 bytes
> bInterval 1
> Interface Descriptor:
> bLength 9
> bDescriptorType 4
> bInterfaceNumber 1
> bAlternateSetting 2
> bNumEndpoints 2
> bInterfaceClass 224 Wireless
> bInterfaceSubClass 1 Radio Frequency
> bInterfaceProtocol 1 Bluetooth
> iInterface 0
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x83 EP 3 IN
> bmAttributes 1
> Transfer Type Isochronous
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0011 1x 17 bytes
> bInterval 1
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x03 EP 3 OUT
> bmAttributes 1
> Transfer Type Isochronous
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0011 1x 17 bytes
> bInterval 1
> Interface Descriptor:
> bLength 9
> bDescriptorType 4
> bInterfaceNumber 1
> bAlternateSetting 3
> bNumEndpoints 2
> bInterfaceClass 224 Wireless
> bInterfaceSubClass 1 Radio Frequency
> bInterfaceProtocol 1 Bluetooth
> iInterface 0
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x83 EP 3 IN
> bmAttributes 1
> Transfer Type Isochronous
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0020 1x 32 bytes
> bInterval 1
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x03 EP 3 OUT
> bmAttributes 1
> Transfer Type Isochronous
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0020 1x 32 bytes
> bInterval 1
> Interface Descriptor:
> bLength 9
> bDescriptorType 4
> bInterfaceNumber 1
> bAlternateSetting 4
> bNumEndpoints 2
> bInterfaceClass 224 Wireless
> bInterfaceSubClass 1 Radio Frequency
> bInterfaceProtocol 1 Bluetooth
> iInterface 0
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x83 EP 3 IN
> bmAttributes 1
> Transfer Type Isochronous
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0040 1x 64 bytes
> bInterval 1
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x03 EP 3 OUT
> bmAttributes 1
> Transfer Type Isochronous
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0040 1x 64 bytes
> bInterval 1
> Interface Descriptor:
> bLength 9
> bDescriptorType 4
> bInterfaceNumber 1
> bAlternateSetting 5
> bNumEndpoints 2
> bInterfaceClass 224 Wireless
> bInterfaceSubClass 1 Radio Frequency
> bInterfaceProtocol 1 Bluetooth
> iInterface 0
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x83 EP 3 IN
> bmAttributes 1
> Transfer Type Isochronous
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0040 1x 64 bytes
> bInterval 1
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x03 EP 3 OUT
> bmAttributes 1
> Transfer Type Isochronous
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0040 1x 64 bytes
> bInterval 1
> Interface Descriptor:
> bLength 9
> bDescriptorType 4
> bInterfaceNumber 2
> bAlternateSetting 0
> bNumEndpoints 2
> bInterfaceClass 255 Vendor Specific Class
> bInterfaceSubClass 255 Vendor Specific Subclass
> bInterfaceProtocol 255 Vendor Specific Protocol
> iInterface 0
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x84 EP 4 IN
> bmAttributes 2
> Transfer Type Bulk
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0020 1x 32 bytes
> bInterval 1
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x04 EP 4 OUT
> bmAttributes 2
> Transfer Type Bulk
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0020 1x 32 bytes
> bInterval 1
> Interface Descriptor:
> bLength 9
> bDescriptorType 4
> bInterfaceNumber 3
> bAlternateSetting 0
> bNumEndpoints 0
> bInterfaceClass 254 Application Specific Interface
> bInterfaceSubClass 1 Device Firmware Update
> bInterfaceProtocol 1
> iInterface 0
> Device Firmware Upgrade Interface Descriptor:
> bLength 7
> bDescriptorType 33
> bmAttributes 7
> Will Not Detach
> Manifestation Tolerant
> Upload Supported
> Download Supported
> wDetachTimeout 5000 milliseconds
> wTransferSize 64 bytes
> Device Status: 0x0001
> Self Powered
>
Hi Tomáš,
> Tell me what you need and how can I get that, and I'm all yours.
We need to figure out why command complete event to reset command is not
received and we get timeout for your bt chip.
So first please provide kernel debug logs and hcidump while resuming (with
timeout set to 10s). Also for kernel logs please make sure you have kernel
prints timestamps enabled.
hcidump -t
kernel:
echo "module bluetooth +pf" >/sys/kernel/debug/dynamic_debug/control
echo "module btusb +pf" >/sys/kernel/debug/dynamic_debug/control
--
Szymon K. Janc
[email protected] // GG: 1383435
Hi Szymon,
* Szymon Janc <[email protected]> [2011-12-23 21:43:20 +0100]:
> On Friday 23 December 2011 17:54:29 Gustavo Padovan wrote:
>=20
> Hi,
>=20
> > > On Mon, Nov 21, 2011 at 05:25:06PM +0200, Johan Hedberg wrote:
> > > > It might be worth to try out the two patches I just sent to
> > > > linux-bluetooth for HCI command failure tracking. They make sure th=
at
> > > > failures are properly caught which should help avoid triggering the
> > > > timeout in certain scenarios (and yours might be one of them).
> > >=20
> > > No, these don't help. :-(
> >=20
> > Is this still happening? If yes I'm going to revert this patch.
>=20
> I kindly ask to not revert this patch yet as this will bring back issue o=
n my=20
> CSR dongle.
>=20
> If this regression still happening I can try investigate it next week (as=
long=20
> as Tom=C3=A1=C5=A1 is willing to provide more detailed logs and do some t=
ests if=20
> needed).
Sure, we can figure out what is going wrong for both of you, but until this
commit will reverted for safety.
Gustavo
Hi Tom=C3=A1=C5=A1,
* Tom=C3=A1=C5=A1 Janou=C5=A1ek <[email protected]> [2011-12-23 21:48:49 +0100]:
> Hello,
>=20
> On Fri, Dec 23, 2011 at 09:43:20PM +0100, Szymon Janc wrote:
> > > Is this still happening? If yes I'm going to revert this patch.
>=20
> Yes, it is.
The commit is now reverted. It should be mainline before the 3.2 release.
Gustavo
Hello,
On Fri, Dec 23, 2011 at 09:43:20PM +0100, Szymon Janc wrote:
> > Is this still happening? If yes I'm going to revert this patch.
Yes, it is.
> I kindly ask to not revert this patch yet as this will bring back issue on my
> CSR dongle.
As far as I'm concerned, I don't mind either way. There's a trivial
workaround and I didn't have to think about this ever since I applied it.
> If this regression still happening I can try investigate it next week (as long
> as Tomáš is willing to provide more detailed logs and do some tests if
> needed).
Tell me what you need and how can I get that, and I'm all yours.
Regards,
--
Tomáš Janoušek, a.k.a. Liskni_si, http://work.lisk.in/
On Friday 23 December 2011 17:54:29 Gustavo Padovan wrote:
Hi,
> > On Mon, Nov 21, 2011 at 05:25:06PM +0200, Johan Hedberg wrote:
> > > 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).
> >
> > No, these don't help. :-(
>
> Is this still happening? If yes I'm going to revert this patch.
I kindly ask to not revert this patch yet as this will bring back issue on my
CSR dongle.
If this regression still happening I can try investigate it next week (as long
as Tomáš is willing to provide more detailed logs and do some tests if
needed).
--
Szymon K. Janc
[email protected] // GG: 1383435
Hi Tom=C3=A1=C5=A1,
* Tom=C3=A1=C5=A1 Janou=C5=A1ek <[email protected]> [2011-11-21 22:15:07 +0100]:
> Hi Johan,
>=20
> On Mon, Nov 21, 2011 at 05:25:06PM +0200, Johan Hedberg wrote:
> > 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).
>=20
> No, these don't help. :-(
Is this still happening? If yes I'm going to revert this patch.
Gustavo
Hi,
On Sun, Jan 08, 2012 at 10:14:50PM +0100, Szymon Janc wrote:
> > > Tell me what you need and how can I get that, and I'm all yours.
> >
> > We need to figure out why command complete event to reset command is not
> > received and we get timeout for your bt chip.
>
> Any chance to get those logs?
I'm sorry, I've been quite busy lately. I'll try what I can do, but no sooner
than the weekend (and even that is quite optimistic). :-(
--
Tomáš Janoušek, a.k.a. Liskni_si, http://work.lisk.in/
Hi Tomáš,
> > Tell me what you need and how can I get that, and I'm all yours.
>
> We need to figure out why command complete event to reset command is not
> received and we get timeout for your bt chip.
Any chance to get those logs?
--
Szymon K. Janc
[email protected]
Hi,
On Sun, Feb 12, 2012 at 05:49:31PM +0100, Szymon Janc wrote:
> Can you try with this patch applied:
> http://git.kernel.org/?p=linux/kernel/git/jh/bluetooth-
> next.git;a=commit;h=30a824d82726f4d10105e5f8c1afa7ebcda17523
> ?
Yes. It no longer waits 10 seconds. Bluetooth works fine both before and after
suspend/resume (just so you don't have to ask). Thanks.
--
Tomáš Janoušek, a.k.a. Liskni_si, http://work.lisk.in/
Hi,
> I'm attaching dmesg and hcidump output.
>
> I'm sorry for the delay, I did not have a kernel with dynamic_debug enabled
> and I didn't have time to reboot and lose my open terminals. Now I updated
> to today's kernel snapshot and enabled debugging, so as long as I don't
> have to reboot, I should be able to react quickly. :-)
Can you try with this patch applied:
http://git.kernel.org/?p=linux/kernel/git/jh/bluetooth-
next.git;a=commit;h=30a824d82726f4d10105e5f8c1afa7ebcda17523
?
--
Szymon K. Janc
[email protected]
Hi,
On Wed, Dec 28, 2011 at 08:21:04PM +0100, Szymon Janc wrote:
> We need to figure out why command complete event to reset command is not
> received and we get timeout for your bt chip.
>
> So first please provide kernel debug logs and hcidump while resuming (with
> timeout set to 10s). Also for kernel logs please make sure you have kernel
> prints timestamps enabled.
>
> hcidump -t
>
> kernel:
> echo "module bluetooth +pf" >/sys/kernel/debug/dynamic_debug/control
> echo "module btusb +pf" >/sys/kernel/debug/dynamic_debug/control
I'm attaching dmesg and hcidump output.
I'm sorry for the delay, I did not have a kernel with dynamic_debug enabled
and I didn't have time to reboot and lose my open terminals. Now I updated to
today's kernel snapshot and enabled debugging, so as long as I don't have to
reboot, I should be able to react quickly. :-)
Regards,
--
Tomáš Janoušek, a.k.a. Liskni_si, http://work.lisk.in/