Date: Thu, 10 Oct 2002 18:25:45 -0400 From: abe <abe@informationwave.net> To: Terry Lambert <tlambert2@mindspring.com> Cc: hackers@freebsd.org Subject: Re: fatal trap 12 kernel panic Message-ID: <20021010222545.GA82461@dipole.informationwave.net> In-Reply-To: <3DA5FCD2.B23CD912@mindspring.com> References: <20021010212954.GA67855@dipole.informationwave.net> <3DA5F3BC.CD0154CF@mindspring.com> <20021010214518.GB71656@dipole.informationwave.net> <3DA5FCD2.B23CD912@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021010222545.GA82461>