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.
