From owner-freebsd-hackers Thu Oct 10 15:20:41 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 84CE337B401 for ; Thu, 10 Oct 2002 15:20:39 -0700 (PDT) Received: from albatross.prod.itd.earthlink.net (albatross.mail.pas.earthlink.net [207.217.120.120]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0D23E43EA9 for ; Thu, 10 Oct 2002 15:20:39 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0397.cvx21-bradley.dialup.earthlink.net ([209.179.193.142] helo=mindspring.com) by albatross.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 17zlfU-00019B-00; Thu, 10 Oct 2002 15:20:33 -0700 Message-ID: <3DA5FCD2.B23CD912@mindspring.com> Date: Thu, 10 Oct 2002 15:18:58 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: abe Cc: hackers@freebsd.org Subject: Re: fatal trap 12 kernel panic References: <20021010212954.GA67855@dipole.informationwave.net> <3DA5F3BC.CD0154CF@mindspring.com> <20021010214518.GB71656@dipole.informationwave.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG abe wrote: > This started out as a sudden panic on a machine that was in a > datacenter for more than 8 months without issue. Then I installed > on fresh machines, compiled in ipfw support, and also tried this as > a module. The result is the same regardless. You have a traceback; do you have a system dump? [ ... ] > > > Stopped at add_dyn_rule+0172: movl 0(%edx,%ebx,4)x%eax Knowing the line of C code involved would be much more useful. Are you suddenly running an application that you did not formerly run? The creation of a dynamic rule as a result of a ip_output() call to ip_fw_chk() to install_state() to add_dyn_rule() implies that the flow ID passed down to add_dyn_rule() with the value of dyn_type == DYN_KEEP_STATE is valid. One possibility that occurs to me is that you end up with a parent count going over 65535 (it's a u_int16_t). When it is counted yet again, it goes to 0, then again, to 1. Then the next reference deletion causes it to go 1->0, at which point, the parent is deleted, even though it's still referenced. If this is the case, you can work around it by ensuring that a dynamic limit of 65534 or less is set. Another workaround would be to change the "count" member of the "struct ipfw_dyn_rule" to b a u_int32_t, and recompile everything. Without knowing the source code involved, you are unlikely to get an answer that's more than a guess. 8-(. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message