so, even after a total replacement of underlying hardware (only hard
disk is the same), and upgrade to ipfilter 3.0.4,
I'm still having problems on our FreeBSD
firewall gateway. As soon as I discovered that disaster is here,
I made a kernel with debugging symbols and DDB in it,
rebooted and waited.
Caught it. Omitting the exact details (hex symbol tables, etc.,
anyway, this kernel is here, still panicing from time
to time, esp. under network load on SLIP interfaces;
I'll send the details as soon as you'll ask) of several panics,
DDB's "trace" command constantly shows that kernel page fault occurs
in bcopy(), called from near line 616 of fil.c -- the function is
fr_check(). That's near the call to a logging routine,
but I couldn't find any bcopy() call in nearest few lines.
IPFILTER_LOG is defined. Filter is compiled into the kernel.
My attempts to use gdb -k on the dumped corefiles failed:
$ gdb -k
"symbol-file ddbkernel" -- Ok
"exec-file kernel.0" -- Ok
"core-file vmcore.0" -- gdb fails to extract some nessesary
info(?) and doesn't show anything :(
I'm not too familiar with gdb :(
The kernel has "options DDB", no compiler optimization,
config(8) had '-g' switch (note: linkage of the kernel failed with this
switch combo; ld didn't find _memcmp symbol, why? I added libc.a to the
list of libraries, after libkernel.a;
linkage succeeded, "debug" kernel works as
planned ;) this means it's Ok until a panic :)) Kernel sources are
-stable as of March 20 (still). (How can I sup somethin new and big if my
router falls down?! Even my mail goes through it, anyway).
What makes me wonder is the fact that DDB tells me: bcopy has 4 (four)
args! first being 0x80smth, another three -- some addresses. Gmm...
Any help/comments/suggestions are strongly appreciated.
P.S. If the damn thing will panic again soon, I'll write down
the exact DDB output and an appropriate
fragment of `nm ddbkernel` and send it to you. Please take
my apologies if the message will be a bit longish. ;)