From owner-freebsd-net@FreeBSD.ORG Sun Nov 7 06:32:54 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ECCB11065674; Sun, 7 Nov 2010 06:32:54 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) by mx1.freebsd.org (Postfix) with ESMTP id AA9CD8FC17; Sun, 7 Nov 2010 06:32:54 +0000 (UTC) Received: from lawrence1.loshell.room52.net (ppp59-167-184-191.static.internode.on.net [59.167.184.191]) by lauren.room52.net (Postfix) with ESMTPSA id 9EE507E84A; Sun, 7 Nov 2010 17:32:52 +1100 (EST) Message-ID: <4CD64814.2000906@freebsd.org> Date: Sun, 07 Nov 2010 17:32:52 +1100 From: Lawrence Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-AU; rv:1.9.2.9) Gecko/20101006 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: Andre Oppermann References: <20100512124702.GJ2679@rambler-co.ru> <20100713140051.GV99657@mdounin.ru> <4C5BCE48.5070504@freebsd.org> <20100913172453.GG99657@mdounin.ru> <20100927081217.GM44164@mdounin.ru> <4CA09987.8020205@freebsd.org> <20101102001134.GP44164@mdounin.ru> <4CD090EF.4020402@freebsd.org> In-Reply-To: <4CD090EF.4020402@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on lauren.room52.net Cc: freebsd-net@freebsd.org, Igor Sysoev , Maxim Dounin Subject: Re: net.inet.tcp.slowstart_flightsize in 8-STABLE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Nov 2010 06:32:55 -0000 On 11/03/10 09:30, Andre Oppermann wrote: > On 02.11.2010 01:11, Maxim Dounin wrote: >> Hello! >> >> On Mon, Sep 27, 2010 at 03:17:59PM +0200, Andre Oppermann wrote: >> >>> On 27.09.2010 10:12, Maxim Dounin wrote: >>>> Hello! >>>> >>>> On Mon, Sep 13, 2010 at 09:24:53PM +0400, Maxim Dounin wrote: >>>> >>>> [...] >>>> >>>>> Andre, could you please take a look at one more patch as well? >>>>> >>>>> Igor reported that it still sees 100ms delays with rfc3465 turned >>>>> on, and it turns out to be similar issue (setting cwnd to 1*MSS) >>>>> for hosts found in hostcache. >>>>> >>>>> The problem with setting cwnd from hostcache was already reported >>>>> here: >>>>> >>>>> http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/92690 >>>>> http://lists.freebsd.org/pipermail/freebsd-net/2007-July/014780.html >>>>> >>>>> As using larger cwnd from hostcache may cause problems on >>>>> congested links (see second thread) I changed code to only use >>>>> cached cwnd as an upper bound for cwnd (instead of fixing current >>>>> code). This is also in-line with what we do on connection >>>>> restarts. >>>>> >>>>> We may later consider re-adding usage of larger cwnd from >>>>> hostcache. But I believe it should be done carefully and >>>>> probably behind sysctl, off by default. >>>> >>>> Ping. >>> >>> Thanks for the reminder. I'll disable priming CWND from hostcache. >> >> Ping again. >> >> I would like to see the patch in question[1] committed and MFC'ed >> somewhere before 8.2. >> >> Andre, if you are just too busy to do it yourself - please say so, >> I'll ask somebody else to commit it. > > Thanks for the reminder. After EuroBSDCon Developer Summit I was > busy with other work and most of my tcp work was stalled due to > review bandwidth issues. Sorry for the review bandwidth issues. I'm only just managing to keep my head above water at the moment and have had to reduce much of my FreeBSD work to a trickle. > Lawrence, could you please spare a few seconds and take a quick look > at the attached patch? The patch looks fine, please commit. I hope to give the hostcache some TLC at some point, but in the meantime it's fine to ignore cached cwnd. Cheers, Lawrence From owner-freebsd-net@FreeBSD.ORG Sun Nov 7 20:32:47 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 26771106564A for ; Sun, 7 Nov 2010 20:32:47 +0000 (UTC) (envelope-from avf@eldamar.org.uk) Received: from sigurdson.opencodes.org (sigurdson.opencodes.org [217.14.120.28]) by mx1.freebsd.org (Postfix) with ESMTP id DC3B58FC14 for ; Sun, 7 Nov 2010 20:32:46 +0000 (UTC) Received: by sigurdson.opencodes.org (Postfix, from userid 1001) id 99A0E940FC; Sun, 7 Nov 2010 21:12:48 +0100 (CET) Date: Sun, 7 Nov 2010 21:12:48 +0100 From: Alexander Frolkin To: freebsd-net@freebsd.org Message-ID: <20101107201248.GH4221@eldamar.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-GPG-Key-Fingerprint: 7820 960F C361 C9CE 401F D07D 993A 2951 D970 4FA4 X-Operating-System: Linux 2.6.24-21-server X-Editor: Vi X-Uptime: 21:14:07 up 15 days, 6:22, 6 users, load average: 2.49, 2.42, 2.40 User-Agent: Mutt/1.5.17+20080114 (2008-01-14) Subject: How to disable syncookies & syncache X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Nov 2010 20:32:47 -0000 Hi, I posted this to questions@ this morning, but the only response I got was to try re-posting it here, so here goes... I spent all day yesterday trying to get my FreeBSD box (8.1-RELEASE, amd64) to talk to a Qlogic 4010 iSCSI card. The problem is that when the Qlogic card tries to make a connection, FreeBSD resets it (SYN, SYN|ACK, ACK, RST). If I turn on net.inet.tcp.log_in_vain, I can see a message similar to TCP: [172.16.25.2]:30557 to [172.16.25.1]:3260 tcpflags 0x10; syncache_expand: TSECR 0 != TS 267223, segment rejected for each connection attempt. I've tried fiddling around with the net.inet.tcp.syn* sysctls, but all I've managed to to is change the message to TCP: [172.16.25.2]:29387 to [172.16.25.1]:3260 tcpflags 0x10; syncache_expand: Segment failed SYNCOOKIE authentication, segment rejected (probably spoofed) (this was with net.inet.tcp.syncookies_only=1, I believe) --- the connection still gets reset, as before. The only "solution" I've found so far is to comment out the bit of code in sys/netinet/tcp_syncache.c that checks if TSECR == TS, but needless to say, this is horrible, and will probably create other problems. Now, I know what you're probably going to say --- the Qlogic card has a broken TCP implementation. While that may well be true, this is the card I have and I'm stuck with it, so there's not much I can about that. Any suggestions welcome. :-) Thanks! Alex -- -----------------------< Alexander Frolkin >----------------------- -----< avf@eldamar.org.uk >-----< http://www.eldamar.org.uk/ >----- ``I can't believe it. You actually found a practical use for geometry!'' -- Bart Simpson, ``Dead Putting Society'' From owner-freebsd-net@FreeBSD.ORG Mon Nov 8 11:07:01 2010 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E7F0110656BF for ; Mon, 8 Nov 2010 11:07:01 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id D42CF8FC14 for ; Mon, 8 Nov 2010 11:07:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id oA8B71Qr088155 for ; Mon, 8 Nov 2010 11:07:01 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id oA8B71Nt088153 for freebsd-net@FreeBSD.org; Mon, 8 Nov 2010 11:07:01 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 8 Nov 2010 11:07:01 GMT Message-Id: <201011081107.oA8B71Nt088153@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Nov 2010 11:07:02 -0000 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/151690 net network connectivity won't work until dhclient is run o kern/151681 net [nfs] NFS mount via IPv6 leads to hang on client with o kern/151593 net [igb] [panic] Kernel panic when bringing up igb networ o kern/150920 net [ixgbe][igb] Panic when packets are dropped with heade o kern/150557 net [igb] igb0: Watchdog timeout -- resetting o kern/150251 net [patch] [ixgbe] Late cable insertion broken o kern/150249 net [ixgbe] Media type detection broken o kern/150247 net [patch] [ixgbe] Version in -current won't build on 7.x o bin/150224 net ppp(8) does not reassign static IP after kill -KILL co o kern/150148 net [ath] Atheros 5424/2424 - AR2425 stopped working with o kern/150052 net [wi] wi(4) driver does not work with wlan(4) driver fo f kern/149969 net [wlan] [ral] ralink rt2661 fails to maintain connectio o kern/149937 net [ipfilter] [patch] kernel panic in ipfilter IP fragmen o kern/149786 net [bwn] bwn on Dell Inspiron 1150: connections stall o kern/149643 net [rum] device not sending proper beacon frames in ap mo o kern/149609 net [panic] reboot after adding second default route o kern/149539 net [ath] atheros ar9287 is not supported by ath_hal o kern/149516 net [ath] ath(4) hostap with fake MAC/BSSID results in sta o kern/149373 net [realtek/atheros]: None of my network card working o kern/149307 net [ath] Doesn't work Atheros 9285 o kern/149306 net [alc] Doesn't work Atheros AR8131 PCIe Gigabit Etherne o kern/149117 net [inet] [patch] in_pcbbind: redundant test o kern/149086 net [multicast] Generic multicast join failure in 8.1 o kern/148862 net [panic] page fault while in kernel mode at _mtx_lock_s o kern/148322 net [ath] Triggering atheros wifi beacon misses in hostap o kern/148317 net [ath] FreeBSD 7.x hostap memory leak in net80211 or At o kern/148078 net [ath] wireless networking stops functioning o kern/147894 net [ipsec] IPv6-in-IPv4 does not work inside an ESP-only o kern/147862 net [wpi] Possible bug in the wpi driver. Network Manager o kern/147155 net [ip6] setfb not work with ipv6 o kern/146845 net [libc] close(2) returns error 54 (connection reset by o kern/146792 net [flowtable] flowcleaner 100% cpu's core load o kern/146759 net [cxgb] [patch] cxgb panic calling cxgb_set_lro() witho o kern/146719 net [pf] [panic] PF or dumynet kernel panic o kern/146534 net [icmp6] wrong source address in echo reply o kern/146517 net [ath] [wlan] device timeouts for ath wlan device on re o kern/146427 net [mwl] Additional virtual access points don't work on m o kern/146426 net [mwl] 802.11n rates not possible on mwl o kern/146425 net [mwl] mwl dropping all packets during and after high u f kern/146394 net [vlan] IP source address for outgoing connections o bin/146377 net [ppp] [tun] Interface doesn't clear addresses when PPP o kern/146358 net [vlan] wrong destination MAC address o kern/146165 net [wlan] [panic] Setting bssid in adhoc mode causes pani o kern/146082 net [ng_l2tp] a false invaliant check was performed in ng_ o kern/146037 net [panic] mpd + CoA = kernel panic o bin/145934 net [patch] add count option to netstat(1) o kern/145826 net [ath] Unable to configure adhoc mode on ath0/wlan0 o kern/145825 net [panic] panic: soabort: so_count o kern/145777 net [wpi] Intel 3945ABG driver breaks the connection after o kern/145728 net [lagg] Stops working lagg between two servers. o amd64/145654 net amd64-curent memory leak in kernel o kern/144987 net [wpi] [panic] injecting packets with wlaninject using o kern/144882 net MacBookPro =>4.1 does not connect to BSD in hostap wit o kern/144874 net [if_bridge] [patch] if_bridge frees mbuf after pfil ho o conf/144700 net [rc.d] async dhclient breaks stuff for too many people o kern/144642 net [rum] [panic] Enabling rum interface causes panic o kern/144616 net [nat] [panic] ip_nat panic FreeBSD 7.2 o kern/144572 net [carp] CARP preemption mode traffic partially goes to f kern/144315 net [ipfw] [panic] freebsd 8-stable reboot after add ipfw o kern/143939 net [ipfw] [em] ipfw nat and em interface rxcsum problem o kern/143874 net [wpi] Wireless 3945ABG error. wpi0 could not allocate o kern/143868 net [ath] [patch] [request] allow Atheros watchdog timeout o kern/143846 net [gif] bringing gif3 tunnel down causes gif0 tunnel to s kern/143673 net [stf] [request] there should be a way to support multi s kern/143666 net [ip6] [request] PMTU black hole detection not implemen o kern/143622 net [pfil] [patch] unlock pfil lock while calling firewall o kern/143595 net [wpi] [panic] Creating virtual interface over wpi0 in o kern/143593 net [ipsec] When using IPSec, tcpdump doesn't show outgoin o kern/143591 net [ral] RT2561C-based DLink card (DWL-510) fails to work o kern/143208 net [ipsec] [gif] IPSec over gif interface not working o conf/143079 net hostapd(8) startup missing multi wlan functionality o kern/143074 net [wi]: wi driver triggers panic o kern/143034 net [panic] system reboots itself in tcp code [regression] o kern/142907 net [wpi] if_wpi unstable on ibm/lenovo x60 -- suspect fir o kern/142877 net [hang] network-related repeatable 8.0-STABLE hard hang o kern/142774 net Problem with outgoing connections on interface with mu o kern/142772 net [libc] lla_lookup: new lle malloc failed o kern/142018 net [iwi] [patch] Possibly wrong interpretation of beacon- o kern/141861 net [wi] data garbled with WEP and wi(4) with Prism 2.5 o kern/141777 net [rum] [patch] Support usbdevs / rum(4) for Buffalo WLI f kern/141741 net Etherlink III NIC won't work after upgrade to FBSD 8, o kern/141023 net [carp] CARP arp replays with wrong src mac o kern/140796 net [ath] [panic] privileged instruction fault o kern/140742 net rum(4) Two asus-WL167G adapters cannot talk to each ot o kern/140682 net [netgraph] [panic] random panic in netgraph o kern/140634 net [vlan] destroying if_lagg interface with if_vlan membe o kern/140619 net [ifnet] [patch] refine obsolete if_var.h comments desc o kern/140564 net [wpi] Problem with Intel(R) PRO/Wireless 3945ABG o kern/140346 net [wlan] High bandwidth use causes loss of wlan connecti o kern/140245 net [ath] [panic] Kernel panic during network activity on o kern/140142 net [ip6] [panic] FreeBSD 7.2-amd64 panic w/IPv6 o kern/140066 net [bwi] install report for 8.0 RC 2 (multiple problems) o kern/139565 net [ipfilter] ipfilter ioctl SIOCDELST broken o kern/139387 net [ipsec] Wrong lenth of PF_KEY messages in promiscuous o bin/139346 net [patch] arp(8) add option to remove static entries lis o kern/139268 net [if_bridge] [patch] allow if_bridge to forward just VL o kern/139204 net [arp] DHCP server replies rejected, ARP entry lost bef o kern/139117 net [lagg] + wlan boot timing (EBUSY) o kern/139079 net [wpi] Failure to attach wpi(4) o kern/139058 net [ipfilter] mbuf cluster leak on FreeBSD 7.2 o kern/138850 net [dummynet] dummynet doesn't work correctly on a bridge o kern/138782 net [panic] sbflush_internal: cc 0 || mb 0xffffff004127b00 o kern/138739 net [wpi] wpi(4) does not work very well under 8.0-BETA4 o amd64/138688 net [rum] possibly broken on 8 Beta 4 amd64: able to wpa a o kern/138678 net [lo] FreeBSD does not assign linklocal address to loop o kern/138620 net [lagg] [patch] lagg port bpf-writes blocked o kern/138427 net [wpi] [panic] Kernel panic after trying set monitor wl o kern/138407 net [gre] gre(4) interface does not come up after reboot o kern/138332 net [tun] [lor] ifconfig tun0 destroy causes LOR if_adata/ o kern/138266 net [panic] kernel panic when udp benchmark test used as r o kern/138177 net [ipfilter] FreeBSD crashing repeatedly in ip_nat.c:257 o kern/137881 net [netgraph] [panic] ng_pppoe fatal trap 12 o bin/137841 net [patch] wpa_supplicant(8) cannot verify SHA256 signed o kern/137776 net [rum] panic in rum(4) driver on 8.0-BETA2 o kern/137775 net [netgraph] [patch] Add XMIT_FAILOVER to ng_one2many o bin/137641 net ifconfig(8): various problems with "vlan_device.vlan_i o kern/137592 net [ath] panic - 7-STABLE (Aug 7, 2009 UTC) crashes on ne o bin/137484 net [patch] Integer overflow in wpa_supplicant(8) base64 e o kern/137392 net [ip] [panic] crash in ip_nat.c line 2577 o kern/137372 net [ral] FreeBSD doesn't support wireless interface from o kern/137089 net [lagg] lagg falsely triggers IPv6 duplicate address de o bin/136994 net [patch] ifconfig(8) print carp mac address o kern/136943 net [wpi] [lor] wpi0_com_lock / wpi0 o kern/136911 net [netgraph] [panic] system panic on kldload ng_bpf.ko t o kern/136836 net [ath] atheros card stops functioning after about 12 ho o bin/136661 net [patch] ndp(8) ignores -f option o kern/136618 net [pf][stf] panic on cloning interface without unit numb o kern/136426 net [panic] spawning several dhclients in parallel panics o kern/135502 net [periodic] Warning message raised by rtfree function i o kern/134931 net [route] Route messages sent to all socket listeners re o kern/134583 net [hang] Machine with jail freezes after random amount o o kern/134531 net [route] [panic] kernel crash related to routes/zebra 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/133969 net [dummynet] [panic] Fatal trap 12: page fault while in o kern/133968 net [dummynet] [panic] dummynet kernel panic 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/133235 net [netinet] [patch] Process SIOCDLIFADDR command incorre o kern/133218 net [carp] [hang] use of carp(4) causes system to freeze f kern/133213 net arp and sshd errors on 7.1-PRERELEASE o kern/133060 net [ipsec] [pfsync] [panic] Kernel panic with ipsec + pfs 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 [patch] rc.conf(5): allow to setfib(1) for service run 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/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/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 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 net ifconfig(8) can't clear 'monitor' mode on the wireless o bin/131365 net route(8): route add changes interpretation of network 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 f 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/129517 net [ipsec] [panic] double fault / stack overflow o kern/129508 net [carp] [panic] Kernel panic with EtherIP (may be relat o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129197 net [panic] 7.0 IP stack related panic o bin/128954 net ifconfig(8) deletes valid routes o kern/128917 net [wpi] [panic] if_wpi and wpa+tkip causing kernel panic o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o conf/128334 net [request] use wpa_cli in the "WPA DHCP" situation o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net [arp] arp: Segmentation fault (core dumped) f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/127102 net [wpi] Intel 3945ABG low throughput o kern/127057 net [udp] Unable to send UDP packet via IPv6 socket to IPv o kern/127050 net [carp] ipv6 does not work on carp interfaces [regressi o kern/126945 net [carp] CARP interface destruction with ifconfig destro o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o kern/126714 net [carp] CARP interface renaming makes system no longer o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126475 net [ath] [panic] ath pcmcia card inevitably panics under o kern/126339 net [ipw] ipw driver drops the connection o kern/126214 net [ath] txpower problem with Atheros wifi card o kern/126075 net [inet] [patch] internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125816 net [carp] [if_bridge] carp stuck in init when using bridg o kern/125721 net [ath] Terrible throughput/high ping latency with Ubiqu o kern/125617 net [ath] [panic] ath(4) related panic f kern/125502 net [ral] ifconfig ral0 scan produces no output unless in o kern/125501 net [ath] atheros cardbus driver hangs f kern/125332 net [ath] [panic] crash under any non-tiny networking unde o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre o kern/124767 net [iwi] Wireless connection using iwi0 driver (Intel 220 o kern/124753 net [ieee80211] net80211 discards power-save queue packets o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124225 net [ndis] [patch] ndis network driver sometimes loses net o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. o kern/123892 net [tap] [patch] No buffer space available o kern/123890 net [ppp] [panic] crash & reboot on work with PPP low-spee o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o kern/123758 net [panic] panic while restarting net/freenet6 o bin/123633 net ifconfig(8) doesn't set inet and ether address in one o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o kern/123429 net [nfe] [hang] "ifconfig nfe up" causes a hard system lo o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123256 net [wpi] panic: blockable sleep lock with wpi(4) o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices f kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122697 net [ath] Atheros card is not well supported o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup ieee o bin/121895 net [patch] rtsol(8)/rtsold(8) doesn't handle managed netw o kern/121872 net [wpi] driver fails to attach on a fujitsu-siemens s711 s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121706 net [netinet] [patch] "rtfree: 0xc4383870 has 1 refs" emit o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121443 net [gif] [lor] icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o bin/121359 net [patch] [security] ppp(8): fix local stack overflow in o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/120966 net [rum] kernel panic with if_rum and WPA encryption p docs/120945 net [patch] ip6(4) man page lacks documentation for TCLASS o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [udp] [panic] gnugk causes kernel panic when closing U o kern/120130 net [carp] [panic] carp causes kernel panics in any conste o bin/120060 net routed(8) deletes link-level routes in the presence of o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o kern/118727 net [netgraph] [patch] [request] add new ng_pf module s kern/117717 net [panic] Kernel panic with Bittorrent client. o kern/117448 net [carp] 6.2 kernel crash [regression] o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o kern/116747 net [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/115019 net [netgraph] ng_ether upper hook packet flow stops on ad o kern/115002 net [wi] if_wi timeout. failed allocation (busy bit). ifco o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o kern/113432 net [ucom] WARNING: attempt to net_add_domain(netgraph) af o kern/112722 net [ipsec] [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/111457 net [ral] ral(4) freeze o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o kern/109308 net [pppd] [panic] Multiple panics kernel ppp suspected [r o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/107944 net [wi] [patch] Forget to unlock mutex-locks f kern/107279 net [ath] [panic] ath_start: attempted use of a free mbuf! o conf/107035 net [patch] bridge(8): bridge interface given in rc.conf n o kern/106444 net [netgraph] [panic] Kernel Panic on Binding to an ip to o kern/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/105945 net Address can disappear from network interface s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] f kern/105348 net [ath] ath device stopps TX o kern/104851 net [inet6] [patch] On link routes not configured when usi o kern/104751 net [netgraph] kernel panic, when getting info about my tr o kern/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac o kern/102540 net [netgraph] [patch] supporting vlan(4) by ng_fec(4) o conf/102502 net [netgraph] [patch] ifconfig name does't rename netgrap o kern/102035 net [plip] plip networking disables parallel port printing o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau o kern/100709 net [libc] getaddrinfo(3) should return TTL info o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/98597 net [inet6] Bug in FreeBSD 6.1 IPv6 link-local DAD procedu o bin/98218 net wpa_supplicant(8) blacklist not working f bin/97392 net ppp(8) hangs instead terminating o kern/97306 net [netgraph] NG_L2TP locks after connection with failed f kern/96268 net [socket] TCP socket performance drops by 3000% if pack o kern/95519 net [ral] ral0 could not map mbuf o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear f kern/93886 net [ath] Atheros/D-Link DWL-G650 long delay to associate f kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/93019 net [ppp] ppp and tunX problems: no traffic after restarti o kern/92880 net [libc] [patch] almost rewritten inet_network(3) functi s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu o kern/91859 net [ndis] if_ndis does not work with Asus WL-138 s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging s kern/90086 net [hang] 5.4p8 on supermicro P8SCT hangs during boot if o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/87421 net [netgraph] [panic]: ng_ether + ng_eiface + if_bridge s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/86871 net [tcp] [patch] allocation logic for PCBs in TIME_WAIT s o kern/86427 net [lor] Deadlock with FASTIPSEC and nat o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter o kern/85780 net 'panic: bogus refcnt 0' in routing/ipv6 o bin/85445 net ifconfig(8): deprecated keyword to ifconfig inoperativ o bin/82975 net route change does not parse classfull network as given o kern/82881 net [netgraph] [panic] ng_fec(4) causes kernel panic after o bin/82185 net [patch] ndp(8) can delete the incorrect entry o kern/81095 net IPsec connection stops working if associated network i o kern/79895 net [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph o bin/79228 net [patch] extend arp(8) to be able to create blackhole r o kern/78968 net FreeBSD freezes on mbufs exhaustion (network interface o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if o kern/77341 net [ip6] problems with IPV6 implementation o kern/77273 net [ipf] ipfilter breaks ipv6 statefull filtering on 5.3 s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/75873 net Usability problem with non-RFC-compliant IP spoof prot s kern/75407 net [an] an(4): no carrier after short time a kern/71474 net [route] route lookup does not skip interfaces marked d o kern/71469 net default route to internet magically disappears with mu o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/66225 net [netgraph] [patch] extend ng_eiface(4) control message o kern/65616 net IPSEC can't detunnel GRE packets after real ESP encryp s kern/60293 net [patch] FreeBSD arp poison patch a kern/56233 net IPsec tunnel (ESP) over IPv6: MTU computation is wrong o kern/54383 net [nfs] [patch] NFS root configurations without dynamic s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr s kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". o kern/31647 net [libc] socket calls can return undocumented EINVAL o kern/30186 net [libc] getaddrinfo(3) does not handle incorrect servna o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c o conf/23063 net [arp] [patch] for static ARP tables in rc.network 363 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Nov 8 14:02:04 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E8985106564A; Mon, 8 Nov 2010 14:02:03 +0000 (UTC) (envelope-from krivenok.dmitry@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7B0CB8FC16; Mon, 8 Nov 2010 14:02:03 +0000 (UTC) Received: by gya6 with SMTP id 6so3475555gya.13 for ; Mon, 08 Nov 2010 06:02:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=AG9668pM+cbpCJUQMBUktFfCsHw5gu/LEh45z5Hx5fo=; b=QdzBxZFXUeFtZe7s5BmC7baPzzBrXlqYOnKW4DPxxd36siH7T/aOWRoULsE3Ewjkxk 1qMYNMcL8hIdeE0jOleG3nat3Moazoxq0BDMj8u+bn/7rxB4ASBxxaTin6R6ZlRjGtuS ThFBhvwqL2PDMWe1b1tMvAinjIbiZkbEIUHLM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=H/jXDFEQzBTaDxTrYDYdatK+JeZC1JEDDoOc1y8Wv12NMAUzP6AMQMKem1SSg4yknO +Ck80AKsizkHGmsJL2vwrPofrELAVfNhzBGXBrt0hg4u6rYoqiLCfG7Bnzuubw1TJTij aJA7u0tDB47m/fvRBeZrbbAs287yHDnNySPP0= MIME-Version: 1.0 Received: by 10.42.176.135 with SMTP id be7mr521985icb.245.1289223050647; Mon, 08 Nov 2010 05:30:50 -0800 (PST) Received: by 10.231.149.210 with HTTP; Mon, 8 Nov 2010 05:30:50 -0800 (PST) In-Reply-To: <201010251129.44262.bschmidt@freebsd.org> References: <20101024052559.GA1971@current.Sisis.de> <201010251129.44262.bschmidt@freebsd.org> Date: Mon, 8 Nov 2010 16:30:50 +0300 Message-ID: From: Dmitry Krivenok To: bschmidt@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, Matthias Apitz , freebsd-hackers@freebsd.org Subject: Re: Broadcom BCM4310 / bwi(4) and interface bwi0 is not showing up X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Nov 2010 14:02:04 -0000 I tried your patch, but my laptop hung at startup. The last line I saw on console was "Timecounters tick every 1.000 msec". I didn't dig into the problem and don't have any information useful for debugging, but I'm going to play with it later today. Dmitry On Mon, Oct 25, 2010 at 1:29 PM, Bernhard Schmidt wr= ote: > On Sunday, October 24, 2010 07:25:59 Matthias Apitz wrote: >> Hello, >> >> I have a new laptop Acer Aspire One D250 and I want to install a >> 8-CURRENT as of CVS from May 2009 (as I use this on all my laptops). >> The laptop comes with as Wifi chip: >> >> none2@pci0:1:0:0: =A0 =A0 =A0 class=3D0x028000 card=3D0xe01b105b chip=3D= 0x431514e4 >> rev=3D0x01 hdr=3D0x00 >> =A0 =A0 vendor =A0 =A0 =3D 'Broadcom Corporation' >> =A0 =A0 device =A0 =A0 =3D 'BCM4310 USB Controller' >> =A0 =A0 class =A0 =A0 =A0=3D network >> >> I learned after searching around that it should be supported by bwi(4) >> and one should install the firmware kmod from the ports. I have in >> loader.conf: >> [..] > > Please try attached patch, I'm not sure if it is that simple.. worth a tr= y > though. > > -- > Bernhard > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org= " > --=20 Sincerely yours, Dmitry V. Krivenok e-mail: krivenok.dmitry@gmail.com skype: krivenok_dmitry jabber: krivenok_dmitry@jabber.ru icq: 242-526-443 From owner-freebsd-net@FreeBSD.ORG Mon Nov 8 16:01:57 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BD3C0106566B; Mon, 8 Nov 2010 16:01:57 +0000 (UTC) (envelope-from jh@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 935338FC19; Mon, 8 Nov 2010 16:01:57 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id oA8G1vjT004662; Mon, 8 Nov 2010 16:01:57 GMT (envelope-from jh@freefall.freebsd.org) Received: (from jh@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id oA8G1vo1004658; Mon, 8 Nov 2010 16:01:57 GMT (envelope-from jh) Date: Mon, 8 Nov 2010 16:01:57 GMT Message-Id: <201011081601.oA8G1vo1004658@freefall.freebsd.org> To: eddy@ncv.ru, jh@FreeBSD.org, freebsd-net@FreeBSD.org From: jh@FreeBSD.org Cc: Subject: Re: bin/97392: ppp(8) hangs instead terminating X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Nov 2010 16:01:57 -0000 Synopsis: ppp(8) hangs instead terminating State-Changed-From-To: feedback->closed State-Changed-By: jh State-Changed-When: Mon Nov 8 16:01:56 UTC 2010 State-Changed-Why: Feedback timeout. http://www.freebsd.org/cgi/query-pr.cgi?pr=97392 From owner-freebsd-net@FreeBSD.ORG Tue Nov 9 00:45:11 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9CBFB106564A; Tue, 9 Nov 2010 00:45:11 +0000 (UTC) (envelope-from gonzo@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 60BFB8FC1B; Tue, 9 Nov 2010 00:45:11 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id oA90jB3m040680; Tue, 9 Nov 2010 00:45:11 GMT (envelope-from gonzo@freefall.freebsd.org) Received: (from gonzo@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id oA90jBjA040675; Tue, 9 Nov 2010 00:45:11 GMT (envelope-from gonzo) Date: Tue, 9 Nov 2010 00:45:11 GMT Message-Id: <201011090045.oA90jBjA040675@freefall.freebsd.org> To: gonzo@FreeBSD.org, gonzo@FreeBSD.org, freebsd-net@FreeBSD.org From: gonzo@FreeBSD.org Cc: Subject: Re: kern/125442: [carp] [lagg] CARP combined with LAGG causes system panic - 7.0/amd64 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2010 00:45:11 -0000 Synopsis: [carp] [lagg] CARP combined with LAGG causes system panic - 7.0/amd64 Responsible-Changed-From-To: gonzo->freebsd-net Responsible-Changed-By: gonzo Responsible-Changed-When: Tue Nov 9 00:43:55 UTC 2010 Responsible-Changed-Why: Over to mainainer(s) http://www.freebsd.org/cgi/query-pr.cgi?pr=125442 From owner-freebsd-net@FreeBSD.ORG Tue Nov 9 00:46:55 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4FC25106564A; Tue, 9 Nov 2010 00:46:55 +0000 (UTC) (envelope-from gonzo@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 258988FC26; Tue, 9 Nov 2010 00:46:55 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id oA90ktjK040820; Tue, 9 Nov 2010 00:46:55 GMT (envelope-from gonzo@freefall.freebsd.org) Received: (from gonzo@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id oA90ktdf040816; Tue, 9 Nov 2010 00:46:55 GMT (envelope-from gonzo) Date: Tue, 9 Nov 2010 00:46:55 GMT Message-Id: <201011090046.oA90ktdf040816@freefall.freebsd.org> To: gonzo@FreeBSD.org, gonzo@FreeBSD.org, freebsd-net@FreeBSD.org From: gonzo@FreeBSD.org Cc: Subject: Re: kern/85320: [gre] [patch] possible depletion of kernel stack in ip_gre.c when net.isr.enable = 1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2010 00:46:55 -0000 Synopsis: [gre] [patch] possible depletion of kernel stack in ip_gre.c when net.isr.enable = 1 Responsible-Changed-From-To: gonzo->freebsd-net Responsible-Changed-By: gonzo Responsible-Changed-When: Tue Nov 9 00:46:12 UTC 2010 Responsible-Changed-Why: Over to maintainer(s) http://www.freebsd.org/cgi/query-pr.cgi?pr=85320 From owner-freebsd-net@FreeBSD.ORG Tue Nov 9 00:47:56 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B2F5B1065693; Tue, 9 Nov 2010 00:47:56 +0000 (UTC) (envelope-from gonzo@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 89BB08FC26; Tue, 9 Nov 2010 00:47:56 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id oA90lu6U040871; Tue, 9 Nov 2010 00:47:56 GMT (envelope-from gonzo@freefall.freebsd.org) Received: (from gonzo@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id oA90luYp040867; Tue, 9 Nov 2010 00:47:56 GMT (envelope-from gonzo) Date: Tue, 9 Nov 2010 00:47:56 GMT Message-Id: <201011090047.oA90luYp040867@freefall.freebsd.org> To: gonzo@FreeBSD.org, gonzo@FreeBSD.org, freebsd-net@FreeBSD.org From: gonzo@FreeBSD.org Cc: Subject: Re: kern/123045: [ng_mppc] ng_mppc_decompress - disabling node X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2010 00:47:56 -0000 Synopsis: [ng_mppc] ng_mppc_decompress - disabling node Responsible-Changed-From-To: gonzo->freebsd-net Responsible-Changed-By: gonzo Responsible-Changed-When: Tue Nov 9 00:47:38 UTC 2010 Responsible-Changed-Why: Over to maintainer(s) http://www.freebsd.org/cgi/query-pr.cgi?pr=123045 From owner-freebsd-net@FreeBSD.ORG Tue Nov 9 01:15:11 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4DA69106566B for ; Tue, 9 Nov 2010 01:15:11 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id F1A1C8FC1A for ; Tue, 9 Nov 2010 01:15:10 +0000 (UTC) Received: by iwn39 with SMTP id 39so6896098iwn.13 for ; Mon, 08 Nov 2010 17:15:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=L6RvDKXl/n2lMA54UKqEFhLJvOy5tBKberMOLvhZfvk=; b=PEzPKia76IrhZomW/KVYuP0RV4ATWXRLT2TXyx1Nz8TzD93JlpmDdsLi4VHZojdI4B 1UjXLfExU4DXKtDMgccVCt70yxvkjvrL7D6hw0B/i717Pu056TIyZoYX20oTJvdnCrhL 8LWC063bLbDPhvU1L9OvzgAIUlZTCbZUjGgvE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=w1zfmyhvUuGrstPAm/eUcVghJrPx1bWU4VD7OX79c82u+xpxB0XEQkYTZOKQ//IEiK RJ4U25O8g0JHyJPYBqLK5QX3SnjpEA13txp+L6GLOCrGlVDcR+WfIFV1Is8zGlHqOBSp A15cwwlvY51P5yIU5RXYvrhFnPFJA4pwxvgGs= Received: by 10.231.59.197 with SMTP id m5mr4714029ibh.94.1289265308879; Mon, 08 Nov 2010 17:15:08 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 34sm538040ibi.2.2010.11.08.17.15.05 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 08 Nov 2010 17:15:06 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Mon, 8 Nov 2010 17:14:10 -0800 From: Pyun YongHyeon Date: Mon, 8 Nov 2010 17:14:10 -0800 To: Yamagi Burmeister Message-ID: <20101109011410.GB1275@michelle.cdnetworks.com> References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="HcAYCG3uE/tztfnV" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: [patch] WOL support for nfe(4) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2010 01:15:11 -0000 --HcAYCG3uE/tztfnV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Nov 05, 2010 at 11:10:37AM +0100, Yamagi Burmeister wrote: > Hi, > > some time ago we migrated a lot of boxes from Linux to FreeBSD. Those > machines have a "NVIDIA nForce4 CK804 MCP4" network adapter, supported > by nfe(4). Even if nfe(4) at least tries to enable the WOL capability of > the NIC it doesn't work and nfe(4) doesn't integrate with FreeBSDs (new) > WOL framework. Since we are in need of WOL I spend some minutes to > implement it the correct way. > > Attached are two patches: > - if_nfe_wol_8.1.diff against FreeBSD 8.1-RELEASE-p1, this one is used > on our servers. > - if_nfe_wol_current.diff against -CURRENT r214831. This one is > _untested_! But it should work... > > In case that the patches a stripped by mailman they can be found here: > http://deponie.yamagi.org/freebsd/nfe/ > > This patch works reliable on our machines and nfe(4) runs without any > problems with it. But nevertheless my skills in writting network drivers > are somewhat limited therefor a review by somewhat with better knowledge > of the WOL framework and maybe nfe(4) itself is highly anticipated. > Thanks for the patch. I attached slightly modified the code to better match other WOL capable drivers in tree. Because data sheet is not available I blindly made a patch based on your code. I have a couple of questions which I can't verify it on real hardware(I have no more access to the hardware). o If you established a gigabit link with link partner and shutdown your box, does the established link automatically change to 10 or 100Mbps? You can check it on your link partner. If your link partner still reports it established 1000Mbps link, we have to do other necessary work in driver(i.e. manually switching to 10/100Mbps). o When you put your box into suspend mode, can you wake up your box with WOL magic packet? o When your system boots up with/without WOL magic packet, sending WOL magic packets from other hosts can hang your box? o If you disabled WOL with ifconfig before system shutdown, can you still wakeup your box with WOL magic packet? o If you reprogram your station address with ifconfig(i.e. ifconfig nfe0 ether xx:xx:xx:xx:xx:xx), can you still wakeup your box with WOL magic packet? The patch I made didn't take into account management firmware so if you use the patch with IMPI, IMPI wouldn't work. But I think that's not an issue since all other parts of nfe(4) also ignores management firmware at this moment. --HcAYCG3uE/tztfnV Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="nfe.wol.patch" Index: sys/dev/nfe/if_nfe.c =================================================================== --- sys/dev/nfe/if_nfe.c (revision 214989) +++ sys/dev/nfe/if_nfe.c (working copy) @@ -125,6 +125,7 @@ static void nfe_sysctl_node(struct nfe_softc *); static void nfe_stats_clear(struct nfe_softc *); static void nfe_stats_update(struct nfe_softc *); +static void nfe_set_wol(struct nfe_softc *); #ifdef NFE_DEBUG static int nfedebug = 0; @@ -586,6 +587,9 @@ if ((ifp->if_capabilities & IFCAP_HWCSUM) != 0) ifp->if_capabilities |= IFCAP_VLAN_HWCSUM; } + + if (pci_find_extcap(dev, PCIY_PMG, ®) == 0) + ifp->if_capabilities |= IFCAP_WOL_MAGIC; ifp->if_capenable = ifp->if_capabilities; /* @@ -752,6 +756,7 @@ NFE_LOCK(sc); nfe_stop(sc->nfe_ifp); + nfe_set_wol(sc); sc->nfe_suspended = 1; NFE_UNLOCK(sc); @@ -768,6 +773,7 @@ sc = device_get_softc(dev); NFE_LOCK(sc); + nfe_power(sc); ifp = sc->nfe_ifp; if (ifp->if_flags & IFF_UP) nfe_init_locked(sc); @@ -1714,6 +1720,10 @@ } } #endif /* DEVICE_POLLING */ + if ((mask & IFCAP_WOL_MAGIC) != 0 && + (ifp->if_capabilities & IFCAP_WOL_MAGIC) != 0) + ifp->if_capenable ^= IFCAP_WOL_MAGIC; + if ((sc->nfe_flags & NFE_HW_CSUM) != 0 && (mask & IFCAP_HWCSUM) != 0) { ifp->if_capenable ^= IFCAP_HWCSUM; @@ -2746,7 +2756,8 @@ NFE_WRITE(sc, NFE_STATUS, sc->mii_phyaddr << 24 | NFE_STATUS_MAGIC); NFE_WRITE(sc, NFE_SETUP_R4, NFE_R4_MAGIC); - NFE_WRITE(sc, NFE_WOL_CTL, NFE_WOL_MAGIC); + /* Disable WOL. */ + NFE_WRITE(sc, NFE_WOL_CTL, 0); sc->rxtxctl &= ~NFE_RXTX_BIT2; NFE_WRITE(sc, NFE_RXTX_CTL, sc->rxtxctl); @@ -2917,18 +2928,8 @@ static int nfe_shutdown(device_t dev) { - struct nfe_softc *sc; - struct ifnet *ifp; - sc = device_get_softc(dev); - - NFE_LOCK(sc); - ifp = sc->nfe_ifp; - nfe_stop(ifp); - /* nfe_reset(sc); */ - NFE_UNLOCK(sc); - - return (0); + return (nfe_suspend(dev)); } @@ -3212,3 +3213,39 @@ stats->rx_broadcast += NFE_READ(sc, NFE_TX_BROADCAST); } } + +static void +nfe_set_wol(struct nfe_softc *sc) +{ + struct ifnet *ifp; + uint32_t wolctl; + int pmc; + uint16_t pmstat; + + NFE_LOCK_ASSERT(sc); + + if (pci_find_extcap(sc->nfe_dev, PCIY_PMG, &pmc) != 0) + return; + ifp = sc->nfe_ifp; + if ((ifp->if_capenable & IFCAP_WOL_MAGIC) != 0) + wolctl = NFE_WOL_MAGIC; + else + wolctl = 0; + NFE_WRITE(sc, NFE_WOL_CTL, wolctl); + if ((ifp->if_capenable & IFCAP_WOL_MAGIC) != 0) { + if ((sc->nfe_flags & NFE_PWR_MGMT) != 0) + NFE_WRITE(sc, NFE_PWR2_CTL, + NFE_READ(sc, NFE_PWR2_CTL) & ~NFE_PWR2_GATE_CLOCKS); + /* Enable RX. */ + NFE_WRITE(sc, NFE_RX_RING_ADDR_HI, 0); + NFE_WRITE(sc, NFE_RX_RING_ADDR_LO, 0); + NFE_WRITE(sc, NFE_RX_CTL, NFE_READ(sc, NFE_RX_CTL) | + NFE_RX_START); + } + /* Request PME if WOL is requested. */ + pmstat = pci_read_config(sc->nfe_dev, pmc + PCIR_POWER_STATUS, 2); + pmstat &= ~(PCIM_PSTAT_PME | PCIM_PSTAT_PMEENABLE); + if ((ifp->if_capenable & IFCAP_WOL) != 0) + pmstat |= PCIM_PSTAT_PME | PCIM_PSTAT_PMEENABLE; + pci_write_config(sc->nfe_dev, pmc + PCIR_POWER_STATUS, pmstat, 2); +} Index: sys/dev/nfe/if_nfereg.h =================================================================== --- sys/dev/nfe/if_nfereg.h (revision 214989) +++ sys/dev/nfe/if_nfereg.h (working copy) @@ -190,6 +190,7 @@ #define NFE_PWR2_WAKEUP_MASK 0x0f11 #define NFE_PWR2_REVA3 (1 << 0) +#define NFE_PWR2_GATE_CLOCKS 0x0f00 #define NFE_MEDIA_SET 0x10000 #define NFE_MEDIA_1000T 0x00032 --HcAYCG3uE/tztfnV-- From owner-freebsd-net@FreeBSD.ORG Tue Nov 9 04:03:28 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0505E106564A for ; Tue, 9 Nov 2010 04:03:28 +0000 (UTC) (envelope-from will@firepipe.net) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 98A278FC18 for ; Tue, 9 Nov 2010 04:03:27 +0000 (UTC) Received: by wyb32 with SMTP id 32so191067wyb.13 for ; Mon, 08 Nov 2010 20:03:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.191.210 with SMTP id g60mr6277322wen.5.1289273746582; Mon, 08 Nov 2010 19:35:46 -0800 (PST) Received: by 10.216.246.3 with HTTP; Mon, 8 Nov 2010 19:35:46 -0800 (PST) In-Reply-To: <77F1671C-33AE-4AAB-8442-7653B00F7E04@develooper.com> References: <17903237-CBF6-4CC3-8CA3-29D9BB65538F@develooper.com> <4CD36BD0.4040409@tomjudge.com> <77F1671C-33AE-4AAB-8442-7653B00F7E04@develooper.com> Date: Mon, 8 Nov 2010 20:35:46 -0700 Message-ID: From: Will Andrews To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: "kernel: carp_input: received len 20 < sizeof(struct carp_header)" messages X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2010 04:03:28 -0000 On Fri, Nov 5, 2010 at 4:47 PM, Ask Bj=F8rn Hansen wro= te: > I agree that it was pretty dumb of the OpenBSD developers to just stomp o= n another protocol ID for their (and ours in FreeBSD ...) implementation. Actually, in this particular case I think it was justified. The IANA refused to allocate a separate protocol number for CARP. Given that, and the fact that CARP and VRRP serve generally the same purpose, it makes sense that they use the same number. Using an "unused" number runs the risk of conflicting with a different unregistered protocol, or one that was registered after the number was chosen. FreeBSD could require administrators to configure the number on all participating hosts on a given network, but that may be non-trivial to implement in a particular network stack. With the recent changes to CARP in FreeBSD, however, it could be made to attach to a different protocol number relatively easily. FreeBSD could allow configuring CARP to silently ignore invalid packets. That would definitely be trivial to implement, but it doesn't solve the issue that a particular network segment might be running fussy VRRP hosts. --Will. From owner-freebsd-net@FreeBSD.ORG Tue Nov 9 08:49:24 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D686D106566B for ; Tue, 9 Nov 2010 08:49:24 +0000 (UTC) (envelope-from lists@yamagi.org) Received: from mail.yamagi.overkill.yamagi.org (unknown [IPv6:2a01:4f8:121:2102:1::7]) by mx1.freebsd.org (Postfix) with ESMTP id 6E9B38FC13 for ; Tue, 9 Nov 2010 08:49:24 +0000 (UTC) Received: from [2001:6f8:108a:1:21b:21ff:fe07:b562] (unknown [IPv6:2001:6f8:108a:1:21b:21ff:fe07:b562]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yamagi.overkill.yamagi.org (Postfix) with ESMTPSA id F065816663D1; Tue, 9 Nov 2010 09:49:22 +0100 (CET) Date: Tue, 9 Nov 2010 09:49:14 +0100 (CET) From: Yamagi Burmeister X-X-Sender: yamagi@saya.home.yamagi.org To: Pyun YongHyeon In-Reply-To: <20101109011410.GB1275@michelle.cdnetworks.com> Message-ID: References: <20101109011410.GB1275@michelle.cdnetworks.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org, Yamagi Burmeister Subject: Re: [patch] WOL support for nfe(4) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2010 08:49:24 -0000 Thanks for your reply. On Mon, 8 Nov 2010, Pyun YongHyeon wrote: > Thanks for the patch. I attached slightly modified the code to > better match other WOL capable drivers in tree. Because data sheet > is not available I blindly made a patch based on your code. I have > a couple of questions which I can't verify it on real hardware(I > have no more access to the hardware). > > o If you established a gigabit link with link partner and shutdown > your box, does the established link automatically change to 10 or > 100Mbps? You can check it on your link partner. If your link > partner still reports it established 1000Mbps link, we have to > do other necessary work in driver(i.e. manually switching to > 10/100Mbps). No, the link stays at 1000Mbps so the driver must manually switch back to 10/100Mbps. > o When you put your box into suspend mode, can you wake up your box > with WOL magic packet? I'm sorry but I can't test that since none of those boxes supports suspend: % sysctl hw.acpi.suspend_state hw.acpi.suspend_state: NONE > o When your system boots up with/without WOL magic packet, sending > WOL magic packets from other hosts can hang your box? No they don't. No matter if the box was started by sending the WOL magic packet or by hand it survives all WOL packets I send to it. > o If you disabled WOL with ifconfig before system shutdown, can you > still wakeup your box with WOL magic packet? No, I can't. WOL is disabled and the box must be started manually. > o If you reprogram your station address with ifconfig(i.e. ifconfig > nfe0 ether xx:xx:xx:xx:xx:xx), can you still wakeup your box with > WOL magic packet? Yes, with sending the WOL magic packet to the new station adress. Sending it to the original adress doesn't work. > The patch I made didn't take into account management firmware so > if you use the patch with IMPI, IMPI wouldn't work. But I think > that's not an issue since all other parts of nfe(4) also ignores > management firmware at this moment. I can't test that, because none of these machines has the IPMI option installed. Sorry. Ciao, Yamagi -- Homepage: www.yamagi.org Jabber: yamagi@yamagi.org GnuPG/GPG: 0xEFBCCBCB From owner-freebsd-net@FreeBSD.ORG Tue Nov 9 19:08:11 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 66F48106566B for ; Tue, 9 Nov 2010 19:08:11 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id 33DEC8FC1C for ; Tue, 9 Nov 2010 19:08:11 +0000 (UTC) Received: by pvc22 with SMTP id 22so1939705pvc.13 for ; Tue, 09 Nov 2010 11:08:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=UMjSKKWom7fBhww8Vk4/4KmJIBx4anbBx8gi6IpUNLs=; b=byXxyLteBPKpb4Xh0t4TxfPzQ1Jnbpe2zXHHoAfm1FcTassZ6nDLHrIB9l9t9RgfMQ eBQzG9BwyNavRbpx+JRwK1vvpqd9Tf/wnmQOG5G1sb9M6QT2VYRtawz3F2PzjF/LfjC0 hJ4Ks4nfDRhg6ILkWDFvM9iYe2rZKaKXXRlEE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=na7uWw81N2BAc07SAMvxq/siHIzLUc78I9XedP2WgaFfkPjevkYBKGOY85pgTPsM15 NQejTNogNk7OVlplsoBJbFLcyfxDqvGOuSDqJuW3UjpgZnJt0NsTDefPBpuvDlub+2e2 1DuSZ/e8IqpNqYnHOG+smM/tM9vUtWoHV2v1I= Received: by 10.142.186.20 with SMTP id j20mr6152757wff.387.1289329690535; Tue, 09 Nov 2010 11:08:10 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id y42sm2036364wfd.10.2010.11.09.11.08.07 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 09 Nov 2010 11:08:08 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Tue, 9 Nov 2010 11:07:13 -0800 From: Pyun YongHyeon Date: Tue, 9 Nov 2010 11:07:13 -0800 To: Yamagi Burmeister Message-ID: <20101109190713.GA7766@michelle.cdnetworks.com> References: <20101109011410.GB1275@michelle.cdnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: [patch] WOL support for nfe(4) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2010 19:08:11 -0000 On Tue, Nov 09, 2010 at 09:49:14AM +0100, Yamagi Burmeister wrote: > > Thanks for your reply. > > On Mon, 8 Nov 2010, Pyun YongHyeon wrote: > > >Thanks for the patch. I attached slightly modified the code to > >better match other WOL capable drivers in tree. Because data sheet > >is not available I blindly made a patch based on your code. I have > >a couple of questions which I can't verify it on real hardware(I > >have no more access to the hardware). > > > >o If you established a gigabit link with link partner and shutdown > > your box, does the established link automatically change to 10 or > > 100Mbps? You can check it on your link partner. If your link > > partner still reports it established 1000Mbps link, we have to > > do other necessary work in driver(i.e. manually switching to > > 10/100Mbps). > > No, the link stays at 1000Mbps so the driver must manually switch back > to 10/100Mbps. > Hmm, this is real problem for WOL. Establishing 1000Mbps link to accept WOL frames is really bad idea since it can draw more power than 375mA. Consuming more power than 375mA is violation of PCI specification and some system may completely shutdown the power to protect hardware against over-current damage which in turn means WOL wouldn't work anymore. Even if WOL work with 1000Mbps link for all nfe(4) controllers, it would dissipate much more power. Because nfe(4) controllers are notorious for using various PHYs, it's hard to write a code to reliably establish 10/100Mbps link in driver. In addition, nfe(4) is known to be buggy in link state handling such that forced media selection didn't work well. I'll see what could be done in this week if I find spare time. > >o When you put your box into suspend mode, can you wake up your box > > with WOL magic packet? > > I'm sorry but I can't test that since none of those boxes supports > suspend: > > % sysctl hw.acpi.suspend_state > hw.acpi.suspend_state: NONE > You can switch to suspend mode with "acpiconf -s1". If all goes well, driver would put the controller into suspend mode after reprogramming controller to accept WOL frames. After that, you can wakeup the box by sending a WOL magic packet. > >o When your system boots up with/without WOL magic packet, sending > > WOL magic packets from other hosts can hang your box? > > No they don't. No matter if the box was started by sending the WOL magic > packet or by hand it survives all WOL packets I send to it. > Ok, some controllers are known to hang the box if it receive WOL frames before initializing controller. > >o If you disabled WOL with ifconfig before system shutdown, can you > > still wakeup your box with WOL magic packet? > > No, I can't. WOL is disabled and the box must be started manually. > > >o If you reprogram your station address with ifconfig(i.e. ifconfig > > nfe0 ether xx:xx:xx:xx:xx:xx), can you still wakeup your box with > > WOL magic packet? > > Yes, with sending the WOL magic packet to the new station adress. > Sending it to the original adress doesn't work. > > >The patch I made didn't take into account management firmware so > >if you use the patch with IMPI, IMPI wouldn't work. But I think > >that's not an issue since all other parts of nfe(4) also ignores > >management firmware at this moment. > > I can't test that, because none of these machines has the IPMI option > installed. Sorry. > Ok, all other features except wakeup from suspend seem to work. Thanks for testing! From owner-freebsd-net@FreeBSD.ORG Tue Nov 9 20:16:15 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1EB5C106566C for ; Tue, 9 Nov 2010 20:16:15 +0000 (UTC) (envelope-from prt@prt.org) Received: from smtp5.uk.umis.net (smtp5.uk.umis.net [217.65.166.40]) by mx1.freebsd.org (Postfix) with ESMTP id D9D718FC1A for ; Tue, 9 Nov 2010 20:16:14 +0000 (UTC) Received: from [109.71.168.158] (helo=emma.local) by smtp5.uk.umis.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1PFuc1-000Dxu-A3 for freebsd-net@freebsd.org; Tue, 09 Nov 2010 20:16:13 +0000 Message-ID: <4CD9AC0D.9060207@prt.org> Date: Tue, 09 Nov 2010 20:16:13 +0000 From: Paul Thornton User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <4CBE0042.4090905@prt.org> <4CBE0846.1090203@freebsd.org> <4CBEFB5A.80704@prt.org> <4CBF15ED.6080606@freebsd.org> <4CC7162C.2020806@prt.org> In-Reply-To: <4CC7162C.2020806@prt.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: Problems with 8.1, PPPoE server, and Cisco client X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2010 20:16:15 -0000 On 26/10/2010 18:55, Paul Thornton wrote: > I've been taking another look at this after being dragged off onto other > things for a few days, and hopefully have some more information that > might help point in the right direction for a fix / where to debug next. > > On 20/10/2010 17:16, Julian Elischer wrote: >> have you tried to connect this cisco router to anything else pppoe? >> (take it home and make it connect to your ISP for example?) > The Cisco client does work to a Cisco router acting as a PPPoE server - > I used a 891 (client) to a 3945 (server) and using an established setup > that is known to work, I collected a happy tcpdump. Of course that > doesn't tell us why there was such an issue with the FreeBSD ppp server > and it looks very similar to me. > > I'm also going to give mpd a go and see if that works - but if it tries > the same config options as pppoed then I may be straight back to where I > am now. > > Thanks to everyone for their help with this. > > So here is the dump from a known good setup, IOS at both ends - starting > from the CHAP success point again. This time, both ends play the game > and agree amongst themselves what they will and won't do as expected > (many thanks to Ian here for the commentary as to what was going on in > the exchanges I have): > >> 20:29:10.200860 PPPoE [ses 0x13] CHAP, Response (0x02), id 1, Value 8f917e3cd84fd4b3a5e8b705655bf16772d0cd1462392eed8bb4ab0ccb7f75bb2d01695ac26cdc07127b4fb3435a279a01, Name VT123456789@vdsl01.v >> 20:29:14.501312 PPPoE [ses 0x13] CHAP, Success (0x03), id 1, Msg >> 20:29:14.501702 PPPoE [ses 0x13] IPCP, Conf-Request (0x01), id 1, length 12 >> encoded length 10 (=Option(s) length 6) >> 0x0000: 8021 0101 000a >> IP-Addr Option (0x03), length 6: 109.71.168.123 >> 0x0000: 6d47 a87b >> 20:29:14.504344 PPPoE [ses 0x13] IPCP, Conf-Request (0x01), id 1, length 12 >> encoded length 10 (=Option(s) length 6) >> 0x0000: 8021 0101 000a >> IP-Addr Option (0x03), length 6: 0.0.0.0 >> 0x0000: 0000 0000 >> 20:29:14.504497 PPPoE [ses 0x13] unknown PPP protocol (0x8207) >> 0x0000: 0101 0004 >> 20:29:14.504669 PPPoE [ses 0x13] IPCP, Conf-Ack (0x02), id 1, length 12 >> encoded length 10 (=Option(s) length 6) >> 0x0000: 8021 0201 000a >> IP-Addr Option (0x03), length 6: 109.71.168.123 >> 0x0000: 6d47 a87b >> 20:29:14.505200 PPPoE [ses 0x13] IPCP, Conf-Nack (0x03), id 1, length 12 >> encoded length 10 (=Option(s) length 6) >> 0x0000: 8021 0301 000a >> IP-Addr Option (0x03), length 6: 109.71.174.50 >> 0x0000: 6d47 ae32 >> 20:29:14.505290 PPPoE [ses 0x13] LCP, Prot-Reject (0x08), id 2, length 12 >> encoded length 10 (=Option(s) length 6) >> 0x0000: c021 0802 000a >> Rejected unknown Protocol (0x8207) >> Rejected Packet >> 0x0000: 0101 0006 0000 0000 >> 20:29:14.505800 PPPoE [ses 0x13] IPCP, Conf-Request (0x01), id 2, length 12 >> encoded length 10 (=Option(s) length 6) >> 0x0000: 8021 0102 000a >> IP-Addr Option (0x03), length 6: 109.71.174.50 >> 0x0000: 6d47 ae32 >> 20:29:14.506753 PPPoE [ses 0x13] IPCP, Conf-Ack (0x02), id 2, length 12 >> encoded length 10 (=Option(s) length 6) >> 0x0000: 8021 0202 000a >> IP-Addr Option (0x03), length 6: 109.71.174.50 >> 0x0000: 6d47 ae32 >> 20:29:23.247975 PPPoE [ses 0x13] IP (tos 0x0, ttl 255, id 35, offset 0, flags [none], proto ICMP (1), length 100) >> 109.71.174.50 > 217.65.161.4: ICMP echo request, id 10, seq 0, length 80 >> 20:29:23.257872 PPPoE [ses 0x13] IP (tos 0x0, ttl 61, id 51771, offset 0, flags [none], proto ICMP (1), length 100) >> 217.65.161.4 > 109.71.174.50: ICMP echo reply, id 10, seq 0, length 80 > The ping here is the start of real data flowing - I used this setup for > about 30 minutes of web browsing with no problems. > > Paul. > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Tue Nov 9 20:18:37 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D0CD9106566B for ; Tue, 9 Nov 2010 20:18:37 +0000 (UTC) (envelope-from prt@prt.org) Received: from smtp5.uk.umis.net (smtp5.uk.umis.net [217.65.166.40]) by mx1.freebsd.org (Postfix) with ESMTP id 984B78FC0A for ; Tue, 9 Nov 2010 20:18:37 +0000 (UTC) Received: from [109.71.168.158] (helo=emma.local) by smtp5.uk.umis.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1PFueK-000Dxy-Ol for freebsd-net@freebsd.org; Tue, 09 Nov 2010 20:18:36 +0000 Message-ID: <4CD9AC9C.9060203@prt.org> Date: Tue, 09 Nov 2010 20:18:36 +0000 From: Paul Thornton User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <4CBE0042.4090905@prt.org> <4CBE0846.1090203@freebsd.org> <4CBEFB5A.80704@prt.org> <4CBF15ED.6080606@freebsd.org> <4CC7162C.2020806@prt.org> In-Reply-To: <4CC7162C.2020806@prt.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: Problems with 8.1, PPPoE server, and Cisco client X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2010 20:18:37 -0000 Hi folks, Keeping the list archives updated for any poor soul that has a similar problem in future... On 26/10/2010 18:55, Paul Thornton wrote: > I'm also going to give mpd a go and see if that works - but if it tries > the same config options as pppoed then I may be straight back to where I > am now. The verdict with mpd is exactly the same - the Cisco takes exception to the IPCP request immediately following the successful auth, and tears down the connection. I'm going to take this to the Cisco TAC and see if they can suggest anything that may be causing this as it makes no sense at all when all other clients I try work. Paul. From owner-freebsd-net@FreeBSD.ORG Tue Nov 9 20:19:38 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 960A1106564A for ; Tue, 9 Nov 2010 20:19:38 +0000 (UTC) (envelope-from prt@prt.org) Received: from smtp5.uk.umis.net (smtp5.uk.umis.net [217.65.166.40]) by mx1.freebsd.org (Postfix) with ESMTP id 5E09A8FC28 for ; Tue, 9 Nov 2010 20:19:38 +0000 (UTC) Received: from [109.71.168.158] (helo=emma.local) by smtp5.uk.umis.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1PFufJ-000Dy1-BV for freebsd-net@freebsd.org; Tue, 09 Nov 2010 20:19:37 +0000 Message-ID: <4CD9ACD9.9090003@prt.org> Date: Tue, 09 Nov 2010 20:19:37 +0000 From: Paul Thornton User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <4CBE0042.4090905@prt.org> <4CBE0846.1090203@freebsd.org> <4CBEFB5A.80704@prt.org> <4CBF15ED.6080606@freebsd.org> <4CC7162C.2020806@prt.org> <4CD9AC0D.9060207@prt.org> In-Reply-To: <4CD9AC0D.9060207@prt.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: Problems with 8.1, PPPoE server, and Cisco client X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2010 20:19:38 -0000 On 09/11/2010 20:16, Paul Thornton wrote: > Sorry for that unedited copy of the last mail to the list. Finger trouble in mail client. Must try harder! Paul. From owner-freebsd-net@FreeBSD.ORG Tue Nov 9 20:22:15 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EC7451065673 for ; Tue, 9 Nov 2010 20:22:15 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from out-0.mx.aerioconnect.net (outy.internet-mail-service.net [216.240.47.248]) by mx1.freebsd.org (Postfix) with ESMTP id CD1958FC1C for ; Tue, 9 Nov 2010 20:22:15 +0000 (UTC) Received: from idiom.com (postfix@mx0.idiom.com [216.240.32.160]) by out-0.mx.aerioconnect.net (8.13.8/8.13.8) with ESMTP id oA9KMB3g022479; Tue, 9 Nov 2010 12:22:12 -0800 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by idiom.com (Postfix) with ESMTP id 3A7BD2D6019; Tue, 9 Nov 2010 12:22:10 -0800 (PST) Message-ID: <4CD9AD76.5080303@freebsd.org> Date: Tue, 09 Nov 2010 12:22:14 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Paul Thornton References: <4CBE0042.4090905@prt.org> <4CBE0846.1090203@freebsd.org> <4CBEFB5A.80704@prt.org> <4CBF15ED.6080606@freebsd.org> <4CC7162C.2020806@prt.org> <4CD9AC9C.9060203@prt.org> In-Reply-To: <4CD9AC9C.9060203@prt.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 216.240.47.51 Cc: freebsd-net@freebsd.org Subject: Re: Problems with 8.1, PPPoE server, and Cisco client X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2010 20:22:16 -0000 On 11/9/10 12:18 PM, Paul Thornton wrote: > Hi folks, > > Keeping the list archives updated for any poor soul that has a similar > problem in future... > > On 26/10/2010 18:55, Paul Thornton wrote: >> I'm also going to give mpd a go and see if that works - but if it tries >> the same config options as pppoed then I may be straight back to where I >> am now. > The verdict with mpd is exactly the same - the Cisco takes exception to > the IPCP request immediately following the successful auth, and tears > down the connection. > > I'm going to take this to the Cisco TAC and see if they can suggest > anything that may be causing this as it makes no sense at all when all > other clients I try work. take especial care with netmasks and network definitions if you have any > Paul. > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Tue Nov 9 21:01:34 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 746A7106566C for ; Tue, 9 Nov 2010 21:01:34 +0000 (UTC) (envelope-from lists@yamagi.org) Received: from mail.yamagi.overkill.yamagi.org (unknown [IPv6:2a01:4f8:121:2102:1::7]) by mx1.freebsd.org (Postfix) with ESMTP id 076358FC1E for ; Tue, 9 Nov 2010 21:01:34 +0000 (UTC) Received: from [2001:6f8:108a:1:226:c6ff:fec4:399e] (unknown [IPv6:2001:6f8:108a:1:226:c6ff:fec4:399e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yamagi.overkill.yamagi.org (Postfix) with ESMTPSA id D569416663D1; Tue, 9 Nov 2010 22:01:32 +0100 (CET) Date: Tue, 9 Nov 2010 22:01:36 +0100 (CET) From: Yamagi Burmeister X-X-Sender: yamagi@maka.home.yamagi.org To: Pyun YongHyeon In-Reply-To: <20101109190713.GA7766@michelle.cdnetworks.com> Message-ID: References: <20101109011410.GB1275@michelle.cdnetworks.com> <20101109190713.GA7766@michelle.cdnetworks.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org, Yamagi Burmeister Subject: Re: [patch] WOL support for nfe(4) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2010 21:01:34 -0000 On Tue, 9 Nov 2010, Pyun YongHyeon wrote: >> No, the link stays at 1000Mbps so the driver must manually switch back >> to 10/100Mbps. >> > > Hmm, this is real problem for WOL. Establishing 1000Mbps link to > accept WOL frames is really bad idea since it can draw more power > than 375mA. Consuming more power than 375mA is violation of > PCI specification and some system may completely shutdown the power > to protect hardware against over-current damage which in turn means > WOL wouldn't work anymore. Even if WOL work with 1000Mbps link for > all nfe(4) controllers, it would dissipate much more power. > > Because nfe(4) controllers are notorious for using various PHYs, > it's hard to write a code to reliably establish 10/100Mbps link in > driver. In addition, nfe(4) is known to be buggy in link state > handling such that forced media selection didn't work well. I'll > see what could be done in this week if I find spare time. Hmm... Maybe just add a hint to the manpage that WOL is possible broken? Nevertheless thanks for your work it's much appreciated :) >>> o When you put your box into suspend mode, can you wake up your box >>> with WOL magic packet? >> >> I'm sorry but I can't test that since none of those boxes supports >> suspend: >> >> % sysctl hw.acpi.suspend_state >> hw.acpi.suspend_state: NONE >> > > You can switch to suspend mode with "acpiconf -s1". If all goes > well, driver would put the controller into suspend mode after > reprogramming controller to accept WOL frames. After that, you can > wakeup the box by sending a WOL magic packet. Okay, It thought that S3 is required. Put the box into S1, waited some minutes and send the magic packet. The video didn't resume but I was able to login via SSH. So waking up by sending the WOL magic packet works. -- Homepage: www.yamagi.org Jabber: yamagi@yamagi.org GnuPG/GPG: 0xEFBCCBCB From owner-freebsd-net@FreeBSD.ORG Tue Nov 9 21:35:18 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8C316106564A for ; Tue, 9 Nov 2010 21:35:18 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id 566098FC13 for ; Tue, 9 Nov 2010 21:35:18 +0000 (UTC) Received: by pxi1 with SMTP id 1so1612843pxi.13 for ; Tue, 09 Nov 2010 13:35:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=6qtJw81wgP7PApwaXigyndjjq5CBChkvAISFy5nTIh0=; b=XHt98HWUM/gVxQeqDuUfcMGrwYNr+qFG9b/+aLm8ebAJCmaCq+nsV71ZHHxiB3Xugh h004SJxR5b28yq9xxE0uz2h8vy8dYZIPd8VfJyB2U80LM62OJmMdfikNqiw4krf46K3x JCnCefO2SR1SGK+nwK6jF9o6+Me/5pfguswNA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=T/IXXJrKiS0hrTkMmGv2NX3hJmg5jMR+QZU9AnNU8gSwfCyCPgdBo6FkohBeYw+yBU iYY+igaYAKSje08hsUjjrzGPsyn4U4g0h4yuBffxFasm/gWWAzdb/VXAzlZ0N859ZDEb a/7qvAeFRIHuQHIUdzyio4+MpNqc9ItgX/YMo= Received: by 10.142.51.14 with SMTP id y14mr6409182wfy.306.1289338517806; Tue, 09 Nov 2010 13:35:17 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id w3sm1756771wfd.14.2010.11.09.13.35.15 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 09 Nov 2010 13:35:16 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Tue, 9 Nov 2010 13:34:21 -0800 From: Pyun YongHyeon Date: Tue, 9 Nov 2010 13:34:21 -0800 To: Yamagi Burmeister Message-ID: <20101109213421.GE7766@michelle.cdnetworks.com> References: <20101109011410.GB1275@michelle.cdnetworks.com> <20101109190713.GA7766@michelle.cdnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: [patch] WOL support for nfe(4) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2010 21:35:18 -0000 On Tue, Nov 09, 2010 at 10:01:36PM +0100, Yamagi Burmeister wrote: > On Tue, 9 Nov 2010, Pyun YongHyeon wrote: > > >>No, the link stays at 1000Mbps so the driver must manually switch back > >>to 10/100Mbps. > >> > > > >Hmm, this is real problem for WOL. Establishing 1000Mbps link to > >accept WOL frames is really bad idea since it can draw more power > >than 375mA. Consuming more power than 375mA is violation of > >PCI specification and some system may completely shutdown the power > >to protect hardware against over-current damage which in turn means > >WOL wouldn't work anymore. Even if WOL work with 1000Mbps link for > >all nfe(4) controllers, it would dissipate much more power. > > > >Because nfe(4) controllers are notorious for using various PHYs, > >it's hard to write a code to reliably establish 10/100Mbps link in > >driver. In addition, nfe(4) is known to be buggy in link state > >handling such that forced media selection didn't work well. I'll > >see what could be done in this week if I find spare time. > > Hmm... Maybe just add a hint to the manpage that WOL is possible broken? I think this may not be enough. Because it can damage your hardware under certain conditions if protection circuit was not there. > Nevertheless thanks for your work it's much appreciated :) > > >>>o When you put your box into suspend mode, can you wake up your box > >>>with WOL magic packet? > >> > >>I'm sorry but I can't test that since none of those boxes supports > >>suspend: > >> > >> % sysctl hw.acpi.suspend_state > >> hw.acpi.suspend_state: NONE > >> > > > >You can switch to suspend mode with "acpiconf -s1". If all goes > >well, driver would put the controller into suspend mode after > >reprogramming controller to accept WOL frames. After that, you can > >wakeup the box by sending a WOL magic packet. > > Okay, It thought that S3 is required. Put the box into S1, waited some > minutes and send the magic packet. The video didn't resume but I was > able to login via SSH. So waking up by sending the WOL magic packet > works. > Thanks for testing. Probably you want to poke jkim@ to address video resume issue. From owner-freebsd-net@FreeBSD.ORG Wed Nov 10 06:26:38 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C7ACE106566C for ; Wed, 10 Nov 2010 06:26:38 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) by mx1.freebsd.org (Postfix) with ESMTP id 46FB58FC1A for ; Wed, 10 Nov 2010 06:26:37 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id oAA6Qa1F025353; Wed, 10 Nov 2010 17:26:36 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Wed, 10 Nov 2010 17:26:36 +1100 (EST) From: Ian Smith To: Pyun YongHyeon In-Reply-To: <20101109213421.GE7766@michelle.cdnetworks.com> Message-ID: <20101110172151.I76697@sola.nimnet.asn.au> References: <20101109011410.GB1275@michelle.cdnetworks.com> <20101109190713.GA7766@michelle.cdnetworks.com> <20101109213421.GE7766@michelle.cdnetworks.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-net@freebsd.org, Yamagi Burmeister Subject: Re: [patch] WOL support for nfe(4) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 06:26:39 -0000 On Tue, 9 Nov 2010, Pyun YongHyeon wrote: > On Tue, Nov 09, 2010 at 10:01:36PM +0100, Yamagi Burmeister wrote: > > On Tue, 9 Nov 2010, Pyun YongHyeon wrote: [..] > > >You can switch to suspend mode with "acpiconf -s1". If all goes > > >well, driver would put the controller into suspend mode after > > >reprogramming controller to accept WOL frames. After that, you can > > >wakeup the box by sending a WOL magic packet. > > > > Okay, It thought that S3 is required. Put the box into S1, waited some > > minutes and send the magic packet. The video didn't resume but I was > > able to login via SSH. So waking up by sending the WOL magic packet > > works. > > > > Thanks for testing. Probably you want to poke jkim@ to address > video resume issue. It _may_ be just a matter of toggling the value of hw.acpi.reset_video ? cheers, Ian From owner-freebsd-net@FreeBSD.ORG Wed Nov 10 09:15:13 2010 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3F50F106564A for ; Wed, 10 Nov 2010 09:15:13 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id 2A9BE8FC14 for ; Wed, 10 Nov 2010 09:15:13 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=rmac.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1PG6ls-0002gC-DF for freebsd-net@FreeBSD.org; Wed, 10 Nov 2010 09:15:12 +0000 Date: Wed, 10 Nov 2010 17:15:10 +0800 Message-ID: From: Randy Bush To: freebsd-net User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: Subject: bjoern just received the itojun award at the ietf X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 09:15:13 -0000 bjoern zeeb just received the itojun award. congratulations, bjoern. and than you for all the hard work on the ipv6 stack. randy From owner-freebsd-net@FreeBSD.ORG Wed Nov 10 09:21:10 2010 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BAF9E106566B for ; Wed, 10 Nov 2010 09:21:10 +0000 (UTC) (envelope-from a.huth@tmr.net) Received: from bo-uwka-srv01.de.tmr.net (bo-uwka-srv01.de.tmr.net [212.23.146.2]) by mx1.freebsd.org (Postfix) with ESMTP id 7CB558FC2C for ; Wed, 10 Nov 2010 09:21:10 +0000 (UTC) Received: from localhost (localhost.de.tmr.net [127.0.0.1]) by bo-uwka-srv01.de.tmr.net (Postfix) with ESMTP id 459A61DE82F for ; Wed, 10 Nov 2010 09:51:16 +0100 (CET) Received: from bo-uwka-srv01.de.tmr.net ([127.0.0.1]) by localhost (bo-uwka-srv01.de.tmr.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 19951-01-100 for ; Wed, 10 Nov 2010 09:51:16 +0100 (CET) Received: from localhost (bo-stwhv-fw02.de.tmr.net [212.23.140.253]) by bo-uwka-srv01.de.tmr.net (Postfix) with ESMTP id ED4661DE822 for ; Wed, 10 Nov 2010 09:51:15 +0100 (CET) Date: Wed, 10 Nov 2010 10:53:45 +0100 From: Alex Huth To: freebsd-net@FreeBSD.org Message-ID: <20101110095345.GC2222@borusse.ewmr.base> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Subject: Differences in network between 6.4 and 7.3 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 09:21:10 -0000 Hello! After a upgrade from 6.4 to 7.3 it seems that we have problems with the network. On the host are running several webserver and a squid, build with openpkg. I have installed the compat package to be sure that there are no problems with the libraries after the upgrade. Now we have network latency problems, with a wiki and bugzilla running on a DomU (seperate SLES 11 host). Also we get lots of open connection on another DomU where a webcontainer is running. In this case we have unreassembled packages and lots of dup ACK in the traffic. Any idea what to do and where to search for the problem? Thanks in advance Alex From owner-freebsd-net@FreeBSD.ORG Wed Nov 10 11:29:34 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7F48C106564A for ; Wed, 10 Nov 2010 11:29:34 +0000 (UTC) (envelope-from john@traktor.dnepro.net) Received: from smtp-out.dnepro.net (smtp-out.dnepro.net [195.24.131.41]) by mx1.freebsd.org (Postfix) with ESMTP id ED8258FC1A for ; Wed, 10 Nov 2010 11:29:33 +0000 (UTC) Received: from traktor.dnepro.net (localhost [127.0.0.1]) by traktor.dnepro.net (8.14.3/8.14.3) with ESMTP id oAAB4SkH044966 for ; Wed, 10 Nov 2010 13:04:28 +0200 (EET) (envelope-from john@traktor.dnepro.net) Received: (from john@localhost) by traktor.dnepro.net (8.14.3/8.14.3/Submit) id oAAB4SrI044965 for freebsd-net@freebsd.org; Wed, 10 Nov 2010 13:04:28 +0200 (EET) (envelope-from john) Date: Wed, 10 Nov 2010 13:04:28 +0200 From: Eugene Perevyazko To: freebsd-net@freebsd.org Message-ID: <20101110110428.GA3505@traktor.dnepro.net> Mail-Followup-To: freebsd-net@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Subject: igb dual-port adapter 1200Mbps limit - what to tune? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 11:29:34 -0000 Hello, freebsd-net. I have a router running RELENG_7 with two dual-port igbs - igb0 and igb1 are on 82575 on intel s5520ur mb and igb2 and igb3 are on 82576 on ET dual-port card. 82576 is in 8x slot. Main traffic flows from igb0+igb1 to igb2+igb3, less traffic goes back. There's no traffic flow in directions igb0 - igb1 and igb2 - igb3. There are vlans on all interfaces. igb0 and igb1 are outbound links. igb2 and igb3 are connected to switch. CPU is E5620@2.4GHz, 8 cores, irqs bound to different cores skipping HT ones. Tried 2 queues and 1 queue per iface, neither hitting cpu limit. The problem is that traffic through igb2+igb3 is limited at around 1200Mbps Tx while I was hoping for 1600-1800Mbps Tx. I've tried aggregating igb2 and igb3 in roundrobin lagg - then load is evenly distributed between them at ~600Mbps. Without aggregating peak load on one of them corresponds to sag on another. But the sum of igb2 tx + igb3 tx is never higher than 1200Mbps. Combination of forwarded traffic and netperf from this host is limited with the same number. Is it at all possible to get 1600+Mbps Tx on dual-port card? What should I tune to get it if yes? Will adding one more ET adapter help if no? Current settings are: rc.conf: ifconfig_igb0="-tso -lro up" ifconfig_igb1="-tso -lro up" ifconfig_igb2="-tso -lro up" ifconfig_igb3="-tso -lro up" ifconfig_vlan37="vlan 37 vlandev igb0" ifconfig_vlan1812="vlan 1812 vlandev igb1" ifconfig_vlan3003="vlan 3003 vlandev igb2" ifconfig_vlan3004="vlan 3004 vlandev igb3" sysctl.conf: net.inet.ip.intr_queue_maxlen=5000 net.inet.ip.redirect=0 net.inet.icmp.drop_redirect=1 net.inet.ip.fastforwarding=1 loader.conf: hw.igb.num_queues=1 hw.igb.enable_aim=1 hw.igb.low_latency=1000 hw.igb.ave_latency=2000 hw.igb.bulk_latency=4000 hw.igb.rx_process_limit=1000 hw.igb.fc_setting=0 ifconfig: igb0: flags=8843 metric 0 mtu 1500 options=bb ether 00:15:17:bd:27:48 media: Ethernet autoselect (1000baseTX ) status: active igb1: flags=8843 metric 0 mtu 1500 options=bb ether 00:15:17:bd:27:49 media: Ethernet autoselect (1000baseTX ) status: active igb2: flags=8843 metric 0 mtu 1500 options=bb ether 00:1b:21:5e:f4:34 media: Ethernet autoselect (1000baseTX ) status: active igb3: flags=8843 metric 0 mtu 1500 options=bb ether 00:1b:21:5e:f4:35 media: Ethernet autoselect (1000baseTX ) status: active dmesg: igb0: port 0x2020-0x203f mem 0xb2520000-0xb253ffff,0xb2544000-0xb2547fff irq 40 at device 0.0 on pci1 igb0: Using MSIX interrupts with 2 vectors igb0: [ITHREAD] igb0: [ITHREAD] igb0: Ethernet address: 00:15:17:bd:27:48 igb1: port 0x2000-0x201f mem 0xb2500000-0xb251ffff,0xb2540000-0xb2543fff irq 28 at device 0.1 on pci1 igb1: Using MSIX interrupts with 2 vectors igb1: [ITHREAD] igb1: [ITHREAD] igb1: Ethernet address: 00:15:17:bd:27:49 igb2: port 0x1020-0x103f mem 0xb2420000-0xb243ffff,0xb2000000-0xb23fffff,0xb24c4000-0xb24c7fff irq 30 at device 0.0 on pci4 igb2: Using MSIX interrupts with 2 vectors igb2: [ITHREAD] igb2: [ITHREAD] igb2: Ethernet address: 00:1b:21:5e:f4:34 igb3: port 0x1000-0x101f mem 0xb2400000-0xb241ffff,0xb1c00000-0xb1ffffff,0xb24c0000-0xb24c3fff irq 37 at device 0.1 on pci4 igb3: Using MSIX interrupts with 2 vectors igb3: [ITHREAD] igb3: [ITHREAD] igb3: Ethernet address: 00:1b:21:5e:f4:35 pciconf -lvc: igb0@pci0:1:0:0: class=0x020000 card=0x34de8086 chip=0x10a78086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82575EB Gigabit Network Connection' class = network subclass = ethernet cap 01[40] = powerspec 2 supports D0 D3 current D0 cap 05[50] = MSI supports 1 message, 64 bit cap 11[60] = MSI-X supports 10 messages in map 0x1c enabled cap 10[a0] = PCI-Express 2 endpoint max data 256(256) link x4(x4) igb1@pci0:1:0:1: class=0x020000 card=0x34de8086 chip=0x10a78086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82575EB Gigabit Network Connection' class = network subclass = ethernet cap 01[40] = powerspec 2 supports D0 D3 current D0 cap 05[50] = MSI supports 1 message, 64 bit cap 11[60] = MSI-X supports 10 messages in map 0x1c enabled cap 10[a0] = PCI-Express 2 endpoint max data 256(256) link x4(x4) igb2@pci0:4:0:0: class=0x020000 card=0xa03c8086 chip=0x10c98086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' class = network subclass = ethernet cap 01[40] = powerspec 3 supports D0 D3 current D0 cap 05[50] = MSI supports 1 message, 64 bit, vector masks cap 11[70] = MSI-X supports 10 messages in map 0x1c enabled cap 10[a0] = PCI-Express 2 endpoint max data 256(512) link x4(x4) igb3@pci0:4:0:1: class=0x020000 card=0xa03c8086 chip=0x10c98086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' class = network subclass = ethernet cap 01[40] = powerspec 3 supports D0 D3 current D0 cap 05[50] = MSI supports 1 message, 64 bit, vector masks cap 11[70] = MSI-X supports 10 messages in map 0x1c enabled cap 10[a0] = PCI-Express 2 endpoint max data 256(512) link x4(x4) -- Eugene Perevyazko From owner-freebsd-net@FreeBSD.ORG Wed Nov 10 11:53:38 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7708B1065670 for ; Wed, 10 Nov 2010 11:53:38 +0000 (UTC) (envelope-from sthaug@nethelp.no) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by mx1.freebsd.org (Postfix) with SMTP id AD99E8FC1F for ; Wed, 10 Nov 2010 11:53:37 +0000 (UTC) Received: (qmail 53807 invoked from network); 10 Nov 2010 11:53:34 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 10 Nov 2010 11:53:34 -0000 Date: Wed, 10 Nov 2010 12:53:34 +0100 (CET) Message-Id: <20101110.125334.41669215.sthaug@nethelp.no> To: freebsd-net@freebsd.org From: sthaug@nethelp.no X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: How to generate IPv6 RA without any prefixes? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 11:53:38 -0000 In IPv6 it should be possible to generate a Router Advertisement which contains no prefix options (the idea being that I want the host to populate its default router list but nothing else). However, I cannot seem to get rtadvd to do this. If I start rtadvd with no /etc/rtadvd.conf file, it sends RAs with a prefix option corresponding to the IPv6 address of the interface. In the /etc/rtadvd.conf I can explicitly specify prefixes ("addr"), but I can't find any way to specify that no prefix options should be sent. Any suggestions? Steinar Haug, Nethelp consulting, sthaug@nethelp.no From owner-freebsd-net@FreeBSD.ORG Wed Nov 10 11:57:27 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D0068106566B for ; Wed, 10 Nov 2010 11:57:27 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 89B168FC17 for ; Wed, 10 Nov 2010 11:57:27 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1PG9Is-00049D-Dk for freebsd-net@freebsd.org; Wed, 10 Nov 2010 12:57:26 +0100 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 10 Nov 2010 12:57:26 +0100 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 10 Nov 2010 12:57:26 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: Ivan Voras Date: Wed, 10 Nov 2010 12:57:16 +0100 Lines: 5 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101102 Thunderbird/3.1.6 In-Reply-To: X-Enigmail-Version: 1.1.2 Subject: Re: bjoern just received the itojun award at the ietf X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 11:57:27 -0000 On 11/10/10 10:15, Randy Bush wrote: > bjoern zeeb just received the itojun award. congratulations, bjoern. > and than you for all the hard work on the ipv6 stack. Congratulations! :) From owner-freebsd-net@FreeBSD.ORG Wed Nov 10 12:05:03 2010 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B12C5106564A; Wed, 10 Nov 2010 12:05:03 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 84C108FC12; Wed, 10 Nov 2010 12:05:03 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 1DC4B46B0D; Wed, 10 Nov 2010 07:05:03 -0500 (EST) Date: Wed, 10 Nov 2010 12:05:02 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Randy Bush , bz@FreeBSD.org In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net Subject: Re: bjoern just received the itojun award at the ietf X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 12:05:03 -0000 On Wed, 10 Nov 2010, Randy Bush wrote: > bjoern zeeb just received the itojun award. congratulations, bjoern. and > than you for all the hard work on the ipv6 stack. Indeed -- many congratulations, Bjoern! The slow road from an experimental protocol in an experimental network stack to one widely depoyed in production has been possible only because of the efforts of developers like Bjoern. People don't often get excited about large numbers of apparently incremental improvements, even when the results are far more than incremental, but they should! This award is fitting, and emphasizes the importantance of exactly those sorts of contributions. IPv6 won't happen without them. Just to point out one example of the kind of easily missed but vitally important work that he's done: converging the IPv4 and IPv6 implementations in the FreeBSD kernel in order that they get the same levels of maintenance, performance optimization, etc, which is both hard work and critical work. Otherwise, the IPv6 code base risks getting sidelined just as it's becoming most important. He's similarly acted as the flag-waver within our own community for the last few years to make sure that new network stack features support IPv6 as well as they do IPv4. And, in case anyone has missed it: when you're adding a new network stack feature, even if your own network is just IPv4, don't forget that there are large and important pools of IPv6 in the world! This is really a chance for the FreeBSD community to lead the way, rather than follow. Robert From owner-freebsd-net@FreeBSD.ORG Wed Nov 10 14:56:13 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DF9EF106564A for ; Wed, 10 Nov 2010 14:56:13 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 716488FC18 for ; Wed, 10 Nov 2010 14:56:13 +0000 (UTC) Received: by eyb7 with SMTP id 7so316222eyb.13 for ; Wed, 10 Nov 2010 06:56:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=MZ9Icvwx1KbpFUiJ8VJ75/BhniALNpSE1XbOrH94Phk=; b=SZkkYM/3JaEyOOodF8S0JBoCkzTHnrZzETpC05l3edCHtaKyk/klJFSG+JPYUYPrgB cwC+DEiLvUb8vxfpb/ftA5HCKejQwlGeT8yWhBlYS9UbpCmV1J/pu8iKHriNY9KTDdg5 MJOD5vot17BHNW2p/UL0ZoIQAtxm4shioLad8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=rlD7E3XAl/X2Tt4HVuceRTb9T21C/AAFAAqEDUjDwU6r6I35ekVjQJkKkMJ8gSndfn 6hbwz3KyE7KzvKUdCGvEwt3D7RO6hHjdXKonKdFHchspcCRL91ymru/aXAyPU2++YjcO Ejl9IzeKUys0GiDgsgzmRYedSlUrQKpYn6RCE= MIME-Version: 1.0 Received: by 10.216.20.66 with SMTP id o44mr4242466weo.59.1289400970921; Wed, 10 Nov 2010 06:56:10 -0800 (PST) Received: by 10.216.50.140 with HTTP; Wed, 10 Nov 2010 06:56:10 -0800 (PST) Date: Wed, 10 Nov 2010 14:56:10 +0000 Message-ID: From: Paul B Mahol To: net@freebsd.org Content-Type: multipart/mixed; boundary=0016364c762bd848430494b40e1f Cc: Subject: ndis: properly allocate memory X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 14:56:14 -0000 --0016364c762bd848430494b40e1f Content-Type: text/plain; charset=ISO-8859-1 Hi, Attached patch resolves buggy allocation of memory in NDISulator. Correct behavior is to not ignore parameters specified by miniport driver. --0016364c762bd848430494b40e1f Content-Type: text/plain; charset=US-ASCII; name="ndis.txt" Content-Disposition: attachment; filename="ndis.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: file0 ZGlmZiAtLWdpdCBhL3NyYy9zeXMvY29tcGF0L25kaXMvc3Vicl9udG9za3JubC5jIGIvc3JjL3N5 cy9jb21wYXQvbmRpcy9zdWJyX250b3Nrcm5sLmMKaW5kZXggMDQxODRhZS4uZjE2OWRlNSAxMDA2 NDQKLS0tIGEvc3JjL3N5cy9jb21wYXQvbmRpcy9zdWJyX250b3Nrcm5sLmMKKysrIGIvc3JjL3N5 cy9jb21wYXQvbmRpcy9zdWJyX250b3Nrcm5sLmMKQEAgLTI0MjYsMTIgKzI0MjYsOSBAQCBNbUFs bG9jYXRlQ29udGlndW91c01lbW9yeVNwZWNpZnlDYWNoZShzaXplLCBsb3dlc3QsIGhpZ2hlc3Qs CiAJdWludDY0X3QJCWJvdW5kYXJ5OwogCXVpbnQzMl90CQljYWNoZXR5cGU7CiB7Ci0Jdm9pZCAq YWRkcjsKLQlzaXplX3QgcGFnZWxlbmd0aCA9IHJvdW5kdXAoc2l6ZSwgUEFHRV9TSVpFKTsKLQot CWFkZHIgPSBFeEFsbG9jYXRlUG9vbFdpdGhUYWcoTm9uUGFnZWRQb29sLCBwYWdlbGVuZ3RoLCAw KTsKIAotCXJldHVybiAoYWRkcik7CisJcmV0dXJuIChjb250aWdtYWxsb2Moc2l6ZSwgTV9ERVZC VUYsIE1fWkVST3xNX05PV0FJVCwgbG93ZXN0LAorCSAgICBoaWdoZXN0LCBQQUdFX1NJWkUsIGJv dW5kYXJ5KSk7CiB9CiAKIHN0YXRpYyB2b2lkCkBAIC0yNDQ3LDcgKzI0NDQsNyBAQCBNbUZyZWVD b250aWd1b3VzTWVtb3J5U3BlY2lmeUNhY2hlKGJhc2UsIHNpemUsIGNhY2hldHlwZSkKIAl1aW50 MzJfdAkJc2l6ZTsKIAl1aW50MzJfdAkJY2FjaGV0eXBlOwogewotCUV4RnJlZVBvb2woYmFzZSk7 CisJY29udGlnZnJlZShiYXNlLCBzaXplLCBNX0RFVkJVRik7CiB9CiAKIHN0YXRpYyB1aW50MzJf dAo= --0016364c762bd848430494b40e1f-- From owner-freebsd-net@FreeBSD.ORG Wed Nov 10 15:44:07 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 057E9106564A for ; Wed, 10 Nov 2010 15:44:07 +0000 (UTC) (envelope-from lists@yamagi.org) Received: from mail.yamagi.overkill.yamagi.org (unknown [IPv6:2a01:4f8:121:2102:1::7]) by mx1.freebsd.org (Postfix) with ESMTP id 8D8558FC13 for ; Wed, 10 Nov 2010 15:44:06 +0000 (UTC) Received: from [2001:6f8:108a:1:21b:21ff:fe07:b562] (unknown [IPv6:2001:6f8:108a:1:21b:21ff:fe07:b562]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yamagi.overkill.yamagi.org (Postfix) with ESMTPSA id 3437716663D1; Wed, 10 Nov 2010 16:44:03 +0100 (CET) Date: Wed, 10 Nov 2010 16:43:57 +0100 (CET) From: Yamagi Burmeister X-X-Sender: yamagi@saya.home.yamagi.org To: Ian Smith In-Reply-To: <20101110172151.I76697@sola.nimnet.asn.au> Message-ID: References: <20101109011410.GB1275@michelle.cdnetworks.com> <20101109190713.GA7766@michelle.cdnetworks.com> <20101109213421.GE7766@michelle.cdnetworks.com> <20101110172151.I76697@sola.nimnet.asn.au> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org, Yamagi Burmeister Subject: Re: [patch] WOL support for nfe(4) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 15:44:07 -0000 On Wed, 10 Nov 2010, Ian Smith wrote: > On Tue, 9 Nov 2010, Pyun YongHyeon wrote: > > On Tue, Nov 09, 2010 at 10:01:36PM +0100, Yamagi Burmeister wrote: > > > On Tue, 9 Nov 2010, Pyun YongHyeon wrote: > [..] > > > >You can switch to suspend mode with "acpiconf -s1". If all goes > > > >well, driver would put the controller into suspend mode after > > > >reprogramming controller to accept WOL frames. After that, you can > > > >wakeup the box by sending a WOL magic packet. > > > > > > Okay, It thought that S3 is required. Put the box into S1, waited some > > > minutes and send the magic packet. The video didn't resume but I was > > > able to login via SSH. So waking up by sending the WOL magic packet > > > works. > > > > > > > Thanks for testing. Probably you want to poke jkim@ to address > > video resume issue. > > It _may_ be just a matter of toggling the value of hw.acpi.reset_video ? No, it doesn't. But... This is a ~5 years old die hard server board. Those machines a running headless, only this test box has a graphics adapter plugged into it. Not even a new one, but an old Geforce FX 5300 PCIe which isn't supported by nVidia any more. The manpower required to get this working is better spend on other ACPI tasks or modern hardware. -- Homepage: www.yamagi.org Jabber: yamagi@yamagi.org GnuPG/GPG: 0xEFBCCBCB From owner-freebsd-net@FreeBSD.ORG Wed Nov 10 17:36:07 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1A913106564A for ; Wed, 10 Nov 2010 17:36:07 +0000 (UTC) (envelope-from bschmidt@techwires.net) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id CD88C8FC14 for ; Wed, 10 Nov 2010 17:36:06 +0000 (UTC) Received: by qwj8 with SMTP id 8so72621qwj.13 for ; Wed, 10 Nov 2010 09:36:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.240.4 with SMTP id ky4mr7811515qcb.104.1289410565805; Wed, 10 Nov 2010 09:36:05 -0800 (PST) Sender: bschmidt@techwires.net Received: by 10.229.213.73 with HTTP; Wed, 10 Nov 2010 09:36:05 -0800 (PST) X-Originating-IP: [84.180.237.1] In-Reply-To: References: Date: Wed, 10 Nov 2010 18:36:05 +0100 X-Google-Sender-Auth: 2AdZU1-Hp3HqE99eUUd3tIpx2qc Message-ID: From: Bernhard Schmidt To: Paul B Mahol Content-Type: text/plain; charset=ISO-8859-1 Cc: net@freebsd.org Subject: Re: ndis: properly allocate memory X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 17:36:07 -0000 On Wed, Nov 10, 2010 at 15:56, Paul B Mahol wrote: > Hi, > > Attached patch resolves buggy allocation of memory in NDISulator. > Correct behavior is to not ignore parameters specified by miniport driver. The important point to mention here is that those restrictions are to be applied to physical memory according to specs for MmAllocateContiguousMemorySpecifyCache(), therefore the call to contigmalloc(). I'll take care of the commit. -- Bernhard From owner-freebsd-net@FreeBSD.ORG Wed Nov 10 22:52:46 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 19E7E106564A for ; Wed, 10 Nov 2010 22:52:46 +0000 (UTC) (envelope-from gumbo@bsdmail.org) Received: from imr-da01.mx.aol.com (imr-da01.mx.aol.com [205.188.105.143]) by mx1.freebsd.org (Postfix) with ESMTP id CA1A18FC19 for ; Wed, 10 Nov 2010 22:52:45 +0000 (UTC) Received: from imo-da04.mx.aol.com (imo-da04.mx.aol.com [205.188.169.202]) by imr-da01.mx.aol.com (8.14.1/8.14.1) with ESMTP id oAAMgenT009130 for ; Wed, 10 Nov 2010 17:42:40 -0500 Received: from gumbo@bsdmail.org by imo-da04.mx.aol.com (mail_out_v42.9.) id n.fd5.20f4129 (37531) for ; Wed, 10 Nov 2010 17:42:37 -0500 (EST) Received: from smtprly-db02.mx.aol.com (smtprly-db02.mx.aol.com [205.188.249.153]) by cia-mb01.mx.aol.com (v129.5) with ESMTP id MAILCIAMB014-5c394cdb1fd8317; Wed, 10 Nov 2010 17:42:37 -0500 Received: from web-mmc-d04 (web-mmc-d04.sim.aol.com [205.188.103.94]) by smtprly-db02.mx.aol.com (v129.5) with ESMTP id MAILSMTPRLYDB027-5c394cdb1fd8317; Wed, 10 Nov 2010 17:42:32 -0500 To: freebsd-net@freebsd.org Date: Wed, 10 Nov 2010 17:42:31 -0500 X-MB-Message-Source: WebUI X-AOL-IP: 67.180.99.85 X-MB-Message-Type: User MIME-Version: 1.0 From: gumbo@bsdmail.org X-Mailer: Mail.com Webmail 32843-STANDARD Received: from 67.180.99.85 by web-mmc-d04.sysops.aol.com (205.188.103.94) with HTTP (WebMailUI); Wed, 10 Nov 2010 17:42:31 -0500 Message-Id: <8CD4F3FB222E6E1-1F14-11DA0@web-mmc-d04.sysops.aol.com> X-Spam-Flag: NO X-AOL-SENDER: gumbo@bsdmail.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: ipfw fwd doesn't handle ipv6 addresses X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 22:52:46 -0000 I'm running freebsd 7.2 and trying to find a way to forward a packet based= on it's source address. The following command works fine for ipv4 addresses but fails for ipv6 add= resses. ipfw add 101 fwd nextaddr ip from myaddr to any out This works fine if nextaddr and myaddr are ipv4 but fails to work if they= are ipv6. Is this not yet supported or is there another way to accomplish the same= thing ? Thanks for any insight, Rick From owner-freebsd-net@FreeBSD.ORG Wed Nov 10 23:42:28 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 70090106564A for ; Wed, 10 Nov 2010 23:42:28 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3B5458FC13 for ; Wed, 10 Nov 2010 23:42:27 +0000 (UTC) Received: by pvc22 with SMTP id 22so333019pvc.13 for ; Wed, 10 Nov 2010 15:42:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=TphuLLmCKeZlaB3CT+bCG3DgXcITUppb7vDG//uLeAc=; b=tmqHunSk86MkGufT7G41mXyqzcIeiwCdIPyzcwa3+/179SPyzVZpXIO4CuiWXTfNBj gnsZvzYk1QvZfWr+yuNYL1xXKjzr9PLdPnJXRqz0vFtte4qGUekv4UE7eA7EECdOnkTJ EOIHmcx3du8AMMxiV8xY27ZcrP4/DpyxIBnCk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=K65tx30zVtpQcSoiThh9ml+ah/ZsVSjyTGDqNsJ6v0w6EEMX9bdPHykyzJEbjZ7MEs CNly3b0l4B1vlW3sVjMfIt9VYdEptv78+fJgevH3eSLP9p2jIA2Tn2E0Qcga/0RzY6Hs oQRZ4oFdO62vWevvygPZYjk9BJOZf1zQsmP84= Received: by 10.142.97.15 with SMTP id u15mr8190631wfb.389.1289432546055; Wed, 10 Nov 2010 15:42:26 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id w14sm1494536wfd.6.2010.11.10.15.42.22 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 10 Nov 2010 15:42:23 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Wed, 10 Nov 2010 15:41:28 -0800 From: Pyun YongHyeon Date: Wed, 10 Nov 2010 15:41:28 -0800 To: Yamagi Burmeister Message-ID: <20101110234128.GC13340@michelle.cdnetworks.com> References: <20101109011410.GB1275@michelle.cdnetworks.com> <20101109190713.GA7766@michelle.cdnetworks.com> <20101109213421.GE7766@michelle.cdnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101109213421.GE7766@michelle.cdnetworks.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: [patch] WOL support for nfe(4) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 23:42:28 -0000 On Tue, Nov 09, 2010 at 01:34:21PM -0800, Pyun YongHyeon wrote: > On Tue, Nov 09, 2010 at 10:01:36PM +0100, Yamagi Burmeister wrote: > > On Tue, 9 Nov 2010, Pyun YongHyeon wrote: > > > > >>No, the link stays at 1000Mbps so the driver must manually switch back > > >>to 10/100Mbps. > > >> > > > > > >Hmm, this is real problem for WOL. Establishing 1000Mbps link to > > >accept WOL frames is really bad idea since it can draw more power > > >than 375mA. Consuming more power than 375mA is violation of > > >PCI specification and some system may completely shutdown the power > > >to protect hardware against over-current damage which in turn means > > >WOL wouldn't work anymore. Even if WOL work with 1000Mbps link for > > >all nfe(4) controllers, it would dissipate much more power. > > > > > >Because nfe(4) controllers are notorious for using various PHYs, > > >it's hard to write a code to reliably establish 10/100Mbps link in > > >driver. In addition, nfe(4) is known to be buggy in link state > > >handling such that forced media selection didn't work well. I'll > > >see what could be done in this week if I find spare time. > > > > Hmm... Maybe just add a hint to the manpage that WOL is possible broken? > > I think this may not be enough. Because it can damage your hardware > under certain conditions if protection circuit was not there. > Ok, I updated patch which will change link speed to 10/100Mps when shutdown/suspend is initiated. You can get the patch at the following URL. Please give it a try and let me know whether it really changes link speed to 10/100Mbps. If it does not work as expected, show me the dmesg output of your system. http://people.freebsd.org/~yongari/nfe/nfe.wol.patch2 > > Nevertheless thanks for your work it's much appreciated :) > > > > >>>o When you put your box into suspend mode, can you wake up your box > > >>>with WOL magic packet? > > >> > > >>I'm sorry but I can't test that since none of those boxes supports > > >>suspend: > > >> > > >> % sysctl hw.acpi.suspend_state > > >> hw.acpi.suspend_state: NONE > > >> > > > > > >You can switch to suspend mode with "acpiconf -s1". If all goes > > >well, driver would put the controller into suspend mode after > > >reprogramming controller to accept WOL frames. After that, you can > > >wakeup the box by sending a WOL magic packet. > > > > Okay, It thought that S3 is required. Put the box into S1, waited some > > minutes and send the magic packet. The video didn't resume but I was > > able to login via SSH. So waking up by sending the WOL magic packet > > works. > > > > Thanks for testing. Probably you want to poke jkim@ to address > video resume issue. From owner-freebsd-net@FreeBSD.ORG Thu Nov 11 00:47:20 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5B698106566C for ; Thu, 11 Nov 2010 00:47:20 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 10D7E8FC16 for ; Thu, 11 Nov 2010 00:47:19 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1PGLJu-0005rq-Ou for freebsd-net@freebsd.org; Thu, 11 Nov 2010 01:47:18 +0100 Received: from cpe-188-129-99-141.dynamic.amis.hr ([188.129.99.141]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 11 Nov 2010 01:47:18 +0100 Received: from ivoras by cpe-188-129-99-141.dynamic.amis.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 11 Nov 2010 01:47:18 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: Ivan Voras Date: Thu, 11 Nov 2010 01:47:02 +0100 Lines: 12 Message-ID: References: <20101110110428.GA3505@traktor.dnepro.net> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: cpe-188-129-99-141.dynamic.amis.hr User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101102 Thunderbird/3.1.6 In-Reply-To: <20101110110428.GA3505@traktor.dnepro.net> Subject: Re: igb dual-port adapter 1200Mbps limit - what to tune? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 00:47:20 -0000 On 11/10/10 12:04, Eugene Perevyazko wrote: > CPU is E5620@2.4GHz, 8 cores, irqs bound to different cores skipping HT ones. Unless you need the CPU cores for other tasks on the server, they won't help you with network throughput here. Faster but fewer cores might. > Tried 2 queues and 1 queue per iface, neither hitting cpu limit. Are you sure you are not hitting the CPU limit on individual cores? Have you tried running "top -H -S"? From owner-freebsd-net@FreeBSD.ORG Thu Nov 11 06:31:47 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 864481065679 for ; Thu, 11 Nov 2010 06:31:47 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx23.fluidhosting.com [204.14.89.6]) by mx1.freebsd.org (Postfix) with ESMTP id 0D2F68FC17 for ; Thu, 11 Nov 2010 06:31:46 +0000 (UTC) Received: (qmail 15784 invoked by uid 399); 11 Nov 2010 06:31:46 -0000 Received: from localhost (HELO doug-optiplex.ka9q.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 11 Nov 2010 06:31:46 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4CDB8DD1.4010808@FreeBSD.org> Date: Wed, 10 Nov 2010 22:31:45 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101028 Thunderbird/3.1.6 MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <8CD4F3FB222E6E1-1F14-11DA0@web-mmc-d04.sysops.aol.com> In-Reply-To: <8CD4F3FB222E6E1-1F14-11DA0@web-mmc-d04.sysops.aol.com> X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: ipfw fwd doesn't handle ipv6 addresses X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 06:31:47 -0000 On 11/10/2010 14:42, gumbo@bsdmail.org wrote: > I'm running freebsd 7.2 and trying to find a way to forward a packet > based on it's source address. The following command works fine for > ipv4 addresses but fails for ipv6 addresses. ipfw add 101 fwd > nextaddr ip from myaddr to any out This works fine if nextaddr and > myaddr are ipv4 but fails to work if they are ipv6. Is this not yet > supported or is there another way to accomplish the same thing ? You might want to take a look at the ipfw man page, I think what you want is me6, not myaddr. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-net@FreeBSD.ORG Thu Nov 11 07:08:35 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 92F631065674 for ; Thu, 11 Nov 2010 07:08:35 +0000 (UTC) (envelope-from lists@yamagi.org) Received: from mail.yamagi.overkill.yamagi.org (unknown [IPv6:2a01:4f8:121:2102:1::7]) by mx1.freebsd.org (Postfix) with ESMTP id 270DC8FC16 for ; Thu, 11 Nov 2010 07:08:34 +0000 (UTC) Received: from [2001:6f8:108a:1:21b:21ff:fe07:b562] (unknown [IPv6:2001:6f8:108a:1:21b:21ff:fe07:b562]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yamagi.overkill.yamagi.org (Postfix) with ESMTPSA id 96CA916663D1; Thu, 11 Nov 2010 08:08:33 +0100 (CET) Date: Thu, 11 Nov 2010 08:08:25 +0100 (CET) From: Yamagi Burmeister X-X-Sender: yamagi@saya.home.yamagi.org To: Pyun YongHyeon In-Reply-To: <20101110234128.GC13340@michelle.cdnetworks.com> Message-ID: References: <20101109011410.GB1275@michelle.cdnetworks.com> <20101109190713.GA7766@michelle.cdnetworks.com> <20101109213421.GE7766@michelle.cdnetworks.com> <20101110234128.GC13340@michelle.cdnetworks.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org, Yamagi Burmeister Subject: Re: [patch] WOL support for nfe(4) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 07:08:35 -0000 On Wed, 10 Nov 2010, Pyun YongHyeon wrote: > On Tue, Nov 09, 2010 at 01:34:21PM -0800, Pyun YongHyeon wrote: >> On Tue, Nov 09, 2010 at 10:01:36PM +0100, Yamagi Burmeister wrote: >>> On Tue, 9 Nov 2010, Pyun YongHyeon wrote: >>> >>>>> No, the link stays at 1000Mbps so the driver must manually switch back >>>>> to 10/100Mbps. >>>>> >>>> >>>> Hmm, this is real problem for WOL. Establishing 1000Mbps link to >>>> accept WOL frames is really bad idea since it can draw more power >>>> than 375mA. Consuming more power than 375mA is violation of >>>> PCI specification and some system may completely shutdown the power >>>> to protect hardware against over-current damage which in turn means >>>> WOL wouldn't work anymore. Even if WOL work with 1000Mbps link for >>>> all nfe(4) controllers, it would dissipate much more power. >>>> >>>> Because nfe(4) controllers are notorious for using various PHYs, >>>> it's hard to write a code to reliably establish 10/100Mbps link in >>>> driver. In addition, nfe(4) is known to be buggy in link state >>>> handling such that forced media selection didn't work well. I'll >>>> see what could be done in this week if I find spare time. >>> >>> Hmm... Maybe just add a hint to the manpage that WOL is possible broken? >> >> I think this may not be enough. Because it can damage your hardware >> under certain conditions if protection circuit was not there. >> > > Ok, I updated patch which will change link speed to 10/100Mps when > shutdown/suspend is initiated. You can get the patch at the > following URL. Please give it a try and let me know whether it > really changes link speed to 10/100Mbps. If it does not work as > expected, show me the dmesg output of your system. > > http://people.freebsd.org/~yongari/nfe/nfe.wol.patch2 Okay, that does the trick. At shutdown the link speed is changed to 10/100Mbps, at boot - either via WOL magic packet or manuell startup - it's changed back to 1000Mbps. Thanks again, Yamagi -- Homepage: www.yamagi.org Jabber: yamagi@yamagi.org GnuPG/GPG: 0xEFBCCBCB From owner-freebsd-net@FreeBSD.ORG Thu Nov 11 10:49:55 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C988C1065673 for ; Thu, 11 Nov 2010 10:49:55 +0000 (UTC) (envelope-from john@traktor.dnepro.net) Received: from smtp-out.dnepro.net (smtp-out.dnepro.net [195.24.131.41]) by mx1.freebsd.org (Postfix) with ESMTP id 3EAFA8FC0C for ; Thu, 11 Nov 2010 10:49:54 +0000 (UTC) Received: from traktor.dnepro.net (localhost [127.0.0.1]) by traktor.dnepro.net (8.14.3/8.14.3) with ESMTP id oABAnqQu013023 for ; Thu, 11 Nov 2010 12:49:52 +0200 (EET) (envelope-from john@traktor.dnepro.net) Received: (from john@localhost) by traktor.dnepro.net (8.14.3/8.14.3/Submit) id oABAnqnd013020 for freebsd-net@freebsd.org; Thu, 11 Nov 2010 12:49:52 +0200 (EET) (envelope-from john) Date: Thu, 11 Nov 2010 12:49:52 +0200 From: Eugene Perevyazko To: freebsd-net@freebsd.org Message-ID: <20101111104952.GA11275@traktor.dnepro.net> Mail-Followup-To: freebsd-net@freebsd.org References: <20101110110428.GA3505@traktor.dnepro.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Subject: Re: igb dual-port adapter 1200Mbps limit - what to tune? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 10:49:55 -0000 On Thu, Nov 11, 2010 at 01:47:02AM +0100, Ivan Voras wrote: > On 11/10/10 12:04, Eugene Perevyazko wrote: > > >CPU is E5620@2.4GHz, 8 cores, irqs bound to different cores skipping HT > >ones. > > Unless you need the CPU cores for other tasks on the server, they won't > help you with network throughput here. Faster but fewer cores might. > > >Tried 2 queues and 1 queue per iface, neither hitting cpu limit. > > Are you sure you are not hitting the CPU limit on individual cores? Have > you tried running "top -H -S"? > Sure, even with 1queue per iface load is 40-60% on busy core, with 2 queues it was much lower. Now I've got the module for mb with 2 more ports, going to see if it helps. -- Eugene Perevyazko From owner-freebsd-net@FreeBSD.ORG Thu Nov 11 14:37:59 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A8D68106566B for ; Thu, 11 Nov 2010 14:37:59 +0000 (UTC) (envelope-from cpenney@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 62ADF8FC12 for ; Thu, 11 Nov 2010 14:37:59 +0000 (UTC) Received: by gxk9 with SMTP id 9so1232998gxk.13 for ; Thu, 11 Nov 2010 06:37:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=K1NfL3UzaLSF64Mu7okfJCGcupPcLXX8G/BrXUN6PKY=; b=NQdQF3x8fLuOEaase1oBMIbk+IENCHa6qDtf8UzHIiyEy7b/750gwOTXCAd3M1QHRA giCRU4LFnJFEJyWtdSRaXugH+nNkN6rGTZ+TpTqosmjj4mJ4xA2SN1enqxOltPdyH8q3 IWrpElYFmEinAC2fYJuJ8TbgbHi73vgfIlEEU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; b=CttBIVzWjr/feqgP+K8SCz0w1t4eKjb1wpoIZfpCcg4oih6KDfdJ7sCo/ROStgrfuE CzdCu36x9D67/mrikydGL2MhyKXc8TJHxRvqJihdixVcF16/VxmvRqozzDPYPv8k6IS5 aeTDpsP2ge/Akcq1At08wCi/F4oEQvbjH40ms= MIME-Version: 1.0 Received: by 10.91.10.21 with SMTP id n21mr1544773agi.75.1289486175029; Thu, 11 Nov 2010 06:36:15 -0800 (PST) Sender: cpenney@gmail.com Received: by 10.90.166.3 with HTTP; Thu, 11 Nov 2010 06:36:14 -0800 (PST) Date: Thu, 11 Nov 2010 09:36:14 -0500 X-Google-Sender-Auth: J8MT4Zp_qSFxSM1OT1-Mbs66LFU Message-ID: From: Christopher Penney To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: FreeBSD TCP Behavior with Linux NAT X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 14:37:59 -0000 Hi, I have a curious problem I'm hoping someone can help with or at least educate me on. I have several large Linux clusters and for each one we hide the compute nodes behind a head node using NAT. Historically, this has worked very well for us and any time a NAT gateway (the head node) reboots everything recovers within a minute or two of it coming back up. This includes NFS mounts from Linux and Solaris NFS servers, license server connections, etc. Recently, we added a FreeBSD based NFS server to our cluster resources and have had significant issues with NFS mounts hanging if the head node reboots. We don't have this happen much, but it does occasionally happen. I've explored this and it seems the behavior of FreeBSD differs a bit from at least Linux and Solaris with respect to TCP recovery. I'm curious if someone can explain this or offer any workarounds. Here are some specifics from a test I ran: Before the reboot two Linux clients were mounting the FreeBSD server. They were both using port 903 locally. On the head node clientA:903 was remapped to headnode:903 and clientB:903 was remapped to headnode:601. There is no activity when the reboot occurs. The head node takes a few minutes to come back up (we kept it down for several minutes). When it comes back up clientA and clientB try to reconnect to the FreeBSD NFS server. They both use the same source port, but since the head node's conntrack table is cleared it's a race to see who gets what port and this time clientA:903 appears as headnode:601 and clientB:903 appears as headnode:903 ( >>> they essentially switch places as far as the FreeBSD server would see <<< ). The FreeBSD NFS server, since there was no outstanding acks it was waiting on, thinks things are ok so when it gets a SYN from the two clients it only responds with an ACK. The ACK for each that it replies with is bogus (invalid seq number) because it's using the return path the other client was using before the reboot so the client sends a RST back, but it never gets to the FreeBSD system since the head node's NAT hasn't yet seen the full handshake (that would allow return packets). The end result is a "permanent" hang (at least until it would otherwise cleanup idle TCP connections). This is in stark contrast to the behavior of the other systems we have. Other systems respond to the SYN used to reconnect with a SYN/ACK. They appear to implicitly tear down the return path based on getting a SYN from a seemingly already established connection. I'm assuming this is one of the grey areas where there is no specific behavior outlined in an RFC? Is there any way to make the FreeBSD system more reliable in this situation (like making it implicitly tear down the return)? Or is there a way to adjust the NAT setup to allow the RST to return to the FreeBSD system? Currently, NAT is setup with simply: iptables -t nat -A POSTROUTING -s 10.1.0.0/16 -o bond0 -j SNAT --to 1.2.3.4 Where 1.2.3.4 is the intranet address and 10.1.0.0 is the cluster network. Thanks! Chris From owner-freebsd-net@FreeBSD.ORG Thu Nov 11 14:43:12 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E98EE1065670 for ; Thu, 11 Nov 2010 14:43:12 +0000 (UTC) (envelope-from cpenney@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id A64FF8FC08 for ; Thu, 11 Nov 2010 14:43:12 +0000 (UTC) Received: by ywa8 with SMTP id 8so681013ywa.13 for ; Thu, 11 Nov 2010 06:43:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=bovAig/Ug8x5Pu5nctZObvBUFYNbiIb8hkfE1GphgBc=; b=F+vaD6K3eLLgSqY3kKEbB3TYl/ypYKZyhWKukCYlGordNj6O5e2BD+RnVo7hXL/4cZ dL3kJ5iWOnZ8H7c10/WY6SobPuZU+Yj8oNaGpGPbgiC9JSIMJCzc2UR2wRQq+m2NDEgp CAgeXyvrnfS/NmB3YQ/z2rgGz6GFJj5/gurRI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=T+2iO6d7ImhGsWOKZpyMsxTYNV02V+lb6oXACNFwBFArvcnPhapz8cKdaSS9G41P6g qHHwhdybFMYs4IFDoqJPtoSaWW0DevTj4+GVNJL80HJDp6TCHSgfg7a4Uepeo6UpmfQv 7EFwbXJb5B0bkupvRA2d28eyzHZ1fkPoA8H48= MIME-Version: 1.0 Received: by 10.90.63.10 with SMTP id l10mr1451011aga.156.1289484736607; Thu, 11 Nov 2010 06:12:16 -0800 (PST) Received: by 10.90.166.3 with HTTP; Thu, 11 Nov 2010 06:12:16 -0800 (PST) Date: Thu, 11 Nov 2010 09:12:16 -0500 Message-ID: From: Christopher Penney To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: FreeBSD TCP Behavior with Linux NAT X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 14:43:13 -0000 Hi, I have a curious problem I'm hoping someone can help with or at least educate me on. I have several large Linux clusters and for each one we hide the compute nodes behind a head node using NAT. Historically, this has worked very well for us and any time a NAT gateway (the head node) reboots everything recovers within a minute or two of it coming back up. This includes NFS mounts from Linux and Solaris NFS servers, license server connections, etc. Recently, we added a FreeBSD based NFS server to our cluster resources and have had significant issues with NFS mounts hanging if the head node reboots. We don't have this happen much, but it does occasionally happen. I've explored this and it seems the behavior of FreeBSD differs a bit from at least Linux and Solaris with respect to TCP recovery. I'm curious if someone can explain this or offer any workarounds. Here are some specifics from a test I ran: Before the reboot two Linux clients were mounting the FreeBSD server. They were both using port 903 locally. On the head node clientA:903 was remapped to headnode:903 and clientB:903 was remapped to headnode:601. There is no activity when the reboot occurs. The head node takes a few minutes to come back up (we kept it down for several minutes). When it comes back up clientA and clientB try to reconnect to the FreeBSD NFS server. They both use the same source port, but since the head node's conntrack table is cleared it's a race to see who gets what port and this time clientA:903 appears as headnode:601 and clientB:903 appears as headnode:903 ( >>> they essentially switch places as far as the FreeBSD server would see <<< ). The FreeBSD NFS server, since there was no outstanding acks it was waiting on, thinks things are ok so when it gets a SYN from the two clients it only responds with an ACK. The ACK for each that it replies with is bogus (invalid seq number) because it's using the return path the other client was using before the reboot so the client sends a RST back, but it never gets to the FreeBSD system since the head node's NAT hasn't yet seen the full handshake (that would allow return packets). The end result is a "permanent" hang (at least until it would otherwise cleanup idle TCP connections). This is in stark contrast to the behavior of the other systems we have. Other systems respond to the SYN used to reconnect with a SYN/ACK. They appear to implicitly tear down the return path based on getting a SYN from a seemingly already established connection. I'm assuming this is one of the grey areas where there is no specific behavior outlined in an RFC? Is there any way to make the FreeBSD system more reliable in this situation (like making it implicitly tear down the return)? Or is there a way to adjust the NAT setup to allow the RST to return to the FreeBSD system? Currently, NAT is setup with simply: iptables -t nat -A POSTROUTING -s 10.1.0.0/16 -o bond0 -j SNAT --to 1.2.3.4 Where 1.2.3.4 is the intranet address and 10.1.0.0 is the cluster network. Thanks! Chris (not a list subscriber -- please CC if you can) From owner-freebsd-net@FreeBSD.ORG Thu Nov 11 15:51:46 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4E341106564A for ; Thu, 11 Nov 2010 15:51:46 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id CCC8C8FC0A for ; Thu, 11 Nov 2010 15:51:45 +0000 (UTC) Received: by fxm19 with SMTP id 19so1421484fxm.13 for ; Thu, 11 Nov 2010 07:51:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=TBNgk9Ing2pO8ADxfyfEm89qLuyckWLI1DmUp31wstk=; b=aNlM9GZVsQgL2pQQ32sP7VtABtDnGCs0z+nqZphLZpBDkzMvGv7DUh5n+c5uWhAmuT JLSWvr7fwW1yxkpfQtyujCcbRH0femThGT6fvO8kguxMKPy3k6ptJwUV1ua17pKpZh+v qBh/wdOqgN91Cv+IYSaI55t6kf9HK73Zp/aAY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:organization:user-agent:mime-version:to :cc:subject:references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=TBLOSK02fFvN+GnA06GBSUe0ixn5fJSMRM66VDFBH7Q0ZyRaV006h9BNqeL9fxCjpa n6ShUgDhkt3hDrwvqcCYpxKrIcIhqomUoZ3dv5V8xNGLyux3Wyy9xHeCVvIBD/GcSgN+ aoVX1ZsqJByliTGa27yRi8tL+qKQ6sdJ2Ji1A= Received: by 10.223.110.202 with SMTP id o10mr289980fap.1.1289489360093; Thu, 11 Nov 2010 07:29:20 -0800 (PST) Received: from centel.dataix.local (adsl-99-181-136-243.dsl.klmzmi.sbcglobal.net [99.181.136.243]) by mx.google.com with ESMTPS id r24sm23277fax.27.2010.11.11.07.29.15 (version=SSLv3 cipher=RC4-MD5); Thu, 11 Nov 2010 07:29:16 -0800 (PST) Sender: "J. Hellenthal" Message-ID: <4CDC0BCA.30304@DataIX.net> Date: Thu, 11 Nov 2010 10:29:14 -0500 From: jhell Organization: http://www.DataIX.net User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.12) Gecko/20101028 Lightning/1.0b1 Thunderbird MIME-Version: 1.0 To: Randy Bush References: In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net Subject: Re: bjoern just received the itojun award at the ietf X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 15:51:46 -0000 On 11/10/2010 04:15, Randy Bush wrote: > bjoern zeeb just received the itojun award. congratulations, bjoern. > and than you for all the hard work on the ipv6 stack. > > randy For this not understanding what this is or what its about: http://www.isoc.org/awards/itojun/ Where you will find Bjoern on the front page. Congrats! Bjoern You deserve it. -- jhell,v From owner-freebsd-net@FreeBSD.ORG Thu Nov 11 16:10:58 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7740F1065672; Thu, 11 Nov 2010 16:10:58 +0000 (UTC) (envelope-from oberman@es.net) Received: from mailgw.es.net (mail1.es.net [IPv6:2001:400:201:1::2]) by mx1.freebsd.org (Postfix) with ESMTP id 61BF98FC15; Thu, 11 Nov 2010 16:10:58 +0000 (UTC) Received: from ptavv.es.net (ptavv.es.net [IPv6:2001:400:910::29]) by mailgw.es.net (8.14.3/8.14.3) with ESMTP id oABGAvV6018721 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 11 Nov 2010 08:10:57 -0800 Received: from ptavv.es.net (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id CA5A71CC0E; Thu, 11 Nov 2010 08:10:57 -0800 (PST) To: Kirill Yelizarov In-reply-to: Your message of "Wed, 10 Nov 2010 23:49:56 PST." <816869.17580.qm@web120510.mail.ne1.yahoo.com> Date: Thu, 11 Nov 2010 08:10:57 -0800 From: "Kevin Oberman" Message-Id: <20101111161057.CA5A71CC0E@ptavv.es.net> Cc: freebsd-stable@freebsd.org, net@freebsd.org Subject: Re: icmp packets on em larger than 1472 [SEC=UNCLASSIFIED] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 16:10:58 -0000 > Date: Wed, 10 Nov 2010 23:49:56 -0800 (PST) > From: Kirill Yelizarov > > > > --- On Thu, 11/11/10, Kevin Oberman wrote: > > > From: Kevin Oberman > > Subject: Re: icmp packets on em larger than 1472 [SEC=UNCLASSIFIED] > > To: "Wilkinson, Alex" > > Cc: freebsd-stable@freebsd.org > > Date: Thursday, November 11, 2010, 8:26 AM > > > Date: Thu, 11 Nov 2010 13:01:26 > > +0800 > > > From: "Wilkinson, Alex" > > > Sender: owner-freebsd-stable@freebsd.org > > > > > > > > >     0n Wed, Nov 10, 2010 at > > 04:21:12AM -0800, Kirill Yelizarov wrote: > > > > > >     >All my em cards running > > 8.1 stable don't reply to icmp echo requests packets larger > > than 1472 bytes. > > >     > > > >     >On stable 7.2 the same > > hardware works as expected: > > >     ># ping -s 1500 > > 192.168.64.99 > > >     >PING 192.168.64.99 > > (192.168.64.99): 1500 data bytes > > >     >1508 bytes from > > 192.168.64.99: icmp_seq=0 ttl=63 time=1.249 ms > > >     >1508 bytes from > > 192.168.64.99: icmp_seq=1 ttl=63 time=1.158 ms > > >     > > > >     >Here is the dump on em > > interface > > >     >15:06:31.452043 IP > > 192.168.66.65 > *****: ICMP echo request, id 28729, seq > > 5, length 1480 > > >     >15:06:31.452047 IP > > 192.168.66.65 > ****: icmp > > >     >15:06:31.452069 IP **** > > > 192.168.66.65: ICMP echo reply, id 28729, seq 5, length > > 1480 > > >     >15:06:31.452071 IP *** > > > 192.168.66.65: icmp > > >     > > > >     >Same ping from same source > > (it's a 8.1 stable with fxp interface) to em card running > > 8.1 stable > > >     >#pciconf -lv > > >  > >    >em0@pci0:3:4:0:    > > class=0x020000 card=0x10798086 chip=0x10798086 rev=0x03 > > hdr=0x00 > > >     >    vendor  > >    = 'Intel Corporation' > > >     >    device  > >    = 'Dual Port Gigabit Ethernet Controller > > (82546EB)' > > >     >    class  > >     = network > > >     >    > > subclass   = ethernet > > >     > > > >     ># ping -s 1472 > > 192.168.64.200 > > >     >PING 192.168.64.200 > > (192.168.64.200): 1472 data bytes > > >     >1480 bytes from > > 192.168.64.200: icmp_seq=0 ttl=63 time=0.848 ms > > >     >^C > > >     > > > >     ># ping -s 1473 > > 192.168.64.200 > > >     >PING 192.168.64.200 > > (192.168.64.200): 1473 data bytes > > >     >^C > > >     >--- 192.168.64.200 ping > > statistics --- > > >     >4 packets transmitted, 0 > > packets received, 100.0% packet loss > > > > > > works fine for me: > > > > > > FreeBSD 8.1-STABLE #0 r213395 > > > > > > em0@pci0:0:25:0:class=0x020000 card=0x3035103c > > chip=0x10de8086 rev=0x02 hdr=0x00 > > >     vendor  > >    = 'Intel Corporation' > > >     device  > >    = 'Intel Gigabit network connection > > (82567LM-3 )' > > >     class      = > > network > > >     subclass   = > > ethernet > > > > > > #ping -s 1473 host > > > PING host(192.168.1.1): 1473 data bytes > > > 1481 bytes from 192.168.1.1: icmp_seq=0 ttl=253 > > time=31.506 ms > > > 1481 bytes from 192.168.1.1: icmp_seq=1 ttl=253 > > time=31.493 ms > > > 1481 bytes from 192.168.1.1: icmp_seq=2 ttl=253 > > time=31.550 ms > > > ^C > > > > The reason the '-s 1500' worked was that the packets were > > fragmented. If > > I add the '-D' option, '-s 1473' fails on v7 and v8. Are > > the V8 systems > > where you see if failing without the '-D' on the same > > network segment? > > If not, it is likely that an intervening device is refusing > > to fragment > > the packet. (Some routers deliberately don't fragment ICMP > > Echos Request > > packets.) > > If i set -D -s 1473 sender side refuses to ping and that is > correct. All mentioned above machines are behind the same router and > switch. Same hardware running v7 is working while v8 is not. And i > never saw such problems before. Also correct me if i'm wrong but the > dump shows that the packet arrived. I'll try driver from head and will > post here results. I did a bit more looking at this today and I see that something bogus is going on and it MAY be the em driver. I tried 1473 data byte pings without the DF flag. I then captured the packets on both ends (where the sending system has a bge (Broadcom GE) and the responding end has an em (Intel) card. What I saw was the fragmented IP packets all being received by the system with the em interface and an ICMP Echo Reply being sent back, again fragmented. I saw the reply on both ends, so both interfaces were able to fragment an over-sized packet, transmit the two pieces, and receive the two pieces. The em device could re-assemble them properly, but the bge device does not seem to re-assemble them correctly or else has a problem with ICMP packets bigger then MTU size. When I send from the em system, I see the packets and fragments all arrive in good form, but the system never sends out a reply. Since this is a kernel function, it may be a driver, but I suspect that it is in the IP stack since I am seeing the problem with a Broadcom card and I see the data all arriving. I think Jack can probably relax, but some patch to the network stack seems to have broken at least ICMP processing. And, since the bge system ups updated to 8-Stable on October 20 while the em system was updated back on August 9, I suspect the flaw was not driver related and was committed between August 9 and Oct. 20. I think this needs to go to the network list where the folks who tinker with that part of the kernel tend to hang out. Sorry for the cross-post. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From owner-freebsd-net@FreeBSD.ORG Thu Nov 11 18:05:45 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6299A106566C for ; Thu, 11 Nov 2010 18:05:45 +0000 (UTC) (envelope-from john@traktor.dnepro.net) Received: from smtp-out.dnepro.net (smtp-out.dnepro.net [195.24.131.41]) by mx1.freebsd.org (Postfix) with ESMTP id D41618FC14 for ; Thu, 11 Nov 2010 18:05:43 +0000 (UTC) Received: from traktor.dnepro.net (localhost [127.0.0.1]) by traktor.dnepro.net (8.14.3/8.14.3) with ESMTP id oABI5ei6057981 for ; Thu, 11 Nov 2010 20:05:40 +0200 (EET) (envelope-from john@traktor.dnepro.net) Received: (from john@localhost) by traktor.dnepro.net (8.14.3/8.14.3/Submit) id oABI5eF4057974 for freebsd-net@freebsd.org; Thu, 11 Nov 2010 20:05:40 +0200 (EET) (envelope-from john) Date: Thu, 11 Nov 2010 20:05:40 +0200 From: Eugene Perevyazko To: freebsd-net@freebsd.org Message-ID: <20101111180539.GC11275@traktor.dnepro.net> Mail-Followup-To: freebsd-net@freebsd.org References: <20101110110428.GA3505@traktor.dnepro.net> <20101111104952.GA11275@traktor.dnepro.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101111104952.GA11275@traktor.dnepro.net> User-Agent: Mutt/1.4.2.3i Subject: Re: igb dual-port adapter 1200Mbps limit - what to tune? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 18:05:45 -0000 On Thu, Nov 11, 2010 at 12:49:52PM +0200, Eugene Perevyazko wrote: > On Thu, Nov 11, 2010 at 01:47:02AM +0100, Ivan Voras wrote: > > On 11/10/10 12:04, Eugene Perevyazko wrote: > > > > >Tried 2 queues and 1 queue per iface, neither hitting cpu limit. > > > > Are you sure you are not hitting the CPU limit on individual cores? Have > > you tried running "top -H -S"? > > > Sure, even with 1queue per iface load is 40-60% on busy core, with 2 queues it was much lower. > Now I've got the module for mb with 2 more ports, going to see if it helps. The IO module has em interfaces on it and somehow I've already got 2 panics after moving one of vlans to it. In the mean time, can someone explain me what is processed by threads marked like "irq256: igb0" and "igb0 que". May be understanding this will let me pin those threads to cores more optimally. There are (hw.igb.num_queues+1) "irq" threads and (hw.igb.num_queues) "que" threads. Now I just pin them sequentially to even cores (odd ones are HT). Now I use hw.igb.num_queues=2, and with traffic limited to 1200Mbits the busiest core is still 60% idle... -- Eugene Perevyazko From owner-freebsd-net@FreeBSD.ORG Thu Nov 11 18:10:22 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8FB2B106566B for ; Thu, 11 Nov 2010 18:10:22 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 232778FC0A for ; Thu, 11 Nov 2010 18:10:20 +0000 (UTC) Received: by gwj20 with SMTP id 20so977568gwj.13 for ; Thu, 11 Nov 2010 10:10:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=joJOpOfqkDXUfYgih7fbl8Z/NudgShJZ7rE02aGL8HE=; b=pkNA0un5XkTbhCrpMsKj9+s1pPpcoOqFJNm2v5PiHu87O8rsBW8vGAuoBjNpzbLdGq bA0Tn4dWCX84Df/MOL0MuppFsy91NJfoEnMem3rnkC3MAQ+U5ocXlVPQUvUnOtUiyD84 Hm2YQuJBF4jDy5AtyCP9fH2f88CnWNzsnJKc4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=NoL3y+0thviRy9esEFZbJFsq4rsOmuSIez2u+zcOp7/uCHTyhfU+AHrvs0ruSU3lZJ b8TbkZCXHJ4WL563NMVk48XQQgmOt/umUqkpcTEl0VpRqpvQbseBR7TdRGrjrtNlNkc6 MmHSta9A9eSpY+E/njMd5LgzC+Cv3PuiAWaEA= Received: by 10.151.14.7 with SMTP id r7mr2202722ybi.19.1289499019971; Thu, 11 Nov 2010 10:10:19 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id h68sm1689231yha.15.2010.11.11.10.10.16 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 11 Nov 2010 10:10:17 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Thu, 11 Nov 2010 10:09:22 -0800 From: Pyun YongHyeon Date: Thu, 11 Nov 2010 10:09:22 -0800 To: Yamagi Burmeister Message-ID: <20101111180922.GA17566@michelle.cdnetworks.com> References: <20101109011410.GB1275@michelle.cdnetworks.com> <20101109190713.GA7766@michelle.cdnetworks.com> <20101109213421.GE7766@michelle.cdnetworks.com> <20101110234128.GC13340@michelle.cdnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: [patch] WOL support for nfe(4) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 18:10:22 -0000 On Thu, Nov 11, 2010 at 08:08:25AM +0100, Yamagi Burmeister wrote: > On Wed, 10 Nov 2010, Pyun YongHyeon wrote: > > >On Tue, Nov 09, 2010 at 01:34:21PM -0800, Pyun YongHyeon wrote: > >>On Tue, Nov 09, 2010 at 10:01:36PM +0100, Yamagi Burmeister wrote: > >>>On Tue, 9 Nov 2010, Pyun YongHyeon wrote: > >>> > >>>>>No, the link stays at 1000Mbps so the driver must manually switch back > >>>>>to 10/100Mbps. > >>>>> > >>>> > >>>>Hmm, this is real problem for WOL. Establishing 1000Mbps link to > >>>>accept WOL frames is really bad idea since it can draw more power > >>>>than 375mA. Consuming more power than 375mA is violation of > >>>>PCI specification and some system may completely shutdown the power > >>>>to protect hardware against over-current damage which in turn means > >>>>WOL wouldn't work anymore. Even if WOL work with 1000Mbps link for > >>>>all nfe(4) controllers, it would dissipate much more power. > >>>> > >>>>Because nfe(4) controllers are notorious for using various PHYs, > >>>>it's hard to write a code to reliably establish 10/100Mbps link in > >>>>driver. In addition, nfe(4) is known to be buggy in link state > >>>>handling such that forced media selection didn't work well. I'll > >>>>see what could be done in this week if I find spare time. > >>> > >>>Hmm... Maybe just add a hint to the manpage that WOL is possible broken? > >> > >>I think this may not be enough. Because it can damage your hardware > >>under certain conditions if protection circuit was not there. > >> > > > >Ok, I updated patch which will change link speed to 10/100Mps when > >shutdown/suspend is initiated. You can get the patch at the > >following URL. Please give it a try and let me know whether it > >really changes link speed to 10/100Mbps. If it does not work as > >expected, show me the dmesg output of your system. > > > >http://people.freebsd.org/~yongari/nfe/nfe.wol.patch2 > > Okay, that does the trick. At shutdown the link speed is changed to > 10/100Mbps, at boot - either via WOL magic packet or manuell startup - > it's changed back to 1000Mbps. > Thanks, patch committed(r215132), will MFC after a week. > Thanks again, > Yamagi > > -- > Homepage: www.yamagi.org > Jabber: yamagi@yamagi.org > GnuPG/GPG: 0xEFBCCBCB From owner-freebsd-net@FreeBSD.ORG Thu Nov 11 19:09:43 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4C13A106564A for ; Thu, 11 Nov 2010 19:09:43 +0000 (UTC) (envelope-from "."@babolo.ru) Received: from smtp1.babolo.ru (smtp1.babolo.ru [195.9.14.139]) by mx1.freebsd.org (Postfix) with ESMTP id C73FF8FC17 for ; Thu, 11 Nov 2010 19:09:42 +0000 (UTC) Received: from cicuta.babolo.ru ([194.58.246.5]) by smtp1.babolo.ru (8.14.2/8.14.2) with SMTP id oABIssuQ048200 for ; Thu, 11 Nov 2010 21:54:54 +0300 (MSK) (envelope-from .@babolo.ru) Received: (nullmailer pid 40653 invoked by uid 136); Thu, 11 Nov 2010 18:58:12 -0000 Date: Thu, 11 Nov 2010 21:58:12 +0300 From: Aleksandr A Babaylov <.@babolo.ru> To: freebsd-net@freebsd.org Message-ID: <20101111185812.GA40610@babolo.ru> References: <20101110110428.GA3505@traktor.dnepro.net> <20101111104952.GA11275@traktor.dnepro.net> <20101111180539.GC11275@traktor.dnepro.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101111180539.GC11275@traktor.dnepro.net> Subject: Re: igb dual-port adapter 1200Mbps limit - what to tune? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 19:09:43 -0000 On Thu, Nov 11, 2010 at 08:05:40PM +0200, Eugene Perevyazko wrote: > On Thu, Nov 11, 2010 at 12:49:52PM +0200, Eugene Perevyazko wrote: > > On Thu, Nov 11, 2010 at 01:47:02AM +0100, Ivan Voras wrote: > > > On 11/10/10 12:04, Eugene Perevyazko wrote: > > > > > > >Tried 2 queues and 1 queue per iface, neither hitting cpu limit. > > > > > > Are you sure you are not hitting the CPU limit on individual cores? Have > > > you tried running "top -H -S"? > > > > > Sure, even with 1queue per iface load is 40-60% on busy core, with 2 queues it was much lower. > > Now I've got the module for mb with 2 more ports, going to see if it helps. > The IO module has em interfaces on it and somehow I've already got 2 panics > after moving one of vlans to it. > > In the mean time, can someone explain me what is processed by threads marked > like "irq256: igb0" and "igb0 que". May be understanding this will let me > pin those threads to cores more optimally. > There are (hw.igb.num_queues+1) "irq" threads and (hw.igb.num_queues) > "que" threads. Now I just pin them sequentially to even cores (odd ones are HT). As far as I understand, you are not right about HT cores. Try switch HT off and do not use HT in routers in usual cases. > Now I use hw.igb.num_queues=2, and with traffic limited to 1200Mbits the busiest core is still 60% idle... > > > > -- > Eugene Perevyazko > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Thu Nov 11 19:42:14 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 217D7106564A for ; Thu, 11 Nov 2010 19:42:14 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id A3BE28FC18 for ; Thu, 11 Nov 2010 19:42:13 +0000 (UTC) Received: by wyb36 with SMTP id 36so220070wyb.13 for ; Thu, 11 Nov 2010 11:42:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=zvAgMhQ0oaJ1z33+GJ2UOQ++cV+vPrYpYCqGd3K1tTk=; b=qXBgH1obfqWEbMurrnI/c5UCjbXK/lD8P3g1HrNcdeUN1eTpZpm3QNIKgNAR10QiOC 4+bJHh1qxIeVy4QaGZr2whH2KRRpPSf2qXEmKeHY/OwV9LRlW7Qnucy7hooJYuU45Q2a 9lxdhx/MAmFR4JPz1FzXBDIi9Bl/pvrjWKBww= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=TShEsfRFG41+T6s54KnbyqgT+L9gG/XU2422AtY1v/qqG6UB/f/dQEnM99Bolc3G04 3+RPWGxRKSswAnfkJXAnXi/8p0s4e2GwWFo2X+tQuYdytyZAi8GS421c6Y+xb8JWkyf9 MumbB8pUqXlaHI2oIDJ2nJmU/n0iCi3xo81mc= MIME-Version: 1.0 Received: by 10.216.179.210 with SMTP id h60mr1138761wem.42.1289504532393; Thu, 11 Nov 2010 11:42:12 -0800 (PST) Received: by 10.216.2.206 with HTTP; Thu, 11 Nov 2010 11:42:12 -0800 (PST) In-Reply-To: <20101111180539.GC11275@traktor.dnepro.net> References: <20101110110428.GA3505@traktor.dnepro.net> <20101111104952.GA11275@traktor.dnepro.net> <20101111180539.GC11275@traktor.dnepro.net> Date: Thu, 11 Nov 2010 11:42:12 -0800 Message-ID: From: Jack Vogel To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: igb dual-port adapter 1200Mbps limit - what to tune? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 19:42:14 -0000 The driver already handles the pinning, you shouldnt need to mess with it. MSIX interrupts start at 256, the igb driver uses one vector per queue, which is an TX/RX pair. The driver creates as many queues as cores up to a max of 8. Jack On Thu, Nov 11, 2010 at 10:05 AM, Eugene Perevyazko wrote: > On Thu, Nov 11, 2010 at 12:49:52PM +0200, Eugene Perevyazko wrote: > > On Thu, Nov 11, 2010 at 01:47:02AM +0100, Ivan Voras wrote: > > > On 11/10/10 12:04, Eugene Perevyazko wrote: > > > > > > >Tried 2 queues and 1 queue per iface, neither hitting cpu limit. > > > > > > Are you sure you are not hitting the CPU limit on individual cores? > Have > > > you tried running "top -H -S"? > > > > > Sure, even with 1queue per iface load is 40-60% on busy core, with 2 > queues it was much lower. > > Now I've got the module for mb with 2 more ports, going to see if it > helps. > The IO module has em interfaces on it and somehow I've already got 2 panics > after moving one of vlans to it. > > In the mean time, can someone explain me what is processed by threads > marked > like "irq256: igb0" and "igb0 que". May be understanding this will let me > pin those threads to cores more optimally. > There are (hw.igb.num_queues+1) "irq" threads and (hw.igb.num_queues) "que" > threads. Now I just pin them sequentially to even cores (odd ones are HT). > > Now I use hw.igb.num_queues=2, and with traffic limited to 1200Mbits the > busiest core is still 60% idle... > > > > -- > Eugene Perevyazko > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Thu Nov 11 19:52:21 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7B649106566B for ; Thu, 11 Nov 2010 19:52:21 +0000 (UTC) (envelope-from rene@reckschwardt.de) Received: from rds11224.i4e-server.de (rds11224.i4e-server.de [195.225.105.212]) by mx1.freebsd.org (Postfix) with ESMTP id E367B8FC15 for ; Thu, 11 Nov 2010 19:52:20 +0000 (UTC) Received: from mail.menny.de (p5DDA92AD.dip.t-dialin.net [93.218.146.173]) by rds11224.i4e-server.de (Postfix) with ESMTPSA id A7D838090AAD for ; Thu, 11 Nov 2010 20:35:34 +0100 (CET) Received: from [192.168.1.129] by mail.menny.de with esmtp (Exim 4.72) (envelope-from ) id 1PGcvk-0001oq-26 for freebsd-net@freebsd.org; Thu, 11 Nov 2010 20:35:33 +0100 Date: Thu, 11 Nov 2010 19:35:32 +0000 From: "rene@reckschwardt.de" User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; de-DE; rv:1.9.2.9) Gecko/20100918 Thunderbird/3.1.4 MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080502010700070406080802" X-Scan-Signature: c44944d26055df8af8493284552e017d X-Spam-Score: -2.7 (--) Message-Id: <20101111193534.A7D838090AAD@rds11224.i4e-server.de> X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: ML370 G4 with poor Network Performance and high CPU Load X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 19:52:21 -0000 This is a cryptographically signed message in MIME format. --------------ms080502010700070406080802 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hello, i am new in this Maillist and i use an ML370G4 with FreeBSD 8.1 AMD64. I = try with netio and TCP. The used Nics are onboard Broadcom=20 (PCI-X133Mhz), an Broadcom PCI-X Nic and an intel PCI-X Nic. The CPU=20 load is around 35% and the performance like this: Packet size 1k bytes: 99303 KByte/s Tx, 44576 KByte/s Rx. Packet size 2k bytes: 72043 KByte/s Tx, 75200 KByte/s Rx. Packet size 4k bytes: 23280 KByte/s Tx, 66072 KByte/s Rx. Packet size 8k bytes: 55234 KByte/s Tx, 64470 KByte/s Rx. Packet size 16k bytes: 82485 KByte/s Tx, 74099 KByte/s Rx. Packet size 32k bytes: 93133 KByte/s Tx, 74992 KByte/s Rx. I try the following tuning: kern.ipc.maxsockbuf=3D16777216 net.inet.tcp.sendbuf_max=3D16777216 net.inet.tcp.recvbuf_max=3D16777216 net.inet.tcp.sendbuf_inc=3D16384 net.inet.tcp.recvbuf_inc=3D524288 net.inet.tcp.inflight.enable=3D0 net.inet.tcp.hostcache.expire=3D1 but this is not helpfull, the Load goes to 60% and the Performance is=20 also poor. How can i prevent this Problem? thanks for response r=E9 P.S. the same Computer with Linux runs perfect with Performance and 1-2% = Load, --------------ms080502010700070406080802-- From owner-freebsd-net@FreeBSD.ORG Thu Nov 11 20:40:00 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 579DC106566C for ; Thu, 11 Nov 2010 20:40:00 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from out-0.mx.aerioconnect.net (outg.internet-mail-service.net [216.240.47.230]) by mx1.freebsd.org (Postfix) with ESMTP id 387F28FC15 for ; Thu, 11 Nov 2010 20:39:59 +0000 (UTC) Received: from idiom.com (postfix@mx0.idiom.com [216.240.32.160]) by out-0.mx.aerioconnect.net (8.13.8/8.13.8) with ESMTP id oABKdwm2026332; Thu, 11 Nov 2010 12:39:58 -0800 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by idiom.com (Postfix) with ESMTP id CE04F2D6017; Thu, 11 Nov 2010 12:39:44 -0800 (PST) Message-ID: <4CDC5490.7030109@freebsd.org> Date: Thu, 11 Nov 2010 12:39:44 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Christopher Penney References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 216.240.47.51 Cc: freebsd-net@freebsd.org Subject: Re: NFS + FreeBSD TCP Behavior with Linux NAT X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 20:40:00 -0000 On 11/11/10 6:36 AM, Christopher Penney wrote: > Hi, > > I have a curious problem I'm hoping someone can help with or at least > educate me on. > > I have several large Linux clusters and for each one we hide the compute > nodes behind a head node using NAT. Historically, this has worked very well > for us and any time a NAT gateway (the head node) reboots everything > recovers within a minute or two of it coming back up. This includes NFS > mounts from Linux and Solaris NFS servers, license server connections, etc. > > Recently, we added a FreeBSD based NFS server to our cluster resources and > have had significant issues with NFS mounts hanging if the head node > reboots. We don't have this happen much, but it does occasionally happen. > I've explored this and it seems the behavior of FreeBSD differs a bit from > at least Linux and Solaris with respect to TCP recovery. I'm curious if > someone can explain this or offer any workarounds. > > Here are some specifics from a test I ran: > > Before the reboot two Linux clients were mounting the FreeBSD server. They > were both using port 903 locally. On the head node clientA:903 was remapped > to headnode:903 and clientB:903 was remapped to headnode:601. There is no > activity when the reboot occurs. The head node takes a few minutes to come > back up (we kept it down for several minutes). > > When it comes back up clientA and clientB try to reconnect to the FreeBSD > NFS server. They both use the same source port, but since the head node's > conntrack table is cleared it's a race to see who gets what port and this > time clientA:903 appears as headnode:601 and clientB:903 appears as > headnode:903 (>>> they essentially switch places as far as the FreeBSD > server would see<<< ). > > The FreeBSD NFS server, since there was no outstanding acks it was waiting > on, thinks things are ok so when it gets a SYN from the two clients it only > responds with an ACK. The ACK for each that it replies with is bogus > (invalid seq number) because it's using the return path the other client was > using before the reboot so the client sends a RST back, but it never gets to > the FreeBSD system since the head node's NAT hasn't yet seen the full > handshake (that would allow return packets). The end result is a > "permanent" hang (at least until it would otherwise cleanup idle TCP > connections). > > This is in stark contrast to the behavior of the other systems we have. > Other systems respond to the SYN used to reconnect with a SYN/ACK. They > appear to implicitly tear down the return path based on getting a SYN from a > seemingly already established connection. > > I'm assuming this is one of the grey areas where there is no specific > behavior outlined in an RFC? Is there any way to make the FreeBSD system > more reliable in this situation (like making it implicitly tear down the > return)? Or is there a way to adjust the NAT setup to allow the RST to > return to the FreeBSD system? Currently, NAT is setup with simply: > > iptables -t nat -A POSTROUTING -s 10.1.0.0/16 -o bond0 -j SNAT --to 1.2.3.4 > > Where 1.2.3.4 is the intranet address and 10.1.0.0 is the cluster network. I just added NFS to the subject because the NFS people are thise you need to connect with. > Thanks! > > Chris > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Thu Nov 11 21:01:22 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CB5E41065672 for ; Thu, 11 Nov 2010 21:01:22 +0000 (UTC) (envelope-from jamesbrandongooch@gmail.com) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 080A68FC08 for ; Thu, 11 Nov 2010 21:01:21 +0000 (UTC) Received: by ewy4 with SMTP id 4so1118324ewy.13 for ; Thu, 11 Nov 2010 13:01:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=xeIjeZgc89BtakLNQfBySmALKzlkjJMKT41Nf2p1vDg=; b=Q42SUN5y3ZjNLL6ri5gHgZv7bbN2u3g402ouY9DeKXaVnO9z9BFoE74bym2fV+NYWI 6Rn+t9PK9q4zfRoLCBLmsBZN/xsAujaxAYlygDL4oPmweUPp1jq1DQJyXUakSV8PocoN HFpwTuGh8xEHz/lGBJigNJp0CjpRTAaI/Am9g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=DDQF+aO5VXKwtYzsJ0shAh6+R7MO1NsAFi4pI4yVC2c8hBphW7uIdnjlmlH/IlDC8U Z2q/DhMgTm1MLgKy3vGBgjcRvKweDGnUZsFWRSO5rmnHG22dR90DAGdswiqjwFznubFQ 9o9+WVqFY4u/vTc6cAsqolBRrax+iJuSuokVg= MIME-Version: 1.0 Received: by 10.216.154.131 with SMTP id h3mr2810712wek.74.1289509280307; Thu, 11 Nov 2010 13:01:20 -0800 (PST) Received: by 10.216.12.80 with HTTP; Thu, 11 Nov 2010 13:01:20 -0800 (PST) In-Reply-To: <20100326095919.A46084@beagle.kn.op.dlr.de> References: <4BAB5A77.7050505@mts.com.ua> <61b573981003250659n1076fef1u7d15920c4d560fdf@mail.gmail.com> <20100326080816.X46084@beagle.kn.op.dlr.de> <4BAC6FF3.7090304@vas.org.ua> <20100326095919.A46084@beagle.kn.op.dlr.de> Date: Thu, 11 Nov 2010 15:01:20 -0600 Message-ID: From: Brandon Gooch To: Hartmut Brandt Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org, Shteryana Shopova , Harti Brandt , Ivan Voras , Vasily Samoylov Subject: Re: Poor situation with snmp support in FreeBSD X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 21:01:22 -0000 On Fri, Mar 26, 2010 at 4:01 AM, Hartmut Brandt wrote: >> VS>I, probably, was to verbose, and didn't make myself clear enough. For now, >> VS>from network admin point of view, it's 3 problems: >> VS>1) No ARP support > > The ARP table should be there. It may be that it got 'lost' with the ARP > changes last year. So this should be fixable. The ARP table is the old > one, though. Old thread, but I just recently bumped into this problem... Does anyone CC'd in this exchange know how to go about fixing this? Perhaps a pointer to a document describing the changes in ARP that broke this? Seems that net-snmp manages to gather this info: # snmpwalk -v 1 -c public 192.168.1.1 ... IP-MIB::ipNetToMediaPhysAddress.1.192.168.0.105 = Hex-STRING: 00 21 E1 FB 25 2D IP-MIB::ipNetToMediaPhysAddress.1.192.168.0.0 = Hex-STRING: 00 13 20 2E 89 61 IP-MIB::ipNetToMediaPhysAddress.1.192.168.0.168 = Hex-STRING: 00 11 43 A3 1C 1F IP-MIB::ipNetToMediaPhysAddress.1.192.168.0.194 = Hex-STRING: 00 60 97 92 59 64 ... Thanks for any pointers... -Brandon From owner-freebsd-net@FreeBSD.ORG Thu Nov 11 21:05:34 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 601DC1065672; Thu, 11 Nov 2010 21:05:34 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1F1698FC19; Thu, 11 Nov 2010 21:05:33 +0000 (UTC) Received: by pvc22 with SMTP id 22so535219pvc.13 for ; Thu, 11 Nov 2010 13:05:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=bJmqtQRPm38Y9qOJkCB8izzVHlpKxHbp9sa9dtsInYY=; b=qfi0XeKeaXMAgRgVyoXRX0iiJBlY4Z+IRXa1zfTd4Sa8NEYPu4WKg69iXHNd2IKOOy l1B2Tl06a07vkbUbg3vbgs5e9DmUDiPIfrtWA00DtfXTQVo4WNlrwvsrZ5XJwbB1ZvdD AwzXS+pSs9WysV2HNNqDvQrqm//JUJheFt9Aw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:content-transfer-encoding :in-reply-to:user-agent; b=GUr0CCYqG7nxk55uOCqu4Kc3vCPpMmcUlm/2/CkEMXJz4gjRZN7ZHxZnUCxN/KDBRv Zl7+8xpSNmqx9LunvF/v2PJoaoM7IJQHREnABkFZnaDPc9IQ6dfpmNrOvhJrLpGKaQon Wz4rFfF0QeBctwbJIgFDDKVF5ZoyvwoFD1TD0= Received: by 10.143.18.7 with SMTP id v7mr1188924wfi.254.1289509532674; Thu, 11 Nov 2010 13:05:32 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id q13sm2832996wfc.17.2010.11.11.13.05.29 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 11 Nov 2010 13:05:30 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Thu, 11 Nov 2010 13:04:36 -0800 From: Pyun YongHyeon Date: Thu, 11 Nov 2010 13:04:36 -0800 To: Kevin Oberman Message-ID: <20101111210436.GD17566@michelle.cdnetworks.com> References: <816869.17580.qm@web120510.mail.ne1.yahoo.com> <20101111161057.CA5A71CC0E@ptavv.es.net> Mime-Version: 1.0 Content-Type: text/plain; charset=EUC-KR Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20101111161057.CA5A71CC0E@ptavv.es.net> User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable@freebsd.org, Kirill Yelizarov , net@freebsd.org Subject: Re: icmp packets on em larger than 1472 [SEC=UNCLASSIFIED] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 21:05:34 -0000 On Thu, Nov 11, 2010 at 08:10:57AM -0800, Kevin Oberman wrote: > > Date: Wed, 10 Nov 2010 23:49:56 -0800 (PST) > > From: Kirill Yelizarov > > > > > > > > --- On Thu, 11/11/10, Kevin Oberman wrote: > > > > > From: Kevin Oberman > > > Subject: Re: icmp packets on em larger than 1472 [SEC=UNCLASSIFIED] > > > To: "Wilkinson, Alex" > > > Cc: freebsd-stable@freebsd.org > > > Date: Thursday, November 11, 2010, 8:26 AM > > > > Date: Thu, 11 Nov 2010 13:01:26 > > > +0800 > > > > From: "Wilkinson, Alex" > > > > Sender: owner-freebsd-stable@freebsd.org > > > > > > > > > > > >? ???0n Wed, Nov 10, 2010 at > > > 04:21:12AM -0800, Kirill Yelizarov wrote: > > > > > > > >? ???>All my em cards running > > > 8.1 stable don't reply to icmp echo requests packets larger > > > than 1472 bytes. > > > >? ???> > > > >? ???>On stable 7.2 the same > > > hardware works as expected: > > > >? ???># ping -s 1500 > > > 192.168.64.99 > > > >? ???>PING 192.168.64.99 > > > (192.168.64.99): 1500 data bytes > > > >? ???>1508 bytes from > > > 192.168.64.99: icmp_seq=0 ttl=63 time=1.249 ms > > > >? ???>1508 bytes from > > > 192.168.64.99: icmp_seq=1 ttl=63 time=1.158 ms > > > >? ???> > > > >? ???>Here is the dump on em > > > interface > > > >? ???>15:06:31.452043 IP > > > 192.168.66.65 > *****: ICMP echo request, id 28729, seq > > > 5, length 1480 > > > >? ???>15:06:31.452047 IP > > > 192.168.66.65 > ****: icmp > > > >? ???>15:06:31.452069 IP **** > > > > 192.168.66.65: ICMP echo reply, id 28729, seq 5, length > > > 1480 > > > >? ???>15:06:31.452071 IP *** > > > > 192.168.66.65: icmp > > > >? ???> > > > >? ???>Same ping from same source > > > (it's a 8.1 stable with fxp interface) to em card running > > > 8.1 stable > > > >? ???>#pciconf -lv > > > >? > > > ???>em0@pci0:3:4:0:??? > > > class=0x020000 card=0x10798086 chip=0x10798086 rev=0x03 > > > hdr=0x00 > > > >? ???>? ? vendor? > > > ???= 'Intel Corporation' > > > >? ???>? ? device? > > > ???= 'Dual Port Gigabit Ethernet Controller > > > (82546EB)' > > > >? ???>? ? class? > > > ? ? = network > > > >? ???>? ? > > > subclass???= ethernet > > > >? ???> > > > >? ???># ping -s 1472 > > > 192.168.64.200 > > > >? ???>PING 192.168.64.200 > > > (192.168.64.200): 1472 data bytes > > > >? ???>1480 bytes from > > > 192.168.64.200: icmp_seq=0 ttl=63 time=0.848 ms > > > >? ???>^C > > > >? ???> > > > >? ???># ping -s 1473 > > > 192.168.64.200 > > > >? ???>PING 192.168.64.200 > > > (192.168.64.200): 1473 data bytes > > > >? ???>^C > > > >? ???>--- 192.168.64.200 ping > > > statistics --- > > > >? ???>4 packets transmitted, 0 > > > packets received, 100.0% packet loss > > > > > > > > works fine for me: > > > > > > > > FreeBSD 8.1-STABLE #0 r213395 > > > > > > > > em0@pci0:0:25:0:class=0x020000 card=0x3035103c > > > chip=0x10de8086 rev=0x02 hdr=0x00 > > > >? ???vendor? > > > ???= 'Intel Corporation' > > > >? ???device? > > > ???= 'Intel Gigabit network connection > > > (82567LM-3 )' > > > >? ???class? ? ? = > > > network > > > >? ???subclass???= > > > ethernet > > > > > > > > #ping -s 1473 host > > > > PING host(192.168.1.1): 1473 data bytes > > > > 1481 bytes from 192.168.1.1: icmp_seq=0 ttl=253 > > > time=31.506 ms > > > > 1481 bytes from 192.168.1.1: icmp_seq=1 ttl=253 > > > time=31.493 ms > > > > 1481 bytes from 192.168.1.1: icmp_seq=2 ttl=253 > > > time=31.550 ms > > > > ^C > > > > > > The reason the '-s 1500' worked was that the packets were > > > fragmented. If > > > I add the '-D' option, '-s 1473' fails on v7 and v8. Are > > > the V8 systems > > > where you see if failing without the '-D' on the same > > > network segment? > > > If not, it is likely that an intervening device is refusing > > > to fragment > > > the packet. (Some routers deliberately don't fragment ICMP > > > Echos Request > > > packets.) > > > > If i set -D -s 1473 sender side refuses to ping and that is > > correct. All mentioned above machines are behind the same router and > > switch. Same hardware running v7 is working while v8 is not. And i > > never saw such problems before. Also correct me if i'm wrong but the > > dump shows that the packet arrived. I'll try driver from head and will > > post here results. > > I did a bit more looking at this today and I see that something bogus is > going on and it MAY be the em driver. > > I tried 1473 data byte pings without the DF flag. I then captured the > packets on both ends (where the sending system has a bge (Broadcom GE) > and the responding end has an em (Intel) card. > > What I saw was the fragmented IP packets all being received by the > system with the em interface and an ICMP Echo Reply being sent back, > again fragmented. I saw the reply on both ends, so both interfaces were > able to fragment an over-sized packet, transmit the two pieces, and > receive the two pieces. The em device could re-assemble them properly, > but the bge device does not seem to re-assemble them correctly or else > has a problem with ICMP packets bigger then MTU size. > > When I send from the em system, I see the packets and fragments all > arrive in good form, but the system never sends out a reply. Since this > is a kernel function, it may be a driver, but I suspect that it is in > the IP stack since I am seeing the problem with a Broadcom card and I > see the data all arriving. > Most ethernet controllers including bge(4) have a function to specify how much RX buffer space would be allocated to receive a frame. When controller receive a frame that has larger size than the size specified in RX buffer space, it would drop the frame. Because the oversized frame was silently dropped in driver layer upper stack has no chance to reply back ICMP responses with fragmentation needed bit for frames that set don't fragment bit. This is where correct MTU configuration play an important role in driver layer. If you want to handle oversized frame you also have to set correct MTU of interface. However all controllers should be able to receive standard MTU sized frame including VLAN tag so no special configuration is needed when you handle standard MTU sized frames. Some old controllers can't handle VLAN oversized frame such that you would have no way to send or receive them. em(4) controllers have different receiving logic where it allows chaining multiple oversized frames into a single frame. So up to certain point, which depends on the size of jumbo frame controller supports, em(4) can receive these oversized frames regardless of MTU configuration with the help of driver. The chaining is done in driver layer and that would add additional overhead(chaining + multiple mbuf allocation) but it has its own advantages. I was not able to to reproduce the issue with em(4)/bge(4) on CURRENT and these drivers worked as expected. > I think Jack can probably relax, but some patch to the network stack > seems to have broken at least ICMP processing. And, since the bge system > ups updated to 8-Stable on October 20 while the em system was updated > back on August 9, I suspect the flaw was not driver related and was > committed between August 9 and Oct. 20. > > I think this needs to go to the network list where the folks who tinker > with that part of the kernel tend to hang out. Sorry for the cross-post. > -- > R. Kevin Oberman, Network Engineer > Energy Sciences Network (ESnet) > Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) > E-mail: oberman@es.net Phone: +1 510 486-8634 > Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Thu Nov 11 21:21:56 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 58035106564A for ; Thu, 11 Nov 2010 21:21:56 +0000 (UTC) (envelope-from gabor.radnai@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id D82898FC14 for ; Thu, 11 Nov 2010 21:21:55 +0000 (UTC) Received: by fxm19 with SMTP id 19so1742177fxm.13 for ; Thu, 11 Nov 2010 13:21:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:from:date :message-id:subject:to:content-type; bh=cY+LYzk1ly3IPn70nDsc8k9TttV9Wy0FR0XHpZnxSFk=; b=FU1QSS/A/f3g+VJD1yxmKu2p/5rI+y099VUZkHcjIRKyQ7mA278i78K3+8YVUVJCU3 xoWjInbsJIir55O7juyJ+9RbLOTmoe1M+OURruG9CuPWE1hH/fY4Va12v3e2QUsvL9Sp A2VA5POU2Hs/AMNym+U1D0kCE/Rq/tKRor9lM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=eHcO9p5/xE+0DUCF+YQrBw/Y7+RI5ZSTK88yLKn7bCG9Im2725ZoeR/nB9ZQKr+3QA a26COC1SY+rB2gvsCCkAAXNtSfZSE0rENH/HqDl3OytYntB3pb69S3WHK2u47A2+ew9X I6ghhlvJr4d+783uAMe36L+keu32PyaE9onKs= Received: by 10.223.79.72 with SMTP id o8mr634647fak.83.1289509001677; Thu, 11 Nov 2010 12:56:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.93.138 with HTTP; Thu, 11 Nov 2010 12:56:26 -0800 (PST) From: Gabor Radnai Date: Thu, 11 Nov 2010 21:56:26 +0100 Message-ID: To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Problem with re0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 21:21:56 -0000 Hi, I have an Asus M2NPV-VM motherboard with integrated Nvidia MCP51 Gigabit Ethernet NIC and TP-Link TG-3468 PCIe network card which is using Realtek 8111 chip. I have problem with the re driver: the Nvidia network interface is working properly but the other though it seems recognized by OS I cannot use. Sporadically it remains down and if it gets up then does not get ip address via DHCP nor help if I set static ip address. Can manipulate via ifconfig but unreachable via IP. I replaced cable, interchanged cable working with Nvidia, restarted switch/router but no luck so far. Also using this nic in a Windows machine - it works. Using my Asus mob with Ubuntu Live CD - card works. Can it be a driver bug or this type of chip is not supported by re driver? Thanks, Gabor ------------------------ uname -v FreeBSD 8.1-RELEASE #0 r210200M: Wed Jul 21 14:21:18 CEST 2010 root@neo.vx.sk:/usr/obj/usr/ src/sys/GENERIC pciconf: nfe0@pci0:0:20:0: class=0x068000 card=0x816a1043 chip=0x026910de rev=0xa3 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'MCP51 Network Bus Enumerator' class = bridge re0@pci0:1:0:0: class=0x020000 card=0x816810ec chip=0x816810ec rev=0x01 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'Gigabit Ethernet NIC(NDIS 6.0) (RTL8168/8111/8111c)' class = network subclass = ethernet rc.conf: ifconfig_nfe0="inet 192.168.0.200 netmask 255.255.255.0" defaultrouter="192.168.0.1" ifconfig_re0="DHCP" dmesg: nfe0: port 0xc800-0xc807 mem 0xfe02b000-0xfe02bfff irq 21 at device 20.0 on pci0 miibus1: on nfe0 e1000phy0: PHY 19 on miibus1 e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto nfe0: Ethernet address: 00:1a:92:38:dc:95 nfe0: [FILTER] re0: port 0xac00-0xacff mem 0xfdbff000-0xfdbfffff irq 16 at device 0.0 on pci1 re0: Using 1 MSI messages re0: Chip rev. 0x38000000 re0: MAC rev. 0x00000000 miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto re0: Ethernet address: d8:5d:4c:80:b4:88 re0: [FILTER] From owner-freebsd-net@FreeBSD.ORG Thu Nov 11 21:27:46 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 67780106566B for ; Thu, 11 Nov 2010 21:27:46 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 1D4238FC08 for ; Thu, 11 Nov 2010 21:27:45 +0000 (UTC) Received: by gwj20 with SMTP id 20so1124354gwj.13 for ; Thu, 11 Nov 2010 13:27:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=DMRemd+6vbkZ4auetQmIXLH5CQxMPL/WchSv/+LftAE=; b=ALUa2YOMBlsGzg3QJcq/wuQL/aLxFrPPgcvn3Ndwy5Ipw9WkLsR1C3VLeKUShjNUr/ PiBTowgalyyr1Vkf8lFDSNbjXKM77xgXgX8qVywoHZ1QZJnB+VslLazAkoQ01GiEXIfq fvUuGGesbOwps8pPgKu1NJqcPDkotc5XhZ8d4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=X+Ma4x8M4nGO4XlROOVsZ31rtTy84Ul/jbZ2MTM1lx2o1c1h/SAlNidG3o1f5AzeCW Jh/Zc7chjvgyDx8SwYfdZlDMmDe8+2jS64NGP+/P35d9o+FMtVVOnP0VFcRtB12xwq0x qM4KjnoEG+t+07lbj5RCKhDTc13ME4T9uTfnU= Received: by 10.90.4.6 with SMTP id 6mr2109996agd.16.1289510865291; Thu, 11 Nov 2010 13:27:45 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id a32sm1808285yhc.25.2010.11.11.13.27.42 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 11 Nov 2010 13:27:44 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Thu, 11 Nov 2010 13:26:48 -0800 From: Pyun YongHyeon Date: Thu, 11 Nov 2010 13:26:48 -0800 To: Gabor Radnai Message-ID: <20101111212648.GF17566@michelle.cdnetworks.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: Problem with re0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 21:27:46 -0000 On Thu, Nov 11, 2010 at 09:56:26PM +0100, Gabor Radnai wrote: > Hi, > > I have an Asus M2NPV-VM motherboard with integrated Nvidia MCP51 Gigabit > Ethernet NIC and > TP-Link TG-3468 PCIe network card which is using Realtek 8111 chip. > > I have problem with the re driver: the Nvidia network interface is working > properly but the other > though it seems recognized by OS I cannot use. Sporadically it remains down > and if it gets up then > does not get ip address via DHCP nor help if I set static ip address. Can > manipulate via ifconfig but > unreachable via IP. > > I replaced cable, interchanged cable working with Nvidia, restarted > switch/router but no luck so far. > Also using this nic in a Windows machine - it works. Using my Asus mob with > Ubuntu Live CD - card works. > > Can it be a driver bug or this type of chip is not supported by re driver? > Eh, you already know the answer, recognized by re(4) but does not work so it's a bug of re(4). Would you show me the output of ifconfig re0 after UP the interface(i.e. ifconfig re0 up). From owner-freebsd-net@FreeBSD.ORG Thu Nov 11 21:32:53 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4D54B106566B for ; Thu, 11 Nov 2010 21:32:53 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 02E0C8FC08 for ; Thu, 11 Nov 2010 21:32:52 +0000 (UTC) Received: by gyg13 with SMTP id 13so352704gyg.13 for ; Thu, 11 Nov 2010 13:32:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=pIhBqfYZb7gpCk0aBRmifVzj4eYUouNnPp+rcB1JBVk=; b=c+Ub79tlrqRfKw+x3gD3CVWnzm3bPHM94oy43qJRhTjWWy6IxMGjtDcwHHnxgntLwM r9xqTGP/oq3n8J6/ucrKUh7FZuYHt909Q564Dw7nbqGmVvTdm9/fE4FY74ZPf+ro4s5t oEnnrKokCqPQnwuT6mYeNbMC4VhwNQl52rUT0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=mEtc/TQK/3lyfW9XzQgzBp6Gpn/+QcxGoN4A40Ll3GfNhCcKFriGOeHSmp+RbbTHSY +I8eTYgzG2yuPlQdIGOIemV9XQH1i3WzbU706NCYaHhmfKYb0gR8SSkSdxobu0W82Vzw yhGiLNvAfCECLPHeQOvVlNpNpPbQxNkxUovsU= Received: by 10.100.213.10 with SMTP id l10mr900590ang.160.1289511171986; Thu, 11 Nov 2010 13:32:51 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 6sm2793607anx.32.2010.11.11.13.32.50 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 11 Nov 2010 13:32:51 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Thu, 11 Nov 2010 13:31:56 -0800 From: Pyun YongHyeon Date: Thu, 11 Nov 2010 13:31:56 -0800 To: "rene@reckschwardt.de" Message-ID: <20101111213156.GG17566@michelle.cdnetworks.com> References: <20101111193534.A7D838090AAD@rds11224.i4e-server.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101111193534.A7D838090AAD@rds11224.i4e-server.de> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: ML370 G4 with poor Network Performance and high CPU Load X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 21:32:53 -0000 On Thu, Nov 11, 2010 at 07:35:32PM +0000, rene@reckschwardt.de wrote: > Hello, > > i am new in this Maillist and i use an ML370G4 with FreeBSD 8.1 AMD64. I > try with netio and TCP. The used Nics are onboard Broadcom > (PCI-X133Mhz), an Broadcom PCI-X Nic and an intel PCI-X Nic. The CPU > load is around 35% and the performance like this: > > Packet size 1k bytes: 99303 KByte/s Tx, 44576 KByte/s Rx. > Packet size 2k bytes: 72043 KByte/s Tx, 75200 KByte/s Rx. > Packet size 4k bytes: 23280 KByte/s Tx, 66072 KByte/s Rx. > Packet size 8k bytes: 55234 KByte/s Tx, 64470 KByte/s Rx. > Packet size 16k bytes: 82485 KByte/s Tx, 74099 KByte/s Rx. > Packet size 32k bytes: 93133 KByte/s Tx, 74992 KByte/s Rx. > And you did perform the test on idle system?(No disk activity, no other network IOs etc). Show me the dmesg output of verbose boot and output of "pciconf -lcbv". > I try the following tuning: > > kern.ipc.maxsockbuf=16777216 > net.inet.tcp.sendbuf_max=16777216 > net.inet.tcp.recvbuf_max=16777216 > net.inet.tcp.sendbuf_inc=16384 > net.inet.tcp.recvbuf_inc=524288 > net.inet.tcp.inflight.enable=0 > net.inet.tcp.hostcache.expire=1 > > but this is not helpfull, the Load goes to 60% and the Performance is > also poor. How can i prevent this Problem? > > thanks for response r? > > > P.S. the same Computer with Linux runs perfect with Performance and 1-2% > Load, > From owner-freebsd-net@FreeBSD.ORG Thu Nov 11 21:37:23 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2A21D106564A; Thu, 11 Nov 2010 21:37:23 +0000 (UTC) (envelope-from oberman@es.net) Received: from mailgw.es.net (mail1.es.net [IPv6:2001:400:201:1::2]) by mx1.freebsd.org (Postfix) with ESMTP id 149648FC17; Thu, 11 Nov 2010 21:37:23 +0000 (UTC) Received: from ptavv.es.net (ptavv.es.net [IPv6:2001:400:910::29]) by mailgw.es.net (8.14.3/8.14.3) with ESMTP id oABLbM8p009216 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 11 Nov 2010 13:37:22 -0800 Received: from ptavv.es.net (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 55BC91CC12; Thu, 11 Nov 2010 13:37:22 -0800 (PST) To: pyunyh@gmail.com In-reply-to: Your message of "Thu, 11 Nov 2010 13:04:36 PST." <20101111210436.GD17566@michelle.cdnetworks.com> Date: Thu, 11 Nov 2010 13:37:22 -0800 From: "Kevin Oberman" Message-Id: <20101111213722.55BC91CC12@ptavv.es.net> Cc: freebsd-stable@freebsd.org, Kirill Yelizarov , net@freebsd.org Subject: Re: icmp packets on em larger than 1472 [SEC=UNCLASSIFIED] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 21:37:23 -0000 > From: Pyun YongHyeon > Date: Thu, 11 Nov 2010 13:04:36 -0800 > > On Thu, Nov 11, 2010 at 08:10:57AM -0800, Kevin Oberman wrote: > > > Date: Wed, 10 Nov 2010 23:49:56 -0800 (PST) > > > From: Kirill Yelizarov > > > > > > > > > > > > --- On Thu, 11/11/10, Kevin Oberman wrote: > > > > > > > From: Kevin Oberman > > > > Subject: Re: icmp packets on em larger than 1472 [SEC=UNCLASSIFIED] > > > > To: "Wilkinson, Alex" > > > > Cc: freebsd-stable@freebsd.org > > > > Date: Thursday, November 11, 2010, 8:26 AM > > > > > Date: Thu, 11 Nov 2010 13:01:26 > > > > +0800 > > > > > From: "Wilkinson, Alex" > > > > > Sender: owner-freebsd-stable@freebsd.org > > > > > > > > > > > > > > >? ???0n Wed, Nov 10, 2010 at > > > > 04:21:12AM -0800, Kirill Yelizarov wrote: > > > > > > > > > >? ???>All my em cards running > > > > 8.1 stable don't reply to icmp echo requests packets larger > > > > than 1472 bytes. > > > > >? ???> > > > > >? ???>On stable 7.2 the same > > > > hardware works as expected: > > > > >? ???># ping -s 1500 > > > > 192.168.64.99 > > > > >? ???>PING 192.168.64.99 > > > > (192.168.64.99): 1500 data bytes > > > > >? ???>1508 bytes from > > > > 192.168.64.99: icmp_seq=0 ttl=63 time=1.249 ms > > > > >? ???>1508 bytes from > > > > 192.168.64.99: icmp_seq=1 ttl=63 time=1.158 ms > > > > >? ???> > > > > >? ???>Here is the dump on em > > > > interface > > > > >? ???>15:06:31.452043 IP > > > > 192.168.66.65 > *****: ICMP echo request, id 28729, seq > > > > 5, length 1480 > > > > >? ???>15:06:31.452047 IP > > > > 192.168.66.65 > ****: icmp > > > > >? ???>15:06:31.452069 IP **** > > > > > 192.168.66.65: ICMP echo reply, id 28729, seq 5, length > > > > 1480 > > > > >? ???>15:06:31.452071 IP *** > > > > > 192.168.66.65: icmp > > > > >? ???> > > > > >? ???>Same ping from same source > > > > (it's a 8.1 stable with fxp interface) to em card running > > > > 8.1 stable > > > > >? ???>#pciconf -lv > > > > >? > > > > ???>em0@pci0:3:4:0:??? > > > > class=0x020000 card=0x10798086 chip=0x10798086 rev=0x03 > > > > hdr=0x00 > > > > >? ???>? ? vendor? > > > > ???= 'Intel Corporation' > > > > >? ???>? ? device? > > > > ???= 'Dual Port Gigabit Ethernet Controller > > > > (82546EB)' > > > > >? ???>? ? class? > > > > ? ? = network > > > > >? ???>? ? > > > > subclass???= ethernet > > > > >? ???> > > > > >? ???># ping -s 1472 > > > > 192.168.64.200 > > > > >? ???>PING 192.168.64.200 > > > > (192.168.64.200): 1472 data bytes > > > > >? ???>1480 bytes from > > > > 192.168.64.200: icmp_seq=0 ttl=63 time=0.848 ms > > > > >? ???>^C > > > > >? ???> > > > > >? ???># ping -s 1473 > > > > 192.168.64.200 > > > > >? ???>PING 192.168.64.200 > > > > (192.168.64.200): 1473 data bytes > > > > >? ???>^C > > > > >? ???>--- 192.168.64.200 ping > > > > statistics --- > > > > >? ???>4 packets transmitted, 0 > > > > packets received, 100.0% packet loss > > > > > > > > > > works fine for me: > > > > > > > > > > FreeBSD 8.1-STABLE #0 r213395 > > > > > > > > > > em0@pci0:0:25:0:class=0x020000 card=0x3035103c > > > > chip=0x10de8086 rev=0x02 hdr=0x00 > > > > >? ???vendor? > > > > ???= 'Intel Corporation' > > > > >? ???device? > > > > ???= 'Intel Gigabit network connection > > > > (82567LM-3 )' > > > > >? ???class? ? ? = > > > > network > > > > >? ???subclass???= > > > > ethernet > > > > > > > > > > #ping -s 1473 host > > > > > PING host(192.168.1.1): 1473 data bytes > > > > > 1481 bytes from 192.168.1.1: icmp_seq=0 ttl=253 > > > > time=31.506 ms > > > > > 1481 bytes from 192.168.1.1: icmp_seq=1 ttl=253 > > > > time=31.493 ms > > > > > 1481 bytes from 192.168.1.1: icmp_seq=2 ttl=253 > > > > time=31.550 ms > > > > > ^C > > > > > > > > The reason the '-s 1500' worked was that the packets were > > > > fragmented. If > > > > I add the '-D' option, '-s 1473' fails on v7 and v8. Are > > > > the V8 systems > > > > where you see if failing without the '-D' on the same > > > > network segment? > > > > If not, it is likely that an intervening device is refusing > > > > to fragment > > > > the packet. (Some routers deliberately don't fragment ICMP > > > > Echos Request > > > > packets.) > > > > > > If i set -D -s 1473 sender side refuses to ping and that is > > > correct. All mentioned above machines are behind the same router and > > > switch. Same hardware running v7 is working while v8 is not. And i > > > never saw such problems before. Also correct me if i'm wrong but the > > > dump shows that the packet arrived. I'll try driver from head and will > > > post here results. > > > > I did a bit more looking at this today and I see that something bogus is > > going on and it MAY be the em driver. > > > > I tried 1473 data byte pings without the DF flag. I then captured the > > packets on both ends (where the sending system has a bge (Broadcom GE) > > and the responding end has an em (Intel) card. > > > > What I saw was the fragmented IP packets all being received by the > > system with the em interface and an ICMP Echo Reply being sent back, > > again fragmented. I saw the reply on both ends, so both interfaces were > > able to fragment an over-sized packet, transmit the two pieces, and > > receive the two pieces. The em device could re-assemble them properly, > > but the bge device does not seem to re-assemble them correctly or else > > has a problem with ICMP packets bigger then MTU size. > > > > When I send from the em system, I see the packets and fragments all > > arrive in good form, but the system never sends out a reply. Since this > > is a kernel function, it may be a driver, but I suspect that it is in > > the IP stack since I am seeing the problem with a Broadcom card and I > > see the data all arriving. > > > > Most ethernet controllers including bge(4) have a function to > specify how much RX buffer space would be allocated to receive a > frame. When controller receive a frame that has larger size than > the size specified in RX buffer space, it would drop the frame. > Because the oversized frame was silently dropped in driver layer > upper stack has no chance to reply back ICMP responses with > fragmentation needed bit for frames that set don't fragment bit. > This is where correct MTU configuration play an important role in > driver layer. If you want to handle oversized frame you also have > to set correct MTU of interface. However all controllers should be > able to receive standard MTU sized frame including VLAN tag so no > special configuration is needed when you handle standard MTU sized > frames. Some old controllers can't handle VLAN oversized frame such > that you would have no way to send or receive them. > > em(4) controllers have different receiving logic where it allows > chaining multiple oversized frames into a single frame. So up to > certain point, which depends on the size of jumbo frame controller > supports, em(4) can receive these oversized frames regardless of > MTU configuration with the help of driver. The chaining is done in > driver layer and that would add additional overhead(chaining + > multiple mbuf allocation) but it has its own advantages. > > I was not able to to reproduce the issue with em(4)/bge(4) on > CURRENT and these drivers worked as expected. I don't have any systems running CURRENT at the moment, so I can't check it out. I hope it is fixed there, but it needs to be fixed in STABLE. Not fragmenting packets that will not fit in a standard frame is a very serious issues as, when the frame is dropped, the source re-transmits the same over-sized frame. Of course, this should not happen if the interface is set to an MTU of 1500 as the higher layers should never pass a block of data larger than 1480 bytes to the IP layer. That's the only reason this had not already been noticed. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From owner-freebsd-net@FreeBSD.ORG Thu Nov 11 22:44:36 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A45711065672 for ; Thu, 11 Nov 2010 22:44:36 +0000 (UTC) (envelope-from rene@reckschwardt.de) Received: from rds11224.i4e-server.de (rds11224.i4e-server.de [195.225.105.212]) by mx1.freebsd.org (Postfix) with ESMTP id 164058FC0C for ; Thu, 11 Nov 2010 22:44:35 +0000 (UTC) Received: from mail.menny.de (p5DDABAAD.dip.t-dialin.net [93.218.186.173]) by rds11224.i4e-server.de (Postfix) with ESMTPSA id 72664B470D68 for ; Thu, 11 Nov 2010 23:44:34 +0100 (CET) Received: from [192.168.1.129] by mail.menny.de with esmtp (Exim 4.72) (envelope-from ) id 1PGfsd-0003rP-Mg for freebsd-net@freebsd.org; Thu, 11 Nov 2010 23:44:33 +0100 Date: Thu, 11 Nov 2010 22:44:31 +0000 From: "rene@reckschwardt.de" User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; de-DE; rv:1.9.2.9) Gecko/20100918 Thunderbird/3.1.4 MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <20101111193534.A7D838090AAD@rds11224.i4e-server.de> <20101111213156.GG17566@michelle.cdnetworks.com> In-Reply-To: <20101111213156.GG17566@michelle.cdnetworks.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090409030107010402060503" X-Scan-Signature: f7d467e91e8843a26f20f6b5d6b8b8e0 X-Spam-Score: -2.7 (--) Message-Id: <20101111224434.72664B470D68@rds11224.i4e-server.de> X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: ML370 G4 with poor Network Performance and high CPU Load X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 22:44:36 -0000 This is a cryptographically signed message in MIME format. --------------ms090409030107010402060503 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hello YongHyeon, yes, booth Test-Servers are in idle State, no Disk activity and no=20 important Networktraffic. the pciconf -lcbv for the Nics: em0@pci0:7:1:0: class=3D0x020000 card=3D0x00db0e11 chip=3D0x10108086 rev=3D= 0x01=20 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'Dual Port Gigabit Ethernet Controller (Copper)=20 (82546EB)' class =3D network subclass =3D ethernet bar [10] =3D type Memory, range 64, base 0xfdfe0000, size 131072, = enabled bar [18] =3D type Memory, range 64, base 0xfdf80000, size 262144, = enabled bar [20] =3D type I/O Port, range 32, base 0x6000, size 64, enable= d cap 01[dc] =3D powerspec 2 supports D0 D3 current D0 cap 07[e4] =3D PCI-X 64-bit supports 133MHz, 2048 burst read, 1 spli= t=20 transaction cap 05[f0] =3D MSI supports 1 message, 64 bit em1@pci0:7:1:1: class=3D0x020000 card=3D0x00db0e11 chip=3D0x10108086 rev=3D= 0x01=20 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'Dual Port Gigabit Ethernet Controller (Copper)=20 (82546EB)' class =3D network subclass =3D ethernet bar [10] =3D type Memory, range 64, base 0xfdf60000, size 131072, = enabled bar [20] =3D type I/O Port, range 32, base 0x6040, size 64, enable= d cap 01[dc] =3D powerspec 2 supports D0 D3 current D0 cap 07[e4] =3D PCI-X 64-bit supports 133MHz, 2048 burst read, 1 spli= t=20 transaction cap 05[f0] =3D MSI supports 1 message, 64 bit if you need more Info please ask me ;-) thanks for your responce r=E9 > On Thu, Nov 11, 2010 at 07:35:32PM +0000, rene@reckschwardt.de wrote: >> Hello, >> >> i am new in this Maillist and i use an ML370G4 with FreeBSD 8.1 AMD64.= I >> try with netio and TCP. The used Nics are onboard Broadcom >> (PCI-X133Mhz), an Broadcom PCI-X Nic and an intel PCI-X Nic. The CPU >> load is around 35% and the performance like this: >> >> Packet size 1k bytes: 99303 KByte/s Tx, 44576 KByte/s Rx. >> Packet size 2k bytes: 72043 KByte/s Tx, 75200 KByte/s Rx. >> Packet size 4k bytes: 23280 KByte/s Tx, 66072 KByte/s Rx. >> Packet size 8k bytes: 55234 KByte/s Tx, 64470 KByte/s Rx. >> Packet size 16k bytes: 82485 KByte/s Tx, 74099 KByte/s Rx. >> Packet size 32k bytes: 93133 KByte/s Tx, 74992 KByte/s Rx. >> > And you did perform the test on idle system?(No disk activity, no > other network IOs etc). > > Show me the dmesg output of verbose boot and output of "pciconf > -lcbv". > >> I try the following tuning: >> >> kern.ipc.maxsockbuf=3D16777216 >> net.inet.tcp.sendbuf_max=3D16777216 >> net.inet.tcp.recvbuf_max=3D16777216 >> net.inet.tcp.sendbuf_inc=3D16384 >> net.inet.tcp.recvbuf_inc=3D524288 >> net.inet.tcp.inflight.enable=3D0 >> net.inet.tcp.hostcache.expire=3D1 >> >> but this is not helpfull, the Load goes to 60% and the Performance is >> also poor. How can i prevent this Problem? >> >> thanks for response r? >> >> >> P.S. the same Computer with Linux runs perfect with Performance and 1-= 2% >> Load, >> > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > --------------ms090409030107010402060503-- From owner-freebsd-net@FreeBSD.ORG Thu Nov 11 22:53:42 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C8AB7106564A for ; Thu, 11 Nov 2010 22:53:42 +0000 (UTC) (envelope-from rene@reckschwardt.de) Received: from rds11224.i4e-server.de (rds11224.i4e-server.de [195.225.105.212]) by mx1.freebsd.org (Postfix) with ESMTP id 3C9DC8FC13 for ; Thu, 11 Nov 2010 22:53:41 +0000 (UTC) Received: from mail.menny.de (p5DDABAAD.dip.t-dialin.net [93.218.186.173]) by rds11224.i4e-server.de (Postfix) with ESMTPSA id C2835B470D68 for ; Thu, 11 Nov 2010 23:53:40 +0100 (CET) Received: from [192.168.1.129] by mail.menny.de with esmtp (Exim 4.72) (envelope-from ) id 1PGg1S-0003xY-Fa for freebsd-net@freebsd.org; Thu, 11 Nov 2010 23:53:39 +0100 Date: Thu, 11 Nov 2010 22:53:38 +0000 From: "rene@reckschwardt.de" User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; de-DE; rv:1.9.2.9) Gecko/20100918 Thunderbird/3.1.4 MIME-Version: 1.0 CC: freebsd-net@freebsd.org References: <20101111193534.A7D838090AAD@rds11224.i4e-server.de> <20101111213156.GG17566@michelle.cdnetworks.com> In-Reply-To: <20101111213156.GG17566@michelle.cdnetworks.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020508080001030802040000" X-Scan-Signature: 5200718ef1f7d98f215916eabbe1b237 X-Spam-Score: -2.2 (--) Message-Id: <20101111225340.C2835B470D68@rds11224.i4e-server.de> X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: ML370 G4 with poor Network Performance and high CPU Load X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 22:53:42 -0000 This is a cryptographically signed message in MIME format. --------------ms020508080001030802040000 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable here is the pciconf for the onboard Nic bge0@pci0:7:3:0: class=3D0x020000 card=3D0x00cb0e11 chip=3D0x16c71= 4e4=20 rev=3D0x10 hdr=3D0x00 vendor =3D 'Broadcom Corporation' device =3D 'BCM5703A3 NetXtreme Gigabit Ethernet' class =3D network subclass =3D ethernet bar [10] =3D type Memory, range 64, base 0xfdef0000, size 65536,=20 enabled cap 07[40] =3D PCI-X 64-bit supports 133MHz, 2048 burst read, 1 spli= t=20 transaction cap 01[48] =3D powerspec 2 supports D0 D3 current D0 cap 03[50] =3D VPD cap 05[58] =3D MSI supports 8 messages, 64 bit regards r=E9 --------------ms020508080001030802040000-- From owner-freebsd-net@FreeBSD.ORG Thu Nov 11 22:56:03 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5A9B8106566C; Thu, 11 Nov 2010 22:56:03 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id EEA4D8FC12; Thu, 11 Nov 2010 22:56:02 +0000 (UTC) Received: by gxk9 with SMTP id 9so1621903gxk.13 for ; Thu, 11 Nov 2010 14:56:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=IGhK6hQW1mD1EyOeGE257dnjStQ6J1uURysVGSQbkAU=; b=r+NImbQF1HBtoEqLeZih9I11lo0I5LUg5o563VbL2NjmfG4AeL5KR/pq8ZKc7K/ytU /vCcaqaz88sdg3eWyekFM5GaIDfsEjyhqNuNeF5BFL4/RzRCi6E9/lqA9B/CxJGGw+WO MqF0NX1PiOU8FV/bj+FCh8r66i6PfIibR+gPw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=ovl59JyI9j8k4NnigN9V/ZMYZTV0j8Rokl65Q0Rd/QmrBgDKng5+grapW1ffDj1tEJ RkIiz/U4NWi4lOhtqD5fxzopuRfK3ED8Sz0zeHF9PuwaMvdoS6m9lJi8RSwbMTjPZGL5 nOj1hO0LbndE25jjbiQ2/ACHvyjidhyji2XNI= Received: by 10.42.222.134 with SMTP id ig6mr1419612icb.403.1289516161242; Thu, 11 Nov 2010 14:56:01 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 8sm2915434iba.10.2010.11.11.14.55.59 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 11 Nov 2010 14:56:00 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Thu, 11 Nov 2010 14:55:05 -0800 From: Pyun YongHyeon Date: Thu, 11 Nov 2010 14:55:05 -0800 To: "rene@reckschwardt.de" Message-ID: <20101111225505.GL17566@michelle.cdnetworks.com> References: <20101111193534.A7D838090AAD@rds11224.i4e-server.de> <20101111213156.GG17566@michelle.cdnetworks.com> <20101111224434.72664B470D68@rds11224.i4e-server.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101111224434.72664B470D68@rds11224.i4e-server.de> User-Agent: Mutt/1.4.2.3i Cc: jfv@FreeBSD.org, freebsd-net@freebsd.org Subject: Re: ML370 G4 with poor Network Performance and high CPU Load X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 22:56:03 -0000 On Thu, Nov 11, 2010 at 10:44:31PM +0000, rene@reckschwardt.de wrote: > Hello YongHyeon, > > yes, booth Test-Servers are in idle State, no Disk activity and no > important Networktraffic. > > the pciconf -lcbv for the Nics: > > em0@pci0:7:1:0: class=0x020000 card=0x00db0e11 chip=0x10108086 rev=0x01 > hdr=0x00 > vendor = 'Intel Corporation' > device = 'Dual Port Gigabit Ethernet Controller (Copper) > (82546EB)' > class = network > subclass = ethernet > bar [10] = type Memory, range 64, base 0xfdfe0000, size 131072, > enabled > bar [18] = type Memory, range 64, base 0xfdf80000, size 262144, > enabled > bar [20] = type I/O Port, range 32, base 0x6000, size 64, enabled > cap 01[dc] = powerspec 2 supports D0 D3 current D0 > cap 07[e4] = PCI-X 64-bit supports 133MHz, 2048 burst read, 1 split > transaction > cap 05[f0] = MSI supports 1 message, 64 bit > em1@pci0:7:1:1: class=0x020000 card=0x00db0e11 chip=0x10108086 rev=0x01 > hdr=0x00 > vendor = 'Intel Corporation' > device = 'Dual Port Gigabit Ethernet Controller (Copper) > (82546EB)' > class = network > subclass = ethernet > bar [10] = type Memory, range 64, base 0xfdf60000, size 131072, > enabled > bar [20] = type I/O Port, range 32, base 0x6040, size 64, enabled > cap 01[dc] = powerspec 2 supports D0 D3 current D0 > cap 07[e4] = PCI-X 64-bit supports 133MHz, 2048 burst read, 1 split > transaction > cap 05[f0] = MSI supports 1 message, 64 bit > > if you need more Info please ask me ;-) > Hmmm, I don't see any Broadcom controllers here. If you see issues on em(4), Jack can help you. Note, 82546EB is really old controller and I also remember the performance was not great compared to PCIe version. > thanks for your responce r? > > >On Thu, Nov 11, 2010 at 07:35:32PM +0000, rene@reckschwardt.de wrote: > >> Hello, > >> > >>i am new in this Maillist and i use an ML370G4 with FreeBSD 8.1 AMD64. I > >>try with netio and TCP. The used Nics are onboard Broadcom > >>(PCI-X133Mhz), an Broadcom PCI-X Nic and an intel PCI-X Nic. The CPU > >>load is around 35% and the performance like this: > >> > >>Packet size 1k bytes: 99303 KByte/s Tx, 44576 KByte/s Rx. > >>Packet size 2k bytes: 72043 KByte/s Tx, 75200 KByte/s Rx. > >>Packet size 4k bytes: 23280 KByte/s Tx, 66072 KByte/s Rx. > >>Packet size 8k bytes: 55234 KByte/s Tx, 64470 KByte/s Rx. > >>Packet size 16k bytes: 82485 KByte/s Tx, 74099 KByte/s Rx. > >>Packet size 32k bytes: 93133 KByte/s Tx, 74992 KByte/s Rx. > >> > >And you did perform the test on idle system?(No disk activity, no > >other network IOs etc). > > > >Show me the dmesg output of verbose boot and output of "pciconf > >-lcbv". > > > >>I try the following tuning: > >> > >>kern.ipc.maxsockbuf=16777216 > >>net.inet.tcp.sendbuf_max=16777216 > >>net.inet.tcp.recvbuf_max=16777216 > >>net.inet.tcp.sendbuf_inc=16384 > >>net.inet.tcp.recvbuf_inc=524288 > >>net.inet.tcp.inflight.enable=0 > >>net.inet.tcp.hostcache.expire=1 > >> > >>but this is not helpfull, the Load goes to 60% and the Performance is > >>also poor. How can i prevent this Problem? > >> > >>thanks for response r? > >> > >> > >>P.S. the same Computer with Linux runs perfect with Performance and 1-2% > >>Load, > >> > >_______________________________________________ > >freebsd-net@freebsd.org mailing list > >http://lists.freebsd.org/mailman/listinfo/freebsd-net > >To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > > > From owner-freebsd-net@FreeBSD.ORG Fri Nov 12 00:05:57 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 966E01065670 for ; Fri, 12 Nov 2010 00:05:57 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from vps.hungerhost.com (vps.hungerhost.com [216.38.53.176]) by mx1.freebsd.org (Postfix) with ESMTP id 6900A8FC14 for ; Fri, 12 Nov 2010 00:05:57 +0000 (UTC) Received: from smtp.hudson-trading.com ([209.249.190.9] helo=gnnmac.hudson-trading.com) by vps.hungerhost.com with esmtpa (Exim 4.69) (envelope-from ) id 1PGYdl-0005kv-LQ; Thu, 11 Nov 2010 10:00:43 -0500 From: George Neville-Neil Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 11 Nov 2010 10:00:41 -0500 Message-Id: To: arch@freebsd.org Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - vps.hungerhost.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - neville-neil.com X-Source: X-Source-Args: X-Source-Dir: Cc: net@freebsd.org Subject: Updated ARP Queue Patch... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Nov 2010 00:05:57 -0000 Howdy, After some excellent comments from Bjoern I've put together the = following patch: http://people.freebsd.org/~gnn/head-arpqueue4.diff Please review and comment. Best, George From owner-freebsd-net@FreeBSD.ORG Fri Nov 12 02:29:16 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D8DD7106564A; Fri, 12 Nov 2010 02:29:16 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) by mx1.freebsd.org (Postfix) with ESMTP id 4857F8FC1D; Fri, 12 Nov 2010 02:29:16 +0000 (UTC) Received: from lawrence1.loshell.room52.net (ppp59-167-184-191.static.internode.on.net [59.167.184.191]) by lauren.room52.net (Postfix) with ESMTPSA id 2B09C7E84A; Fri, 12 Nov 2010 13:29:14 +1100 (EST) Message-ID: <4CDCA679.7020401@freebsd.org> Date: Fri, 12 Nov 2010 13:29:13 +1100 From: Lawrence Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-AU; rv:1.9.2.9) Gecko/20101006 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: Julian Elischer References: <4CDC5490.7030109@freebsd.org> In-Reply-To: <4CDC5490.7030109@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=5.0 tests=T_FRT_CONTACT, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on lauren.room52.net Cc: freebsd-net@freebsd.org, Christopher Penney , Andre Oppermann Subject: Re: NFS + FreeBSD TCP Behavior with Linux NAT X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Nov 2010 02:29:17 -0000 On 11/12/10 07:39, Julian Elischer wrote: > On 11/11/10 6:36 AM, Christopher Penney wrote: >> Hi, >> >> I have a curious problem I'm hoping someone can help with or at least >> educate me on. >> >> I have several large Linux clusters and for each one we hide the compute >> nodes behind a head node using NAT. Historically, this has worked >> very well >> for us and any time a NAT gateway (the head node) reboots everything >> recovers within a minute or two of it coming back up. This includes NFS >> mounts from Linux and Solaris NFS servers, license server connections, >> etc. >> >> Recently, we added a FreeBSD based NFS server to our cluster resources >> and >> have had significant issues with NFS mounts hanging if the head node >> reboots. We don't have this happen much, but it does occasionally >> happen. >> I've explored this and it seems the behavior of FreeBSD differs a >> bit from >> at least Linux and Solaris with respect to TCP recovery. I'm curious if >> someone can explain this or offer any workarounds. >> >> Here are some specifics from a test I ran: >> >> Before the reboot two Linux clients were mounting the FreeBSD server. >> They >> were both using port 903 locally. On the head node clientA:903 was >> remapped >> to headnode:903 and clientB:903 was remapped to headnode:601. There >> is no >> activity when the reboot occurs. The head node takes a few minutes to >> come >> back up (we kept it down for several minutes). >> >> When it comes back up clientA and clientB try to reconnect to the FreeBSD >> NFS server. They both use the same source port, but since the head >> node's >> conntrack table is cleared it's a race to see who gets what port and this >> time clientA:903 appears as headnode:601 and clientB:903 appears as >> headnode:903 (>>> they essentially switch places as far as the FreeBSD >> server would see<<< ). >> >> The FreeBSD NFS server, since there was no outstanding acks it was >> waiting >> on, thinks things are ok so when it gets a SYN from the two clients it >> only >> responds with an ACK. The ACK for each that it replies with is bogus >> (invalid seq number) because it's using the return path the other >> client was >> using before the reboot so the client sends a RST back, but it never >> gets to >> the FreeBSD system since the head node's NAT hasn't yet seen the full >> handshake (that would allow return packets). The end result is a >> "permanent" hang (at least until it would otherwise cleanup idle TCP >> connections). >> >> This is in stark contrast to the behavior of the other systems we have. >> Other systems respond to the SYN used to reconnect with a SYN/ACK. >> They >> appear to implicitly tear down the return path based on getting a SYN >> from a >> seemingly already established connection. >> >> I'm assuming this is one of the grey areas where there is no specific >> behavior outlined in an RFC? Is there any way to make the FreeBSD system >> more reliable in this situation (like making it implicitly tear down the >> return)? Or is there a way to adjust the NAT setup to allow the RST to >> return to the FreeBSD system? Currently, NAT is setup with simply: >> >> iptables -t nat -A POSTROUTING -s 10.1.0.0/16 -o bond0 -j SNAT --to >> 1.2.3.4 >> >> Where 1.2.3.4 is the intranet address and 10.1.0.0 is the cluster >> network. > > I just added NFS to the subject because the NFS people are thise you > need to > connect with. Skimming Chris' problem description, I don't think I agree that this is an NFS issue and agree with Chris that it's netstack related behaviour as opposed to application related. Chris, I have minimal cycles at the moment and your scenario is bending my brain a little bit too much to give a quick response. A tcpdump excerpt showing such an exchange would be very useful. I'll try come back to it when I I have a sec. Andre, do you have a few cycles to digest this in more detail? Cheers, Lawrence From owner-freebsd-net@FreeBSD.ORG Fri Nov 12 06:26:21 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 411361065674 for ; Fri, 12 Nov 2010 06:26:21 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id B57AE8FC13 for ; Fri, 12 Nov 2010 06:26:20 +0000 (UTC) Received: (qmail 21049 invoked from network); 12 Nov 2010 06:10:18 -0000 Received: from localhost (HELO [127.0.0.1]) ([127.0.0.1]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 12 Nov 2010 06:10:18 -0000 Message-ID: <4CDCDE0F.8010501@freebsd.org> Date: Fri, 12 Nov 2010 07:26:23 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Lawrence Stewart References: <4CDC5490.7030109@freebsd.org> <4CDCA679.7020401@freebsd.org> In-Reply-To: <4CDCA679.7020401@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Christopher Penney Subject: Re: NFS + FreeBSD TCP Behavior with Linux NAT X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Nov 2010 06:26:21 -0000 On 12.11.2010 03:29, Lawrence Stewart wrote: > On 11/12/10 07:39, Julian Elischer wrote: >> On 11/11/10 6:36 AM, Christopher Penney wrote: >>> Hi, >>> >>> I have a curious problem I'm hoping someone can help with or at least >>> educate me on. >>> >>> I have several large Linux clusters and for each one we hide the compute >>> nodes behind a head node using NAT. Historically, this has worked >>> very well >>> for us and any time a NAT gateway (the head node) reboots everything >>> recovers within a minute or two of it coming back up. This includes NFS >>> mounts from Linux and Solaris NFS servers, license server connections, >>> etc. >>> >>> Recently, we added a FreeBSD based NFS server to our cluster resources >>> and >>> have had significant issues with NFS mounts hanging if the head node >>> reboots. We don't have this happen much, but it does occasionally >>> happen. >>> I've explored this and it seems the behavior of FreeBSD differs a >>> bit from >>> at least Linux and Solaris with respect to TCP recovery. I'm curious if >>> someone can explain this or offer any workarounds. >>> >>> Here are some specifics from a test I ran: >>> >>> Before the reboot two Linux clients were mounting the FreeBSD server. >>> They >>> were both using port 903 locally. On the head node clientA:903 was >>> remapped >>> to headnode:903 and clientB:903 was remapped to headnode:601. There >>> is no >>> activity when the reboot occurs. The head node takes a few minutes to >>> come >>> back up (we kept it down for several minutes). >>> >>> When it comes back up clientA and clientB try to reconnect to the FreeBSD >>> NFS server. They both use the same source port, but since the head >>> node's >>> conntrack table is cleared it's a race to see who gets what port and this >>> time clientA:903 appears as headnode:601 and clientB:903 appears as >>> headnode:903 (>>> they essentially switch places as far as the FreeBSD >>> server would see<<< ). >>> >>> The FreeBSD NFS server, since there was no outstanding acks it was >>> waiting >>> on, thinks things are ok so when it gets a SYN from the two clients it >>> only >>> responds with an ACK. The ACK for each that it replies with is bogus >>> (invalid seq number) because it's using the return path the other >>> client was >>> using before the reboot so the client sends a RST back, but it never >>> gets to >>> the FreeBSD system since the head node's NAT hasn't yet seen the full >>> handshake (that would allow return packets). The end result is a >>> "permanent" hang (at least until it would otherwise cleanup idle TCP >>> connections). >>> >>> This is in stark contrast to the behavior of the other systems we have. >>> Other systems respond to the SYN used to reconnect with a SYN/ACK. >>> They >>> appear to implicitly tear down the return path based on getting a SYN >>> from a >>> seemingly already established connection. >>> >>> I'm assuming this is one of the grey areas where there is no specific >>> behavior outlined in an RFC? Is there any way to make the FreeBSD system >>> more reliable in this situation (like making it implicitly tear down the >>> return)? Or is there a way to adjust the NAT setup to allow the RST to >>> return to the FreeBSD system? Currently, NAT is setup with simply: >>> >>> iptables -t nat -A POSTROUTING -s 10.1.0.0/16 -o bond0 -j SNAT --to >>> 1.2.3.4 >>> >>> Where 1.2.3.4 is the intranet address and 10.1.0.0 is the cluster >>> network. >> >> I just added NFS to the subject because the NFS people are thise you >> need to >> connect with. > > Skimming Chris' problem description, I don't think I agree that this is > an NFS issue and agree with Chris that it's netstack related behaviour > as opposed to application related. > > Chris, I have minimal cycles at the moment and your scenario is bending > my brain a little bit too much to give a quick response. A tcpdump > excerpt showing such an exchange would be very useful. I'll try come > back to it when I I have a sec. Andre, do you have a few cycles to > digest this in more detail? I had very few cycles since EuroBSDCon as well but this weekend my little son has a sleep over at my mother in law and my wife is at work. So I'm going to reduce my FreeBSD backlog. There are a few things that have queued up. I should get enough time to take care of this one. -- Andre From owner-freebsd-net@FreeBSD.ORG Fri Nov 12 07:27:47 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6B0611065673 for ; Fri, 12 Nov 2010 07:27:47 +0000 (UTC) (envelope-from zeus@relay.ibs.dn.ua) Received: from relay.ibs.dn.ua (relay.ibs.dn.ua [91.216.196.25]) by mx1.freebsd.org (Postfix) with ESMTP id C3B868FC0C for ; Fri, 12 Nov 2010 07:27:46 +0000 (UTC) Received: from relay.ibs.dn.ua (localhost [127.0.0.1]) by relay.ibs.dn.ua with ESMTP id oAC77xDq096615 for ; Fri, 12 Nov 2010 09:07:59 +0200 (EET) Received: (from zeus@localhost) by relay.ibs.dn.ua (8.14.4/8.14.4/Submit) id oAC77xqM096614 for freebsd-net@freebsd.org; Fri, 12 Nov 2010 09:07:59 +0200 (EET) Date: Fri, 12 Nov 2010 09:07:59 +0200 From: Zeus V Panchenko To: freebsd-net@freebsd.org Message-ID: <20101112070759.GA36248@relay.ibs.dn.ua> References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 8.1-RELEASE X-Editor: GNU Emacs 23.2.1 Subject: Re: Problem with re0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: zeus@ibs.dn.ua List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Nov 2010 07:27:47 -0000 Hi, Gabor Radnai (gabor.radnai@gmail.com) [10.11.11 23:22] wrote: > pciconf: > nfe0@pci0:0:20:0: class=0x068000 card=0x816a1043 chip=0x026910de rev=0xa3 > hdr=0x00 > vendor = 'NVIDIA Corporation' > device = 'MCP51 Network Bus Enumerator' > class = bridge > re0@pci0:1:0:0: class=0x020000 card=0x816810ec chip=0x816810ec rev=0x01 > hdr=0x00 > vendor = 'Realtek Semiconductor' > device = 'Gigabit Ethernet NIC(NDIS 6.0) (RTL8168/8111/8111c)' > class = network > subclass = ethernet > i have the same problem (i was writing here before, but still no idea) with onboard (Realtek Gigabit Ethernet NIC(NDIS 6.0) (RTL8168/8111/8111c)) nic while the same driver but another vendor (D-Link DGE-528T Gigabit adaptor (dlg10086)) nic works fine ... the flapping of the realtek interface is so much drastic, that i was forced to unplug the cable even on the ip less nic i was sure it is the problem of the onboard rt nics ... uname: FreeBSD 8.1-STABLE #3 amd64 pciconf -lv: re0@pci0:2:0:0: class=0x020000 card=0x83a31043 chip=0x816810ec rev=0x03 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'Gigabit Ethernet NIC(NDIS 6.0) (RTL8168/8111/8111c)' class = network subclass = ethernet re1@pci0:1:0:0: class=0x020000 card=0x43001186 chip=0x43001186 rev=0x10 hdr=0x00 vendor = 'D-Link System Inc' device = 'Used on DGE-528T Gigabit adaptor (dlg10086)' class = network subclass = ethernet dmidecode: Handle 0x0002, DMI type 2, 15 bytes Base Board Information Manufacturer: ASUSTeK Computer INC. Product Name: AT5NM10-I Version: Rev x.0x Serial Number: MT7006K15200628 Asset Tag: To Be Filled By O.E.M. Features: Board is a hosting board Board is replaceable Location In Chassis: To Be Filled By O.E.M. Chassis Handle: 0x0003 Type: Motherboard Contained Object Handles: 0 Handle 0x0012, DMI type 8, 9 bytes Port Connector Information Internal Reference Designator: LAN Internal Connector Type: None External Reference Designator: LAN External Connector Type: RJ-45 Port Type: Network Port -- Zeus V. Panchenko IT Dpt., IBS ltd GMT+2 (EET) From owner-freebsd-net@FreeBSD.ORG Fri Nov 12 08:02:56 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E98B4106566B; Fri, 12 Nov 2010 08:02:56 +0000 (UTC) (envelope-from rpaulo@lavabit.com) Received: from karen.lavabit.com (karen.lavabit.com [72.249.41.33]) by mx1.freebsd.org (Postfix) with ESMTP id A099B8FC12; Fri, 12 Nov 2010 08:02:56 +0000 (UTC) Received: from d.earth.lavabit.com (d.earth.lavabit.com [192.168.111.13]) by karen.lavabit.com (Postfix) with ESMTP id D7AA211B83A; Fri, 12 Nov 2010 01:38:53 -0600 (CST) Received: from 192.168.1.70 (bl17-149-52.dsl.telepac.pt [188.82.149.52]) by lavabit.com with ESMTP id FY3X08BENJVA; Fri, 12 Nov 2010 01:38:53 -0600 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=lavabit; d=lavabit.com; b=lQkE4MYJH5nmOU/Tf8UzQSD68uTHTXDQfGzggJSKAFYBtIC2AUU8Sc8imKLzrIgjuuqIUh1XJW1G2soXldtNbTi46zD7WVVXTBIKM2t/UKUmPHF0yCZNHJL+nY4dn60/DiwpkmEphfzpOWtNVuvPCPW/NVYZL5u1A23RrLXh17o=; h=References:In-Reply-To:Mime-Version:Content-Type:Message-Id:Content-Transfer-Encoding:Cc:From:Subject:Date:To:X-Mailer; References: In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii Message-Id: <1C1981FB-1B67-4873-9B23-39D51B61F5B3@lavabit.com> Content-Transfer-Encoding: quoted-printable From: Rui Paulo Date: Fri, 12 Nov 2010 07:38:50 +0000 To: George Neville-Neil X-Mailer: Apple Mail (2.1082) Cc: arch@freebsd.org, net@freebsd.org Subject: Re: Updated ARP Queue Patch... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Nov 2010 08:02:57 -0000 On Nov 11, 2010, at 3:00 PM, George Neville-Neil wrote: > Howdy, >=20 > After some excellent comments from Bjoern I've put together the = following patch: >=20 > http://people.freebsd.org/~gnn/head-arpqueue4.diff >=20 > Please review and comment. Looks good to me. Regards, -- Rui Paulo From owner-freebsd-net@FreeBSD.ORG Fri Nov 12 09:44:31 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5890B106566C; Fri, 12 Nov 2010 09:44:31 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) by mx1.freebsd.org (Postfix) with ESMTP id C74A08FC08; Fri, 12 Nov 2010 09:44:30 +0000 (UTC) Received: from lawrence1.loshell.room52.net (ppp59-167-184-191.static.internode.on.net [59.167.184.191]) by lauren.room52.net (Postfix) with ESMTPSA id B60827E853; Fri, 12 Nov 2010 20:44:29 +1100 (EST) Message-ID: <4CDD0C7D.1070102@freebsd.org> Date: Fri, 12 Nov 2010 20:44:29 +1100 From: Lawrence Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-AU; rv:1.9.2.9) Gecko/20101006 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: Andre Oppermann References: <20100512124702.GJ2679@rambler-co.ru> <20100713140051.GV99657@mdounin.ru> <4C5BCE48.5070504@freebsd.org> <20100913172453.GG99657@mdounin.ru> <20100927081217.GM44164@mdounin.ru> <4CA09987.8020205@freebsd.org> <20101102001134.GP44164@mdounin.ru> <4CD090EF.4020402@freebsd.org> <4CD64814.2000906@freebsd.org> In-Reply-To: <4CD64814.2000906@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on lauren.room52.net Cc: freebsd-net@freebsd.org, Igor Sysoev , Maxim Dounin Subject: Re: net.inet.tcp.slowstart_flightsize in 8-STABLE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Nov 2010 09:44:31 -0000 On 11/07/10 17:32, Lawrence Stewart wrote: > On 11/03/10 09:30, Andre Oppermann wrote: >> On 02.11.2010 01:11, Maxim Dounin wrote: >>> Hello! >>> >>> On Mon, Sep 27, 2010 at 03:17:59PM +0200, Andre Oppermann wrote: >>> >>>> On 27.09.2010 10:12, Maxim Dounin wrote: >>>>> Hello! >>>>> >>>>> On Mon, Sep 13, 2010 at 09:24:53PM +0400, Maxim Dounin wrote: >>>>> >>>>> [...] >>>>> >>>>>> Andre, could you please take a look at one more patch as well? >>>>>> >>>>>> Igor reported that it still sees 100ms delays with rfc3465 turned >>>>>> on, and it turns out to be similar issue (setting cwnd to 1*MSS) >>>>>> for hosts found in hostcache. >>>>>> >>>>>> The problem with setting cwnd from hostcache was already reported >>>>>> here: >>>>>> >>>>>> http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/92690 >>>>>> http://lists.freebsd.org/pipermail/freebsd-net/2007-July/014780.html >>>>>> >>>>>> As using larger cwnd from hostcache may cause problems on >>>>>> congested links (see second thread) I changed code to only use >>>>>> cached cwnd as an upper bound for cwnd (instead of fixing current >>>>>> code). This is also in-line with what we do on connection >>>>>> restarts. >>>>>> >>>>>> We may later consider re-adding usage of larger cwnd from >>>>>> hostcache. But I believe it should be done carefully and >>>>>> probably behind sysctl, off by default. >>>>> >>>>> Ping. >>>> >>>> Thanks for the reminder. I'll disable priming CWND from hostcache. >>> >>> Ping again. >>> >>> I would like to see the patch in question[1] committed and MFC'ed >>> somewhere before 8.2. >>> >>> Andre, if you are just too busy to do it yourself - please say so, >>> I'll ask somebody else to commit it. >> >> Thanks for the reminder. After EuroBSDCon Developer Summit I was >> busy with other work and most of my tcp work was stalled due to >> review bandwidth issues. > > Sorry for the review bandwidth issues. I'm only just managing to keep my > head above water at the moment and have had to reduce much of my FreeBSD > work to a trickle. > >> Lawrence, could you please spare a few seconds and take a quick look >> at the attached patch? > > The patch looks fine, please commit. I hope to give the hostcache some > TLC at some point, but in the meantime it's fine to ignore cached cwnd. FYI Andre, this patch got rolled into r215166 because I had to move all the code around which the patch was based on. Is that going to cause any issues here? I should have checked prior to committing but completely forgot I had pulled the patch into my dev tree before creating the mod CC patch. Cheers, Lawrence From owner-freebsd-net@FreeBSD.ORG Fri Nov 12 09:35:52 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 69FD4106566C for ; Fri, 12 Nov 2010 09:35:52 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) by mx1.freebsd.org (Postfix) with ESMTP id D84228FC25 for ; Fri, 12 Nov 2010 09:35:51 +0000 (UTC) Received: from lawrence1.loshell.room52.net (ppp59-167-184-191.static.internode.on.net [59.167.184.191]) by lauren.room52.net (Postfix) with ESMTPSA id D7C817E84A; Fri, 12 Nov 2010 20:35:45 +1100 (EST) Message-ID: <4CDD0A71.7020708@freebsd.org> Date: Fri, 12 Nov 2010 20:35:45 +1100 From: Lawrence Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-AU; rv:1.9.2.9) Gecko/20101006 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: freebsd-current@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on lauren.room52.net X-Mailman-Approved-At: Fri, 12 Nov 2010 09:55:54 +0000 Cc: Subject: [HEADS UP] Significant TCP work committed to head X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Nov 2010 09:35:52 -0000 Hi All, A quick note that this evening, I made the first in a series of upcoming commits to head that modify the TCP stack fairly significantly. I have no reason to believe you'll notice any issues, but TCP is a complex beast and it's possible things might crop up. The changes are mostly related to congestion control, so the sorts of issues that are likely to crop up if any will most probably be subtle and difficult to even detect. The first svn revision in question is r215166. The next few commits I plan to make will be basically zero impact and then another significant patch will follow in a few weeks. If you bump into an issue that you think might be related to this work, please roll back r215166 from your tree and attempt to reporoduce before reporting the problem. Please CC me directly with your problem report and post to freebsd-current@ or freebsd-net@ as well. Lots more information about what all this does and how to use it will be following in the coming weeks, but in the meantime, just keep this note in the back of your mind. For the curious, some information about the project is available at [1,2]. Cheers, Lawrence [1] http://caia.swin.edu.au/freebsd/5cc/ [2] http://www.freebsd.org/news/status/report-2010-07-2010-09.html#Five-New-TCP-Congestion-Control-Algorithms-for-FreeBSD From owner-freebsd-net@FreeBSD.ORG Fri Nov 12 10:21:32 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ADEDA106566C; Fri, 12 Nov 2010 10:21:32 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) by mx1.freebsd.org (Postfix) with ESMTP id 41B5E8FC15; Fri, 12 Nov 2010 10:21:32 +0000 (UTC) Received: from lawrence1.loshell.room52.net (ppp59-167-184-191.static.internode.on.net [59.167.184.191]) by lauren.room52.net (Postfix) with ESMTPSA id B128E7E84A; Fri, 12 Nov 2010 21:21:30 +1100 (EST) Message-ID: <4CDD1529.8070504@freebsd.org> Date: Fri, 12 Nov 2010 21:21:29 +1100 From: Lawrence Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-AU; rv:1.9.2.9) Gecko/20101006 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: Andre Oppermann References: <20100512124702.GJ2679@rambler-co.ru> <20100713140051.GV99657@mdounin.ru> <4C5BCE48.5070504@freebsd.org> <20100913172453.GG99657@mdounin.ru> <20100927081217.GM44164@mdounin.ru> <4CA09987.8020205@freebsd.org> <20101102001134.GP44164@mdounin.ru> <4CD090EF.4020402@freebsd.org> <4CD64814.2000906@freebsd.org> <4CDD0C7D.1070102@freebsd.org> In-Reply-To: <4CDD0C7D.1070102@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on lauren.room52.net Cc: freebsd-net@freebsd.org, Igor Sysoev , Maxim Dounin Subject: Re: net.inet.tcp.slowstart_flightsize in 8-STABLE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Nov 2010 10:21:32 -0000 On 11/12/10 20:44, Lawrence Stewart wrote: > On 11/07/10 17:32, Lawrence Stewart wrote: >> On 11/03/10 09:30, Andre Oppermann wrote: >>> On 02.11.2010 01:11, Maxim Dounin wrote: >>>> Hello! >>>> >>>> On Mon, Sep 27, 2010 at 03:17:59PM +0200, Andre Oppermann wrote: >>>> >>>>> On 27.09.2010 10:12, Maxim Dounin wrote: >>>>>> Hello! >>>>>> >>>>>> On Mon, Sep 13, 2010 at 09:24:53PM +0400, Maxim Dounin wrote: >>>>>> >>>>>> [...] >>>>>> >>>>>>> Andre, could you please take a look at one more patch as well? >>>>>>> >>>>>>> Igor reported that it still sees 100ms delays with rfc3465 turned >>>>>>> on, and it turns out to be similar issue (setting cwnd to 1*MSS) >>>>>>> for hosts found in hostcache. >>>>>>> >>>>>>> The problem with setting cwnd from hostcache was already reported >>>>>>> here: >>>>>>> >>>>>>> http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/92690 >>>>>>> http://lists.freebsd.org/pipermail/freebsd-net/2007-July/014780.html >>>>>>> >>>>>>> As using larger cwnd from hostcache may cause problems on >>>>>>> congested links (see second thread) I changed code to only use >>>>>>> cached cwnd as an upper bound for cwnd (instead of fixing current >>>>>>> code). This is also in-line with what we do on connection >>>>>>> restarts. >>>>>>> >>>>>>> We may later consider re-adding usage of larger cwnd from >>>>>>> hostcache. But I believe it should be done carefully and >>>>>>> probably behind sysctl, off by default. >>>>>> >>>>>> Ping. >>>>> >>>>> Thanks for the reminder. I'll disable priming CWND from hostcache. >>>> >>>> Ping again. >>>> >>>> I would like to see the patch in question[1] committed and MFC'ed >>>> somewhere before 8.2. >>>> >>>> Andre, if you are just too busy to do it yourself - please say so, >>>> I'll ask somebody else to commit it. >>> >>> Thanks for the reminder. After EuroBSDCon Developer Summit I was >>> busy with other work and most of my tcp work was stalled due to >>> review bandwidth issues. >> >> Sorry for the review bandwidth issues. I'm only just managing to keep my >> head above water at the moment and have had to reduce much of my FreeBSD >> work to a trickle. >> >>> Lawrence, could you please spare a few seconds and take a quick look >>> at the attached patch? >> >> The patch looks fine, please commit. I hope to give the hostcache some >> TLC at some point, but in the meantime it's fine to ignore cached cwnd. > > FYI Andre, this patch got rolled into r215166 because I had to move all > the code around which the patch was based on. Is that going to cause any > issues here? I should have checked prior to committing but completely > forgot I had pulled the patch into my dev tree before creating the mod > CC patch. Gah, I think I've answered my own question. MFCing the patch standalone in time for 8.2 as Maxim requested is not going to be possible. I think I'll have to back out r215166, commit your patch and then recommit the modular CC patch. Unless someone can think of a way that doesn't involve all the mucking about? Cheers, Lawrence From owner-freebsd-net@FreeBSD.ORG Fri Nov 12 11:13:13 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E44EF1065670; Fri, 12 Nov 2010 11:13:13 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 5ED698FC0A; Fri, 12 Nov 2010 11:13:12 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id oACAf9F3040496 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Nov 2010 12:41:09 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id oACAf9DK059842; Fri, 12 Nov 2010 12:41:09 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id oACAf9K8059841; Fri, 12 Nov 2010 12:41:09 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 12 Nov 2010 12:41:09 +0200 From: Kostik Belousov To: Lawrence Stewart Message-ID: <20101112104109.GY2392@deviant.kiev.zoral.com.ua> References: <20100713140051.GV99657@mdounin.ru> <4C5BCE48.5070504@freebsd.org> <20100913172453.GG99657@mdounin.ru> <20100927081217.GM44164@mdounin.ru> <4CA09987.8020205@freebsd.org> <20101102001134.GP44164@mdounin.ru> <4CD090EF.4020402@freebsd.org> <4CD64814.2000906@freebsd.org> <4CDD0C7D.1070102@freebsd.org> <4CDD1529.8070504@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="N+om2BM+ElqV+U6I" Content-Disposition: inline In-Reply-To: <4CDD1529.8070504@freebsd.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-net@freebsd.org, Igor Sysoev , Andre Oppermann , Maxim Dounin Subject: Re: net.inet.tcp.slowstart_flightsize in 8-STABLE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Nov 2010 11:13:14 -0000 --N+om2BM+ElqV+U6I Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Nov 12, 2010 at 09:21:29PM +1100, Lawrence Stewart wrote: > On 11/12/10 20:44, Lawrence Stewart wrote: > > On 11/07/10 17:32, Lawrence Stewart wrote: > >> On 11/03/10 09:30, Andre Oppermann wrote: > >>> On 02.11.2010 01:11, Maxim Dounin wrote: > >>>> Hello! > >>>> > >>>> On Mon, Sep 27, 2010 at 03:17:59PM +0200, Andre Oppermann wrote: > >>>> > >>>>> On 27.09.2010 10:12, Maxim Dounin wrote: > >>>>>> Hello! > >>>>>> > >>>>>> On Mon, Sep 13, 2010 at 09:24:53PM +0400, Maxim Dounin wrote: > >>>>>> > >>>>>> [...] > >>>>>> > >>>>>>> Andre, could you please take a look at one more patch as well? > >>>>>>> > >>>>>>> Igor reported that it still sees 100ms delays with rfc3465 turned > >>>>>>> on, and it turns out to be similar issue (setting cwnd to 1*MSS) > >>>>>>> for hosts found in hostcache. > >>>>>>> > >>>>>>> The problem with setting cwnd from hostcache was already reported > >>>>>>> here: > >>>>>>> > >>>>>>> http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dkern/92690 > >>>>>>> http://lists.freebsd.org/pipermail/freebsd-net/2007-July/014780.h= tml > >>>>>>> > >>>>>>> As using larger cwnd from hostcache may cause problems on > >>>>>>> congested links (see second thread) I changed code to only use > >>>>>>> cached cwnd as an upper bound for cwnd (instead of fixing current > >>>>>>> code). This is also in-line with what we do on connection > >>>>>>> restarts. > >>>>>>> > >>>>>>> We may later consider re-adding usage of larger cwnd from > >>>>>>> hostcache. But I believe it should be done carefully and > >>>>>>> probably behind sysctl, off by default. > >>>>>> > >>>>>> Ping. > >>>>> > >>>>> Thanks for the reminder. I'll disable priming CWND from hostcache. > >>>> > >>>> Ping again. > >>>> > >>>> I would like to see the patch in question[1] committed and MFC'ed > >>>> somewhere before 8.2. > >>>> > >>>> Andre, if you are just too busy to do it yourself - please say so, > >>>> I'll ask somebody else to commit it. > >>> > >>> Thanks for the reminder. After EuroBSDCon Developer Summit I was > >>> busy with other work and most of my tcp work was stalled due to > >>> review bandwidth issues. > >> > >> Sorry for the review bandwidth issues. I'm only just managing to keep = my > >> head above water at the moment and have had to reduce much of my FreeB= SD > >> work to a trickle. > >> > >>> Lawrence, could you please spare a few seconds and take a quick look > >>> at the attached patch? > >> > >> The patch looks fine, please commit. I hope to give the hostcache some > >> TLC at some point, but in the meantime it's fine to ignore cached cwnd. > >=20 > > FYI Andre, this patch got rolled into r215166 because I had to move all > > the code around which the patch was based on. Is that going to cause any > > issues here? I should have checked prior to committing but completely > > forgot I had pulled the patch into my dev tree before creating the mod > > CC patch. >=20 > Gah, I think I've answered my own question. MFCing the patch standalone > in time for 8.2 as Maxim requested is not going to be possible. I think > I'll have to back out r215166, commit your patch and then recommit the > modular CC patch. >=20 > Unless someone can think of a way that doesn't involve all the mucking > about? Well, if the change is indeed already in HEAD, you can do a direct commit to stable/8 after proper MFC period, noting that this is a cherry-pick of the part of corresponding revision. --N+om2BM+ElqV+U6I Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAkzdGcQACgkQC3+MBN1Mb4gmywCeNialKmZswaQvBadXdyHZqhhE eLAAnA7jMUKYywgFzB0K1VKonZYH5B7S =EMru -----END PGP SIGNATURE----- --N+om2BM+ElqV+U6I-- From owner-freebsd-net@FreeBSD.ORG Fri Nov 12 13:18:33 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 071821065675; Fri, 12 Nov 2010 13:18:33 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) by mx1.freebsd.org (Postfix) with ESMTP id 8B32B8FC1A; Fri, 12 Nov 2010 13:18:32 +0000 (UTC) Received: from lawrence1.loshell.room52.net (ppp59-167-184-191.static.internode.on.net [59.167.184.191]) by lauren.room52.net (Postfix) with ESMTPSA id EFBA47E8BA; Sat, 13 Nov 2010 00:18:29 +1100 (EST) Message-ID: <4CDD3EA5.7020101@freebsd.org> Date: Sat, 13 Nov 2010 00:18:29 +1100 From: Lawrence Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-AU; rv:1.9.2.9) Gecko/20101006 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: Kostik Belousov References: <20100713140051.GV99657@mdounin.ru> <4C5BCE48.5070504@freebsd.org> <20100913172453.GG99657@mdounin.ru> <20100927081217.GM44164@mdounin.ru> <4CA09987.8020205@freebsd.org> <20101102001134.GP44164@mdounin.ru> <4CD090EF.4020402@freebsd.org> <4CD64814.2000906@freebsd.org> <4CDD0C7D.1070102@freebsd.org> <4CDD1529.8070504@freebsd.org> <20101112104109.GY2392@deviant.kiev.zoral.com.ua> In-Reply-To: <20101112104109.GY2392@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on lauren.room52.net Cc: freebsd-net@freebsd.org, Igor Sysoev , Andre Oppermann , Maxim Dounin Subject: Re: net.inet.tcp.slowstart_flightsize in 8-STABLE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Nov 2010 13:18:33 -0000 On 11/12/10 21:41, Kostik Belousov wrote: > On Fri, Nov 12, 2010 at 09:21:29PM +1100, Lawrence Stewart wrote: >> On 11/12/10 20:44, Lawrence Stewart wrote: >>> On 11/07/10 17:32, Lawrence Stewart wrote: >>>> On 11/03/10 09:30, Andre Oppermann wrote: >>>>> On 02.11.2010 01:11, Maxim Dounin wrote: >>>>>> Hello! >>>>>> >>>>>> On Mon, Sep 27, 2010 at 03:17:59PM +0200, Andre Oppermann wrote: >>>>>> >>>>>>> On 27.09.2010 10:12, Maxim Dounin wrote: >>>>>>>> Hello! >>>>>>>> >>>>>>>> On Mon, Sep 13, 2010 at 09:24:53PM +0400, Maxim Dounin wrote: >>>>>>>> >>>>>>>> [...] >>>>>>>> >>>>>>>>> Andre, could you please take a look at one more patch as well? >>>>>>>>> >>>>>>>>> Igor reported that it still sees 100ms delays with rfc3465 turned >>>>>>>>> on, and it turns out to be similar issue (setting cwnd to 1*MSS) >>>>>>>>> for hosts found in hostcache. >>>>>>>>> >>>>>>>>> The problem with setting cwnd from hostcache was already reported >>>>>>>>> here: >>>>>>>>> >>>>>>>>> http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/92690 >>>>>>>>> http://lists.freebsd.org/pipermail/freebsd-net/2007-July/014780.html >>>>>>>>> >>>>>>>>> As using larger cwnd from hostcache may cause problems on >>>>>>>>> congested links (see second thread) I changed code to only use >>>>>>>>> cached cwnd as an upper bound for cwnd (instead of fixing current >>>>>>>>> code). This is also in-line with what we do on connection >>>>>>>>> restarts. >>>>>>>>> >>>>>>>>> We may later consider re-adding usage of larger cwnd from >>>>>>>>> hostcache. But I believe it should be done carefully and >>>>>>>>> probably behind sysctl, off by default. >>>>>>>> >>>>>>>> Ping. >>>>>>> >>>>>>> Thanks for the reminder. I'll disable priming CWND from hostcache. >>>>>> >>>>>> Ping again. >>>>>> >>>>>> I would like to see the patch in question[1] committed and MFC'ed >>>>>> somewhere before 8.2. >>>>>> >>>>>> Andre, if you are just too busy to do it yourself - please say so, >>>>>> I'll ask somebody else to commit it. >>>>> >>>>> Thanks for the reminder. After EuroBSDCon Developer Summit I was >>>>> busy with other work and most of my tcp work was stalled due to >>>>> review bandwidth issues. >>>> >>>> Sorry for the review bandwidth issues. I'm only just managing to keep my >>>> head above water at the moment and have had to reduce much of my FreeBSD >>>> work to a trickle. >>>> >>>>> Lawrence, could you please spare a few seconds and take a quick look >>>>> at the attached patch? >>>> >>>> The patch looks fine, please commit. I hope to give the hostcache some >>>> TLC at some point, but in the meantime it's fine to ignore cached cwnd. >>> >>> FYI Andre, this patch got rolled into r215166 because I had to move all >>> the code around which the patch was based on. Is that going to cause any >>> issues here? I should have checked prior to committing but completely >>> forgot I had pulled the patch into my dev tree before creating the mod >>> CC patch. >> >> Gah, I think I've answered my own question. MFCing the patch standalone >> in time for 8.2 as Maxim requested is not going to be possible. I think >> I'll have to back out r215166, commit your patch and then recommit the >> modular CC patch. >> >> Unless someone can think of a way that doesn't involve all the mucking >> about? > Well, if the change is indeed already in HEAD, you can do a direct commit > to stable/8 after proper MFC period, noting that this is a cherry-pick of > the part of corresponding revision. hmm, not ideal but would get the job done. When I eventually MFC the modular CC patch everything will be back in sync mergeinfo wise as well. Would anyone object if I follow Kostik's suggestion and direct commit the TCP_METRICS_CWND patch to stable/8 in, say, a week's time? If I don't hear anything, I'll aim to do the commit next weekend. Cheers, Lawrence From owner-freebsd-net@FreeBSD.ORG Fri Nov 12 13:32:13 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DCCF2106566C for ; Fri, 12 Nov 2010 13:32:13 +0000 (UTC) (envelope-from gumbo@bsdmail.org) Received: from imr-db02.mx.aol.com (imr-db02.mx.aol.com [205.188.91.96]) by mx1.freebsd.org (Postfix) with ESMTP id 94A6D8FC0A for ; Fri, 12 Nov 2010 13:32:13 +0000 (UTC) Received: from imo-da02.mx.aol.com (imo-da02.mx.aol.com [205.188.169.200]) by imr-db02.mx.aol.com (8.14.1/8.14.1) with ESMTP id oACDWAqZ010204 for ; Fri, 12 Nov 2010 08:32:10 -0500 Received: from gumbo@bsdmail.org by imo-da02.mx.aol.com (mail_out_v42.9.) id n.cc3.5429d013 (37529) for ; Fri, 12 Nov 2010 08:32:06 -0500 (EST) Received: from smtprly-me02.mx.aol.com (smtprly-me02.mx.aol.com [64.12.95.103]) by cia-mb01.mx.aol.com (v129.5) with ESMTP id MAILCIAMB012-b2cf4cdd41d31ea; Fri, 12 Nov 2010 08:32:05 -0500 Received: from web-mmc-d04 (web-mmc-d04.sim.aol.com [205.188.103.94]) by smtprly-me02.mx.aol.com (v129.4) with ESMTP id MAILSMTPRLYME026-b2cf4cdd41d31ea; Fri, 12 Nov 2010 08:32:03 -0500 References: <8CD4F3FB222E6E1-1F14-11DA0@web-mmc-d04.sysops.aol.com> <4CDB8DD1.4010808@FreeBSD.org> To: freebsd-net@freebsd.org Date: Fri, 12 Nov 2010 08:32:03 -0500 X-AOL-IP: 67.180.99.85 In-Reply-To: <4CDB8DD1.4010808@FreeBSD.org> X-MB-Message-Source: WebUI MIME-Version: 1.0 From: gumbo@bsdmail.org X-MB-Message-Type: User X-Mailer: Mail.com Webmail 32843-STANDARD Received: from 67.180.99.85 by web-mmc-d04.sysops.aol.com (205.188.103.94) with HTTP (WebMailUI); Fri, 12 Nov 2010 08:32:03 -0500 Message-Id: <8CD508520915099-1F14-1E0C0@web-mmc-d04.sysops.aol.com> X-Spam-Flag: NO X-AOL-SENDER: gumbo@bsdmail.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: ipfw fwd doesn't handle ipv6 addresses X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Nov 2010 13:32:13 -0000 The problem is the "fwd" can't handle "nextaddr" if "nextaddr" resolves to= an ipv6 address. It works fine if it resolves to an ipv4 address. Any other ideas ? Thanks, Rick -----Original Message----- From: Doug Barton To: freebsd-net@freebsd.org Sent: Wed, Nov 10, 2010 10:31 pm Subject: Re: ipfw fwd doesn't handle ipv6 addresses On 11/10/2010 14:42, gumbo@bsdmail.org wrote:=20 =20 > I'm running freebsd 7.2 and trying to find a way to forward a packet=20 > based on it's source address. The following command works fine for=20 > ipv4 addresses but fails for ipv6 addresses. ipfw add 101 fwd=20 > nextaddr ip from myaddr to any out This works fine if nextaddr and=20 > myaddr are ipv4 but fails to work if they are ipv6. Is this not yet=20 > supported or is there another way to accomplish the same thing ?=20 =20 You might want to take a look at the ipfw man page, I think what you want= is me6, not myaddr.=20 =20 Doug=20 =20 -- =20 Nothin' ever doesn't change, but nothin' changes much.=20 -- OK Go=20 =20 Breadth of IT experience, and depth of knowledge in the DNS.=20 Yours for the right price. :) http://SupersetSolutions.com/=20 =20 _______________________________________________=20 freebsd-net@freebsd.org mailing list=20 http://lists.freebsd.org/mailman/listinfo/freebsd-net=20 To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"=20 From owner-freebsd-net@FreeBSD.ORG Fri Nov 12 13:39:26 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AB01B106566B for ; Fri, 12 Nov 2010 13:39:26 +0000 (UTC) (envelope-from pieter@os3.nl) Received: from mail.thelostparadise.com (router.thelostparadise.com [IPv6:2a02:898:0:30::30:1]) by mx1.freebsd.org (Postfix) with ESMTP id 3D1748FC0C for ; Fri, 12 Nov 2010 13:39:26 +0000 (UTC) Received: by mail.thelostparadise.com (Postfix, from userid 127) id B090F7303C; Fri, 12 Nov 2010 14:39:24 +0100 (CET) Received: from localhost by mail.thelostparadise.com (Postfix) with ESMTP id 024D673038; Fri, 12 Nov 2010 14:39:21 +0100 (CET) Message-ID: <4CDD4389.5060405@os3.nl> Date: Fri, 12 Nov 2010 14:39:21 +0100 From: Pieter de Boer MIME-Version: 1.0 To: Christopher Penney References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00,RDNS_NONE, T_FRT_CONTACT autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on aberdeen.thelostparadise.com Cc: freebsd-net@freebsd.org Subject: Re: FreeBSD TCP Behavior with Linux NAT X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Nov 2010 13:39:26 -0000 Hi Christopher, > Before the reboot two Linux clients were mounting the FreeBSD server. They > were both using port 903 locally. On the head node clientA:903 was remapped > to headnode:903 and clientB:903 was remapped to headnode:601. There is no > activity when the reboot occurs. The head node takes a few minutes to come > back up (we kept it down for several minutes). > > When it comes back up clientA and clientB try to reconnect to the FreeBSD > NFS server. They both use the same source port, but since the head node's > conntrack table is cleared it's a race to see who gets what port and this > time clientA:903 appears as headnode:601 and clientB:903 appears as > headnode:903 (>>> they essentially switch places as far as the FreeBSD > server would see<<< ). So what you are saying is that the Linux NAT box reuses the same source_ip:source_port / destination_ip:destination_port tuple for a new connection to the FreeBSD NFS server after the Linux box has rebooted. This quickly enough that the connection on the FreeBSD NFS server has not timed out yet? Isn't there a rule in TCP you shouldn't be reusing port numbers within the MSL (or 2*MSL?) period? -- Pieter From owner-freebsd-net@FreeBSD.ORG Fri Nov 12 21:14:31 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A4304106564A; Fri, 12 Nov 2010 21:14:31 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 7932C8FC14; Fri, 12 Nov 2010 21:14:31 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id oACLEViO014166; Fri, 12 Nov 2010 21:14:31 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id oACLEVpH014162; Fri, 12 Nov 2010 21:14:31 GMT (envelope-from linimon) Date: Fri, 12 Nov 2010 21:14:31 GMT Message-Id: <201011122114.oACLEVpH014162@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/152148: [pfil] vnet_pfil_init() happens too late if pfil_head_register() is called from if_ethersubr.c X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Nov 2010 21:14:31 -0000 Old Synopsis: vnet_pfil_init() happens too late if pfil_head_register() is called from if_ethersubr.c New Synopsis: [pfil] vnet_pfil_init() happens too late if pfil_head_register() is called from if_ethersubr.c Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Fri Nov 12 21:13:58 UTC 2010 Responsible-Changed-Why: reclassify. http://www.freebsd.org/cgi/query-pr.cgi?pr=152148 From owner-freebsd-net@FreeBSD.ORG Fri Nov 12 21:18:31 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 84CC2106564A; Fri, 12 Nov 2010 21:18:31 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 5A1398FC08; Fri, 12 Nov 2010 21:18:31 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id oACLIV9g014476; Fri, 12 Nov 2010 21:18:31 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id oACLIVAp014472; Fri, 12 Nov 2010 21:18:31 GMT (envelope-from linimon) Date: Fri, 12 Nov 2010 21:18:31 GMT Message-Id: <201011122118.oACLIVAp014472@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/151908: [patch] nd6_ns_input: panic may happen, for RTFREE_LOCKED set rt to 0. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Nov 2010 21:18:31 -0000 Old Synopsis: nd6_ns_input:panic may happen, for RTFREE_LOCKED set rt to 0. New Synopsis: [patch] nd6_ns_input: panic may happen, for RTFREE_LOCKED set rt to 0. Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Fri Nov 12 21:16:04 UTC 2010 Responsible-Changed-Why: Patch against networking code. http://www.freebsd.org/cgi/query-pr.cgi?pr=151908 From owner-freebsd-net@FreeBSD.ORG Fri Nov 12 21:18:58 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 154E31065694 for ; Fri, 12 Nov 2010 21:18:58 +0000 (UTC) (envelope-from gabor.radnai@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9985C8FC15 for ; Fri, 12 Nov 2010 21:18:56 +0000 (UTC) Received: by fxm19 with SMTP id 19so2638388fxm.13 for ; Fri, 12 Nov 2010 13:18:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=jkI8ji/N1TiDEim/SKi4+MV1PBgGTweoZdX/jOg3df4=; b=CyKBYnIUgE5p8Aq2ZvornP+NuuwTHm0q/PPMtBgA5MgH3qluCrE3/A3r9ibSnmnWO1 gDcmv/LXXAo4r6h8bxjQGkv0kS1QmJbmno0BeYT3r9bkWC8zdA5rYKCSewx7wdw3tYf7 zmh9kBQegIhyc31zP24LN9bqsP2yYY6WusM58= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=HDIuOXtaa0RmVtoOwZ6mTgDnFdzT6NgeCZxrAUjlB4+9clVZ++Jgh9WqPzFz3ypIch vcdzuFQcbz/OnRZj686sFkqubDlumlXfU9NrQgDPUexjF1ZgEB8gu8ao17Rx2jSS79vI N+kW7yWWLccXT0ctKBVjVy+n1f/fSTrnbcNR0= Received: by 10.223.100.15 with SMTP id w15mr2039676fan.121.1289596735210; Fri, 12 Nov 2010 13:18:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.93.138 with HTTP; Fri, 12 Nov 2010 13:18:40 -0800 (PST) In-Reply-To: <20101111212648.GF17566@michelle.cdnetworks.com> References: <20101111212648.GF17566@michelle.cdnetworks.com> From: Gabor Radnai Date: Fri, 12 Nov 2010 22:18:40 +0100 Message-ID: To: pyunyh@gmail.com Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: Problem with re0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Nov 2010 21:18:58 -0000 Hi, I hope you are interested in inet section it looks like this (will able to send the exact output only a bit later unfortunately as removed the card) : inet 0.0.0.0 netmask 255.255.255.255 Thanks, Gabor On Thu, Nov 11, 2010 at 10:26 PM, Pyun YongHyeon wrote: > On Thu, Nov 11, 2010 at 09:56:26PM +0100, Gabor Radnai wrote: > > Hi, > > > > I have an Asus M2NPV-VM motherboard with integrated Nvidia MCP51 Gigabit > > Ethernet NIC and > > TP-Link TG-3468 PCIe network card which is using Realtek 8111 chip. > > > > I have problem with the re driver: the Nvidia network interface is > working > > properly but the other > > though it seems recognized by OS I cannot use. Sporadically it remains > down > > and if it gets up then > > does not get ip address via DHCP nor help if I set static ip address. Can > > manipulate via ifconfig but > > unreachable via IP. > > > > I replaced cable, interchanged cable working with Nvidia, restarted > > switch/router but no luck so far. > > Also using this nic in a Windows machine - it works. Using my Asus mob > with > > Ubuntu Live CD - card works. > > > > Can it be a driver bug or this type of chip is not supported by re > driver? > > > > Eh, you already know the answer, recognized by re(4) but does not > work so it's a bug of re(4). Would you show me the output of > ifconfig re0 after UP the interface(i.e. ifconfig re0 up). > From owner-freebsd-net@FreeBSD.ORG Fri Nov 12 21:32:36 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A5925106566B; Fri, 12 Nov 2010 21:32:36 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 7B0C38FC1C; Fri, 12 Nov 2010 21:32:36 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id oACLWaXY034854; Fri, 12 Nov 2010 21:32:36 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id oACLWan7034850; Fri, 12 Nov 2010 21:32:36 GMT (envelope-from linimon) Date: Fri, 12 Nov 2010 21:32:36 GMT Message-Id: <201011122132.oACLWan7034850@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/152141: [vlan] encapsulate vlan in ng_ether before output to if X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Nov 2010 21:32:36 -0000 Old Synopsis: encapsulate vlan in ng_ether before output to if New Synopsis: [vlan] encapsulate vlan in ng_ether before output to if Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Fri Nov 12 21:31:41 UTC 2010 Responsible-Changed-Why: Affects networking code. To submitter: is the code you included a patch, or a test case? It is not clear to me. http://www.freebsd.org/cgi/query-pr.cgi?pr=152141 From owner-freebsd-net@FreeBSD.ORG Fri Nov 12 21:56:23 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E0D66106566C for ; Fri, 12 Nov 2010 21:56:23 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [IPv6:2001:470:a803::1]) by mx1.freebsd.org (Postfix) with ESMTP id 8A6FC8FC0A for ; Fri, 12 Nov 2010 21:56:23 +0000 (UTC) Received: from mail.geekcn.org (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id 9BA71A67DDF; Sat, 13 Nov 2010 05:56:22 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by mail.geekcn.org (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with LMTP id OvJ3WXrFM4z5; Sat, 13 Nov 2010 05:56:15 +0800 (CST) Received: from delta.delphij.net (drawbridge.ixsystems.com [206.40.55.65]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id 1143BA67DD5; Sat, 13 Nov 2010 05:56:11 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:subject:x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=VtOGycm+qHID9dQdUnTlc2R/ynuDHyJ/v9wvYgCnG91gnYCKO5yD+eqAb2XRMx+jH 5enZE0nQU04PcB+Izo0bA== Message-ID: <4CDDB7F8.4050005@delphij.net> Date: Fri, 12 Nov 2010 13:56:08 -0800 From: Xin LI Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.15) Gecko/20101028 Thunderbird/3.0.10 ThunderBrowse/3.3.2 MIME-Version: 1.0 To: "freebsd-net@freebsd.org" X-Enigmail-Version: 1.0.1 OpenPGP: id=3FCA37C1; url=http://www.delphij.net/delphij.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: named: client (a broadcast address)#(port): error sending response: permission denied X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Nov 2010 21:56:24 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, Since I have seen this issue resolved nowhere within Google results, I would like to post it here for future reference - its cause, how to work around it. Thanks for rwatson@ for his expertise. This is what I have seen on my own system: Nov 11 19:13:02 tarsier named[21464]: client 211.166.10.255#38500: error sending response: permission denied Which happens very frequently. ====== The cause: Some other system on the same subnet produced a DNS query, claiming it from the IP broadcast address (either full 1's or full 0's from the same subnet), and unicast to the system running a DNS service. named(8), in turn, attempts to respond the DNS query. When sending out the response packet, the destination IP address would be that IP broadcast address. The FreeBSD implementation (also other TCP/IP stacks I am aware of) does not permit this unless the socket have SO_BROADCAST, according to sendmsg(2) manual page. This EACCES would result in the messsage "error sending response: permission denied". Basically our TCP/IP stack is doing the right thing. ====== The workaround is to filter out the traffic from the offending host. I am not yet aware of which operating system did that. Another workaround is to patch named (contrib/bind9/bin/named/client.c) around the log and disable the whole log thing. ====== The fix is to either fix the offending host or remove it. Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iQEcBAEBCAAGBQJM3bf4AAoJEATO+BI/yjfBc1AH/R/jt6/wS0Doy6o4cZairo3q zeYlQspPSNfBMI65OKl9F08iEI9kVSvfokgQg/eyriqtLre/upu2TnKyx+y/zDxX 4RD17i4lYqAnYP6Hp4z++yk8gKU10FZe0rlPjGZ14UV2WKgqPuAYXR5qIAFlB3Hz I/7okVNY6TahkgcCfZQ1mCtQPbXtHHsmM37HEkPPz7GbFNYNYTxp7Zb9tEhyE5Ye 4b/ocJuBSN12FY9GTsgeyGWMp2ZO6JhEUgwuThVYB6CU9oi56pIpVOFIgI0IW0Q6 UQh6N4VjcoRF9Z12uwqXgS84gPPAIbNZ8Pa3z5FkVpXoJOxT4rP9INU/mA5Ay+Q= =sgKB -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Fri Nov 12 22:48:08 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4CB7D1065814 for ; Fri, 12 Nov 2010 22:48:08 +0000 (UTC) (envelope-from cowens@greatbaysoftware.com) Received: from portcityhosting.com (edge.tidalhosting.net [64.140.243.92]) by mx1.freebsd.org (Postfix) with ESMTP id C51548FC18 for ; Fri, 12 Nov 2010 22:48:07 +0000 (UTC) Received: from jack.bspruce.com ([173.14.128.81]) by portcityhosting.com with MailEnable ESMTP; Fri, 12 Nov 2010 17:08:09 -0500 X-WatchGuard-Mail-Exception: Allow Message-ID: <4CDDBAC6.6080500@greatbaysoftware.com> Date: Fri, 12 Nov 2010 17:08:06 -0500 From: Charles Owens MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-WatchGuard-AntiVirus: part scanned. clean action=allow X-ME-Bayesian: 0.000000 Subject: em(4): 4-port Intel Pro/1000 PF card not detected X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Nov 2010 22:48:08 -0000 Hello, We're trying to work with newly purcharsed Intel EXPi9404PF NICs ("Intel PRO/1000 PF Quad Port Server Adapter") but they do not seem to be detected (no ports showing with 'ifconfig -l'). We're having no problems with the 2-port version of the same card -- is there a known issue with the 4-port version? We've tried three different cards of this model, all with same result. Thanks in advance for any help. Charles -- Charles Owens Great Bay Software, Inc. From owner-freebsd-net@FreeBSD.ORG Fri Nov 12 22:54:17 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 46E5F106566B for ; Fri, 12 Nov 2010 22:54:17 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id ED8568FC17 for ; Fri, 12 Nov 2010 22:54:16 +0000 (UTC) Received: by yxe1 with SMTP id 1so189572yxe.13 for ; Fri, 12 Nov 2010 14:54:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=XTYOWpE8REa0TCdRklQVVSD/GnnTZqW6SeHZyF3Ys2s=; b=Y/g3JTgXjVgFtYXkZpr/slW2BPdrkvjFG4XrE+Kpss8xOFDKdPdaPkyBMIFgIcuhNh 1JTPg15BgQC7IbHrlEHHI6qdB4fjPTPeuddUKCGIDmKsWDmo8hdHzncIVIHVy/LZSMrq 1K/OwmBHdRZM7RWFQhbwfjwLJfHpcoib7QpG4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=g5yv0v9YOgNJoao+sn21AkZQD/rKE5MVSbepv4JhzW9rpyW8MQcvUDY/1h9DRFbxp4 2ERSmvYfSBvR3owBpLK5qNO2esNhqn+LIYfGb7MINsnqL5FpG6KuQunOk2Q3c2YwWLjF tVHkSkx3BYqICxVc6QSflLnHs7nPqAaP5Tk9o= Received: by 10.150.58.1 with SMTP id g1mr4786939yba.149.1289602455857; Fri, 12 Nov 2010 14:54:15 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id q5sm1068780ybe.18.2010.11.12.14.54.13 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 12 Nov 2010 14:54:14 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Fri, 12 Nov 2010 14:53:20 -0800 From: Pyun YongHyeon Date: Fri, 12 Nov 2010 14:53:20 -0800 To: Gabor Radnai Message-ID: <20101112225320.GC22460@michelle.cdnetworks.com> References: <20101111212648.GF17566@michelle.cdnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: Problem with re0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Nov 2010 22:54:17 -0000 On Fri, Nov 12, 2010 at 10:18:40PM +0100, Gabor Radnai wrote: > Hi, > > I hope you are interested in inet section it looks like this (will able to > send the exact output only a bit later unfortunately as removed the card) : > inet 0.0.0.0 netmask 255.255.255.255 > This might be caused by dhclient(i.e. dhclient(8) failed to receive DHCP ACK). BTW, you still didn't show me the output of ifconfig re0 after UP the interface(i.e. ifconfig re0 up). > Thanks, > Gabor > > On Thu, Nov 11, 2010 at 10:26 PM, Pyun YongHyeon wrote: > > > On Thu, Nov 11, 2010 at 09:56:26PM +0100, Gabor Radnai wrote: > > > Hi, > > > > > > I have an Asus M2NPV-VM motherboard with integrated Nvidia MCP51 Gigabit > > > Ethernet NIC and > > > TP-Link TG-3468 PCIe network card which is using Realtek 8111 chip. > > > > > > I have problem with the re driver: the Nvidia network interface is > > working > > > properly but the other > > > though it seems recognized by OS I cannot use. Sporadically it remains > > down > > > and if it gets up then > > > does not get ip address via DHCP nor help if I set static ip address. Can > > > manipulate via ifconfig but > > > unreachable via IP. > > > > > > I replaced cable, interchanged cable working with Nvidia, restarted > > > switch/router but no luck so far. > > > Also using this nic in a Windows machine - it works. Using my Asus mob > > with > > > Ubuntu Live CD - card works. > > > > > > Can it be a driver bug or this type of chip is not supported by re > > driver? > > > > > > > Eh, you already know the answer, recognized by re(4) but does not > > work so it's a bug of re(4). Would you show me the output of > > ifconfig re0 after UP the interface(i.e. ifconfig re0 up). > > From owner-freebsd-net@FreeBSD.ORG Fri Nov 12 23:00:57 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ECE9F1065694 for ; Fri, 12 Nov 2010 23:00:56 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id A0EEE8FC14 for ; Fri, 12 Nov 2010 23:00:56 +0000 (UTC) Received: by gyg13 with SMTP id 13so1032561gyg.13 for ; Fri, 12 Nov 2010 15:00:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=zJp3MEH1dkbg/Wbca+bFpisin4tRBuRkOCMU3yeLPKE=; b=x9aOypfcp1v8b2clGhrI0tEmyDPpSkWFw2Lif5IFWWkt7OQE51r0VbJOJkSU2h7RYK hjcq3GuDWOFqXjJZsL8MW4UrjS2EV2mOIVsy5um9Y7OeTn0KswG+BC35CpeE1SAibPhd YSeWbc8bHWxA2ASaKDVI1LuKPYVzbVOrgNYBQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=vLeYRgocwxnET4nY7cuqdbLlW7YmIMBHZHFyVlYYpju0xs6kwg60ywkY3ZnVXRsQMd hE7TzduU4MXKWnnrDuMOJAoIprbgrqHsZczmf3yDboRkrRC1tJfdqhNg65O/MGBTNld/ uqVCwqcIFAvKV6+gWXFV4x3IZYY2/glpMZy8M= Received: by 10.150.200.7 with SMTP id x7mr4761072ybf.153.1289602855894; Fri, 12 Nov 2010 15:00:55 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id q41sm1220347ybk.1.2010.11.12.15.00.53 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 12 Nov 2010 15:00:54 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Fri, 12 Nov 2010 15:00:00 -0800 From: Pyun YongHyeon Date: Fri, 12 Nov 2010 15:00:00 -0800 To: Zeus V Panchenko Message-ID: <20101112230000.GD22460@michelle.cdnetworks.com> References: <20101112070759.GA36248@relay.ibs.dn.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101112070759.GA36248@relay.ibs.dn.ua> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: Problem with re0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Nov 2010 23:00:57 -0000 On Fri, Nov 12, 2010 at 09:07:59AM +0200, Zeus V Panchenko wrote: > Hi, > > Gabor Radnai (gabor.radnai@gmail.com) [10.11.11 23:22] wrote: > > pciconf: > > nfe0@pci0:0:20:0: class=0x068000 card=0x816a1043 chip=0x026910de rev=0xa3 > > hdr=0x00 > > vendor = 'NVIDIA Corporation' > > device = 'MCP51 Network Bus Enumerator' > > class = bridge > > re0@pci0:1:0:0: class=0x020000 card=0x816810ec chip=0x816810ec rev=0x01 > > hdr=0x00 > > vendor = 'Realtek Semiconductor' > > device = 'Gigabit Ethernet NIC(NDIS 6.0) (RTL8168/8111/8111c)' > > class = network > > subclass = ethernet > > > > i have the same problem (i was writing here before, but still no idea) > with onboard (Realtek Gigabit Ethernet NIC(NDIS 6.0) > (RTL8168/8111/8111c)) nic while the same driver but another vendor > (D-Link DGE-528T Gigabit adaptor (dlg10086)) nic works fine ... > > the flapping of the realtek interface is so much drastic, that i was > forced to unplug the cable even on the ip less nic > Please be more specific for the issue. Your description is hard to narrow down possible cause. > i was sure it is the problem of the onboard rt nics ... > pciconf output of all re(4) controllers are useless because the vendor uses the same device id. Please show me the output of dmesg which will contain necessary information to identify your controller revision. > uname: > FreeBSD 8.1-STABLE #3 amd64 > > pciconf -lv: > re0@pci0:2:0:0: class=0x020000 card=0x83a31043 chip=0x816810ec rev=0x03 hdr=0x00 > vendor = 'Realtek Semiconductor' > device = 'Gigabit Ethernet NIC(NDIS 6.0) (RTL8168/8111/8111c)' > class = network > subclass = ethernet > re1@pci0:1:0:0: class=0x020000 card=0x43001186 chip=0x43001186 rev=0x10 hdr=0x00 > vendor = 'D-Link System Inc' > device = 'Used on DGE-528T Gigabit adaptor (dlg10086)' > class = network > subclass = ethernet > > dmidecode: > Handle 0x0002, DMI type 2, 15 bytes > Base Board Information > Manufacturer: ASUSTeK Computer INC. > Product Name: AT5NM10-I > Version: Rev x.0x > Serial Number: MT7006K15200628 > Asset Tag: To Be Filled By O.E.M. > Features: > Board is a hosting board > Board is replaceable > Location In Chassis: To Be Filled By O.E.M. > Chassis Handle: 0x0003 > Type: Motherboard > Contained Object Handles: 0 > > Handle 0x0012, DMI type 8, 9 bytes > Port Connector Information > Internal Reference Designator: LAN > Internal Connector Type: None > External Reference Designator: LAN > External Connector Type: RJ-45 > Port Type: Network Port > > -- > Zeus V. Panchenko > IT Dpt., IBS ltd GMT+2 (EET) > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Sat Nov 13 02:16:03 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E6FD1106564A for ; Sat, 13 Nov 2010 02:16:03 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id B2FC58FC15 for ; Sat, 13 Nov 2010 02:16:03 +0000 (UTC) Received: by pxi1 with SMTP id 1so753084pxi.13 for ; Fri, 12 Nov 2010 18:16:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=0qy3Qp6HA/wDhzNkFGOt/kmvhqWV/cNHrv3CKgdoAGc=; b=xeM23yL8Ashxo7rqOsrNYpRzgWnVc3b9uUDto2DIYznkvNSfBN9MYnUy1vJNhfjOOR WxxbmPXrkd5LDUgrT5P30vXp11jeq13b7ORoO8LqWDfa/r9zHyKwU+Conr34djuHrWj3 CUKnCwF6EyQPWpVsc9eCsRXD0OLjzgbKdkqOc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=ZVuwe7QEHLkXUuSF6EsuckWqw2xMRMDwoD6KcgT0gGkTiIopoa72ZbDB9nUp+dKfVT t9hI+Ht5CqkKgdpIKm2mNwNG06GZkNjsRPxrArIWz5Z20lQpVt7OCAr0s/G6v9vsfptK 7GG4AKWYqcR6RE0D4Z1NgQBBFFRRURS+2FyPU= Received: by 10.142.102.2 with SMTP id z2mr2654517wfb.105.1289614563065; Fri, 12 Nov 2010 18:16:03 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id p8sm4685648wff.4.2010.11.12.18.16.00 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 12 Nov 2010 18:16:00 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Fri, 12 Nov 2010 18:15:07 -0800 From: Pyun YongHyeon Date: Fri, 12 Nov 2010 18:15:07 -0800 To: "rene@reckschwardt.de" Message-ID: <20101113021507.GG22460@michelle.cdnetworks.com> References: <20101111193534.A7D838090AAD@rds11224.i4e-server.de> <20101111213156.GG17566@michelle.cdnetworks.com> <20101111225340.C2835B470D68@rds11224.i4e-server.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101111225340.C2835B470D68@rds11224.i4e-server.de> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: ML370 G4 with poor Network Performance and high CPU Load X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Nov 2010 02:16:04 -0000 On Thu, Nov 11, 2010 at 10:53:38PM +0000, rene@reckschwardt.de wrote: > here is the pciconf for the onboard Nic > You still didn't post dmesg output. Because there were a lot of bge(4) changes since 8.1-RELEASE, I think it would be better to try CURRENT or latest snapshot release and check whether you still see the same issue. > bge0@pci0:7:3:0: class=0x020000 card=0x00cb0e11 chip=0x16c714e4 > rev=0x10 hdr=0x00 > vendor = 'Broadcom Corporation' > device = 'BCM5703A3 NetXtreme Gigabit Ethernet' > class = network > subclass = ethernet > bar [10] = type Memory, range 64, base 0xfdef0000, size 65536, > enabled > cap 07[40] = PCI-X 64-bit supports 133MHz, 2048 burst read, 1 split > transaction > cap 01[48] = powerspec 2 supports D0 D3 current D0 > cap 03[50] = VPD > cap 05[58] = MSI supports 8 messages, 64 bit > > regards r? > From owner-freebsd-net@FreeBSD.ORG Sat Nov 13 07:09:21 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A1388106566B for ; Sat, 13 Nov 2010 07:09:21 +0000 (UTC) (envelope-from zeus@relay.ibs.dn.ua) Received: from relay.ibs.dn.ua (relay.ibs.dn.ua [91.216.196.25]) by mx1.freebsd.org (Postfix) with ESMTP id 1AB208FC08 for ; Sat, 13 Nov 2010 07:09:20 +0000 (UTC) Received: from relay.ibs.dn.ua (localhost [127.0.0.1]) by relay.ibs.dn.ua with ESMTP id oAD79Ik9061291; Sat, 13 Nov 2010 09:09:18 +0200 (EET) Received: (from zeus@localhost) by relay.ibs.dn.ua (8.14.4/8.14.4/Submit) id oAD79Iwr061290; Sat, 13 Nov 2010 09:09:18 +0200 (EET) Date: Sat, 13 Nov 2010 09:09:18 +0200 From: Zeus V Panchenko To: Pyun YongHyeon Message-ID: <20101113070918.GB15278@relay.ibs.dn.ua> References: <20101112070759.GA36248@relay.ibs.dn.ua> <20101112230000.GD22460@michelle.cdnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20101112230000.GD22460@michelle.cdnetworks.com> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 8.1-RELEASE X-Editor: GNU Emacs 23.2.1 Cc: freebsd-net@freebsd.org Subject: Re: Problem with re0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: zeus@ibs.dn.ua List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Nov 2010 07:09:21 -0000 Pyun YongHyeon (pyunyh@gmail.com) [10.11.13 01:01] wrote: > > Please be more specific for the issue. Your description is hard to > narrow down possible cause. > > > i was sure it is the problem of the onboard rt nics ... > > > > pciconf output of all re(4) controllers are useless because the > vendor uses the same device id. Please show me the output of dmesg > which will contain necessary information to identify your > controller revision. > oh, sorry :( here is what you say: the integrated onboard nic: re0: port 0xe800-0xe8ff mem 0xfafff000-0xfaffffff,0xfaff8000-0xfaffbfff irq 17 at device 0.0 on pci2 re0: Using 1 MSI messages re0: Chip rev. 0x28000000 re0: MAC rev. 0x00000000 miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto re0: Ethernet address: 48:5b:39:d2:1d:89 re0: [FILTER] external PCI nic: re1: port 0xd800-0xd8ff mem 0xfbeffc00-0xfbeffcff irq 17 at device 0.0 on pci1 re1: Chip rev. 0x10000000 re1: MAC rev. 0x00000000 miibus1: on re1 rgephy1: PHY 1 on miibus1 rgephy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto re1: Ethernet address: 00:21:91:f4:5f:e4 re1: [FILTER] all that data i was posting here before (several months ago) and nothing changed since that time due to production state of the boxes i was forced finally to switch to external nics and to configure it with vlans and even to unplug the cable of the onboard nic since nic with plugged cable but without assigned ip address did begin flap (may be it's specific of the swith it plugged in, it is TP-Link TL-SG5426 but no other nic behaves this way) i have 7 boxes of this configuration and all 6 are running now on external nics if i can provide any debug/info/e.t.c. please let me know, i'd be happy it'd work at last :) -- Zeus V. Panchenko IT Dpt., IBS ltd GMT+2 (EET) From owner-freebsd-net@FreeBSD.ORG Sat Nov 13 07:24:36 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5E652106566B for ; Sat, 13 Nov 2010 07:24:36 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id E43C08FC17 for ; Sat, 13 Nov 2010 07:24:35 +0000 (UTC) Received: by wwj40 with SMTP id 40so747628wwj.31 for ; Fri, 12 Nov 2010 23:24:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=jflKJ07xaX62vNDxk3XkqG+OUkUGuAiInmqNOO5+BWo=; b=LuSpzI2Na84YIOYJqisd9Tmae1/Dr2pKHK/LYkQDNKwAdgj6YPiCzqVF59dWgrqtZf dGVOPB6iDTI0ErTJm59OBpAAE//L00hK/3A1IiUSBR86xsUKQ+Pz1N5GXWiXFma3G9N4 hPjfJpqf5FuV/XgsgwAYLtWVOFLtj4b7vtitk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=gmJ1/7gplJQs0nhEFWys6jx1g4CdjuwG6Nka8HOWle4DNV33l7CSkuHzY9ROS1mwyl BEYGnyuTslb4NJjWcfp9sLstGsjtJFecpYpqIjTMa+40StBS2Nv+IRSdlJZAZ9+M1nM6 es9PE7JLWq+t7cWUd8F+sWl9aizVQRjQIji2s= MIME-Version: 1.0 Received: by 10.216.29.197 with SMTP id i47mr2910641wea.27.1289633074391; Fri, 12 Nov 2010 23:24:34 -0800 (PST) Received: by 10.216.2.206 with HTTP; Fri, 12 Nov 2010 23:24:34 -0800 (PST) In-Reply-To: <4CDDBAC6.6080500@greatbaysoftware.com> References: <4CDDBAC6.6080500@greatbaysoftware.com> Date: Fri, 12 Nov 2010 23:24:34 -0800 Message-ID: From: Jack Vogel To: Charles Owens Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: em(4): 4-port Intel Pro/1000 PF card not detected X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Nov 2010 07:24:36 -0000 pciconf -l please, I'll betcha these are the new quad ports that are in my next igb driver update, it would have gone in already but I've been fighting a bug in the header split code. Show me what the output looks like, and I'll get ya fixed up, dont worry :) Jack On Fri, Nov 12, 2010 at 2:08 PM, Charles Owens wrote: > Hello, > > We're trying to work with newly purcharsed Intel EXPi9404PF NICs ("Intel > PRO/1000 PF Quad Port Server Adapter") but they do not seem to be detected > (no ports showing with 'ifconfig -l'). We're having no problems with the > 2-port version of the same card -- is there a known issue with the 4-port > version? > > We've tried three different cards of this model, all with same result. > Thanks in advance for any help. > > Charles > > -- > Charles Owens > Great Bay Software, Inc. > > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Sat Nov 13 08:43:18 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 06D781065670; Sat, 13 Nov 2010 08:43:18 +0000 (UTC) (envelope-from brucec@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id D03F98FC13; Sat, 13 Nov 2010 08:43:17 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id oAD8hHhq059329; Sat, 13 Nov 2010 08:43:17 GMT (envelope-from brucec@freefall.freebsd.org) Received: (from brucec@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id oAD8hHdA059325; Sat, 13 Nov 2010 08:43:17 GMT (envelope-from brucec) Date: Sat, 13 Nov 2010 08:43:17 GMT Message-Id: <201011130843.oAD8hHdA059325@freefall.freebsd.org> To: brucec@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: brucec@FreeBSD.org Cc: Subject: Re: bin/150642: netstat(1) doesn't print anything for SCTP sockets X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Nov 2010 08:43:18 -0000 Synopsis: netstat(1) doesn't print anything for SCTP sockets Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: brucec Responsible-Changed-When: Sat Nov 13 08:42:55 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=150642 From owner-freebsd-net@FreeBSD.ORG Sat Nov 13 14:49:14 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AA54B1065694 for ; Sat, 13 Nov 2010 14:49:14 +0000 (UTC) (envelope-from rene@reckschwardt.de) Received: from rds11224.i4e-server.de (rds11224.i4e-server.de [195.225.105.212]) by mx1.freebsd.org (Postfix) with ESMTP id BF01C8FC20 for ; Sat, 13 Nov 2010 14:49:13 +0000 (UTC) Received: from mail.menny.de (p5DDA92A3.dip.t-dialin.net [93.218.146.163]) by rds11224.i4e-server.de (Postfix) with ESMTPSA id 8554CB470D68 for ; Sat, 13 Nov 2010 15:49:11 +0100 (CET) Received: from [192.168.1.129] by mail.menny.de with esmtp (Exim 4.72) (envelope-from ) id 1PHHPf-00044y-0k for freebsd-net@freebsd.org; Sat, 13 Nov 2010 15:49:10 +0100 Date: Sat, 13 Nov 2010 14:49:06 +0000 From: "rene@reckschwardt.de" User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; de-DE; rv:1.9.2.9) Gecko/20100918 Thunderbird/3.1.4 MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <20101111193534.A7D838090AAD@rds11224.i4e-server.de> <20101111213156.GG17566@michelle.cdnetworks.com> <20101111225340.C2835B470D68@rds11224.i4e-server.de> <20101113021507.GG22460@michelle.cdnetworks.com> In-Reply-To: <20101113021507.GG22460@michelle.cdnetworks.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060301020609010704040501" X-Scan-Signature: 4b7c546b54f537557784d77230aa1653 X-Spam-Score: -2.7 (--) Message-Id: <20101113144911.8554CB470D68@rds11224.i4e-server.de> X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: ML370 G4 with poor Network Performance and high CPU Load X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Nov 2010 14:49:14 -0000 This is a cryptographically signed message in MIME format. --------------ms060301020609010704040501 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable > You still didn't post dmesg output. Because there were a lot of > bge(4) changes since 8.1-RELEASE, I think it would be better to try > CURRENT or latest snapshot release and check whether you still see > the same issue. > OK, here is the complete dmesg: file# dmesg Copyright (c) 1992-2010 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved= =2E FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.1-RELEASE #3 r210190: Sat Jul 17 16:30:44 PDT 2010 =20 root@build8x64.pcbsd.org:/usr/obj/storage/fbsd-sources/8.1/sys/GENERIC am= d64 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(TM) CPU 3.60GHz (3600.15-MHz K8-class CPU) Origin =3D "GenuineIntel" Id =3D 0xf41 Family =3D f Model =3D 4 St= epping =3D 1 =20 Features=3D0xbfebfbff=20 Features2=3D0x659d AMD Features=3D0x20000800 TSC: P-state invariant real memory =3D 4294967296 (4096 MB) avail memory =3D 4039778304 (3852 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 2 package(s) x 1 core(s) x 2 HTT threads cpu0 (BSP): APIC ID: 0 cpu1 (AP/HT): APIC ID: 1 cpu2 (AP): APIC ID: 6 cpu3 (AP/HT): APIC ID: 7 ACPI Warning: Invalid length for Pm1aControlBlock: 32, using default 16=20 (20100331/tbfadt-707) ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard ioapic2 irqs 48-71 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x908-0x90b on acpi0 cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 pcib0: on acpi0 pci0: on pcib0 pcib1: at device 2.0 on pci0 pci2: on pcib1 pcib2: at device 0.0 on pci2 pci3: on pcib2 pcib3: at device 1.0 on pci3 pci4: on pcib3 vgapci0: port 0x5000-0x50ff mem=20 0xfc000000-0xfcffffff,0xfbff0000-0xfbff0fff at device 0.0 on pci4 pci4: at device 1.0 (no driver attached) pci4: at device 2.0 (no driver attached) pci4: at device 4.0 (no driver attached) ciss0: port 0x4000-0x40ff mem=20 0xfbef0000-0xfbef1fff,0xfbe80000-0xfbebffff irq 29 at device 2.0 on pci3 ciss0: PERFORMANT Transport ciss0: got 0 MSI messages] ciss0: [ITHREAD] pcib4: at device 0.2 on pci2 pci7: on pcib4 em0: port=20 0x6000-0x603f mem 0xfdfe0000-0xfdffffff,0xfdf80000-0xfdfbffff irq 50 at=20 device 1.0 on pci7 em0: [FILTER] em0: Ethernet address: 00:11:0a:58:8b:d0 em1: port=20 0x6040-0x607f mem 0xfdf60000-0xfdf7ffff irq 57 at device 1.1 on pci7 em1: [FILTER] em1: Ethernet address: 00:11:0a:58:8b:d1 ciss1: port 0x6400-0x64ff mem=20 0xfdf50000-0xfdf51fff,0xfdf00000-0xfdf3ffff irq 53 at device 2.0 on pci7 ciss1: PERFORMANT Transport ciss1: got 0 MSI messages] ciss1: [ITHREAD] bge0: mem=20 0xfdef0000-0xfdefffff irq 49 at device 3.0 on pci7 miibus0: on bge0 brgphy0: PHY 1 on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT,=20 1000baseT-FDX, auto bge0: Ethernet address: 00:13:21:c8:fa:ff bge0: [ITHREAD] pcib5: at device 4.0 on pci0 pci11: on pcib5 pcib6: at device 5.0 on pci0 pci14: on pcib6 uhci0: port 0x3000-0x301f=20 irq 16 at device 29.0 on pci0 uhci0: [ITHREAD] usbus0: on uhci0 uhci1: port 0x3020-0x303f=20 irq 19 at device 29.1 on pci0 uhci1: [ITHREAD] usbus1: on uhci1 uhci2: port 0x3040-0x305f=20 irq 18 at device 29.2 on pci0 uhci2: [ITHREAD] usbus2: on uhci2 uhci3: port 0x3060-0x307f=20 irq 16 at device 29.3 on pci0 uhci3: [ITHREAD] usbus3: on uhci3 ehci0: mem=20 0xf9ef0000-0xf9ef03ff irq 23 at device 29.7 on pci0 ehci0: [ITHREAD] usbus4: EHCI version 1.0 usbus4: on ehci0 pcib7: at device 30.0 on pci0 pci1: on pcib7 pci1: at device 4.0 (no driver attached) pci1: at device 4.2 (no driver attached) isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port=20 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x500-0x50f at device 31.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] acpi_tz0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: [FILTER] fdc0: port 0x3f2-0x3f5 irq 6 drq 2 on acp= i0 fdc0: [FILTER] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 orm0: at iomem=20 0xc0000-0xc7fff,0xc8000-0xcbfff,0xcc000-0xcd7ff,0xcd800-0xd17ff,0xee000-0= xeffff=20 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=3D0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0= atrtc0: at port 0x70 irq 8 on isa0 ppc0: cannot reserve I/O port range est0: on cpu0 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 122a0000122a device_attach: est0 attach returned 6 p4tcc0: on cpu0 est1: on cpu1 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 122a0000122a device_attach: est1 attach returned 6 p4tcc1: on cpu1 est2: on cpu2 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 122a0000122a device_attach: est2 attach returned 6 p4tcc2: on cpu2 est3: on cpu3 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 122a0000122a device_attach: est3 attach returned 6 p4tcc3: on cpu3 Timecounters tick every 1.000 msec usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 12Mbps Full Speed USB v1.0 usbus4: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 ugen4.1: at usbus4 uhub4: on usbus4 uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered uhub3: 2 ports with 2 removable, self powered acd0: DVDROM at ata0-master UDMA33 uhub4: 8 ports with 8 removable, self powered da0 at ciss0 bus 0 scbus0 target 0 lun 0 da0: Fixed Direct Access SCSI-5 device da0: 135.168MB/s transfers da0: Command Queueing enabled da0: 2861512MB (5860378032 512 byte sectors: 255H 32S/T 65535C) da1 at ciss1 bus 0 scbus2 target 0 lun 0 da1: Fixed Direct Access SCSI-4 device da1: 135.168MB/s transfers da1: Command Queueing enabled da1: 34727MB (71122560 512 byte sectors: 255H 32S/T 8716C) SMP: AP CPU #1 Launched! SMP: AP CPU #3 Launched! SMP: AP CPU #2 Launched! Trying to mount root from ufs:/dev/label/rootfs0 ZFS filesystem version 3 ZFS storage pool version 14 em0: link state changed to UP pid 1120 (mpd), uid 1003: exited on signal 6 em0: link state changed to DOWN em0: link state changed to UP em0: link state changed to DOWN em0: link state changed to UP pid 28337 (try), uid 0: exited on signal 10 (core dumped) pid 67888 (try), uid 0: exited on signal 10 (core dumped) pid 9379 (mpd), uid 0: exited on signal 6 (core dumped) lagg0: link state changed to UP lagg0: link state changed to DOWN lagg0: link state changed to UP lagg0: link state changed to DOWN lagg0: link state changed to UP em1: link state changed to UP lagg0: link state changed to DOWN bge0: link state changed to UP lagg0: link state changed to UP lagg0: link state changed to DOWN regards r=E9 --------------ms060301020609010704040501-- From owner-freebsd-net@FreeBSD.ORG Sat Nov 13 16:08:47 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 82AB0106564A; Sat, 13 Nov 2010 16:08:47 +0000 (UTC) (envelope-from brucec@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 579228FC1B; Sat, 13 Nov 2010 16:08:47 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id oADG8lJH021943; Sat, 13 Nov 2010 16:08:47 GMT (envelope-from brucec@freefall.freebsd.org) Received: (from brucec@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id oADG8lh7021939; Sat, 13 Nov 2010 16:08:47 GMT (envelope-from brucec) Date: Sat, 13 Nov 2010 16:08:47 GMT Message-Id: <201011131608.oADG8lh7021939@freefall.freebsd.org> To: brucec@FreeBSD.org, freebsd-i386@FreeBSD.org, freebsd-net@FreeBSD.org From: brucec@FreeBSD.org Cc: Subject: Re: kern/148780: [panic] mtx_lock() of spin mutex (null) @ /usr/src/sys/net/netisr.c:830 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Nov 2010 16:08:47 -0000 Synopsis: [panic] mtx_lock() of spin mutex (null) @ /usr/src/sys/net/netisr.c:830 Responsible-Changed-From-To: freebsd-i386->freebsd-net Responsible-Changed-By: brucec Responsible-Changed-When: Sat Nov 13 16:08:11 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=148780 From owner-freebsd-net@FreeBSD.ORG Sat Nov 13 22:17:30 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 30B3C106564A for ; Sat, 13 Nov 2010 22:17:30 +0000 (UTC) (envelope-from mahan@mahan.org) Received: from ns.mahan.org (ns.mahan.org [67.116.10.138]) by mx1.freebsd.org (Postfix) with ESMTP id DDBE28FC1C for ; Sat, 13 Nov 2010 22:17:29 +0000 (UTC) Received: from Gypsy.mahan.org (crowTrobot [67.116.10.140]) by ns.mahan.org (8.13.6/8.13.6) with ESMTP id oADLwc5E009642 for ; Sat, 13 Nov 2010 13:58:38 -0800 (PST) (envelope-from mahan@mahan.org) Message-ID: <4CDF09BD.3050509@mahan.org> Date: Sat, 13 Nov 2010 13:57:17 -0800 From: Patrick Mahan User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Debugging em(4) driver X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Nov 2010 22:17:30 -0000 Good afternoon, I am trying to run down a root cause of a link failure between two of my HP Proliant DL350's. pciconf shows them as the 82571EB chip. These are a 4 port card on the HP. We are doing some routing code in the kernel and have a call to our entry function in the forwarding path in ip_input(). We have WITNESS and INVARIANTS enable in our kernel configuration. Our current testbed has these two HP's em3 ports connected via a ethernet crossover cable. I am generating traffic using 'iperf -u -b 20M' and these links show up as 1000Mbps, so I should not be saturating the interface. The traffic is fine for a while, but then we start to fail to see anymore traffic. A ping started before generating the traffic just stops almost as soon as the iperf traffic begins. I cannot find any error messages indicating that there is a problem with em(4). Is there anything I can use to debug this issue? If not, then I guess I will need to put in some debugging in the xmit path of em(4). Another issue that sometimes raises it head, especially if I have a lot of printf's occurring on a per-packet basis, is I get a double deallocation panic from uma_dbg_free(). When this has occurred I have freed the packet using m_freem() (Since we don't want the packet to be forwarded). But then it looks like em(4) gets an interrupt and frees the packet at em_init_locked()+0x91f. Which may be in the receive handler code. Any and all help/ideas will be appreciated. Output of 'ifconfig em3' em3: flags=8843 metric 0 mtu 1500 options=19b ether 00:1f:29:5f:c6:aa inet 172.16.13.30 netmask 0xffffff00 broadcast 172.16.13.255 media: Ethernet autoselect (1000baseT ) status: active Output of 'netstat -I em3' Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll em3 1500 00:1f:29:5f:c6:aa 11099 89322 11298 0 0 em3 1500 172.16.13.0 172.16.13.30 11096 - 11296 - - pciconf -lv shows - em0@pci0:21:0:0: class=0x020000 card=0x704b103c chip=0x10bc8086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' device = '82571EB Gigabit Ethernet Controller (Copper)' class = network subclass = ethernet em1@pci0:21:0:1: class=0x020000 card=0x704b103c chip=0x10bc8086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' device = '82571EB Gigabit Ethernet Controller (Copper)' class = network subclass = ethernet em2@pci0:22:0:0: class=0x020000 card=0x704b103c chip=0x10bc8086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' device = '82571EB Gigabit Ethernet Controller (Copper)' class = network subclass = ethernet em3@pci0:22:0:1: class=0x020000 card=0x704b103c chip=0x10bc8086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' device = '82571EB Gigabit Ethernet Controller (Copper)' class = network subclass = ethernet Thanks, Patrick From owner-freebsd-net@FreeBSD.ORG Sat Nov 13 22:27:32 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D291A106566C for ; Sat, 13 Nov 2010 22:27:32 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 652D18FC15 for ; Sat, 13 Nov 2010 22:27:31 +0000 (UTC) Received: by ewy3 with SMTP id 3so904949ewy.13 for ; Sat, 13 Nov 2010 14:27:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=kTcgD56XIcT6YszAa/qKOvmZayskRpcVY88lDmBXZwU=; b=sUqZydS4Z98tPT1L2jDOhNDpUAgcPu1414bphuuHkS3BTyNl+sSMkJYlOJgD2taRhH gKhjKmdZtWnkWtWSphzscsHqsNuDIzQr5MemJMWsF2PfRJU1ZMltX7NQc7tXV5KsIENL lJNbsKESOHt1wPHP1pjbYmcl2Us1Il0QeU/iw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=A3pOpakU9RnU4eOYJFQwMpWSjrGmaaNgcDmjPpDtUn5+K8EZF/IFxm/39RrrnyoGtr NNZoZUQ1hoKAmRRMVwVzcj9r+heHdbEUOWbG5UFZtJ505wZKATQbnRSAAcIEU/VqcKvf d8UNU0TZa6t3KGWmaoWA2IsNYXZ1hgYKGl63c= MIME-Version: 1.0 Received: by 10.213.33.82 with SMTP id g18mr3466462ebd.64.1289687251080; Sat, 13 Nov 2010 14:27:31 -0800 (PST) Received: by 10.213.2.143 with HTTP; Sat, 13 Nov 2010 14:27:31 -0800 (PST) In-Reply-To: <4CDF09BD.3050509@mahan.org> References: <4CDF09BD.3050509@mahan.org> Date: Sat, 13 Nov 2010 17:27:31 -0500 Message-ID: From: Ryan Stone To: Patrick Mahan Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org Subject: Re: Debugging em(4) driver X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Nov 2010 22:27:32 -0000 It looks to me that you're getting a ton of input drops. That's presumably the cause of your issue. You can get the em driver to print debug information to the console by running: # sysctl dev.em.3.stats=1 # sysctl.dev.em.3.debug=1 The output should be available in dmesg and /var/log/messages Hopefully that can shed some light on the nature of the drops.