[Regression] Cambridge Silicon Radio, Ltd Bluetooth Dongle unusable again with kernel 6.0

[Regression] Cambridge Silicon Radio, Ltd Bluetooth Dongle unusable again with kernel 6.0

[Jack]

Cheap USB BT dongles that are bad clones of CSR  "ID 0a12:0001  
Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)" have had  
historic problems, due to various bad behaviors.  See [Bug 60824]  
[PATCH][regression] Cambridge Silicon Radio, Ltd Bluetooth Dongle  
unusable (https://bugzilla.kernel.org/show_bug.cgi) for more details  
and background.  The patch in that bug was initially mainlined in 5.9,  
and underwent several revisions since then.  It has continued to work  
through all of the 5.19 series, but it does not work with any of the  
6.0 kernels.

I have made three unsuccessful attempts to git bisect using vanilla  
sources.  All settled on totally irrelevant commits.  These have all  
used v6.0-rc1 and v5.19 as the starting bad and good commits.

Having read all the pages on filing a [REGRESSION} bug, I'm a bit  
intimidated to file something without sufficient information to be  
taken seriously, but will do so using this information, if that seems  
the best course of action.

Thanks for any advice, including requests for additional information.

Below is the output from 'dmesg | egrep -iC2 "bt|blue" of a typical  
failed boot.  Note that unplugging and replugging the dongle (sometimes  
two or more times) will sometimes be successful in having it recognized  
and usable.

[    2.284192] usb 1-2: New USB device found, idVendor=0a12,  
idProduct=0001, bcdDevice=88.91
[    2.284925] usb 1-2: New USB device strings: Mfr=0, Product=2,  
SerialNumber=0
[    2.285648] usb 1-2: Product: BT DONGLE10
[    2.416732] usb 1-8: new high-speed USB device number 3 using  
xhci_hcd
[    2.480396] usb 3-2: new low-speed USB device number 3 using xhci_hcd
--
[    3.809944] [drm] GART: num cpu pages 524288, num gpu pages 524288
[    3.810893] [drm] PCIE gen 3 link speeds already enabled
[    3.820930] Bluetooth: Core ver 2.22
[    3.820951] NET: Registered PF_BLUETOOTH protocol family
[    3.820955] Bluetooth: HCI device and connection manager initialized
[    3.820960] Bluetooth: HCI socket layer initialized
[    3.820964] Bluetooth: L2CAP socket layer initialized
[    3.820968] Bluetooth: SCO socket layer initialized
[    3.826636] usbcore: registered new interface driver btusb
[    3.827192] [drm] PCIE GART of 2048M enabled (table at  
0x00000000001D6000).
[    3.827302] radeon 0000:1c:00.0: WB enabled
--
[    3.827320] radeon 0000:1c:00.0: fence driver on ring 4 use gpu addr  
0x0000000040000c10
[    3.827531] radeon 0000:1c:00.0: fence driver on ring 5 use gpu addr  
0x0000000000075a18
[    3.828917] Bluetooth: hci0: CSR: Unbranded CSR clone detected;  
adding workarounds and force-suspending once...
[    3.828925] Bluetooth: hci0: CSR: Couldn't suspend the device for  
our Barrot 8041a02 receive-issue workaround
[    3.828932] Bluetooth: hci0: HCI Delete Stored Link Key command is  
advertised, but not supported.
[    3.828936] Bluetooth: hci0: HCI Set Event Filter command not  
supported.
[    3.840596] sr 5:0:0:0: Attached scsi CD-ROM sr0
[    3.843043] usbcore: registered new interface driver snd-usb-audio
--
[    5.436854] [drm] ib test on ring 5 succeeded
[    5.943391] [drm] ib test on ring 6 succeeded
[    5.996684] Bluetooth: hci0: Opcode 0x c5a failed: -110
[    5.996712] Bluetooth: hci0: command tx timeout
[    6.125712] EXT4-fs (nvme0n1p2): re-mounted. Quota mode: none.
[    6.231315] Adding 15728636k swap on /dev/sda2.  Priority:-2  
extents:1 across:15728636k FS
--
[    7.866607] amdgpu: Virtual CRAT table created for CPU
[    7.866630] amdgpu: Topology: Add CPU node
[    7.957240] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[    7.957257] Bluetooth: BNEP filters: protocol multicast
[    7.957272] Bluetooth: BNEP socket layer initialized
[    8.611080] RPC: Registered named UNIX socket transport module.
[    8.611607] RPC: Registered udp transport module.

A successful run produces something like:
[  107.893971] usb 1-2: New USB device found, idVendor=0a12,  
idProduct=0001, bcdDevice=88.91
[  107.893979] usb 1-2: New USB device strings: Mfr=0, Product=2,  
SerialNumber=0
[  107.893982] usb 1-2: Product: BT DONGLE10
[  107.906721] Bluetooth: hci0: CSR: Unbranded CSR clone detected;  
adding workarounds and force-suspending once...
[  107.906731] Bluetooth: hci0: CSR: Couldn't suspend the device for  
our Barrot 8041a02 receive-issue workaround
[  107.906737] Bluetooth: hci0: HCI Delete Stored Link Key command is  
advertised, but not supported.
[  107.906739] Bluetooth: hci0: HCI Read Default Erroneous Data  
Reporting command is advertised, but not supported.
[  107.906741] Bluetooth: hci0: HCI Set Event Filter command not  
supported.
[  108.050825] Bluetooth: RFCOMM TTY layer initialized
[  108.050834] Bluetooth: RFCOMM socket layer initialized
[  108.050842] Bluetooth: RFCOMM ver 1.11

Re: [Regression] Cambridge Silicon Radio, Ltd Bluetooth Dongle unusable again with kernel 6.0

[Paul Menzel]

Dear Jack,


Thank you for your work on this driver.


Am 24.10.22 um 23:11 schrieb Jack:
> Cheap USB BT dongles that are bad clones of CSR  "ID 0a12:0001 Cambridge 
> Silicon Radio, Ltd Bluetooth Dongle (HCI mode)" have had historic 
> problems, due to various bad behaviors.  See [Bug 60824] 
> [PATCH][regression] Cambridge Silicon Radio, Ltd Bluetooth Dongle 
> unusable (https://bugzilla.kernel.org/show_bug.cgi) for more details and 
> background.  The patch in that bug was initially mainlined in 5.9, and 
> underwent several revisions since then.  It has continued to work 
> through all of the 5.19 series, but it does not work with any of the 6.0 
> kernels.
> 
> I have made three unsuccessful attempts to git bisect using vanilla 
> sources.  All settled on totally irrelevant commits.  These have all 
> used v6.0-rc1 and v5.19 as the starting bad and good commits.

Thank you for trying to bisect the issue. Too bad, it’s inconclusive. 
Did you or can you please test the commits below, relating to the merges 
of the Bluetooth trees.

1.  b8c3bf0ed2edf2deaedba5f0bf0bb54c76dee71d
2.  1d1ab5d39be7590bb2400418877bff43da9e75ec
3.  2e64fe4624d19bc71212aae434c54874e5c49c5a
4.  4a934eca7b39df35569f97a070701d6846ce46df
5.  14202eff214e1e941fefa0366d4c3bc4b1a0d500
6.  c69ecb0ea4c96b8b191cbaa0b420222a37867655
7.  6e0e846ee2ab01bc44254e6a0a6a6a0db1cba16d
8.  5588d628027092e66195097bdf6835ddf64418b3

> Having read all the pages on filing a [REGRESSION} bug, I'm a bit 
> intimidated to file something without sufficient information to be taken 
> seriously, but will do so using this information, if that seems the best 
> course of action.

Having the regression documented is the most important thing, and it 
will be taken seriously even if the reporter has not fully analyzed or 
solved it.

[…]


Kind regards,

Paul

Re: [Regression] Cambridge Silicon Radio, Ltd Bluetooth Dongle unusable again with kernel 6.0

[Jack]

On 2022.10.25 03:02, Paul Menzel wrote:
> Thank you for your work on this driver.
> 
> Am 24.10.22 um 23:11 schrieb Jack:
>> Cheap USB BT dongles that are bad clones of CSR  "ID 0a12:0001  
>> Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)" have had  
>> historic problems, due to various bad behaviors.  See [Bug 60824]  
>> [PATCH][regression] Cambridge Silicon Radio, Ltd Bluetooth Dongle  
>> unusable (https://bugzilla.kernel.org/show_bug.cgi) for more details  
>> and background.  The patch in that bug was initially mainlined in  
>> 5.9, and underwent several revisions since then.  It has continued  
>> to work through all of the 5.19 series, but it does not work with  
>> any of the 6.0 kernels.
>> 
>> I have made three unsuccessful attempts to git bisect using vanilla  
>> sources.  All settled on totally irrelevant commits.  These have all  
>> used v6.0-rc1 and v5.19 as the starting bad and good commits.
> 
Before receiving your reply, I made another start at bisect

# bad: [5030a9a03f0107f645772450bcba521b2ec19a51] dt-bindings: net:  
fsl,fec: Add nvmem-cells / nvmem-cell-names properties
# good: [8a958732818bc27f7da4d41ecf2c5c99d9aa8b0e] tls: rx: factor out  
device darg update
git bisect start '5030a9a03f0107f645772450bcba521b2ec19a51'  
'8a958732818bc27f7da4d41ecf2c5c99d9aa8b0e'
# good: [7ca433dc6dedb2ec98dfc943f6db0c9b8996ed11] Merge tag  
'net-5.19-rc8' of  
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net
git bisect good 7ca433dc6dedb2ec98dfc943f6db0c9b8996ed11
# bad: [e168f690087735ad12604ee6ee2db1b93e323072] Bluetooth: btusb:  
Remove HCI_QUIRK_BROKEN_ERR_DATA_REPORTING for fake CSR
git bisect bad e168f690087735ad12604ee6ee2db1b93e323072
# good: [5fb859f79f4f49d9df16bac2b3a84a6fa3aaccf1] net: ipa: initialize  
ring indexes to 0
git bisect good 5fb859f79f4f49d9df16bac2b3a84a6fa3aaccf1
# good: [ec2ea5e06c67f85c6541a74b661722a176be086f] net: ipa: list  
supported IPA versions in the Makefile
git bisect good ec2ea5e06c67f85c6541a74b661722a176be086f
# good: [df332800a914e9fd97b83aa63832979227fd8a8d] Bluetooth:  
btmtksdio: Add in-band wakeup support
git bisect good df332800a914e9fd97b83aa63832979227fd8a8d
# good: [6f43f6169a8229bb6ddbf483d3be760d48c4cdd1] Bluetooth: clean up  
error pointer checking
git bisect good 6f43f6169a8229bb6ddbf483d3be760d48c4cdd1
# good: [46459cb6d4e63066e227a496ae8af35ba8c0b23b] Bluetooth: hci_bcm:  
Increase host baudrate for CYW55572 in autobaud mode
git bisect good 46459cb6d4e63066e227a496ae8af35ba8c0b23b
# good: [0feb8af0275d196a29e321bedc15319673923cb6] Bluetooth: hci_sync:  
Correct hci_set_event_mask_page_2_sync() event mask
git bisect good 0feb8af0275d196a29e321bedc15319673923cb6
# bad: [1172c59f451f524a14bac5e7b047781883dfe441] Bluetooth: btusb:  
Remove HCI_QUIRK_BROKEN_ERR_DATA_REPORTING for QCA
git bisect bad 1172c59f451f524a14bac5e7b047781883dfe441
# bad: [766ae2422b4312a73510ebee9266bc23b466fbbb] Bluetooth: hci_sync:  
Check LMP feature bit instead of quirk
git bisect bad 766ae2422b4312a73510ebee9266bc23b466fbbb
# first bad commit: [766ae2422b4312a73510ebee9266bc23b466fbbb]  
Bluetooth: hci_sync: Check LMP feature bit instead of quirk

And 766ae2422b4312a73510ebee9266bc23b466fbbb does make sense as a  
likely culprit.

> Thank you for trying to bisect the issue. Too bad, it’s inconclusive.  
> Did you or can you please test the commits below, relating to the  
> merges of the Bluetooth trees.
> 
> 1.  b8c3bf0ed2edf2deaedba5f0bf0bb54c76dee71d
> 2.  1d1ab5d39be7590bb2400418877bff43da9e75ec
> 3.  2e64fe4624d19bc71212aae434c54874e5c49c5a
> 4.  4a934eca7b39df35569f97a070701d6846ce46df
> 5.  14202eff214e1e941fefa0366d4c3bc4b1a0d500
> 6.  c69ecb0ea4c96b8b191cbaa0b420222a37867655
> 7.  6e0e846ee2ab01bc44254e6a0a6a6a0db1cba16d
> 8.  5588d628027092e66195097bdf6835ddf64418b3
Let me know if you think there is still any need to test these.
> 
>> Having read all the pages on filing a [REGRESSION} bug, I'm a bit  
>> intimidated to file something without sufficient information to be  
>> taken seriously, but will do so using this information, if that  
>> seems the best course of action.
> 
> Having the regression documented is the most important thing, and it  
> will be taken seriously even if the reporter has not fully analyzed  
> or solved it.
Questions on actually filing the bug:  my understanding is that as a BT  
bug, this list will be notified, or do I need to explicitly do  
anything.  Do I just add regressions@lists.linux.dev as a cc?

> 
> […]
> 
> 
> Kind regards,
> 
> Paul
Jack

Re: [Regression] Cambridge Silicon Radio, Ltd Bluetooth Dongle unusable again with kernel 6.0

[Luiz Augusto von Dentz]

Hi Zijun,

On Tue, Oct 25, 2022 at 11:08 AM Jack <ostroffjh@users.sourceforge.net> wrote:
>
> On 2022.10.25 03:02, Paul Menzel wrote:
> > Thank you for your work on this driver.
> >
> > Am 24.10.22 um 23:11 schrieb Jack:
> >> Cheap USB BT dongles that are bad clones of CSR  "ID 0a12:0001
> >> Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)" have had
> >> historic problems, due to various bad behaviors.  See [Bug 60824]
> >> [PATCH][regression] Cambridge Silicon Radio, Ltd Bluetooth Dongle
> >> unusable (https://bugzilla.kernel.org/show_bug.cgi) for more details
> >> and background.  The patch in that bug was initially mainlined in
> >> 5.9, and underwent several revisions since then.  It has continued
> >> to work through all of the 5.19 series, but it does not work with
> >> any of the 6.0 kernels.
> >>
> >> I have made three unsuccessful attempts to git bisect using vanilla
> >> sources.  All settled on totally irrelevant commits.  These have all
> >> used v6.0-rc1 and v5.19 as the starting bad and good commits.
> >
> Before receiving your reply, I made another start at bisect
>
> # bad: [5030a9a03f0107f645772450bcba521b2ec19a51] dt-bindings: net:
> fsl,fec: Add nvmem-cells / nvmem-cell-names properties
> # good: [8a958732818bc27f7da4d41ecf2c5c99d9aa8b0e] tls: rx: factor out
> device darg update
> git bisect start '5030a9a03f0107f645772450bcba521b2ec19a51'
> '8a958732818bc27f7da4d41ecf2c5c99d9aa8b0e'
> # good: [7ca433dc6dedb2ec98dfc943f6db0c9b8996ed11] Merge tag
> 'net-5.19-rc8' of
> git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net
> git bisect good 7ca433dc6dedb2ec98dfc943f6db0c9b8996ed11
> # bad: [e168f690087735ad12604ee6ee2db1b93e323072] Bluetooth: btusb:
> Remove HCI_QUIRK_BROKEN_ERR_DATA_REPORTING for fake CSR
> git bisect bad e168f690087735ad12604ee6ee2db1b93e323072
> # good: [5fb859f79f4f49d9df16bac2b3a84a6fa3aaccf1] net: ipa: initialize
> ring indexes to 0
> git bisect good 5fb859f79f4f49d9df16bac2b3a84a6fa3aaccf1
> # good: [ec2ea5e06c67f85c6541a74b661722a176be086f] net: ipa: list
> supported IPA versions in the Makefile
> git bisect good ec2ea5e06c67f85c6541a74b661722a176be086f
> # good: [df332800a914e9fd97b83aa63832979227fd8a8d] Bluetooth:
> btmtksdio: Add in-band wakeup support
> git bisect good df332800a914e9fd97b83aa63832979227fd8a8d
> # good: [6f43f6169a8229bb6ddbf483d3be760d48c4cdd1] Bluetooth: clean up
> error pointer checking
> git bisect good 6f43f6169a8229bb6ddbf483d3be760d48c4cdd1
> # good: [46459cb6d4e63066e227a496ae8af35ba8c0b23b] Bluetooth: hci_bcm:
> Increase host baudrate for CYW55572 in autobaud mode
> git bisect good 46459cb6d4e63066e227a496ae8af35ba8c0b23b
> # good: [0feb8af0275d196a29e321bedc15319673923cb6] Bluetooth: hci_sync:
> Correct hci_set_event_mask_page_2_sync() event mask
> git bisect good 0feb8af0275d196a29e321bedc15319673923cb6
> # bad: [1172c59f451f524a14bac5e7b047781883dfe441] Bluetooth: btusb:
> Remove HCI_QUIRK_BROKEN_ERR_DATA_REPORTING for QCA
> git bisect bad 1172c59f451f524a14bac5e7b047781883dfe441
> # bad: [766ae2422b4312a73510ebee9266bc23b466fbbb] Bluetooth: hci_sync:
> Check LMP feature bit instead of quirk
> git bisect bad 766ae2422b4312a73510ebee9266bc23b466fbbb
> # first bad commit: [766ae2422b4312a73510ebee9266bc23b466fbbb]
> Bluetooth: hci_sync: Check LMP feature bit instead of quirk
>
> And 766ae2422b4312a73510ebee9266bc23b466fbbb does make sense as a
> likely culprit.

Looks like we will need to reintroduce the quirk then since it appears
the LMP feature bit is probably set in those controllers but the
command doesn't work.

-- 
Luiz Augusto von Dentz

Re: [Regression] Cambridge Silicon Radio, Ltd Bluetooth Dongle unusable again with kernel 6.0

[quic_zijuhu]

On 10/26/2022 3:38 AM, Luiz Augusto von Dentz wrote:
> Hi Zijun,
> 
> On Tue, Oct 25, 2022 at 11:08 AM Jack <ostroffjh@users.sourceforge.net> wrote:
>>
>> On 2022.10.25 03:02, Paul Menzel wrote:
>>> Thank you for your work on this driver.
>>>
>>> Am 24.10.22 um 23:11 schrieb Jack:
>>>> Cheap USB BT dongles that are bad clones of CSR  "ID 0a12:0001
>>>> Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)" have had
>>>> historic problems, due to various bad behaviors.  See [Bug 60824]
>>>> [PATCH][regression] Cambridge Silicon Radio, Ltd Bluetooth Dongle
>>>> unusable (https://bugzilla.kernel.org/show_bug.cgi) for more details
>>>> and background.  The patch in that bug was initially mainlined in
>>>> 5.9, and underwent several revisions since then.  It has continued
>>>> to work through all of the 5.19 series, but it does not work with
>>>> any of the 6.0 kernels.
>>>>
>>>> I have made three unsuccessful attempts to git bisect using vanilla
>>>> sources.  All settled on totally irrelevant commits.  These have all
>>>> used v6.0-rc1 and v5.19 as the starting bad and good commits.
>>>
>> Before receiving your reply, I made another start at bisect
>>
>> # bad: [5030a9a03f0107f645772450bcba521b2ec19a51] dt-bindings: net:
>> fsl,fec: Add nvmem-cells / nvmem-cell-names properties
>> # good: [8a958732818bc27f7da4d41ecf2c5c99d9aa8b0e] tls: rx: factor out
>> device darg update
>> git bisect start '5030a9a03f0107f645772450bcba521b2ec19a51'
>> '8a958732818bc27f7da4d41ecf2c5c99d9aa8b0e'
>> # good: [7ca433dc6dedb2ec98dfc943f6db0c9b8996ed11] Merge tag
>> 'net-5.19-rc8' of
>> git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net
>> git bisect good 7ca433dc6dedb2ec98dfc943f6db0c9b8996ed11
>> # bad: [e168f690087735ad12604ee6ee2db1b93e323072] Bluetooth: btusb:
>> Remove HCI_QUIRK_BROKEN_ERR_DATA_REPORTING for fake CSR
>> git bisect bad e168f690087735ad12604ee6ee2db1b93e323072
>> # good: [5fb859f79f4f49d9df16bac2b3a84a6fa3aaccf1] net: ipa: initialize
>> ring indexes to 0
>> git bisect good 5fb859f79f4f49d9df16bac2b3a84a6fa3aaccf1
>> # good: [ec2ea5e06c67f85c6541a74b661722a176be086f] net: ipa: list
>> supported IPA versions in the Makefile
>> git bisect good ec2ea5e06c67f85c6541a74b661722a176be086f
>> # good: [df332800a914e9fd97b83aa63832979227fd8a8d] Bluetooth:
>> btmtksdio: Add in-band wakeup support
>> git bisect good df332800a914e9fd97b83aa63832979227fd8a8d
>> # good: [6f43f6169a8229bb6ddbf483d3be760d48c4cdd1] Bluetooth: clean up
>> error pointer checking
>> git bisect good 6f43f6169a8229bb6ddbf483d3be760d48c4cdd1
>> # good: [46459cb6d4e63066e227a496ae8af35ba8c0b23b] Bluetooth: hci_bcm:
>> Increase host baudrate for CYW55572 in autobaud mode
>> git bisect good 46459cb6d4e63066e227a496ae8af35ba8c0b23b
>> # good: [0feb8af0275d196a29e321bedc15319673923cb6] Bluetooth: hci_sync:
>> Correct hci_set_event_mask_page_2_sync() event mask
>> git bisect good 0feb8af0275d196a29e321bedc15319673923cb6
>> # bad: [1172c59f451f524a14bac5e7b047781883dfe441] Bluetooth: btusb:
>> Remove HCI_QUIRK_BROKEN_ERR_DATA_REPORTING for QCA
>> git bisect bad 1172c59f451f524a14bac5e7b047781883dfe441
>> # bad: [766ae2422b4312a73510ebee9266bc23b466fbbb] Bluetooth: hci_sync:
>> Check LMP feature bit instead of quirk
>> git bisect bad 766ae2422b4312a73510ebee9266bc23b466fbbb
>> # first bad commit: [766ae2422b4312a73510ebee9266bc23b466fbbb]
>> Bluetooth: hci_sync: Check LMP feature bit instead of quirk
>>
>> And 766ae2422b4312a73510ebee9266bc23b466fbbb does make sense as a
>> likely culprit.
> 
> Looks like we will need to reintroduce the quirk then since it appears
> the LMP feature bit is probably set in those controllers but the
> command doesn't work.
> 
no, that issue is not caused by my change
it is below HCI command error which is not related the quirk HCI_QUIRK_BROKEN_ERR_DATA_REPORTING

< HCI Command: Set Event Filter (0x03|0x0005) plen 1                                                                                                     #23 [hci0] 5.316838
        Type: Clear All Filters (0x00)
> HCI Event: Command Complete (0x0e) plen 4                                    
>                                                                          #24
> [hci0] 5.319751

      Set Event Filter (0x03|0x0005) ncmd 1
        Status: Invalid HCI Command Parameters (0x12)
= Close Index: 00:1A:7D:xx:xx:xx

Re: [Regression] Cambridge Silicon Radio, Ltd Bluetooth Dongle unusable again with kernel 6.0

[quic_zijuhu]

On 10/26/2022 11:41 AM, quic_zijuhu wrote:
> On 10/26/2022 3:38 AM, Luiz Augusto von Dentz wrote:
>> Hi Zijun,
>>
>> On Tue, Oct 25, 2022 at 11:08 AM Jack <ostroffjh@users.sourceforge.net> wrote:
>>>
>>> On 2022.10.25 03:02, Paul Menzel wrote:
>>>> Thank you for your work on this driver.
>>>>
>>>> Am 24.10.22 um 23:11 schrieb Jack:
>>>>> Cheap USB BT dongles that are bad clones of CSR  "ID 0a12:0001
>>>>> Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)" have had
>>>>> historic problems, due to various bad behaviors.  See [Bug 60824]
>>>>> [PATCH][regression] Cambridge Silicon Radio, Ltd Bluetooth Dongle
>>>>> unusable (https://bugzilla.kernel.org/show_bug.cgi) for more details
>>>>> and background.  The patch in that bug was initially mainlined in
>>>>> 5.9, and underwent several revisions since then.  It has continued
>>>>> to work through all of the 5.19 series, but it does not work with
>>>>> any of the 6.0 kernels.
>>>>>
>>>>> I have made three unsuccessful attempts to git bisect using vanilla
>>>>> sources.  All settled on totally irrelevant commits.  These have all
>>>>> used v6.0-rc1 and v5.19 as the starting bad and good commits.
>>>>
>>> Before receiving your reply, I made another start at bisect
>>>
>>> # bad: [5030a9a03f0107f645772450bcba521b2ec19a51] dt-bindings: net:
>>> fsl,fec: Add nvmem-cells / nvmem-cell-names properties
>>> # good: [8a958732818bc27f7da4d41ecf2c5c99d9aa8b0e] tls: rx: factor out
>>> device darg update
>>> git bisect start '5030a9a03f0107f645772450bcba521b2ec19a51'
>>> '8a958732818bc27f7da4d41ecf2c5c99d9aa8b0e'
>>> # good: [7ca433dc6dedb2ec98dfc943f6db0c9b8996ed11] Merge tag
>>> 'net-5.19-rc8' of
>>> git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net
>>> git bisect good 7ca433dc6dedb2ec98dfc943f6db0c9b8996ed11
>>> # bad: [e168f690087735ad12604ee6ee2db1b93e323072] Bluetooth: btusb:
>>> Remove HCI_QUIRK_BROKEN_ERR_DATA_REPORTING for fake CSR
>>> git bisect bad e168f690087735ad12604ee6ee2db1b93e323072
>>> # good: [5fb859f79f4f49d9df16bac2b3a84a6fa3aaccf1] net: ipa: initialize
>>> ring indexes to 0
>>> git bisect good 5fb859f79f4f49d9df16bac2b3a84a6fa3aaccf1
>>> # good: [ec2ea5e06c67f85c6541a74b661722a176be086f] net: ipa: list
>>> supported IPA versions in the Makefile
>>> git bisect good ec2ea5e06c67f85c6541a74b661722a176be086f
>>> # good: [df332800a914e9fd97b83aa63832979227fd8a8d] Bluetooth:
>>> btmtksdio: Add in-band wakeup support
>>> git bisect good df332800a914e9fd97b83aa63832979227fd8a8d
>>> # good: [6f43f6169a8229bb6ddbf483d3be760d48c4cdd1] Bluetooth: clean up
>>> error pointer checking
>>> git bisect good 6f43f6169a8229bb6ddbf483d3be760d48c4cdd1
>>> # good: [46459cb6d4e63066e227a496ae8af35ba8c0b23b] Bluetooth: hci_bcm:
>>> Increase host baudrate for CYW55572 in autobaud mode
>>> git bisect good 46459cb6d4e63066e227a496ae8af35ba8c0b23b
>>> # good: [0feb8af0275d196a29e321bedc15319673923cb6] Bluetooth: hci_sync:
>>> Correct hci_set_event_mask_page_2_sync() event mask
>>> git bisect good 0feb8af0275d196a29e321bedc15319673923cb6
>>> # bad: [1172c59f451f524a14bac5e7b047781883dfe441] Bluetooth: btusb:
>>> Remove HCI_QUIRK_BROKEN_ERR_DATA_REPORTING for QCA
>>> git bisect bad 1172c59f451f524a14bac5e7b047781883dfe441
>>> # bad: [766ae2422b4312a73510ebee9266bc23b466fbbb] Bluetooth: hci_sync:
>>> Check LMP feature bit instead of quirk
>>> git bisect bad 766ae2422b4312a73510ebee9266bc23b466fbbb
>>> # first bad commit: [766ae2422b4312a73510ebee9266bc23b466fbbb]
>>> Bluetooth: hci_sync: Check LMP feature bit instead of quirk
>>>
>>> And 766ae2422b4312a73510ebee9266bc23b466fbbb does make sense as a
>>> likely culprit.
>>
>> Looks like we will need to reintroduce the quirk then since it appears
>> the LMP feature bit is probably set in those controllers but the
>> command doesn't work.
>>
> no, that issue is not caused by my change
> it is below HCI command error which is not related the quirk HCI_QUIRK_BROKEN_ERR_DATA_REPORTING
> 
> < HCI Command: Set Event Filter (0x03|0x0005) plen 1                                                                                                     #23 [hci0] 5.316838
>         Type: Clear All Filters (0x00)
>> HCI Event: Command Complete (0x0e) plen 4                                    
>>                                                                          #24
>> [hci0] 5.319751
> 
>       Set Event Filter (0x03|0x0005) ncmd 1
>         Status: Invalid HCI Command Parameters (0x12)
> = Close Index: 00:1A:7D:xx:xx:xx
> 

Hi Luiz,
i find out it is a new issue. this device is fake device actually.
but it is not detected as fake device.

i will submit patch to fix it. the fix is very simple.
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
old mode 100644
new mode 100755

index 420be2ee2acf..727469d073f9
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -2155,7 +2155,7 @@ static int btusb_setup_csr(struct hci_dev *hdev)
                is_fake = true;

        else if (le16_to_cpu(rp->lmp_subver) <= 0x22bb &&
-                le16_to_cpu(rp->hci_ver) > BLUETOOTH_VER_4_0)
+                le16_to_cpu(rp->hci_ver) >= BLUETOOTH_VER_4_0)
                is_fake = true;

Re: [Regression] Cambridge Silicon Radio, Ltd Bluetooth Dongle

[Swyter]

>> Correct hci_set_event_mask_page_2_sync() event mask
>> git bisect good 0feb8af0275d196a29e321bedc15319673923cb6
>> # bad: [1172c59f451f524a14bac5e7b047781883dfe441] Bluetooth: btusb:
>> Remove HCI_QUIRK_BROKEN_ERR_DATA_REPORTING for QCA
>> git bisect bad 1172c59f451f524a14bac5e7b047781883dfe441
>> # bad: [766ae2422b4312a73510ebee9266bc23b466fbbb] Bluetooth: hci_sync:
>> Check LMP feature bit instead of quirk
>> git bisect bad 766ae2422b4312a73510ebee9266bc23b466fbbb
>> # first bad commit: [766ae2422b4312a73510ebee9266bc23b466fbbb]
>> Bluetooth: hci_sync: Check LMP feature bit instead of quirk
>>
>> And 766ae2422b4312a73510ebee9266bc23b466fbbb does make sense as a
>> likely culprit.
> 
> Looks like we will need to reintroduce the quirk then since it appears
> the LMP feature bit is probably set in those controllers but the
> command doesn't work.

It is. I already mentioned it in the Bugzilla thread and that's
what the patch series I submitted the other day fixes:

> Bluetooth: btusb: Fix Chinese CSR dongles again by re-adding ERR_DATA_REPORTING quirk
> https://patchwork.kernel.org/project/bluetooth/patch/20221029202454.25651-1-swyterzone@gmail.com/

Hans de Goede gave it a Reviewed-by, but it has been ignored even since.

Keep in mind that I'm an occasional contributor and I can barely use a mailing list,
but this goes back to the patch that Zijun Hu sent back in July and I was pinged.


I took a look back then, it looked suspect, but I imagined you guys knew what you were
doing. Fast-forward three months and the code arrives at most mainstream distros.

Every single cheap Bluetooth dongle on Earth broke again. Just like that.

https://bugzilla.kernel.org/show_bug.cgi?id=60824#c242

I just came across this thread archive by pure chance, this isn't very user friendly.
Please CC me if you talk about this, I'm not subscribed to any list.

Re: [Regression] Cambridge Silicon Radio, Ltd Bluetooth Dongle

[Jack]

On 2022.11.09 14:12, Swyter wrote:
> >> Correct hci_set_event_mask_page_2_sync() event mask
> >> git bisect good 0feb8af0275d196a29e321bedc15319673923cb6
> >> # bad: [1172c59f451f524a14bac5e7b047781883dfe441] Bluetooth: btusb:
> >> Remove HCI_QUIRK_BROKEN_ERR_DATA_REPORTING for QCA
> >> git bisect bad 1172c59f451f524a14bac5e7b047781883dfe441
> >> # bad: [766ae2422b4312a73510ebee9266bc23b466fbbb] Bluetooth:  
> hci_sync:
> >> Check LMP feature bit instead of quirk
> >> git bisect bad 766ae2422b4312a73510ebee9266bc23b466fbbb
> >> # first bad commit: [766ae2422b4312a73510ebee9266bc23b466fbbb]
> >> Bluetooth: hci_sync: Check LMP feature bit instead of quirk
> >>
> >> And 766ae2422b4312a73510ebee9266bc23b466fbbb does make sense as a
> >> likely culprit.
> >
> > Looks like we will need to reintroduce the quirk then since it  
> appears
> > the LMP feature bit is probably set in those controllers but the
> > command doesn't work.
> 
> It is. I already mentioned it in the Bugzilla thread and that's
> what the patch series I submitted the other day fixes:
> 
> > Bluetooth: btusb: Fix Chinese CSR dongles again by re-adding  
> ERR_DATA_REPORTING quirk
> >  
> https://patchwork.kernel.org/project/bluetooth/patch/20221029202454.25651-1-swyterzone@gmail.com/
> 
> Hans de Goede gave it a Reviewed-by, but it has been ignored even  
> since.
> 
> Keep in mind that I'm an occasional contributor and I can barely use  
> a mailing list,
> but this goes back to the patch that Zijun Hu sent back in July and I  
> was pinged.
> 
> 
> I took a look back then, it looked suspect, but I imagined you guys  
> knew what you were
> doing. Fast-forward three months and the code arrives at most  
> mainstream distros.
> 
> Every single cheap Bluetooth dongle on Earth broke again. Just like  
> that.
> 
> https://bugzilla.kernel.org/show_bug.cgi?id=60824#c242
> 
> I just came across this thread archive by pure chance, this isn't  
> very user friendly.
> Please CC me if you talk about this, I'm not subscribed to any list.
> 
In case it helps any, I have applied Swyter's patch referenced at  
comment #243 of the bug referenced above, and it does restore function  
to my particular dongle (Gentoo linux, with gentoo-sources kernel  
6.0.6.)  (I believe I provided the git bisect quoted at the top of this  
message.)

Jack

Re: [Regression] Cambridge Silicon Radio, Ltd Bluetooth Dongle

[Luiz Augusto von Dentz]

Hi,

On Wed, Nov 9, 2022 at 11:40 AM Jack <ostroffjh@users.sourceforge.net> wrote:
>
> On 2022.11.09 14:12, Swyter wrote:
> > >> Correct hci_set_event_mask_page_2_sync() event mask
> > >> git bisect good 0feb8af0275d196a29e321bedc15319673923cb6
> > >> # bad: [1172c59f451f524a14bac5e7b047781883dfe441] Bluetooth: btusb:
> > >> Remove HCI_QUIRK_BROKEN_ERR_DATA_REPORTING for QCA
> > >> git bisect bad 1172c59f451f524a14bac5e7b047781883dfe441
> > >> # bad: [766ae2422b4312a73510ebee9266bc23b466fbbb] Bluetooth:
> > hci_sync:
> > >> Check LMP feature bit instead of quirk
> > >> git bisect bad 766ae2422b4312a73510ebee9266bc23b466fbbb
> > >> # first bad commit: [766ae2422b4312a73510ebee9266bc23b466fbbb]
> > >> Bluetooth: hci_sync: Check LMP feature bit instead of quirk
> > >>
> > >> And 766ae2422b4312a73510ebee9266bc23b466fbbb does make sense as a
> > >> likely culprit.
> > >
> > > Looks like we will need to reintroduce the quirk then since it
> > appears
> > > the LMP feature bit is probably set in those controllers but the
> > > command doesn't work.
> >
> > It is. I already mentioned it in the Bugzilla thread and that's
> > what the patch series I submitted the other day fixes:
> >
> > > Bluetooth: btusb: Fix Chinese CSR dongles again by re-adding
> > ERR_DATA_REPORTING quirk
> > >
> > https://patchwork.kernel.org/project/bluetooth/patch/20221029202454.25651-1-swyterzone@gmail.com/
> >
> > Hans de Goede gave it a Reviewed-by, but it has been ignored even
> > since.
> >
> > Keep in mind that I'm an occasional contributor and I can barely use
> > a mailing list,
> > but this goes back to the patch that Zijun Hu sent back in July and I
> > was pinged.
> >
> >
> > I took a look back then, it looked suspect, but I imagined you guys
> > knew what you were
> > doing. Fast-forward three months and the code arrives at most
> > mainstream distros.
> >
> > Every single cheap Bluetooth dongle on Earth broke again. Just like
> > that.
> >
> > https://bugzilla.kernel.org/show_bug.cgi?id=60824#c242
> >
> > I just came across this thread archive by pure chance, this isn't
> > very user friendly.
> > Please CC me if you talk about this, I'm not subscribed to any list.
> >
> In case it helps any, I have applied Swyter's patch referenced at
> comment #243 of the bug referenced above, and it does restore function
> to my particular dongle (Gentoo linux, with gentoo-sources kernel
> 6.0.6.)  (I believe I provided the git bisect quoted at the top of this
> message.)

Ive applied the first 2 patches, the third one I'm not so sure I'd
like to introduce another module parameter.

> Jack



-- 
Luiz Augusto von Dentz

Re: [Regression] Cambridge Silicon Radio, Ltd Bluetooth Dongle

[Swyter]

>> In case it helps any, I have applied Swyter's patch referenced at
>> comment #243 of the bug referenced above, and it does restore function
>> to my particular dongle (Gentoo linux, with gentoo-sources kernel
>> 6.0.6.)  (I believe I provided the git bisect quoted at the top of this
>> message.)
>
> Ive applied the first 2 patches, the third one I'm not so sure I'd
> like to introduce another module parameter.

Thanks for that, Luiz. The module parameter does help a lot and it
has been requested a few times in the Bugzilla thread.

I have been thinking about this problem for a long time.

Essentially nulls-out any potential drawback the suspend workaround
may ever cause. In the past for this we used a very spotty whitelist,
but we can't really work with that here. When I'm talking about hundreds
to thousands of dongles in various states of brokenness I mean it.

The generic catch-all-as-best-as-we-can is the best way forward here.

Detecting fakes is hard enough, detecting dongles that don't like
the suspend workaround is essentially impossible. As they all
share the same identifiers than the ones that do.

Some fakes NEED the suspend workaround to work at all while a *much*
smaller subset of otherwise identical dongles have trouble with it.

Thanks to this last-effort parameter we can cover that last mile
without people having to recompile custom versions of btusb.

My dongle doesn't work? Easy, add this here. Most people won't
have to bother with this, but that final ~3% would be screwed.

Re: [Regression] Cambridge Silicon Radio, Ltd Bluetooth Dongle

[Mika Laitio]

> Thanks to this last-effort parameter we can cover that last mile
> without people having to recompile custom versions of btusb.
>
> My dongle doesn't work? Easy, add this here. Most people won't
> have to bother with this, but that final ~3% would be screwed.

So what is the parameter needed for now? Might help users coming to this 
bug and finding this thread.

Mika

Re: [Regression] Cambridge Silicon Radio, Ltd Bluetooth Dongle

[Swyter]

>> Thanks to this last-effort parameter we can cover that last mile
>> without people having to recompile custom versions of btusb.
>>
>> My dongle doesn't work? Easy, add this here. Most people won't
>> have to bother with this, but that final ~3% would be screwed.
> 
> So what is the parameter needed for now? Might help users coming to this 
> bug and finding this thread.

Hans explained it better than me.

The Linux people haven't merged this patch yet, but the idea is that in
case our generic workaround is a bit too much for a small bunch of dissident
devices and we are actually making it not work (we're making it worse!) when
it would work otherwise, adding «btusb.disable_fake_csr_forcesuspend_hack=1»
should neutralize any side effects, as that workaround wasn't needed
for your dongle in the first place. But we can't be sure of that.

I think we have received two or three reports of this actually helping.

It should be a thing you'd try and see what happens, this isn't an exact
science. Most people won't need it, we're just being thorough and nice.

Letting you skip our little shakeup. Easily.

Re: [Regression] Cambridge Silicon Radio, Ltd Bluetooth Dongle unusable again with kernel 6.0 #forregzbot

[Thorsten Leemhuis]

[Note: this mail is primarily send for documentation purposes and/or for
regzbot, my Linux kernel regression tracking bot. That's why I removed
most or all folks from the list of recipients, but left any that looked
like a mailing lists. These mails usually contain '#forregzbot' in the
subject, to make them easy to spot and filter out.]

[TLDR: I'm adding this regression report to the list of tracked
regressions; all text from me you find below is based on a few templates
paragraphs you might have encountered already already in similar form.]

Hi, this is your Linux kernel regression tracker.

On 24.10.22 23:11, Jack wrote:
> Cheap USB BT dongles that are bad clones of CSR  "ID 0a12:0001 Cambridge
> Silicon Radio, Ltd Bluetooth Dongle (HCI mode)" have had historic
> problems, due to various bad behaviors.  See [Bug 60824]
> [PATCH][regression] Cambridge Silicon Radio, Ltd Bluetooth Dongle
> unusable (https://bugzilla.kernel.org/show_bug.cgi) for more details and
> background.  The patch in that bug was initially mainlined in 5.9, and
> underwent several revisions since then.  It has continued to work
> through all of the 5.19 series, but it does not work with any of the 6.0
> kernels.
> [...]

Thanks for the report. To be sure below issue doesn't fall through the
cracks unnoticed, I'm adding it to regzbot, my Linux kernel regression
tracking bot:

#regzbot ^introduced 766ae2422b4312
#regzbot title net: bluetooth: Cambridge Silicon Radio, Ltd Bluetooth
Dongle unusable again with kernel 6.0
#regzbot ignore-activity

This isn't a regression? This issue or a fix for it are already
discussed somewhere else? It was fixed already? You want to clarify when
the regression started to happen? Or point out I got the title or
something else totally wrong? Then just reply -- ideally with also
telling regzbot about it, as explained here:
https://linux-regtracking.leemhuis.info/tracked-regression/

Reminder for developers: When fixing the issue, add 'Link:' tags
pointing to the report (the mail this one replies to), as explained for
in the Linux kernel's documentation; above webpage explains why this is
important for tracked regressions.

Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)

P.S.: As the Linux kernel's regression tracker I deal with a lot of
reports and sometimes miss something important when writing mails like
this. If that's the case here, don't hesitate to tell me in a public
reply, it's in everyone's interest to set the public record straight.

Re: [Regression] Cambridge Silicon Radio, Ltd Bluetooth Dongle unusable again with kernel 6.0 #forregzbot

[Thorsten Leemhuis]

On 26.10.22 11:17, Thorsten Leemhuis wrote:
> [Note: this mail is primarily send for documentation purposes and/or for
> regzbot, my Linux kernel regression tracking bot. That's why I removed
> most or all folks from the list of recipients, but left any that looked
> like a mailing lists. These mails usually contain '#forregzbot' in the
> subject, to make them easy to spot and filter out.]

> Hi, this is your Linux kernel regression tracker.
> 
> On 24.10.22 23:11, Jack wrote:
>> Cheap USB BT dongles that are bad clones of CSR  "ID 0a12:0001 Cambridge
>> Silicon Radio, Ltd Bluetooth Dongle (HCI mode)" have had historic
>> problems, due to various bad behaviors.  See [Bug 60824]
>> [PATCH][regression] Cambridge Silicon Radio, Ltd Bluetooth Dongle
>> unusable (https://bugzilla.kernel.org/show_bug.cgi) for more details and
>> background.  The patch in that bug was initially mainlined in 5.9, and
>> underwent several revisions since then.  It has continued to work
>> through all of the 5.19 series, but it does not work with any of the 6.0
>> kernels.
>> [...]
> 
> Thanks for the report. To be sure below issue doesn't fall through the
> cracks unnoticed, I'm adding it to regzbot, my Linux kernel regression
> tracking bot:
> 
> #regzbot ^introduced 766ae2422b4312
> #regzbot title net: bluetooth: Cambridge Silicon Radio, Ltd Bluetooth
> Dongle unusable again with kernel 6.0
> #regzbot ignore-activity

#regzbot inconclusive: some of this was fixed, some might still needs
fixing, but it'S tricky; the bluetooth people are working on it afaics

Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)

P.S.: As the Linux kernel's regression tracker I deal with a lot of
reports and sometimes miss something important when writing mails like
this. If that's the case here, don't hesitate to tell me in a public
reply, it's in everyone's interest to set the public record straight.