On Sat, 9 Sep 2000 20:02:56 +0200,
Peter.Kelemen@xxxxxxx wrote:
>All right, while hunting another oops[1], I reproduced the
>vnode-crash situation. Attached is the oops (copied by hand)
>processed by ksymoops. Keith, your tip with "klogd -x" didn't
>help---it simply dies in case of an oops and nothing gets logged.
I sent a patch to the sysklogd maintainer over a year ago, they said
they would include it in the next release, no next release yet.
ftp://ftp.ocs.com.au/pub/ksymoops/v2.3/patch-sysklogd-1-3-31-ksymoops-1.gz
might help.
>Can anyone enlighten me please, what's this f000000 in the call
>trace?
The kernel code that prints the i386 call trace is really simple
minded. Scan up the stack, any word on the stack that looks remotely
like a kernel address is printed. This is anything in the kernel text
area or in the "vmalloc" area, defined on i386 as ending around
0xffffe000. This results in false positives, entries on the "call
trace" that have nothing to do with the call. ksymoops just converts
every address it is given.
This simple minded method of printing the call trace is forced on us by
the lack of a decent stack frame system on i386. If you really want to
shudder, see the kdb code which does the reverse, it has a full unwind
scheme for i386, full of special cases. In particular
arch/i386/kdb/kdbasupport.c, kdba_find_return and kdba_prologue
arch/i386/kdb/kdba_bt.c, kdba_bt_stack
|