I think problem may be like there
http://lists.freebsd.org/pipermail/freebsd-net/2010-April/025156.html
what type of IFace for your FWD rules ?
I have crash only for ng IF. over gif fwd work without problem.
But it only for my case.
Mon, 21 Feb 2011 00:13:12 +0100 письмо от Pawel Tyll :
> >
On 2011-Feb-20 01:39:00 +0100, Pawel Tyll wrote:
>Since nobody came up with any interest in having this properly
>investigated, then I suppose I'm the only one that uses dummynet for
>some larger-scale traffic shaping - maybe that's my mistake?
I'm using dummpnet+pf (not ipfw) on (roughly) FreeBS
> addresses not needed, thanks. From what i saw in the backtrace, the panic
> occurred on an incoming packet on the 'antispoof' option.
> The ruleset confirms the backtrace, but since
> 'antispoof' happens
> to be run on every packet given it is on the first rule,
> it apparently has nothing to do
On Mon, Feb 21, 2011 at 12:13:12AM +0100, Pawel Tyll wrote:
> > understood. I am just saying that for instance the vlan presence and
> > changes is quite significant in this context.
> > You say vlans are "pretty much static" but can you tell us who adds/remove
> > them, assign addresses ?
> It's
> understood. I am just saying that for instance the vlan presence and
> changes is quite significant in this context.
> You say vlans are "pretty much static" but can you tell us who adds/remove
> them, assign addresses ?
It's not that much work and changes are simple and far between. I do
that p
On Sun, Feb 20, 2011 at 11:50:28PM +0100, Pawel Tyll wrote:
...
> This machine is only doing dummynet traffic shaping from significant
> things (otherwise it runs a dhcpd, ntpd and named). It's pretty
> straight-forward routing, packets come in, packets come out via static
> routes - there are curr
> The way a problem is presented has a big impact on how it gets handled:
> in this specific case the poster is pointing out a possible culprit
> (which may be helpful or misleading), and gives no hint on other
> things that may be relevant: number of interfaces, vlans, tunnels, taps,
> bpf etc ? a
On Sun, Feb 20, 2011 at 04:54:34AM +0100, Pawel Tyll wrote:
> > I've never seen a trace like this, and no absolutely nothing about
> > dummynet, sorry.
> > If it is in some way em's fault, then making sure you have the latest code
> > would be
> > a good idea. I have a test driver that is under s
> I've never seen a trace like this, and no absolutely nothing about dummynet,
> sorry.
> If it is in some way em's fault, then making sure you have the latest code
> would be
> a good idea. I have a test driver that is under selective test, it does
> effect the code
> path that you seem to be i
> I was actually going to suggest Pawl try a different network device if
> possible. I'm using dummynet on a network gateway equipped with
> on-board bge(4). I haven't had any crashes, but then again, I'm not
> seeing that many packets either.
It seems to be closely related to amount of processed p
> Same backtrace as reported here?
I'm unable to get the new backtrace, but judging from what I can see
on the console pre-reboot, it's exactly the same deal since
8.0-RELEASE - panic with dummynet as main star.
> What revision of the em(4) driver code are you using? I know Jack has
> been working
On Sat, Feb 19, 2011 at 8:40 PM, Jack Vogel wrote:
> I've never seen a trace like this, and no absolutely nothing about dummynet,
> sorry.
> If it is in some way em's fault, then making sure you have the latest code
> would be
> a good idea. I have a test driver that is under selective test, it do
I've never seen a trace like this, and no absolutely nothing about dummynet,
sorry.
If it is in some way em's fault, then making sure you have the latest code
would be
a good idea. I have a test driver that is under selective test, it does
effect the code
path that you seem to be in, so it might be
2011/2/19 Pawel Tyll :
> Hi guys, lists,
>
> It's me, the bi-weekly panic guy. Guess what, it crashed today. As an
> act of desperation I disabled the pipe dumping script after previous
> crash, which today turned out to be merely a coincidence and didn't
> prevent panics. (I thought it to be a lon
Hi guys, lists,
It's me, the bi-weekly panic guy. Guess what, it crashed today. As an
act of desperation I disabled the pipe dumping script after previous
crash, which today turned out to be merely a coincidence and didn't
prevent panics. (I thought it to be a longshot anyway, but it was the
only
> Just replying so you know I'm seeing it, but something that takes 14 days to
> even happen
> is NOT going to be an easy one to find. As Brandon said, all the info you
> can provide please.
Here's the dump in case you've not seen it before. Somehow 8.1-RELEASE
managed to make a proper dump, which
Just replying so you know I'm seeing it, but something that takes 14 days to
even happen
is NOT going to be an easy one to find. As Brandon said, all the info you
can provide please.
Jack
On Mon, Jan 24, 2011 at 9:11 AM, Brandon Gooch
wrote:
> On Sun, Jan 23, 2011 at 7:08 PM, Pawel Tyll wrote:
On Sun, Jan 23, 2011 at 7:08 PM, Pawel Tyll wrote:
> On Fri, Jan 7, 2011, Brandon Gooch wrote:
>> It's likely that the mbuf handling problem (in em_refresh_mbufs()) is
>> triggered by the processing you're doing with ipfw (or elsewhere for
>> that matter), so, yes, I think it's a bug fixed in the
On Fri, Jan 7, 2011, Brandon Gooch wrote:
> It's likely that the mbuf handling problem (in em_refresh_mbufs()) is
> triggered by the processing you're doing with ipfw (or elsewhere for
> that matter), so, yes, I think it's a bug fixed in the revision
> discussed.
> When you update and test, pleas
On Fri, Jan 7, 2011 at 10:14 AM, Pawel Tyll wrote:
> One more question tough,
>
> I have 4 identical machines, also with em-driven NICs - yet this is
> the only one that dies like this. OTOH Other machines don't do traffic
> shaping and do not use ipfw that extensively. Does this match your
> theo
One more question tough,
I have 4 identical machines, also with em-driven NICs - yet this is
the only one that dies like this. OTOH Other machines don't do traffic
shaping and do not use ipfw that extensively. Does this match your
theory?
___
freebsd-n
Hi Brandon,
> Might this be an issue with the em(4) driver? It may be that it's fixed:
> http://svn.freebsd.org/viewvc/base?view=revision&sortby=date&revision=216440
Thanks Brandon - I'll update to fresh stable and get back to you... in
three to four weeks :)
2011/1/6 Pawel Tyll :
> Hi lists,
>
> I've reported this problem:
> http://www.freebsd.org/cgi/query-pr.cgi?pr=152360
>
> and ever since 8.1-RELEASE this machine keeps panicking every two weeks
> or so. Any help will be much appreciated. I'll be happy to provide any
> more info to help tracking thi
Hi lists,
I've reported this problem:
http://www.freebsd.org/cgi/query-pr.cgi?pr=152360
and ever since 8.1-RELEASE this machine keeps panicking every two weeks
or so. Any help will be much appreciated. I'll be happy to provide any
more info to help tracking this down.
__
24 matches
Mail list logo
