From owner-freebsd-current@FreeBSD.ORG Fri May 23 07:38:26 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9BB6E37B401; Fri, 23 May 2003 07:38:26 -0700 (PDT) Received: from white.imgsrc.co.jp (ns.imgsrc.co.jp [210.226.20.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id ADD1143F93; Fri, 23 May 2003 07:38:25 -0700 (PDT) (envelope-from kuriyama@imgsrc.co.jp) Received: from localhost (localhost [127.0.0.1]) by white.imgsrc.co.jp (Postfix) with ESMTP id 0F0CC24EC3; Fri, 23 May 2003 23:38:25 +0900 (JST) Received: from black.imgsrc.co.jp (black.imgsrc.co.jp [2001:218:422:2::130]) by white.imgsrc.co.jp (Postfix) with ESMTP id 9198224EC2; Fri, 23 May 2003 23:38:22 +0900 (JST) Received: from black.imgsrc.co.jp (black.imgsrc.co.jp [2001:218:422:2::130]) by black.imgsrc.co.jp (Postfix) with ESMTP id 49AFC1E4620; Fri, 23 May 2003 23:38:22 +0900 (JST) Date: Fri, 23 May 2003 23:38:22 +0900 Message-ID: <7mfzn5k9sx.wl@black.imgsrc.co.jp> From: Jun Kuriyama To: Current In-Reply-To: References: <7mllwzlu0u.wl@black.imgsrc.co.jp> User-Agent: Wanderlust/2.10.0 (Venus) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.4 Emacs/21.2 (i386--freebsd) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: by AMaViS snapshot-20020531 cc: sos@FreeBSD.org Subject: Re: Panic in _mtx_lock_flags+0x40 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2003 14:38:26 -0000 At Thu, 22 May 2003 16:35:33 +0000 (UTC), John Baldwin wrote: > > db> trace > > _mtx_lock_flags(0,0,c0401b81,11d,e11edb18) at _mtx_lock_flags+0x40 >=20 > Trying to lock a NULL pointer is definitely going to panic, yes. > I'm curious what vm_fault() line you are at. >=20 > > vm_fault(c082f000,deadc000,1,0,c3affab0) at vm_fault+0x2cc > > trap_pfault(e11edc10,0,deadc0de,cf74d400,deadc0de) at trap_pfault+0x161 > > trap(c0410018,10,c03e0010,c7a73c9c,c7e8f600) at trap+0x3ad > > calltrap() at calltrap+0x5 > > --- trap 0xc, eip =3D 0xc015c580, esp =3D 0xe11edc50, ebp =3D 0xe11edc6= 8 --- > > ad_detach(c7a73c9c,ffffffff,c03d5de3,0,1) at ad_detach+0x40 >=20 > The real bug is probably here, probably a NULL pointer dereference. > I would use gdb to figure out what this file:line is and send the > report to S=F8ren. >=20 > > ata_reinit(c7a73c00,cacf5100,c03d1747,0,0) at ata_reinit+0x9b > > ad_timeout(cacf5100,0,c03ec2fe,bf,4feaef) at ad_timeout+0x136 > > softclock(0,0,c03e9271,233,c3afe780) at softclock+0x19c > > ithread_loop(c3afd200,e11edd48,c03e9122,2f8,0) at ithread_loop+0x182 > > fork_exit(c021bab0,c3afd200,e11edd48) at fork_exit+0xc0 > > fork_trampoline() at fork_trampoline+0x1a > > --- trap 0x1, eip =3D 0, esp =3D 0xe11edd7c, ebp =3D 0 --- Is this help you? (kgdb) l *ad_detach+0x40 0xc015c580 is in ad_detach (../../../dev/ata/ata-disk.c:218). 213 =20 214 atadev->flags |=3D ATA_D_DETACHING; 215 ata_prtdev(atadev, "removed from configuration\n"); 216 ad_invalidatequeue(adp, NULL); 217 TAILQ_FOREACH(request, &atadev->channel->ata_queue, chain) { 218 if (request->softc !=3D adp) 219 continue; 220 TAILQ_REMOVE(&atadev->channel->ata_queue, request, chain); 221 biofinish(request->bp, NULL, ENXIO); 222 ad_free(request); --=20 Jun Kuriyama // IMG SRC, Inc. // FreeBSD Project