Re: kbacktrace, 2. Versuch

From: Andi Kleen (ak@muc.de)
Date: Mon Jan 10 2000 - 12:47:21 EST


Hallo Manfred,

On Mon, Jan 10, 2000 at 04:25:29PM +0100, Manfred Spraul wrote:
> What about the following idea [only possible on 2.3]:
>
> * The TSS address is always fixed, ie we can access the TSS of the
> secondary CPU's and find the kernel stack pages.
> * We dump the _complete_ backtrace [ie all function pointers in the 7 kB
> stack area of the current thread].
>
> This means:
> * we always get the complete back trace
> * it will be more difficult to read the back trace, but it should be
> possible.
> * We'll _always_ get the back trace, the only exception is during stack
> switching. But AFAICS, this code cannot block.
>
> What do you think?

I have my doubts that a backtrace is that useful without a register dump.
I see no way to get at the registers without the IPI. You would
have no idea which datastructure was corrupted, if you don't see the
EIP and the register values.

It would be nice as a fallback though (spin for two jiffies waiting
for IPI results, if they are not there dump the TSS)

The current smp_call_function path has far too much cruft though, I agree,
it would be better to have a special vector reserved for this
purposee that works with as little infrastructure as possible (kdb does
it this way). A debug vector that could be shared by kdb would be good.

-Andi

P.S.: Alan seems to agree to put some stripped down version of
kbacktrace/your patch into 2.2.15 for bh hangs debugging.

-- 
This is like TV. I don't like TV.

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Sat Jan 15 2000 - 21:00:16 EST