Re: how to find out what the other CPU is doing

On Sunday 28 January 2007 07:38, Randall Stewart wrote:
> All:
> 
> Ok, I did not get an answer to this.. and of course
> I hit the bug again (which I now figured out how to
> fix :-D)
> 
> So let me explain what I did.. so that way I
> can come back and find this email later when it
> someday happens again ;-) (and for anyone else
> curious).
> 
> 1) I had to do this from DDB ... I could not find a
>     way in kgdb.
> 
> 2) When you stop the machine in ddb (at least in i386) it
>     dumps BOTH CPU's info in something called
>     stoppcbs[num-cpus]
> 3) Its an array of  struct pcb .. which has all the info
>     you need to get started.
> 4) With a trusty x/ stoppcbs you can work your way through
>     and gather the info you need.. For x86 the second CPU
>     started at stoppcbs+0x270 .. if you don't want to look
>     at all those 0's (of course the offset could change and
>     will vary from CPU type to CPU type :-D)
> 5) Dig out the ebp from here. You can look at the IP
>     but it will be in some NMI stop CPU routine.
> 6) You can use the bp to trace backward through the stack
>     and figure out the running stack trace... I went back
>     to kgdb after getting the ebp (with CPU still spinning away).
> 7) You have to go several frames back to get by all the NMI
>     stuff before you find your guilty party :-)
> 
> There might be a better way to do this.. and I am thinking
> about adding a machine dependent trace that can take
> a ebp argument (if one does not already exist in kgdb.. I
> suppose I need to poke around in the macro's a bit).. anyway
> its primitive .. but it allows you to find that spinning
> kernel routine :-)

When you use 'thread/tid/proc' in kgdb it uses stoppcbs[] automatically, so 
you can do 'proc 437' and do 'bt' to get a trace as I explained earlier.  ddb 
can also do this for you as 'tr' in ddb can take a pid or tid as an argument, 
so in ddb you can do 'tr 437' to trace proc 437.  Note if you want to use 
the 'tid' in kgdb you use 'tid <tid>'.  'proc' takes PIDs not TIDs in kgdb.

-- 
John Baldwin