Re: 8.0-RELEASE-p3: 4k jumbo mbuf cluster exhaustion

2010-08-24 Thread Adrian Chadd
On 24 August 2010 21:00, Andre Oppermann wrote: > > Try "netstat -n -p tcp -x" to see whether one socket is holding on to > too much data. ok. > Testing with a different network card would help to narrow down the > area to look for the bug as well. I don't have this option, unfortunately. The

Re: Error: em0: Watchdog timeout -- resetting

2010-08-24 Thread Vladislav V. Prodan
It was the motherboard from Supermicro, or another manufacturer? Have you tried to deal with this problem in support of the manufacturer? 25.08.2010 1:20, mar...@intranetplanet.com wrote: > I had the same issue six months ago with a test server. I did not find a > solution. I'm very much would li

Re: Error: em0: Watchdog timeout -- resetting

2010-08-24 Thread marek3
I had the same issue six months ago with a test server. I did not find a solution. I'm very much would like to see if you do find one. Thanks. Marek > The server is sometimes off the network card. > It helps just to restart via KVM-IPMI. > > MotherBoard: X8SIL/X8SIL-F > BIOS Version: 1.0c > Build

Error: em0: Watchdog timeout -- resetting

2010-08-24 Thread Vladislav V. Prodan
The server is sometimes off the network card. It helps just to restart via KVM-IPMI. MotherBoard: X8SIL/X8SIL-F BIOS Version: 1.0c Build Date: 02/05/10 OS: FreeBSD 8.1-RELEASE, FreeBSD 8.1-STABLE, FreeBSD 9.0-CURRENT What would you recommend to address the problem? # uname -a FreeBSD sol

RE: funny ECMP

2010-08-24 Thread Ingo Flaschberger
Dear Bjoern, I looked at some similar problem for someone end of April and the crude workaround was to disable (#if 0) the following code in in_lltable_lookup(): #if 0 if (!(flags & LLE_IFADDR) && in_lltable_rtcheck(ifp, flags, l3addr) != 0) goto done; #endif I had since defere

RE: funny ECMP

2010-08-24 Thread Bjoern A. Zeeb
On Tue, 24 Aug 2010, Ingo Flaschberger wrote: Hey, in arp-lookup code, the lowest weight + without gateway should be choosen. Sure, but such a configuration did not make much sense. when the in_lltable_lookup code tries to lookup the arp entry, the rtalloc_mpath_fib already has choosen th

RE: funny ECMP

2010-08-24 Thread Ingo Flaschberger
Dear Li, I hoped, that now, as freebsd has multi-route support (as other unix really have for a long long time) everything would be easier. But multipath support of freebsd is in my opinion, in a "experimental" state. Yes, agreed. It will be in the experimental state until there is vari

RE: funny ECMP

2010-08-24 Thread Li, Qing
> > > Sure, but such a configuration did not make much sense. > > Why not? > Use CARP and OSPF and you have such a configuration. > Okay, I will try that. > > I hoped, that now, as freebsd has multi-route support (as other unix > really have for a long long time) everything would be easie

RE: funny ECMP

2010-08-24 Thread Ingo Flaschberger
Dear Li, in arp-lookup code, the lowest weight + without gateway should be choosen. Sure, but such a configuration did not make much sense. when the in_lltable_lookup code tries to lookup the arp entry, the rtalloc_mpath_fib already has choosen that this packet should go the direkt way. S

RE: funny ECMP

2010-08-24 Thread Ingo Flaschberger
Dear Li, Sure, but such a configuration did not make much sense. Why not? Use CARP and OSPF and you have such a configuration. I read your other email explaining why your system is configured this way but I am still unclear from you text. Router 1 and Router 2 share 1 Ipadress via VRRP

RE: funny ECMP

2010-08-24 Thread Li, Qing
> > > I am trying to figure out, if the routing table have > > > > 10.13.13.0/24 10.11.11.1 > > 10.13.13.0/24 link#1 > > > > And if I do "ssh 10.13.13.2", which route should be used? > > the route with the lower weight. > if they have the same weight, use any of them. > I get the pr

Re: 8.0-RELEASE-p3: 4k jumbo mbuf cluster exhaustion

2010-08-24 Thread Pyun YongHyeon
On Tue, Aug 24, 2010 at 08:37:52PM +0800, Adrian Chadd wrote: > On 23 August 2010 18:18, Andre Oppermann wrote: > > It seems the 4k clusters do not get freed back to the pool after they've > > been sent by the NIC and dropped from the socket buffer after the ACK has > > arrived. ?The leak must occ

RE: funny ECMP

2010-08-24 Thread Ingo Flaschberger
Dear Li, I am trying to figure out, if the routing table have 10.13.13.0/24 10.11.11.1 10.13.13.0/24 link#1 And if I do "ssh 10.13.13.2", which route should be used? the route with the lower weight. if they have the same weight, use any of them. in arp-lookup code, the l

RE: funny ECMP

2010-08-24 Thread Li, Qing
Hi, I am trying to figure out, if the routing table have 10.13.13.0/24 10.11.11.1 10.13.13.0/24 link#1 And if I do "ssh 10.13.13.2", which route should be used? -- Qing > -Original Message- > From: Ingo Flaschberger [mailto:i...@xip.at] > Sent: Tuesday, August 24,

RE: funny ECMP

2010-08-24 Thread Ingo Flaschberger
Dear Li, The indirect route is colliding with the interface route, both have the same mask. How do you expect this to work ? How would the routing code differentiate between on-link nodes and the those needing to be routed through 10.11.11.1 ? in_lltable_rtcheck if (rt == NULL || (!(

RE: funny ECMP

2010-08-24 Thread Li, Qing
Hi, The indirect route is colliding with the interface route, both have the same mask. How do you expect this to work ? How would the routing code differentiate between on-link nodes and the those needing to be routed through 10.11.11.1 ? -- Qing > > one of the problems: > sysctl -w net.inet.

RE: funny ECMP

2010-08-24 Thread Ingo Flaschberger
Hi, one of the problems: sysctl -w net.inet.flowtable.enable=0 route add 10.13.13.0/24 10.11.11.1 -weight 2 ifconfig em1 alias 10.13.13.90/24 arp-resolve fails: arpresolve: can't allocate llinfo for 10.13.13.95 in sys/netinet/in.c: in_lltable_lookup calls in_lltable_rtcheck which calls rtalloc1

Re: 8.0-RELEASE-p3: 4k jumbo mbuf cluster exhaustion

2010-08-24 Thread Andre Oppermann
On 24.08.2010 14:37, Adrian Chadd wrote: On 23 August 2010 18:18, Andre Oppermann wrote: It seems the 4k clusters do not get freed back to the pool after they've been sent by the NIC and dropped from the socket buffer after the ACK has arrived. The leak must occur in one of these two places.

Re: 8.0-RELEASE-p3: 4k jumbo mbuf cluster exhaustion

2010-08-24 Thread Adrian Chadd
On 23 August 2010 18:18, Andre Oppermann wrote: > It seems the 4k clusters do not get freed back to the pool after they've > been sent by the NIC and dropped from the socket buffer after the ACK has > arrived.  The leak must occur in one of these two places.  The socket > buffer is unlikely as it

Re: kern/123603: [tcp] tcp_do_segment and Received duplicate SYN

2010-08-24 Thread andre
Synopsis: [tcp] tcp_do_segment and Received duplicate SYN Responsible-Changed-From-To: freebsd-net->andre Responsible-Changed-By: andre Responsible-Changed-When: Tue Aug 24 08:30:34 UTC 2010 Responsible-Changed-Why: Take over. http://www.freebsd.org/cgi/query-pr.cgi?pr=123603 ___

Re: kern/123617: [tcp] breaking connection when client downloading files from server

2010-08-24 Thread andre
Synopsis: [tcp] breaking connection when client downloading files from server Responsible-Changed-From-To: freebsd-net->andre Responsible-Changed-By: andre Responsible-Changed-When: Tue Aug 24 08:30:07 UTC 2010 Responsible-Changed-Why: Take over. http://www.freebsd.org/cgi/query-pr.cgi?pr=123617

Re: kern/149917: [net] [patch] freebsd 8.1 crash with ECMP

2010-08-24 Thread andre
Synopsis: [net] [patch] freebsd 8.1 crash with ECMP Responsible-Changed-From-To: freebsd-net->qingli Responsible-Changed-By: andre Responsible-Changed-When: Tue Aug 24 08:25:53 UTC 2010 Responsible-Changed-Why: Over to maintainer. http://www.freebsd.org/cgi/query-pr.cgi?pr=149917 ___

Re: kern/144777: [arp] proxyarp broken in 8.0 [regression]

2010-08-24 Thread andre
Synopsis: [arp] proxyarp broken in 8.0 [regression] Responsible-Changed-From-To: freebsd-net->qingli Responsible-Changed-By: andre Responsible-Changed-When: Tue Aug 24 07:54:38 UTC 2010 Responsible-Changed-Why: Over to maintainer. http://www.freebsd.org/cgi/query-pr.cgi?pr=144777 ___