NetBSD-Bugs archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
kern/55182: NPF on NetBSD 9 can lock / panic machine
>Number: 55182
>Category: kern
>Synopsis: NPF on NetBSD 9 can lock / panic machine
>Confidential: no
>Severity: critical
>Priority: high
>Responsible: kern-bug-people
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Wed Apr 15 17:00:01 +0000 2020
>Originator: John Klos
>Release: NetBSD 9.0_STABLE
>Organization:
>Environment:
System: NetBSD athena.zia.io 9.0_STABLE NetBSD 9.0_STABLE (ATHENA-$Revision: 9.0q $) #1: Fri Apr 10 06:29:38 UTC 2020 john%athena.zia.io@localhost:/home/obj-alpha/sys/arch/alpha/compile/ATHENA alpha
Architecture: alpha
Machine: alpha
>Description:
NPF on NetBSD 9 has caused a direct panic on Alpha and a complete lockup
on amd64 by running:
echo "199.233.217.205" >> /etc/npf_blacklist ; /etc/rc.d/npf reload
The panic on Alpha gave:
[ 4656449.519341] CPU 0: fatal kernel trap:
[ 4656449.521294] CPU 0 trap entry = 0x2 (memory management fault)
[ 4656449.522270] CPU 0 a0 = 0x0
[ 4656449.523247] CPU 0 a1 = 0x1
[ 4656449.524224] CPU 0 a2 = 0x0
[ 4656449.525200] CPU 0 pc = 0xfffffc0000bc9048
[ 4656449.526177] CPU 0 ra = 0xfffffc0000bc2d0c
[ 4656449.527153] CPU 0 pv = 0xfffffc0000bc9030
[ 4656449.528130] CPU 0 curlwp = 0xfffffc0150c7c580
[ 4656449.529106] CPU 0 pid = 29135, comm = npfctl
[ 4656449.531059] panic: trap
The amd64 system had to be power cycled (it is remote).
On other amd64 NetBSD 9 systems, I have observed:
Plenty of NAT traffic, fine.
Tons of network connections and work, fine.
Both together, I can lock up a machine pretty reliably within an hour.
One issue is that even when I've had this happen locally, I cannot get
in to the kernel debugger on amd64 after a lockup.
The configurations are essentially the same as in the NPF documentation.
This is both with GENERIC kernels and with kernels with NPF compiled in.
>How-To-Repeat:
Set up a machine to do NAT via NPF for a somewhat busy network using the
example configurations in the NPF documentation.
While the network is reasonably busy, either make changes to NPF and run
"/etc/rc.d/npf reload", or create lots of network traffic on the machine
running NPF. There will be a non-trivial chance of lockup or panic.
>Fix:
>Unformatted:
Home |
Main Index |
Thread Index |
Old Index