Date: Thu, 16 Sep 2004 03:53:32 -0000 From: Bruno Afonso <brunomiguel@dequim.ist.utl.pt> To: pf4freebsd@freelists.org Subject: [pf4freebsd] Re: pf errors meaning Message-ID: <3F7CB204.9030506@dequim.ist.utl.pt> In-Reply-To: <19920876018.20031002175427@love2party.net> References: <1065107810.3f7c4162b252a@mrna.ist.utl.pt> <19920876018.20031002175427@love2party.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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=20
only thing I have:
db> show map
Task map 0xc01c3745: pmap=3D0x82444c7, nentries=3D-1324417024, version=3D=
203703495
map entry 0xc0850000: start=3D0, end=3D0
prot=3D0/0/share, object=3D0, offset=3D0x0
Fatal trap 12: page fault while in kernel mode
fault virtual address =3D 0x14
fault code =3D supervisor read, page not present
instruction pointer =3D 0x8:0xc031d976
stack pointer =3D 0x10:0xdfbaaa44
frame pointer =3D 0x10:0xdfbaaa64
code segment =3D base 0x0, limit 0xfffff, type 0x1b
=3D DPL 0, pres 1, def32 1, gran 1
processor eflags =3D resume, IOPL =3D 0
current process =3D 591 (dnscache)
kernel: type 12 trap, code=3D0
Stopped at _fget+0x15: movl $0,0(%edx)
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 ? :>
>=20
> 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?
>=20
> 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. Pleas=
e
> 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=20
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.
> 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=20
related as no one else seems to be having problems. I had to disable now=20
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...
Bruno, hoping in case any other panic occurs, the machine can restart=20
doing its business... :>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3F7CB204.9030506>