On 2023/11/21 20:42, Aditya Garg wrote: > > >> On 20-Nov-2023, at 4:37 PM, Hector Martin <marcan@xxxxxxxxx> wrote: >> >> >> >>> 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. >> > My bad for not specifying that. The user reports that the Bluetooth device is not recognised at all. > > Also, broken_le_coded = true did not "fix" it. > > Talking about dmesg, well not getting any logs regarding this message indeed is a frustrating thing for me, and bisecting seems to be the only option in my mind rn. > What does that mean? The controller or the device? Can you initiate a scan? Does it find any devices? Is pairing broken or just connecting? Was the device paired before or after the breaking change? *What* device are you trying to use/pair? What do these commands say? $ bluetoothctl show $ bluetoothctl devices Since the kernel isn't logging any errors, have you looked at syslog to see what the whole userspace side has to say? If an operation is failing *something* should be logging an error. *Please*, we need proper detailed bug reports if you want this to get fixed. I'm sure you're aware of what a reasonable bug report is. Please teach your user how to provide useful information. Otherwise yes, it's going to be on you to bisect it since there's nothing we can do with zero details and useful logs. - Hector
