Kernel Panic in latest -CURRENT

Kevin Gerry sfpoof at gmail.com
Sat Jun 23 05:04:52 UTC 2007


No, I don't have NET_WITH_GIANT in the config, However, I'll try adding that
in loader.conf and restart in a second. (That is, after I recompile the
kernel again to make sure the errors weren't some fluke)

On 6/22/07, Kip Macy <kip.macy at gmail.com> wrote:
>
> 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="1"
>
> to your loader.conf?
>
> -Kip
>
>
>
> On 6/22/07, Kevin Gerry <sfpoof at gmail.com> wrote:
> > I don't. My loader.conf consists of:
> >
> > [root at storage ~]# cat /boot/loader.conf
> > autoboot_delay="3"
> > [root at storage ~]#
> >
> > and sysctl.conf-
> > net.inet6.ip6.accept_rtadv=0
> > net.inet6.ip6.forwarding=1
> > net.inet.tcp.blackhole=2
> > net.inet.udp.blackhole=1
> > net.inet.tcp.msl=7500
> > net.inet.ip.rtminexpire=2
> > -
> >
> >
> > On 6/22/07, Kip Macy < kip.macy at gmail.com> wrote:
> > > Don't set debug.mpsafenet="0" in loader.conf .
> > >
> > >
> > > -Kip
> > >
> > > On 6/22/07, Kevin Gerry <sfpoof at gmail.com> wrote:
> > > > 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=260) at
> > /usr/src/sys/kern/kern_shutdown.c:409
> > > > #2  0xc0606d3f in panic (fmt=Variable "fmt" is not available.
> > > > ) at /usr/src/sys/kern/kern_shutdown.c:563
> > > > #3  0xc05fb61d in _mtx_assert (m=0xc098e9a8, what=1, file=0xc08ba898
> > > > "/usr/src/sys/net/if.c", line=2697)
> > > >     at /usr/src/sys/kern/kern_mutex.c:618
> > > > #4  0xc068f437 in if_start (ifp=0xc3bb3c00) at
> > /usr/src/sys/net/if.c:2697
> > > > #5  0xc06c5974 in ieee80211_send_probereq (ni=0xc3bd4000,
> sa=0xc3bb84ac
> > "",
> > > > da=0xc087eba0 "ÿÿÿÿÿÿether_ifattach",
> > > >     bssid=0xc087eba0 "ÿÿÿÿÿÿether_ifattach", ssid=0xc08a4613 "",
> > ssidlen=0,
> > > > optie=0x0, optielen=0)
> > > >     at /usr/src/sys/net80211/ieee80211_output.c:1539
> > > > #6  0xc06cc2ea in scan_curchan (ic=0xc3bb822c, maxdwell=200) at
> > > > /usr/src/sys/net80211/ieee80211_scan.c:651
> > > > #7  0xc06cb489 in scan_next (arg=0xc3b67000) at
> > > > /usr/src/sys/net80211/ieee80211_scan.c:740
> > > > #8  0xc0617cd9 in softclock (dummy=0x0) at
> > > > /usr/src/sys/kern/kern_timeout.c:280
> > > > #9  0xc05ecca5 in ithread_loop (arg=0xc3ab3050) at
> > > > /usr/src/sys/kern/kern_intr.c:1036
> > > > #10 0xc05ea558 in fork_exit (callout=0xc05ecaf0 <ithread_loop>,
> > > > arg=0xc3ab3050, frame=0xe25d8d38)
> > > >     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 at chesapeake.net> 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=260) at
> > > > > /usr/src/sys/kern/kern_shutdown.c:409
> > > > > >> #2  0xc060cd6f in panic (fmt=Variable "fmt" is not available.
> > > > > >> ) at /usr/src/sys/kern/kern_shutdown.c:563
> > > > > >> #3  0xc086954c in trap_fatal (frame=0xe40d3b9c, eva=20) at
> > > > > >> /usr/src/sys/i386/i386/trap.c:870
> > > > > >> #4  0xc0869e8c in trap (frame=0xe40d3b9c) 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=0xc3ab5e00) at
> > > > > >> /usr/src/sys/kern/subr_turnstile.c:272
> > > > > >> #7  0xc063b989 in turnstile_wait (ts=0xc3a9e6e0,
> owner=0xc3ab5e00,
> > > > > >> queue=Variable "queue" is not available.
> > > > > >> ) at /usr/src/sys/kern/subr_turnstile.c:739
> > > > > >> #8  0xc060140d in _mtx_lock_sleep (m=0xc0993228,
> tid=3284357632,
> > > > > opts=0,
> > > > > >> file=0x0, line=0) at
> > /usr/src/sys/kern/kern_mutex.c:395
> > > > > >> #9  0xc04decd7 in em_handle_rxtx (context=0xc3b63000,
> pending=1) at
> > > > > >> /usr/src/sys/dev/em/if_em.c:1477
> > > > > >> #10 0xc0639e72 in taskqueue_run (queue=0xc3be1880) at
> > > > > >> /usr/src/sys/kern/subr_taskqueue.c:255
> > > > > >> #11 0xc063a04f in taskqueue_thread_loop (arg=0xc3b632ec) at
> > > > > >> /usr/src/sys/kern/subr_taskqueue.c:374
> > > > > >> #12 0xc05ee896 in fork_exit (callout=0xc0639fd0
> > > > > <taskqueue_thread_loop>,
> > > > > >> arg=0xc3b632ec, frame=0xe40d3d38)
> > > > > >>    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 = td->td_blocked;
> > > > > >> 269                     MPASS(ts != NULL);
> > > > > >> 270                     MPASS(td->td_lock == &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
> > > > > >
> > > > >
> > > > _______________________________________________
> > > > freebsd-current at freebsd.org mailing list
> > > >
> > http://lists.freebsd.org/mailman/listinfo/freebsd-current
> > > > To unsubscribe, send any mail to
> > "freebsd-current-unsubscribe at freebsd.org"
> > > >
> > >
> >
> >
>


More information about the freebsd-current mailing list