https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=285813
Kristof Provost <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #13 from Kristof Provost <[email protected]> --- 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.
