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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxxx as a cc?


[…]


Kind regards,

Paul
Jack



[Index of Archives]     [Bluez Devel]     [Linux Wireless Networking]     [Linux Wireless Personal Area Networking]     [Linux ATH6KL]     [Linux USB Devel]     [Linux Media Drivers]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Big List of Linux Books]

  Powered by Linux