Re: what to replace splnet in FreeBSD 5.x?

From: Ed Maste (emaste_at_phaedrus.sandvine.ca)
Date: 08/03/05

  • Next message: Dave+Seddon: "running out of mbufs?" 
    Date: Tue, 2 Aug 2005 21:18:06 -0400
To: Robert Watson <rwatson@FreeBSD.org>

    On Mon, Aug 01, 2005 at 07:16:58PM +0100, Robert Watson wrote:

    > >Updated version of the patch at:
    > >
    > >http://www.watson.org/~robert/freebsd/netperf/20050523-multicast.diff
    > >
    > >Spl-related cleanups (no longer useful documentation of old
    > >synchronization in many places), lock order hard-coded into WITNESS
    > >order rather than dynamically detected.
    >
    > Ed,
    >
    > Have you had a chance to run with this patch as yet? If possible, I'd
    > like to get it merged to 7.x-CURRENT so we can backport it for 6.0.

    I finally got our local CVS repository back into shape and gave this
    patch a try. Unfortunately got a panic as soon as our multicast app
    started up:

    panic: _mtx_lock_sleep: recursed on non-recursive mutex in_multi_mtx @ /d2/emaste/cvs_mcast/src/sys/netinet/ip_output.c:298

    cpuid = 0
    KDB: stack backtrace:
    kdb_backtrace(100,a2894300,a07eba00,a07eba00,12a) at 0xa0586915 = kdb_backtrace+0x29
    panic(a071a883,a071f26e,a0729680,12a,a07eba00) at 0xa056eeb8 = panic+0x114
    _mtx_lock_sleep(a07eba00,a2894300,0,a0729680,12a) at 0xa05669cb = _mtx_lock_sleep+0x33
    _mtx_lock_flags(a07eba00,0,a0729680,12a,0) at 0xa05664ba = _mtx_lock_flags+0x8a
    ip_output(a2645e00,a2649100,a07eb9b0,0,c8635b08) at 0xa05f7b0e = ip_output+0x3fe
    igmp_sendpkt(a24b9de0,16,0,a24b9de0,c8635bb8) at 0xa05e292e = igmp_sendpkt+0x106
    igmp_joingroup(a24b9de0,a2504240,210,240600ef,0) at 0xa05e2642 = igmp_joingroup+0x92
    in_addmulti(c8635bcc,a23a1400,a23a1400,240600ef,1000001) at 0xa05e437e = in_addmulti+0x10e
    ip_setmoptions(a272c7f8,c8635c90,a071a701,12c,0) at 0xa05f9278 = ip_setmoptions+0x3a0
    ip_ctloutput(a27c2650,c8635c90,a283a22c,0,a0722810) at 0xa05f8a57 = ip_ctloutput+0x36b
    sosetopt(a27c2650,c8635c90,a26af798,1,0) at 0xa05a91ac = sosetopt+0x2c
    kern_setsockopt(a2894300,b,0,c,9fbfcd60) at 0xa05ada71 = kern_setsockopt+0xb5
    setsockopt(a2894300,c8635d04,5,3,246) at 0xa05ad9ba = setsockopt+0x1e
    syscall(81e003b,81e003b,9fbf003b,9fbfcd70,841fc28) at 0xa06c72fb = syscall+0x25b

    in_addmulti holds the in_multi_mtx when it calls _joingroup.

    I haven't yet looked over the whole patch to understand the
    specifics. I'll post again once I do if I have any ideas. 

    --
Ed Maste, Sandvine Incorporated.
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
  • Next message: Dave+Seddon: "running out of mbufs?"

    Relevant Pages

    • Re: spitz (zaurus sl-c3000) support
      ... so it should be spitz. ... write the patch and I think a reference to the battery device sneaked ... into mainline when it shouldn't have done. ... agreed some changes to enable it to stand a chance of making mainline. ...
      (Linux-Kernel)
    • RFC: [PATCH] Small patch on top of per device dirty throttling -v9
      ... Hi Peter, ... Just by chance I found that this ... apparently is an enforced limit in mm/page-writeback.c. ... With below patch I have lowered the limit to 2%. ...
      (Linux-Kernel)
    • Re: ListBox Problem in VS2003
      ... Running McAfee antivirus by any chance? ... It's a bug in that product that causes this behaviour ... It has been fixed with patch 5 (sorry, ...
      (microsoft.public.dotnet.framework.windowsforms.controls)
    • Re: Endless ACPI errors on Linus tree (5b664cb235)
      ... already sent out attached patch as a replacement one. ... Any chance you ... doing this would be to introduce a command line option controlling the ...
      (Linux-Kernel)
    • Re: CA real time forecast oddity
      ... that map seems to say there is a 1/100 chance of MM VI ... shaking across a large area by Anza - that can't be right. ... archives, it appears the patch grew yesterday, as you indicate. ...
      (sci.geo.earthquakes)