Re: [REGRESSION] Bluetooth not working on 5.15+ since "Bluetooth: Move shutdown callback before flushing tx and rx queue"

[Thorsten Leemhuis <regressions@leemhuis.info>]

Top-posting for once, to make this easy accessible to everyone.

Coldolt, could you please check if this regression is still in 5.17-rc1
or 5.16.2? I wonder if this patch fixed things:

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-5.16.y&id=8e8cae520210139aab4b701a822bbefb13b8f007

Ciao, Thorsten

#regzbot poke

On 20.01.22 14:08, Thorsten Leemhuis wrote:
> On 10.12.21 10:16, Thorsten Leemhuis wrote:
>> Hi, this is your Linux kernel regression tracker speaking.
> 
> /me again
> 
>> On 10.12.21 02:10, An, Tedd wrote:
>>> On Fri, 2021-12-10 at 01:36 +0200, coldolt wrote:
>>>> After a restart, bluetooth doesn't work since commit 0ea53674d07f
>>>> "Bluetooth: Move shutdown callback before flushing tx and rx queue"
>>>>
>>>> bluetoothctl doesn't list any controllers and I get the following in
>>>> dmesg | grep -i bluetooth
>>>>
>>>> [    2.634812] Bluetooth: Core ver 2.22
>>>> [    2.634843] NET: Registered PF_BLUETOOTH protocol family
>>>> [    2.634845] Bluetooth: HCI device and connection manager initialized
>>>> [    2.634850] Bluetooth: HCI socket layer initialized
>>>> [    2.634853] Bluetooth: L2CAP socket layer initialized
>>>> [    2.634858] Bluetooth: SCO socket layer initialized
>>>> [    4.077788] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
>>>> [    4.077794] Bluetooth: BNEP filters: protocol multicast
>>>> [    4.077799] Bluetooth: BNEP socket layer initialized
>>>> [    4.078219] random: bluetoothd: uninitialized urandom read (4 bytes read)
>>>> [    4.852835] Bluetooth: hci0: Reading Intel version command failed (-110)
>>>> [    4.852838] Bluetooth: hci0: command 0xfc05 tx timeout
>>>>
>>>> However, it works after a cold start or after putting the computer to sleep.
>>>>
>>>> Before 83f2dafe2a62 "Bluetooth: btintel: Refactoring setup routine for
>>>> legacy ROM sku", it always works after a restart, but from that commit
>>>> up until before 0ea53674d07f it either works or doesn't work after a
>>>> restart depending on if before restart it was working or not, meaning
>>>> it stays working or stays not working.
>>>>
>>>> Also on the first restart from before 83f2dafe2a62 into 0ea53674d07f
>>>> or later it works, but then restarting again into 0ea53674d07f or
>>>> later it no longer works. So it seems that 0ea53674d07f and later puts
>>>> the bluetooth in a nonworking state if you restart from it, but before
>>>> 83f2dafe2a62 it puts it back into a working state at startup, and in
>>>> between it doesn't do either, i.e. it stays the way it was.
>>>>
>>>> I have a Dell Latitude E5550 laptop with an Intel 7265 wifi/bluetooth
>>>> card REV=0x210 firmware version 29.4063824552.0 7265D-29. I'm on Arch
>>>> Linux, the problem is still there on 5.16-rc4.
>>>>
>>>> Here is a thread on the Arch Linux forums with several people with the
>>>> same problem, for some of them it got fixed with a kernel update or by
>>>> reloading modules, but not for everybody, including me
>>>> https://bbs.archlinux.org/viewtopic.php?id=271459
>>>>
>>>> #regzbot introduced 0ea53674d07f
>>
>> Many thx for directly getting regzbot involved! :-D
>>
>>> This issue is under investigation to find the root cause and proper solution.
>>
>> Only internally? Or are there any other related public discussions that
>> are relevant to this and thus good to be aware of?
> 
> What's the status here? It looks like there was no progress since 41
> days, which is awfully long even with the festive season in between.
> Could anyone provide a status update please?
> 
> Ciao, Thorsten
> 
> #regzbot poke
> 
> P.S.: As a Linux kernel regression tracker I'm getting a lot of reports
> on my table. I can only look briefly into most of them. Unfortunately
> therefore I sometimes will get things wrong or miss something important.
> I hope that's not the case here; if you think it is, don't hesitate to
> tell me about it in a public reply, that's in everyone's interest.
> 
> BTW, I have no personal interest in this issue, which is tracked using
> regzbot, my Linux kernel regression tracking bot
> (https://linux-regtracking.leemhuis.info/regzbot/). I'm only posting
> this mail to get things rolling again and hence don't need to be CC on
> all further activities wrt to this regression.
> 
>>> The downloaded firmware breaks the behavior though, we need to investigate
>>> further to see if it can be fixed in firmware or fix in the driver.
>>
>> The answer from my point is simple: it needs to be fixed in the kernel,
>> not just in the firmware, otherwise people that update the kernel
>> without updating the firmware at the same time will run into a
>> regression -- and that is not acceptable by kernel development standards.
>>
>> Ciao, Thorsten
>>
>> P.S.: As a Linux kernel regression tracker I'm getting a lot of reports
>> on my table. I can only look briefly into most of them. Unfortunately
>> therefore I sometimes will get things wrong or miss something important.
>> I hope that's not the case here; if you think it is, don't hesitate to
>> tell me about it in a public reply. That's in everyone's interest, as
>> what I wrote above might be misleading to everyone reading this; any
>> suggestion I gave they thus might sent someone reading this down the
>> wrong rabbit hole, which none of us wants.
>>
>> BTW, I have no personal interest in this issue, which is tracked using
>> regzbot, my Linux kernel regression tracking bot
>> (https://linux-regtracking.leemhuis.info/regzbot/). I'm only posting
>> this mail to get things rolling again and hence don't need to be CC on
>> all further activities wrt to this regression.