Re: kern/51522

[Tom Ivar Helbekkmo]

The following reply was made to PR kern/51522; it has been noted by GNATS.

From: Tom Ivar Helbekkmo <t...@hamartun.priv.no>
To: gnats...@netbsd.org
Cc:
Subject: Re: kern/51522
Date: Sun, 09 Oct 2016 10:51:45 +0200

I've been seeing these for a while. Here's a recent one:

barsoom# dmesg -N netbsd.34 -M netbsd.34.core
[...]
fatal protection fault in supervisor mode
trap type 4 code 0 rip ffffffff808ae10d cs 8 rflags 10282 cr2
7a14f761e102 ilevel 4 rsp fffffe8100007a10
curlwp 0xfffffe823f72b420 pid 0.3 lowest kstack 0xfffffe81000042c0
panic: trap
cpu0: Begin traceback...
vpanic() at netbsd:vpanic+0x140
snprintf() at netbsd:snprintf
trap() at netbsd:trap+0xc4b
--- trap (number 4) ---
psref_release() at netbsd:psref_release+0x7f
ip_output() at netbsd:ip_output+0x3c3
icmp_reflect() at netbsd:icmp_reflect+0x568
icmp_error() at netbsd:icmp_error+0x306
udp_input() at netbsd:udp_input+0x4d2
ipintr() at netbsd:ipintr+0xa4e
softint_dispatch() at netbsd:softint_dispatch+0xd3
DDB lost frame for netbsd:Xsoftintr+0x4f, trying 0xfffffe8100007ff0
Xsoftintr() at netbsd:Xsoftintr+0x4f
--- interrupt ---

I suspect the problem may have been there for a long time. This box is
my main VLAN router, and general service host, and runs lots of network
services. The console is a never-ending stream of complaints about
various bits of software (PowerDNS, dhcpd, OpenVPN, etc) not being able
to allocate mbufs when needed, which is somewhat weird, considering that
most of the traffic is limited by my 2Mbps Internet connection, anyway.

Back when it had slower hardware, and used ipfilter, I had to forego
having ipfilter return ICMP messages for dropped packets, because it
made the machine really unstable. Now, with much faster hardware, I'm
letting pf do so ("set block-policy return"), and the crashes look as if
that's when it happens. Might be a coincidence, of course.

[Tom Ivar Helbekkmo]

The following reply was made to PR kern/51522; it has been noted by GNATS.

From: Tom Ivar Helbekkmo <t...@hamartun.priv.no>
To: gnats...@netbsd.org
Cc:
Subject: Re: kern/51522

Date: Tue, 11 Oct 2016 06:43:15 +0200

Incidentally, the crashes looked different under 7.99.36:

crash> crash -M netbsd.33.core -N netbsd.33
Crash version 7.99.39, image version 7.99.36.
WARNING: versions differ, you may not be able to examine this image.
System panicked: kernel diagnostic assertion "(m)->m_type != MT_FREE"
failed: file "/usr/src/sys/kern/uipc_mbuf.c", line 655
Backtrace from time of crash is available.
crash> bt
_KERNEL_OPT_NARCNET() at 0
_KERNEL_OPT_RASOPS_DEFAULT_HEIGHT() at
_KERNEL_OPT_RASOPS_DEFAULT_HEIGHT+0x3
vpanic() at vpanic+0x149
cd_play_msf() at cd_play_msf
m_freem() at m_freem+0xab
udp_input() at udp_input+0x4d2
ipintr() at ipintr+0xa47
softint_dispatch() at softint_dispatch+0xd3
DDB lost frame for Xsoftintr+0x4f, trying 0xfffffe8100007ff0
Xsoftintr() at Xsoftintr+0x4f
--- interrupt ---

[Tom Ivar Helbekkmo]

The following reply was made to PR kern/51522; it has been noted by GNATS.

From: Tom Ivar Helbekkmo <t...@hamartun.priv.no>
To: gnats...@netbsd.org
Cc:
Subject: Re: kern/51522
Date: Tue, 11 Oct 2016 17:21:16 +0200

> Incidentally, the crashes looked different under 7.99.36:

Ah, no. Seems I'm just seeing two different patterns. Just now, with a
7.99.39 from September 28th:

barsoom# dmesg -M netbsd.36.core -N netbsd.36
[...]
panic: kernel diagnostic assertion "(m)->m_type != MT_FREE" failed: file "/usr/src/sys/kern/uipc_mbuf.c", line 655

cpu0: Begin traceback...
vpanic() at netbsd:vpanic+0x140

cd_play_msf() at netbsd:cd_play_msf
m_freem() at netbsd:m_freem+0xab