Kernel Panic when using any 14.0-BETA version up to BETA4 running rustscan while on iwlwifi causes the computer to panic. Steps to Reproduce: Install: pkg install rustscan Run: rustscan -a 192.168.0.1 --ulimit 5000 Result: kernel Panic FreeBSD ThinkPadT480s 14.0-BETA4 FreeBSD 14.0-BETA4 #0 releng/14.0-n265159-ced511bd972a: Fri Sep 29 06:08:27 UTC 2023 root@releng1.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 iwlwifi0@pci0:61:0:0: class=0x028000 rev=0x1a hdr=0x00 vendor=0x8086 device=0x2725 subvendor=0x8086 subdevice=0x0024 vendor = 'Intel Corporation' device = 'Wi-Fi 6 AX210/AX211/AX411 160MHz' class = network
Do you have any information on the panic? panic message? backtrace? Also in case you have a chance, can you try main?
(In reply to Bjoern A. Zeeb from comment #1) I have enabled the following to /etc/rc.conf dumpdev="AUTO" dumpdir="/var/crash" savecore_enable="YES" but ls -la /var/crash total 10 drwxr-x--- 2 root wheel 3 2023-09-19 09:27 ./ drwxr-xr-x 25 root wheel 25 2023-09-30 15:17 ../ -rw-r--r-- 1 root wheel 5 2023-09-15 04:17 minfree No dumps collected... I could try Main on another laptop (ThinkPad x220) if you think that can help.
It seems you can reproduce the problem. Can you take a picture and transcribe the panic or put a photo somewhere. It would help in first place to classify where the problem likely is.
(In reply to Bjoern A. Zeeb from comment #3) when running rustscan on either machine running 14.0-BETA(1,2,3,4) the computer instantly restarts, there isn't any logs printed on screen, nothing captured. I do want to help anyway I can, so if you have any instructions on what you need me to do, I will. Best, M
Created attachment 245364 [details] core/backtrace iwlwifi panic with rustscan I managed to get a backtrace/core. here it is.
(In reply to matuzalem from comment #5) Great. Thank you. The output is bit confusing as there seem to be two different cases in the message buffer. However they seem to have a common part. I'll look into that.
Could you try the patch from https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275710#c2
(In reply to Bjoern A. Zeeb from comment #7) Do you know why "git apply" does not work from the patch directly? root@n1_iwl_vm:/usr/src # git apply --check /usr/patches/20231212-02-lkpi-txq.diff error: compat/linuxkpi/common/include/net/mac80211.h: No such file or directory error: compat/linuxkpi/common/src/linux_80211.c: No such file or directory error: compat/linuxkpi/common/src/linux_80211.h: No such file or directory But the interactive "patch" works. root@n1_iwl_vm:/usr/src # patch -p1 < /usr/patches/20231212-02-lkpi-txq.diff Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |diff --git sys/compat/linuxkpi/common/include/net/mac80211.h sys/compat/linuxkpi/common/include/net/mac80211.h |index fa36bd84ac6e..c4d001b3a7e8 100644 |--- sys/compat/linuxkpi/common/include/net/mac80211.h |+++ sys/compat/linuxkpi/common/include/net/mac80211.h -------------------------- File to patch: No file found--skip this patch? [y] n File to patch: sys/compat/linuxkpi/common/include/net/mac80211.h Patching file sys/compat/linuxkpi/common/include/net/mac80211.h using Plan A... Hunk #1 succeeded at 1117. Hunk #2 succeeded at 1683. Hunk #3 succeeded at 1708. Hunk #4 succeeded at 2199. Hunk #5 succeeded at 2470. ...
(In reply to Cheng Cui from comment #8) Sorry, I posted in the wrong PR.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=eac3646fcdd445297cade756630335e23e92ea13 commit eac3646fcdd445297cade756630335e23e92ea13 Author: Bjoern A. Zeeb <bz@FreeBSD.org> AuthorDate: 2023-12-12 01:59:17 +0000 Commit: Bjoern A. Zeeb <bz@FreeBSD.org> CommitDate: 2023-12-19 00:50:49 +0000 LinuxKPI: 802.11: more TXQ implementation and locking Implement ieee80211_handle_wake_tx_queue() and ieee80211_tx_dequeue_ni() while looking at the code. They are needed by various wireless drivers. Introduce an ltxq lock and protect the skbq by that. This prevents panics due to a race between a driver upcall and the net80211 tx downcall. While the former should be rcu protected we cannot rely on that. It remains questionable if we need to protect further fields there (with a different lock?). Also introduce a txq_mtx on the lhw which needs to be further deployed but we need to come up with a good strategy to not end up with 7 different locks. Sponsored by: The FreeBSD Foundation PR: 274178, 275710 Tested by: cc MFC after: 3 days sys/compat/linuxkpi/common/include/net/mac80211.h | 27 +++++---- sys/compat/linuxkpi/common/src/linux_80211.c | 67 +++++++++++++++++++++-- sys/compat/linuxkpi/common/src/linux_80211.h | 29 +++++++++- 3 files changed, 107 insertions(+), 16 deletions(-)
A commit in branch stable/14 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=1c7be8ecaddfac2b412244e91f924bf73f95658a commit 1c7be8ecaddfac2b412244e91f924bf73f95658a Author: Bjoern A. Zeeb <bz@FreeBSD.org> AuthorDate: 2023-12-12 01:59:17 +0000 Commit: Bjoern A. Zeeb <bz@FreeBSD.org> CommitDate: 2024-02-18 18:31:14 +0000 LinuxKPI: 802.11: more TXQ implementation and locking Implement ieee80211_handle_wake_tx_queue() and ieee80211_tx_dequeue_ni() while looking at the code. They are needed by various wireless drivers. Introduce an ltxq lock and protect the skbq by that. This prevents panics due to a race between a driver upcall and the net80211 tx downcall. While the former should be rcu protected we cannot rely on that. It remains questionable if we need to protect further fields there (with a different lock?). Also introduce a txq_mtx on the lhw which needs to be further deployed but we need to come up with a good strategy to not end up with 7 different locks. Sponsored by: The FreeBSD Foundation PR: 274178, 275710 Tested by: cc (cherry picked from commit eac3646fcdd445297cade756630335e23e92ea13) sys/compat/linuxkpi/common/include/net/mac80211.h | 27 +++++---- sys/compat/linuxkpi/common/src/linux_80211.c | 67 +++++++++++++++++++++-- sys/compat/linuxkpi/common/src/linux_80211.h | 29 +++++++++- 3 files changed, 107 insertions(+), 16 deletions(-)
A commit in branch stable/13 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=3df959638baa60c1c88e9ac66289502f99ad8418 commit 3df959638baa60c1c88e9ac66289502f99ad8418 Author: Bjoern A. Zeeb <bz@FreeBSD.org> AuthorDate: 2023-12-12 01:59:17 +0000 Commit: Bjoern A. Zeeb <bz@FreeBSD.org> CommitDate: 2024-02-19 08:02:00 +0000 LinuxKPI: 802.11: more TXQ implementation and locking Implement ieee80211_handle_wake_tx_queue() and ieee80211_tx_dequeue_ni() while looking at the code. They are needed by various wireless drivers. Introduce an ltxq lock and protect the skbq by that. This prevents panics due to a race between a driver upcall and the net80211 tx downcall. While the former should be rcu protected we cannot rely on that. It remains questionable if we need to protect further fields there (with a different lock?). Also introduce a txq_mtx on the lhw which needs to be further deployed but we need to come up with a good strategy to not end up with 7 different locks. Sponsored by: The FreeBSD Foundation PR: 274178, 275710 Tested by: cc (cherry picked from commit eac3646fcdd445297cade756630335e23e92ea13) sys/compat/linuxkpi/common/include/net/mac80211.h | 27 +++++---- sys/compat/linuxkpi/common/src/linux_80211.c | 67 +++++++++++++++++++++-- sys/compat/linuxkpi/common/src/linux_80211.h | 29 +++++++++- 3 files changed, 107 insertions(+), 16 deletions(-)
A commit in branch releng/13.3 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=804a4c1c7b8fe00a6924fa5e4ae27a487bdc2337 commit 804a4c1c7b8fe00a6924fa5e4ae27a487bdc2337 Author: Bjoern A. Zeeb <bz@FreeBSD.org> AuthorDate: 2023-12-12 01:59:17 +0000 Commit: Bjoern A. Zeeb <bz@FreeBSD.org> CommitDate: 2024-02-19 16:06:43 +0000 LinuxKPI: 802.11: more TXQ implementation and locking Implement ieee80211_handle_wake_tx_queue() and ieee80211_tx_dequeue_ni() while looking at the code. They are needed by various wireless drivers. Introduce an ltxq lock and protect the skbq by that. This prevents panics due to a race between a driver upcall and the net80211 tx downcall. While the former should be rcu protected we cannot rely on that. It remains questionable if we need to protect further fields there (with a different lock?). Also introduce a txq_mtx on the lhw which needs to be further deployed but we need to come up with a good strategy to not end up with 7 different locks. Approved by: re (cperciva) Sponsored by: The FreeBSD Foundation PR: 274178, 275710 Tested by: cc (cherry picked from commit eac3646fcdd445297cade756630335e23e92ea13) (cherry picked from commit 3df959638baa60c1c88e9ac66289502f99ad8418) sys/compat/linuxkpi/common/include/net/mac80211.h | 27 +++++---- sys/compat/linuxkpi/common/src/linux_80211.c | 67 +++++++++++++++++++++-- sys/compat/linuxkpi/common/src/linux_80211.h | 29 +++++++++- 3 files changed, 107 insertions(+), 16 deletions(-)
I believe this should be fixed in all branches now. Can you re-test or can we close this?
(In reply to Bjoern A. Zeeb from comment #14) I've tested on 14.0x and issue is resolved.