From owner-freebsd-hackers Thu Oct 10 15:27:30 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 BCBA437B401 for ; Thu, 10 Oct 2002 15:27:28 -0700 (PDT) Received: from mail1.informationwave.net (dipole.informationwave.net [199.74.235.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1315B43EB3 for ; Thu, 10 Oct 2002 15:27:28 -0700 (PDT) (envelope-from abe@informationwave.net) Received: by mail1.informationwave.net (Postfix, from userid 1007) id 585C74F917; Thu, 10 Oct 2002 18:25:45 -0400 (EDT) Date: Thu, 10 Oct 2002 18:25:45 -0400 From: abe To: Terry Lambert Cc: hackers@freebsd.org Subject: Re: fatal trap 12 kernel panic Message-ID: <20021010222545.GA82461@dipole.informationwave.net> References: <20021010212954.GA67855@dipole.informationwave.net> <3DA5F3BC.CD0154CF@mindspring.com> <20021010214518.GB71656@dipole.informationwave.net> <3DA5FCD2.B23CD912@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3DA5FCD2.B23CD912@mindspring.com> User-Agent: Mutt/1.4i 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 On Thu, Oct 10, 2002 at 03:18:58PM -0700, Terry Lambert wrote: > 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? Sorry Terry, unfortunately it wouldn't produce a system dump unless I was not taking the proper steps to produce one. Any URL that would point this out to me or any suggestion? > > [ ... ] > > > > 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. This is a vanilla installation with pretty much all inet services disabled. > > 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-(. Hell, it's more than I've gotten thus far. Much appreciation. Regards, Abe > > -- Terry > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message