David Cornejo wrote:
This may not be related, but I have a Soekris 4801 running CURRENT that
with a GENERIC kernel exhibits the behavior where TCP connects don't
happen. If I switch to an old kernel config file, it works..
This failure happens between this box and a RELENG_6 (updated last
we
Andre, good day.
Tue, Jun 12, 2007 at 07:15:32PM +0200, Andre Oppermann wrote:
> >Just checked my netstat output and spotted weird lines:
> >-
> >tcp4 0 0 127.0.0.1.*127.0.0.1.40001CLOSED
> >tcp4 0 0 127.0.0.1.*127.0.0.1.40001CLOS
This may not be related, but I have a Soekris 4801 running CURRENT
that with a GENERIC kernel exhibits the behavior where TCP connects
don't happen. If I switch to an old kernel config file, it works..
This failure happens between this box and a RELENG_6 (updated last
week), another CURRENT b
I noticed that if I reboot a server that is the MASTER, the carp0 on the
BACKUP box goes into MASTER mode and stays that way -- even when the
real master machine has finished rebooting. Is this a desired trait to
prevent CARP from switching IPs out of control?
Any how, I wrote a cronjob tha
Bill Moran wrote this message on Tue, Jun 12, 2007 at 13:13 -0400:
> > b) you may run out of socket on the client side and reuse them
> > too fast. Try to lower net.inet.ip.portrange.first to 30,000
> > or so.
>
> I find that unlikely. The problem usually occurs reliably after less
>
On Tue, Jun 12, 2007 at 10:19:49AM -0400, Bill Moran wrote:
This one has got me pretty befuddled.
We're seeing some really odd behaviour with FreeBSD ignoring SYN packets.
I've been trying to diagnose this for a couple of weeks now, and my current
guess is that there's something wron
Eygene Ryabinkin wrote:
Me again.
Tue, Jun 12, 2007 at 07:26:56AM +0400, Eygene Ryabinkin wrote:
Mon, Jun 11, 2007 at 09:09:18PM +0200, Andre Oppermann wrote:
These messages are unrelated to your hardware. There you can relax.
We have a bug in the TCP FSM state transitions which I'm currently
In response to Andre Oppermann <[EMAIL PROTECTED]>:
>
> Before we go into more detail:
>
> a) the em(4) driver is most likely totally unrelated to this
Are you saying it's more likely to be a tcp stack problem? As an experiment,
I tried to reproduce it over the loopback and was unable to, whi
Hello,
We have some servers that have a very high packet rate in a normal
production mode, and require polling to keep the CPU load reasonable.
We have Kern.HZ=4000, and even still, have some dropped packets.
On our servers that use the intel "em" driver, we have tuned the
drivers as following,
Bill Moran wrote:
This one has got me pretty befuddled.
We're seeing some really odd behaviour with FreeBSD ignoring SYN packets.
I've been trying to diagnose this for a couple of weeks now, and my current
guess is that there's something wrong with the em driver. Here's a narrowed
down list of
Brief update to add another item to the list of things I've tried:
*) The problem occurs whether the em device is polling or not.
In response to Bill Moran <[EMAIL PROTECTED]>:
>
> This one has got me pretty befuddled.
>
> We're seeing some really odd behaviour with FreeBSD ignoring SYN packets.
This one has got me pretty befuddled.
We're seeing some really odd behaviour with FreeBSD ignoring SYN packets.
I've been trying to diagnose this for a couple of weeks now, and my current
guess is that there's something wrong with the em driver. Here's a narrowed
down list of what I've ruled out
12 matches
Mail list logo
