Keith Owens wrote: >On Fri, 17 May 2002 15:01:07 -0700, >Matthew Dobson <[EMAIL PROTECTED]> wrote: > >>Keith Owens wrote: >> >>>On Wed, 15 May 2002 18:03:29 -0700, >>>Patricia Gaughen <[EMAIL PROTECTED]> 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
