[Cc: +regressions]
#regzbot ^introduced: b7ce436a5d798bc59e71797952566608a4b4626b
#regzbot title: [Bug] [Deadlock] Kernel thread deadlock in rfcomm socket
release when connect interrupted
Dear Pete,
Am 11.09.22 um 17:42 schrieb Peter Sutton:
Just following this up. Is there anything I can do to help fix this?
Running a custom kernel is a real pain. I've been running with the
commit revert and upgrading with Arch Linux kernel releases with no
issue.
(Please do not top post.)
Have you tested bluetooth-next already? Regardless, the offending commit
present in Linux since 5.15-rc1 should be reverted.
Kind regards,
Paul
On Mon, 30 May 2022 at 12:44, Peter Sutton <peter@xxxxxxxxxxxxxxxxx> wrote:
Commit b7ce436a5d798bc59e71797952566608a4b4626b is the probable cause.
I compiled a custom Arch Linux kernel package [1] and the bug was
present. Reverting the commit fixed the bug. Below is the reply I was
writing before Matt found the suspect commit and I tested with the
custom kernel.
What hardware is that?
$ dmesg | grep iwlwifi
Me: Intel(R) Dual Band Wireless AC 8260, REV=0x204
Matt: Intel(R) Dual Band Wireless AC 8265, REV=0x230
We both get:
$ lsusb | grep Bluetooth
Me & Matt: Bus 001 Device 006: ID 8087:0a2b Intel Corp. Bluetooth wireless interface
As a lot of patches are also applied to the stable series, do you know,
if this is a regression? Does it work with Linux 5.15(.0) or 5.10?
Bug is present on current Arch Linux LTS kernel:
$ uname -a
Linux taffer 5.15.43-1-lts #1 SMP Wed, 25 May 2022 14:08:34 +0000 x86_64 GNU/Linux
Matt tested on 5.10.115 and the bug is not present. So I guess it's a
regression. Anecdotally, we encountered this behaviour 1 yr ago
(difficult to say exactly), then it went away but came back about 1 or
2 months ago. All of this is on Arch Linux, I update about once a
week.
[1] https://wiki.archlinux.org/title/Kernel/Arch_Build_System
