From owner-freebsd-current Tue Jun 12 17:26:25 2001 Delivered-To: freebsd-current@freebsd.org Received: from kyle.tandemedia.com (kyle.tandemedia.com [216.29.169.3]) by hub.freebsd.org (Postfix) with ESMTP id 381B437B401; Tue, 12 Jun 2001 17:26:22 -0700 (PDT) (envelope-from rmtodd@servalan.servalan.com) Received: by kyle.tandemedia.com (Postfix, from userid 66) id D291B55402; Tue, 12 Jun 2001 20:26:20 -0400 (EDT) Received: from localhost (1708 bytes) by servalan.servalan.com via sendmail with P:stdio/R:smart_host/T:hacked-uux (sender: ) (ident using unix) id for ; Tue, 12 Jun 2001 19:05:30 -0500 (CDT) (Smail-3.2.0.111 2000-Feb-17 #1 built 2001-Jan-15) Message-Id: Date: Tue, 12 Jun 2001 19:05:30 -0500 (CDT) From: rmtodd@servalan.servalan.com (Richard Todd) To: jhb@FreeBSD.ORG, current@freebsd.org Subject: Re: Couple "Giant not locked" at vm_object.c:261 panics I had to Newsgroups: servalan.mailinglist.fbsd-current References: X-Newsreader: NN version 6.5.6 (NOV) Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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 majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message