Date: Thu, 16 Sep 2004 03:53:28 -0000 From: Max Laier <max@love2party.net> To: Bruno Afonso <brunomiguel@dequim.ist.utl.pt> Cc: "pf4freebsd@freelists.org" <pf4freebsd@freelists.org> Subject: [pf4freebsd] Re: pf errors meaning Message-ID: <19920876018.20031002175427@love2party.net> In-Reply-To: <1065107810.3f7c4162b252a@mrna.ist.utl.pt> References: <1065107810.3f7c4162b252a@mrna.ist.utl.pt>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello Bruno, Thursday, October 2, 2003, 5:16:50 PM, you wrote: BA> I'm sorry to disturb the ML silence ;) but I am gettin' some odd pani= cs with a BA> machine since I upgraded to 1.66. They may be totally unrelated, but = it has BA> been two in two days! First crash was due to dnscache, then, last nig= ht I BA> disabled and replace it with bind. Today morning, it crashed again. S= o, it's BA> either hardware, pf or god playing with me :> Well ... what do you mean by "due to dnscache"? Any traces, dumps or anything that might help to really debug? BA> I must say that the machine has been routing ~1megbyte/sec for 24h+. = Can this BA> be too much of a stress ? :> Should not ... obviously. BA> btw, Fbsd 5.1, pf 1.66, no altq. BA> Here are some pf errors while booting the machine with pf enabled on = boot. BA> Oct 2 10:34:09 deq kernel: pflog: $Name: VERSION_1_66 $ BA> Oct 2 10:34:09 deq kernel: pfsync: $Name: VERSION_1_66 $ BA> Oct 2 10:34:09 deq kernel: in6_ifattach: pflog0 is not multicast cap= able, IPv6 BA> not enabled BA> Oct 2 10:34:09 deq kernel: in6_ifattach: pfsync0 is not multicast ca= pable, BA> IPv6 not enabled BA> Oct 2 10:34:09 deq kernel: pflog0: promiscuous mode enabled BA> Oct 2 10:34:09 deq kernel: pf: $Name: VERSION_1_66 $ Okay, the above are the normal boot messages. The two from in6_ifattach are meaningless (can't be fixed without touching the kernel). BA> Oct 2 10:34:34 deq kernel: Zone pfrktable was not empty (18 items). = Lost 2 BA> pages of memory. BA> Oct 2 10:34:34 deq kernel: Zone pfrkentry was not empty (34 items). = Lost 4 BA> pages of memory. These are strange (and should not exist). First of all such should only show up when you remove the pf module and even then, they should not. The meaning of it, is that some tables could not be freed as expected. In the long run that's bad. Check the output of "vmstat -z | grep ^pf" after some time of operation. If the "USED" value increases steadily that'd be a sign of memory leakage (which could lead to a crash). However, I am running pf as well, check "vmstat -z" regularly and did not see any hints for a memory leak. So this might be a problem only for module unload. I'll look into it. BA> Oct 2 10:34:34 deq kernel: pflog0: promiscuous mode disabled BA> Oct 2 10:34:34 deq pflogd[481]: read: Device not configured BA> Oct 2 10:34:34 deq pflogd[481]: Exiting due to signal BA> Oct 2 10:34:34 deq pflogd[481]: 0 packets received, 0 dropped These are the normal messages from the stop phase of the pf.sh script. BA> thoughts? Hmmm ... for some reason your seem to remove/stop pf right after (23sec) you loaded/started it. That might come from old pf.sh scripts lurking around in /usr/local/etc/rc.d from a previous ports installation. Please check kdlstat output once the box booted to make sure that you really have pf in place. Additionally you'd make sure that you only have the up2date modules and not old ones in /usr/local/modules from a previous port installation. If you keep getting panics it'd be quite interesting to see at least a trace of those. Without it, it's impossible to tell what's the reason for it. --=20 Best regards, Max mailto:max@love2party.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19920876018.20031002175427>