From owner-freebsd-hackers Thu Oct 10 16:26: 3 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 460FE37B401 for ; Thu, 10 Oct 2002 16:26:00 -0700 (PDT) Received: from mail1.informationwave.net (dipole.informationwave.net [199.74.235.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9A11243EA9 for ; Thu, 10 Oct 2002 16:25:59 -0700 (PDT) (envelope-from abe@informationwave.net) Received: by mail1.informationwave.net (Postfix, from userid 1007) id EF8A04F917; Thu, 10 Oct 2002 19:24:16 -0400 (EDT) Date: Thu, 10 Oct 2002 19:24:16 -0400 From: abe To: Terry Lambert Cc: hackers@freebsd.org Subject: Re: fatal trap 12 kernel panic Message-ID: <20021010232416.GA97757@dipole.informationwave.net> References: <20021010212954.GA67855@dipole.informationwave.net> <3DA5F3BC.CD0154CF@mindspring.com> <20021010214518.GB71656@dipole.informationwave.net> <3DA5FCD2.B23CD912@mindspring.com> <20021010222545.GA82461@dipole.informationwave.net> <3DA60447.4C66C85@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3DA60447.4C66C85@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:50:47PM -0700, Terry Lambert wrote: > abe wrote: > > > 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? > > Poul changed this code. I haven't been able to get a correct dump > locally since then. It would really depend on the *exact* version > of FreeBSD you are running. You might want to look in the handbook, > if you have a good version. > > The normal way on older versions was to add: > > dumpdev="/dev/ad0s3b" > > ...or whatever device your swap normally lives on... to your > /etc/rc.conf. It's required to be the size of physical memory > plus 64K (at a minimum). See "man dumpon". Tried that, no luck. savecore still complained about no dumpdev. 4.5-release I'd imagine is the exact version... > > > > > 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. > > You are doing something UDP. It may be that some idiot has > configured your machine as their DNS forwarder. This can > happen if you leave your DNS server open for forwarding requests. Using at the moment comcast's nameservers, and an IP issued via DHCP from them. > > > > > 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. > > No problem. > > Thinking a bit more: > > You should be able to find out the C code at assembly code offset > 0x172, assuming you created your kernel with "config -g", and you > compiled the ipfw statically into the kernel, instead of loading > it as a module. > > Assuming this is the case, to do that, go to the directory you > compiled the kernel in, and run: > > gdb -k kernel.debug > list *add_dyn_rule+0x172 (kgdb) list *add_dyn_rule+0x172 No source file for address 0xc021e5d6 (kgdb) > > ...don't forget to insert the 'x': it's a hex number. The kernel > debugger leaves out the 'x' "To Be A Pain In Terry's Ass, For No > Good Reason"(tm) ...you'll notice that it didn't leave it out of the > traceback itself. > > You will likely need to back the number up to get a clean listing > of the source line that caused the fault. > > Yeah, statically compiling in the IPFW is annoying, particularly > since you will have to play "swap the kernel" to get a kernel up > without IPFW, and this will be a pain, if the panic is immediate. > > -- Terry Regards, Abe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message