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
