The box with the problem had lots of arp: ip moved from mac to mac messages. They did not happen around the same time of the crash. I’ve fixed them since and by statically allocating the IP adresses they no longer happened.
> On 13 Aug 2025, at 14:17, bugzilla-nore...@freebsd.org wrote: > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=285813 > > Kristof Provost <k...@freebsd.org> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |k...@freebsd.org > > --- Comment #13 from Kristof Provost <k...@freebsd.org> --- > We have at least one pfSense (CE 2.8.0, which is basically FreeBSD main from a > few months ago) user running into this panic as well. > We've obtained one core dump, which I'm not entirely sure is the same problem. > > The relevant bits: > #16 <signal handler called> > #17 callout_process (now=now@entry=4696905619631) at > /var/jenkins/workspace/pfSense-CE-snapshots-2_8_0-main/sources/FreeBSD-src-RELENG_2_8_0/sys/kern/kern_timeout.c:498 > #18 0xffffffff80c82366 in handleevents (now=now@entry=4696905619631, > fake=fake@entry=0) > at > /var/jenkins/workspace/pfSense-CE-snapshots-2_8_0-main/sources/FreeBSD-src-RELENG_2_8_0/sys/kern/kern_clocksource.c:212 > #19 0xffffffff80c82f56 in timercb (et=0xffffffff82b2d3c8 <lapic_et>, > arg=<optimized out>) > at > /var/jenkins/workspace/pfSense-CE-snapshots-2_8_0-main/sources/FreeBSD-src-RELENG_2_8_0/sys/kern/kern_clocksource.c:353 > #20 0xffffffff813b3cab in lapic_handle_timer (frame=<optimized out>) > at > /var/jenkins/workspace/pfSense-CE-snapshots-2_8_0-main/sources/FreeBSD-src-RELENG_2_8_0/sys/x86/x86/local_apic.c:1324 > #21 <signal handler called> > #22 0xffffffff804eb162 in acpi_cpu_idle (sbt=<optimized out>) at > /var/jenkins/workspace/pfSense-CE-snapshots-2_8_0-main/sources/FreeBSD-src-RELENG_2_8_0/sys/dev/acpica/acpi_cpu.c:1167 > #23 0xffffffff812ab556 in cpu_idle_acpi (sbt=404313140) at > /var/jenkins/workspace/pfSense-CE-snapshots-2_8_0-main/sources/FreeBSD-src-RELENG_2_8_0/sys/x86/x86/cpu_machdep.c:589 > #24 0xffffffff812ab60d in cpu_idle (busy=0) at > /var/jenkins/workspace/pfSense-CE-snapshots-2_8_0-main/sources/FreeBSD-src-RELENG_2_8_0/sys/x86/x86/cpu_machdep.c:678 > #25 0xffffffff80d2ce36 in sched_idletd (dummy=dummy@entry=0x0) at > /var/jenkins/workspace/pfSense-CE-snapshots-2_8_0-main/sources/FreeBSD-src-RELENG_2_8_0/sys/kern/sched_ule.c:3058 > #26 0xffffffff80caf53b in fork_exit (callout=0xffffffff80d2c8f0 > <sched_idletd>, > arg=0x0, frame=0xfffffe015840bf40) > > We've somehow wound up with a struct callout entry in cc->cc_callwheel[] > that's > entirely zeroed out. > > That left me wondering if we're somehow freeing an llentry without stopping > the > callout. > I'm not sure if llentry_free()'s 'if (callout_stop() > 0)' is correct. The man > page claims callout_stop() can return -1, 0 or 1, and I wonder if the '0' case > (i.e. the callout is currently running and cannot be stopped) is leaving us in > a scenario where the callout will reschedule itself but llentry_free() frees > it. > That's mostly speculation, I'm not familiar enough with the relevant code for > much more than that. > > -- > You are receiving this mail because: > You are the assignee for the bug.
