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.
bcopy (and all other functions written in assembler) doesn't set up the
frame pointer, so stack traces in it don't work right. Usually, the
previous function's args are shown as bcopy's args and the previous
function's name isn't shown. They are easy to see by examining the
stack (x/x $esp,10).
The kernel has "options DDB", no compiler optimization,
Not even the default -O?
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
memcmp is a C library function that isn't available in the kernel.
What makes me wonder is the fact that DDB tells me: bcopy has 4 (four)
args! first being 0x80smth, another three -- some addresses. Gmm...
DDB often can't figure out how many args there are. Then it guesses that
the args are 5 32-bit numbers.