Created attachment 229267 [details] crash text Attached are the details
Thank you for your report. Could you include additional information, including: - /var/run/dmesg.boot output (as an attachment) - /etc/rc.conf network configuration (as an attachment) - pciconf -lv output (as an attachment) - firewall (pf) configuration (as an attachment, sanitized where necessary)
This smells a lot like #254419. Possibly we need to mb_unmapped_to_ext() in pf_check_proto_cksum() as well.
> after FreeBSD 13.0 p5 update update from which version?
FreeBSD 13.0 p4 to 13.0 p5
IT did happen a second time
Created attachment 229295 [details] 2nd crash tesxt
Kubilay Kocak I am adding what you requested in a file called crash20211105
Created attachment 229296 [details] file containing technical details upon request
(In reply to Kristof Provost from comment #2) This path is somewhat tricky to fix, it seems, since we'd have to modify a few functions to return a new mbuf, and handle out-of-memory conditions. So maybe this (WIP) approach is better instead: https://reviews.freebsd.org/D32859
Created attachment 229338 [details] Yet another crash from this morning 3rd crash since updating to 3.0 p5
This is getting ridiculous. I am getting crashes rather regulary. Should I turn pf until this is fixed?
(In reply to doctor from comment #11) Could you please instead try setting # sysctl kern.ipc.mb_use_ext_pgs=0 and confirm whether or not the panics go away? I am working on a proper solution in the meantime.
just set to 0 . Still This should be treated as a DoS Style takedown. I am adding 2 more core txts.
Created attachment 229351 [details] 4th crash 4th crash text
Created attachment 229352 [details] 5th crash 5th crash report
*** Bug 257627 has been marked as a duplicate of this bug. ***
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=0d9c3423f59bb305301f5a5bc7c8f5daf7b7aa52 commit 0d9c3423f59bb305301f5a5bc7c8f5daf7b7aa52 Author: Mark Johnston <markj@FreeBSD.org> AuthorDate: 2021-11-24 18:19:54 +0000 Commit: Mark Johnston <markj@FreeBSD.org> CommitDate: 2021-11-24 18:31:16 +0000 netinet: Implement in_cksum_skip() using m_apply() This allows it to work with unmapped mbufs. In particular, in_cksum_skip() calls no longer need to be preceded by calls to mb_unmapped_to_ext() to avoid a page fault. PR: 259645 Reviewed by: gallatin, glebius, jhb MFC after: 1 week Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D33096 sys/netinet/in_cksum.c | 63 +++++++++++++++++++++++++------------------------- 1 file changed, 32 insertions(+), 31 deletions(-)
A commit in branch stable/13 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=dfd5240189ca024b268e53df2f0a3076df57b240 commit dfd5240189ca024b268e53df2f0a3076df57b240 Author: Mark Johnston <markj@FreeBSD.org> AuthorDate: 2021-11-24 18:19:54 +0000 Commit: Mark Johnston <markj@FreeBSD.org> CommitDate: 2021-12-01 12:43:03 +0000 netinet: Implement in_cksum_skip() using m_apply() This allows it to work with unmapped mbufs. In particular, in_cksum_skip() calls no longer need to be preceded by calls to mb_unmapped_to_ext() to avoid a page fault. PR: 259645 Reviewed by: gallatin, glebius, jhb Sponsored by: The FreeBSD Foundation (cherry picked from commit 0d9c3423f59bb305301f5a5bc7c8f5daf7b7aa52) sys/netinet/in_cksum.c | 63 +++++++++++++++++++++++++------------------------- 1 file changed, 32 insertions(+), 31 deletions(-)
Fixed in stable/13 now. The patches will appear in 13.1, as we have a workaround (kern.ipc.mb_use_ext_pgs=0) in the meantime. With 13.1 that workaround will not be necessary.
(In reply to Mark Johnston from comment #19) Could you confirm stable/12 is not affected and doesn't need the merge?
(In reply to Kubilay Kocak from comment #20) Yes, the bug is in 13.0 and later.
Hi, I patched yesterday at around 8AM CET from 13.0-p4 to 13.0-p5 and experienced two crashes in a a few minutes at around 11PM CET. I guess it's related to this bug and will apply the workaround. I'm running on a Bare Metal server (i5-3570S). More server details in attachments (prefixed by apn).
Created attachment 229950 [details] apn PF Firewall configuration
Created attachment 229951 [details] apn pciconf -lv
Created attachment 229952 [details] apn dmesg.boot
(In reply to Arnaud de Prelle from comment #22) Can you share the panic string and backtrace? Or a copy of /var/crash/core.txt.<N> from the crash. The files that you attached do not tell me anything. The bug has nothing to do with 13.0-p5 specifically, the title is misleading.
(In reply to Mark Johnston from comment #26) Hi Mark, I don't have a core file in /var/crash: # ls -ltra /var/crash total 12 -rw-r--r-- 1 root wheel 5 Jan 16 2014 minfree drwxr-x--- 2 root wheel 512 Jan 16 2014 . drwxr-xr-x 30 root wheel 512 Dec 6 22:54 .. # Note that it's the first and only crash in years that I experience on my FreeBSD server, so I immediately linked this crash to the update performed a few hours before and to this ticket which I was already following. Now it could be a coincidence ? Electricity cut(s) at OVH (my bare metal hoster) side ? Hardware issue ?
(In reply to Arnaud de Prelle from comment #27) Do you have kernel dumps configured? What does "dumpon -l" print? Without some console logs from the time of the reset it's impossible to say what happened. There is nothing that can be diagnosed from what you have shared here. If there is more info available, then I suggest opening a new PR since I'm skeptical that this one is related.
(In reply to Mark Johnston from comment #28) Yes, kernel dumps are enabled imho : BSD:~ # grep dumpdev /etc/rc.conf | grep -v "^#" dumpdev="AUTO" BSD:~ # dumpon -l ada0s1b # grep ada0s1b /etc/fstab /dev/ada0s1b swap swap sw 0 0 I issued a "savecore /var/crash /dev/ada0s1b" which didn't result in files being generated in /var/crash/. I'll open a dedicated PR should I have more valuable logs/outputs to share.