From: Michael Schmitt <hidden> Date: 2011-11-18 15:28:32
Hi list,
as bugzilla.kernel.org seems to be down right now I thought about
reporting directly to lkml but then I saw a bt-specific list and... here
we are.
I have a Bluetooth USB-Stick that does not work anymore with more recent
2.6 and 3.x kernels. I have another stick which works ok on all kernels
(at least with those I run / tested ;))
When plugged in, the USB-LED lights up permanently (no blinking), the
bluetooth LED is off. It does not show up anywhere apart from hciconfig
which reports it to be down and a hciconfig hci1 up times out after a
few seconds.
adrastea:~# hcitool dev
Devices:
hci0 11:11:11:11:11:11
adrastea:~# hciconfig
hci0: Type: BR/EDR Bus: USB
BD Address: 11:11:11:11:11:11 ACL MTU: 678:8 SCO MTU: 48:10
UP RUNNING PSCAN ISCAN
RX bytes:1461 acl:0 sco:0 events:44 errors:0
TX bytes:697 acl:0 sco:0 commands:44 errors:0
hci1: Type: BR/EDR Bus: USB
BD Address: 00:04:0E:8C:E2:93 ACL MTU: 120:20 SCO MTU: 24:5
DOWN
RX bytes:1086 acl:0 sco:0 events:39 errors:0
TX bytes:171 acl:0 sco:0 commands:39 errors:0
adrastea:~# hciconfig hci1 up
Can't init device hci1: Connection timed out (110)
adrastea:~#
I never bisected an issue, but if necessary I will try it out. But sure,
I prefer that someone (Mr. Holtmann?) just has an heureka!-moment and
knows the second he reads this report what went wrong in what patch /
enhancement. :)
And as said (to make it utterly clear) the device works with older
kernels. Tested and approved with kernel 2.6.32 (on Debian squeeze) and
ist not physically broken.
Greetings
Michael
P.S.: Here the lsusb -v output for that device (if the usb-id is not
enough):
Bus 004 Device 003: ID 057c:3800 AVM GmbH BlueFRITZ! Bluetooth Stick
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 255 Vendor Specific Class
bDeviceSubClass 255 Vendor Specific Subclass
bDeviceProtocol 255 Vendor Specific Protocol
bMaxPacketSize0 64
idVendor 0x057c AVM GmbH
idProduct 0x3800 BlueFRITZ! Bluetooth Stick
bcdDevice 15.00
iManufacturer 1 Bluetooth Device
iProduct 2 Bluetooth Device
iSerial 3 93E28C0E0400
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 177
bNumInterfaces 2
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xa0
(Bus Powered)
Remote Wakeup
MaxPower 200mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 3
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 255 Vendor Specific Subclass
bInterfaceProtocol 255 Vendor Specific Protocol
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 0
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 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
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 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 255 Vendor Specific Class
bInterfaceSubClass 255 Vendor Specific Subclass
bInterfaceProtocol 255 Vendor Specific Protocol
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 255 Vendor Specific Class
bInterfaceSubClass 255 Vendor Specific Subclass
bInterfaceProtocol 255 Vendor Specific Protocol
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 255 Vendor Specific Class
bInterfaceSubClass 255 Vendor Specific Subclass
bInterfaceProtocol 255 Vendor Specific Protocol
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 0x0019 1x 25 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 0x0019 1x 25 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 4
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 0x83 EP 3 IN
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0021 1x 33 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 0x0021 1x 33 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 5
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 0x83 EP 3 IN
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0031 1x 49 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 0x0031 1x 49 bytes
bInterval 1
Device Status: 0x0000
(Bus Powered)
I'm pretty sure we'll at least need to see the hcidump output for the
initialization sequence of this adapter (i.e. start hcidump before
calling hciconfig hci0 up) and show us the output. Which Bluetooth
version does this adapter support and how old is it?
Johan
I'm pretty sure we'll at least need to see the hcidump output for the
initialization sequence of this adapter (i.e. start hcidump before
calling hciconfig hci0 up) and show us the output. Which Bluetooth
version does this adapter support and how old is it?
Johan
Hi Johann,
let me fire up a machine that runs 2.6.32 (Debian squeeze) and where it
works... or is there a way to get the bt-version it supports with the
"broken" kernel? And no idea how old it is... at least some years as I
got it for free from a buddy some time ago. It is from a AVM
BlueTooth-ISDN-set which was in a box in the cellar and never used by
the original owner (that was years ago too).
Anyway, here is the hcidump output as requested. Only the timespan since
issueing hciconfig hci0 up and error message displayed in terminal:
adrastea:~# hcidump
HCI sniffer - Bluetooth packet analyzer ver 2.1
device: hci0 snap_len: 1028 filter: 0xffffffff
< HCI Command: Reset (0x03|0x0003) plen 0
> HCI Event: Command Complete (0x0e) plen 4
Reset (0x03|0x0003) ncmd 1
status 0x00
< HCI Command: Read Local Supported Features (0x04|0x0003) plen 0
> HCI Event: Command Complete (0x0e) plen 12
Read Local Supported Features (0x04|0x0003) ncmd 1
status 0x00
Features: 0xff 0xff 0x05 0x00 0x18 0x18 0x00 0x00
< HCI Command: Read Local Version Information (0x04|0x0001) plen 0
> HCI Event: Command Complete (0x0e) plen 12
Read Local Version Information (0x04|0x0001) ncmd 1
status 0x00
HCI Version: 1.2 (0x2) HCI Revision: 0x2006
LMP Version: 1.2 (0x2) LMP Subversion: 0x1806
Manufacturer: AVM Berlin (31)
< HCI Command: Read Buffer Size (0x04|0x0005) plen 0
> HCI Event: Command Complete (0x0e) plen 11
Read Buffer Size (0x04|0x0005) ncmd 1
status 0x00
ACL MTU 120:20 SCO MTU 24:5
< HCI Command: Read BD ADDR (0x04|0x0009) plen 0
> HCI Event: Command Complete (0x0e) plen 10
Read BD ADDR (0x04|0x0009) ncmd 1
status 0x00 bdaddr 00:04:0E:8C:E2:93
< HCI Command: Read Class of Device (0x03|0x0023) plen 0
> HCI Event: Command Complete (0x0e) plen 7
Read Class of Device (0x03|0x0023) ncmd 1
status 0x00 class 0x000000
< HCI Command: Read Local Name (0x03|0x0014) plen 0
> HCI Event: Command Complete (0x0e) plen 252
Read Local Name (0x03|0x0014) ncmd 1
status 0x00 name ''
< HCI Command: Read Voice Setting (0x03|0x0025) plen 0
> HCI Event: Command Complete (0x0e) plen 6
Read Voice Setting (0x03|0x0025) ncmd 1
status 0x00 voice setting 0x0060
< HCI Command: Set Event Filter (0x03|0x0005) plen 1
type 0 condition 0
Clear all filters
> HCI Event: Command Complete (0x0e) plen 4
Set Event Filter (0x03|0x0005) ncmd 1
status 0x00
< HCI Command: Write Connection Accept Timeout (0x03|0x0016) plen 2
timeout 32000
> HCI Event: Command Complete (0x0e) plen 4
Write Connection Accept Timeout (0x03|0x0016) ncmd 1
status 0x00
< HCI Command: Delete Stored Link Key (0x03|0x0012) plen 7
bdaddr 00:00:00:00:00:00 all 1
> HCI Event: Command Complete (0x0e) plen 6
Delete Stored Link Key (0x03|0x0012) ncmd 1
status 0x00 deleted 0
< HCI Command: Set Event Mask (0x03|0x0001) plen 8
Mask: 0xfffffbff07180000
> HCI Event: Command Complete (0x0e) plen 4
Set Event Mask (0x03|0x0001) ncmd 1
status 0x00
< HCI Command: Read Local Supported Commands (0x04|0x0002) plen 0
> HCI Event: Command Status (0x0f) plen 4
Read Local Supported Commands (0x04|0x0002) status 0x01 ncmd 1
Error: Unknown HCI Command
greetings
Michael
I'm pretty sure we'll at least need to see the hcidump output for the
initialization sequence of this adapter (i.e. start hcidump before
calling hciconfig hci0 up) and show us the output. Which Bluetooth
version does this adapter support and how old is it?
Johan
I am not sure if this is the right version you were talking about, but
here it is (from the squeeze box):
mschmitt@sogo:~$ /usr/sbin/hciconfig -a
hci0: Type: BR/EDR Bus: USB
BD Address: 11:11:11:11:11:11 ACL MTU: 678:8 SCO MTU: 48:10
UP RUNNING PSCAN
RX bytes:969 acl:0 sco:0 events:27 errors:0
TX bytes:361 acl:0 sco:0 commands:27 errors:0
Features: 0xbf 0xfe 0x8d 0x78 0x08 0x18 0x00 0x00
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
Link policy: RSWITCH HOLD SNIFF PARK
Link mode: SLAVE ACCEPT
Name: 'sogo-0'
Class: 0x4a0100
Service Classes: Networking, Capturing, Telephony
Device Class: Computer, Uncategorized
HCI Version: 1.2 (0x2) Revision: 0x1fe
LMP Version: 1.2 (0x2) Subversion: 0x1fe
Manufacturer: Integrated System Solution Corp. (57)
greetings
Michael
From: Johan Hedberg <hidden> Date: 2011-11-18 16:21:11
Hi Michael,
On Fri, Nov 18, 2011, Michael Schmitt wrote:
< HCI Command: Read Local Version Information (0x04|0x0001) plen 0
quoted
HCI Event: Command Complete (0x0e) plen 12
Read Local Version Information (0x04|0x0001) ncmd 1
status 0x00
HCI Version: 1.2 (0x2) HCI Revision: 0x2006
LMP Version: 1.2 (0x2) LMP Subversion: 0x1806
Manufacturer: AVM Berlin (31)
Ok, so this is a 1.2 adapter.
< HCI Command: Read Local Supported Commands (0x04|0x0002) plen 0
quoted
HCI Event: Command Status (0x0f) plen 4
Read Local Supported Commands (0x04|0x0002) status 0x01 ncmd 1
Error: Unknown HCI Command
This is the reason why you're getting a timeout. Since the adapter
claims to support Bluetooth version 1.2 it should also support this HCI
command, so from that perspective it's not conforming to the
specification. Right now the kernel (lib/bluetooth/hci_event.c) is
completely missing a command status handler for this command. If such a
handler was in place instead of a timeout you would be getting an
immediate error (the kernel maps this HCI status code to EBADRQC).
However, since this is also not acceptable behavior (as the adapter
still wouldn't work for you) I suspect the need for some
adapter-specific quirk is in place or then the kernel should just ignore
any errors for HCI_Read_Local_Supported_Commands.
Johan
From: Michael Schmitt <hidden> Date: 2011-11-18 16:34:17
Am 18.11.2011 17:21, schrieb Johan Hedberg:
Hi Michael,
On Fri, Nov 18, 2011, Michael Schmitt wrote:
quoted
< HCI Command: Read Local Version Information (0x04|0x0001) plen 0
quoted
HCI Event: Command Complete (0x0e) plen 12
Read Local Version Information (0x04|0x0001) ncmd 1
status 0x00
HCI Version: 1.2 (0x2) HCI Revision: 0x2006
LMP Version: 1.2 (0x2) LMP Subversion: 0x1806
Manufacturer: AVM Berlin (31)
Ok, so this is a 1.2 adapter.
quoted
< HCI Command: Read Local Supported Commands (0x04|0x0002) plen 0
quoted
HCI Event: Command Status (0x0f) plen 4
Read Local Supported Commands (0x04|0x0002) status 0x01 ncmd 1
Error: Unknown HCI Command
This is the reason why you're getting a timeout. Since the adapter
claims to support Bluetooth version 1.2 it should also support this HCI
command, so from that perspective it's not conforming to the
specification. Right now the kernel (lib/bluetooth/hci_event.c) is
completely missing a command status handler for this command. If such a
handler was in place instead of a timeout you would be getting an
immediate error (the kernel maps this HCI status code to EBADRQC).
However, since this is also not acceptable behavior (as the adapter
still wouldn't work for you) I suspect the need for some
adapter-specific quirk is in place or then the kernel should just ignore
any errors for HCI_Read_Local_Supported_Commands.
Johan
Thanks for the input. But do you know why the device works with older
kernel / userland? As Debian stable may be old, but not THAT old ;)
(bluetooth 1.2 was released somewhere around 2005 I think).
So, and what do we do from here on? Btw. I did mix up the two bt-sticks
I have so the last info was from the wrong stick. Here is the right info
but it looks almost the same (at least the version numbers...):
mschmitt@sogo:~$ /usr/sbin/hciconfig -a
hci0: Type: BR/EDR Bus: USB
BD Address: 00:04:0E:8C:E2:93 ACL MTU: 120:20 SCO MTU: 24:5
UP RUNNING PSCAN ISCAN
RX bytes:695 acl:0 sco:0 events:23 errors:0
TX bytes:97 acl:0 sco:0 commands:23 errors:0
Features: 0xff 0xff 0x05 0x00 0x18 0x18 0x00 0x00
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
Link policy:
Link mode: SLAVE ACCEPT
Name: ''
Class: 0x4a0000
Service Classes: Networking, Capturing, Telephony
Device Class: Miscellaneous,
HCI Version: 1.2 (0x2) Revision: 0x2006
LMP Version: 1.2 (0x2) Subversion: 0x1806
Manufacturer: AVM Berlin (31)
greetings
Michael
From: Johan Hedberg <hidden> Date: 2011-11-18 20:30:19
HI Michael,
On Fri, Nov 18, 2011, Michael Schmitt wrote:
Thanks for the input. But do you know why the device works with
older kernel / userland?>
Probably because the list of supported commands wasn't previously
requested as part of the adapter init sequence, or because the kernel
code didn't actually wait for all commands to complete before notifying
success to user space (I know the latter is at least true since I
submitted a patch for it).
So, and what do we do from here on?
Well, the attached patch will at least make sure that the failure of
this command is correctly detected so you get an immediate error instead
of a timeout. The next step is to decide whether to do a quirk for your
specific adapter or to make it a general rule that errors for this
particular HCI command are ignored (for that we'd need feedback from the
real kernel experts like Marcel and Gustavo).
Johan
From: Michael Schmitt <hidden> Date: 2011-11-20 15:27:59
Am 18.11.2011 21:30, schrieb Johan Hedberg:
HI Michael,
On Fri, Nov 18, 2011, Michael Schmitt wrote:
quoted
Thanks for the input. But do you know why the device works with
older kernel / userland?>
Probably because the list of supported commands wasn't previously
requested as part of the adapter init sequence, or because the kernel
code didn't actually wait for all commands to complete before notifying
success to user space (I know the latter is at least true since I
submitted a patch for it).
So that means, if the bt-stack in the kernel would ignore the successful
completion of those "what protocol version do you understand"-commands
all bt-related stuff with the stick would work nevertheless?
quoted
So, and what do we do from here on?
Well, the attached patch will at least make sure that the failure of
this command is correctly detected so you get an immediate error instead
of a timeout. The next step is to decide whether to do a quirk for your
specific adapter or to make it a general rule that errors for this
particular HCI command are ignored (for that we'd need feedback from the
real kernel experts like Marcel and Gustavo).
But apparently none of them had the urge to actually respond in this
ml-thread yet. :) Let's see, I try to poke them "mildly" in cc'ing them...
General speaking, the bt-stick in question is old (at least 5 years or
so) and I have another (working) stick here, so there is no immediate
adversity for me. But I guess as this stick is from major bt-accessoirs
supplier from germany (AVM GmbH Berlin) this hardware may be around for
many users for a fairly long time. But then again... it seems to be a
hardware-bug...
Anyway, I guess it would ne nice to have it "fixed" someday. :)
Greetings
Michael
From: Andrei Emeltchenko <hidden> Date: 2011-11-21 08:57:06
Hi Johan,
On Fri, Nov 18, 2011 at 06:21:11PM +0200, Johan Hedberg wrote:
Hi Michael,
On Fri, Nov 18, 2011, Michael Schmitt wrote:
quoted
< HCI Command: Read Local Version Information (0x04|0x0001) plen 0
quoted
HCI Event: Command Complete (0x0e) plen 12
Read Local Version Information (0x04|0x0001) ncmd 1
status 0x00
HCI Version: 1.2 (0x2) HCI Revision: 0x2006
LMP Version: 1.2 (0x2) LMP Subversion: 0x1806
Manufacturer: AVM Berlin (31)
Ok, so this is a 1.2 adapter.
quoted
< HCI Command: Read Local Supported Commands (0x04|0x0002) plen 0
quoted
HCI Event: Command Status (0x0f) plen 4
Read Local Supported Commands (0x04|0x0002) status 0x01 ncmd 1
Error: Unknown HCI Command
This is the reason why you're getting a timeout. Since the adapter
claims to support Bluetooth version 1.2 it should also support this HCI
command, so from that perspective it's not conforming to the
Apparently we check for "Bluetooth Core Specification 1.1"
Shall we change to:
specification. Right now the kernel (lib/bluetooth/hci_event.c) is
completely missing a command status handler for this command. If such a
handler was in place instead of a timeout you would be getting an
immediate error (the kernel maps this HCI status code to EBADRQC).
However, since this is also not acceptable behavior (as the adapter
still wouldn't work for you) I suspect the need for some
adapter-specific quirk is in place or then the kernel should just ignore
any errors for HCI_Read_Local_Supported_Commands.
Johan
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Andrei Emeltchenko <hidden> Date: 2011-11-21 09:12:55
On Mon, Nov 21, 2011 at 10:57:06AM +0200, Andrei Emeltchenko wrote:
Hi Johan,
On Fri, Nov 18, 2011 at 06:21:11PM +0200, Johan Hedberg wrote:
quoted
Hi Michael,
On Fri, Nov 18, 2011, Michael Schmitt wrote:
quoted
< HCI Command: Read Local Version Information (0x04|0x0001) plen 0
quoted
HCI Event: Command Complete (0x0e) plen 12
Read Local Version Information (0x04|0x0001) ncmd 1
status 0x00
HCI Version: 1.2 (0x2) HCI Revision: 0x2006
LMP Version: 1.2 (0x2) LMP Subversion: 0x1806
Manufacturer: AVM Berlin (31)
Ok, so this is a 1.2 adapter.
quoted
< HCI Command: Read Local Supported Commands (0x04|0x0002) plen 0
quoted
HCI Event: Command Status (0x0f) plen 4
Read Local Supported Commands (0x04|0x0002) status 0x01 ncmd 1
Error: Unknown HCI Command
This is the reason why you're getting a timeout. Since the adapter
claims to support Bluetooth version 1.2 it should also support this HCI
command, so from that perspective it's not conforming to the
Apparently we check for "Bluetooth Core Specification 1.1"
Sorry, it is already checking for it.
Discard the code below.
Best regards
Andrei Emeltchenko
specification. Right now the kernel (lib/bluetooth/hci_event.c) is
completely missing a command status handler for this command. If such a
handler was in place instead of a timeout you would be getting an
immediate error (the kernel maps this HCI status code to EBADRQC).
However, since this is also not acceptable behavior (as the adapter
still wouldn't work for you) I suspect the need for some
adapter-specific quirk is in place or then the kernel should just ignore
any errors for HCI_Read_Local_Supported_Commands.
Johan
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
< HCI Command: Read Local Version Information (0x04|0x0001) plen 0
quoted
HCI Event: Command Complete (0x0e) plen 12
Read Local Version Information (0x04|0x0001) ncmd 1
status 0x00
HCI Version: 1.2 (0x2) HCI Revision: 0x2006
LMP Version: 1.2 (0x2) LMP Subversion: 0x1806
Manufacturer: AVM Berlin (31)
Ok, so this is a 1.2 adapter.
quoted
< HCI Command: Read Local Supported Commands (0x04|0x0002) plen 0
quoted
HCI Event: Command Status (0x0f) plen 4
Read Local Supported Commands (0x04|0x0002) status 0x01 ncmd 1
Error: Unknown HCI Command
This is the reason why you're getting a timeout. Since the adapter
claims to support Bluetooth version 1.2 it should also support this HCI
command, so from that perspective it's not conforming to the
Apparently we check for "Bluetooth Core Specification 1.1"
Shall we change to:
0x00 is 1.0b and 0x01 is 1.1. So you are changing the check from 1.2 to
2.0. The command was introduced with 1.2 actually.
The only real change that needs to be done here is to check hci_ver
instead of lmp_ver. This command is a HCI feature and not a LMP feature
actually.
Regards
Marcel
From: Andrei Emeltchenko <hidden> Date: 2011-11-21 10:22:02
Hi Marcel,
On Mon, Nov 21, 2011 at 10:13:49AM +0100, Marcel Holtmann wrote:
Hi Andrei,
quoted
quoted
On Fri, Nov 18, 2011, Michael Schmitt wrote:
quoted
< HCI Command: Read Local Version Information (0x04|0x0001) plen 0
quoted
HCI Event: Command Complete (0x0e) plen 12
Read Local Version Information (0x04|0x0001) ncmd 1
status 0x00
HCI Version: 1.2 (0x2) HCI Revision: 0x2006
LMP Version: 1.2 (0x2) LMP Subversion: 0x1806
Manufacturer: AVM Berlin (31)
Ok, so this is a 1.2 adapter.
quoted
< HCI Command: Read Local Supported Commands (0x04|0x0002) plen 0
quoted
HCI Event: Command Status (0x0f) plen 4
Read Local Supported Commands (0x04|0x0002) status 0x01 ncmd 1
Error: Unknown HCI Command
This is the reason why you're getting a timeout. Since the adapter
claims to support Bluetooth version 1.2 it should also support this HCI
command, so from that perspective it's not conforming to the
Apparently we check for "Bluetooth Core Specification 1.1"
Shall we change to:
From: Johan Hedberg <hidden> Date: 2011-11-21 10:35:47
Hi Marcel,
On Mon, Nov 21, 2011, Marcel Holtmann wrote:
quoted
quoted
On Fri, Nov 18, 2011, Michael Schmitt wrote:
quoted
< HCI Command: Read Local Version Information (0x04|0x0001) plen 0
quoted
HCI Event: Command Complete (0x0e) plen 12
Read Local Version Information (0x04|0x0001) ncmd 1
status 0x00
HCI Version: 1.2 (0x2) HCI Revision: 0x2006
LMP Version: 1.2 (0x2) LMP Subversion: 0x1806
Manufacturer: AVM Berlin (31)
Ok, so this is a 1.2 adapter.
quoted
< HCI Command: Read Local Supported Commands (0x04|0x0002) plen 0
quoted
HCI Event: Command Status (0x0f) plen 4
Read Local Supported Commands (0x04|0x0002) status 0x01 ncmd 1
Error: Unknown HCI Command
This is the reason why you're getting a timeout. Since the adapter
claims to support Bluetooth version 1.2 it should also support this HCI
command, so from that perspective it's not conforming to the
Apparently we check for "Bluetooth Core Specification 1.1"
Shall we change to:
0x00 is 1.0b and 0x01 is 1.1. So you are changing the check from 1.2 to
2.0. The command was introduced with 1.2 actually.
The only real change that needs to be done here is to check hci_ver
instead of lmp_ver. This command is a HCI feature and not a LMP feature
actually.
That doesn't help much with this particular dongle though since the LMP
and HCI versions are the same. What I'd propose is the patch which I
already attached to an earlier email in this thread and then either a
quirk for this adapter or just generally ignoring the
HCI_Read_Local_Commands failure status.
Johan
< HCI Command: Read Local Version Information (0x04|0x0001) plen 0
quoted
HCI Event: Command Complete (0x0e) plen 12
Read Local Version Information (0x04|0x0001) ncmd 1
status 0x00
HCI Version: 1.2 (0x2) HCI Revision: 0x2006
LMP Version: 1.2 (0x2) LMP Subversion: 0x1806
Manufacturer: AVM Berlin (31)
Ok, so this is a 1.2 adapter.
quoted
< HCI Command: Read Local Supported Commands (0x04|0x0002) plen 0
quoted
HCI Event: Command Status (0x0f) plen 4
Read Local Supported Commands (0x04|0x0002) status 0x01 ncmd 1
Error: Unknown HCI Command
This is the reason why you're getting a timeout. Since the adapter
claims to support Bluetooth version 1.2 it should also support this HCI
command, so from that perspective it's not conforming to the
Apparently we check for "Bluetooth Core Specification 1.1"
Shall we change to:
0x00 is 1.0b and 0x01 is 1.1. So you are changing the check from 1.2 to
2.0. The command was introduced with 1.2 actually.
Can we define in bluetooth.h something like:
#define BLUETOOTH_LMP_VER_1.1 1
#define BLUETOOTH_LMP_VER_1.2 2
yes, but just leave LMP out of it. Just do BLUETOOTH_VER_1_1 or similar.
Even the . in the define will not work out.
quoted
The only real change that needs to be done here is to check hci_ver
instead of lmp_ver. This command is a HCI feature and not a LMP feature
actually.
Maybe same define for HCI_VER ?
They are identical. So one is enough. They just have a different
meaning. The LMP is air protocol version and HCI is host controller
version. In most cases they are the same, but not have to be.
Regards
Marcel
< HCI Command: Read Local Version Information (0x04|0x0001) plen 0
quoted
HCI Event: Command Complete (0x0e) plen 12
Read Local Version Information (0x04|0x0001) ncmd 1
status 0x00
HCI Version: 1.2 (0x2) HCI Revision: 0x2006
LMP Version: 1.2 (0x2) LMP Subversion: 0x1806
Manufacturer: AVM Berlin (31)
Ok, so this is a 1.2 adapter.
quoted
< HCI Command: Read Local Supported Commands (0x04|0x0002) plen 0
quoted
HCI Event: Command Status (0x0f) plen 4
Read Local Supported Commands (0x04|0x0002) status 0x01 ncmd 1
Error: Unknown HCI Command
This is the reason why you're getting a timeout. Since the adapter
claims to support Bluetooth version 1.2 it should also support this HCI
command, so from that perspective it's not conforming to the
Apparently we check for "Bluetooth Core Specification 1.1"
Shall we change to:
0x00 is 1.0b and 0x01 is 1.1. So you are changing the check from 1.2 to
2.0. The command was introduced with 1.2 actually.
The only real change that needs to be done here is to check hci_ver
instead of lmp_ver. This command is a HCI feature and not a LMP feature
actually.
That doesn't help much with this particular dongle though since the LMP
and HCI versions are the same. What I'd propose is the patch which I
already attached to an earlier email in this thread and then either a
quirk for this adapter or just generally ignoring the
HCI_Read_Local_Commands failure status.
using lmp_ver instead of hci_ver is still a bug, but fair enough it is a
different bug.
I am fine just allowing Read_Local_Commands to fail. However that will
serious limit some features since we have to be using the result more
often in the future. But luckily that does not matter for 1.2 controller
at all.
Regards
Marcel
From: Johan Hedberg <hidden> Date: 2011-11-21 15:21:11
Hi Marcel,
On Mon, Nov 21, 2011, Marcel Holtmann wrote:
quoted
That doesn't help much with this particular dongle though since the LMP
and HCI versions are the same. What I'd propose is the patch which I
already attached to an earlier email in this thread and then either a
quirk for this adapter or just generally ignoring the
HCI_Read_Local_Commands failure status.
using lmp_ver instead of hci_ver is still a bug, but fair enough it is a
different bug.
I am fine just allowing Read_Local_Commands to fail. However that will
serious limit some features since we have to be using the result more
often in the future. But luckily that does not matter for 1.2 controller
at all.
Ok. I just sent two patches for this. I have a hunch these might also
fix the recently reported "resume takes longer due to increased timeout"
regression report.
Johan
From: Michael Schmitt <hidden> Date: 2011-11-27 10:04:31
Just as a follow-up question (as I did not get a clear conclusion out of
the discussion and it seems to me the "discussion" did stop without a
real conclusion)...
What is the plan right now? Will there be a patch upstream (in the
kernel) at some point? Is it not clear how to fix that (broken?)
hardware driver-wise yet? Should I test something?
regards
Michael
From: Andrei Emeltchenko <hidden> Date: 2011-11-28 08:42:08
Hi Michael,
On Sun, Nov 27, 2011 at 11:04:31AM +0100, Michael Schmitt wrote:
Just as a follow-up question (as I did not get a clear conclusion
out of the discussion and it seems to me the "discussion" did stop
without a real conclusion)...
What is the plan right now? Will there be a patch upstream (in the
kernel) at some point? Is it not clear how to fix that (broken?)
hardware driver-wise yet? Should I test something?
regards
Michael
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html