Created attachment 300343 [details] kernel panic When I use r8723bs (sdio) as access point and a client begins a intensive download or speed test, a kernel panic ocurrs (see attachment). I can reproduce this bug consistently. Also, I have bisected the kernel source code and happens for first time with the following commit: commit 54659ca026e586bbb33a7e60daa6443a3ac6b5df Author: Fabio Aiuto <fabioaiuto83@gmail.com> Date: Mon Sep 20 16:55:00 2021 +0200 staging: rtl8723bs: remove possible deadlock when disconnect (v2)
Thank you for your bug-report. Can you please enable the kernel's lockdep feature (CONFIG_LOCKDEP=y) and then reproduce with that enabled and collect logs again ? That should help with figuring out what is going on here.
Created attachment 300495 [details] CONFIG_LOCKDEP=y I uploaded a new attachment: lockdep.txt. Kernel 5.16.7 recompiled with CONFIG_LOCKDEP=y as you suggested.
Created attachment 300510 [details] Patch removing unneeded lock
Hello Jose Angel, thanks for filing this. Could you tell me if the patch fixes the issue? Thanks a lot.
Thanks Fabio, I have tested your patch and the kernel panic has gone! I am going to use it daily, this patch is enough fine for me. Thanks a lot again, Fabio and Hans.
Hello José, On Tue, Mar 01, 2022 at 08:20:09AM +0000, bugzilla-daemon@kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=215542 > > --- Comment #5 from José Ángel Pastrana (japp.debian@gmail.com) --- > Thanks Fabio, I have tested your patch and the kernel panic has gone! good to hear. Please feel free to do some stress tests if you need and try in STA mode, anyway STA mode should be fine. > > I am going to use it daily, this patch is enough fine for me. > > Thanks a lot again, Fabio and Hans. Happy to help, fabio > > -- > You may reply to this email to add a comment. > > You are receiving this mail because: > You are on the CC list for the bug.
Hi José, Thank you for reporting and testing this. Unfortunately Fabio's fix only fixes one possible deadlock and further analysis has shown that there are other problematic parts also introduced by the commit your bisect found. Since that commit another, extra fix for the same locking issue has landed: commit a7ac783c338b ("staging: rtl8723bs: remove a second possible deadlock") which should fix the original issue even if the bad commit you found is reverted. So after some further analysis, I believe it is best to just revert the bad commit. I'm attaching a patch which does the revert (untested so far) if you can give this a test in access-point mode that would be great. I will run some tests in normal client mode myself tomorrow.
Created attachment 300516 [details] [PATCH] staging: rtl8723bs: Fix access-point mode deadlock
Hi Hans and Fabio, Fabio, I had no problems with sta mode, but also I was testing both sta and access point mode. Hans, about your latest patch, it worked pretty well and I didn't find any problem.
Hello José, good to hear, anyway Hans's patches works better, are cleaner and cover all known cases, they have just been accepted upstream and soon will be mainline. Thank you for your testing. Please could you share the setup you have for AP mode testing? (configuration files) Thanks a lot, Fabio
Created attachment 300525 [details] Configuration files Hello Fabio, I use hostapd 2.9 and dnsmasq 2.86. Check out the attachment file: setup-ap.tgz
Thanks! fabio
The code fix was merged into the Linux kernel 5.18 several months ago [1] and I have been testing it since it was released until today. As this issue was solved finally, I am closing the bug report now. Thanks to all [1] https://github.com/torvalds/linux/commit/8f4347081be32e67b0873827e0138ab0fdaaf450