In fbsd-current John Baldwin writes:
>On 09-Jun-01 Richard Todd wrote:
>> Note that the first panic is somewhat muddled by the fact that, while 
>> syncing disks from the vm_object.c panic, it apparently paniced again with
>> "Giant locked" at i386/trap.c:1153.  That probably confuses the issue 
>> greatly.

>Yes, I need the first traceback, not the second.  One question: are you using
>ktrace?  ddb is your friend here, as it can do a traceback when you have the
>first panic.

Yeah, I am using ktrace, and now that I think of it, yeah, a ktraced process
was probably running when those panics occured.  Unfortunately, ddb is
not my friend, as I'm usually running X.  :-(  

>> P.S. Stupid -current question: How does one tell what process was running
>> that triggered a panic?  This used to be findable with "p *curproc" in
>> gdb, but that doesn't seem to work anymore.

>You have to look at the list of per-cpu data (look at the gd_allcpu list).  In
>ddb you can use 'show pcpu' to look at per-cpu data.  At some point, gdb needs
>to be taught the notion of a 'current CPU' and be taught a way to access
>per-cpu data of the current CPU.

Ah. Okay.  

>>#10 0xc042c603 in ast (framep=0xc8ce0fa8) at ../../i386/i386/trap.c:1320
>>#11 0xc0417b00 in doreti_ast ()

>Ok, this one is the ktrace bogon that was recently brought to my attention.

Cool.  Thanks. 

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to