kern/134157: [dummynet] dummynet loads cpu for 100% and make a system frozen and unstable [regression]

[Oleg Bulyzhin]

The following reply was made to PR kern/134157; it has been noted by GNATS.

From: Oleg Bulyzhin 
To: bug-follo...@freebsd.org
Cc: s...@ft.cv.ua
Subject: kern/134157: [dummynet] dummynet loads cpu for 100% and make a
system frozen and unstable [regression]
Date: Mon, 4 May 2009 12:05:19 +0400

 Please show sysctl net.inet.ip.dummynet output, your ipfw ruleset and
 pipe configs.
 
 -- 
 Oleg.
 
 
 === Oleg Bulyzhin -- OBUL-RIPN -- OBUL-RIPE -- o...@rinet.ru ===
 
 
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Filesystem and bigger files

[Antonio Tommasi]

Hi to all,
i've freebsd 7.0 in production and i've this hard-drive

Filesystem   SizeUsed   AvailCapacity  Mounted on
/dev/aacd0s1a  64G15G 44G 26%/

In a directory (spamassassin) i've one file (auto-whitelist) with 
dimension 4.0 TB and one file (bayes_learn) with dimension 1.0TB


How is it possible? How this file are managed?


thanks
Antonio
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Current problem reports assigned to freebsd-net@FreeBSD.org

[FreeBSD bugmaster]

Note: to view an individual PR, use:
  http://www.freebsd.org/cgi/query-pr.cgi?pr=(number).

The following is a listing of current problems submitted by FreeBSD users.
These represent problem reports covering all versions including
experimental development code and obsolete releases.


S Tracker  Resp.  Description

o kern/134168  net[ral] ral driver problem on RT2525 2.4GHz transceiver 
o kern/134157  net[dummynet] dummynet loads cpu for 100% and make a syst
o kern/134079  net[em] "em0: Invalid MAC address" in FreeBSD-Current ( 8
o kern/133969  net[dummynet] [panic] Fatal trap 12: page fault while in 
o kern/133968  net[dummynet] [panic] dummynet kernel panic
o kern/133902  net[tun] Killing tun0 iface ssh tunnel causes Panic Strin
o kern/133736  net[udp] ip_id not protected ...
o kern/133613  net[wpi] [panic] kernel panic in wpi(4)
o kern/133595  net[panic] Kernel Panic at pcpu.h:195
o kern/133572  net[ppp] [hang] incoming PPTP connection hangs the system
o kern/133490  net[bpf] [panic] 'kmem_map too small' panic on Dell r900 
o kern/133328  net[bge] [panic] Kernel panics with Windows7 client
o kern/133235  net[netinet] [patch] Process SIOCDLIFADDR command incorre
o kern/133218  net[carp] [hang] use of carp(4) causes system to freeze
o kern/133204  net[msk] msk driver timeouts
o kern/133060  net[ipsec] [pfsync] [panic] Kernel panic with ipsec + pfs
o kern/132991  net[bge] if_bge low performance problem
o kern/132984  net[netgraph] swi1: net 100% cpu usage
f bin/132911   netip6fw(8): argument type of fill_icmptypes is wrong and
o kern/132889  net[ndis] [panic] NDIS kernel crash on load BCM4321 AGN d
o kern/132885  net[wlan] 802.1x broken after SVN rev 189592
o conf/132851  net[fib] [patch] allow to setup fib for service running f
o kern/132832  net[netinet] [patch] tcp_output() might generate invalid 
o bin/132798   net[patch] ggatec(8): ggated/ggatec connection slowdown p
o kern/132734  net[ifmib] [panic] panic in net/if_mib.c
o kern/132722  net[ath] Wifi ath0 associates fine with AP, but DHCP or I
o kern/132715  net[lagg] [panic] Panic when creating vlan's on lagg inte
o kern/132705  net[libwrap] [patch] libwrap - infinite loop if hosts.all
o kern/132672  net[ndis] [panic] ndis with rt2860.sys causes kernel pani
o kern/132669  net[xl] 3c905-TX send DUP! in reply on ping (sometime)
o kern/132625  net[iwn] iwn drivers don't support setting country
o kern/132554  net[ipl] There is no ippool start script/ipfilter magic t
o kern/132354  net[nat] Getting some packages to ipnat(8) causes crash
o kern/132285  net[carp] alias gives incorrect hash in dmesg
o kern/132277  net[crypto] [ipsec] poor performance using cryptodevice f
o conf/132179  net[patch] /etc/network.subr: ipv6 rtsol on incorrect wla
o kern/132107  net[carp] carp(4) advskew setting ignored when carp IP us
o kern/131781  net[ndis] ndis keeps dropping the link
o kern/131776  net[wi] driver fails to init
o kern/131753  net[altq] [panic] kernel panic in hfsc_dequeue
o bin/131567   net[socket] [patch] Update for regression/sockets/unix_cm
o kern/131549  netifconfig(8) can't clear 'monitor' mode on the wireless
o kern/131536  net[netinet] [patch] kernel does allow manipulation of su
o bin/131365   netroute(8): route add changes interpretation of network 
o kern/131162  net[ath] Atheros driver bugginess and kernel crashes
o kern/131153  net[iwi] iwi doesn't see a wireless network
f kern/131087  net[ipw] [panic] ipw / iwi - no sent/received packets; iw
f kern/130820  net[ndis] wpa_supplicant(8) returns 'no space on device'
o kern/130628  net[nfs] NFS / rpc.lockd deadlock on 7.1-R
o conf/130555  net[rc.d] [patch] No good way to set ipfilter variables a
o kern/130525  net[ndis] [panic] 64 bit ar5008 ndisgen-erated driver cau
o kern/130311  net[wlan_xauth] [panic] hostapd restart causing kernel pa
o kern/130109  net[ipfw] Can not set fib for packets originated from loc
f kern/130059  net[panic] Leaking 50k mbufs/hour
o kern/129750  net[ath] Atheros AR5006 exits on "cannot map register spa
f kern/129719  net[nfs] [panic] Panic during shutdown, tcp_ctloutput: in
o kern/129580  net[ndis] Netgear WG311v3 (ndis) causes kenel trap at boo
o kern/129517  net[ipsec] [panic] double fault / stack overflow
o kern/129508  net[carp] [panic] Kernel panic with EtherIP (may be relat
o kern/129352  net[xl] [patch] xl0 watchdog timeout
o kern/129219  net[ppp] Kernel panic when using kernel mode ppp
o kern/129197 

Re: kern/134157: [dummynet] dummynet loads cpu for 100% and make a system frozen and unstable [regression]

[Oleg Bulyzhin]

The following reply was made to PR kern/134157; it has been noted by GNATS.

From: Oleg Bulyzhin 
To: Andrey Golenischev 
Cc: bug-follo...@freebsd.org
Subject: Re: kern/134157: [dummynet] dummynet loads cpu for 100% and make a
system frozen and unstable [regression]
Date: Mon, 4 May 2009 19:09:50 +0400

 Few more questions:
 1) Are you using mpd? Did you upgrade it along with system? Have you tried
 to use mpd4? (if you have problem with mpd5)
 2) please show me values of following sysctl:
 net.inet.ip.fw.one_pass
 net.isr.direct
 
 -- 
 Oleg.
 
 
 === Oleg Bulyzhin -- OBUL-RIPN -- OBUL-RIPE -- o...@rinet.ru ===
 
 
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: CARP as a module; followup thoughts

[Bruce Simpson]

Will Andrews wrote:

Thank you very much for your feedback.  I have implemented your
suggestion as follows:

http://firepipe.net/patches/carp-as-module-20090503-2.diff
  


Great stuff. Overall this does make things that much cleaner.


This version doesn't reinvent the wheel as far as registering the
protocol goes.  Personally, I think that notwithstanding your other
objection, this should get committed, since it is a step in the right
direction (perhaps minus the netinet6/in6_proto.c change that adds
spacers).  One step at a time!
  


Yeah, I wouldn't worry about it too much for now.

It is something which would be nice to have -- some NICs will perfect 
hash in hardware on more than one MAC address -- but I believe we've got 
other issues in this area to do with per-AF locking, which would 
probably be touched by exactly the issues you raise in the last part of 
your post... well spotted...




carp_encapcheck() is simplistic, but probably suffices (maybe also
check to see if the vh MAC matches).  This patch does work fine with
my test setup, one system using GENERIC+if_carp and the other using a
static build without the patch.
  


I'll have to take your word for that as I'm not using CARP just at the 
moment. I had to touch the mcast setup for the IPv6 SSM implementation. 
All compiles OK, but I haven't tested the code other than loading it. 
Only IPv6 multicast group setup should be affected.


Does your patch apply against these revisions OK?


I also found a "memory leak" in the original code, where it calls
free(cif, M_IFADDR), which is wrong, it should be free(cif, M_CARP),
since the original malloc uses M_CARP -- this fix is also included in
the patch above.
  


Great stuff.
Can this bug fix be merged separately, i.e. before other code is committed?
That way it can get merged back to -STABLE more quickly, once RELENG_7 
is unfrozen.



...

Another way would be to have a separate list/hash table for virtual
lladdr's (ifnet.ifvirt_lladdrhead?).  I considered that but it seems
better and more general to simply upgrade ifnet.if_addrhead.
  


It would be good to have a more general code path for stuff like this to 
benefit from using the perfect hash filters in modern NICs, the main 
thing is that everything continues to work with no regressions :-)


Thanks for the effort you've put into this, it will certainly help a lot 
of folk to be able to ship a CARP-capable GENERIC kernel.


cheers,
BMS
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: Slow local TCP transfers on -CURRENT

[George Neville-Neil]

On May 2, 2009, at 08:16 , Lawrence Stewart wrote:


Kevin Day wrote:
I've been seeing this for a few months now on -CURRENT. TCP  
transfers to local IP addresses (but not 127.0.0.1) are incredibly  
slow.

Transfer from localhost:
# scp "r...@127.0.0.1:/boot/kernel/kernel" .
kernel 
  100 
%   11MB  11.1MB/s   00:00

Appropriately fast.
Transfer from an IP on a local interface:
# scp "r...@216.14.96.4:/boot/kernel/kernel" .
kernel 
0 
%   16KB  13.0KB/s   14:37 ETA

The routes seem normal:
# route get 127.0.0.1
 route to: localhost
destination: localhost
interface: lo0
flags: 
recvpipe  sendpipe  ssthresh  rtt,msecmtuweightexpire
 0 0 0 0 16384 1 0
# route -n get 216.14.96.4
 route to: 216.14.96.4
destination: 216.14.96.0
 mask: 255.255.255.128
interface: nfe0
flags: 
recvpipe  sendpipe  ssthresh  rtt,msecmtuweightexpire
 0 0 0 0  1500 1 0
nfe0: flags=8843 metric 0  
mtu 1500
   
options=19b

  ether 00:30:48:c6:dd:9c
  inet 216.14.96.4 netmask 0xff80 broadcast 216.14.96.127
Takes 10-60 minutes to copy, stalling frequently during the  
transfer. It's not limited to just scp either, all TCP transfers  
seem to stall this way.
I don't believe I'm doing anything unusual, has anyone seen  
anything like this?


Known fallout from the ARPv2 work I believe. As a workaround until  
it gets fixed:


route add -host (if-ip) -iface lo0 (note I haven't tested this myself)

(see the Jan 2009 freebsd-net@ thread "Bacula: VERY SLOW on SAME  
host" for some details).




Anyone know if there is a fix in the offing?

Best,
George

___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: Filesystem and bigger files

[Eygene Ryabinkin]

Antonio, good day.

Mon, May 04, 2009 at 12:50:59PM +0200, Antonio Tommasi wrote:
> i've freebsd 7.0 in production and i've this hard-drive
> 
> Filesystem   SizeUsed   AvailCapacity  Mounted on
> /dev/aacd0s1a  64G15G 44G 26%/
> 
> In a directory (spamassassin) i've one file (auto-whitelist) with 
> dimension 4.0 TB and one file (bayes_learn) with dimension 1.0TB
> 
> How is it possible? How this file are managed?

First, this isn't a proper question for the freebsd-net mailing list,
so I am redirecting it to freebsd-questions.

To answer your question: most likely, your filesystem is damaged and
should be fsck'ed.  Reboot in a single-user mode and run 'fsck -p
/dev/aacd0s1a' on your filesystem.  If it will correct the things --
it's good.  If not, run 'fsck /dev/aacd0s1a'.  It is always good to have
backups ;))  And the possible filesystem corruption is one of the
reasons why people prefer multiple partitions on the system, rather then
having one big and fat '/' partition.

Another possibility is that these files are sparse: they have "holes"
that aren't yet filled in.  Tb sizes are insane, but may be you directed
SA to do it.  Here is the illustration of sparse file creation and
its impact on the filesystem size:
-
Filesystem  1K-blocks Used   Avail Capacity  Mounted on
/dev/ad4s2f  24808094 14819988 800346065%/0

$ dd if=/dev/zero of=test.bin bs=1K count=1 seek=10M
1+0 records in
1+0 records out
1024 bytes transferred in 0.49 secs (20951060 bytes/sec)

$ ls -l test.bin
-rw-r--r--  1 usr  usr  10737419264  4 май 16:54 test.bin

$ df .
Filesystem  1K-blocks Used   Avail Capacity  Mounted on
/dev/ad4s2f  24808094 14820046 800340265%/0
-
-- 
Eygene
 ____   _.--.   #
 \`.|\.....-'`   `-._.-'_.-'`   #  Remember that it is hard
 /  ' ` ,   __.--'  #  to read the on-line manual
 )/' _/ \   `-_,   /#  while single-stepping the kernel.
 `-'" `"\_  ,_.-;_.-\_ ',  fsc/as   #
 _.-'_./   {_.'   ; /   #-- FreeBSD Developers handbook
{_.-``-' {_/#
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: Slow local TCP transfers on -CURRENT

[Lawrence Stewart]

George Neville-Neil wrote:


On May 2, 2009, at 08:16 , Lawrence Stewart wrote:


Kevin Day wrote:
I've been seeing this for a few months now on -CURRENT. TCP transfers 
to local IP addresses (but not 127.0.0.1) are incredibly slow.

Transfer from localhost:
# scp "r...@127.0.0.1:/boot/kernel/kernel" .
kernel  
100%   11MB  11.1MB/s   00:00

Appropriately fast.
Transfer from an IP on a local interface:
# scp "r...@216.14.96.4:/boot/kernel/kernel" .
kernel
0%   16KB  13.0KB/s   14:37 ETA

The routes seem normal:
# route get 127.0.0.1
 route to: localhost
destination: localhost
interface: lo0
flags: 
recvpipe  sendpipe  ssthresh  rtt,msecmtuweightexpire
 0 0 0 0 16384 1 0
# route -n get 216.14.96.4
 route to: 216.14.96.4
destination: 216.14.96.0
 mask: 255.255.255.128
interface: nfe0
flags: 
recvpipe  sendpipe  ssthresh  rtt,msecmtuweightexpire
 0 0 0 0  1500 1 0
nfe0: flags=8843 metric 0 mtu 
1500
  
options=19b

  ether 00:30:48:c6:dd:9c
  inet 216.14.96.4 netmask 0xff80 broadcast 216.14.96.127
Takes 10-60 minutes to copy, stalling frequently during the transfer. 
It's not limited to just scp either, all TCP transfers seem to stall 
this way.
I don't believe I'm doing anything unusual, has anyone seen anything 
like this?


Known fallout from the ARPv2 work I believe. As a workaround until it 
gets fixed:


route add -host (if-ip) -iface lo0 (note I haven't tested this myself)

(see the Jan 2009 freebsd-net@ thread "Bacula: VERY SLOW on SAME host" 
for some details).




Anyone know if there is a fix in the offing?


Qing (added to CC) is aware of the problem. Not sure how far off the fix is.

Cheers,
Lawrence
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: kern/132734: panic in net/if_mib.c

[Alexey Illarionov]

The following reply was made to PR kern/132734; it has been noted by GNATS.

From: Alexey Illarionov 
To: Mikolaj Golub 
Cc: bug-follo...@freebsd.org, Robert Watson 
Subject: Re: kern/132734: panic in net/if_mib.c
Date: Mon, 04 May 2009 20:00:17 +0400

 Hi
 
 Mikolaj Golub wrote:
 > So, Alexey, can you try upgrading to the latest stable/7 or releng/7.2 or
 > apply attached patch to see if this tweak at least eliminates the instant
 > panic?
 
 With this patch this panic does not repeat any more.
 There are some error messages in log files:
 snmpd: sysctl linkmib estimate (ng1): No such file or directory.
 But kernel does not panics. Thanks.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

TCP analysis, research and debugging tools: SIFTR v1.2.1 released

[Lawrence Stewart]

Hi All,

I'm very pleased to announce the release of a significantly improved
version of our SIFTR (Statistical Information For TCP Research) tool
for FreeBSD. It can be obtained from [1], along with other papers,
patches and software useful for protocol analysis, debugging and
experimental research.

SIFTR is a loadable kernel module supporting FreeBSD 6.2+ that logs a
range of statistics on active TCP connections to a log file. It provides
the ability to make highly granular, event-driven measurements of TCP
connection state. More details are available in the readme and changelog
available at [1].

Work on SIFTR v1.2.0 and v1.2.1 has been sponsored by the FreeBSD
Foundation [2] as part of the "Enhancing the FreeBSD TCP Implementation"
project [3]. SIFTR development prior to v1.2.0 was supported in part by
a grant from the Cisco University Research Program Fund at Community
Foundation Silicon Valley.

SIFTR's functionality will be merged into the FreeBSD base system in one
of the next steps in this project, and will hopefully ship with FreeBSD 8.0.

Cheers,
Lawrence

http://caia.swin.edu.au



[1] http://caia.swin.edu.au/urp/newtcp/tools.html

[2] http://www.freebsdfoundation.org/

[3] http://caia.swin.edu.au/freebsd/etcp09/


___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: Freebsd failed to create routing prefix

[Hiroki Sato]

Rommel Laranjo  wrote
  in :

rs> Hello Hiroki-san,
rs>
rs> The box I am using is FreeBSD 7.0-Release:
rs>
rs> # uname -a
rs> FreeBSD freebsd7.example.com 7.0-RELEASE FreeBSD 7.0-RELEASE #0: Sun
rs> Feb 24 19:59:52 UTC 2008
rs> r...@logan.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  i386

 Oh, really?  So maybe 7.0R has the same problem.  I will try to
 reproduce the symptom on my box.

--
| Hiroki SATO


pgpxmCik6m9d1.pgp
Description: PGP signature

Re: Filesystem and bigger files

[Andrew Snow]

Antonio Tommasi wrote:

Filesystem   SizeUsed   AvailCapacity  Mounted on
/dev/aacd0s1a  64G15G 44G 26%/
In a directory (spamassassin) i've one file (auto-whitelist) with 
dimension 4.0 TB and one file (bayes_learn) with dimension 1.0TB


How is it possible? How this file are managed?



Spamassassin uses sparse files.

http://en.wikipedia.org/wiki/Sparse_file

Try running "du" on the files instead of "ls -l".


- Andrew
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: kern/134157: [dummynet] dummynet loads cpu for 100% and make a system frozen and unstable [regression]

[Andrey Golenischev]

The following reply was made to PR kern/134157; it has been noted by GNATS.

From: Andrey Golenischev 
To: Oleg Bulyzhin 
Cc: bug-follo...@freebsd.org
Subject: Re: kern/134157: [dummynet] dummynet loads cpu for 100% and make a 
system frozen and unstable [regression]
Date: Tue, 5 May 2009 00:02:44 +0300

 --0016e6dbe6dcd8bd0d04691c7b92
 Content-Type: text/plain; charset=KOI8-R
 Content-Transfer-Encoding: base64
 
 WWVzIGknbSB1c2luZyBtcGQgKHRyaWVkIHdpdGggbXBkNCBhbmQgbXBkNS4gVHJpZWQgdGhpcyBv
 biBzZXZlcmFsIFBDJ3MgLQp0aGUgc2FtZSBwcm9ibGVtIDooIElmIGkgaGF2ZSAzMC01MCBvbmxp
 bmUgdXNlcnMgLSBpdCBpcyBvay4gMTAwKyAtIGR1bW15bmV0CjEwMCUgbG9hZHMgYW5kIHNlcnZl
 ciBiZWNvbWUgdW5zdGFibGUvZnJlZXppbmcuCgpuZXQuaW5ldC5pcC5mdy5vbmVfcGFzczogMQpu
 ZXQuaXNyLmRpcmVjdDogMQoKCk9uIE1vbiwgTWF5IDQsIDIwMDkgYXQgNjowOSBQTSwgT2xlZyBC
 dWx5emhpbiA8b2xlZ0BmcmVlYnNkLm9yZz4gd3JvdGU6Cgo+Cj4gRmV3IG1vcmUgcXVlc3Rpb25z
 Ogo+IDEpIEFyZSB5b3UgdXNpbmcgbXBkPyBEaWQgeW91IHVwZ3JhZGUgaXQgYWxvbmcgd2l0aCBz
 eXN0ZW0/IEhhdmUgeW91IHRyaWVkCj4gdG8gdXNlIG1wZDQ/IChpZiB5b3UgaGF2ZSBwcm9ibGVt
 IHdpdGggbXBkNSkKPiAyKSBwbGVhc2Ugc2hvdyBtZSB2YWx1ZXMgb2YgZm9sbG93aW5nIHN5c2N0
 bDoKPiBuZXQuaW5ldC5pcC5mdy5vbmVfcGFzcwo+IG5ldC5pc3IuZGlyZWN0Cj4KPiAtLQo+IE9s
 ZWcuCj4KPiA9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
 PT09PT09PT09PT09PT09Cj4gPT09IE9sZWcgQnVseXpoaW4gLS0gT0JVTC1SSVBOIC0tIE9CVUwt
 UklQRSAtLSBvbGVnQHJpbmV0LnJ1ID09PQo+ID09PT09PT09PT09PT09PT09PT09PT09PT09PT09
 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KPgo+CgoKLS0gCi0tLS0K8yDV18HW
 xc7Jxc0sIOHOxNLFygo=
 --0016e6dbe6dcd8bd0d04691c7b92
 Content-Type: text/html; charset=KOI8-R
 Content-Transfer-Encoding: quoted-printable
 
 Yes i'm using mpd (tried with mpd4 and mpd5. Tried this on several PC&#=
 39;s - the same problem :( If i have 30-50 online users - it is ok. 100+ - =
 dummynet 100% loads and server become unstable/freezing.net.inet.ip=
 .fw.one_pass: 1
 net.isr.direct: 1On Mon, May 4, 2009=
  at 6:09 PM, Oleg Bulyzhin o...@freebsd.org> wrote:
 
 Few more questions:
 1) Are you using mpd? Did you upgrade it along with system? Have you tried<=
 br>
 to use mpd4? (if you have problem with mpd5)
 2) please show me values of following sysctl:
 net.inet.ip.fw.one_pass
 net.isr.direct
 
 --
 Oleg.
 
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 =3D=3D=3D Oleg Bulyzhin -- OBUL-RIPN -- OBUL-RIPE -- mailto:oleg=
 @rinet.ru">o...@rinet.ru =3D=3D=3D
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 
 -- =F3=
  =D5=D7=C1=D6=C5=CE=C9=C5=CD, =E1=CE=C4=D2=C5=CA
 
 --0016e6dbe6dcd8bd0d04691c7b92--
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: CARP as a module; followup thoughts

[Will Andrews]

On Mon, May 4, 2009 at 10:04 AM, Bruce Simpson  wrote:
> I'll have to take your word for that as I'm not using CARP just at the
> moment. I had to touch the mcast setup for the IPv6 SSM implementation. All
> compiles OK, but I haven't tested the code other than loading it. Only IPv6
> multicast group setup should be affected.
>
> Does your patch apply against these revisions OK?

It should.  I am using git to develop these patches.  I just did
another sync (to r191794) and the diff from svn to my local git branch
is the same as the patch I posted last night, so I presume it will
apply to a fresh svn checkout of -current as of that revision.

> Great stuff.
> Can this bug fix be merged separately, i.e. before other code is committed?
> That way it can get merged back to -STABLE more quickly, once RELENG_7 is
> unfrozen.

Yes, I can generate a separate patch for that one.  If I were able to
commit it myself, I'd certainly be doing it the way you suggest.  I'd
also suggest a more aggressive MFC timing for the free() bug fix than
for the module feature (perhaps 3 days vs. 1-2 months, as 7.2R is now
out).  I am going to backport this patch to RELENG_7.  Because of the
way it is implemented, I believe it should be safe to MFC.

> It would be good to have a more general code path for stuff like this to
> benefit from using the perfect hash filters in modern NICs, the main thing
> is that everything continues to work with no regressions :-)
>
> Thanks for the effort you've put into this, it will certainly help a lot of
> folk to be able to ship a CARP-capable GENERIC kernel.

Indeed, regressions will be difficult to prevent.  I'm planning to
work on virtual lladdrs for a bit to see if I can find a suitable
solution for the problem.  If nothing else, I think it provides a
reasonable method for getting rid of carp_forus(), and possibly for
implementing carpdev.

Thanks,
--Will.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Awful forwarding rate [7.2-Release, igb]

[Oleg Baranov]

Hello!

I have extremely low forwarding speed on 7.2-Release box with dual Intel 
82575.


Box "B" with dual 82575 nic is connected between A and C using gigabit 
swithes

A <---> B <> C


iperf run from A to C shows:

$ iperf -w 128k -c 192.168.111.3


Client connecting to 192.168.111.3, TCP port 5001
TCP window size:   129 KByte (WARNING: requested   128 KByte)

[  3] local 192.168.1.15 port 51077 connected with 192.168.111.3 port 5001
[ ID] Interval   Transfer Bandwidth
[  3]  0.0-11.2 sec160 KBytes117 Kbits/sec



the same run from A to B shows:

]$ iperf -w 128k -c 192.168.1.153

Client connecting to 192.168.1.153, TCP port 5001
TCP window size:   129 KByte (WARNING: requested   128 KByte)

[  3] local 192.168.1.15 port 60907 connected with 192.168.1.153 port 5001
[ ID] Interval   Transfer Bandwidth
[  3]  0.0-10.0 sec  1.09 GBytes933 Mbits/sec


and from B to C shows:

$ iperf -w 128k -c 192.168.111.3

Client connecting to 192.168.111.3, TCP port 5001
TCP window size:   129 KByte (WARNING: requested   128 KByte)

[  3] local 192.168.111.254 port 64290 connected with 192.168.111.3 port 
5001

[ ID] Interval   Transfer Bandwidth
[  3]  0.0-10.0 sec  1.08 GBytes930 Mbits/sec


Boxes B and C are both dual quad-core e5420 CPUs on Supermicro X7DWN+ 
motherboard.
As A I tried several machines including dual quad-core Phenom system as 
well as some portable PCs and workstations residing in the same LAN.


Here is ifconfig from B

$ ifconfig
igb0: flags=8843 metric 0 mtu 1500
   options=19b
   ether 00:30:48:c8:19:66
   inet 192.168.1.153 netmask 0xff00 broadcast 192.168.1.255
   media: Ethernet autoselect (1000baseTX )
   status: active
igb1: flags=8843 metric 0 mtu 1500
   options=19b
   ether 00:30:48:c8:19:67
   media: Ethernet autoselect (1000baseTX )
   status: active
   lagg: laggdev lagg0
lo0: flags=8049 metric 0 mtu 16384
   inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3
   inet6 ::1 prefixlen 128
   inet 127.0.0.1 netmask 0xff00
lagg0: flags=8843 metric 0 mtu 1500
   options=19b
   ether 00:30:48:c8:19:67
   inet 192.168.111.254 netmask 0xff00 broadcast 192.168.111.255
   media: Ethernet autoselect
   status: active
   laggproto lacp
   laggport: igb1 flags=1c
gif0: flags=8051 metric 0 mtu 1280
   tunnel inet 192.168.1.153 --> 192.168.1.156
   inet 192.168.111.254 --> 192.168.112.254 netmask 0x


I tried to remove lagg & gif interfaces, boot GENERIC kernel and even 
set up same net config from LiveFS cd - nothing helps. Forwarding speed 
sometimes goes up to 1-2 Mbit/sec while local speeds are always above 
900Mbit.

System load is less 1%, logs contain nothing interesting...

Any clues and ideas would be appreciated



___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: Awful forwarding rate [7.2-Release, igb]

[Jack Vogel]

Turn off LRO, its on by default, you can do it with sysctl, be sure to
down and up the interface.

In FreeBSD 8 this will be automagic but for 7.2 its manual.

Jack


On Mon, May 4, 2009 at 3:47 PM, Oleg Baranov  wrote:

> Hello!
>
> I have extremely low forwarding speed on 7.2-Release box with dual Intel
> 82575.
>
> Box "B" with dual 82575 nic is connected between A and C using gigabit
> swithes
> A <---> B <> C
>
>
> iperf run from A to C shows:
>
> $ iperf -w 128k -c 192.168.111.3
>  
> Client connecting to 192.168.111.3, TCP port 5001
> TCP window size:   129 KByte (WARNING: requested   128 KByte)
> 
> [  3] local 192.168.1.15 port 51077 connected with 192.168.111.3 port 5001
> [ ID] Interval   Transfer Bandwidth
> [  3]  0.0-11.2 sec160 KBytes117 Kbits/sec
>
>
>
> the same run from A to B shows:
>
> ]$ iperf -w 128k -c 192.168.1.153
> 
> Client connecting to 192.168.1.153, TCP port 5001
> TCP window size:   129 KByte (WARNING: requested   128 KByte)
> 
> [  3] local 192.168.1.15 port 60907 connected with 192.168.1.153 port 5001
> [ ID] Interval   Transfer Bandwidth
> [  3]  0.0-10.0 sec  1.09 GBytes933 Mbits/sec
>
>
> and from B to C shows:
>
> $ iperf -w 128k -c 192.168.111.3
> 
> Client connecting to 192.168.111.3, TCP port 5001
> TCP window size:   129 KByte (WARNING: requested   128 KByte)
> 
> [  3] local 192.168.111.254 port 64290 connected with 192.168.111.3 port
> 5001
> [ ID] Interval   Transfer Bandwidth
> [  3]  0.0-10.0 sec  1.08 GBytes930 Mbits/sec
>
>
> Boxes B and C are both dual quad-core e5420 CPUs on Supermicro X7DWN+
> motherboard.
> As A I tried several machines including dual quad-core Phenom system as
> well as some portable PCs and workstations residing in the same LAN.
>
> Here is ifconfig from B
>
> $ ifconfig
> igb0: flags=8843 metric 0 mtu 1500
>   options=19b
>   ether 00:30:48:c8:19:66
>   inet 192.168.1.153 netmask 0xff00 broadcast 192.168.1.255
>   media: Ethernet autoselect (1000baseTX )
>   status: active
> igb1: flags=8843 metric 0 mtu 1500
>   options=19b
>   ether 00:30:48:c8:19:67
>   media: Ethernet autoselect (1000baseTX )
>   status: active
>   lagg: laggdev lagg0
> lo0: flags=8049 metric 0 mtu 16384
>   inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3
>   inet6 ::1 prefixlen 128
>   inet 127.0.0.1 netmask 0xff00
> lagg0: flags=8843 metric 0 mtu 1500
>   options=19b
>   ether 00:30:48:c8:19:67
>   inet 192.168.111.254 netmask 0xff00 broadcast 192.168.111.255
>   media: Ethernet autoselect
>   status: active
>   laggproto lacp
>   laggport: igb1 flags=1c
> gif0: flags=8051 metric 0 mtu 1280
>   tunnel inet 192.168.1.153 --> 192.168.1.156
>   inet 192.168.111.254 --> 192.168.112.254 netmask 0x
>
>
> I tried to remove lagg & gif interfaces, boot GENERIC kernel and even set
> up same net config from LiveFS cd - nothing helps. Forwarding speed
> sometimes goes up to 1-2 Mbit/sec while local speeds are always above
> 900Mbit.
> System load is less 1%, logs contain nothing interesting...
>
> Any clues and ideas would be appreciated
>
>
>
> ___
> freebsd-net@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
>
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"