On 2026-10-17 23:14, Alexandr Nedvedicky wrote:
Hello,
On Mon, Oct 12, 2026 at 02:29:43PM +0300, Atanas Vladimirov wrote:
Hello,
I'm running a bit older 8.0-beta snapshot (Sep 26) and now I got this
kernel panic.
Let me know if anything further is needed from my end.
panic: m_copydata: off -32747 < 0
Stopped at db_enter+0x14: popq %rbp
TID PID UID PRFLAGS PFLAGS CPU COMMAND
360513 98266 826 0x3 0 2 sysctl
358191 67271 826 0x3 0x4000000 3 telegraf
377105 67271 826 0x3 0x4000000 1K telegraf
*312904 61127 0 0x14000 0x200 0 softnet2
db_enter() at db_enter+0x14
panic(ffffffff8266efb5) at panic+0xd5
m_copydata(fffffd0349fce500,ffff8015,8,ffff8001bb224bb8) at
m_copydata+0x11c
pf_setup_pdesc(0,0,0,0,0,0) at pf_setup_pdesc+0x6be
end trace frame: 0x0, count: 11
https://www.openbsd.org/ddb.html describes the minimum info required
in bug
reports. Insufficient info makes it difficult to find and fix bugs.
ddb{0}> show panic
*cpu0: m_copydata: off -32747 < 0
I built kernel from Sept 27th the location in pf_setup_pdesc()
is here:
0xffffffff8261239e is in pf_setup_pdesc
(/home/sashan/src.sashan/sys/net/pf.c:8162).
8157 struct udphdr *uh = &pd->hdr.udp;
8158
8159 if (!pf_pull_hdr(pd->m, pd->off, uh,
sizeof(*uh),
8160 reason, pd->af))
8161 return (PF_DROP);
8162 pd->hdrlen = sizeof(*uh);
8163 if (uh->uh_dport == 0 ||
8164 pd->off + ntohs(uh->uh_ulen) > pd->tot_len
||
8165 ntohs(uh->uh_ulen) < sizeof(struct udphdr))
{
8166 REASON_SET(reason, PFRES_SHORT);
the crash seems to be triggered by some UDP packet. But it is still
wild guess.
because the I would expect to see deeper callstack. it could be
memory corruption
of some sort and pf(4) is just victim here.
any idea how frequently the box crashes?
thanks and
regards
sashan
Hi Alexandr,
Thanks for your time on this.
This is the first time I see such a crash and the machine wasn't crashed
for a long time ...
I'm following -current and try to do a regular upgrades and usually when
I hit something like this
I found that it was already fixed in a more recent snapshot.
Of course, this might not be the case here.
The hardware is SuperMicro with ECC memory (visible from dmesg) and I
can't find any indications for hardware issues from IPMI/BMC.
I'll report here if the same (or similar) crash happens again.
In the mean time please do not hesitate to write me with any questions,
or if I can do something to help further with finding the root cause of
the crash.
Best wishes,
Atanas
