[pf4freebsd] Re: pf errors meaning
yongari at kt-is.co.kr
Wed Sep 15 20:53:43 PDT 2004
On Fri, Oct 03, 2003 at 12:17:24AM +0100, Bruno Afonso wrote:
> Hey Max,
> > Well ... what do you mean by "due to dnscache"? Any traces, dumps or
> > anything that might help to really debug?
> I couldn't think right since my "boss" was yelling at me. Here's the
> only thing I have:
> db> show map
> Task map 0xc01c3745: pmap=0x82444c7, nentries=-1324417024, version=203703495
> map entry 0xc0850000: start=0, end=0
> prot=0/0/share, object=0, offset=0x0
> Fatal trap 12: page fault while in kernel mode
> fault virtual address = 0x14
> fault code = supervisor read, page not present
> instruction pointer = 0x8:0xc031d976
> stack pointer = 0x10:0xdfbaaa44
> frame pointer = 0x10:0xdfbaaa64
> code segment = base 0x0, limit 0xfffff, type 0x1b
> = DPL 0, pres 1, def32 1, gran 1
> processor eflags = resume, IOPL = 0
> current process = 591 (dnscache)
> kernel: type 12 trap, code=0
> Stopped at _fget+0x15: movl $0,0(%edx)
It seems the fault was caused by dnscache application.
May be NULL pointer reference in kernel space.
You can see the offending function _fget() in /sys/kern/kern_descrip.c.
I believe this error is not related with FreeBSD pf.
However, you don't have traces so I can't sure that.
> Stupid me forgot to do a trace....
> > 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.
> We're at about 10% max...
> > 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"
> I'm dumping now every 10min vmstat -z |grep ^pf into a file.
> > 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.
> I had only .sh start script. the others were .sh~ and .sh.d, which
> shouldn't run at all. Anyway, I've removed them.
> No pf modules in local/modules :>
> The box boots ok, as I have just rebooted it. It started fine, pf et al.
Did you have two kernel modules in your system?(/boot/kernel and
/usr/local/modules) Did you patch your kernel after installing
FreeBSD pf? Can you tell me the exact procure you used while loading
and unloading pf? Can you post your rule file and comment on your
network setup? Did your rule file have table rules?
> > 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.
> I know. I posted hoping for some feedback... apparently, it's not pf
> related as no one else seems to be having problems. I had to disable now
No. It does not necessarily mean FreeBSD pf is error free. There
might be bugs creeping through pf module.
> the break into ddb as I can't afford the box down for a couple hours :-(
> Unfortunately, someone pressed the restart button before I could get to
> ddb via serial console...
You dont't have to let the box down for a while. At least, we need a
trace report to identify the problem. At DDB propmt you can invoke
'trace' command and write down the output. If you have enabled kernel
debugging options, you may get valuable crash dump file. This is the
most perferrable one.
> Bruno, hoping in case any other panic occurs, the machine can restart
> doing its business... :>
Pyun YongHyeon <http://www.kr.freebsd.org/~yongari>
KTIS, Inc. +82-2-597-0600
More information about the freebsd-pf