Date: Fri, 22 Jun 2007 21:42:18 -0700 From: "Kip Macy" <kip.macy@gmail.com> To: "Kevin Gerry" <sfpoof@gmail.com> Cc: Attilio Rao <attilio@freebsd.org>, Jeff Roberson <jroberson@chesapeake.net>, freebsd-current@freebsd.org Subject: Re: Kernel Panic in latest -CURRENT Message-ID: <b1fa29170706222142s52c4f639p9577c21c36be9457@mail.gmail.com> In-Reply-To: <c027a39a0706222133i6e4a23bek3e905a6f9c42c8b3@mail.gmail.com> References: <c027a39a0706201141v4eba45a4vb815f130264b9e28@mail.gmail.com> <467A3869.3020706@FreeBSD.org> <20070622121008.T542@10.0.0.1> <c027a39a0706222057g508a3170naf3b9ce3148e8d62@mail.gmail.com> <b1fa29170706222107y28b53638ndd437aa8a9b2cbfe@mail.gmail.com> <c027a39a0706222133i6e4a23bek3e905a6f9c42c8b3@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Somehow debug.mpsafenet is getting set to 0, the default is 1. Do you
have NET_WITH_GIANT in your config?
Can you try adding
debug.mpsafenet=3D"1"
to your loader.conf?
-Kip
On 6/22/07, Kevin Gerry <sfpoof@gmail.com> wrote:
> I don't. My loader.conf consists of:
>
> [root@storage ~]# cat /boot/loader.conf
> autoboot_delay=3D"3"
> [root@storage ~]#
>
> and sysctl.conf-
> net.inet6.ip6.accept_rtadv=3D0
> net.inet6.ip6.forwarding=3D1
> net.inet.tcp.blackhole=3D2
> net.inet.udp.blackhole=3D1
> net.inet.tcp.msl=3D7500
> net.inet.ip.rtminexpire=3D2
> -
>
>
> On 6/22/07, Kip Macy < kip.macy@gmail.com> wrote:
> > Don't set debug.mpsafenet=3D"0" in loader.conf .
> >
> >
> > -Kip
> >
> > On 6/22/07, Kevin Gerry <sfpoof@gmail.com> wrote:
> > > Go figure... If it compile with INVARIANTS and INVARIANT_SUPPORT, I g=
et
> 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:409
> > > #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=3D0xc08=
ba898
> > > "/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=3D0xc3=
bb84ac
> "",
> > > da=3D0xc087eba0 "=FF=FF=FF=FF=FF=FFether_ifattach",
> > > bssid=3D0xc087eba0 "=FF=FF=FF=FF=FF=FFether_ifattach", ssid=3D0xc=
08a4613 "",
> 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 <ithread_loop>,
> > > 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 <jroberson@chesapeake.net> wrote:
> > > >
> > > > Kevin,
> > > >
> > > > Can you please compile a kernel with INVARIANTS and INVARIANT_SUPPO=
RT
> > > > 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:139
> > > > >> #6 0xc063b008 in propagate_priority (td=3D0xc3ab5e00) at
> > > > >> /usr/src/sys/kern/subr_turnstile.c:272
> > > > >> #7 0xc063b989 in turnstile_wait (ts=3D0xc3a9e6e0, owner=3D0xc3a=
b5e00,
> > > > >> queue=3DVariable "queue" is not available.
> > > > >> ) at /usr/src/sys/kern/subr_turnstile.c:739
> > > > >> #8 0xc060140d in _mtx_lock_sleep (m=3D0xc0993228, tid=3D3284357=
632,
> > > > 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) at
> > > > >> /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
> > > > <taskqueue_thread_loop>,
> > > > >> 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 loc=
k
> > > > above. */
> > > > >> 277 }
> > > > >
> > > > > Jeff can better comment on it, but for what I can see it seems th=
at
> > > > > 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
> > > > >
> > > >
> > > _______________________________________________
> > > freebsd-current@freebsd.org mailing list
> > >
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> > > To unsubscribe, send any mail to
> "freebsd-current-unsubscribe@freebsd.org"
> > >
> >
>
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?b1fa29170706222142s52c4f639p9577c21c36be9457>