On 2023/11/19 4:31, Aditya Garg wrote: > > >> On 14-Nov-2023, at 3:14 PM, Hector Martin <marcan@xxxxxxxxx> wrote: >> >> On 14/11/2023 18.03, Aditya Garg wrote: >>> >>> >>>> On 14-Nov-2023, at 1:28 PM, Hector Martin <marcan@xxxxxxxxx> wrote: >>>> >>>> On 14/11/2023 15.59, Hector Martin wrote: >>>>> On 14/11/2023 15.23, Aditya Garg wrote: >>>>>> >>>>>> >>>>>>> On 14-Nov-2023, at 5:01 AM, Bagas Sanjaya <bagasdotme@xxxxxxxxx> wrote: >>>>>>> >>>>>>> On Mon, Nov 13, 2023 at 08:57:35PM +0000, Aditya Garg wrote: >>>>>>>> Starting from kernel 6.5, a regression in the kernel is causing Bluetooth to not work on T2 Macs with BCM4377 chip. >>>>>>>> >>>>>>>> Journalctl of kernel 6.4.8 which has Bluetooth working is given here: https://pastebin.com/u9U3kbFJ >>>>>>>> >>>>>>>> Journalctl of kernel 6.5.2, which has Bluetooth broken is given here: https://pastebin.com/aVHNFMRs >>>>>>>> >>>>>>>> Also, the bug hasn’t been fixed even in 6.6.1, as reported by users. >>>>>>> >>>>>>> Can you bisect this regression please? >>>>>> >>>>>> Since I don't have access to this hardware, it's not possible for me to bisect this regression. Let's hope someone is able to do so though. >>>>> >>>>> It's not a regression, it was always broken. I'm sending a patch. >>>>> >>>>> - Hector >>>> >>>> You are quite likely conflating two problems. The ubsan issue you quoted >>>> was always there and the patch I just sent fixes it, but it almost >>>> certainly always worked fine in practice without ubsan. >>>> >>>> The Bluetooth problem you are referring to is likely *specific to >>>> Bluetooth LE devices* and the regression was introduced by 288c90224e >>>> and fixed by 41e9cdea9c, which is also in 6.5.11 and 6.6.1. >>>> >>>> If Bluetooth is broken in *some other way* in 6.6.1 then we need a >>>> proper report or a bisect. Your logs don't show any issues other than >>>> the ubsan noise, which is not a regression. >>>> >>>> - Hector >>>> >>> >>> UBSAN noise seems to be fixed, Bluetooth not working though >>> >>> https://pastebin.com/HeVvMVk4 >>> >>> Ill try setting .broken_le_coded = true, >> >> Now you have a probe timeout, which you didn't have before. That's a >> different problem. >> >> Please try this commit and see if it helps: >> >> https://github.com/AsahiLinux/linux/commit/8ec770b4f78fc14629705206e2db54d9d6439686 >> >> If it's this then it's still not a regression, it's probably just random >> chance since I think the old timeout value was borderline for the older >> chips. >> >> - Hector >> > > > Hi > > I recently got a kernel tested with this patch as well as with .broken_le_coded = true, > Here are the logs: https://pastebin.com/BpfJuJKY > > Also, without .broken_le_coded = true, the bluetooth doesn't work, as specified in my previous email. So are you saying everything works now? If not, what doesn't work? "Bluetooth doesn't work" isn't useful information, especially in the absence of any useful error messages. You can't just dump dmesg logs at us, you have to *describe* what the problem is. If broken_le_coded = true "fixed" it then "bluetooth doesn't work" was a terrible bug report. What that quirk does is make *connecting/pairing to Bluetooth LE devices* work. Non-BLE devices already worked, the controller worked, scanning worked, etc. All that is useful information if you want to get support for issues. We can't magically divine what's wrong if you just send us a dmesg and say "it's broken". We need detailed information about exactly what works and what doesn't (e.g. the controller not showing up at all is VERY different from it showing up but not finding your device). The only reason we guessed this here is that this was a known issue that affected other chips. If we ever run into a 4377-specific issue that only you can reproduce, "bluetooth doesn't work" and no error logs really isn't going to get it fixed. - Hector
