Amitai Schleier
2019-01-19 16:03:04 UTC
I'd been getting occasional panics on the netbsd-8 branch under a hosted
amd64 Xen domU. No console access and crash dumps haven't worked, so I
just ignored.
In the last couple weeks, the panicking has considerably increased in
frequency. My best guess for what changed is, I recently enabled IPv6.
Since it's happening way more often, I've been asking my hosting
provider to send me the traces they can see on the console. The first
one looked like NPF (which I'd already been running, and recently added
IPv6-related rules:
fatal page fault in supervisor mode
trap type 6 code 0x2 rip 0xffffffff8159c120 cs 0xe030 rflags
0x10282 cr2 0x10000044 ilevel 0x5 rsp 0xffffa0012aff3b88
curlwp 0xffffa0000ae8e420 pid 0.3 lowest kstack 0xffffa0012aff02c0
panic: trap
cpu0: Begin traceback...
vpanic() at netbsd:vpanic+0x140
snprintf() at netbsd:snprintf
trap() at netbsd:trap+0x953
--- trap (number 6) ---
?() at ffffffff8159c120
npf_packet_handler() at npf:npf_packet_handler+0x1bd
pfil_run_hooks() at netbsd:pfil_run_hooks+0x103
ipintr() at netbsd:ipintr+0x555
softint_thread() at netbsd:softint_thread+0x5c
cpu0: End traceback...
As did the second one (with DEBUG, LOCKDEBUG, and DIAGNOSTIC, from
yesterday's netbsd-8 src/sys):
fatal protection fault in supervisor mode
trap type 4 code 0 rip 0xffffffff81652e75 cs 0xe030 rflags 0x10282
cr2 0x74f885d5a000 ilevel 0x5 rsp 0xffffa0012e2aca60
curlwp 0xffffa000104611a0 pid 16446.1 lowest kstack
0xffffa0012e2a82c0
panic: trap
cpu0: Begin traceback...
vpanic() at netbsd:vpanic+0x140
snprintf() at netbsd:snprintf
trap() at netbsd:trap+0xb0a
--- trap (number 4) ---
npf_ruleset_inspect() at npf:npf_ruleset_inspect+0x133
npf_packet_handler() at npf:npf_packet_handler+0x1bd
pfil_run_hooks() at netbsd:pfil_run_hooks+0x114
ipintr() at netbsd:ipintr+0x469
softint_overlay() at netbsd:softint_overlay+0x503
lwp_userret() at netbsd:lwp_userret+0x209
trap() at netbsd:trap+0x5e1
--- trap (number 6) ---
74f887301fdc:
cpu0: End traceback...
But the third one, just now, looks different. rmind@ suggested this
might be a bug in the xennet driver:
panic: kernel diagnostic assertion "!cpu_intr_p()" failed: file
"../../../../net/bpf.c", line 1564
cpu0: Begin traceback...
vpanic() at netbsd:vpanic+0x140
kern_assert() at netbsd:kern_assert+0x48
_bpf_mtap() at netbsd:_bpf_mtap+0x498
xennet_softstart() at netbsd:xennet_softstart+0x3cd
xennet_handler.part.3() at netbsd:xennet_handler.part.3+0x1c
xennet_handler() at netbsd:xennet_handler+0x18
intr_biglock_wrapper() at netbsd:intr_biglock_wrapper+0x1d
evtchn_do_event() at netbsd:evtchn_do_event+0x27d
do_hypervisor_callback() at netbsd:do_hypervisor_callback+0x17a
hypervisor_callback() at netbsd:hypervisor_callback+0xa1
idle_loop() at netbsd:idle_loop+0x19c
cpu0: End traceback...
I don't know how to reproduce, but some sort of panic-reboot seems to
happen multiple times a day now. What can I try to narrow this down?
Thanks,
- Amitai
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
amd64 Xen domU. No console access and crash dumps haven't worked, so I
just ignored.
In the last couple weeks, the panicking has considerably increased in
frequency. My best guess for what changed is, I recently enabled IPv6.
Since it's happening way more often, I've been asking my hosting
provider to send me the traces they can see on the console. The first
one looked like NPF (which I'd already been running, and recently added
IPv6-related rules:
fatal page fault in supervisor mode
trap type 6 code 0x2 rip 0xffffffff8159c120 cs 0xe030 rflags
0x10282 cr2 0x10000044 ilevel 0x5 rsp 0xffffa0012aff3b88
curlwp 0xffffa0000ae8e420 pid 0.3 lowest kstack 0xffffa0012aff02c0
panic: trap
cpu0: Begin traceback...
vpanic() at netbsd:vpanic+0x140
snprintf() at netbsd:snprintf
trap() at netbsd:trap+0x953
--- trap (number 6) ---
?() at ffffffff8159c120
npf_packet_handler() at npf:npf_packet_handler+0x1bd
pfil_run_hooks() at netbsd:pfil_run_hooks+0x103
ipintr() at netbsd:ipintr+0x555
softint_thread() at netbsd:softint_thread+0x5c
cpu0: End traceback...
As did the second one (with DEBUG, LOCKDEBUG, and DIAGNOSTIC, from
yesterday's netbsd-8 src/sys):
fatal protection fault in supervisor mode
trap type 4 code 0 rip 0xffffffff81652e75 cs 0xe030 rflags 0x10282
cr2 0x74f885d5a000 ilevel 0x5 rsp 0xffffa0012e2aca60
curlwp 0xffffa000104611a0 pid 16446.1 lowest kstack
0xffffa0012e2a82c0
panic: trap
cpu0: Begin traceback...
vpanic() at netbsd:vpanic+0x140
snprintf() at netbsd:snprintf
trap() at netbsd:trap+0xb0a
--- trap (number 4) ---
npf_ruleset_inspect() at npf:npf_ruleset_inspect+0x133
npf_packet_handler() at npf:npf_packet_handler+0x1bd
pfil_run_hooks() at netbsd:pfil_run_hooks+0x114
ipintr() at netbsd:ipintr+0x469
softint_overlay() at netbsd:softint_overlay+0x503
lwp_userret() at netbsd:lwp_userret+0x209
trap() at netbsd:trap+0x5e1
--- trap (number 6) ---
74f887301fdc:
cpu0: End traceback...
But the third one, just now, looks different. rmind@ suggested this
might be a bug in the xennet driver:
panic: kernel diagnostic assertion "!cpu_intr_p()" failed: file
"../../../../net/bpf.c", line 1564
cpu0: Begin traceback...
vpanic() at netbsd:vpanic+0x140
kern_assert() at netbsd:kern_assert+0x48
_bpf_mtap() at netbsd:_bpf_mtap+0x498
xennet_softstart() at netbsd:xennet_softstart+0x3cd
xennet_handler.part.3() at netbsd:xennet_handler.part.3+0x1c
xennet_handler() at netbsd:xennet_handler+0x18
intr_biglock_wrapper() at netbsd:intr_biglock_wrapper+0x1d
evtchn_do_event() at netbsd:evtchn_do_event+0x27d
do_hypervisor_callback() at netbsd:do_hypervisor_callback+0x17a
hypervisor_callback() at netbsd:hypervisor_callback+0xa1
idle_loop() at netbsd:idle_loop+0x19c
cpu0: End traceback...
I don't know how to reproduce, but some sort of panic-reboot seems to
happen multiple times a day now. What can I try to narrow this down?
Thanks,
- Amitai
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de