[email protected] writes: I wrote this PR a little while ago.....
kern/57136: NPF panic probably on a NPF table list call >>Category: kern >>Responsible: kern-bug-people >>Synopsis: NPF panic probably on a NPF table list call >>Arrival-Date: Fri Dec 23 20:20:00 +0000 2022 I was finally able to catch more of the panic message. It appears to be a diagnostic assertion in kern_synch.c. Copied from an image this is the assert: panic: kernel diagnostic assertion "ci->ci_mtx_count == -1" failed: file "../../../../kern/kern_synch.c", line 726 mi_switch: cpu0: ci_mtx_count (-2) != -1 (block with spin-mutex held) (following that is the panic I copied into the PR) The system is a pure PVH DOMU running a 10.0_BETA mostly GENERIC kernel with 2 VCPUS and 12GB of memory. What was going on at the time was a tar-pipe copy "tar -cf - . | (cd /someplace;tar -xvf -)" and probably a pretty large network burst of activity from another system on the lan into the DOMU (and a bunch of other stuff, like being a router and firewall). The trigger of the panic is as mentioned in the PR, a "npfctl table sometable list" was performed from a cron job, but that wasn't where the actual panic happened, it seems. ... so lots of Xen guest disk and some Xen network activity was present. I have other DOMUs that perform the same npfctl actions just as often and they never panic... but they also only have 1 VCPU. The DOMU that panics is the only one with more than 1 VCPU. The problem does seem to get worse, in the sense that the panic happens more often, if 3 VCPUs are given to the DOMU. As it is right now, the panic can't exactly be reproduced upon demand, but pretty much WILL happen at day 6 or so of uptime if some sort of activity ties up the CPUS (this may be a bit subjective on my part, but it seems like the system can handle activity better in days 1 to 5 and only around day 6 does the chances of the panic increase, but I may also be smoking something...). With 3 VCPUs, it was happening about every 30 hours. Any help or hints would be greatly appreciated. With some planning I can perform tests. -- Brad Spencer - [email protected] - KC8VKS - http://anduin.eldar.org
