From owner-freebsd-current@FreeBSD.ORG Sat Jun 23 03:57:16 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 899BD16A468 for ; Sat, 23 Jun 2007 03:57:16 +0000 (UTC) (envelope-from sfpoof@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.234]) by mx1.freebsd.org (Postfix) with ESMTP id 3444F13C448 for ; Sat, 23 Jun 2007 03:57:16 +0000 (UTC) (envelope-from sfpoof@gmail.com) Received: by wx-out-0506.google.com with SMTP id h28so905103wxd for ; Fri, 22 Jun 2007 20:57:15 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=Yn9tQOn6fNdP8Eyl/mEFI7bokSIkcOqwby3AwDCZ43p9DU6gXXRVgc1tmimDZEKk+t4nHYQ9BadVJKJAU8XmpHQo3f47zMDh10MkmM7zx42WI3Qpqjxvng3F7A2k0Pk86r/Dx9tE0Xut9ksAm5uDWVEOeWUdorES8L7MiXtJ0Lo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=JsksijXI2qh3odvSq81yts9HpvePs54cyUevJaT6antOyv3W8c6ArtxtlZgGJh4ehb2+uLZfV36hljzfrEhWPIWzzFr72Q7o82LUov8Xp+x4O+YyJEAEhBSk0F8P2FxaErUECl+axTsuv3dHzkfA9t5Kvf0nH7cDGqAEBYQit5U= Received: by 10.90.118.8 with SMTP id q8mr3212825agc.1182571035282; Fri, 22 Jun 2007 20:57:15 -0700 (PDT) Received: by 10.90.70.9 with HTTP; Fri, 22 Jun 2007 20:57:15 -0700 (PDT) Message-ID: Date: Fri, 22 Jun 2007 20:57:15 -0700 From: "Kevin Gerry" To: "Jeff Roberson" In-Reply-To: <20070622121008.T542@10.0.0.1> MIME-Version: 1.0 References: <467A3869.3020706@FreeBSD.org> <20070622121008.T542@10.0.0.1> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Attilio Rao , freebsd-current@freebsd.org Subject: Re: Kernel Panic in latest -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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: Sat, 23 Jun 2007 03:57:16 -0000 Go figure... If it compile with INVARIANTS and INVARIANT_SUPPORT, I get a core on boot with: panic: mutex Giant not owned at /usr/src/sys/net/if.c:2697 Uptime: 5s Physical memory: 1015 MB Dumping 41 MB: 26 10 #0 doadump () at pcpu.h:195 195 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:195 #1 0xc0606aff in boot (howto=3D260) at /usr/src/sys/kern/kern_shutdown.c:4= 09 #2 0xc0606d3f in panic (fmt=3DVariable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:563 #3 0xc05fb61d in _mtx_assert (m=3D0xc098e9a8, what=3D1, file=3D0xc08ba898 "/usr/src/sys/net/if.c", line=3D2697) at /usr/src/sys/kern/kern_mutex.c:618 #4 0xc068f437 in if_start (ifp=3D0xc3bb3c00) at /usr/src/sys/net/if.c:2697 #5 0xc06c5974 in ieee80211_send_probereq (ni=3D0xc3bd4000, sa=3D0xc3bb84ac= "", da=3D0xc087eba0 "=FF=FF=FF=FF=FF=FFether_ifattach", bssid=3D0xc087eba0 "=FF=FF=FF=FF=FF=FFether_ifattach", ssid=3D0xc08a461= 3 "", ssidlen=3D0, optie=3D0x0, optielen=3D0) at /usr/src/sys/net80211/ieee80211_output.c:1539 #6 0xc06cc2ea in scan_curchan (ic=3D0xc3bb822c, maxdwell=3D200) at /usr/src/sys/net80211/ieee80211_scan.c:651 #7 0xc06cb489 in scan_next (arg=3D0xc3b67000) at /usr/src/sys/net80211/ieee80211_scan.c:740 #8 0xc0617cd9 in softclock (dummy=3D0x0) at /usr/src/sys/kern/kern_timeout.c:280 #9 0xc05ecca5 in ithread_loop (arg=3D0xc3ab3050) at /usr/src/sys/kern/kern_intr.c:1036 #10 0xc05ea558 in fork_exit (callout=3D0xc05ecaf0 , arg=3D0xc3ab3050, frame=3D0xe25d8d38) at /usr/src/sys/kern/kern_fork.c:797 #11 0xc083e5f0 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:205 The same kernel without -g and inv/inv_sup boots fine. Any idea here? On 6/22/07, Jeff Roberson wrote: > > Kevin, > > Can you please compile a kernel with INVARIANTS and INVARIANT_SUPPORT > enabled? That would help us greatly with this problem. > > Thanks, > Jeff > > On Thu, 21 Jun 2007, Attilio Rao wrote: > > > Kevin Gerry wrote: > >> #0 doadump () at pcpu.h:195 > >> 195 pcpu.h: No such file or directory. > >> in pcpu.h > >> (kgdb) bt > >> #0 doadump () at pcpu.h:195 > >> #1 0xc060cb73 in boot (howto=3D260) at > /usr/src/sys/kern/kern_shutdown.c:409 > >> #2 0xc060cd6f in panic (fmt=3DVariable "fmt" is not available. > >> ) at /usr/src/sys/kern/kern_shutdown.c:563 > >> #3 0xc086954c in trap_fatal (frame=3D0xe40d3b9c, eva=3D20) at > >> /usr/src/sys/i386/i386/trap.c:870 > >> #4 0xc0869e8c in trap (frame=3D0xe40d3b9c) at > >> /usr/src/sys/i386/i386/trap.c:276 > >> #5 0xc0853afb in calltrap () at /usr/src/sys/i386/i386/exception.s:13= 9 > >> #6 0xc063b008 in propagate_priority (td=3D0xc3ab5e00) at > >> /usr/src/sys/kern/subr_turnstile.c:272 > >> #7 0xc063b989 in turnstile_wait (ts=3D0xc3a9e6e0, owner=3D0xc3ab5e00, > >> queue=3DVariable "queue" is not available. > >> ) at /usr/src/sys/kern/subr_turnstile.c:739 > >> #8 0xc060140d in _mtx_lock_sleep (m=3D0xc0993228, tid=3D3284357632, > opts=3D0, > >> file=3D0x0, line=3D0) at /usr/src/sys/kern/kern_mutex.c:395 > >> #9 0xc04decd7 in em_handle_rxtx (context=3D0xc3b63000, pending=3D1) a= t > >> /usr/src/sys/dev/em/if_em.c:1477 > >> #10 0xc0639e72 in taskqueue_run (queue=3D0xc3be1880) at > >> /usr/src/sys/kern/subr_taskqueue.c:255 > >> #11 0xc063a04f in taskqueue_thread_loop (arg=3D0xc3b632ec) at > >> /usr/src/sys/kern/subr_taskqueue.c:374 > >> #12 0xc05ee896 in fork_exit (callout=3D0xc0639fd0 > , > >> arg=3D0xc3b632ec, frame=3D0xe40d3d38) > >> at /usr/src/sys/kern/kern_fork.c:797 > >> #13 0xc0853b70 in fork_trampoline () at > >> /usr/src/sys/i386/i386/exception.s:205 > >> (kgdb) list *0xc063b008 > >> 0xc063b008 is in propagate_priority > >> (/usr/src/sys/kern/subr_turnstile.c:273). > >> 268 ts =3D td->td_blocked; > >> 269 MPASS(ts !=3D NULL); > >> 270 MPASS(td->td_lock =3D=3D &ts->ts_lock); > >> 271 /* Resort td on the list if needed. */ > >> 272 if (!turnstile_adjust_thread(ts, td)) { > >> 273 mtx_unlock_spin(&ts->ts_lock); > >> 274 return; > >> 275 } > >> 276 /* The thread lock is released as ts lock > above. */ > >> 277 } > > > > Jeff can better comment on it, but for what I can see it seems that > > ts->ts_lock is not acquired again once the new assignment from > td->td_blocked > > is done and I think it should be. > > > > Thanks a lot for your report, > > Attilio > > >