dummynet damages ICMPv6 packets
Hello, we are experiencing interesing behaviour of dummynet enabled on IPv6 interfaces. When the following rules are added: add pipe 24 ip from any to any in recv vlan1 add pipe 25 ip from any to any out xmit vlan1 all ICMPv6 packets passing on vlan1 are being damaged: 10:55:53.180801 IP6 fe80::215:17ff:feae:4d99 > ff02::1: ip-proto-64 16 0x: 6000 0010 403a fe80 `.@: 0x0010: 0215 17ff feae 4d99 ff02 ..M. 0x0020: 0001 8000 2dc9 31f2 002e ..-.1... 0x0030: 4eb7 ab29 0002 c207 N..) Please note invalid protocol shown by tcpdump and shifted bytes at offset 7 and 8 (it reads 0x403a but should be 0x3a40). After changing dummynet rule to: add pipe 24 ip4 from any to any in recv vlan1 add pipe 25 ip4 from any to any out xmit vlan1 packets are no longer malformed: 11:01:49.934348 IP6 fe80::215:17ff:feae:4d99 > ff02::1: ICMP6, echo request, seq 0, length 16 0x: 6000 0010 3a40 fe80 `.:@ 0x0010: 0215 17ff feae 4d99 ff02 ..M. 0x0020: 0001 8000 ab9a 3341 3A.. 0x0030: 4eb7 ac8d 000e 41a5 N.A. The above problem affects 8.2-STABLE compiled on 3rd May 2011. ___ 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
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/162201 net[ip] [patch] multicast forwarding cache hash always al o kern/162153 net[em] intel em driver 7.2.4 don't compile o kern/162110 net[igb] [panic] RELENG_9 panics on boot in IGB driver - o kern/162028 net[ixgbe] [patch] misplaced #endif in ixgbe.c o kern/161908 net[netgraph] [patch] ng_vlan update for QinQ support o kern/161899 net[route] ntpd(8): Repeating RTM_MISS packets causing hi o kern/161381 net[re] RTL8169SC - re0: PHY write failed o kern/161277 net[em] [patch] BMC cannot receive IPMI traffic after loa o kern/160873 net[igb] igb(4) from HEAD fails to build on 7-STABLE o kern/160750 netIntel PRO/1000 connection breaks under load until rebo o kern/160693 net[gif] [em] Multicast packet are not passed from GIF0 t o kern/160420 net[msk] phy write timeout on HP 5310m o kern/160293 net[ieee80211] ppanic] kernel panic during network setup o kern/160206 net[gif] gifX stops working after a while (IPv6 tunnel) o kern/159817 net[udp] write UDPv4: No buffer space available (code=55) o kern/159795 net[tcp] excessive duplicate ACKs and TCP session freezes o kern/159629 net[ipsec] [panic] kernel panic with IPsec in transport m o kern/159621 net[tcp] [panic] panic: soabort: so_count o kern/159603 net[netinet] [patch] in_ifscrubprefix() - network route c o kern/159601 net[netinet] [patch] in_scrubprefix() - loopback route re o kern/159294 net[em] em watchdog timeouts o kern/159203 net[wpi] Intel 3945ABG Wireless LAN not support IBSS o kern/158930 net[bpf] BPF element leak in ifp->bpf_if->bif_dlist o kern/158726 net[ip6] [patch] ICMPv6 Router Announcement flooding limi o kern/158694 net[ix] [lagg] ix0 is not working within lagg(4) o kern/158665 net[ip6] [panic] kernel pagefault in in6_setscope() o kern/158635 net[em] TSO breaks BPF packet captures with em driver f kern/157802 net[dummynet] [panic] kernel panic in dummynet o kern/157785 netamd64 + jail + ipfw + natd = very slow outbound traffi o kern/157429 net[re] Realtek RTL8169 doesn't work with re(4) o kern/157418 net[em] em driver lockup during boot on Supermicro X9SCM- o kern/157410 net[ip6] IPv6 Router Advertisements Cause Excessive CPU U o kern/157287 net[re] [panic] INVARIANTS panic (Memory modified after f o kern/157209 net[ip6] [patch] locking error in rip6_input() (sys/netin o kern/157200 net[network.subr] [patch] stf(4) can not communicate betw o kern/157182 net[lagg] lagg interface not working together with epair o kern/156877 net[dummynet] [panic] dummynet move_pkt() null ptr derefe o kern/156667 net[em] em0 fails to init on CURRENT after March 17 o kern/156408 net[vlan] Routing failure when using VLANs vs. Physical e o kern/156328 net[icmp]: host can ping other subnet but no have IP from o kern/156317 net[ip6] Wrong order of IPv6 NS DAD/MLD Report o kern/156283 net[ip6] [patch] nd6_ns_input - rtalloc_mpath does not re o kern/156279 net[if_bridge][divert][ipfw] unable to correctly re-injec o kern/156226 net[lagg]: failover does not announce the failover to swi o kern/156030 net[ip6] [panic] Crash in nd6_dad_start() due to null ptr o kern/155772 netifconfig(8): ioctl (SIOCAIFADDR): File exists on direc o kern/155680 net[multicast] problems with multicast s kern/155642 net[request] Add driver for Realtek RTL8191SE/RTL8192SE W o kern/155604 net[flowtable] Flowtable excessively caches dest MAC addr o kern/155597 net[panic] Kernel panics with "sbdrop" message o kern/155420 net[vlan] adding vlan break existent vlan o kern/155177 net[route] [panic] Panic when inject routes in kernel o kern/155030 net[igb] igb(4) DEVICE_POLLING does not work with carp(4) o kern/155010 net[msk] ntfs-3g via iscsi using msk driver cause kernel o kern/155004 net[bce] [panic] kernel panic in bce0 driver o kern/154943 net[gif] ifconfig gifX create on existing gifX clears IP s kern/154851 net[request]: Port brcm80211 driver from Linux to FreeBSD o kern/154850 net[netgraph] [patch] ng_ether fails to name nodes when t o kern/154679 net[em] Fatal trap 12: "em1 taskq" only at startup (8.1-R o kern/154600 net[tcp] [panic] Random kernel panics o
Re[2]: kern/155585: [tcp] [panic] tcp_output tcp_mtudisc loop until kernel panic
Hi. I updated system to r227141:227142M and tried patch. 6 hours uptime right now. Bug looks fixed. 02 ноября 2011, 21:01 от Andrey Zonov : > The following reply was made to PR kern/155585; it has been noted by GNATS. > > From: Andrey Zonov > To: bug-follo...@freebsd.org, samsp...@mail.ru > Cc: > Subject: Re: kern/155585: [tcp] [panic] tcp_output tcp_mtudisc loop until > kernel panic > Date: Wed, 02 Nov 2011 20:54:15 +0400 > > This is a multi-part message in MIME format. > --040501090905060606010708 > Content-Type: text/plain; charset=UTF-8; format=flowed > Content-Transfer-Encoding: 7bit > > Hi Andrey, > > Please try attached patch. > > I think the same problem was resolved here [1]. > > [1] http://svnweb.freebsd.org/base?view=revision&revision=178029 > > -- > Andrey Zonov > > --040501090905060606010708 > Content-Type: text/plain; > name="patch-tcp_output.c.txt" > Content-Transfer-Encoding: base64 > Content-Disposition: attachment; > filename="patch-tcp_output.c.txt" > > SW5kZXg6IHN5cy9uZXRpbmV0L3RjcF9vdXRwdXQuYwo9PT09PT09PT09PT09PT09PT09PT09 > PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzeXMv > bmV0aW5ldC90Y3Bfb3V0cHV0LmMJKHJldmlzaW9uIDIyNzAyMCkKKysrIHN5cy9uZXRpbmV0 > L3RjcF9vdXRwdXQuYwkod29ya2luZyBjb3B5KQpAQCAtMTc3LDggKzE3Nyw5IEBACiAJaW50 > IGlkbGUsIHNlbmRhbG90OwogCWludCBzYWNrX3J4bWl0LCBzYWNrX2J5dGVzX3J4bXQ7CiAJ > c3RydWN0IHNhY2tob2xlICpwOwotCWludCB0c287CisJaW50IHRzbywgbXR1LCBvZmZlcjsK > IAlzdHJ1Y3QgdGNwb3B0IHRvOworCXN0cnVjdCByb3V0ZSBybzsKICNpZiAwCiAJaW50IG1h > eGJ1cnN0ID0gVENQX01BWEJVUlNUOwogI2VuZGlmCkBAIC0yMTgsNiArMjE5LDcgQEAKIAkJ > dGNwX3NhY2tfYWRqdXN0KHRwKTsKIAlzZW5kYWxvdCA9IDA7CiAJdHNvID0gMDsKKwltdHUg > PSAwOwogCW9mZiA9IHRwLT5zbmRfbnh0IC0gdHAtPnNuZF91bmE7CiAJc2VuZHdpbiA9IG1p > bih0cC0+c25kX3duZCwgdHAtPnNuZF9jd25kKTsKIApAQCAtMTIzMSw5ICsxMjMzLDE2IEBA > CiAJaWYgKFZfcGF0aF9tdHVfZGlzY292ZXJ5ICYmIHRwLT50X21heG9wZCA+IFZfdGNwX21p > bm1zcykKIAkJaXAtPmlwX29mZiB8PSBJUF9ERjsKIAotCWVycm9yID0gaXBfb3V0cHV0KG0s > IHRwLT50X2lucGNiLT5pbnBfb3B0aW9ucywgTlVMTCwKKwliemVybygmcm8sIHNpemVvZihy > bykpOworCisJZXJyb3IgPSBpcF9vdXRwdXQobSwgdHAtPnRfaW5wY2ItPmlucF9vcHRpb25z > LCAmcm8sCiAJICAgICgoc28tPnNvX29wdGlvbnMgJiBTT19ET05UUk9VVEUpID8gSVBfUk9V > VEVUT0lGIDogMCksIDAsCiAJICAgIHRwLT50X2lucGNiKTsKKworCWlmIChlcnJvciA9PSBF > TVNHU0laRSAmJiByby5yb19ydCkKKwkJbXR1ID0gcm8ucm9fcnQtPnJ0X3JteC5ybXhfbXR1 > OworCWlmIChyby5yb19ydCkKKwkJUlRGUkVFKHJvLnJvX3J0KTsKICAgICB9CiAjZW5kaWYg > LyogSU5FVCAqLwogCWlmIChlcnJvcikgewpAQCAtMTI3OSwyMiArMTI4OCwyMCBAQAogCQkJ > LyoKIAkJCSAqIEZvciBzb21lIHJlYXNvbiB0aGUgaW50ZXJmYWNlIHdlIHVzZWQgaW5pdGlh > bGx5CiAJCQkgKiB0byBzZW5kIHNlZ21lbnRzIGNoYW5nZWQgdG8gYW5vdGhlciBvciBsb3dl > cmVkCi0JCQkgKiBpdHMgTVRVLgotCQkJICoKLQkJCSAqIHRjcF9tdHVkaXNjKCkgd2lsbCBm > aW5kIG91dCB0aGUgbmV3IE1UVSBhbmQgYXMKLQkJCSAqIGl0cyBsYXN0IGFjdGlvbiwgaW5p > dGlhdGUgcmV0cmFuc21pc3Npb24sIHNvIGl0Ci0JCQkgKiBpcyBpbXBvcnRhbnQgdG8gbm90 > IGRvIHNvIGhlcmUuCi0JCQkgKgotCQkJICogSWYgVFNPIHdhcyBhY3RpdmUgd2UgZWl0aGVy > IGdvdCBhbiBpbnRlcmZhY2UKLQkJCSAqIHdpdGhvdXQgVFNPIGNhcGFiaWxpdHMgb3IgVFNP > IHdhcyB0dXJuZWQgb2ZmLgotCQkJICogRGlzYWJsZSBpdCBmb3IgdGhpcyBjb25uZWN0aW9u > IGFzIHRvbyBhbmQKLQkJCSAqIGltbWVkaWF0bHkgcmV0cnkgd2l0aCBNU1Mgc2l6ZWQgc2Vn > bWVudHMgZ2VuZXJhdGVkCi0JCQkgKiBieSB0aGlzIGZ1bmN0aW9uLgorCQkJICogaXRzIE1U > VS4gVXBkYXRlIHRfbWF4b3BkIGFuZCB0X21heHNlZyB0aHJvdWdoCisJCQkgKiB0Y3BfbXNz > X3VwZGF0ZSgpIGFuZCB0cnkgdG8gc2VuZCBkYXRhIGFnYWluLgogCQkJICovCi0JCQlpZiAo > dHNvKQotCQkJCXRwLT50X2ZsYWdzICY9IH5URl9UU087Ci0JCQl0Y3BfbXR1ZGlzYyh0cC0+ > dF9pbnBjYiwgMCk7Ci0JCQlyZXR1cm4gKDApOworCQkJaWYgKG10dSAhPSAwKSB7CisJCQkJ > b2ZmZXIgPSBtdHUgLSBoZHJsZW47CisJCQkJaWYgKCh0cC0+dF9mbGFncyAmIFRGX1JDVkRf > VFNUTVApID09IFRGX1JDVkRfVFNUTVApCisJCQkJCW9mZmVyICs9IFRDUE9MRU5fVFNUQU1Q > X0FQUEE7CisJCQkJdGNwX21zc191cGRhdGUodHAsIG9mZmVyLCBOVUxMLCBOVUxMKTsKKwkJ > CQlnb3RvIGFnYWluOworCQkJfQorCQkJLyoKKwkJCSAqIFRoaXMgaXMgdGhlIGJlc3Qgd2Ug > Y2FuIGRvIGhlcmUuCisJCQkgKi8KKwkJCXJldHVybiAoZXJyb3IpOwogCQljYXNlIEVIT1NU > RE9XTjoKIAkJY2FzZSBFSE9TVFVOUkVBQ0g6CiAJCWNhc2UgRU5FVERPV046Cg== > --040501090905060606010708-- > ___ > 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"
Re[2]: PCI-E VT6130 NIC (if_vge) hang system with gigabit link
02 ноября 2011, 06:07 от YongHyeon PYUN : > If there is no cabling issue there, please try attached patch and > let me know whether the patch makes any difference on you. > > Thanks. > I tried patch. Now automatic connection can't established. In dmesg vge0: MII read timed out ___ 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"
Possible MROUTING regression in 9.0 RC1
Hello! I have problems with ip_mroute (loaded as module) - kernel multicast packet forwarder. I have 2 disk: freebsd 8.2 release amd64 on first and freebsd 9.0 rc1 on second. I use net/igmpproxy to watch IPTV on my home atom-based router. On FreeBSD 8.2 it works good. But when I try to use FreeBSD 9.0 RC-1 in same role (with same configs, of cource) I have messages like: Nov 7 16:16:46 timp igmpproxy[35495]: received packet from 172.16.254.1 shorter (28 bytes) than hdr+data length (20+28) Nov 7 16:16:47 timp igmpproxy[35495]: received packet from 172.16.254.1 shorter (32 bytes) than hdr+data length (24+32) Nov 7 16:17:28 timp igmpproxy[35495]: received packet from 10.85.13.5 shorter (28 bytes) than hdr+data length (20+28) And IPTV doesn't work =( Any ideas? Do you need configs? ___ 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: Undocumented netgraph `cmd' flags ?
On Mon, Oct 31, 2011 at 10:31:25PM -0700, Julian Elischer wrote: J> NGM_HASREPLY is not used that I can see in the kernel. It may be a J> historical artifact or J> maybe only used in the library as a hint. I introduced NGM_HASREPLY. Yes, it is used in library, to make repliable messages synchronous, as they were in RELENG_4. Applications like mpd rely on that fact. -- Totus tuus, Glebius. ___ 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: mbuf leak in icmp6 code??
Kristof, On Thu, Nov 03, 2011 at 01:07:52PM +0100, Kristof Provost wrote: K> > For example: K> > K> > icmp6_input calls icmp6_redirect_input and right after it returns it K> > makes m=NULL. Inside icmp6_redirect_input there are checks for ifp and K> > for the message being short (which probably don't get exercised that K> > often (or at all?)) and for these checks simply return. Looks to be K> > mbuf leak. In other icmp6 functions also we have similar instances. K> K> The checks for m and ifp should probably be asserts, rather than just K> returns. I think they are always supposed to be true. I've checked all callers, and it looks like m and m->pkthdr.rcvif can be safely asserted. I've committed that change. -- Totus tuus, Glebius. ___ 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"
Panic in the udp_input() under heavy load
Hi Gang,
We are seeing repeatable panics under high PPS load on our production
systems. It happens when the traffic gets into the range or 200MBps and
150-200K PPS. We have been managed to track it down to the following
piece of code:
(gdb) l *udp_input+0x5d2
0x806f6202 is in udp_input (/usr/src/sys/netinet/udp_usrreq.c:628).
623 if (inp->inp_ip_minttl && inp->inp_ip_minttl > ip->ip_ttl) {
624 INP_RUNLOCK(inp);
625 goto badunlocked;
626 }
627 up = intoudpcb(inp);
628 if (up->u_tun_func == NULL) {
629 udp_append(inp, ip, m, iphlen + sizeof(struct
udphdr), &udp_in);
630 } else {
631 /*
632 * Engage the tunneling protocol.
The faulty line appears to be 628, with up value is being NULL, attempt
to deference it causes NULL pointer exception. I believe this particular
piece of code has been introduced here:
---
Author: bz
Date: Thu Aug 13 15:16:30 2009
New Revision: 196192
URL: http://svn.freebsd.org/changeset/base/196192
Log:
MFC: r192649
Implement UDP control block support.
Add udpcb support with own fields and flags for UDP instead
of further sticking things into in_pcb and flags fields.
Attach the udpcb to the inp_ppcb in the kernel.
Note: the udp tunneling parts are not (yet) existing in 7
and thus were not merged.
Reviewed by: rwatson
---
The screenshot of the panic message is attached. This is pretty recent
8.2-STABLE. Any help is greatly appreciated. This particular bug has
haunted us for at least 4-5 months now.
Thanks!
-Maxim
___
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 9-RC1, openbgpd, tcp md5
On Nov 4, 2011, at 1:41 PM, Patrick Lamaiziere wrote: > Isn't a new option to build openbgpd with tcp-md5 (and without pf_key)? > > I've used TCP-MD5 signature for bgp between a FreeBSD 8.x and OpenBSD, > using setkey(8) to enforce the signature between the peers. That > worked (of course, then you shouldn't use tcp-md5 in openbgd). > > setkey(8): > add -4 peer1 peer2 tcp 0x1000 -A tcp-md5 "PASSWORD"; > add -4 peer2 peer1 tcp 0x1000 -A tcp-md5 "PASSWORD"; Ouch! Silly me, I assumed there was some setsockopt() option to set an MD5 for a TCP socket. Thank you very much, working now both with both bird and openbgpd. :) Turns out you have to delete the md5 option from the openbgpd config file, but you need to put it (even with a bogus key) in the bird config file. add 10.0.0.1 10.0.0.2 tcp 0x1000 -A tcp-md5 "mekmitasgoat"; add 10.0.1.1 10.0.1.2 tcp 0x1000 -A tcp-md5 "mekmitasgoat"; add 10.0.0.2 10.0.0.1 tcp 0x1000 -A tcp-md5 "mekmitasgoat"; add 10.0.1.2 10.0.1.1 tcp 0x1000 -A tcp-md5 "mekmitasgoat"; Borja. ___ 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: Panic in the udp_input() under heavy load
Panic screenshot is here: http://sobomax.sippysoft.com/ScreenShot859.png -Maxim ___ 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: Intel 82574L interface wedging on em 7.1.9/7.2.3 when MSIX enabled
On Mon, Oct 31, 2011 at 1:13 AM, Hooman Fazaeli wrote:
>
> Attached is a patch for if_em.c. It flushes interface queue when it is
> full
> and link is not active. Please note that when this happens, drops are
> increasing
> on interface and this will trigger your scripts as before. You need to
> change
> a little the scripts as follows:
>
> check interface TX status
> if (interface TX seems hung) {
> sleep 5
> check interface TX status
> if (interface TX seems hung) {
> reset the interface.
> }
> }
>
> For MULTIQUEUE, it just disables the check for link status (which is not
> good).
> so pls. test in non-MULTIQUEUE mode.
>
> The patch also contains some minor fixups to compile on 7 plus
> a fix from r1.69 which addressed RX hang problem (the fix was
> later removed in r1.70). I included it for Emil to give it a
> try.
>
> Pls. let me know if you have any problems with patch.
>
>
Hooman,
Unfortunately one of the server just had a wedge event a couple hours ago
with this patch. To confirm your changes should cause a recovery within
the time I'm allowing, here is the current format:
check interface TX status
if (interface TX seems hung) {
sleep 3
check packets out
sleep 2
check packets out
if (packets not incrementing) {
reset the interface
}
}
I bounced em0 because dropped packets incremented 1749543 to 1749708 and
the interface is not incrementing packets out.
4:10AM up 6 days, 15:23, 0 users, load averages: 0.02, 0.12, 0.14
em0: flags=8843 metric 0 mtu 1500
options=219b
ether X
inet6 X%em0 prefixlen 64 scopeid 0x1
nd6 options=1
media: Ethernet autoselect (1000baseT )
status: active
em1: flags=8843 metric 0 mtu 1500
options=219b
ether X
inet6 X%em1 prefixlen 64 scopeid 0x2
nd6 options=3
media: Ethernet autoselect (1000baseT )
status: active
ipfw0: flags=8801 metric 0 mtu 65536
lo0: flags=8049 metric 0 mtu 16384
options=3
inet 127.0.0.1 netmask 0xff00
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4
inet X.X.X.X netmask 0x
inet X.X.X.X netmask 0x
inet X.X.X.X netmask 0x
nd6 options=3
lagg0: flags=8843 metric 0 mtu 1500
options=219b
ether X
inet X.X.X.X netmask 0xff00 broadcast X.X.X.X
inet6 X%lagg0 prefixlen 64 scopeid 0x5
inet6 X prefixlen 64 autoconf
nd6 options=3
media: Ethernet autoselect
status: active
laggproto loadbalance
laggport: em0 flags=4
laggport: em1 flags=4
interrupt total rate
irq3: uart1 3810 0
cpu0: timer 1147568087 2000
irq256: em0:rx 0 59779710 104
irq257: em0:tx 0 2771888652 4831
irq258: em0:link 1 0
irq259: em1:rx 0 3736828886 6512
irq260: em1:tx 0 2790566376 4863
irq261: em1:link 27286 0
irq262: mps0 395687386 689
cpu1: timer 1147559894 2000
cpu2: timer 1147559901 2000
cpu3: timer 1147559902 2000
Total 14345029891 25001
13466/4144/17610 mbufs in use (current/cache/total)
2567/2635/5202/5853720 mbuf clusters in use (current/cache/total/max)
2567/633 mbuf+clusters out of packet secondary zone in use (current/cache)
6798/554/7352/2926859 4k (page size) jumbo clusters in use
(current/cache/total/max)
0/0/0/6400 9k jumbo clusters in use (current/cache/total/max)
0/0/0/3200 16k jumbo clusters in use (current/cache/total/max)
35692K/8522K/44214K bytes allocated to network (current/cache/total)
0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters)
0/0/0 requests for jumbo clusters denied (4k/9k/16k)
0/0/0 sfbufs in use (current/peak/max)
0 requests for sfbufs denied
0 requests for sfbufs delayed
0 requests for I/O initiated by sendfile
0 calls to protocol drain routines
Name Mtu Network Address Ipkts Ierrs Idrop Opkts Oerrs Coll Drop
em0 1500 00:25:90:2b:e5:75 60747643 0 0 11246408092 0 0 1750763
em0 1500 fe80:1::225:9 fe80:1::225:90ff: 0 - - 4 - - -
em1 1500 00:25:90:2b:e5:75 11237195776 123950 0 11344722383 0 0
545682
em1 1500 fe80:2::225:9 fe80:2::225:90ff: 0 - - 1 - - -
lagg0 1500 00:25:90:2b:e5:75 11297850142 0 0 22588666102 2296445 0
0
lagg0 1500 69.164.38.0/2 69.164.38.83 10189108030 - - 22592881776 - - -
lagg0 1500 fe80:5::225:9 fe80:5::225:90ff: 24 - - 28 - - -
lagg0 1500 2607:f4e8:310 2607:f4e8:310:12: 19578 - - 19591 - - -
kern.msgbuf:
Nov 7 04:10:06 cds1033 kernel: Interface is RUNNING and INACTIVE
Nov 7 04:10:06 cds1033 kernel: em0: hw tdh = 558, hw tdt = 558
Nov 7 04:10:06 cds1033 kernel: em0: hw rdh = 889, hw rdt = 888
Nov 7 04:10:06 cds1033 kernel: em0: Tx Queue Status = 0
Nov 7 04:10:06 cds1033 kernel: em0: TX descriptors avail = 1024
Nov 7 04:10:06 cds1033 kernel: em0: Tx Descriptors avail failure = 0
Nov 7 04:10:06 cds1033 kernel: em0: RX discarded packets = 0
Nov 7 04:10:06 cds1033 kernel: em0: RX Next to Check = 889
Nov 7 04:10:06 cds1033 kernel: em0: RX Next to Refresh = 888
Nov 7 04:10:06 cds1033 kernel: em0: Link state: active
Nov 7 04:10:06 cds1033 kernel: Interface is RUNNING and INACTIVE
Nov
Re: Gigabit Ethernet performance with Realtek 8111E
On Sun, Nov 06, 2011 at 03:40:54PM -0800, YongHyeon PYUN wrote: > On Sat, Nov 05, 2011 at 12:53:23PM +0100, Michael La?? wrote: > > Hi! > > > > I've got a small NAS with Intel D525MW (Atom) board inside using FreeBSD > > 9.0-RC1 as operating system. It has an onboard Realtek 8111E ethernet > > adapter. I'm experiencing heavy performance problems when transfering > > files from a specific PC in my network to that NAS. I did the following > > tests by transfering large amount of data between the diferrent machines > > (using dd and nc): > > > > NAS -> Linux1:~ 400Mbit/s > > NAS -> Linux2:~ 400Mbit/s > > Linux1 -> NAS:heavy fluctuation, between 700Mbit/s and 0bit/s > > Linux2 -> NAS:~ 400Mbit/s > > Linux1 -> Linux2: ~ 400Mbit/s > > Linux2 -> Linux1: ~ 400Mbit/s > > > > As you can see everythink works fine except for transfering data from > > Linux1 to that NAS box. The following graph shows the problem: > > http://dl.dropbox.com/u/25455527/network-problems.png > > > > While the transfer rate drops to zero the NAS also has a very bad ping > > up to one second. Ping of Linux1 is perfectly fine during these outages. > > > > I also had a quick look on the data stream with wireshark on Linux1 and > > it shows a lot of TCP Dup ACK (up to 263 Dup ACKs created by NAS for one > > frame). > > > > What can be eliminated as a cause is: > > - Switch (I tried connecting Linux1 and NAS directly) > > - Cable (I changed that a few times) > > - Harddisk I/O (I'm only writing from /dev/zero to /dev/null) > > > > The sevirity of that problem varies from one minute to another but can > > always be reproduced with a few tries. > > > > When limiting either NAS or Linux1 to 100Mbit I'm getting a steady > > transfer rate of about 90Mbit/s. > > Some revisions of RealTek controller have FIFO overrun issue but > I'm not sure whether you're seeing the issue. Try enabling flow > control and see whether that makes any difference. You can enable > it by issuing 'ifconfig re0 media flow'. This should be read as 'ifconfig re0 mediaopt flow'. > > > When decreasing the MTU on NAS to 1200 the problem seems to disappear, > > getting a transfer rate of about 160Mbit/s. > > > > ifconfig re0: > > > re0: flags=8843 metric 0 mtu 1500 > > > > > > options=388b > > > ether 38:60:77:3e:af:a5 > > > inet 192.168.178.54 netmask 0xff00 broadcast 192.168.178.255 > > > nd6 options=29 > > > media: Ethernet autoselect (1000baseT ) > > > status: active > > > > pciconf -lv: > > > re0@pci0:1:0:0: class=0x02 card=0xd6258086 chip=0x816810ec rev=0x06 > > > hdr=0x00 > > > vendor = 'Realtek Semiconductor Co., Ltd.' > > > device = 'RTL8111/8168B PCI Express Gigabit Ethernet controller' > > > class = network > > > subclass = ethernet > > > > Show me the dmesg output. RealTek uses the same device PCI ids so it's > impossible to know which controller you have from the pciconf(8) > output. > > > Because Linux1 seems to be involved in that problem: It's running Linux > > 3.0 and it has an "Atheros Communications AR8121/AR8113/AR8114" onboard. > > > > Does anyone have an idea what could be the problem here? Decreasing the > > MTU is some kind of solution but the performance is still not optimal > > and a MTU of 1500 should be no problem. > > > > Greetings, > > Michael Laß ___ 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: Panic in the udp_input() under heavy load
On Mon, 7 Nov 2011, Maxim Sobolev wrote:
Hi Gang,
We are seeing repeatable panics under high PPS load on our production
systems. It happens when the traffic gets into the range or 200MBps and
150-200K PPS. We have been managed to track it down to the following piece of
code:
(gdb) l *udp_input+0x5d2
0x806f6202 is in udp_input (/usr/src/sys/netinet/udp_usrreq.c:628).
623 if (inp->inp_ip_minttl && inp->inp_ip_minttl > ip->ip_ttl) {
624 INP_RUNLOCK(inp);
625 goto badunlocked;
626 }
627 up = intoudpcb(inp);
628 if (up->u_tun_func == NULL) {
629 udp_append(inp, ip, m, iphlen + sizeof(struct
udphdr), &udp_in);
630 } else {
631 /*
632 * Engage the tunneling protocol.
The faulty line appears to be 628, with up value is being NULL, attempt to
deference it causes NULL pointer exception. I believe this particular piece
of code has been introduced here:
Unlikely; the inp is properly locked there and the udp info attach
better still be valid there; your problem is most likely elsewhere;
try to see if you have other threads and see what they do at the same
time, etc. You would need to race with udp_detach(); you also want
to make sure that the inp still looks sane from either ddb or a dump
and we are not talking about random memory corruption here.
/bz
--
Bjoern A. Zeeb You have to have visions!
Stop bit received. Insert coin for new address family.
___
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/162352: [patch] Enhancement: add SO_PROTO to socket.h
Old Synopsis: Enhancement: New Synopsis: [patch] Enhancement: add SO_PROTO to socket.h Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Nov 7 21:18:58 UTC 2011 Responsible-Changed-Why: reclassify. http://www.freebsd.org/cgi/query-pr.cgi?pr=162352 ___ 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: Multiqueue support for bpf
Hi, Probably my previous mail had been skipped or forgot replying, so I'd like to try notice again. # This is original post of this thread, if you don't remember what is this: http://lists.freebsd.org/pipermail/freebsd-net/2011-August/029585.html George said "I think we should try to integrate this work and then tune it up more. in previous mail, then I want to merge this now. Is there any additional work required to merge, or just fine? 2011/9/22 Takuya ASADA : > Sorry for late replying, > >> One comment, one question. >> >> First, I think we should try to integrate this work and then tune it up >> more. The API >> is, I think, fine, and performance tuning takes a bit of work. > > Is there good way(I mean tools or something) to find the bottleneck? > >> Second, what are the parameters set on buffers for the drivers? I.e. how >> many slots >> do they have in their queues etc.? If they defaults are too small, and >> often they are, >> then that's going to hurt your performance. > > It does equals to number of descriptors per queue, right? > If I'm correct, it's 2048 descriptors per queue by default, and I used > default parameter when I perform benchmarks. > > It's on line 290 of > http://p4db.freebsd.org/fileViewer.cgi?FSPC=//depot/projects/soc2011/mq_bpf/src/sys/dev/ixgbe/ixgbe.c&REV=2 > > and line 105 of > http://p4db.freebsd.org/fileViewer.cgi?FSPC=//depot/projects/soc2011/mq_bpf/src/sys/dev/ixgbe/ixgbe.h&REV=2 > ___ 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: Panic in the udp_input() under heavy load
On 11/7/2011 10:24 AM, Bjoern A. Zeeb wrote: Unlikely; the inp is properly locked there and the udp info attach better still be valid there; your problem is most likely elsewhere; try to see if you have other threads and see what they do at the same time, etc. You would need to race with udp_detach(); you also want to make sure that the inp still looks sane from either ddb or a dump and we are not talking about random memory corruption here. Well, as you can see from the trace it points pretty strongly to that piece of code. And as I said this panic is completely reproducible, we've seen it at least 5 times to date in exactly this location. Unfortunately the trace is rather long so we could not capture it in full before, until we've switched to the 80x50 mode. If it was a memory corruption it would be just random fault, while here we have it failing in this point reliably. Unfortunately the panic happens in the driver thread context (I believe), so the KDB/dump is not working. After panicing the machine just hangs there. Keyboard is not working and I need to do a hard reset. Is there any other explanation that you can think of? Is it possible for some other portion of the code (i.e. network driver, DMA engine etc) to trash this structure by writing something off bound? Or something along the lines? Thanks! Regards, -- Maksym Sobolyev Sippy Software, Inc. Internet Telephony (VoIP) Experts Tel: +1-646-651-1110 Fax: +1-866-857-6942 Web: http://www.sippysoft.com MSN: sa...@sippysoft.com Skype: SippySoft ___ 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: Panic in the udp_input() under heavy load
On 11/7/2011 2:57 PM, Maxim Sobolev wrote:
On 11/7/2011 10:24 AM, Bjoern A. Zeeb wrote:
Unlikely; the inp is properly locked there and the udp info attach
better still be valid there; your problem is most likely elsewhere;
try to see if you have other threads and see what they do at the same
time, etc. You would need to race with udp_detach(); you also want
to make sure that the inp still looks sane from either ddb or a dump
and we are not talking about random memory corruption here.
Well, as you can see from the trace it points pretty strongly to that
piece of code. And as I said this panic is completely reproducible,
we've seen it at least 5 times to date in exactly this location.
Unfortunately the trace is rather long so we could not capture it in
full before, until we've switched to the 80x50 mode.
If it was a memory corruption it would be just random fault, while here
we have it failing in this point reliably.
Unfortunately the panic happens in the driver thread context (I
believe), so the KDB/dump is not working. After panicing the machine
just hangs there. Keyboard is not working and I need to do a hard reset.
Is there any other explanation that you can think of? Is it possible for
some other portion of the code (i.e. network driver, DMA engine etc) to
trash this structure by writing something off bound? Or something along
the lines?
OK, I've put the following catch to prove the case:
up = intoudpcb(inp);
if (up == NULL) {
printf("BZZT! Something is terribly wrong, up == NULL!\n");
INP_RUNLOCK(inp);
goto badunlocked;
}
if (up->u_tun_func == NULL) {
I am going to give it a spin on two busiest boxes and see if I can log
anything.
Regards,
--
Maksym Sobolyev
Sippy Software, Inc.
Internet Telephony (VoIP) Experts
Tel: +1-646-651-1110
Fax: +1-866-857-6942
Web: http://www.sippysoft.com
MSN: sa...@sippysoft.com
Skype: SippySoft
___
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: Panic in the udp_input() under heavy load
On Mon, 7 Nov 2011, Maxim Sobolev wrote:
On 11/7/2011 2:57 PM, Maxim Sobolev wrote:
On 11/7/2011 10:24 AM, Bjoern A. Zeeb wrote:
Unlikely; the inp is properly locked there and the udp info attach
better still be valid there; your problem is most likely elsewhere;
try to see if you have other threads and see what they do at the same
time, etc. You would need to race with udp_detach(); you also want
to make sure that the inp still looks sane from either ddb or a dump
and we are not talking about random memory corruption here.
Well, as you can see from the trace it points pretty strongly to that
piece of code. And as I said this panic is completely reproducible,
we've seen it at least 5 times to date in exactly this location.
Unfortunately the trace is rather long so we could not capture it in
full before, until we've switched to the 80x50 mode.
If it was a memory corruption it would be just random fault, while here
we have it failing in this point reliably.
Unfortunately the panic happens in the driver thread context (I
believe), so the KDB/dump is not working. After panicing the machine
just hangs there. Keyboard is not working and I need to do a hard reset.
Is there any other explanation that you can think of? Is it possible for
some other portion of the code (i.e. network driver, DMA engine etc) to
trash this structure by writing something off bound? Or something along
the lines?
OK, I've put the following catch to prove the case:
up = intoudpcb(inp);
if (up == NULL) {
printf("BZZT! Something is terribly wrong, up == NULL!\n");
INP_RUNLOCK(inp);
goto badunlocked;
}
if (up->u_tun_func == NULL) {
I am going to give it a spin on two busiest boxes and see if I can log
anything.
Now if you are clever you'd also log the inp there as the above will
only prove the case that something is wrong but still not help us in
anything to figure out what.
/bz
--
Bjoern A. Zeeb You have to have visions!
Stop bit received. Insert coin for new address family.
___
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: Panic in the udp_input() under heavy load
On 11/7/2011 3:25 PM, Bjoern A. Zeeb wrote:
Now if you are clever you'd also log the inp there as the above will
only prove the case that something is wrong but still not help us in
anything to figure out what.
Good point, thank you Sir.
Would that be good enough?
printf("BZZT! Something is terribly wrong, up == NULL! inp = %p\n", inp);
Do you think of any other useful piece of information that I can log at
this point?
-Maxim
___
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: Panic in the udp_input() under heavy load
On Mon, 7 Nov 2011, Maxim Sobolev wrote:
On 11/7/2011 3:25 PM, Bjoern A. Zeeb wrote:
Now if you are clever you'd also log the inp there as the above will only
prove the case that something is wrong but still not help us in anything to
figure out what.
Good point, thank you Sir.
Would that be good enough?
printf("BZZT! Something is terribly wrong, up == NULL! inp = %p\n", inp);
Do you think of any other useful piece of information that I can log at this
point?
Hi Maxim:
There was recently a commit to fix a race condition in 10-CURRENT which I
think is not slated to be merged for 9.0. You might check the commit logs
there and see if that fixes the problems you have -- if so, we might want to
reconsider the plan not to merge for 9.0.
(It relates to a race condition on closing sockets..)
Robert
___
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"
