kdb
[Top] [All Lists]

Re: having trouble with kdb on smp (kernel 2.5.9)

To: Keith Owens <kaos@xxxxxxx>
Subject: Re: having trouble with kdb on smp (kernel 2.5.9)
From: Matthew C Dobson <colpatch@xxxxxxxxxx>
Date: Mon, 20 May 2002 11:17:51 -0700
Cc: gone@xxxxxxxxxx, kdb@xxxxxxxxxxx
References: <2934.1021865004@xxxxxxxxxxxxxxxxxxxxxx>
Sender: owner-kdb@xxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020408
Keith Owens wrote:

On Fri, 17 May 2002 15:01:07 -0700, Matthew Dobson <colpatch@xxxxxxxxxx> wrote:

Keith Owens wrote:

On Wed, 15 May 2002 18:03:29 -0700,
Patricia Gaughen <gone@xxxxxxxxxx> wrote:

2.5.9 on an 8 proc numaq box.  I saw the recent patch from Ethan Solomita and
I'll give it a try tonight or tomorrow.  But we've ran into a couple of issues:

     - when the system hangs we enter kdb but using bt, bta and btp do not 
produce
stacks for any of the processes.  We're able to get the stacks manually, but
this is not much fun :-)

Which version of gcc?  Newer versions of gcc produce stack frame code
that kdb cannot backtrace without CONFIG_FRAME_POINTER=y.

I'm currently using gcc version 3.0.2.  And I definitely do have
CONFIG_FRAME_POINTER turned on.


Any error messages?  I am guessing that it says "Stack is not in
task_struct, backtrace not available".  task_struct data has been moved
around in recent 2.5 kernels and kdb has not been changed to validate
the new layout yet.

Yep... That the error message that I get... The latest kdb on the oss.sgi site is based on 2.5.7 which has the new task_struct changes, so I figured it would know how to find the stack... Like I said, we've been able to do it manually, by locating the thread_info in task_struct, and then manually dumping the 2 pages of memory sitting there... The back-trace functionality would be nice, but isn't strictly necessary... What would be really helpful is if I could look at what other cpus are doing...

Thanks!

-Matt


<Prev in Thread] Current Thread [Next in Thread>