On Wed, 8 Aug 2001 14:17:01 -0400,
Kapish K <[EMAIL PROTECTED]> wrote:
> Thanks for the info. I was able to get the KDBDEBUG set on and
>capture the output. The output on processor 0 is able to resolve
>the symbols. The one on processor 1 is not. The gcc and modutils
>are from Red Hat 7.1 distribution. The kdb output is attached.
bt
EBP EIP Function(args)
kdb_get_next_ar: arend=0xf2cfbc57 func=0x0 pc=0x9c3f1cf8 fp=0xb735e8f2
kdb_get_next_ar: callee not in kernel
kdba_prologue: code=0x0 <unknown> pc=0x0 sp=0xf2cfbc57 fp=0xb735e8f2
pc==0: ret=0xcfbc68f8
kdb_get_next_ar: callee activation record
start=0xf2cfbc5b end=0xf2cfbc57 ret=0xcfbc68f8 oldfp=0x0 fp=0x0
locals=0 regs=0 setup=4
This data is complete garbage. The program count is 0x9c3f1cf8 which
is outside the kernel and modules. Normally that would indicate your
code has taken a branch via an undefined function pointer. However the
stack pointer has values like 0xf2cfbc57 which is flatly impossible.
All kernel stack addresses are 4 byte aligned, that sp value cannot
occur in a valid kernel. It looks like something has corrupted the
registers.
The registers are saved in the process structure, the process stack is
at the top of the process structure and fills downwards. Is there any
chance that your code has gone recursive or allocated a large structure
on stack and overwritten the start of the process structure? Remember
that ix86 kernel stacks are limited to about 6Kb.
The only useful field in that trace is ret=0xcfbc68f8, everything else
looks corrupt. Check where 0xcfbc68f8 is, it might help track down
what is corrupting the registers.
