On 09/10/15 21:23, hiren panchasara wrote:
I am on 11.0-CURRENT FreeBSD 11.0-CURRENT #4 r286760M: Thu Sep 10
08:15:43 MST 2015
I get random (1 out of 10 tries) panics when I do:
# kldunload dummynet ; kldunload ipfw ;kldload ipfw ; kldload dummynet
I used to get panics on a couple months old -head also.
kernel trap 12 with interrupts disabled
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address = 0xffffffff8225cf58
fault code = supervisor read data, page not present
instruction pointer = 0x20:0xffffffff80aad500
stack pointer = 0x28:0xfffffe1f9d588700
frame pointer = 0x28:0xfffffe1f9d588790
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
Following https://www.freebsd.org/doc/faq/advanced.html, I did:
# nm -n /boot/kernel/kernel | grep ffffffff80aad500
# nm -n /boot/kernel/kernel | grep ffffffff80aad50
# nm -n /boot/kernel/kernel | grep ffffffff80aad5
# nm -n /boot/kernel/kernel | grep ffffffff80aad
ffffffff80aad030 t itimers_event_hook_exec
ffffffff80aad040 t realtimer_expire
ffffffff80aad360 T callout_process
ffffffff80aad6b0 t softclock_call_cc
ffffffff80aadc10 T softclock
ffffffff80aadd20 T timeout
ffffffff80aade90 T callout_reset_sbt_on
So I guess " ffffffff80aad360 T callout_process" is the closest match?
I'll try to get real dump to get more information but that may take a
while.
ccing jch and hans who've been playing in this area.
Hi,
Possibly it means some timer was not drained before the module was
unloaded. It is not enough to only stop timers before freeing its
memory. Or maybe a timer was restarted after drain.
Can you get the full backtrace and put debugging symbols into the kernel?
--HPS
Cheers,
Hiren
_______________________________________________
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
