Re: Kernel Panic in latest -CURRENT

Alright, I have run it with that in the loader.conf and tried removing
everything from both.

However, I also found while reading the boot mesages, the reason why
mpsafenet is unset is because I have
options IPSEC
options IPSEC_ESP
in the kernel.

So, recompiling with those two options removed.

On 6/22/07, Kevin Gerry <sfpoof@xxxxxxxxx> wrote:

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@xxxxxxxxx> 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@xxxxxxxxx> wrote:
> > I don't. My loader.conf consists of:
> >
> > [root@storage ~]# cat /boot/loader.conf
> > autoboot_delay="3"
> > [root@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@xxxxxxxxx> wrote:
> > > Don't set debug.mpsafenet="0" in loader.conf .
> > >
> > >
> > > -Kip
> > >
> > > On 6/22/07, Kevin Gerry <sfpoof@xxxxxxxxx> 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@xxxxxxxxxxxxxx> 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@xxxxxxxxxxx mailing list
> > > >
> > http://lists.freebsd.org/mailman/listinfo/freebsd-current
> > > > To unsubscribe, send any mail to
> > " freebsd-current-unsubscribe@xxxxxxxxxxx"
> > > >
> > >
> >
> >
>


_______________________________________________
freebsd-current@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: [PATCH] CodingStyle: add typedefs chapter
    ... The reason we have them for things like pte_t etc. is that there ... then by all means go ahead and use a typedef. ... New types which are identical to standard C99 types, ... covers RTL which is used frequently with assembly language in the kernel. ...
    (Linux-Kernel)
  • Re: Forth for Mac OS X Leopard (Intel) - what are the options?
    ... As I understand it even FreeBSD binaries are elf. ... If the .data section works for the kernel part of xina, ... The official way is to use linker scripts. ... For some reason a normal start address in linux32 is around ...
    (comp.lang.forth)
  • Re: SuSE: migrating tot linux software RAID?
    ... > third machine with a megaraid that crashed because of this kernel ... >> The reason that you had data loss at all... ... > I had backups and successfully restored the system after a full install. ...
    (alt.os.linux.suse)
  • Re: eradicating out of tree modules (was: : Linux Security *Module* Framework)
    ... reasons, won't ever be accepted into the mainline kernel tree, what you ... crashes of "the Linux kernel" caused by some binary-only driver. ... it's still a reason for fixing the real problem. ...
    (Linux-Kernel)
  • Re: RFT: updatedb "morning after" problem [was: Re: -mm merge plans for 2.6.23]
    ... Upon completion, it actually frees enough memory that swap-prefetch _could_ help on some boxes, while the real issue is that they should first and foremost dump GNU locate. ... I'm not saying the kernel needs to fix the software itself, but the kernel should try and keep such software from hurting the rest of the system where it can. ... (reading this thread it sometimes seems like the downside is that updatedb shouldn't cause this problem and so if you fixed updatedb there wold be no legitimate benifit, or alturnatly this patch doesn't help updatedb so there's no legitimate benifit) ... it's not that they shouldn't have been swapped out, it's that the reason they were swapped out no longer exists. ...
    (Linux-Kernel)