Re: Linux 2.6.39

Re: Linux 2.6.39

[Ed Tomlinson]

On Wednesday 25 May 2011 06:54:54 Corey Boyle wrote:
> > On Mon, May 23, 2011 at 06:08:36PM -0400, ext Ed Tomlinson wrote:
> > > On Saturday 21 May 2011 16:31:00 Ed Tomlinson wrote:
> > > > On Saturday 21 May 2011 13:56:20 Milan Oravec wrote:
> > > > > Hi Linus, I'm sorry bothering you, but my usb-bluetooth dongle stop working in
> > > > > 2.6.39 kernel series.
> > > > > I know it is nothing ground breaking but it is bug.
> > > > > I'm using this hardware from 2.6.11 kernel series.
> > > > > Details are included in this thread:
> > > > >
> > > > > https://lkml.org/lkml/2011/4/18/481
> > > > >
> > > > > I hope I'm doing nothing false writing this email.
> > > >
> > > > Same device, same problem here.
> > > >
> > > > You are not alone
> > >
> > > I had some time this afternood so I tried bisecting without much luck.  I ended up \
> > > somewhere rc1 ish with a system that would paniced during boot.  Here is the bisect \
> > > log incase it helps:
> > > # bad: [61c4f2c81c61f73549928dfd9f3e8f26aa36a8cf] Linux 2.6.39
> > > # good: [521cb40b0c44418a4fd36dc633f575813d59a43d] Linux 2.6.38
> > > git bisect start 'v2.6.39' 'v2.6.38' '--' 'drivers/bluetooth'
> > > # bad: [7a6362800cb7d1d618a697a650c7aaed3eb39320] Merge \
> > > git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next-2.6 git bisect bad \
> > > 7a6362800cb7d1d618a697a650c7aaed3eb39320 # bad: \
> > > [0a0e9ae1bd788bc19adc4d4ae08c98b233697402] Merge branch 'master' of \
> > > master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6 git bisect bad \
> > > 0a0e9ae1bd788bc19adc4d4ae08c98b233697402 # skip: \
> > > [03c2d0e89409b59c1ec9d9511533cedc0b7aaa69] Bluetooth: Use usb_fill_int_urb() git \
> > > bisect skip 03c2d0e89409b59c1ec9d9511533cedc0b7aaa69 # skip: \
> > > [7f4b2b04c88377af30c022f36c060190182850fb] Bluetooth: Make hci a child of the \
> > > corresponding tty device. git bisect skip 7f4b2b04c88377af30c022f36c060190182850fb
> > > # skip: [84f0e17f78471857104a20dfc57711409f68d7bf] Bluetooth: ath3k: Avoid \
> > > duplication of code git bisect skip 84f0e17f78471857104a20dfc57711409f68d7bf
> > >
> > > Ring any bells for anyone?
> > >
> > > Probably should open a regression bug for this too....
> >
> > I think this is regression with d5859e22cd40b73164b3e5d8d5d796f96edcc6af
> > commit. Probably the code tries to enable something that is not supported.
> >
> > Could you pastebin hcidump while doing hciconfig hci0 up?

hcidump
HCI sniffer - Bluetooth packet analyzer ver 2.0
device: hci0 snap_len: 1028 filter: 0xffffffffffffffff
< 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 0x0f 0x00 0x00 0x00 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.1 (0x1) HCI Revision: 0x20d
    LMP Version: 1.1 (0x1) LMP Subversion: 0x20d
    Manufacturer: Cambridge Silicon Radio (10)
< 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 192:8 SCO MTU 64:8
< 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:0A:3A:55:07:5A
< 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 'grover-0'
< 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: 0xfffffbff00000000
> HCI Event: Command Complete (0x0e) plen 4
    Set Event Mask (0x03|0x0001) ncmd 1
    status 0x12
    Error: Invalid HCI Command Parameters

Thanks
Ed

> This sounds like it could be the same problem I mailed about here:
> http://marc.info/?l=linux-bluetooth&m=130610549726588&w=2.
> I still haven't determined why the HCI_OP_SET_EVENT_MASK command was failing.
> 
> Hope this helps!
> 
> 

Re: Linux 2.6.39

[Ville Tervo]

On Wed, May 25, 2011 at 07:11:17AM -0400, ext Ed Tomlinson wrote:
> On Wednesday 25 May 2011 06:54:54 Corey Boyle wrote:
> > > On Mon, May 23, 2011 at 06:08:36PM -0400, ext Ed Tomlinson wrote:
> > > > On Saturday 21 May 2011 16:31:00 Ed Tomlinson wrote:
> > > > > On Saturday 21 May 2011 13:56:20 Milan Oravec wrote:
> > > > > > Hi Linus, I'm sorry bothering you, but my usb-bluetooth dongle stop working in
> > > > > > 2.6.39 kernel series.
> > > > > > I know it is nothing ground breaking but it is bug.
> > > > > > I'm using this hardware from 2.6.11 kernel series.
> > > > > > Details are included in this thread:
> > > > > >
> > > > > > https://lkml.org/lkml/2011/4/18/481
> > > > > >
> > > > > > I hope I'm doing nothing false writing this email.
> > > > >
> > > > > Same device, same problem here.
> > > > >
> > > > > You are not alone
> > > >
> > > > I had some time this afternood so I tried bisecting without much luck.  I ended up \
> > > > somewhere rc1 ish with a system that would paniced during boot.  Here is the bisect \
> > > > log incase it helps:
> > > > # bad: [61c4f2c81c61f73549928dfd9f3e8f26aa36a8cf] Linux 2.6.39
> > > > # good: [521cb40b0c44418a4fd36dc633f575813d59a43d] Linux 2.6.38
> > > > git bisect start 'v2.6.39' 'v2.6.38' '--' 'drivers/bluetooth'
> > > > # bad: [7a6362800cb7d1d618a697a650c7aaed3eb39320] Merge \
> > > > git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next-2.6 git bisect bad \
> > > > 7a6362800cb7d1d618a697a650c7aaed3eb39320 # bad: \
> > > > [0a0e9ae1bd788bc19adc4d4ae08c98b233697402] Merge branch 'master' of \
> > > > master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6 git bisect bad \
> > > > 0a0e9ae1bd788bc19adc4d4ae08c98b233697402 # skip: \
> > > > [03c2d0e89409b59c1ec9d9511533cedc0b7aaa69] Bluetooth: Use usb_fill_int_urb() git \
> > > > bisect skip 03c2d0e89409b59c1ec9d9511533cedc0b7aaa69 # skip: \
> > > > [7f4b2b04c88377af30c022f36c060190182850fb] Bluetooth: Make hci a child of the \
> > > > corresponding tty device. git bisect skip 7f4b2b04c88377af30c022f36c060190182850fb
> > > > # skip: [84f0e17f78471857104a20dfc57711409f68d7bf] Bluetooth: ath3k: Avoid \
> > > > duplication of code git bisect skip 84f0e17f78471857104a20dfc57711409f68d7bf
> > > >
> > > > Ring any bells for anyone?
> > > >
> > > > Probably should open a regression bug for this too....
> > >
> > > I think this is regression with d5859e22cd40b73164b3e5d8d5d796f96edcc6af
> > > commit. Probably the code tries to enable something that is not supported.
> > >
> > > Could you pastebin hcidump while doing hciconfig hci0 up?

Some cutting done

> 
> hcidump
> HCI sniffer - Bluetooth packet analyzer ver 2.0
> < 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 0x0f 0x00 0x00 0x00 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.1 (0x1) HCI Revision: 0x20d
>     LMP Version: 1.1 (0x1) LMP Subversion: 0x20d
>     Manufacturer: Cambridge Silicon Radio (10)
> < HCI Command: Set Event Mask (0x03|0x0001) plen 8
>     Mask: 0xfffffbff00000000
> > HCI Event: Command Complete (0x0e) plen 4
>     Set Event Mask (0x03|0x0001) ncmd 1
>     status 0x12
>     Error: Invalid HCI Command Parameters
> 

Yes the HCI_OP_SET_EVENT_MASK cmd seems to be the source of problems. 

Maybe is rejects it because two reserved bits are being enabled. Could you try
this patch?

diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
index 19cd4af..e483e30 100644
--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -475,7 +475,7 @@ static void hci_setup_event_mask(struct hci_dev *hdev)
        /* The second byte is 0xff instead of 0x9f (two reserved bits
         * disabled) since a Broadcom 1.2 dongle doesn't respond to the
         * command otherwise */
-       u8 events[8] = { 0xff, 0xff, 0xfb, 0xff, 0x00, 0x00, 0x00, 0x00 };
+       u8 events[8] = { 0xff, 0x9f, 0xfb, 0xff, 0x00, 0x00, 0x00, 0x00 };
 
        /* Events for 1.2 and newer controllers */
        if (hdev->lmp_ver > 1) {


-- 
Ville

Re: Linux 2.6.39

[Corey Boyle]

On Wed, May 25, 2011 at 7:36 AM, Ville Tervo <ville.tervo@nokia.com> wrote:
> On Wed, May 25, 2011 at 07:11:17AM -0400, ext Ed Tomlinson wrote:
>> On Wednesday 25 May 2011 06:54:54 Corey Boyle wrote:
>> > > On Mon, May 23, 2011 at 06:08:36PM -0400, ext Ed Tomlinson wrote:
>> > > > On Saturday 21 May 2011 16:31:00 Ed Tomlinson wrote:
>> > > > > On Saturday 21 May 2011 13:56:20 Milan Oravec wrote:
>> > > > > > Hi Linus, I'm sorry bothering you, but my usb-bluetooth dongle stop working in
>> > > > > > 2.6.39 kernel series.
>> > > > > > I know it is nothing ground breaking but it is bug.
>> > > > > > I'm using this hardware from 2.6.11 kernel series.
>> > > > > > Details are included in this thread:
>> > > > > >
>> > > > > > https://lkml.org/lkml/2011/4/18/481
>> > > > > >
>> > > > > > I hope I'm doing nothing false writing this email.
>> > > > >
>> > > > > Same device, same problem here.
>> > > > >
>> > > > > You are not alone
>> > > >
>> > > > I had some time this afternood so I tried bisecting without much luck.  I ended up \
>> > > > somewhere rc1 ish with a system that would paniced during boot.  Here is the bisect \
>> > > > log incase it helps:
>> > > > # bad: [61c4f2c81c61f73549928dfd9f3e8f26aa36a8cf] Linux 2.6.39
>> > > > # good: [521cb40b0c44418a4fd36dc633f575813d59a43d] Linux 2.6.38
>> > > > git bisect start 'v2.6.39' 'v2.6.38' '--' 'drivers/bluetooth'
>> > > > # bad: [7a6362800cb7d1d618a697a650c7aaed3eb39320] Merge \
>> > > > git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next-2.6 git bisect bad \
>> > > > 7a6362800cb7d1d618a697a650c7aaed3eb39320 # bad: \
>> > > > [0a0e9ae1bd788bc19adc4d4ae08c98b233697402] Merge branch 'master' of \
>> > > > master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6 git bisect bad \
>> > > > 0a0e9ae1bd788bc19adc4d4ae08c98b233697402 # skip: \
>> > > > [03c2d0e89409b59c1ec9d9511533cedc0b7aaa69] Bluetooth: Use usb_fill_int_urb() git \
>> > > > bisect skip 03c2d0e89409b59c1ec9d9511533cedc0b7aaa69 # skip: \
>> > > > [7f4b2b04c88377af30c022f36c060190182850fb] Bluetooth: Make hci a child of the \
>> > > > corresponding tty device. git bisect skip 7f4b2b04c88377af30c022f36c060190182850fb
>> > > > # skip: [84f0e17f78471857104a20dfc57711409f68d7bf] Bluetooth: ath3k: Avoid \
>> > > > duplication of code git bisect skip 84f0e17f78471857104a20dfc57711409f68d7bf
>> > > >
>> > > > Ring any bells for anyone?
>> > > >
>> > > > Probably should open a regression bug for this too....
>> > >
>> > > I think this is regression with d5859e22cd40b73164b3e5d8d5d796f96edcc6af
>> > > commit. Probably the code tries to enable something that is not supported.
>> > >
>> > > Could you pastebin hcidump while doing hciconfig hci0 up?
>
> Some cutting done
>
>>
>> hcidump
>> HCI sniffer - Bluetooth packet analyzer ver 2.0
>> < 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 0x0f 0x00 0x00 0x00 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.1 (0x1) HCI Revision: 0x20d
>>     LMP Version: 1.1 (0x1) LMP Subversion: 0x20d
>>     Manufacturer: Cambridge Silicon Radio (10)
>> < HCI Command: Set Event Mask (0x03|0x0001) plen 8
>>     Mask: 0xfffffbff00000000
>> > HCI Event: Command Complete (0x0e) plen 4
>>     Set Event Mask (0x03|0x0001) ncmd 1
>>     status 0x12
>>     Error: Invalid HCI Command Parameters
>>
>
> Yes the HCI_OP_SET_EVENT_MASK cmd seems to be the source of problems.
>
> Maybe is rejects it because two reserved bits are being enabled. Could you try
> this patch?
>
> diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
> index 19cd4af..e483e30 100644
> --- a/net/bluetooth/hci_event.c
> +++ b/net/bluetooth/hci_event.c
> @@ -475,7 +475,7 @@ static void hci_setup_event_mask(struct hci_dev *hdev)
>        /* The second byte is 0xff instead of 0x9f (two reserved bits
>         * disabled) since a Broadcom 1.2 dongle doesn't respond to the
>         * command otherwise */
> -       u8 events[8] = { 0xff, 0xff, 0xfb, 0xff, 0x00, 0x00, 0x00, 0x00 };
> +       u8 events[8] = { 0xff, 0x9f, 0xfb, 0xff, 0x00, 0x00, 0x00, 0x00 };
>
>        /* Events for 1.2 and newer controllers */
>        if (hdev->lmp_ver > 1) {
>
>
> --
> Ville
>

No luck for me with a Microsoft Wireless Transceiver for Bluetooth.
Not sending the HCI_OP_SET_EVENT_MASK command at all seems to fix it,
but it seems to have negative effects on my devices battery life when
doing so.

Re: Linux 2.6.39

[Ed Tomlinson]

On Wednesday 25 May 2011 07:36:14 Ville Tervo wrote:
> On Wed, May 25, 2011 at 07:11:17AM -0400, ext Ed Tomlinson wrote:
> > On Wednesday 25 May 2011 06:54:54 Corey Boyle wrote:
> > > > On Mon, May 23, 2011 at 06:08:36PM -0400, ext Ed Tomlinson wrote:
> > > > > On Saturday 21 May 2011 16:31:00 Ed Tomlinson wrote:
> > > > > > On Saturday 21 May 2011 13:56:20 Milan Oravec wrote:
> > > > > > > Hi Linus, I'm sorry bothering you, but my usb-bluetooth dongle stop working in
> > > > > > > 2.6.39 kernel series.
> > > > > > > I know it is nothing ground breaking but it is bug.
> > > > > > > I'm using this hardware from 2.6.11 kernel series.
> > > > > > > Details are included in this thread:
> > > > > > >
> > > > > > > https://lkml.org/lkml/2011/4/18/481
> > > > > > >
> > > > > > > I hope I'm doing nothing false writing this email.
> > > > > >
> > > > > > Same device, same problem here.
> > > > > >
> > > > > > You are not alone
> > > > >
> > > > > I had some time this afternood so I tried bisecting without much luck.  I ended up \
> > > > > somewhere rc1 ish with a system that would paniced during boot.  Here is the bisect \
> > > > > log incase it helps:
> > > > > # bad: [61c4f2c81c61f73549928dfd9f3e8f26aa36a8cf] Linux 2.6.39
> > > > > # good: [521cb40b0c44418a4fd36dc633f575813d59a43d] Linux 2.6.38
> > > > > git bisect start 'v2.6.39' 'v2.6.38' '--' 'drivers/bluetooth'
> > > > > # bad: [7a6362800cb7d1d618a697a650c7aaed3eb39320] Merge \
> > > > > git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next-2.6 git bisect bad \
> > > > > 7a6362800cb7d1d618a697a650c7aaed3eb39320 # bad: \
> > > > > [0a0e9ae1bd788bc19adc4d4ae08c98b233697402] Merge branch 'master' of \
> > > > > master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6 git bisect bad \
> > > > > 0a0e9ae1bd788bc19adc4d4ae08c98b233697402 # skip: \
> > > > > [03c2d0e89409b59c1ec9d9511533cedc0b7aaa69] Bluetooth: Use usb_fill_int_urb() git \
> > > > > bisect skip 03c2d0e89409b59c1ec9d9511533cedc0b7aaa69 # skip: \
> > > > > [7f4b2b04c88377af30c022f36c060190182850fb] Bluetooth: Make hci a child of the \
> > > > > corresponding tty device. git bisect skip 7f4b2b04c88377af30c022f36c060190182850fb
> > > > > # skip: [84f0e17f78471857104a20dfc57711409f68d7bf] Bluetooth: ath3k: Avoid \
> > > > > duplication of code git bisect skip 84f0e17f78471857104a20dfc57711409f68d7bf
> > > > >
> > > > > Ring any bells for anyone?
> > > > >
> > > > > Probably should open a regression bug for this too....
> > > >
> > > > I think this is regression with d5859e22cd40b73164b3e5d8d5d796f96edcc6af
> > > > commit. Probably the code tries to enable something that is not supported.
> > > >
> > > > Could you pastebin hcidump while doing hciconfig hci0 up?
> 
> Some cutting done
> 
> > 
> > hcidump
> > HCI sniffer - Bluetooth packet analyzer ver 2.0
> > < 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 0x0f 0x00 0x00 0x00 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.1 (0x1) HCI Revision: 0x20d
> >     LMP Version: 1.1 (0x1) LMP Subversion: 0x20d
> >     Manufacturer: Cambridge Silicon Radio (10)
> > < HCI Command: Set Event Mask (0x03|0x0001) plen 8
> >     Mask: 0xfffffbff00000000
> > > HCI Event: Command Complete (0x0e) plen 4
> >     Set Event Mask (0x03|0x0001) ncmd 1
> >     status 0x12
> >     Error: Invalid HCI Command Parameters
> > 
> 
> Yes the HCI_OP_SET_EVENT_MASK cmd seems to be the source of problems. 
> 
> Maybe is rejects it because two reserved bits are being enabled. Could you try
> this patch?
> 
> diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
> index 19cd4af..e483e30 100644
> --- a/net/bluetooth/hci_event.c
> +++ b/net/bluetooth/hci_event.c
> @@ -475,7 +475,7 @@ static void hci_setup_event_mask(struct hci_dev *hdev)
>         /* The second byte is 0xff instead of 0x9f (two reserved bits
>          * disabled) since a Broadcom 1.2 dongle doesn't respond to the
>          * command otherwise */
> -       u8 events[8] = { 0xff, 0xff, 0xfb, 0xff, 0x00, 0x00, 0x00, 0x00 };
> +       u8 events[8] = { 0xff, 0x9f, 0xfb, 0xff, 0x00, 0x00, 0x00, 0x00 };
>  
>         /* Events for 1.2 and newer controllers */
>         if (hdev->lmp_ver > 1) {

No luck here - same results.

Thanks
Ed

RE: Linux 2.6.39

[Cufi, Carles]

On Wednesday 25 May 2011 07:36:14 Ville Tervo wrote:
> On Wed, May 25, 2011 at 07:11:17AM -0400, ext Ed Tomlinson wrote:
> > On Wednesday 25 May 2011 06:54:54 Corey Boyle wrote:
> > > > On Mon, May 23, 2011 at 06:08:36PM -0400, ext Ed Tomlinson wrote:
> > > > > On Saturday 21 May 2011 16:31:00 Ed Tomlinson wrote:
> > > > > > On Saturday 21 May 2011 13:56:20 Milan Oravec wrote:
> > > > > > > Hi Linus, I'm sorry bothering you, but my usb-bluetooth 
> > > > > > > dongle stop working in
> > > > > > > 2.6.39 kernel series.
> > > > > > > I know it is nothing ground breaking but it is bug.
> > > > > > > I'm using this hardware from 2.6.11 kernel series.
> > > > > > > Details are included in this thread:
> > > > > > >
> > > > > > > https://lkml.org/lkml/2011/4/18/481
> > > > > > >
> > > > > > > I hope I'm doing nothing false writing this email.
> > > > > >
> > > > > > Same device, same problem here.
> > > > > >
> > > > > > You are not alone
> > > > >
> > > > > I had some time this afternood so I tried bisecting without 
> > > > > much luck.  I ended up \ somewhere rc1 ish with a system that 
> > > > > would paniced during boot.  Here is the bisect \ log incase it helps:
> > > > > # bad: [61c4f2c81c61f73549928dfd9f3e8f26aa36a8cf] Linux 2.6.39 
> > > > > # good: [521cb40b0c44418a4fd36dc633f575813d59a43d] Linux 
> > > > > 2.6.38 git bisect start 'v2.6.39' 'v2.6.38' '--' 'drivers/bluetooth'
> > > > > # bad: [7a6362800cb7d1d618a697a650c7aaed3eb39320] Merge \
> > > > > git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next-2
> > > > > .6 git bisect bad \
> > > > > 7a6362800cb7d1d618a697a650c7aaed3eb39320 # bad: \ 
> > > > > [0a0e9ae1bd788bc19adc4d4ae08c98b233697402] Merge branch 
> > > > > 'master' of \
> > > > > master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6 git 
> > > > > bisect bad \
> > > > > 0a0e9ae1bd788bc19adc4d4ae08c98b233697402 # skip: \ 
> > > > > [03c2d0e89409b59c1ec9d9511533cedc0b7aaa69] Bluetooth: Use 
> > > > > usb_fill_int_urb() git \ bisect skip 
> > > > > 03c2d0e89409b59c1ec9d9511533cedc0b7aaa69 # skip: \ 
> > > > > [7f4b2b04c88377af30c022f36c060190182850fb] Bluetooth: Make hci 
> > > > > a child of the \ corresponding tty device. git bisect skip 
> > > > > 7f4b2b04c88377af30c022f36c060190182850fb
> > > > > # skip: [84f0e17f78471857104a20dfc57711409f68d7bf] Bluetooth: 
> > > > > ath3k: Avoid \ duplication of code git bisect skip 
> > > > > 84f0e17f78471857104a20dfc57711409f68d7bf
> > > > >
> > > > > Ring any bells for anyone?
> > > > >
> > > > > Probably should open a regression bug for this too....
> > > >
> > > > I think this is regression with 
> > > > d5859e22cd40b73164b3e5d8d5d796f96edcc6af
> > > > commit. Probably the code tries to enable something that is not supported.
> > > >
> > > > Could you pastebin hcidump while doing hciconfig hci0 up?
> 
> Some cutting done
> 
> > 
> > hcidump
> > HCI sniffer - Bluetooth packet analyzer ver 2.0 < 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 0x0f 0x00 0x00 0x00 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.1 (0x1) HCI Revision: 0x20d
> >     LMP Version: 1.1 (0x1) LMP Subversion: 0x20d
> >     Manufacturer: Cambridge Silicon Radio (10) < HCI Command: Set 
> > Event Mask (0x03|0x0001) plen 8
> >     Mask: 0xfffffbff00000000
> > > HCI Event: Command Complete (0x0e) plen 4
> >     Set Event Mask (0x03|0x0001) ncmd 1
> >     status 0x12
> >     Error: Invalid HCI Command Parameters
> > 
> 
> Yes the HCI_OP_SET_EVENT_MASK cmd seems to be the source of problems. 
> 
> Maybe is rejects it because two reserved bits are being enabled. Could 
> you try this patch?
> 
> diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c 
> index 19cd4af..e483e30 100644
> --- a/net/bluetooth/hci_event.c
> +++ b/net/bluetooth/hci_event.c
> @@ -475,7 +475,7 @@ static void hci_setup_event_mask(struct hci_dev *hdev)
>         /* The second byte is 0xff instead of 0x9f (two reserved bits
>          * disabled) since a Broadcom 1.2 dongle doesn't respond to the
>          * command otherwise */
> -       u8 events[8] = { 0xff, 0xff, 0xfb, 0xff, 0x00, 0x00, 0x00, 0x00 };
> +       u8 events[8] = { 0xff, 0x9f, 0xfb, 0xff, 0x00, 0x00, 0x00, 
> + 0x00 };
>  
>         /* Events for 1.2 and newer controllers */
>         if (hdev->lmp_ver > 1) {

> No luck here - same results.

For what it's worth:

With a (recent)CSR chipset, with 2.6.38 only Set Event Filter is used (with a 0 filter) and no Set Event Mask is sent at all. With Bluetooth-next, I get the following:

< HCI Command: Set Event Mask (0x03|0x0001) plen 8
    Mask: 0xfffffbff07f8bf3d
> HCI Event: Command Complete (0x0e) plen 4
    Set Event Mask (0x03|0x0001) ncmd 1
    status 0x00

So Set Event Mask actually seems to go through without any problems.

Carles

Re: Linux 2.6.39

[Corey Boyle]

On Wed, May 25, 2011 at 8:46 AM, Cufi, Carles <carles.cufi@nordicsemi.no> wrote:
>
>
> On Wednesday 25 May 2011 07:36:14 Ville Tervo wrote:
>> On Wed, May 25, 2011 at 07:11:17AM -0400, ext Ed Tomlinson wrote:
>> > On Wednesday 25 May 2011 06:54:54 Corey Boyle wrote:
>> > > > On Mon, May 23, 2011 at 06:08:36PM -0400, ext Ed Tomlinson wrote:
>> > > > > On Saturday 21 May 2011 16:31:00 Ed Tomlinson wrote:
>> > > > > > On Saturday 21 May 2011 13:56:20 Milan Oravec wrote:
>> > > > > > > Hi Linus, I'm sorry bothering you, but my usb-bluetooth
>> > > > > > > dongle stop working in
>> > > > > > > 2.6.39 kernel series.
>> > > > > > > I know it is nothing ground breaking but it is bug.
>> > > > > > > I'm using this hardware from 2.6.11 kernel series.
>> > > > > > > Details are included in this thread:
>> > > > > > >
>> > > > > > > https://lkml.org/lkml/2011/4/18/481
>> > > > > > >
>> > > > > > > I hope I'm doing nothing false writing this email.
>> > > > > >
>> > > > > > Same device, same problem here.
>> > > > > >
>> > > > > > You are not alone
>> > > > >
>> > > > > I had some time this afternood so I tried bisecting without
>> > > > > much luck.  I ended up \ somewhere rc1 ish with a system that
>> > > > > would paniced during boot.  Here is the bisect \ log incase it helps:
>> > > > > # bad: [61c4f2c81c61f73549928dfd9f3e8f26aa36a8cf] Linux 2.6.39
>> > > > > # good: [521cb40b0c44418a4fd36dc633f575813d59a43d] Linux
>> > > > > 2.6.38 git bisect start 'v2.6.39' 'v2.6.38' '--' 'drivers/bluetooth'
>> > > > > # bad: [7a6362800cb7d1d618a697a650c7aaed3eb39320] Merge \
>> > > > > git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next-2
>> > > > > .6 git bisect bad \
>> > > > > 7a6362800cb7d1d618a697a650c7aaed3eb39320 # bad: \
>> > > > > [0a0e9ae1bd788bc19adc4d4ae08c98b233697402] Merge branch
>> > > > > 'master' of \
>> > > > > master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6 git
>> > > > > bisect bad \
>> > > > > 0a0e9ae1bd788bc19adc4d4ae08c98b233697402 # skip: \
>> > > > > [03c2d0e89409b59c1ec9d9511533cedc0b7aaa69] Bluetooth: Use
>> > > > > usb_fill_int_urb() git \ bisect skip
>> > > > > 03c2d0e89409b59c1ec9d9511533cedc0b7aaa69 # skip: \
>> > > > > [7f4b2b04c88377af30c022f36c060190182850fb] Bluetooth: Make hci
>> > > > > a child of the \ corresponding tty device. git bisect skip
>> > > > > 7f4b2b04c88377af30c022f36c060190182850fb
>> > > > > # skip: [84f0e17f78471857104a20dfc57711409f68d7bf] Bluetooth:
>> > > > > ath3k: Avoid \ duplication of code git bisect skip
>> > > > > 84f0e17f78471857104a20dfc57711409f68d7bf
>> > > > >
>> > > > > Ring any bells for anyone?
>> > > > >
>> > > > > Probably should open a regression bug for this too....
>> > > >
>> > > > I think this is regression with
>> > > > d5859e22cd40b73164b3e5d8d5d796f96edcc6af
>> > > > commit. Probably the code tries to enable something that is not supported.
>> > > >
>> > > > Could you pastebin hcidump while doing hciconfig hci0 up?
>>
>> Some cutting done
>>
>> >
>> > hcidump
>> > HCI sniffer - Bluetooth packet analyzer ver 2.0 < 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 0x0f 0x00 0x00 0x00 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.1 (0x1) HCI Revision: 0x20d
>> >     LMP Version: 1.1 (0x1) LMP Subversion: 0x20d
>> >     Manufacturer: Cambridge Silicon Radio (10) < HCI Command: Set
>> > Event Mask (0x03|0x0001) plen 8
>> >     Mask: 0xfffffbff00000000
>> > > HCI Event: Command Complete (0x0e) plen 4
>> >     Set Event Mask (0x03|0x0001) ncmd 1
>> >     status 0x12
>> >     Error: Invalid HCI Command Parameters
>> >
>>
>> Yes the HCI_OP_SET_EVENT_MASK cmd seems to be the source of problems.
>>
>> Maybe is rejects it because two reserved bits are being enabled. Could
>> you try this patch?
>>
>> diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
>> index 19cd4af..e483e30 100644
>> --- a/net/bluetooth/hci_event.c
>> +++ b/net/bluetooth/hci_event.c
>> @@ -475,7 +475,7 @@ static void hci_setup_event_mask(struct hci_dev *hdev)
>>         /* The second byte is 0xff instead of 0x9f (two reserved bits
>>          * disabled) since a Broadcom 1.2 dongle doesn't respond to the
>>          * command otherwise */
>> -       u8 events[8] = { 0xff, 0xff, 0xfb, 0xff, 0x00, 0x00, 0x00, 0x00 };
>> +       u8 events[8] = { 0xff, 0x9f, 0xfb, 0xff, 0x00, 0x00, 0x00,
>> + 0x00 };
>>
>>         /* Events for 1.2 and newer controllers */
>>         if (hdev->lmp_ver > 1) {
>
>> No luck here - same results.
>
> For what it's worth:
>
> With a (recent)CSR chipset, with 2.6.38 only Set Event Filter is used (with a 0 filter) and no Set Event Mask is sent at all. With Bluetooth-next, I get the following:
>
> < HCI Command: Set Event Mask (0x03|0x0001) plen 8
>    Mask: 0xfffffbff07f8bf3d
>> HCI Event: Command Complete (0x0e) plen 4
>    Set Event Mask (0x03|0x0001) ncmd 1
>    status 0x00
>
> So Set Event Mask actually seems to go through without any problems.
>
> Carles
>

My adapter is from 2002 so I'm guessing it either doesn't support Set
Event Mask at all, or is very sensitive about the values it receives.
I tried to figure out what chip it is using by disassembling the
dongle, but the chip seems to be covered by a metal case which is
soldered to the board and I'd rather not try to rip it off.

Any thoughts on how to further debug this apart from trying all
possible values of event mask?

RE: Linux 2.6.39

[Cufi, Carles]

On Wed, May 25, 2011 at 8:46 AM, Cufi, Carles <carles.cufi@nordicsemi.no> wrote:
>
>
> On Wednesday 25 May 2011 07:36:14 Ville Tervo wrote:
>> On Wed, May 25, 2011 at 07:11:17AM -0400, ext Ed Tomlinson wrote:
>> > On Wednesday 25 May 2011 06:54:54 Corey Boyle wrote:
>> > > > On Mon, May 23, 2011 at 06:08:36PM -0400, ext Ed Tomlinson wrote:
>> > > > > On Saturday 21 May 2011 16:31:00 Ed Tomlinson wrote:
>> > > > > > On Saturday 21 May 2011 13:56:20 Milan Oravec wrote:
>> > > > > > > Hi Linus, I'm sorry bothering you, but my usb-bluetooth 
>> > > > > > > dongle stop working in
>> > > > > > > 2.6.39 kernel series.
>> > > > > > > I know it is nothing ground breaking but it is bug.
>> > > > > > > I'm using this hardware from 2.6.11 kernel series.
>> > > > > > > Details are included in this thread:
>> > > > > > >
>> > > > > > > https://lkml.org/lkml/2011/4/18/481
>> > > > > > >
>> > > > > > > I hope I'm doing nothing false writing this email.
>> > > > > >
>> > > > > > Same device, same problem here.
>> > > > > >
>> > > > > > You are not alone
>> > > > >
>> > > > > I had some time this afternood so I tried bisecting without 
>> > > > > much luck.  I ended up \ somewhere rc1 ish with a system that 
>> > > > > would paniced during boot.  Here is the bisect \ log incase it helps:
>> > > > > # bad: [61c4f2c81c61f73549928dfd9f3e8f26aa36a8cf] Linux 
>> > > > > 2.6.39 # good: [521cb40b0c44418a4fd36dc633f575813d59a43d] 
>> > > > > Linux
>> > > > > 2.6.38 git bisect start 'v2.6.39' 'v2.6.38' '--' 'drivers/bluetooth'
>> > > > > # bad: [7a6362800cb7d1d618a697a650c7aaed3eb39320] Merge \
>> > > > > git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next-
>> > > > > 2
>> > > > > .6 git bisect bad \
>> > > > > 7a6362800cb7d1d618a697a650c7aaed3eb39320 # bad: \ 
>> > > > > [0a0e9ae1bd788bc19adc4d4ae08c98b233697402] Merge branch 
>> > > > > 'master' of \
>> > > > > master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6 git 
>> > > > > bisect bad \
>> > > > > 0a0e9ae1bd788bc19adc4d4ae08c98b233697402 # skip: \ 
>> > > > > [03c2d0e89409b59c1ec9d9511533cedc0b7aaa69] Bluetooth: Use
>> > > > > usb_fill_int_urb() git \ bisect skip
>> > > > > 03c2d0e89409b59c1ec9d9511533cedc0b7aaa69 # skip: \ 
>> > > > > [7f4b2b04c88377af30c022f36c060190182850fb] Bluetooth: Make 
>> > > > > hci a child of the \ corresponding tty device. git bisect 
>> > > > > skip 7f4b2b04c88377af30c022f36c060190182850fb
>> > > > > # skip: [84f0e17f78471857104a20dfc57711409f68d7bf] Bluetooth:
>> > > > > ath3k: Avoid \ duplication of code git bisect skip 
>> > > > > 84f0e17f78471857104a20dfc57711409f68d7bf
>> > > > >
>> > > > > Ring any bells for anyone?
>> > > > >
>> > > > > Probably should open a regression bug for this too....
>> > > >
>> > > > I think this is regression with 
>> > > > d5859e22cd40b73164b3e5d8d5d796f96edcc6af
>> > > > commit. Probably the code tries to enable something that is not supported.
>> > > >
>> > > > Could you pastebin hcidump while doing hciconfig hci0 up?
>>
>> Some cutting done
>>
>> >
>> > hcidump
>> > HCI sniffer - Bluetooth packet analyzer ver 2.0 < 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 0x0f 0x00 0x00 0x00 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.1 (0x1) HCI Revision: 0x20d
>> >     LMP Version: 1.1 (0x1) LMP Subversion: 0x20d
>> >     Manufacturer: Cambridge Silicon Radio (10) < HCI Command: Set 
>> > Event Mask (0x03|0x0001) plen 8
>> >     Mask: 0xfffffbff00000000
>> > > HCI Event: Command Complete (0x0e) plen 4
>> >     Set Event Mask (0x03|0x0001) ncmd 1
>> >     status 0x12
>> >     Error: Invalid HCI Command Parameters
>> >
>>
>> Yes the HCI_OP_SET_EVENT_MASK cmd seems to be the source of problems.
>>
>> Maybe is rejects it because two reserved bits are being enabled. 
>> Could you try this patch?
>>
>> diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c 
>> index 19cd4af..e483e30 100644
>> --- a/net/bluetooth/hci_event.c
>> +++ b/net/bluetooth/hci_event.c
>> @@ -475,7 +475,7 @@ static void hci_setup_event_mask(struct hci_dev 
>> *hdev)
>>         /* The second byte is 0xff instead of 0x9f (two reserved bits
>>          * disabled) since a Broadcom 1.2 dongle doesn't respond to 
>> the
>>          * command otherwise */
>> -       u8 events[8] = { 0xff, 0xff, 0xfb, 0xff, 0x00, 0x00, 0x00, 
>> 0x00 };
>> +       u8 events[8] = { 0xff, 0x9f, 0xfb, 0xff, 0x00, 0x00, 0x00,
>> + 0x00 };
>>
>>         /* Events for 1.2 and newer controllers */
>>         if (hdev->lmp_ver > 1) {
>
>> No luck here - same results.
>
> For what it's worth:
>
> With a (recent)CSR chipset, with 2.6.38 only Set Event Filter is used (with a 0 filter) and no Set Event Mask is sent at all. With Bluetooth-next, I get the following:
>
> < HCI Command: Set Event Mask (0x03|0x0001) plen 8
>    Mask: 0xfffffbff07f8bf3d
>> HCI Event: Command Complete (0x0e) plen 4
>    Set Event Mask (0x03|0x0001) ncmd 1
>    status 0x00
>
> So Set Event Mask actually seems to go through without any problems.
>
> Carles
>
>My adapter is from 2002 so I'm guessing it either doesn't support Set Event Mask at all, or is very sensitive about the values it >receives.

Set Event Mask has been in the Bluetooth Spec since day 1, so it must be the bitmask, which has been extended with each new spec release to cover newly added events. Looking at the latest spec, and judging by the year your chipset was released in (it probably is a 1.1 compliant chipset) I believe that 0x000000008FFFFFFF is the highest event mask it would support (up until and including Page Scan Repetition Mode Change Event), but since I don't have the old 1.1 spec around I may be one or two bits off.

Carles

RE: Linux 2.6.39

[Tom Allebrandi]

-----Original Message-----
From: linux-bluetooth-owner@vger.kernel.org
[mailto:linux-bluetooth-owner@vger.kernel.org] On Behalf Of Cufi, Carles
Sent: Wednesday, May 25, 2011 7:15 AM
To: corey@kansanian.com
Cc: Ed Tomlinson; Ville Tervo; Bluettooth Linux;
linux-kernel@vger.kernel.org
Subject: RE: Linux 2.6.39

(Snipping...)
On Wed, May 25, 2011 at 8:46 AM, Cufi, Carles <carles.cufi@nordicsemi.no>
wrote:
> On Wednesday 25 May 2011 07:36:14 Ville Tervo wrote:
>> On Wed, May 25, 2011 at 07:11:17AM -0400, ext Ed Tomlinson wrote:
>> > On Wednesday 25 May 2011 06:54:54 Corey Boyle wrote:
>> > > > On Mon, May 23, 2011 at 06:08:36PM -0400, ext Ed Tomlinson wrote:
>> > > > > On Saturday 21 May 2011 16:31:00 Ed Tomlinson wrote:
>> > > > > > On Saturday 21 May 2011 13:56:20 Milan Oravec wrote:
...
>> > 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.1 (0x1) HCI Revision: 0x20d
*************************
>> >     LMP Version: 1.1 (0x1) LMP Subversion: 0x20d
*************************
>> >     Manufacturer: Cambridge Silicon Radio (10) < HCI Command: Set 
>> > Event Mask (0x03|0x0001) plen 8
>> >     Mask: 0xfffffbff00000000
*************************
>> > > HCI Event: Command Complete (0x0e) plen 4
>> >     Set Event Mask (0x03|0x0001) ncmd 1
>> >     status 0x12
>> >     Error: Invalid HCI Command Parameters
>
>Set Event Mask has been in the Bluetooth Spec since day 1, so it must be
the bitmask, which has been extended with each new spec release to cover
newly >added events. Looking at the latest spec, and judging by the year
your chipset was released in (it probably is a 1.1 compliant chipset) I
believe that >0x000000008FFFFFFF is the highest event mask it would support
(up until and including Page Scan Repetition Mode Change Event), but since I
don't have the >old 1.1 spec around I may be one or two bits off.

The device appears to have identified itself as CSR firmware using Bluetooth
version 1.1.

I do happen to have the 1.1 spec lying around :-), for Set_Event_Mask it
says

0x0000000100000000
To                                          Reserved for future use
0x8000000000000000

0x00000000FFFFFFFF	Default (All events enabled)

The mask above looks ok (no undefined bits), but are they supposed to be
displayed in that order? (IOW, are the bytes in correct order?)

--- tom
tom allebrandi
wyrles@ytram.com

RE: Linux 2.6.39

[Cufi, Carles]

 (Snipping...)
On Wed, May 25, 2011 at 8:46 AM, Cufi, Carles <carles.cufi@nordicsemi.no>
wrote:
> On Wednesday 25 May 2011 07:36:14 Ville Tervo wrote:
>> On Wed, May 25, 2011 at 07:11:17AM -0400, ext Ed Tomlinson wrote:
>> > On Wednesday 25 May 2011 06:54:54 Corey Boyle wrote:
>> > > > On Mon, May 23, 2011 at 06:08:36PM -0400, ext Ed Tomlinson wrote:
>> > > > > On Saturday 21 May 2011 16:31:00 Ed Tomlinson wrote:
>> > > > > > On Saturday 21 May 2011 13:56:20 Milan Oravec wrote:
...
>> > 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.1 (0x1) HCI Revision: 0x20d
*************************
>> >     LMP Version: 1.1 (0x1) LMP Subversion: 0x20d
*************************
>> >     Manufacturer: Cambridge Silicon Radio (10) < HCI Command: Set 
>> > Event Mask (0x03|0x0001) plen 8
>> >     Mask: 0xfffffbff00000000
*************************
>> > > HCI Event: Command Complete (0x0e) plen 4
>> >     Set Event Mask (0x03|0x0001) ncmd 1
>> >     status 0x12
>> >     Error: Invalid HCI Command Parameters
>
>Set Event Mask has been in the Bluetooth Spec since day 1, so it must 
>be
>the bitmask, which has been extended with each new spec release to cover newly >added events. Looking at the latest spec, and judging >by the year your chipset was released in (it probably is a 1.1 compliant chipset) I believe that >0x000000008FFFFFFF is the highest >event mask it would support (up until and including Page Scan Repetition Mode Change Event), but since I don't have the >old 1.1 spec >around I may be one or two bits off.

>The device appears to have identified itself as CSR firmware using Bluetooth version 1.1.
>I do happen to have the 1.1 spec lying around :-), for Set_Event_Mask it says
>0x0000000100000000
>To                                          Reserved for future use
>0x8000000000000000
>0x00000000FFFFFFFF	Default (All events enabled)
>The mask above looks ok (no undefined bits), but are they supposed to be displayed in that order? (IOW, are the bytes in correct >order?)

The HCI spec lists this as a 64-bit number but it must be sent in Little Endian to the controller, hence the reverse order in Ville Tervo's patch earlier in the email thread. 

Carles

RE: Linux 2.6.39

[Tom Allebrandi]

> >> > Read Local Version Information (0x04|0x0001) plen 0
> >> > > HCI Event: Command Complete (0x0e) plen 12
> >> >     Read Local Version Information (0x04|0x0001) ncmd 1
> >> >     HCI Version: 1.1 (0x1) HCI Revision: 0x20d
> >> >     LMP Version: 1.1 (0x1) LMP Subversion: 0x20d
> >> >     Manufacturer: Cambridge Silicon Radio (10) < HCI Command: Set
> >> > Event Mask (0x03|0x0001) plen 8
> >> >     Mask: 0xfffffbff00000000
> 
> The HCI spec lists this as a 64-bit number but it must be sent in Little
Endian to
> the controller, hence the reverse order in Ville Tervo's patch earlier in
the
> email thread.

That I knew. I was just checking that 64 bit values are displayed left to
right since other little endian values (0x020d, 0x0001 above) are displayed
right to left.

Cheers!

--- tom
tom allebrandi
wyrles@ytram.com

Re: Linux 2.6.39

[Corey Boyle]

On Wed, May 25, 2011 at 12:31 PM, Tom Allebrandi <wyrles@ytram.com> wrote:
> -----Original Message-----
> From: linux-bluetooth-owner@vger.kernel.org
> [mailto:linux-bluetooth-owner@vger.kernel.org] On Behalf Of Cufi, Carles
> Sent: Wednesday, May 25, 2011 7:15 AM
> To: corey@kansanian.com
> Cc: Ed Tomlinson; Ville Tervo; Bluettooth Linux;
> linux-kernel@vger.kernel.org
> Subject: RE: Linux 2.6.39
>
> (Snipping...)
> On Wed, May 25, 2011 at 8:46 AM, Cufi, Carles <carles.cufi@nordicsemi.no>
> wrote:
>> On Wednesday 25 May 2011 07:36:14 Ville Tervo wrote:
>>> On Wed, May 25, 2011 at 07:11:17AM -0400, ext Ed Tomlinson wrote:
>>> > On Wednesday 25 May 2011 06:54:54 Corey Boyle wrote:
>>> > > > On Mon, May 23, 2011 at 06:08:36PM -0400, ext Ed Tomlinson wrote:
>>> > > > > On Saturday 21 May 2011 16:31:00 Ed Tomlinson wrote:
>>> > > > > > On Saturday 21 May 2011 13:56:20 Milan Oravec wrote:
> ...
>>> > 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.1 (0x1) HCI Revision: 0x20d
> *************************
>>> >     LMP Version: 1.1 (0x1) LMP Subversion: 0x20d
> *************************
>>> >     Manufacturer: Cambridge Silicon Radio (10) < HCI Command: Set
>>> > Event Mask (0x03|0x0001) plen 8
>>> >     Mask: 0xfffffbff00000000
> *************************
>>> > > HCI Event: Command Complete (0x0e) plen 4
>>> >     Set Event Mask (0x03|0x0001) ncmd 1
>>> >     status 0x12
>>> >     Error: Invalid HCI Command Parameters
>>
>>Set Event Mask has been in the Bluetooth Spec since day 1, so it must be
> the bitmask, which has been extended with each new spec release to cover
> newly >added events. Looking at the latest spec, and judging by the year
> your chipset was released in (it probably is a 1.1 compliant chipset) I
> believe that >0x000000008FFFFFFF is the highest event mask it would support
> (up until and including Page Scan Repetition Mode Change Event), but since I
> don't have the >old 1.1 spec around I may be one or two bits off.
>
> The device appears to have identified itself as CSR firmware using Bluetooth
> version 1.1.
>
> I do happen to have the 1.1 spec lying around :-), for Set_Event_Mask it
> says
>
> 0x0000000100000000
> To                                          Reserved for future use
> 0x8000000000000000
>
> 0x00000000FFFFFFFF      Default (All events enabled)
>

I am beginning to think that my adapter simply does not support this
command.  I have tried with all the suggested bitmasks, all zeros, all
ones, all combinations where a single bit is set, etc.  I'm not sure
where to go from here other than add a flag which incidates that
certain devices don't support this command so it can be skipped.
Again, the only way I have gotten it to work is by not sending the
command at all.  Thoughts?

Re: Linux 2.6.39

[Ville Tervo]

On Wed, May 25, 2011 at 09:11:19PM -0400, ext Corey Boyle wrote:
> On Wed, May 25, 2011 at 12:31 PM, Tom Allebrandi <wyrles@ytram.com> wrote:
> > -----Original Message-----
> > From: linux-bluetooth-owner@vger.kernel.org
> > [mailto:linux-bluetooth-owner@vger.kernel.org] On Behalf Of Cufi, Carles
> > Sent: Wednesday, May 25, 2011 7:15 AM
> > To: corey@kansanian.com
> > Cc: Ed Tomlinson; Ville Tervo; Bluettooth Linux;
> > linux-kernel@vger.kernel.org
> > Subject: RE: Linux 2.6.39
> >
> > (Snipping...)
> > On Wed, May 25, 2011 at 8:46 AM, Cufi, Carles <carles.cufi@nordicsemi.no>
> > wrote:
> >> On Wednesday 25 May 2011 07:36:14 Ville Tervo wrote:
> >>> On Wed, May 25, 2011 at 07:11:17AM -0400, ext Ed Tomlinson wrote:
> >>> > On Wednesday 25 May 2011 06:54:54 Corey Boyle wrote:
> >>> > > > On Mon, May 23, 2011 at 06:08:36PM -0400, ext Ed Tomlinson wrote:
> >>> > > > > On Saturday 21 May 2011 16:31:00 Ed Tomlinson wrote:
> >>> > > > > > On Saturday 21 May 2011 13:56:20 Milan Oravec wrote:
> > ...
> >>> > 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.1 (0x1) HCI Revision: 0x20d
> > *************************
> >>> >     LMP Version: 1.1 (0x1) LMP Subversion: 0x20d
> > *************************
> >>> >     Manufacturer: Cambridge Silicon Radio (10) < HCI Command: Set
> >>> > Event Mask (0x03|0x0001) plen 8
> >>> >     Mask: 0xfffffbff00000000
> > *************************
> >>> > > HCI Event: Command Complete (0x0e) plen 4
> >>> >     Set Event Mask (0x03|0x0001) ncmd 1
> >>> >     status 0x12
> >>> >     Error: Invalid HCI Command Parameters
> >>
> >>Set Event Mask has been in the Bluetooth Spec since day 1, so it must be
> > the bitmask, which has been extended with each new spec release to cover
> > newly >added events. Looking at the latest spec, and judging by the year
> > your chipset was released in (it probably is a 1.1 compliant chipset) I
> > believe that >0x000000008FFFFFFF is the highest event mask it would support
> > (up until and including Page Scan Repetition Mode Change Event), but since I
> > don't have the >old 1.1 spec around I may be one or two bits off.
> >
> > The device appears to have identified itself as CSR firmware using Bluetooth
> > version 1.1.
> >
> > I do happen to have the 1.1 spec lying around :-), for Set_Event_Mask it
> > says
> >
> > 0x0000000100000000
> > To                                          Reserved for future use
> > 0x8000000000000000
> >
> > 0x00000000FFFFFFFF      Default (All events enabled)
> >
> 
> I am beginning to think that my adapter simply does not support this
> command.  I have tried with all the suggested bitmasks, all zeros, all
> ones, all combinations where a single bit is set, etc.  I'm not sure
> where to go from here other than add a flag which incidates that
> certain devices don't support this command so it can be skipped.
> Again, the only way I have gotten it to work is by not sending the
> command at all.  Thoughts?

I also played a bit with 1.1 CSR dongle and couldn't find any mask that would
be accepted. I think this command can be left out for older than 1.2 devices.

Following patch should do it. Could you verify it. I don't have access to old
hw ATM.

diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
index 19cd4af..86d1e26 100644
--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -477,14 +477,16 @@ static void hci_setup_event_mask(struct hci_dev *hdev)
 	 * command otherwise */
 	u8 events[8] = { 0xff, 0xff, 0xfb, 0xff, 0x00, 0x00, 0x00, 0x00 };
 
-	/* Events for 1.2 and newer controllers */
-	if (hdev->lmp_ver > 1) {
-		events[4] |= 0x01; /* Flow Specification Complete */
-		events[4] |= 0x02; /* Inquiry Result with RSSI */
-		events[4] |= 0x04; /* Read Remote Extended Features Complete */
-		events[5] |= 0x08; /* Synchronous Connection Complete */
-		events[5] |= 0x10; /* Synchronous Connection Changed */
-	}
+	/* CSR 1.1 dongles does not accept any bitfield so don't try to set
+	 * any event mask for pre 1.2 devices */
+	if (hdev->lmp_ver <= 1)
+		return;
+
+	events[4] |= 0x01; /* Flow Specification Complete */
+	events[4] |= 0x02; /* Inquiry Result with RSSI */
+	events[4] |= 0x04; /* Read Remote Extended Features Complete */
+	events[5] |= 0x08; /* Synchronous Connection Complete */
+	events[5] |= 0x10; /* Synchronous Connection Changed */
 
 	if (hdev->features[3] & LMP_RSSI_INQ)
 		events[4] |= 0x04; /* Inquiry Result with RSSI */
-- 

Re: Linux 2.6.39

[Corey Boyle]

On Thu, May 26, 2011 at 4:37 AM, Ville Tervo <ville.tervo@nokia.com> wrote:
> On Wed, May 25, 2011 at 09:11:19PM -0400, ext Corey Boyle wrote:
>> On Wed, May 25, 2011 at 12:31 PM, Tom Allebrandi <wyrles@ytram.com> wrote:
>> > -----Original Message-----
>> > From: linux-bluetooth-owner@vger.kernel.org
>> > [mailto:linux-bluetooth-owner@vger.kernel.org] On Behalf Of Cufi, Carles
>> > Sent: Wednesday, May 25, 2011 7:15 AM
>> > To: corey@kansanian.com
>> > Cc: Ed Tomlinson; Ville Tervo; Bluettooth Linux;
>> > linux-kernel@vger.kernel.org
>> > Subject: RE: Linux 2.6.39
>> >
>> > (Snipping...)
>> > On Wed, May 25, 2011 at 8:46 AM, Cufi, Carles <carles.cufi@nordicsemi.no>
>> > wrote:
>> >> On Wednesday 25 May 2011 07:36:14 Ville Tervo wrote:
>> >>> On Wed, May 25, 2011 at 07:11:17AM -0400, ext Ed Tomlinson wrote:
>> >>> > On Wednesday 25 May 2011 06:54:54 Corey Boyle wrote:
>> >>> > > > On Mon, May 23, 2011 at 06:08:36PM -0400, ext Ed Tomlinson wrote:
>> >>> > > > > On Saturday 21 May 2011 16:31:00 Ed Tomlinson wrote:
>> >>> > > > > > On Saturday 21 May 2011 13:56:20 Milan Oravec wrote:
>> > ...
>> >>> > 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.1 (0x1) HCI Revision: 0x20d
>> > *************************
>> >>> >     LMP Version: 1.1 (0x1) LMP Subversion: 0x20d
>> > *************************
>> >>> >     Manufacturer: Cambridge Silicon Radio (10) < HCI Command: Set
>> >>> > Event Mask (0x03|0x0001) plen 8
>> >>> >     Mask: 0xfffffbff00000000
>> > *************************
>> >>> > > HCI Event: Command Complete (0x0e) plen 4
>> >>> >     Set Event Mask (0x03|0x0001) ncmd 1
>> >>> >     status 0x12
>> >>> >     Error: Invalid HCI Command Parameters
>> >>
>> >>Set Event Mask has been in the Bluetooth Spec since day 1, so it must be
>> > the bitmask, which has been extended with each new spec release to cover
>> > newly >added events. Looking at the latest spec, and judging by the year
>> > your chipset was released in (it probably is a 1.1 compliant chipset) I
>> > believe that >0x000000008FFFFFFF is the highest event mask it would support
>> > (up until and including Page Scan Repetition Mode Change Event), but since I
>> > don't have the >old 1.1 spec around I may be one or two bits off.
>> >
>> > The device appears to have identified itself as CSR firmware using Bluetooth
>> > version 1.1.
>> >
>> > I do happen to have the 1.1 spec lying around :-), for Set_Event_Mask it
>> > says
>> >
>> > 0x0000000100000000
>> > To                                          Reserved for future use
>> > 0x8000000000000000
>> >
>> > 0x00000000FFFFFFFF      Default (All events enabled)
>> >
>>
>> I am beginning to think that my adapter simply does not support this
>> command.  I have tried with all the suggested bitmasks, all zeros, all
>> ones, all combinations where a single bit is set, etc.  I'm not sure
>> where to go from here other than add a flag which incidates that
>> certain devices don't support this command so it can be skipped.
>> Again, the only way I have gotten it to work is by not sending the
>> command at all.  Thoughts?
>
> I also played a bit with 1.1 CSR dongle and couldn't find any mask that would
> be accepted. I think this command can be left out for older than 1.2 devices.
>
> Following patch should do it. Could you verify it. I don't have access to old
> hw ATM.
>
> diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
> index 19cd4af..86d1e26 100644
> --- a/net/bluetooth/hci_event.c
> +++ b/net/bluetooth/hci_event.c
> @@ -477,14 +477,16 @@ static void hci_setup_event_mask(struct hci_dev *hdev)
>         * command otherwise */
>        u8 events[8] = { 0xff, 0xff, 0xfb, 0xff, 0x00, 0x00, 0x00, 0x00 };
>
> -       /* Events for 1.2 and newer controllers */
> -       if (hdev->lmp_ver > 1) {
> -               events[4] |= 0x01; /* Flow Specification Complete */
> -               events[4] |= 0x02; /* Inquiry Result with RSSI */
> -               events[4] |= 0x04; /* Read Remote Extended Features Complete */
> -               events[5] |= 0x08; /* Synchronous Connection Complete */
> -               events[5] |= 0x10; /* Synchronous Connection Changed */
> -       }
> +       /* CSR 1.1 dongles does not accept any bitfield so don't try to set
> +        * any event mask for pre 1.2 devices */
> +       if (hdev->lmp_ver <= 1)
> +               return;
> +
> +       events[4] |= 0x01; /* Flow Specification Complete */
> +       events[4] |= 0x02; /* Inquiry Result with RSSI */
> +       events[4] |= 0x04; /* Read Remote Extended Features Complete */
> +       events[5] |= 0x08; /* Synchronous Connection Complete */
> +       events[5] |= 0x10; /* Synchronous Connection Changed */
>
>        if (hdev->features[3] & LMP_RSSI_INQ)
>                events[4] |= 0x04; /* Inquiry Result with RSSI */
> --
>
>

Patch works great - typing this email from my bluetooth keyboard.

Re: Linux 2.6.39

[Ed Tomlinson]

On Thursday 26 May 2011 06:17:20 Corey Boyle wrote:
> On Thu, May 26, 2011 at 4:37 AM, Ville Tervo <ville.tervo@nokia.com> wrote:
> > On Wed, May 25, 2011 at 09:11:19PM -0400, ext Corey Boyle wrote:
> >> On Wed, May 25, 2011 at 12:31 PM, Tom Allebrandi <wyrles@ytram.com> wrote:
> >> > -----Original Message-----
> >> > From: linux-bluetooth-owner@vger.kernel.org
> >> > [mailto:linux-bluetooth-owner@vger.kernel.org] On Behalf Of Cufi, Carles
> >> > Sent: Wednesday, May 25, 2011 7:15 AM
> >> > To: corey@kansanian.com
> >> > Cc: Ed Tomlinson; Ville Tervo; Bluettooth Linux;
> >> > linux-kernel@vger.kernel.org
> >> > Subject: RE: Linux 2.6.39
> >> >
> >> > (Snipping...)
> >> > On Wed, May 25, 2011 at 8:46 AM, Cufi, Carles <carles.cufi@nordicsemi.no>
> >> > wrote:
> >> >> On Wednesday 25 May 2011 07:36:14 Ville Tervo wrote:
> >> >>> On Wed, May 25, 2011 at 07:11:17AM -0400, ext Ed Tomlinson wrote:
> >> >>> > On Wednesday 25 May 2011 06:54:54 Corey Boyle wrote:
> >> >>> > > > On Mon, May 23, 2011 at 06:08:36PM -0400, ext Ed Tomlinson wrote:
> >> >>> > > > > On Saturday 21 May 2011 16:31:00 Ed Tomlinson wrote:
> >> >>> > > > > > On Saturday 21 May 2011 13:56:20 Milan Oravec wrote:
> >> > ...
> >> >>> > 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.1 (0x1) HCI Revision: 0x20d
> >> > *************************
> >> >>> >     LMP Version: 1.1 (0x1) LMP Subversion: 0x20d
> >> > *************************
> >> >>> >     Manufacturer: Cambridge Silicon Radio (10) < HCI Command: Set
> >> >>> > Event Mask (0x03|0x0001) plen 8
> >> >>> >     Mask: 0xfffffbff00000000
> >> > *************************
> >> >>> > > HCI Event: Command Complete (0x0e) plen 4
> >> >>> >     Set Event Mask (0x03|0x0001) ncmd 1
> >> >>> >     status 0x12
> >> >>> >     Error: Invalid HCI Command Parameters
> >> >>
> >> >>Set Event Mask has been in the Bluetooth Spec since day 1, so it must be
> >> > the bitmask, which has been extended with each new spec release to cover
> >> > newly >added events. Looking at the latest spec, and judging by the year
> >> > your chipset was released in (it probably is a 1.1 compliant chipset) I
> >> > believe that >0x000000008FFFFFFF is the highest event mask it would support
> >> > (up until and including Page Scan Repetition Mode Change Event), but since I
> >> > don't have the >old 1.1 spec around I may be one or two bits off.
> >> >
> >> > The device appears to have identified itself as CSR firmware using Bluetooth
> >> > version 1.1.
> >> >
> >> > I do happen to have the 1.1 spec lying around :-), for Set_Event_Mask it
> >> > says
> >> >
> >> > 0x0000000100000000
> >> > To                                          Reserved for future use
> >> > 0x8000000000000000
> >> >
> >> > 0x00000000FFFFFFFF      Default (All events enabled)
> >> >
> >>
> >> I am beginning to think that my adapter simply does not support this
> >> command.  I have tried with all the suggested bitmasks, all zeros, all
> >> ones, all combinations where a single bit is set, etc.  I'm not sure
> >> where to go from here other than add a flag which incidates that
> >> certain devices don't support this command so it can be skipped.
> >> Again, the only way I have gotten it to work is by not sending the
> >> command at all.  Thoughts?
> >
> > I also played a bit with 1.1 CSR dongle and couldn't find any mask that would
> > be accepted. I think this command can be left out for older than 1.2 devices.
> >
> > Following patch should do it. Could you verify it. I don't have access to old
> > hw ATM.
> >
> > diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
> > index 19cd4af..86d1e26 100644
> > --- a/net/bluetooth/hci_event.c
> > +++ b/net/bluetooth/hci_event.c
> > @@ -477,14 +477,16 @@ static void hci_setup_event_mask(struct hci_dev *hdev)
> >         * command otherwise */
> >        u8 events[8] = { 0xff, 0xff, 0xfb, 0xff, 0x00, 0x00, 0x00, 0x00 };
> >
> > -       /* Events for 1.2 and newer controllers */
> > -       if (hdev->lmp_ver > 1) {
> > -               events[4] |= 0x01; /* Flow Specification Complete */
> > -               events[4] |= 0x02; /* Inquiry Result with RSSI */
> > -               events[4] |= 0x04; /* Read Remote Extended Features Complete */
> > -               events[5] |= 0x08; /* Synchronous Connection Complete */
> > -               events[5] |= 0x10; /* Synchronous Connection Changed */
> > -       }
> > +       /* CSR 1.1 dongles does not accept any bitfield so don't try to set
> > +        * any event mask for pre 1.2 devices */
> > +       if (hdev->lmp_ver <= 1)
> > +               return;
> > +
> > +       events[4] |= 0x01; /* Flow Specification Complete */
> > +       events[4] |= 0x02; /* Inquiry Result with RSSI */
> > +       events[4] |= 0x04; /* Read Remote Extended Features Complete */
> > +       events[5] |= 0x08; /* Synchronous Connection Complete */
> > +       events[5] |= 0x10; /* Synchronous Connection Changed */
> >
> >        if (hdev->features[3] & LMP_RSSI_INQ)
> >                events[4] |= 0x04; /* Inquiry Result with RSSI */
> > --
> >
> >
> 
> Patch works great - typing this email from my bluetooth keyboard.

Works here too.

Thanks
Ed

Re: Linux 2.6.39

[Gustavo F. Padovan]

* Ed Tomlinson <edt@aei.ca> [2011-05-26 06:47:55 -0400]:

> On Thursday 26 May 2011 06:17:20 Corey Boyle wrote:
> > On Thu, May 26, 2011 at 4:37 AM, Ville Tervo <ville.tervo@nokia.com> wrote:
> > > On Wed, May 25, 2011 at 09:11:19PM -0400, ext Corey Boyle wrote:
> > >> On Wed, May 25, 2011 at 12:31 PM, Tom Allebrandi <wyrles@ytram.com> wrote:
> > >> > -----Original Message-----
> > >> > From: linux-bluetooth-owner@vger.kernel.org
> > >> > [mailto:linux-bluetooth-owner@vger.kernel.org] On Behalf Of Cufi, Carles
> > >> > Sent: Wednesday, May 25, 2011 7:15 AM
> > >> > To: corey@kansanian.com
> > >> > Cc: Ed Tomlinson; Ville Tervo; Bluettooth Linux;
> > >> > linux-kernel@vger.kernel.org
> > >> > Subject: RE: Linux 2.6.39
> > >> >
> > >> > (Snipping...)
> > >> > On Wed, May 25, 2011 at 8:46 AM, Cufi, Carles <carles.cufi@nordicsemi.no>
> > >> > wrote:
> > >> >> On Wednesday 25 May 2011 07:36:14 Ville Tervo wrote:
> > >> >>> On Wed, May 25, 2011 at 07:11:17AM -0400, ext Ed Tomlinson wrote:
> > >> >>> > On Wednesday 25 May 2011 06:54:54 Corey Boyle wrote:
> > >> >>> > > > On Mon, May 23, 2011 at 06:08:36PM -0400, ext Ed Tomlinson wrote:
> > >> >>> > > > > On Saturday 21 May 2011 16:31:00 Ed Tomlinson wrote:
> > >> >>> > > > > > On Saturday 21 May 2011 13:56:20 Milan Oravec wrote:
> > >> > ...
> > >> >>> > 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.1 (0x1) HCI Revision: 0x20d
> > >> > *************************
> > >> >>> >     LMP Version: 1.1 (0x1) LMP Subversion: 0x20d
> > >> > *************************
> > >> >>> >     Manufacturer: Cambridge Silicon Radio (10) < HCI Command: Set
> > >> >>> > Event Mask (0x03|0x0001) plen 8
> > >> >>> >     Mask: 0xfffffbff00000000
> > >> > *************************
> > >> >>> > > HCI Event: Command Complete (0x0e) plen 4
> > >> >>> >     Set Event Mask (0x03|0x0001) ncmd 1
> > >> >>> >     status 0x12
> > >> >>> >     Error: Invalid HCI Command Parameters
> > >> >>
> > >> >>Set Event Mask has been in the Bluetooth Spec since day 1, so it must be
> > >> > the bitmask, which has been extended with each new spec release to cover
> > >> > newly >added events. Looking at the latest spec, and judging by the year
> > >> > your chipset was released in (it probably is a 1.1 compliant chipset) I
> > >> > believe that >0x000000008FFFFFFF is the highest event mask it would support
> > >> > (up until and including Page Scan Repetition Mode Change Event), but since I
> > >> > don't have the >old 1.1 spec around I may be one or two bits off.
> > >> >
> > >> > The device appears to have identified itself as CSR firmware using Bluetooth
> > >> > version 1.1.
> > >> >
> > >> > I do happen to have the 1.1 spec lying around :-), for Set_Event_Mask it
> > >> > says
> > >> >
> > >> > 0x0000000100000000
> > >> > To                                          Reserved for future use
> > >> > 0x8000000000000000
> > >> >
> > >> > 0x00000000FFFFFFFF      Default (All events enabled)
> > >> >
> > >>
> > >> I am beginning to think that my adapter simply does not support this
> > >> command.  I have tried with all the suggested bitmasks, all zeros, all
> > >> ones, all combinations where a single bit is set, etc.  I'm not sure
> > >> where to go from here other than add a flag which incidates that
> > >> certain devices don't support this command so it can be skipped.
> > >> Again, the only way I have gotten it to work is by not sending the
> > >> command at all.  Thoughts?
> > >
> > > I also played a bit with 1.1 CSR dongle and couldn't find any mask that would
> > > be accepted. I think this command can be left out for older than 1.2 devices.
> > >
> > > Following patch should do it. Could you verify it. I don't have access to old
> > > hw ATM.
> > >
> > > diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
> > > index 19cd4af..86d1e26 100644
> > > --- a/net/bluetooth/hci_event.c
> > > +++ b/net/bluetooth/hci_event.c
> > > @@ -477,14 +477,16 @@ static void hci_setup_event_mask(struct hci_dev *hdev)
> > >         * command otherwise */
> > >        u8 events[8] = { 0xff, 0xff, 0xfb, 0xff, 0x00, 0x00, 0x00, 0x00 };
> > >
> > > -       /* Events for 1.2 and newer controllers */
> > > -       if (hdev->lmp_ver > 1) {
> > > -               events[4] |= 0x01; /* Flow Specification Complete */
> > > -               events[4] |= 0x02; /* Inquiry Result with RSSI */
> > > -               events[4] |= 0x04; /* Read Remote Extended Features Complete */
> > > -               events[5] |= 0x08; /* Synchronous Connection Complete */
> > > -               events[5] |= 0x10; /* Synchronous Connection Changed */
> > > -       }
> > > +       /* CSR 1.1 dongles does not accept any bitfield so don't try to set
> > > +        * any event mask for pre 1.2 devices */
> > > +       if (hdev->lmp_ver <= 1)
> > > +               return;
> > > +
> > > +       events[4] |= 0x01; /* Flow Specification Complete */
> > > +       events[4] |= 0x02; /* Inquiry Result with RSSI */
> > > +       events[4] |= 0x04; /* Read Remote Extended Features Complete */
> > > +       events[5] |= 0x08; /* Synchronous Connection Complete */
> > > +       events[5] |= 0x10; /* Synchronous Connection Changed */
> > >
> > >        if (hdev->features[3] & LMP_RSSI_INQ)
> > >                events[4] |= 0x04; /* Inquiry Result with RSSI */
> > > --
> > >
> > >
> > 
> > Patch works great - typing this email from my bluetooth keyboard.
> 
> Works here too.

Great, I'll consider both comments as a Tested-by thing and add it to the
commit.

-- 
Gustavo F. Padovan
http://profusion.mobi

Re: Linux 2.6.39

[Ville Tervo]

On Mon, May 23, 2011 at 06:08:36PM -0400, ext Ed Tomlinson wrote:
> On Saturday 21 May 2011 16:31:00 Ed Tomlinson wrote:
> > On Saturday 21 May 2011 13:56:20 Milan Oravec wrote:
> > > Hi Linus, I'm sorry bothering you, but my usb-bluetooth dongle stop working in
> > > 2.6.39 kernel series. 
> > > I know it is nothing ground breaking but it is bug. 
> > > I'm using this hardware from 2.6.11 kernel series. 
> > > Details are included in this thread:
> > > 
> > > https://lkml.org/lkml/2011/4/18/481
> > > 
> > > I hope I'm doing nothing false writing this email. 
> > 
> > Same device, same problem here.
> > 
> > You are not alone
> 
> I had some time this afternood so I tried bisecting without much luck.  I ended up somewhere rc1 ish with a system
> that would paniced during boot.  Here is the bisect log incase it helps:
> 
> # bad: [61c4f2c81c61f73549928dfd9f3e8f26aa36a8cf] Linux 2.6.39
> # good: [521cb40b0c44418a4fd36dc633f575813d59a43d] Linux 2.6.38
> git bisect start 'v2.6.39' 'v2.6.38' '--' 'drivers/bluetooth'
> # bad: [7a6362800cb7d1d618a697a650c7aaed3eb39320] Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next-2.6
> git bisect bad 7a6362800cb7d1d618a697a650c7aaed3eb39320
> # bad: [0a0e9ae1bd788bc19adc4d4ae08c98b233697402] Merge branch 'master' of master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6
> git bisect bad 0a0e9ae1bd788bc19adc4d4ae08c98b233697402
> # skip: [03c2d0e89409b59c1ec9d9511533cedc0b7aaa69] Bluetooth: Use usb_fill_int_urb()
> git bisect skip 03c2d0e89409b59c1ec9d9511533cedc0b7aaa69
> # skip: [7f4b2b04c88377af30c022f36c060190182850fb] Bluetooth: Make hci a child of the corresponding tty device.
> git bisect skip 7f4b2b04c88377af30c022f36c060190182850fb
> # skip: [84f0e17f78471857104a20dfc57711409f68d7bf] Bluetooth: ath3k: Avoid duplication of code
> git bisect skip 84f0e17f78471857104a20dfc57711409f68d7bf
> 
> Ring any bells for anyone?
> 
> Probably should open a regression bug for this too....

I think this is regression with d5859e22cd40b73164b3e5d8d5d796f96edcc6af
commit. Probably the code tries to enable something that is not supported.

Could you pastebin hcidump while doing hciconfig hci0 up? 

-- 
Ville

Re: Linux 2.6.39

[Milan Oravec]

Hi Ville, thank you for your help.

In 2.6.39 kernel command hciconfig hci0 up produces this output:

HCI sniffer - Bluetooth packet analyzer ver 1.42
device: hci0 snap_len: 1028 filter: 0xffffffff
< HCI Command: Reset (0x03|0x0003) plen 0
 > > HCI Event: Command Complete (0x0e) plen 4
< HCI Command: Read Local Supported Features (0x04|0x0003) plen 0
 > > HCI Event: Command Complete (0x0e) plen 12
< HCI Command: Read Local Version Information (0x04|0x0001) plen 0
 > > HCI Event: Command Complete (0x0e) plen 12
< HCI Command: Read Buffer Size (0x04|0x0005) plen 0
 > > HCI Event: Command Complete (0x0e) plen 11
< HCI Command: Read BD ADDR (0x04|0x0009) plen 0
 > > HCI Event: Command Complete (0x0e) plen 10
< HCI Command: Read Class of Device (0x03|0x0023) plen 0
 > > HCI Event: Command Complete (0x0e) plen 7
< HCI Command: Read Local Name (0x03|0x0014) plen 0
 > > HCI Event: Command Complete (0x0e) plen 252
< HCI Command: Read Voice Setting (0x03|0x0025) plen 0
 > > HCI Event: Command Complete (0x0e) plen 6
< HCI Command: Set Event Filter (0x03|0x0005) plen 1
 > > HCI Event: Command Complete (0x0e) plen 4
< HCI Command: Write Connection Accept Timeout (0x03|0x0016) plen 2
 > > HCI Event: Command Complete (0x0e) plen 4
< HCI Command: Delete Stored Link Key (0x03|0x0012) plen 7
 > > HCI Event: Command Complete (0x0e) plen 6
< HCI Command: Set Event Mask (0x03|0x0001) plen 8
 > > HCI Event: Command Complete (0x0e) plen 4

In 2.6.38.7 kernel command hciconfig hci0 up produces:

HCI sniffer - Bluetooth packet analyzer ver 1.42
device: hci0 snap_len: 1028 filter: 0xffffffff
< HCI Command: Reset (0x03|0x0003) plen 0
 > > HCI Event: Command Complete (0x0e) plen 4
< HCI Command: Read Local Supported Features (0x04|0x0003) plen 0
 > > HCI Event: Command Complete (0x0e) plen 12
< HCI Command: Read Local Version Information (0x04|0x0001) plen 0
 > > HCI Event: Command Complete (0x0e) plen 12
< HCI Command: Read Buffer Size (0x04|0x0005) plen 0
 > > HCI Event: Command Complete (0x0e) plen 11
< HCI Command: Read BD ADDR (0x04|0x0009) plen 0
 > > HCI Event: Command Complete (0x0e) plen 10
< HCI Command: Read Class of Device (0x03|0x0023) plen 0
 > > HCI Event: Command Complete (0x0e) plen 7
< HCI Command: Read Local Name (0x03|0x0014) plen 0
 > > HCI Event: Command Complete (0x0e) plen 252
< HCI Command: Read Voice Setting (0x03|0x0025) plen 0
 > > HCI Event: Command Complete (0x0e) plen 6
< HCI Command: Set Event Filter (0x03|0x0005) plen 1
 > > HCI Event: Command Complete (0x0e) plen 4
< HCI Command: Write Page Timeout (0x03|0x0018) plen 2
 > > HCI Event: Command Complete (0x0e) plen 4
< HCI Command: Write Connection Accept Timeout (0x03|0x0016) plen 2
 > > HCI Event: Command Complete (0x0e) plen 4
< HCI Command: Write Page Timeout (0x03|0x0018) plen 2
 > > HCI Event: Command Complete (0x0e) plen 4
< HCI Command: Read Stored Link Key (0x03|0x000d) plen 7
 > > HCI Event: Command Complete (0x0e) plen 8
< HCI Command: Set Event Mask (0x03|0x0001) plen 8
 > > HCI Event: Command Complete (0x0e) plen 4
< HCI Command: Write Default Link Policy Settings (0x02|0x000f) plen 2
 > > HCI Event: Command Status (0x0f) plen 4
< HCI Command: Write Local Name (0x03|0x0013) plen 248
 > > HCI Event: Command Complete (0x0e) plen 4
< HCI Command: Write Class of Device (0x03|0x0024) plen 3
 > > HCI Event: Command Complete (0x0e) plen 4
< HCI Command: Write Scan Enable (0x03|0x001a) plen 1
 > > HCI Event: Command Complete (0x0e) plen 4
< HCI Command: Read Local Name (0x03|0x0014) plen 0
 > > HCI Event: Command Complete (0x0e) plen 252
< HCI Command: Read Scan Enable (0x03|0x0019) plen 0
 > > HCI Event: Command Complete (0x0e) plen 5

Hope this helps.

Best regards,

Milan



On 05/25/2011 10:27 AM, Ville Tervo wrote:
> On Mon, May 23, 2011 at 06:08:36PM -0400, ext Ed Tomlinson wrote:
>> On Saturday 21 May 2011 16:31:00 Ed Tomlinson wrote:
>>> On Saturday 21 May 2011 13:56:20 Milan Oravec wrote:
>>>> Hi Linus, I'm sorry bothering you, but my usb-bluetooth dongle stop working in
>>>> 2.6.39 kernel series.
>>>> I know it is nothing ground breaking but it is bug.
>>>> I'm using this hardware from 2.6.11 kernel series.
>>>> Details are included in this thread:
>>>>
>>>> https://lkml.org/lkml/2011/4/18/481
>>>>
>>>> I hope I'm doing nothing false writing this email.
>>>
>>> Same device, same problem here.
>>>
>>> You are not alone
>>
>> I had some time this afternood so I tried bisecting without much luck.  I ended up somewhere rc1 ish with a system
>> that would paniced during boot.  Here is the bisect log incase it helps:
>>
>> # bad: [61c4f2c81c61f73549928dfd9f3e8f26aa36a8cf] Linux 2.6.39
>> # good: [521cb40b0c44418a4fd36dc633f575813d59a43d] Linux 2.6.38
>> git bisect start 'v2.6.39' 'v2.6.38' '--' 'drivers/bluetooth'
>> # bad: [7a6362800cb7d1d618a697a650c7aaed3eb39320] Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next-2.6
>> git bisect bad 7a6362800cb7d1d618a697a650c7aaed3eb39320
>> # bad: [0a0e9ae1bd788bc19adc4d4ae08c98b233697402] Merge branch 'master' of master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6
>> git bisect bad 0a0e9ae1bd788bc19adc4d4ae08c98b233697402
>> # skip: [03c2d0e89409b59c1ec9d9511533cedc0b7aaa69] Bluetooth: Use usb_fill_int_urb()
>> git bisect skip 03c2d0e89409b59c1ec9d9511533cedc0b7aaa69
>> # skip: [7f4b2b04c88377af30c022f36c060190182850fb] Bluetooth: Make hci a child of the corresponding tty device.
>> git bisect skip 7f4b2b04c88377af30c022f36c060190182850fb
>> # skip: [84f0e17f78471857104a20dfc57711409f68d7bf] Bluetooth: ath3k: Avoid duplication of code
>> git bisect skip 84f0e17f78471857104a20dfc57711409f68d7bf
>>
>> Ring any bells for anyone?
>>
>> Probably should open a regression bug for this too....
>
> I think this is regression with d5859e22cd40b73164b3e5d8d5d796f96edcc6af
> commit. Probably the code tries to enable something that is not supported.
>
> Could you pastebin hcidump while doing hciconfig hci0 up?
>

Re: Linux 2.6.39

[Milan Oravec]

Hi Ville, than you for your patch. BT dongle works now again in 3.0-rc4 
kernel.

Best wishes,

Milan

On 05/25/2011 10:27 AM, Ville Tervo wrote:
> On Mon, May 23, 2011 at 06:08:36PM -0400, ext Ed Tomlinson wrote:
>> On Saturday 21 May 2011 16:31:00 Ed Tomlinson wrote:
>>> On Saturday 21 May 2011 13:56:20 Milan Oravec wrote:
>>>> Hi Linus, I'm sorry bothering you, but my usb-bluetooth dongle stop working in
>>>> 2.6.39 kernel series.
>>>> I know it is nothing ground breaking but it is bug.
>>>> I'm using this hardware from 2.6.11 kernel series.
>>>> Details are included in this thread:
>>>>
>>>> https://lkml.org/lkml/2011/4/18/481
>>>>
>>>> I hope I'm doing nothing false writing this email.
>>>
>>> Same device, same problem here.
>>>
>>> You are not alone
>>
>> I had some time this afternood so I tried bisecting without much luck.  I ended up somewhere rc1 ish with a system
>> that would paniced during boot.  Here is the bisect log incase it helps:
>>
>> # bad: [61c4f2c81c61f73549928dfd9f3e8f26aa36a8cf] Linux 2.6.39
>> # good: [521cb40b0c44418a4fd36dc633f575813d59a43d] Linux 2.6.38
>> git bisect start 'v2.6.39' 'v2.6.38' '--' 'drivers/bluetooth'
>> # bad: [7a6362800cb7d1d618a697a650c7aaed3eb39320] Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next-2.6
>> git bisect bad 7a6362800cb7d1d618a697a650c7aaed3eb39320
>> # bad: [0a0e9ae1bd788bc19adc4d4ae08c98b233697402] Merge branch 'master' of master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6
>> git bisect bad 0a0e9ae1bd788bc19adc4d4ae08c98b233697402
>> # skip: [03c2d0e89409b59c1ec9d9511533cedc0b7aaa69] Bluetooth: Use usb_fill_int_urb()
>> git bisect skip 03c2d0e89409b59c1ec9d9511533cedc0b7aaa69
>> # skip: [7f4b2b04c88377af30c022f36c060190182850fb] Bluetooth: Make hci a child of the corresponding tty device.
>> git bisect skip 7f4b2b04c88377af30c022f36c060190182850fb
>> # skip: [84f0e17f78471857104a20dfc57711409f68d7bf] Bluetooth: ath3k: Avoid duplication of code
>> git bisect skip 84f0e17f78471857104a20dfc57711409f68d7bf
>>
>> Ring any bells for anyone?
>>
>> Probably should open a regression bug for this too....
>
> I think this is regression with d5859e22cd40b73164b3e5d8d5d796f96edcc6af
> commit. Probably the code tries to enable something that is not supported.
>
> Could you pastebin hcidump while doing hciconfig hci0 up?
>