Re: Protocol timer running before protocol init (Re: current panic igmp related ?)

From: Max Laier (max_at_love2party.net)
Date: 12/07/04

  • Next message: Gary Jennejohn: "NTFS after phk's changes" 
    To: Robert Watson <rwatson@freebsd.org>
Date: Tue, 7 Dec 2004 14:25:39 +0100

    On Tuesday 07 December 2004 13:50, Robert Watson wrote:
    > On Tue, 7 Dec 2004, Poul-Henning Kamp wrote:
    > > Timecounters tick every 1.000 msec
    > > panic: mtx_lock() of spin mutex (null) @ ../../../netinet/igmp.c:431
    > > cpuid = 0
    > > KDB: enter: panic
    > > [thread pid 37 tid 100013 ]
    > > Stopped at kdb_enter+0x2c: leave
    > > db> trace
    > > Tracing pid 37 tid 100013 td 0xc3485480
    > > kdb_enter(c06d85e0,100,c3485480,1af,c06e0fec) at kdb_enter+0x2c
    > > panic(c06d7ac5,0,c06e0fec,1af,c0713fc4) at panic+0x17f
    > > _mtx_lock_flags(c0738740,0,c06e0fec,1af,e4c97cc8) at _mtx_lock_flags+0x82
    > > igmp_slowtimo(e,0,e4c97cf4,c050683a,0) at igmp_slowtimo+0x19
    > > pfslowtimo(0,27,0,2,2) at pfslowtimo+0x66
    > > softclock(0,0,0,c34d07e0,0) at softclock+0x10a
    > > ithread_loop(c34cf100,e4c97d48,c34cf100,c04e9200,0) at ithread_loop+0x18e
    > > fork_exit(c04e9200,c34cf100,e4c97d48) at fork_exit+0x7e
    > > fork_trampoline() at fork_trampoline+0x8
    > > --- trap 0x1, eip = 0, esp = 0xe4c97d7c, ebp = 0 ---
    >
    > igmp_mtx looks to be uninitialized here (BSS memory). This suggests that
    > igmp_slowtimo is being called before igmp_init(), which strikes me as
    > somewhat odd. There's recently been some rerrangement of the domain
    > initialization code to correct potentially related problems, but perhaps
    > things aren't quite there yet. CC'ing Max on general principle. :-)

    That's not mine. Didn't touch the protosw parts ;)

    Still, the attached diff might help. It looks like we try to use Giant to
    protect the pfslowtimo() array walking, thus we must make sure that we hold
    Giant long enough while we set things up. I hope protosw_init() and therein
    called pr_init()s are fine with Giant hold. It'd surprise me, if not. 

    -- 
/"\  Best regards,                      | mlaier@freebsd.org
\ /  Max Laier                          | ICQ #67774661
 X   http://pf4freebsd.love2party.net/  | mlaier@EFnet
/ \  ASCII Ribbon Campaign              | Against HTML Mail and News

  • Next message: Gary Jennejohn: "NTFS after phk's changes"

    Relevant Pages

    • Re: if_start running deferred for Giant
      ... Robert Watson wrote: ... This occurs when a network device driver has declared itself IFF_NEEDSGIANT -- that is, has declared that it requires the Giant lock in order to operate. ... However, in the case of a USB device driver, it is currently required as the USB framework is not MPSAFE, so requires Giant. ...
      (freebsd-net)
    • Re: NET_NEEDS_GIANT removal
      ... On Fri, 1 Jun 2007, Robert Watson wrote: ... This allows them to run moderately safely, but eliminates use of more than one processor at a time in any part of the network stack, as well as increasing contention on Giant for any other non-MPSAFE components, requiring Giant be acquired in possible shared ithreads, etc. ... It does not yet compile, as parts requiring NET_NEEDS_GIANThaven't been removed/disabled yet, but does begin to give a sense of how removing these shims cleans up many complex code paths. ...
      (freebsd-current)
    • Re: I/O or Threading Suffer
      ... Robert Watson writes: ... There are some Giant issues related to the UIO stuff ... Mark Murray ...
      (freebsd-current)
    • Re: HEADS UP: Giant-free networking now the default in CVS HEAD (6.x)
      ... Robert Watson wrote: ... a number of kernel elements will now run without ... > Giant by default, and often in parallel or preemptively. ... To unsubscribe, ...
      (freebsd-current)