Date: Thu, 16 Sep 2004 03:53:48 -0000 From: Bruno Afonso <brunomiguel@dequim.ist.utl.pt> To: pf4freebsd@freelists.org Subject: [pf4freebsd] Re: pf errors meaning Message-ID: <3F803A15.9060405@dequim.ist.utl.pt> In-Reply-To: <20031003075152.GA16760@kt-is.co.kr> References: <1065107810.3f7c4162b252a@mrna.ist.utl.pt> <19920876018.20031002175427@love2party.net> <3F7CB204.9030506@dequim.ist.utl.pt> <20031003075152.GA16760@kt-is.co.kr>
next in thread | previous in thread | raw e-mail | index | archive | help
Pyun YongHyeon wrote: > 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. yes :-( > 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? Only have one model. I used stock kernel from releng_5_1 with only some options added. :-) I'm using a port based rc.d script... I only changed the file paths. I use tables... I have a 10.10.0.0/20 table, and some other tables=20 collecting a lot of /24 and /22 networks. I have also removed one synproxy rule I had for http... Since I had=20 problems with it in the past, I removed it once again. (re-introduced it=20 when installing 1.66) > No. It does not necessarily mean FreeBSD pf is error free. There > might be bugs creeping through pf module. I have had no more panics since I removed the synproxy rule and disabled=20 dnscache. But this is irrelevant as we can't really know what caused the=20 panics. :-( I never heard anyone having dnscache panics, so I found that *odd*. > > 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=20 > > ddb via serial console... > >=20 > 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. I'm not working full time, this is a college and I'm a poor student=20 being explored. :-) I am going to look into crash dumps. take care, BA
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3F803A15.9060405>