From owner-freebsd-net@FreeBSD.ORG Sun Jun 26 00:17:34 2011 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 644F21065670 for ; Sun, 26 Jun 2011 00:17:34 +0000 (UTC) (envelope-from dudu@dudu.ro) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id 2DF9E8FC0A for ; Sun, 26 Jun 2011 00:17:33 +0000 (UTC) Received: by qyk30 with SMTP id 30so951975qyk.13 for ; Sat, 25 Jun 2011 17:17:33 -0700 (PDT) Received: by 10.229.134.199 with SMTP id k7mr3562084qct.171.1309045785195; Sat, 25 Jun 2011 16:49:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.39.210 with HTTP; Sat, 25 Jun 2011 16:49:05 -0700 (PDT) In-Reply-To: References: From: Vlad Galu Date: Sun, 26 Jun 2011 01:49:05 +0200 Message-ID: To: Adrian Minta Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: FreeBSD 8.2 and MPD5 stability issues 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, 26 Jun 2011 00:17:34 -0000 On Sat, Jun 25, 2011 at 11:28 PM, Adrian Minta wrote: > After recompilation with "*default release=cvs tag=RELENG_8" and pooling > disables the system still crashes around 4200 sessions. The server has a > xeon E5520 CPU and 4G of ram. Here is the crash on the screen: > http://img232.imageshack.us/img232/6751/crashm.png > > $uname -a > FreeBSD lns 8.2-STABLE FreeBSD 8.2-STABLE #2: Sat Jun 25 23:50:06 EEST > 2011 gygy@lns:/usr/obj/usr/src/sys/MYKERNELv3 amd64 > > /boot/loader.conf: > > net.graph.maxdata=65536 > net.graph.maxalloc=65536 > kern.ipc.maxpipekva=320000000 > #I wave 4 cores > net.isr.bindthreads=4 > net.isr.maxthreads=1 > net.isr.defaultqlimit=4096 > > /etc/sysctl.conf: > > net.inet.ip.forwarding=1 > kern.maxfiles=65535 > net.inet.ip.intr_queue_maxlen=8192 > net.inet.icmp.icmplim=0 > kern.ipc.nmbclusters=1280000 > kern.ipc.maxsockbuf=128000000 > net.graph.maxdgram=10240000 > net.graph.recvspace=10240000 > kern.random.sys.harvest.ethernet=0 > net.isr.direct=1 > net.isr.direct_force=0 > > > Kernel GENERIC plus: > > #options DEVICE_POLLING > options HZ=1000 > options NETGRAPH > options NETGRAPH_PPPOE > options NETGRAPH_SOCKET > options NETGRAPH_CISCO > options NETGRAPH_ECHO > options NETGRAPH_FRAME_RELAY > options NETGRAPH_HOLE > options NETGRAPH_KSOCKET > options NETGRAPH_LMI > options NETGRAPH_RFC1490 > options NETGRAPH_TTY > options NETGRAPH_ASYNC > options NETGRAPH_BPF > options NETGRAPH_ETHER > options NETGRAPH_IFACE > options NETGRAPH_L2TP > options NETGRAPH_MPPC_ENCRYPTION > options NETGRAPH_PPP > options NETGRAPH_PPTPGRE > options NETGRAPH_TEE > options NETGRAPH_UI > options NETGRAPH_VJC > > options ALTQ > options ALTQ_CBQ > options ALTQ_RED > options ALTQ_RIO > options ALTQ_HFSC > options ALTQ_PRIQ > # options ALTQ_NOPCC > > device pf > device pflog > device pfsync > device gre > > device tap > device hme > > # Bridging > device if_bridge > device lagg > > options IPSTEALTH > options ZERO_COPY_SOCKETS > > options NETGRAPH_DEBUG > options GDB > options DDB > options KDB_UNATTENDED > > > Hi Adrian, You will need to set dumpdev to something (e.g. "AUTO") in /etc/rc.conf (it defaults to NO) so that your kernel coredump is saved to your swap partition before rebooting. Also, you might want to remove ZERO_COPY_SOCKETS. -- Good, fast & cheap. Pick any two. From owner-freebsd-net@FreeBSD.ORG Sun Jun 26 00:17:40 2011 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 B03E1106566B for ; Sun, 26 Jun 2011 00:17:40 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1-6.sentex.ca [IPv6:2607:f3e0:0:1::12]) by mx1.freebsd.org (Postfix) with ESMTP id 75BCB8FC0C for ; Sun, 26 Jun 2011 00:17:40 +0000 (UTC) Received: from [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a] (saphire3.sentex.ca [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a]) by smarthost1.sentex.ca (8.14.4/8.14.4) with ESMTP id p5Q0HaHT052606; Sat, 25 Jun 2011 20:17:36 -0400 (EDT) (envelope-from mike@sentex.net) Message-ID: <4E067A9E.20706@sentex.net> Date: Sat, 25 Jun 2011 20:17:34 -0400 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Adrian Minta References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on IPv6:2607:f3e0:0:1::12 Cc: freebsd-net@freebsd.org Subject: Re: FreeBSD 8.2 and MPD5 stability issues 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, 26 Jun 2011 00:17:40 -0000 On 6/25/2011 5:28 PM, Adrian Minta wrote: > > options ALTQ > options ALTQ_CBQ > options ALTQ_RED > options ALTQ_RIO > options ALTQ_HFSC > options ALTQ_PRIQ > # options ALTQ_NOPCC > > device pf > device pflog > device pfsync pf and altq add quite a bit of networking overhead. If you are not using them, I would get rid of them. > device hme You really have this nic ? > options ZERO_COPY_SOCKETS Not sure how stable this option is. Enable crash dumps crashinfo_enable="YES" # Automatically generate crash dump summary. dumpdev="AUTO" dumpdir="/var/crash" # Directory where crash dumps are to be stored This will create a .txt file in /var/crash that will have all the info about the issue ---Mike > > > > > _______________________________________________ > 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" > > -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-net@FreeBSD.ORG Sun Jun 26 05:22:31 2011 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 191BB106564A for ; Sun, 26 Jun 2011 05:22:31 +0000 (UTC) (envelope-from michael.schuh@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id D19E28FC14 for ; Sun, 26 Jun 2011 05:22:30 +0000 (UTC) Received: by iyb11 with SMTP id 11so4651742iyb.13 for ; Sat, 25 Jun 2011 22:22:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=+sHUjfqN96q1FCEqGxVERcMA32rP3sHqp9CI5Yly4WE=; b=H/XFg/AuF4Zpr9aqMh5KqEhPcuh86oOIcO/ZD3cicSY9ATRCDy2seWqR3TmLqZQ+Nq HjvLcif6P6dLBJgwc8K2C0Y2r24IsxCT2ZospYRPdJmLl8oA7xsep+GGHmFYK3wqtQG/ GvuRBVvh1P5x0AXunj1jM3uqZZz6RXNVgoUgY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=XnAl49E/VVgH5c5O4oxVgibQdARx+wu2NUGWUK13jD7MHN5Ho6qaKzVqfI6nWvlDUo jh8V5RUU37GruT06a+yc2vKSvaDI0FgWAnqD2ITSRnXetOiQ4y68XBRSdcbRJlMGt7gO JSnzJKqGIOFSysI+aV1QgCmCirMC00F9hNxoY= MIME-Version: 1.0 Received: by 10.231.74.84 with SMTP id t20mr4630004ibj.38.1309064037133; Sat, 25 Jun 2011 21:53:57 -0700 (PDT) Received: by 10.231.146.9 with HTTP; Sat, 25 Jun 2011 21:53:57 -0700 (PDT) Date: Sun, 26 Jun 2011 06:53:57 +0200 Message-ID: From: Michael Schuh To: FreeBSD Net Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: Kernel memory corruption(?) with age(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: Sun, 26 Jun 2011 05:22:31 -0000 Hi, i am not on the list atm. i found this entry after digging in google during problems with a normally rock stable system ( under linux). I can also confirm the behaviour from the first post. After a long hard night digging in the system and changing some options i found a repeatable way to crash the system ultrafast. at the initial crashes the system crashed after copying around 800GB. the second and third and further attempts/impacts got issued everytime after an ~ hour from reboot on. leaving the system withouth any power, changing some hardware forth and back didn't changed anything, except the network card. a happening beside that: immediatly after the initial boot will get the ntpdate and ntpd started. by this, the ntpd complains about unsresolveable hostnames from ntp.conf. if you log in and restart the ntpd by hand, everything is fine, no complains, no unresolveable hostnames. the hostnames are well known and tested and the DNS works still fine. this happening will also leave if you change the Ethernet-adapter to an Intel Card. My system crashed so fast that i didn't got any log entry nor a crashdump. my last try's crashed my system after 100 - 120 seconds. HW: AMD P5K with Atheros age-Interface enabled, 6GB Corsair DDR2 800MHZ (pc6400) RAM ( latency 5-5-5-5-18) Ati Radeon HD4350 with 512MB Onboard Memory, 3 disks 2 PATA, 1 SATA. OS: FreeBSD/amd64 8.2-RELEASE ( unmodified original RELEASE install ) REQUIREMENTS to repeat the issue: box A: a stable FreeBSD or Linux Box with GBitEthernet interface and no essential networkload box B: the affected FreeBSD Host with the age interface. the age0 interface is configured with default options. only the ip-configuration got applied through rc.conf ifconfig_age0=3D"192.168.1.3 netmask 255.255.255.0" PROCEDURE: On Box A ( p.e IP: 192.168.1.2 ) issue the command: # dd if=3D/dev/zero |nc -l -p 1666 On Box B issue a complementary command like: # nc 192.168.1.2 1666| dd of=3D/dev/null I am sorry i cannot test a patch at this time cause this is a backup server= , that has to get asap into production. After disabling the age-Interface in the bios settings and inserting a Inte= l GBit NIC the System runs stable again. i hope this informations will help a bit. if you need to message me, please message me directly cause i am not registered for this list. thank you greetings m. --=20 =3D =3D =3D http://michael-schuh.net/ =3D =3D =3D Projektmanagement - IT-Consulting - Professional Services IT Michael Schuh Postfach 10 21 52 66021 Saarbr=FCcken phone: 0681/8319664 mobil: 0175/5616453 @: m i c h a e l . s c h u h @ g m a i l . c o m =3D =3D =3D Ust-ID: DE251072318 =3D =3D =3D From owner-freebsd-net@FreeBSD.ORG Sun Jun 26 11:20:04 2011 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 2ED93106566B for ; Sun, 26 Jun 2011 11:20:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id F38548FC08 for ; Sun, 26 Jun 2011 11:20:03 +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 p5QBK38f028097 for ; Sun, 26 Jun 2011 11:20:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p5QBK3sh028096; Sun, 26 Jun 2011 11:20:03 GMT (envelope-from gnats) Date: Sun, 26 Jun 2011 11:20:03 GMT Message-Id: <201106261120.p5QBK3sh028096@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: "Alexander V. Chernikov" Cc: Subject: Re: kern/127057: [udp] Unable to send UDP packet via IPv6 socket to IPv4 mapped address X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Alexander V. Chernikov" List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jun 2011 11:20:04 -0000 The following reply was made to PR kern/127057; it has been noted by GNATS. From: "Alexander V. Chernikov" To: bug-followup@FreeBSD.org, saper@SYSTEM.PL Cc: Subject: Re: kern/127057: [udp] Unable to send UDP packet via IPv6 socket to IPv4 mapped address Date: Sun, 26 Jun 2011 15:16:46 +0400 Problem seems to be fixed in -current in r220463 From owner-freebsd-net@FreeBSD.ORG Sun Jun 26 14:41:35 2011 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 43A511065673 for ; Sun, 26 Jun 2011 14:41:35 +0000 (UTC) (envelope-from adrian.chadd@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 F1CE88FC13 for ; Sun, 26 Jun 2011 14:41:34 +0000 (UTC) Received: by gxk28 with SMTP id 28so2152425gxk.13 for ; Sun, 26 Jun 2011 07:41:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=1WvGQltiznG3dCJ5xotj3H+wMlOqFFsPE1uOtVszWBM=; b=qRAph7Q4xerrIxLbJVIJW8hosXC8jk/Mcb1WgeYrpT39H+eSzjFi31zFHNcR1wcCis OVLLBDZNCiQpSVC5RrPWshhzrGLn2vLP3U7z2kB25lQK+TKc2pTsFp/dFgpMhNGm+wpN NkGdCOAAj4PIay1jLRh8CoFEId2PUgAsv1cUM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=Ohs7KwFcK9Aspube9948xIp/JQHF/pwB+9mWMXqFL+Jx9H1q2KJTwWG7pHeJHrozFb hi8r0dokHZZ52awbVG/L8Dc3HA48mw98OpNjBXSQVMuasSvwNaH/tDekhk3DXzPQdR5r c3F5yLgRg/pTrp6RTnOfL4G5rOaDfXU1EMIYI= MIME-Version: 1.0 Received: by 10.150.55.12 with SMTP id d12mr5934937yba.66.1309099294349; Sun, 26 Jun 2011 07:41:34 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.150.146.13 with HTTP; Sun, 26 Jun 2011 07:41:34 -0700 (PDT) In-Reply-To: References: Date: Sun, 26 Jun 2011 22:41:34 +0800 X-Google-Sender-Auth: 2I4BojAON4sPIHzH7Z1PuOb13qE Message-ID: From: Adrian Chadd To: Patrick Lahni Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: iwn -CURRENT drivers on -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, 26 Jun 2011 14:41:35 -0000 On 25 June 2011 03:00, Patrick Lahni wrote: > End game is I'd like tinker around using it at least in hostap mode. =A0I > realize 11n is still very much in development and I'm ok with that. =A0Ev= en > using it as 11g in hostap mode would be a plus until 11n catches up. =A0A= s of > now, hostap isn't supported on my card in -stable, at least that's what > dmesg tells me when I try. =A0I'd love to help test this if it was possib= le to > use -current for just those modules and -stable for the rest of the machi= ne. I think the problem with the iwn NICs here is we're limited to what the firmware supports, and I don't -think- the firmware even supports hostap mode. Your best bet is what everyone else seems to do, use an ath(4) NIC. :) Bernhard's making some great progress with iwn and 11n in STA mode though. Adrian From owner-freebsd-net@FreeBSD.ORG Sun Jun 26 16:28:45 2011 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 A7E261065673 for ; Sun, 26 Jun 2011 16:28:45 +0000 (UTC) (envelope-from cyko@cykotix.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 7952B8FC14 for ; Sun, 26 Jun 2011 16:28:45 +0000 (UTC) Received: by iwr19 with SMTP id 19so4928687iwr.13 for ; Sun, 26 Jun 2011 09:28:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.47.134 with SMTP id n6mr5170944ibf.7.1309105724549; Sun, 26 Jun 2011 09:28:44 -0700 (PDT) Sender: cyko@cykotix.com Received: by 10.231.30.73 with HTTP; Sun, 26 Jun 2011 09:28:44 -0700 (PDT) X-Originating-IP: [69.133.3.144] In-Reply-To: References: Date: Sun, 26 Jun 2011 12:28:44 -0400 X-Google-Sender-Auth: lB0qcGlf_g0gjkXlgQuTbBydeCY Message-ID: From: Patrick Lahni To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: iwn -CURRENT drivers on -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, 26 Jun 2011 16:28:45 -0000 On Sun, Jun 26, 2011 at 10:41 AM, Adrian Chadd wrote: > On 25 June 2011 03:00, Patrick Lahni wrote: > > > End game is I'd like tinker around using it at least in hostap mode. I > > realize 11n is still very much in development and I'm ok with that. Even > > using it as 11g in hostap mode would be a plus until 11n catches up. As > of > > now, hostap isn't supported on my card in -stable, at least that's what > > dmesg tells me when I try. I'd love to help test this if it was possible > to > > use -current for just those modules and -stable for the rest of the > machine. > > I think the problem with the iwn NICs here is we're limited to what > the firmware supports, and I don't -think- the firmware even supports > hostap mode. > > Your best bet is what everyone else seems to do, use an ath(4) NIC. :) > > Bernhard's making some great progress with iwn and 11n in STA mode though. > > > Adrian > Yea, that's what I just ended up doing. Just purchased a AR9280 half-height mini pci-e to install on my itx board. I'm hoping this will do what I want - dual band 11gn hostap (or at least just 11g hostap). Live and learn. Thanks for the input! Patrick From owner-freebsd-net@FreeBSD.ORG Sun Jun 26 20:38:22 2011 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 479E2106564A; Sun, 26 Jun 2011 20:38:22 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 1FC458FC14; Sun, 26 Jun 2011 20:38:22 +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 p5QKcMGY040424; Sun, 26 Jun 2011 20:38:22 GMT (envelope-from gavin@freefall.freebsd.org) Received: (from gavin@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p5QKcLLS040420; Sun, 26 Jun 2011 20:38:21 GMT (envelope-from gavin) Date: Sun, 26 Jun 2011 20:38:21 GMT Message-Id: <201106262038.p5QKcLLS040420@freefall.freebsd.org> To: gavin@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: gavin@FreeBSD.org Cc: Subject: Re: kern/158307: [ipv6] ipv6_pktinfo breaks IPV6_USE_MIN_MTU 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, 26 Jun 2011 20:38:22 -0000 Synopsis: [ipv6] ipv6_pktinfo breaks IPV6_USE_MIN_MTU Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: gavin Responsible-Changed-When: Sun Jun 26 20:38:03 UTC 2011 Responsible-Changed-Why: Over to maintaner(s) http://www.freebsd.org/cgi/query-pr.cgi?pr=158307 From owner-freebsd-net@FreeBSD.ORG Sun Jun 26 21:20:19 2011 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 746E31065674 for ; Sun, 26 Jun 2011 21:20:19 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 43E2E8FC13 for ; Sun, 26 Jun 2011 21:20:19 +0000 (UTC) Received: by pzk27 with SMTP id 27so202349pzk.13 for ; Sun, 26 Jun 2011 14:20:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:date:to:cc:subject:message-id:reply-to :references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=o5HgdgoXhK0BwmApnomI+DorFDGeR1P5E8bcTz4J2HQ=; b=SpnvD3+B+/r5bJnUj7AffljN3l4WDmPvN3TBnwqeg1SB8I993Dlsprjyzm2mciqCSP SrsA3zSciOqzk7em4as4xaqW8guappjVmb9pJFoue+EdM75a207SGKGheTsS8o7BzpBP dl12iSOqz/K8lCTfvOVl3HklO4hVGgIuZqWl0= 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=BthcpZGE5xzR56Vorv065xIT+RYhzr0mNY09E56pDirQsy2iS55FOTSyIEsBXvZ8lr 7+y8cI9ws1Y/juwbjFF89drrPQwRUh6dgBV4lsz942z9Rcuj2owwgjGgTv9Chj7DUcl4 o8NlDkR952Vk9dE+5MskL6HRyweJQ2WgUMCK4= Received: by 10.142.152.28 with SMTP id z28mr982048wfd.293.1309123218549; Sun, 26 Jun 2011 14:20:18 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id n9sm4098098wfk.8.2011.06.26.14.20.15 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 26 Jun 2011 14:20:17 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Sun, 26 Jun 2011 14:19:22 -0700 From: YongHyeon PYUN Date: Sun, 26 Jun 2011 14:19:21 -0700 To: Michael Schuh Message-ID: <20110626211921.GA1629@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 Subject: Re: Kernel memory corruption(?) with age(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: Sun, 26 Jun 2011 21:20:19 -0000 On Sun, Jun 26, 2011 at 06:53:57AM +0200, Michael Schuh wrote: > Hi, > > i am not on the list atm. > > i found this entry after digging in google during problems with a normally > rock stable > system ( under linux). > > I can also confirm the behaviour from the first post. > After a long hard night digging in the system and changing some options > i found a repeatable way to crash the system ultrafast. > > at the initial crashes the system crashed after copying around 800GB. > the second and third and further attempts/impacts got issued everytime > after an ~ hour from reboot on. leaving the system withouth any power, > changing some hardware > forth and back didn't changed anything, except the network card. > > a happening beside that: immediatly after the initial boot will get the > ntpdate and ntpd started. > by this, the ntpd complains about unsresolveable hostnames from ntp.conf. > if you log in and restart the ntpd by hand, everything is fine, no > complains, > no unresolveable hostnames. > the hostnames are well known and tested and the DNS works still fine. > this happening will also leave if you change the Ethernet-adapter to an > Intel Card. > > My system crashed so fast that i didn't got any log entry nor a crashdump. > > my last try's crashed my system after 100 - 120 seconds. > > HW: AMD P5K with Atheros age-Interface enabled, 6GB Corsair DDR2 800MHZ > (pc6400) RAM ( latency 5-5-5-5-18) > Ati Radeon HD4350 with 512MB Onboard Memory, 3 disks 2 PATA, 1 SATA. > > OS: FreeBSD/amd64 8.2-RELEASE ( unmodified original RELEASE install ) > > REQUIREMENTS to repeat the issue: > box A: a stable FreeBSD or Linux Box with GBitEthernet interface and no > essential networkload > box B: the affected FreeBSD Host with the age interface. > > the age0 interface is configured with default options. > only the ip-configuration got applied through rc.conf > > ifconfig_age0="192.168.1.3 netmask 255.255.255.0" > > PROCEDURE: > On Box A ( p.e IP: 192.168.1.2 ) issue the command: > > # dd if=/dev/zero |nc -l -p 1666 > > On Box B issue a complementary command like: > > # nc 192.168.1.2 1666| dd of=/dev/null > > I am sorry i cannot test a patch at this time cause this is a backup server, > that has to get asap into production. > After disabling the age-Interface in the bios settings and inserting a Intel > GBit NIC the System runs stable again. > > i hope this informations will help a bit. > if you need to message me, please message me directly cause i am not > registered for this list. > I think the issue was already fixed(r220249, r220252). Apply the patch and rebuild your kernel after downloading it from the following URL. http://svnweb.freebsd.org/base/head/sys/dev/age/if_age.c?r1=219902&r2=220252&view=patch If you see the same issue again with this patch please let me know. From owner-freebsd-net@FreeBSD.ORG Mon Jun 27 10:41:20 2011 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 03176106566B for ; Mon, 27 Jun 2011 10:41:20 +0000 (UTC) (envelope-from williamejsalt@googlemail.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 C28A28FC0A for ; Mon, 27 Jun 2011 10:41:19 +0000 (UTC) Received: by iwr19 with SMTP id 19so5548093iwr.13 for ; Mon, 27 Jun 2011 03:41:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=eYMYnzhKqiiZt4bJ7QzGxsC+hzp8puHBIxLCrUqGM4E=; b=hDY1kj1wGeQrQXAe8NHaaDV3jwEpuModvQrwgDbmEHmJJtwNAf4lvwE7sMI5tVortb YLtHJxTpl6yl5juFB9bZVMjes/YomjbAzXkmeTPddX5nBIKtVW4iW9oRf+lkv1gD8wxr GY9Nl4Nt5DkOhWCNaetsUTE6aP+My0fo03mF8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=K2vutA7QKEA6CmTZE6yRJN3ep+fD1LOOJi0whTzBgIpvHpLb1q4EXrrKNlH8P7Z5F1 ptgmEDmn/rR3kPUrjDmBOk29iwkr9RGncfRjrd0BUgOFbA5OMndmRyDPyAi3Eg1Z3TwQ vT/kDPaWUoszF/rP3xH6wix+b+dCi+d64opXw= MIME-Version: 1.0 Received: by 10.42.108.70 with SMTP id g6mr4763951icp.284.1309169672811; Mon, 27 Jun 2011 03:14:32 -0700 (PDT) Received: by 10.231.31.198 with HTTP; Mon, 27 Jun 2011 03:14:32 -0700 (PDT) Date: Mon, 27 Jun 2011 11:14:32 +0100 Message-ID: From: William Salt To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: 1gbit LFN WAN link - odd tcp behavior 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, 27 Jun 2011 10:41:20 -0000 Hi All, For the last couple of months i have been pulling my hair out trying to solve this problem. We have a 1Gbps transatlantic link from the UK to the US, which has successfully passed the RFC2544 test. At either end, we have a media converter, and a supermicro server with an intel quad port NIC running pfsense 2 (freebsd 8.1) with the NIC running on the yandex IGB driver. We can pass 1gbps either way with UDP. However we are experiencing very strange issues with tcp connections. With window scaling enabled, and a max socket buffer set to 16MB, we see no difference. Even disabling window scaling and setting the window to 16MB makes no difference. Each TCP connection starts very slowly, and will max out at around 190mbps, taking nearly 2 minutes to climb to this speed before *plateauing*. We have to initiate many (5+) connections to saturate the link with tcp connections with iperf. I have followed guides like this: http://www.psc.edu/networking/projects/tcptune/#FreeBSD With no luck, and have tweaked, disabled, and enabled nearly every relevant sysctl parameter with no luck. Can anyone shed some light on this? I am now doubting the IGB driver, and am looking to swap out the cards as a last ditch effort. However, we have tried different hardware (L3 switches, media convertes + laptops etc), and the symptoms still persist... The only constant is freebsd 8.1 (or 8.2 for production systems). Cheers in advance Will From owner-freebsd-net@FreeBSD.ORG Mon Jun 27 11:07:07 2011 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 C01461065674 for ; Mon, 27 Jun 2011 11:07:07 +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 AEFB08FC1B for ; Mon, 27 Jun 2011 11:07:07 +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 p5RB77We071907 for ; Mon, 27 Jun 2011 11:07:07 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p5RB774n071904 for freebsd-net@FreeBSD.org; Mon, 27 Jun 2011 11:07:07 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 27 Jun 2011 11:07:07 GMT Message-Id: <201106271107.p5RB774n071904@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, 27 Jun 2011 11:07:07 -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/158307 net [ip6] ipv6_pktinfo breaks IPV6_USE_MIN_MTU o kern/158156 net [bce] bce driver shows "no carrier" on IBM blade (HS22 f kern/157802 net [dummynet] [panic] kernel panic in dummynet o kern/157429 net [re] Realtek RTL8169 doesn't work with re(4) o kern/157418 net [em] em driver lockup during boot on Supermicro X9SCM- o kern/157410 net [ip6] IPv6 Router Advertisements Cause Excessive CPU U o kern/157287 net [re] [panic] INVARIANTS panic (Memory modified after f o kern/157209 net [ip6] [patch] locking error in rip6_input() (sys/netin o kern/157200 net [network.subr] [patch] stf(4) can not communicate betw o kern/157182 net [lagg] lagg interface not working together with epair o kern/156978 net [lagg][patch] Take lagg rlock before checking flags o kern/156877 net [dummynet] [panic] dummynet move_pkt() null ptr derefe o kern/156667 net [em] em0 fails to init on CURRENT after March 17 o kern/156408 net [vlan] Routing failure when using VLANs vs. Physical e o kern/156328 net [icmp]: host can ping other subnet but no have IP from o kern/156317 net [ip6] Wrong order of IPv6 NS DAD/MLD Report o kern/156283 net [ip6] [patch] nd6_ns_input - rtalloc_mpath does not re o kern/156279 net [if_bridge][divert][ipfw] unable to correctly re-injec o kern/156226 net [lagg]: failover does not announce the failover to swi o kern/156030 net [ip6] [panic] Crash in nd6_dad_start() due to null ptr o kern/155772 net ifconfig(8): ioctl (SIOCAIFADDR): File exists on direc o kern/155680 net [multicast] problems with multicast s kern/155642 net [request] Add driver for Realtek RTL8191SE/RTL8192SE W o kern/155604 net [flowtable] Flowtable excessively caches dest MAC addr o kern/155597 net [panic] Kernel panics with "sbdrop" message o kern/155585 net [tcp] [panic] tcp_output tcp_mtudisc loop until kernel o kern/155498 net [ral] ral(4) needs to be resynced with OpenBSD's to ga o kern/155420 net [vlan] adding vlan break existent vlan o bin/155365 net [patch] routed(8): if.c in routed fails to compile if o kern/155177 net [route] [panic] Panic when inject routes in kernel o kern/155030 net [igb] igb(4) DEVICE_POLLING does not work with carp(4) o kern/155010 net [msk] ntfs-3g via iscsi using msk driver cause kernel o kern/155004 net [bce] [panic] kernel panic in bce0 driver o kern/154943 net [gif] ifconfig gifX create on existing gifX clears IP s kern/154851 net [request]: Port brcm80211 driver from Linux to FreeBSD o kern/154850 net [netgraph] [patch] ng_ether fails to name nodes when t o kern/154831 net [arp] [patch] arp sysctl setting log_arp_permanent_mod o kern/154679 net [em] Fatal trap 12: "em1 taskq" only at startup (8.1-R o kern/154600 net [tcp] [panic] Random kernel panics on tcp_output o kern/154557 net [tcp] Freeze tcp-session of the clients, if in the gat o kern/154443 net [if_bridge] Kernel module bridgestp.ko missing after u o kern/154286 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/154255 net [nfs] NFS not responding o kern/154214 net [stf] [panic] Panic when creating stf interface o kern/154185 net race condition in mb_dupcl o kern/154169 net [multicast] [ip6] Node Information Query multicast add o kern/154134 net [ip6] stuck kernel state in LISTEN on ipv6 daemon whic o kern/154091 net [netgraph] [panic] netgraph, unaligned mbuf? o conf/154062 net [vlan] [patch] change to way of auto-generatation of v o kern/153937 net [ral] ralink panics the system (amd64 freeBSDD 8.X) wh o kern/153936 net [ixgbe] [patch] MPRC workaround incorrectly applied to o kern/153816 net [ixgbe] ixgbe doesn't work properly with the Intel 10g o kern/153772 net [ixgbe] [patch] sysctls reference wrong XON/XOFF varia o kern/153497 net [netgraph] netgraph panic due to race conditions o kern/153454 net [patch] [wlan] [urtw] Support ad-hoc and hostap modes o kern/153308 net [em] em interface use 100% cpu o kern/153244 net [em] em(4) fails to send UDP to port 0xffff o kern/152893 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/152853 net [em] tftpd (and likely other udp traffic) fails over e o kern/152828 net [em] poor performance on 8.1, 8.2-PRE o kern/152569 net [net]: Multiple ppp connections and routing table prob o kern/152235 net [arp] Permanent local ARP entries are not properly upd o kern/152141 net [vlan] [patch] encapsulate vlan in ng_ether before out o kern/151690 net [ep] network connectivity won't work until dhclient is 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 bin/150642 net netstat(1) doesn't print anything for SCTP sockets 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 bin/150224 net ppp(8) does not reassign static IP after kill -KILL co 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/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/149117 net [inet] [patch] in_pcbbind: redundant test o kern/149086 net [multicast] Generic multicast join failure in 8.1 o kern/148018 net [flowtable] flowtable crashes on ia64 o kern/147912 net [boot] FreeBSD 8 Beta won't boot on Thinkpad i1300 11 o kern/147894 net [ipsec] IPv6-in-IPv4 does not work inside an ESP-only o kern/147155 net [ip6] setfb not work with ipv6 o kern/146845 net [libc] close(2) returns error 54 (connection reset by f kern/146792 net [flowtable] flowcleaner 100% cpu's core load o kern/146719 net [pf] [panic] PF or dumynet kernel panic o kern/146534 net [icmp6] wrong source address in echo reply 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/145825 net [panic] panic: soabort: so_count o kern/145728 net [lagg] Stops working lagg between two servers. f kern/144917 net [flowtable] [panic] flowtable crashes system [regressi 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/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/144231 net bind/connect/sendto too strict about sockaddr length o kern/143939 net [ipfw] [em] ipfw nat and em interface rxcsum problem 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/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 kern/143034 net [panic] system reboots itself in tcp code [regression] 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 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/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/140346 net [wlan] High bandwidth use causes loss of wlan connecti 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 p kern/139204 net [arp] DHCP server replies rejected, ARP entry lost bef o kern/139117 net [lagg] + wlan boot timing (EBUSY) 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/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/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 p kern/137776 net [rum] panic in rum(4) driver on 8.0-BETA2 o bin/137641 net ifconfig(8): various problems with "vlan_device.vlan_i 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/136911 net [netgraph] [panic] system panic on kldload ng_bpf.ko t 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/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/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 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/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 kern/131601 net [ipfilter] [panic] 7-STABLE panic in nat_finalise (tcp o bin/131567 net [socket] [patch] Update for regression/sockets/unix_cm 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/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 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 p kern/127360 net [socket] TOE socket options missing from sosetopt() 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/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/126339 net [ipw] ipw driver drops the connection 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 f kern/125442 net [carp] [lagg] CARP combined with LAGG causes system pa 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/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 conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 f kern/123045 net [ng_mppc] ng_mppc_decompress - disabling node 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/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 s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net 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 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 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 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/111537 net [inet6] [patch] ip6_input() treats mbuf cluster wrong o kern/111457 net [ral] ral(4) freeze o kern/110284 net [if_ethersubr] Invalid Assumption in SIOCSIFADDR in et o kern/110249 net [kernel] [regression] [patch] setsockopt() error regre 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 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] 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 o kern/97306 net [netgraph] NG_L2TP locks after connection with failed o conf/97014 net [gif] gifconfig_gif? in rc.conf does not recognize IPv 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/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 p kern/85320 net [gre] [patch] possible depletion of kernel stack in ip 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 kern/82468 net Using 64MB tcp send/recv buffers, trafficflow stops, i 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 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/68889 net [panic] m_copym, length > size of mbuf chain 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/31940 net ip queue length too short for >500kpps 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 f kern/24959 net [patch] proper TCP_NOPUSH/TCP_CORK compatibility o conf/23063 net [arp] [patch] for static ARP tables in rc.network o kern/21998 net [socket] [patch] ident only for outgoing connections o kern/5877 net [socket] sb_cc counts control data as well as data dat 377 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Jun 27 11:17:05 2011 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 D1E211065678 for ; Mon, 27 Jun 2011 11:17:05 +0000 (UTC) (envelope-from matthias.andree@gmx.de) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by mx1.freebsd.org (Postfix) with SMTP id 5982F8FC0C for ; Mon, 27 Jun 2011 11:17:04 +0000 (UTC) Received: (qmail invoked by alias); 27 Jun 2011 11:17:03 -0000 Received: from g226238161.adsl.alicedsl.de (EHLO apollo.emma.line.org) [92.226.238.161] by mail.gmx.net (mp006) with SMTP; 27 Jun 2011 13:17:03 +0200 X-Authenticated: #428038 X-Provags-ID: V01U2FsdGVkX1/QRX8zmkXQoYdqE4tN/BW4Q0m0myNv4aC3wkBihN Fy3TQGTHOtVlPn Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by apollo.emma.line.org (Postfix) with ESMTP id 2217A23DAE4; Mon, 27 Jun 2011 13:17:02 +0200 (CEST) Message-ID: <4E0866AD.6010203@gmx.de> Date: Mon, 27 Jun 2011 13:17:01 +0200 From: Matthias Andree User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110516 Mnenhy/0.8.3 Thunderbird/3.1.10 MIME-Version: 1.0 To: Steven Hartland References: <9585F512F239475B8145C3D344F6EC62@multiplay.co.uk> <4E051576.7090505@gmx.de> <512CB9DD5802403BA3ACC48FE3AE63F5@multiplay.co.uk> In-Reply-To: <512CB9DD5802403BA3ACC48FE3AE63F5@multiplay.co.uk> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: freebsd-net@freebsd.org, freebsd-java@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: IPv4 socket bind using IPv6 socket on openjdk6 breaks udp send 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, 27 Jun 2011 11:17:06 -0000 Am 25.06.2011 13:28, schrieb Steven Hartland: > > ----- Original Message ----- From: "Matthias Andree" > > > I'm adding back in -java as based on you comments it may well be > something in the jdk passing invalid values down to the kernel > syscall. > >>> The socket bind works fine and the packets sent to the server arrive >>> and are processed by the app but when it tries to reply using >>> send the result is:- >>> java.io.IOException: Invalid argument >>> at java.net.PlainDatagramSocketImpl.send(Native Method) >>> at java.net.DatagramSocket.send(DatagramSocket.java:629) >>> >>> using truss we see the following:- >>> socket(PF_INET6,SOCK_DGRAM,0) = 20 (0x14) >>> setsockopt(0x14,0x29,0x1b,0x7ffffedf0318,0x4,0x0) = 0 (0x0) >>> setsockopt(0x14,0xffff,0x20,0x7ffffedf031c,0x4,0x0) = 0 (0x0) >>> bind(20,{ AF_INET6 [3800::10:0:0:0]:20736 },28) = 0 (0x0) >>> .. >>> sendto(20,"\M^?\M^?\M^?\M^?I\aMultiplay :: "...,82,0x0,{ AF_INET6 >>> [3800::10:0:0:0]:20736 },0x1c) ERR#22 'Invalid argument' >> >> You're trying to send to your own address, but you're likely not using >> the loopback interface for that. Is that permitted by your firewall >> configuration and routing? > > No I'm not its replying to the sender. Yes you are, check your trace: The sendto address and port are the same as the bound address. > In the java code we have:- > socket.send( new DatagramPacket( data, data.length, > src.getSocketAddress() ) ); > Where src is the src packet. This works fine on IPv4 only machines and > when the jdk is told to use only IPv4 stack. So its not a problem with > the java code itself but could well be an issue with the What data type is it? > >> >>> sockstat shows it binding correctly >>> root java 894 21 tcp4 85.236.109.212:25675 *:* >> >> This is unrelated, as it has fd #21 not #20 as in the socket/bind/sendto >> calls. You've quoted the wrong line from sockstat output. > > Oops sorry cut and paste error (wrong line) heres the correct line. > root java 894 20 udp4 85.236.109.212:25675 *:* While a datagram socket, it does not match the socket()/bind() above. An INET6-domain datagram socket would be listed as udp6 here. Are you sure you're tracing the right VM and are looking at the right thread? If so, is the incriminated traffic actually going through socket #20? Is src.getSocketAddress() actually returning an IPv6 address? SocketAddress is an abstract class. For my lack of Java knowledge: are there any automatic type promotions on the Java side? What's the Java code for binding to the socket and fetching the query packet? > The jvm automatically sets this on all sockets for compatibility for > this exact reason. I'm not rulling out an issue with the IPv6 -> v4 > routing in the kernel though. That is prohibited, so there isn't IPv6 -> IPv4 routing. All IPv6 traffic remains in the IPv6 domain. >> Are you sure that's what you seeing? It's not a match for what you give >> above, but anyways it's an implementation artifact because the tcp code >> for v4 and v6 used to be shared and the udp code separate. > > Thats not how the jdk works, its ment to be 100% transparent but isn't. You mean the JRE. >> It is best to set up one IPv4 and one IPv6 listening socket. > > I don't believe there is any way to do this in java it either uses the > IPv4 stack only or the IPv6 stack only hence relies on the kernel > routing IPv4 packets through the IPv6 stack. > > Thats the reason the jdk explicitly enables this for all the ports it > creates, which was added as a back port of the jdk7 fixes which can > be seen here:- > http://www.freebsd.org/cgi/cvsweb.cgi/ports/java/openjdk6/files/patch-set > >> Check the URL above, perhaps that helps your understanding a bit. I >> presume 3800::10:0:0:0 is your server? > > Not that I'm aware of, here's the output from ifconfig if anyone can > tell me different, as I'm new to IPv6 and don't follow how its mapped > yet. > > ifconfig > igb0: flags=8843 metric 0 mtu 1500 > > options=1bb > > ether 00:25:90:2c:3c:b0 > inet 85.236.109.212 netmask 0xffffff00 broadcast 85.236.109.255 > inet6 fe80::225:90ff:fe2c:3cb0%igb0 prefixlen 64 scopeid 0x1 > inet6 2001:4db0:20:2::1337 prefixlen 64 nd6 The 2001:something is your local address. If you bind to 3800:: something that won't work. You couldn't bind an IPv4 address of 10.9.8.7 on this interface either. > igb1: flags=8802 metric 0 mtu 1500 > > options=1bb > > ether 00:25:90:2c:3c:b1 > media: Ethernet autoselect (1000baseSX ) > status: active This iface has no addresses at IP level at all. > lo0: flags=8049 metric 0 mtu 16384 > options=3 > inet 127.0.0.1 netmask 0xff000000 > inet6 ::1 prefixlen 128 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 nd6 > options=3 Other than that, looks reasonable. There are link-local IPv6 addresses on igb0 and lo0, and there is a global IPv6 address on igb0. There is a routable IPv4 address on igb0, and the loopback address on lo0. That's OK, but an IPv6 bind could only ever use an address from 2001:4db0:20:2::/64, not 3800. Are you sure you're using the right address in bind()? It specifies the local sender address for transmitted datagrams... From owner-freebsd-net@FreeBSD.ORG Mon Jun 27 11:46:34 2011 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 0C50D1065672; Mon, 27 Jun 2011 11:46:34 +0000 (UTC) (envelope-from prvs=11594ac97a=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 289708FC18; Mon, 27 Jun 2011 11:46:32 +0000 (UTC) X-MDAV-Processed: mail1.multiplay.co.uk, Mon, 27 Jun 2011 12:34:40 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Mon, 27 Jun 2011 12:34:40 +0100 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-5.0 required=6.0 tests=USER_IN_WHITELIST shortcircuit=ham autolearn=disabled version=3.2.5 Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50013885737.msg; Mon, 27 Jun 2011 12:34:38 +0100 X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=11594ac97a=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: <01DA6DDBE3684C3785734F16008244E4@multiplay.co.uk> From: "Steven Hartland" To: "Matthias Andree" References: <9585F512F239475B8145C3D344F6EC62@multiplay.co.uk> <4E051576.7090505@gmx.de> <512CB9DD5802403BA3ACC48FE3AE63F5@multiplay.co.uk> <4E0866AD.6010203@gmx.de> Date: Mon, 27 Jun 2011 12:34:57 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6090 Cc: freebsd-net@freebsd.org, freebsd-java@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: IPv4 socket bind using IPv6 socket on openjdk6 breaks udp send 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, 27 Jun 2011 11:46:34 -0000 ----- Original Message ----- From: "Matthias Andree" >> No I'm not its replying to the sender. > > Yes you are, check your trace: The sendto address and port are the same > as the bound address. This is a bug in truss it seems, Bjoern said he's gonna have a look at it. Doesn't matter what you bind to it always reports this value in the truss output. >> In the java code we have:- >> socket.send( new DatagramPacket( data, data.length, >> src.getSocketAddress() ) ); >> Where src is the src packet. This works fine on IPv4 only machines and >> when the jdk is told to use only IPv4 stack. So its not a problem with >> the java code itself but could well be an issue with the > > What data type is it? All mute as the Bjoern found and fixed the issue, it was a bug in the kernel fixed by:- http://svnweb.freebsd.org/base?view=revision&revision=220463 >> Oops sorry cut and paste error (wrong line) heres the correct line. >> root java 894 20 udp4 85.236.109.212:25675 *:* > > While a datagram socket, it does not match the socket()/bind() above. > > An INET6-domain datagram socket would be listed as udp6 here. Are you > sure you're tracing the right VM and are looking at the right thread? Again, truss isn't showing the correct results, confused me too ;-) Possibly another bug in sockstat / netstat as well, when the socket is a IPv6 socket bound to an IPv4 address maybe it should indicate this e.g. udp6-4 instead of either udp4 or udp6; alternatively maybe udp6 + a IPv4 address is enough to indicate this, but that could cause confusion. Thanks for looking at this, appreciated :) Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-net@FreeBSD.ORG Mon Jun 27 11:50:18 2011 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 492FD1065700 for ; Mon, 27 Jun 2011 11:50:18 +0000 (UTC) (envelope-from michael.schuh@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 4C3A88FC0C for ; Mon, 27 Jun 2011 11:50:13 +0000 (UTC) Received: by iwr19 with SMTP id 19so5601799iwr.13 for ; Mon, 27 Jun 2011 04:50:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=KcI3MooGX5vM/G9ycYBRW2dM/k2C/chTA0/LA10X69c=; b=OQOiFpKFxSlOjabv6LOnOrLp+EGuUv+NnqBHafwyIDdbwZxkBBUGGrQi9qB8Cj6Zc0 I/KwHXoCZPl6iJ6k8eC8Jxlq/eWpbQunWvrqp3VopvWim+Qk2G2X0yTlOhxooFEhzkPW +6LJ6umD3cYg+8NtTG0ZTn1q6prnTPTHVr22g= 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=OWtAaaAsH4G8esPfljGOasPCMYBH2eZH4ivj4BZsUQU0DEnUPXcXTAMH89OMs0o8zO YCVYDC4lyOTxsNOXtzjRF5ZHYGAcdNnsPScGKkMqigca3OfUR7O/XTOrca23GP2i9VLC pidSXSK12dKZCff49P5zdW0lBeLfKJEj0PA4g= MIME-Version: 1.0 Received: by 10.231.73.138 with SMTP id q10mr6043250ibj.13.1309175411704; Mon, 27 Jun 2011 04:50:11 -0700 (PDT) Received: by 10.231.146.9 with HTTP; Mon, 27 Jun 2011 04:50:11 -0700 (PDT) In-Reply-To: <20110626211921.GA1629@michelle.cdnetworks.com> References: <20110626211921.GA1629@michelle.cdnetworks.com> Date: Mon, 27 Jun 2011 13:50:11 +0200 Message-ID: From: Michael Schuh To: pyunyh@gmail.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: FreeBSD Net Subject: Re: Kernel memory corruption(?) with age(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: Mon, 27 Jun 2011 11:50:18 -0000 2011/6/26 YongHyeon PYUN > On Sun, Jun 26, 2011 at 06:53:57AM +0200, Michael Schuh wrote: > > Hi, > > > > i am not on the list atm. > > > > i found this entry after digging in google during problems with a > normally > > rock stable > > system ( under linux). > > > > I can also confirm the behaviour from the first post. > > After a long hard night digging in the system and changing some options > > i found a repeatable way to crash the system ultrafast. > > > > at the initial crashes the system crashed after copying around 800GB. > > the second and third and further attempts/impacts got issued everytime > > after an ~ hour from reboot on. leaving the system withouth any power, > > changing some hardware > > forth and back didn't changed anything, except the network card. > > > > a happening beside that: immediatly after the initial boot will get the > > ntpdate and ntpd started. > > by this, the ntpd complains about unsresolveable hostnames from ntp.con= f. > > if you log in and restart the ntpd by hand, everything is fine, no > > complains, > > no unresolveable hostnames. > > the hostnames are well known and tested and the DNS works still fine. > > this happening will also leave if you change the Ethernet-adapter to an > > Intel Card. > > > > My system crashed so fast that i didn't got any log entry nor a > crashdump. > > > > my last try's crashed my system after 100 - 120 seconds. > > > > HW: AMD P5K with Atheros age-Interface enabled, 6GB Corsair DDR2 800MHZ > > (pc6400) RAM ( latency 5-5-5-5-18) > > Ati Radeon HD4350 with 512MB Onboard Memory, 3 disks 2 PATA, 1 SATA. > > > > OS: FreeBSD/amd64 8.2-RELEASE ( unmodified original RELEASE install ) > > > > REQUIREMENTS to repeat the issue: > > box A: a stable FreeBSD or Linux Box with GBitEthernet interface and no > > essential networkload > > box B: the affected FreeBSD Host with the age interface. > > > > the age0 interface is configured with default options. > > only the ip-configuration got applied through rc.conf > > > > ifconfig_age0=3D"192.168.1.3 netmask 255.255.255.0" > > > > PROCEDURE: > > On Box A ( p.e IP: 192.168.1.2 ) issue the command: > > > > # dd if=3D/dev/zero |nc -l -p 1666 > > > > On Box B issue a complementary command like: > > > > # nc 192.168.1.2 1666| dd of=3D/dev/null > > > > I am sorry i cannot test a patch at this time cause this is a backup > server, > > that has to get asap into production. > > After disabling the age-Interface in the bios settings and inserting a > Intel > > GBit NIC the System runs stable again. > > > > i hope this informations will help a bit. > > if you need to message me, please message me directly cause i am not > > registered for this list. > > > > I think the issue was already fixed(r220249, r220252). Apply the > patch and rebuild your kernel after downloading it from the > following URL. > > http://svnweb.freebsd.org/base/head/sys/dev/age/if_age.c?r1=3D219902&r2= =3D220252&view=3Dpatch > If you see the same issue again with this patch please let me know. > Many thanks for the patch. i will test him later. Just another question in relation to this: Got this patch applied to the stable branch? I plan to switch the system this week to stable. thanks again. --=20 =3D =3D =3D http://michael-schuh.net/ =3D =3D =3D Projektmanagement - IT-Consulting - Professional Services IT Michael Schuh Postfach 10 21 52 66021 Saarbr=FCcken phone: 0681/8319664 mobil: 0175/5616453 @: m i c h a e l . s c h u h @ g m a i l . c o m =3D =3D =3D Ust-ID: DE251072318 =3D =3D =3D From owner-freebsd-net@FreeBSD.ORG Mon Jun 27 12:18:10 2011 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 15C0C1065670 for ; Mon, 27 Jun 2011 12:18:10 +0000 (UTC) (envelope-from matthias.andree@gmx.de) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by mx1.freebsd.org (Postfix) with SMTP id 58D7E8FC17 for ; Mon, 27 Jun 2011 12:18:08 +0000 (UTC) Received: (qmail invoked by alias); 27 Jun 2011 12:18:07 -0000 Received: from g226238161.adsl.alicedsl.de (EHLO apollo.emma.line.org) [92.226.238.161] by mail.gmx.net (mp065) with SMTP; 27 Jun 2011 14:18:07 +0200 X-Authenticated: #428038 X-Provags-ID: V01U2FsdGVkX19tTZwXKiRtqchkisXbSrjBm0z266/OPgXCaKwECv oSijh2/+i7qHtS Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by apollo.emma.line.org (Postfix) with ESMTP id EEE6123CF8A; Mon, 27 Jun 2011 14:18:05 +0200 (CEST) Message-ID: <4E0874FD.506@gmx.de> Date: Mon, 27 Jun 2011 14:18:05 +0200 From: Matthias Andree User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110516 Mnenhy/0.8.3 Thunderbird/3.1.10 MIME-Version: 1.0 To: Steven Hartland References: <9585F512F239475B8145C3D344F6EC62@multiplay.co.uk> <4E051576.7090505@gmx.de> <512CB9DD5802403BA3ACC48FE3AE63F5@multiplay.co.uk> <4E0866AD.6010203@gmx.de> <01DA6DDBE3684C3785734F16008244E4@multiplay.co.uk> In-Reply-To: <01DA6DDBE3684C3785734F16008244E4@multiplay.co.uk> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: freebsd-net@freebsd.org, freebsd-java@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: IPv4 socket bind using IPv6 socket on openjdk6 breaks udp send 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, 27 Jun 2011 12:18:10 -0000 Just so we have pointers in the public archives: alternatives to truss are strace (in ports) and ktrace/kdump; and to obtain socket statistics, try lsof (from ports, too) possibly with -i and optionally -n and/or -P option. From owner-freebsd-net@FreeBSD.ORG Mon Jun 27 13:39:46 2011 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 AD5B8106564A for ; Mon, 27 Jun 2011 13:39:46 +0000 (UTC) (envelope-from adrian.chadd@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 67D598FC1E for ; Mon, 27 Jun 2011 13:39:46 +0000 (UTC) Received: by ywf7 with SMTP id 7so2479543ywf.13 for ; Mon, 27 Jun 2011 06:39:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=6I4HgM5S4TfB3ebj6AkGseKHXoWGRD0S6GL8PURzhXs=; b=T1v7xvxe2d8efGRCFJ2cQVFF1zCYWWIM9h1zSohYBBol9PSeugq2wvbjw6tvbRFInk xOGAyFC9rm9e8MyIEjHjWnWBhUgYlolhPMaaEWMUUVv8puQRdwhsNXA4xek3+NuTRbkW Q2f5HjXx2CPxPNNSyS22sbaTTP3U8TgvEHARc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=L3faCKTUATjMyehgl3OKSo8LOQg0dBPRYM7lSBY1WyVaTAlsQIBX7Kd8hoyvnQ5GOF IwFWNx5Pt0HCOqTOVKZ5Xp8+Zr4KnKfZTSa7jgkW4G5nTbgkmfeSxY8RnwUEpZcrbOPo QvWWMscmrFHGCPJjijrg23nFMvd7I1ei7JgBw= MIME-Version: 1.0 Received: by 10.150.236.3 with SMTP id j3mr6739434ybh.294.1309181985565; Mon, 27 Jun 2011 06:39:45 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.150.146.13 with HTTP; Mon, 27 Jun 2011 06:39:45 -0700 (PDT) In-Reply-To: References: Date: Mon, 27 Jun 2011 21:39:45 +0800 X-Google-Sender-Auth: DNuShXqB837kXDeAcZebjmGUmvk Message-ID: From: Adrian Chadd To: Patrick Lahni Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: iwn -CURRENT drivers on -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: Mon, 27 Jun 2011 13:39:46 -0000 On 27 June 2011 00:28, Patrick Lahni wrote: > Yea, that's what I just ended up doing. =A0Just purchased a AR9280 half-h= eight > mini pci-e to install on my itx board. =A0I'm hoping this will do what I = want > - dual band 11gn hostap (or at least just 11g hostap). =A0Live and learn. > Thanks for the input! It'll do 11g fine. It'll do 11n with -HEAD if you're feeling experimental and know what to disable (specifically, TX AMPDU.) Adrian From owner-freebsd-net@FreeBSD.ORG Mon Jun 27 16:24:08 2011 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 383A01065673 for ; Mon, 27 Jun 2011 16:24:08 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 05E7C8FC19 for ; Mon, 27 Jun 2011 16:24:07 +0000 (UTC) Received: by pzk27 with SMTP id 27so779429pzk.13 for ; Mon, 27 Jun 2011 09:24:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:date:to:cc:subject:message-id:reply-to :references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=TJipto7f9Pdn0xL6EVY/fyA73GOcC9xVdm9GV1exrWw=; b=ImiNhiXNMB5cxHkPrX+NaujrmUwF2bXAVUs1WahxIAUmSz6HAOXB2BCD+SmE4rcRHD ppUUJ8peTkTwEP2yh9QiL9XbbxhTAVl7ou5bEKps/TpQeO9Z7ziY5ZRiLiqmwg/7ohZA CttGABiJEIR/FfVhdvhi3xN0uyX6oZ+9MecCQ= 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=LEonZl3abusb/JLGECOXeLZnDj1KmJVh6ZToRp3OqFk0zBnhLHz3mAdknp9KTPTWVO eyiulI+MC/CRvOUJP/DulR5uuSgtBQbAGJy6HmMcVpSJJVvUFm6FzYx2+fXJCWLcdFVK O9wKwgDgT7ulsE4dubxI1Bj6wB7asGwlRpDYk= Received: by 10.142.249.41 with SMTP id w41mr1186508wfh.255.1309191847419; Mon, 27 Jun 2011 09:24:07 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id x2sm4409256pbn.77.2011.06.27.09.24.04 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 27 Jun 2011 09:24:05 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Mon, 27 Jun 2011 09:23:11 -0700 From: YongHyeon PYUN Date: Mon, 27 Jun 2011 09:23:11 -0700 To: Michael Schuh Message-ID: <20110627162311.GA1652@michelle.cdnetworks.com> References: <20110626211921.GA1629@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 Subject: Re: Kernel memory corruption(?) with age(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: Mon, 27 Jun 2011 16:24:08 -0000 On Mon, Jun 27, 2011 at 01:50:11PM +0200, Michael Schuh wrote: > 2011/6/26 YongHyeon PYUN > > > On Sun, Jun 26, 2011 at 06:53:57AM +0200, Michael Schuh wrote: > > > Hi, > > > > > > i am not on the list atm. > > > > > > i found this entry after digging in google during problems with a > > normally > > > rock stable > > > system ( under linux). > > > > > > I can also confirm the behaviour from the first post. > > > After a long hard night digging in the system and changing some options > > > i found a repeatable way to crash the system ultrafast. > > > > > > at the initial crashes the system crashed after copying around 800GB. > > > the second and third and further attempts/impacts got issued everytime > > > after an ~ hour from reboot on. leaving the system withouth any power, > > > changing some hardware > > > forth and back didn't changed anything, except the network card. > > > > > > a happening beside that: immediatly after the initial boot will get the > > > ntpdate and ntpd started. > > > by this, the ntpd complains about unsresolveable hostnames from ntp.conf. > > > if you log in and restart the ntpd by hand, everything is fine, no > > > complains, > > > no unresolveable hostnames. > > > the hostnames are well known and tested and the DNS works still fine. > > > this happening will also leave if you change the Ethernet-adapter to an > > > Intel Card. > > > > > > My system crashed so fast that i didn't got any log entry nor a > > crashdump. > > > > > > my last try's crashed my system after 100 - 120 seconds. > > > > > > HW: AMD P5K with Atheros age-Interface enabled, 6GB Corsair DDR2 800MHZ > > > (pc6400) RAM ( latency 5-5-5-5-18) > > > Ati Radeon HD4350 with 512MB Onboard Memory, 3 disks 2 PATA, 1 SATA. > > > > > > OS: FreeBSD/amd64 8.2-RELEASE ( unmodified original RELEASE install ) > > > > > > REQUIREMENTS to repeat the issue: > > > box A: a stable FreeBSD or Linux Box with GBitEthernet interface and no > > > essential networkload > > > box B: the affected FreeBSD Host with the age interface. > > > > > > the age0 interface is configured with default options. > > > only the ip-configuration got applied through rc.conf > > > > > > ifconfig_age0="192.168.1.3 netmask 255.255.255.0" > > > > > > PROCEDURE: > > > On Box A ( p.e IP: 192.168.1.2 ) issue the command: > > > > > > # dd if=/dev/zero |nc -l -p 1666 > > > > > > On Box B issue a complementary command like: > > > > > > # nc 192.168.1.2 1666| dd of=/dev/null > > > > > > I am sorry i cannot test a patch at this time cause this is a backup > > server, > > > that has to get asap into production. > > > After disabling the age-Interface in the bios settings and inserting a > > Intel > > > GBit NIC the System runs stable again. > > > > > > i hope this informations will help a bit. > > > if you need to message me, please message me directly cause i am not > > > registered for this list. > > > > > > > I think the issue was already fixed(r220249, r220252). Apply the > > patch and rebuild your kernel after downloading it from the > > following URL. > > > > http://svnweb.freebsd.org/base/head/sys/dev/age/if_age.c?r1=219902&r2=220252&view=patch > > If you see the same issue again with this patch please let me know. > > > > Many thanks for the patch. > i will test him later. > > Just another question in relation to this: > Got this patch applied to the stable branch? The patch is for 8.2-RELEASE or 7.4-RELEASE. > I plan to switch the system this week to stable. > You don't have to apply the patch to stable/8. The patch was already merged to both stable/8 and stable/7. > thanks again. From owner-freebsd-net@FreeBSD.ORG Mon Jun 27 16:52:49 2011 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 C0C56106566B for ; Mon, 27 Jun 2011 16:52:49 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 8C73E8FC13 for ; Mon, 27 Jun 2011 16:52:49 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id E8A3773027; Mon, 27 Jun 2011 19:09:25 +0200 (CEST) Date: Mon, 27 Jun 2011 19:09:25 +0200 From: Luigi Rizzo To: net@freebsd.org Message-ID: <20110627170925.GA2920@onelab2.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: Subject: RTL8169 (if_re) poor tx packet rate ? 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, 27 Jun 2011 16:52:49 -0000 Asking just in case someone has experience on the sending rate with Realtek 8168/8169/8110 Gbit cards. On the receive side, using netmap, even with the CPU at 200 MHz the card seems able to receive 1.38 Mpps (the most i can generate with my other, intel 1 Gbit/s cards). But on the receive side the most i get is 370 Kpps (with 64-byte packets), and achieve slightly faster speeds (390Kpps) only sending shorter frames (16 bytes) and relying on the padding inserted by the card. Even the standard drivers reach similar speeds (in the 300Kpps range). I have tried to change several configuration parameters in the NIC settings (tx dma threshold, mitigation, checked the inter-packet gap, increasing the ring size to 1024) but they seem to have no effect. The only improvement (but a very modest one) is if i use the "high priority" tx ring instead of the regular one -- then speed goes up from 365 to 370 Kpps (very reproducible). At much larger packet sizes (1024 and above) the card does line rate with no problems. Has anyone tried to push these cards at high speed, or do you have suggestions on what to try ? cheers luigi http://info.iet.unipi.it/~luigi/netmap/ From owner-freebsd-net@FreeBSD.ORG Mon Jun 27 17:22:12 2011 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 EDB44106564A; Mon, 27 Jun 2011 17:22:12 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id C6B3A8FC0C; Mon, 27 Jun 2011 17:22:12 +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 p5RHMCsh026464; Mon, 27 Jun 2011 17:22:12 GMT (envelope-from hrs@freefall.freebsd.org) Received: (from hrs@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p5RHMCx0026460; Mon, 27 Jun 2011 17:22:12 GMT (envelope-from hrs) Date: Mon, 27 Jun 2011 17:22:12 GMT Message-Id: <201106271722.p5RHMCx0026460@freefall.freebsd.org> To: hrs@FreeBSD.org, freebsd-net@FreeBSD.org, hrs@FreeBSD.org From: hrs@FreeBSD.org Cc: Subject: Re: kern/158307: [ip6] ipv6_pktinfo breaks IPV6_USE_MIN_MTU 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, 27 Jun 2011 17:22:13 -0000 Synopsis: [ip6] ipv6_pktinfo breaks IPV6_USE_MIN_MTU Responsible-Changed-From-To: freebsd-net->hrs Responsible-Changed-By: hrs Responsible-Changed-When: Mon Jun 27 17:21:52 UTC 2011 Responsible-Changed-Why: I'll take this. http://www.freebsd.org/cgi/query-pr.cgi?pr=158307 From owner-freebsd-net@FreeBSD.ORG Mon Jun 27 20:50:15 2011 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 EC1B9106566C for ; Mon, 27 Jun 2011 20:50:15 +0000 (UTC) (envelope-from gygy@stsnet.ro) Received: from mail.stsnet.ro (mail.stsnet.ro [193.151.31.253]) by mx1.freebsd.org (Postfix) with ESMTP id A56C88FC17 for ; Mon, 27 Jun 2011 20:50:15 +0000 (UTC) Received: from mail.stsnet.ro (localhost.localdomain [127.0.0.1]) by mail.stsnet.ro (Postfix) with ESMTP id 449E54BBB2 for ; Mon, 27 Jun 2011 23:50:09 +0300 (EEST) Received: from localhost.localdomain [127.0.0.1] by BitDefender SMTP Proxy on localhost.localdomain [127.0.0.1] for localhost.localdomain [127.0.0.1]; Mon, 27 Jun 2011 23:50:09 +0300 (EEST) Received: from mail.stsnet.ro (localhost.localdomain [127.0.0.1]) (Authenticated sender: gygy) by mail.stsnet.ro (Postfix) with ESMTPA id 188904BBB1 for ; Mon, 27 Jun 2011 23:50:09 +0300 (EEST) Received: from 188.26.159.198 (SquirrelMail authenticated user gygy) by mail.stsnet.ro with HTTP; Mon, 27 Jun 2011 23:50:09 +0300 Message-ID: <4d705cd0d73fb0d25cc3a017eb2eb072.squirrel@mail.stsnet.ro> Date: Mon, 27 Jun 2011 23:50:09 +0300 From: "Adrian Minta" To: freebsd-net@freebsd.org User-Agent: SquirrelMail/1.4.20 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-BitDefender-Spam: No (0) X-BitDefender-SpamStamp: v1, build 2.8.97.166311, SQMD Hits: none, bayes score: 500(0), pbayes score: 237(0), neunet score: 0(0), SQMD: 0e44558a7e67bcaf4d2fbf246fc1f56d.fuzzy.fzrbl.org, total: 0(775) X-BitDefender-CF-Stamp: none X-BitDefender-Scanner: Clean, Agent: BitDefender Smtp Proxy 3.1.0 on mail.stsnet.ro, sigver: 7.38072 Subject: Re: FreeBSD 8.2 and MPD5 stability issues 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, 27 Jun 2011 20:50:16 -0000 Thanks to Vlad Galu I was able to acquire a full crashinfo and kernel dump after a system freeze. I put all the files at: http://pluto.stsisp.ro/fbsd/ I hope this will help somebody in finding the race condition. From owner-freebsd-net@FreeBSD.ORG Tue Jun 28 00:40:13 2011 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 0D514106567E for ; Tue, 28 Jun 2011 00:40:13 +0000 (UTC) (envelope-from wxs@atarininja.org) Received: from syn.atarininja.org (syn.csh.rit.edu [129.21.49.45]) by mx1.freebsd.org (Postfix) with ESMTP id BA68D8FC0C for ; Tue, 28 Jun 2011 00:40:12 +0000 (UTC) Received: by syn.atarininja.org (Postfix, from userid 1001) id C451F5C3A; Mon, 27 Jun 2011 20:25:56 -0400 (EDT) Date: Mon, 27 Jun 2011 20:25:56 -0400 From: Wesley Shields To: freebsd-net@FreeBSD.org Message-ID: <20110628002556.GA87130@atarininja.org> References: <201105192153.p4JLrvtH004172@red.freebsd.org> <20110521064847.GB23992@lonesome.com> <20110522193007.GA63178@atarininja.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110522193007.GA63178@atarininja.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Subject: Re: fwd: kern/157188: [libpcap] [patch] incorporate patch from upstream 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, 28 Jun 2011 00:40:13 -0000 I'm still hoping someone who cares about IPv6 is willing to commit this fix for libpcap in the base before 9.0. Is anyone willing to tackle this? It's been in the port for a while now, and in upstream for even longer. -- WXS On Sun, May 22, 2011 at 03:30:07PM -0400, Wesley Shields wrote: > I've updated the port to address this. The audit trail for this PR has a > patch which touches more than just libpcap. I'm curious if anyone on > this list has comments on it, and if any committer wants to commit it > (at least the libpcap part, the others appear right to me). > > -- WXS > > On Sat, May 21, 2011 at 01:48:47AM -0500, Mark Linimon wrote: > > Apparently affects both the port and src. > > mcl > > > > On Thu, May 19, 2011 at 09:53:57PM +0000, Peter Losher wrote: > > > > > > >Number: 157188 > > > >Category: misc > > > >Synopsis: libpcap > > > >Confidential: no > > > >Severity: non-critical > > > >Priority: medium > > > >Responsible: freebsd-bugs > > > >State: open > > > >Quarter: > > > >Keywords: > > > >Date-Required: > > > >Class: sw-bug > > > >Submitter-Id: current-users > > > >Arrival-Date: Thu May 19 22:00:27 UTC 2011 > > > >Closed-Date: > > > >Last-Modified: > > > >Originator: Peter Losher > > > >Release: 8.2-RELEASE > > > >Organization: > > > Internet Systems Consortium > > > >Environment: > > > FreeBSD freebsd8.lab.isc.org 8.2-RELEASE FreeBSD 8.2-RELEASE #0: Thu Feb 17 02:41:51 UTC 2011 root@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 > > > >Description: > > > One of our engineers @ISC discovered that there is a bug in the currently released version of libpcap (in base and in ports) that can be triggered when using an "ip6 protochain" filter. It's due to the fairly complicated BPF bytecode that libpcap generates for IPv6 header chasing combined with a sign extension bug when processing JA (jump absolute) opcodes. (JA is used to go backwards and without sign extension on 64 bit platforms the BPF interpreter incorrectly jumps forward... a lot.) > > > > > > >How-To-Repeat: > > > root@freebsd8:~# tcpdump -nr ip6-hopbyhop-icmp.pcap 'ip6 protochain 58' > > > reading from file ip6-hopbyhop-icmp.pcap, link-type EN10MB (Ethernet) > > > Segmentation fault: 11 (core dumped) > > > > > > >Fix: > > > There is a fix in the libpcap repository: > > > > > > https://github.com/mcr/libpcap/commit/ecdc5c0a7f7591a7cd4aff696e42757c677fbbf7 > > > > > > but the tcpdump-workers have been pretty tardy about putting out newer code, so it sits there stalled. > > > > > > With the patch applied, it all works well and you should see something like this: > > > > > > -=- > > > $ tcpdump -nr ip6-hopbyhop-icmp.pcap 'ip6 protochain 58' > > > reading from file ip6-hopbyhop-icmp.pcap, link-type EN10MB (Ethernet) > > > 18:43:07.098489 IP6 fe80::208:7dff:feb7:2cca > ff02::1: HBH ICMP6, multicast listener queryv2 [gaddr ::], length 28 > > > -=- > > > > > > >Release-Note: > > > >Audit-Trail: > > > >Unformatted: > > > _______________________________________________ > > > freebsd-bugs@freebsd.org mailing list > > > http://lists.freebsd.org/mailman/listinfo/freebsd-bugs > > > To unsubscribe, send any mail to "freebsd-bugs-unsubscribe@freebsd.org" > _______________________________________________ > 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 Jun 28 13:09:06 2011 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 4CE68106566C for ; Tue, 28 Jun 2011 13:09:06 +0000 (UTC) (envelope-from benoit.panizzon@imp.ch) Received: from godot.imp.ch (godot.imp.ch [157.161.4.8]) by mx1.freebsd.org (Postfix) with ESMTP id B237E8FC16 for ; Tue, 28 Jun 2011 13:09:05 +0000 (UTC) Received: from go.imp.ch (go.imp.ch [IPv6:2001:4060:1:4133:20f:1fff:fe7d:d3da]) by godot.imp.ch (8.14.1/8.14.1) with ESMTP id p5S9mbn3005705 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 28 Jun 2011 11:48:37 +0200 (CEST) (envelope-from benoit.panizzon@imp.ch) From: Benoit Panizzon Organization: ImproWare AG To: freebsd-net@freebsd.org Date: Tue, 28 Jun 2011 11:48:34 +0200 User-Agent: KMail/1.9.9 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart6617720.nWCGMWR6Ov"; protocol="application/pkcs7-signature"; micalg=sha1 Content-Transfer-Encoding: 7bit Message-Id: <201106281148.36754.benoit.panizzon@imp.ch> X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: udp checksum implementation error in FreeBSD 7.2? 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, 28 Jun 2011 13:09:06 -0000 --nextPart6617720.nWCGMWR6Ov Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi We are running a DHCP Server on a FreeBSD 7.2-RELEASE-p4 box. This works for most of our customers, except ones with some kind of SonicWa= ll=20 =46irewalls. We have analyzed the problem with the sonicwall tech support: We found the problem being in the sonicwall setting a UDP checksum of 0x000= 0=20 for DHCP Requests. According to the RFC this is a valid value and tells the receiving UDP stac= k=20 not to check the checksum: http://www.faqs.org/rfcs/rfc768.html If the value is different from 0x0000 the receiving UDP stack can perform a= =20 checksum check and if this fails, silently drop that packet. What we observe is: DHCP Request with UDP checksum set =3D> Packet reaches DHCP Daemon and is b= eing=20 answered. DHCP Request with UDP checksum 0x0000 =3D> ICMP Port Unreachable from FreeB= SD. Can someone confirm this non RFC conform behaviour and knows how to fix it? As I understand, setting net.inet.udp.checksum to zero would not fix the=20 problem, as this is only for packet generation. Kind regards Benoit Panizzon =2D-=20 I m p r o W a r e A G - =20 ______________________________________________________ Zurlindenstrasse 29 Tel +41 61 826 93 07 CH-4133 Pratteln Fax +41 61 826 93 02 Schweiz Web http://www.imp.ch ______________________________________________________ --nextPart6617720.nWCGMWR6Ov-- From owner-freebsd-net@FreeBSD.ORG Tue Jun 28 14:24:37 2011 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 E61BC1065670 for ; Tue, 28 Jun 2011 14:24:37 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id A57B68FC1A for ; Tue, 28 Jun 2011 14:24:37 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap0EAELjCU6DaFvO/2dsb2JhbABShEmjb7kPkTSBK4N5gQwEkhCQPQ X-IronPort-AV: E=Sophos;i="4.65,437,1304308800"; d="scan'208";a="125415334" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 28 Jun 2011 10:24:36 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id C1723B3F05; Tue, 28 Jun 2011 10:24:36 -0400 (EDT) Date: Tue, 28 Jun 2011 10:24:36 -0400 (EDT) From: Rick Macklem To: Benoit Panizzon Message-ID: <1658896945.9968.1309271076776.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <201106281148.36754.benoit.panizzon@imp.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.201] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - IE7 (Win)/6.0.10_GA_2692) Cc: freebsd-net@freebsd.org Subject: Re: udp checksum implementation error in FreeBSD 7.2? 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, 28 Jun 2011 14:24:38 -0000 Benoit Panizzon wrote: > Hi > > We are running a DHCP Server on a FreeBSD 7.2-RELEASE-p4 box. > > This works for most of our customers, except ones with some kind of > SonicWall > Firewalls. We have analyzed the problem with the sonicwall tech > support: > > We found the problem being in the sonicwall setting a UDP checksum of > 0x0000 > for DHCP Requests. > > According to the RFC this is a valid value and tells the receiving UDP > stack > not to check the checksum: > > http://www.faqs.org/rfcs/rfc768.html > > If the value is different from 0x0000 the receiving UDP stack can > perform a > checksum check and if this fails, silently drop that packet. > > What we observe is: > > DHCP Request with UDP checksum set => Packet reaches DHCP Daemon and > is being > answered. > DHCP Request with UDP checksum 0x0000 => ICMP Port Unreachable from > FreeBSD. > > Can someone confirm this non RFC conform behaviour and knows how to > fix it? > Well, I took a quick look at the sources (which are in sys/netinet/udp_usrreq.c in a function called udp_input() at about line#300) and it only does the checksum if it is non-zero. It looks like: if (uh->uh_sum) { ....do checksum (If you don't have kernel sources handy, you can find them here: http://svn.freebsd.org/viewvc/base/releng/7.2) So, I have no idea why the packet without the checksum doesn't make it through, but it doesn't appear to be because the checksum field is set to 0. In fact, if you do "netstat -s", you should see the count for UDP packets with no checksum increase as it receives them. If this count isn't increaing when the request with checksum == 0x0000 is being sent to the FreeBSD box, it isn't getting as far as the udp checksum calculation. (The code fails a UDP packet with a 0 destination port#, for example.) Or maybe your network hardware is trying to do the checksum and then dropping the packet? Look at "ifconfig -a" and if RXCSUM is enabled, you could try disabling it with "-rxcsum" on the ifconfig command line. Otherwise, all I can suggest is good old fashioned printf()s in the udp_input() function to try and figure out why the packet is being dropped? (Oh, this assumes you've already looked at the packet via wireshark or tcpdump to make sure that the UDP packet looks ok otherwise when it has the checksum == 0x0000.) > As I understand, setting net.inet.udp.checksum to zero would not fix > the > problem, as this is only for packet generation. > Yes, the code shouldn't ever try and calculate a UDP checksum when it's 0 in the packet. Maybe others have better suggestions, rick From owner-freebsd-net@FreeBSD.ORG Tue Jun 28 15:46:30 2011 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 E6F7C1065673 for ; Tue, 28 Jun 2011 15:46:30 +0000 (UTC) (envelope-from d.banschikov@peterhost.ru) Received: from fb0.z8.ru (fb0.z8.ru [80.93.62.38]) by mx1.freebsd.org (Postfix) with ESMTP id 7D5368FC18 for ; Tue, 28 Jun 2011 15:46:30 +0000 (UTC) Received: from smtp.z8.ru ([80.93.62.30]) by fb0.z8.ru with esmtp (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QbaGH-000NcZ-GK for freebsd-net@freebsd.org; Tue, 28 Jun 2011 19:31:37 +0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=peterhost.ru; s=y2011-v1; h=Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=jmJIE7M2ml6MTyX05mbhRwVoLAlBmTB0/RI+srELwyA=; b=W661ONq7SFSTl3eyC3sL7nqxfUvR5RVbAb5EJyZmc0H/ccEOBD6x8RAxHuX3hJ1WoxvHJZQrF6NLm8xxDV6ICBjRa3b1zbRl3Nfta0dPTs+jhPnwVXBCURyLrK38Dj4QxnJofmStRBlOyyqBqt7GlYdrFwBqmv1lwWBZ666NbN0=; Received: from [212.116.101.94] (helo=[10.10.32.3]) by smtp.z8.ru with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1QbaGE-000ORm-QZ for freebsd-net@freebsd.org; Tue, 28 Jun 2011 19:31:34 +0400 Message-ID: <4E09F3D6.3060206@peterhost.ru> Date: Tue, 28 Jun 2011 19:31:34 +0400 From: Dmitry Banschikov User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110307 Icedove/3.0.11 MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <201106281148.36754.benoit.panizzon@imp.ch> In-Reply-To: <201106281148.36754.benoit.panizzon@imp.ch> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030206000303050501000706" X-SA-Exim-Connect-IP: 212.116.101.94 X-SA-Exim-Mail-From: d.banschikov@peterhost.ru X-SA-Exim-Scanned: No (on smtp.z8.ru); SAEximRunCond expanded to false X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: udp checksum implementation error in FreeBSD 7.2? 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, 28 Jun 2011 15:46:31 -0000 This is a cryptographically signed message in MIME format. --------------ms030206000303050501000706 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 28.06.2011 13:48, Benoit Panizzon wrote: > Hi > > We are running a DHCP Server on a FreeBSD 7.2-RELEASE-p4 box. > > This works for most of our customers, except ones with some kind of Son= icWall > Firewalls. We have analyzed the problem with the sonicwall tech support= : > > We found the problem being in the sonicwall setting a UDP checksum of 0= x0000 > for DHCP Requests. > > According to the RFC this is a valid value and tells the receiving UDP = stack > not to check the checksum: > > http://www.faqs.org/rfcs/rfc768.html > > If the value is different from 0x0000 the receiving UDP stack can perfo= rm a > checksum check and if this fails, silently drop that packet. > > What we observe is: > > DHCP Request with UDP checksum set =3D> Packet reaches DHCP Daemon and= is being > answered. > DHCP Request with UDP checksum 0x0000 =3D> ICMP Port Unreachable from = FreeBSD. > > Can someone confirm this non RFC conform behaviour and knows how to fix= it? > > As I understand, setting net.inet.udp.checksum to zero would not fix th= e > problem, as this is only for packet generation. DHCP (isc-dhcp) uses bpf(4) device for reading and writing dhcp packets. = Since bpf(4) device provides raw access to ether frames, udp checksum=20 calculation must take place in the dhcp server code. You could use=20 ktrace(1) if you want to make sure that a icmp packet is generated by=20 the dhcp server. Also, you have said that icmp error message is port=20 unreachable, that means, that there is no any udp socket which listens=20 on 67 port. Can you check if dhcp-server listens on 67-udp port and=20 there is no any firewall rules, which forbids udp packet to 67 port? --=20 Dmitry Banschikov --------------ms030206000303050501000706-- From owner-freebsd-net@FreeBSD.ORG Tue Jun 28 18:06:17 2011 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 1B5F1106564A for ; Tue, 28 Jun 2011 18:06:17 +0000 (UTC) (envelope-from rs@netapp.com) Received: from mx3.netapp.com (mx3.netapp.com [217.70.210.9]) by mx1.freebsd.org (Postfix) with ESMTP id A61F48FC12 for ; Tue, 28 Jun 2011 18:06:16 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.65,438,1304319600"; d="scan'208";a="261836177" Received: from smtp3.europe.netapp.com ([10.64.2.67]) by mx3-out.netapp.com with ESMTP; 28 Jun 2011 11:06:14 -0700 Received: from ldcrsexc1-prd.hq.netapp.com (ldcrsexc1-prd.hq.netapp.com [10.65.251.109]) by smtp3.europe.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id p5SI6EYh016273; Tue, 28 Jun 2011 11:06:14 -0700 (PDT) Received: from LDCMVEXC1-PRD.hq.netapp.com ([10.65.251.108]) by ldcrsexc1-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Jun 2011 19:06:15 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 28 Jun 2011 19:06:10 +0100 Message-ID: <5FDC413D5FA246468C200652D63E627A0F014ED7@LDCMVEXC1-PRD.hq.netapp.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 1gbit LFN WAN link - odd tcp behavior Thread-Index: Acw0tvt/hyqWdAytQ5iuuA7lBeX37gBBuO0A References: From: "Scheffenegger, Richard" To: "William Salt" X-OriginalArrivalTime: 28 Jun 2011 18:06:15.0052 (UTC) FILETIME=[1217F4C0:01CC35BE] Cc: freebsd-net@freebsd.org Subject: RE: 1gbit LFN WAN link - odd tcp behavior 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, 28 Jun 2011 18:06:17 -0000 What is the effective latency under load, and the packet loss probability? Just to add some more detail. Richard Scheffenegger > -----Original Message----- > From: William Salt [mailto:williamejsalt@googlemail.com] > Sent: Montag, 27. Juni 2011 12:15 > To: freebsd-net@freebsd.org > Subject: 1gbit LFN WAN link - odd tcp behavior >=20 > Hi All, > For the last couple of months i have been pulling my hair out > trying to solve this problem. > We have a 1Gbps transatlantic link from the UK to the US, which has > successfully passed the RFC2544 test. >=20 > At either end, we have a media converter, and a supermicro server with > an > intel quad port NIC running pfsense 2 (freebsd 8.1) with the NIC > running on > the yandex IGB driver. >=20 > We can pass 1gbps either way with UDP. However we are experiencing very > strange issues with tcp connections. >=20 > With window scaling enabled, and a max socket buffer set to 16MB, we > see no > difference. > Even disabling window scaling and setting the window to 16MB makes no > difference. >=20 > Each TCP connection starts very slowly, and will max out at around > 190mbps, > taking nearly 2 minutes to climb to this speed before *plateauing*. >=20 > We have to initiate many (5+) connections to saturate the link with tcp > connections with iperf. >=20 > I have followed guides like this: > http://www.psc.edu/networking/projects/tcptune/#FreeBSD >=20 > With no luck, and have tweaked, disabled, and enabled nearly every > relevant > sysctl parameter with no luck. >=20 > Can anyone shed some light on this? >=20 > I am now doubting the IGB driver, and am looking to swap out the cards > as a > last ditch effort. > However, we have tried different hardware (L3 switches, media convertes > + > laptops etc), and the symptoms still persist... > The only constant is freebsd 8.1 (or 8.2 for production systems). >=20 >=20 > Cheers in advance > Will > _______________________________________________ > 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 Jun 28 18:44:42 2011 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 48DB8106564A for ; Tue, 28 Jun 2011 18:44:42 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1-6.sentex.ca [IPv6:2607:f3e0:0:1::12]) by mx1.freebsd.org (Postfix) with ESMTP id 0DEAB8FC19 for ; Tue, 28 Jun 2011 18:44:41 +0000 (UTC) Received: from [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a] (saphire3.sentex.ca [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a]) by smarthost1.sentex.ca (8.14.4/8.14.4) with ESMTP id p5SIidLV012955; Tue, 28 Jun 2011 14:44:40 -0400 (EDT) (envelope-from mike@sentex.net) Message-ID: <4E0A210F.7050105@sentex.net> Date: Tue, 28 Jun 2011 14:44:31 -0400 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Adrian Minta References: <4d705cd0d73fb0d25cc3a017eb2eb072.squirrel@mail.stsnet.ro> In-Reply-To: <4d705cd0d73fb0d25cc3a017eb2eb072.squirrel@mail.stsnet.ro> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on IPv6:2607:f3e0:0:1::12 Cc: freebsd-net@freebsd.org Subject: Re: FreeBSD 8.2 and MPD5 stability issues 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, 28 Jun 2011 18:44:42 -0000 On 6/27/2011 4:50 PM, Adrian Minta wrote: > Thanks to Vlad Galu I was able to acquire a full crashinfo and kernel dump > after a system freeze. I put all the files at: > http://pluto.stsisp.ro/fbsd/ > > I hope this will help somebody in finding the race condition. Dont know about the race, but one thing I would get rid of in your kernel config is the FLOWTABLE option as it has a few bugs still Also get rid of device gre device tap # Bridging device if_bridge device lagg if you are not using them Are you loading any klds ? Why the linux.ko and linprocfs.ko ? If you dont use it, get rid of it. I would also not run snmpd and disable devd as they will do a lot of work traversing all those interfaces. Also, how come your nics all show no carrier in the crash dump ? ---Mike > > > > _______________________________________________ > 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" > > -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-net@FreeBSD.ORG Tue Jun 28 19:09:11 2011 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 96C21106566C for ; Tue, 28 Jun 2011 19:09:11 +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 EC7888FC1A for ; Tue, 28 Jun 2011 19:09:10 +0000 (UTC) Received: (qmail 2808 invoked from network); 28 Jun 2011 19:09:09 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 28 Jun 2011 19:09:09 -0000 Date: Tue, 28 Jun 2011 21:09:09 +0200 (CEST) Message-Id: <20110628.210909.74655931.sthaug@nethelp.no> To: benoit.panizzon@imp.ch From: sthaug@nethelp.no In-Reply-To: <1658896945.9968.1309271076776.JavaMail.root@erie.cs.uoguelph.ca> References: <201106281148.36754.benoit.panizzon@imp.ch> <1658896945.9968.1309271076776.JavaMail.root@erie.cs.uoguelph.ca> 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 Cc: freebsd-net@freebsd.org Subject: Re: udp checksum implementation error in FreeBSD 7.2? 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, 28 Jun 2011 19:09:11 -0000 > > What we observe is: > > > > DHCP Request with UDP checksum set => Packet reaches DHCP Daemon and > > is being > > answered. > > DHCP Request with UDP checksum 0x0000 => ICMP Port Unreachable from > > FreeBSD. > > > > Can someone confirm this non RFC conform behaviour and knows how to > > fix it? > > > Well, I took a quick look at the sources (which are in sys/netinet/udp_usrreq.c > in a function called udp_input() at about line#300) and it only does the > checksum if it is non-zero. It looks like: > if (uh->uh_sum) { > ....do checksum > (If you don't have kernel sources handy, you can find them here: > http://svn.freebsd.org/viewvc/base/releng/7.2) As another poster commented, ISC dhcpd by default uses BPF, *not* the kernel UDP implementation - this is done to be able to handle broadcast packets. However, the mystery doesn't end here - because the ISC dhcpd implementation *also* only cares about UDP packets with a non-zero checksum. The code is in common/packet.c, routine decode_udp_ip_header() which is used by BPF and other link level access methods (e.g. DLPI on Solaris). From dhcp-4.2.0-P2/common/packet.c: ---------------------------------------------------------------------- /* Compute UDP checksums, including the ``pseudo-header'', the UDP header and the data. If the UDP checksum field is zero, we're not supposed to do a checksum. */ data = upp + sizeof(udp); len = ulen - sizeof(udp); usum = udp.uh_sum; udp.uh_sum = 0; /* XXX: We have to pass &udp, because we have to zero the checksum * field before calculating the sum...'upp' isn't zeroed. */ sum = wrapsum(checksum((unsigned char *)&udp, sizeof(udp), checksum(data, len, checksum((unsigned char *)&ip.ip_src, 8, IPPROTO_UDP + ulen)))); udp_packets_seen++; if (usum && usum != sum) { udp_packets_bad_checksum++; if (udp_packets_seen > 4 && (udp_packets_seen / udp_packets_bad_checksum) < 2) { log_info ("%d bad udp checksums in %d packets", udp_packets_bad_checksum, udp_packets_seen); udp_packets_seen = udp_packets_bad_checksum = 0; } return -1; } ---------------------------------------------------------------------- The way I read the code - the UDP checksum is computed in all cases, but is only *compared* with the original checksum field of the packet if this field is non-zero. Returning to the original claim of > DHCP Request with UDP checksum 0x0000 => ICMP Port Unreachable from > FreeBSD. I can see (e.g. using tcpdump) FreeBSD handle packets with a UDP checksum field of 0 just fine - for instance on a busy name server. So I am quite confident that your observed ICMP Port Unreachable is not generated by the FreeBSD kernel, as long as you have the DHCP server listening on UDP port 67. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From owner-freebsd-net@FreeBSD.ORG Tue Jun 28 19:38:12 2011 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 ECDE51065672 for ; Tue, 28 Jun 2011 19:38:12 +0000 (UTC) (envelope-from gygy@stsnet.ro) Received: from mail.stsnet.ro (mail.stsnet.ro [193.151.31.253]) by mx1.freebsd.org (Postfix) with ESMTP id A434B8FC14 for ; Tue, 28 Jun 2011 19:38:12 +0000 (UTC) Received: from mail.stsnet.ro (localhost.localdomain [127.0.0.1]) by mail.stsnet.ro (Postfix) with ESMTP id 3A04116DDA3; Tue, 28 Jun 2011 22:38:07 +0300 (EEST) Received: from localhost.localdomain [127.0.0.1] by BitDefender SMTP Proxy on localhost.localdomain [127.0.0.1] for localhost.localdomain [127.0.0.1]; Tue, 28 Jun 2011 22:38:07 +0300 (EEST) Received: from mail.stsnet.ro (localhost.localdomain [127.0.0.1]) (Authenticated sender: gygy) by mail.stsnet.ro (Postfix) with ESMTPA id 0A16816DDA0; Tue, 28 Jun 2011 22:38:07 +0300 (EEST) Received: from 86.121.68.231 (SquirrelMail authenticated user gygy) by mail.stsnet.ro with HTTP; Tue, 28 Jun 2011 22:38:07 +0300 Message-ID: In-Reply-To: <4E0A210F.7050105@sentex.net> References: <4d705cd0d73fb0d25cc3a017eb2eb072.squirrel@mail.stsnet.ro> <4E0A210F.7050105@sentex.net> Date: Tue, 28 Jun 2011 22:38:07 +0300 From: "Adrian Minta" To: "Adrian Minta" , freebsd-net@freebsd.org User-Agent: SquirrelMail/1.4.20 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-BitDefender-Spam: No (0) X-BitDefender-SpamStamp: v1, build 2.8.97.166700, SQMD Hits: none, bayes score: 500(0), pbayes score: 241(0), neunet score: 0(0), SQMD: 0f60d70e3861d982aeffea55b746fc85.fuzzy.fzrbl.org, total: 0(775) X-BitDefender-CF-Stamp: none X-BitDefender-Scanner: Clean, Agent: BitDefender Smtp Proxy 3.1.0 on mail.stsnet.ro, sigver: 7.38079 Cc: Subject: Re: FreeBSD 8.2 and MPD5 stability issues 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, 28 Jun 2011 19:38:13 -0000 Good news ! Last night I remove FLOWTABLE option and since then the server is stable. No crash what so ever an I was able to increase the number of tunnels. > On 6/27/2011 4:50 PM, Adrian Minta wrote: >> Thanks to Vlad Galu I was able to acquire a full crashinfo and kernel >> dump >> after a system freeze. I put all the files at: >> http://pluto.stsisp.ro/fbsd/ >> >> I hope this will help somebody in finding the race condition. > > Dont know about the race, but one thing I would get rid of in your > kernel config is the FLOWTABLE option as it has a few bugs still > > > Also get rid of > > > device gre > device tap > > # Bridging > device if_bridge > device lagg > > if you are not using them > > > Are you loading any klds ? Why the linux.ko and linprocfs.ko ? If you > dont use it, get rid of it. > > I would also not run snmpd and disable devd as they will do a lot of > work traversing all those interfaces. > > Also, how come your nics all show no carrier in the crash dump ? > > ---Mike > -- Best regards, Adrian Minta MA3173-RIPE +40726.110.369 +40212.022.660 From owner-freebsd-net@FreeBSD.ORG Tue Jun 28 19:52:11 2011 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 598251065675 for ; Tue, 28 Jun 2011 19:52:11 +0000 (UTC) (envelope-from ptyll@nitronet.pl) Received: from mail.nitronet.pl (smtp.nitronet.pl [195.90.106.27]) by mx1.freebsd.org (Postfix) with ESMTP id 116718FC13 for ; Tue, 28 Jun 2011 19:52:10 +0000 (UTC) Received: from mailnull by mail.nitronet.pl with virscan (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QbeKP-0006ZL-C6 for freebsd-net@freebsd.org; Tue, 28 Jun 2011 21:52:09 +0200 Date: Tue, 28 Jun 2011 21:55:30 +0200 From: Pawel Tyll X-Priority: 3 (Normal) Message-ID: <1414962521.20110628215530@nitronet.pl> To: "Adrian Minta" In-Reply-To: References: <4d705cd0d73fb0d25cc3a017eb2eb072.squirrel@mail.stsnet.ro> <4E0A210F.7050105@sentex.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: Nitronet.pl X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: ptyll@nitronet.pl X-SA-Exim-Scanned: No (on mail.nitronet.pl); SAEximRunCond expanded to false Cc: freebsd-net@freebsd.org Subject: Re: FreeBSD 8.2 and MPD5 stability issues 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, 28 Jun 2011 19:52:11 -0000 Hi Adrian, > Good news ! > Last night I remove FLOWTABLE option and since then the server is stable. > No crash what so ever an I was able to increase the number of tunnels. Yeah, FLOWTABLE still needs work, good news on the stability. Could you perhaps drop us all a note in two weeks if things keep stable? I myself run similar setup, plan to increase traffic and number of sessions in few days, so I'm very interested in how things go for you. Cheers. From owner-freebsd-net@FreeBSD.ORG Tue Jun 28 19:52:40 2011 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 280C71065672 for ; Tue, 28 Jun 2011 19:52:40 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1-6.sentex.ca [IPv6:2607:f3e0:0:1::12]) by mx1.freebsd.org (Postfix) with ESMTP id E03178FC1C for ; Tue, 28 Jun 2011 19:52:39 +0000 (UTC) Received: from [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a] (saphire3.sentex.ca [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a]) by smarthost1.sentex.ca (8.14.4/8.14.4) with ESMTP id p5SJqcUm025346; Tue, 28 Jun 2011 15:52:38 -0400 (EDT) (envelope-from mike@sentex.net) Message-ID: <4E0A30FD.3010107@sentex.net> Date: Tue, 28 Jun 2011 15:52:29 -0400 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Adrian Minta References: <4d705cd0d73fb0d25cc3a017eb2eb072.squirrel@mail.stsnet.ro> <4E0A210F.7050105@sentex.net> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on IPv6:2607:f3e0:0:1::12 Cc: freebsd-net@freebsd.org Subject: Re: FreeBSD 8.2 and MPD5 stability issues 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, 28 Jun 2011 19:52:40 -0000 On 6/28/2011 3:38 PM, Adrian Minta wrote: > Good news ! > Last night I remove FLOWTABLE option and since then the server is stable. > No crash what so ever an I was able to increase the number of tunnels. Thats great! If you are getting close to the CPU maxing out, consider getting rid of snmpd. Also, as a next step, try and run with ipv6 :) ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-net@FreeBSD.ORG Tue Jun 28 20:27:42 2011 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 CA30A106566C for ; Tue, 28 Jun 2011 20:27:42 +0000 (UTC) (envelope-from ck-lists@cksoft.de) Received: from mx1.cksoft.de (mx1.cksoft.de [IPv6:2001:4068:10::2]) by mx1.freebsd.org (Postfix) with ESMTP id 559848FC0C for ; Tue, 28 Jun 2011 20:27:42 +0000 (UTC) Received: from m.cksoft.de (m.cksoft.de [192.168.64.204]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.cksoft.de (Postfix) with ESMTP id ADA272F152C; Tue, 28 Jun 2011 22:27:40 +0200 (CEST) Received: from amavis.ahti.cksoft.de (amavis.ahti.cksoft.de [192.168.64.201]) by m.cksoft.de (Postfix) with ESMTP id 4A272ECFCE; Tue, 28 Jun 2011 22:27:40 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from m.cksoft.de ([192.168.64.204]) by amavis.ahti.cksoft.de (amavis.ahti.cksoft.de [192.168.64.201]) (amavisd-new, port 10024) with ESMTP id PflhUr2zbkdc; Tue, 28 Jun 2011 22:27:38 +0200 (CEST) Received: from tapio.cksoft.de (tapio.cksoft.de [192.168.64.37]) by m.cksoft.de (Postfix) with ESMTP id 2683BECFCB; Tue, 28 Jun 2011 22:27:38 +0200 (CEST) Received: by tapio.cksoft.de (Postfix, from userid 1000) id 17A4EB9E9; Tue, 28 Jun 2011 22:27:38 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by tapio.cksoft.de (Postfix) with ESMTP id 13A84B9E8; Tue, 28 Jun 2011 22:27:38 +0200 (CEST) Date: Tue, 28 Jun 2011 22:27:38 +0200 (CEST) From: Christian Kratzer X-X-Sender: ck@tapio.cksoft.de To: Pawel Tyll In-Reply-To: <1414962521.20110628215530@nitronet.pl> Message-ID: References: <4d705cd0d73fb0d25cc3a017eb2eb072.squirrel@mail.stsnet.ro> <4E0A210F.7050105@sentex.net> <1414962521.20110628215530@nitronet.pl> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-Spammer-Kill-Ratio: 75% MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org, Adrian Minta Subject: Re: FreeBSD 8.2 and MPD5 stability issues X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Christian Kratzer List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 20:27:42 -0000 Hi, On Tue, 28 Jun 2011, Pawel Tyll wrote: > Hi Adrian, > >> Good news ! >> Last night I remove FLOWTABLE option and since then the server is stable. >> No crash what so ever an I was able to increase the number of tunnels. > Yeah, FLOWTABLE still needs work, good news on the stability. Could > you perhaps drop us all a note in two weeks if things keep stable? from all I have seen all the work FLOWTABLE needs is finally being dropped from the tree. Its a constant cause of trouble and from what I recall not even ipv6 capable. Greetings Christian > > I myself run similar setup, plan to increase traffic and number of > sessions in few days, so I'm very interested in how things go for you. > > Cheers. > > > _______________________________________________ > 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" > -- Christian Kratzer CK Software GmbH Email: ck@cksoft.de Wildberger Weg 24/2 Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart Web: http://www.cksoft.de/ Geschaeftsfuehrer: Christian Kratzer From owner-freebsd-net@FreeBSD.ORG Tue Jun 28 20:33:51 2011 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 AD67D106564A for ; Tue, 28 Jun 2011 20:33:51 +0000 (UTC) (envelope-from igor.anishchuk@gmail.com) Received: from mail-qy0-f175.google.com (mail-qy0-f175.google.com [209.85.216.175]) by mx1.freebsd.org (Postfix) with ESMTP id 70A468FC15 for ; Tue, 28 Jun 2011 20:33:51 +0000 (UTC) Received: by qyk30 with SMTP id 30so2464302qyk.13 for ; Tue, 28 Jun 2011 13:33:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=aBuIw+sr/g91aCxq5D+1nV9iaM4cRCm+GdJaHJ2lhC8=; b=QuRis9XyQH0N3zi4C6uqcKObMTtDFpIrSIn+7xtPHrIkW+Br8TIsYaWAjW6d2SnMAU g/O66n4V990myNcgBTS9Ak9ycRF0nNMjiQv7Nwg2wvFcM7glCXpmmyxsmYORZzWk4tc/ PJStJEmdJJJG/3CCaC5pvI8FLjFuNOR0udEg4= MIME-Version: 1.0 Received: by 10.224.177.205 with SMTP id bj13mr2033802qab.287.1309291358197; Tue, 28 Jun 2011 13:02:38 -0700 (PDT) Received: by 10.224.36.207 with HTTP; Tue, 28 Jun 2011 13:02:38 -0700 (PDT) In-Reply-To: <8F86FFA7-E2D7-40D6-A1B5-DFCFA47EBD75@averesystems.com> References: <8F86FFA7-E2D7-40D6-A1B5-DFCFA47EBD75@averesystems.com> Date: Tue, 28 Jun 2011 23:02:38 +0300 Message-ID: From: Igor Anishchuk To: Andrew Boyer Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: ixgbe> vlan addition and removal brings the interfaces down and 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: Tue, 28 Jun 2011 20:33:51 -0000 Hi Andrew, could you please share the patch as I'm dying with this problem. What makes it worse is that on a busy router the DOWN/UP of the interfaces causes the ixgbe card to lose all network access until the box is rebooted. I can reproduce it easily on a variety of hosts from both HP and Dell. Therefore a patch that would not cause the card to reset would help a lot. -- Igor On Thu, May 19, 2011 at 8:58 PM, Andrew Boyer wro= te: > I have a patch that will fix this. =C2=A0Please give me a little while to= clean it up, and I will send it out on the list. > > -Andrew > > On May 19, 2011, at 2:58 AM, Igor Anishchuk wrote: > >> Hi All, >> >> I've been using Intel E10G42AFDA 10Gbit/s AF DA Dual Port adapters >> with direct attach cables and there is one thing keeps bothering me. >> I've been searching the Internet for any information with no luck. I >> would also assume that the problem is widely known, and I found one >> related PR kern/141285 but that one was closed unsolved. >> >> When a VLAN interface is added or removed to from the ix interfaces >> the parent interface is briefly brought down and up. This event is >> visible for all applications and the switches. With my use case I add >> and remove VLAN interfaces on the fly and the described behavior >> causes undesired effects, especially for BGP daemons that are >> configured to monitor one of permanent VLAN interfaces. >> >> I use FreeBSD 7-STABLE and the behavior is the same with stock >> drivers, with 2.2.3 and with 2.3.8 drivers downloaded from Intel web >> site. I have attempted to disable -vlanhwtag, -vlanhwfilter and >> -vlanhwtso with no effect. >> >> Could someone help me to stop the cards behaving this way? I do not >> mind some performance penalties, nor running in permanent promiscuous >> mode. I just want the card to stay up all the time regardless of the >> vlan interfaces attached to it. >> >> Any help, links, patches are much appreciated. >> >> Regards, >> >> Igor Anishchuk >> _______________________________________________ >> 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" > > -------------------------------------------------- > Andrew Boyer =C2=A0 =C2=A0aboyer@averesystems.com > > > > > From owner-freebsd-net@FreeBSD.ORG Tue Jun 28 20:44:57 2011 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 EC46A106564A for ; Tue, 28 Jun 2011 20:44:57 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) by mx1.freebsd.org (Postfix) with ESMTP id 7A0EE8FC1E for ; Tue, 28 Jun 2011 20:44:57 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id ED53825D385E; Tue, 28 Jun 2011 20:44:55 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 1C3A815A2ADF; Tue, 28 Jun 2011 20:44:55 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id xJjA7Pa7lSgm; Tue, 28 Jun 2011 20:44:53 +0000 (UTC) Received: from orange-en1.sbone.de (orange-en1.sbone.de [IPv6:fde9:577b:c1a9:31:cabc:c8ff:fecf:e8e3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 8176315A2A8F; Tue, 28 Jun 2011 20:44:52 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Bjoern A. Zeeb" In-Reply-To: Date: Tue, 28 Jun 2011 20:44:51 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <1722A449-718D-4403-A8F4-A3E733CD1518@lists.zabbadoz.net> References: <4d705cd0d73fb0d25cc3a017eb2eb072.squirrel@mail.stsnet.ro> <4E0A210F.7050105@sentex.net> <1414962521.20110628215530@nitronet.pl> To: Christian Kratzer X-Mailer: Apple Mail (2.1084) Cc: Pawel Tyll , Adrian Minta , freebsd-net@freebsd.org Subject: Re: FreeBSD 8.2 and MPD5 stability issues 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, 28 Jun 2011 20:44:58 -0000 On Jun 28, 2011, at 8:27 PM, Christian Kratzer wrote: > Hi, >=20 > On Tue, 28 Jun 2011, Pawel Tyll wrote: >> Hi Adrian, >>=20 >>> Good news ! >>> Last night I remove FLOWTABLE option and since then the server is = stable. >>> No crash what so ever an I was able to increase the number of = tunnels. >> Yeah, FLOWTABLE still needs work, good news on the stability. Could >> you perhaps drop us all a note in two weeks if things keep stable? >=20 > from all I have seen all the work FLOWTABLE needs is finally being > dropped from the tree. Its a constant cause of trouble and from what > I recall not even ipv6 capable. Well, I'd like to point you at http://svnweb.freebsd.org/base?view=3Drevision&revision=3D219775 and as an example at: = http://svnweb.freebsd.org/base/head/sys/net/route.c?r1=3D223334&r2=3D22333= 3&pathrev=3D223334 That said, for some workloads it may be a fairly reasonable option. /bz --=20 Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. From owner-freebsd-net@FreeBSD.ORG Tue Jun 28 20:48:21 2011 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 8C318106564A for ; Tue, 28 Jun 2011 20:48:21 +0000 (UTC) (envelope-from aboyer@averesystems.com) Received: from zimbra.averesystems.com (75-149-8-245-Pennsylvania.hfc.comcastbusiness.net [75.149.8.245]) by mx1.freebsd.org (Postfix) with ESMTP id 47F938FC08 for ; Tue, 28 Jun 2011 20:48:21 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zimbra.averesystems.com (Postfix) with ESMTP id C38B98BC01F; Tue, 28 Jun 2011 16:34:01 -0400 (EDT) X-Virus-Scanned: amavisd-new at averesystems.com Received: from zimbra.averesystems.com ([127.0.0.1]) by localhost (zimbra.averesystems.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B1XZxIVKQ8m0; Tue, 28 Jun 2011 16:34:00 -0400 (EDT) Received: from riven.arriad.com (fw.arriad.com [10.0.0.16]) by zimbra.averesystems.com (Postfix) with ESMTPSA id 9CC1D8BC003; Tue, 28 Jun 2011 16:34:00 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Andrew Boyer In-Reply-To: Date: Tue, 28 Jun 2011 16:31:57 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6E5D6CF9-E197-44E8-835A-ABD9F5969DBE@averesystems.com> References: <8F86FFA7-E2D7-40D6-A1B5-DFCFA47EBD75@averesystems.com> To: Igor Anishchuk , Jack Vogel X-Mailer: Apple Mail (2.1084) Cc: freebsd-net@freebsd.org Subject: Re: ixgbe> vlan addition and removal brings the interfaces down and 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: Tue, 28 Jun 2011 20:48:21 -0000 Hello Igor, Sorry for the delay. I'm a little hesitant to share our ixgbe patch to = change this behavior because Jack has checked in changes to igb that = make me think that our change is not correct. Or, at least, that he's = probably working on fixing ixgbe the right way. Jack, are you planning = to copy the reorganization of igb_setup_vlan_hw_support() over to = ixgbe_setup_vlan_hw_support? -Andrew On Jun 28, 2011, at 4:02 PM, Igor Anishchuk wrote: > Hi Andrew, >=20 > could you please share the patch as I'm dying with this problem. >=20 > What makes it worse is that on a busy router the DOWN/UP of the > interfaces causes the ixgbe card to lose all network access until the > box is rebooted. I can reproduce it easily on a variety of hosts from > both HP and Dell. Therefore a patch that would not cause the card to > reset would help a lot. >=20 > -- Igor >=20 > On Thu, May 19, 2011 at 8:58 PM, Andrew Boyer = wrote: >> I have a patch that will fix this. Please give me a little while to = clean it up, and I will send it out on the list. >>=20 >> -Andrew >>=20 >> On May 19, 2011, at 2:58 AM, Igor Anishchuk wrote: >>=20 >>> Hi All, >>>=20 >>> I've been using Intel E10G42AFDA 10Gbit/s AF DA Dual Port adapters >>> with direct attach cables and there is one thing keeps bothering me. >>> I've been searching the Internet for any information with no luck. I >>> would also assume that the problem is widely known, and I found one >>> related PR kern/141285 but that one was closed unsolved. >>>=20 >>> When a VLAN interface is added or removed to from the ix interfaces >>> the parent interface is briefly brought down and up. This event is >>> visible for all applications and the switches. With my use case I = add >>> and remove VLAN interfaces on the fly and the described behavior >>> causes undesired effects, especially for BGP daemons that are >>> configured to monitor one of permanent VLAN interfaces. >>>=20 >>> I use FreeBSD 7-STABLE and the behavior is the same with stock >>> drivers, with 2.2.3 and with 2.3.8 drivers downloaded from Intel web >>> site. I have attempted to disable -vlanhwtag, -vlanhwfilter and >>> -vlanhwtso with no effect. >>>=20 >>> Could someone help me to stop the cards behaving this way? I do not >>> mind some performance penalties, nor running in permanent = promiscuous >>> mode. I just want the card to stay up all the time regardless of the >>> vlan interfaces attached to it. >>>=20 >>> Any help, links, patches are much appreciated. >>>=20 >>> Regards, >>>=20 >>> Igor Anishchuk >>> _______________________________________________ >>> 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" >>=20 >> -------------------------------------------------- >> Andrew Boyer aboyer@averesystems.com >>=20 >>=20 >>=20 >>=20 >>=20 -------------------------------------------------- Andrew Boyer aboyer@averesystems.com From owner-freebsd-net@FreeBSD.ORG Tue Jun 28 21:01:35 2011 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 575CB1065676 for ; Tue, 28 Jun 2011 21:01:35 +0000 (UTC) (envelope-from prvs=11607a9d0c=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id CDD778FC20 for ; Tue, 28 Jun 2011 21:01:34 +0000 (UTC) X-MDAV-Processed: mail1.multiplay.co.uk, Tue, 28 Jun 2011 21:49:24 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Tue, 28 Jun 2011 21:49:24 +0100 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-5.0 required=6.0 tests=USER_IN_WHITELIST shortcircuit=ham autolearn=disabled version=3.2.5 Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50013904675.msg for ; Tue, 28 Jun 2011 21:49:23 +0100 X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=11607a9d0c=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-net@freebsd.org Message-ID: From: "Steven Hartland" To: "Igor Anishchuk" , "Andrew Boyer" References: <8F86FFA7-E2D7-40D6-A1B5-DFCFA47EBD75@averesystems.com> Date: Tue, 28 Jun 2011 21:49:46 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6090 Cc: freebsd-net@freebsd.org Subject: Re: ixgbe> vlan addition and removal brings the interfaces down andup 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, 28 Jun 2011 21:01:35 -0000 Pretty sure this is already in the source tree as it sounds like the same as the alias fix:- http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/ixgbe/ixgbe.c?rev=1.51;content-type=text%2Fplain There's also some additional fixes in the latest head version:- http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/ixgbe/ixgbe.c?rev=1.52;content-type=text%2Fplain Regards Steve ----- Original Message ----- From: "Igor Anishchuk" To: "Andrew Boyer" Cc: Sent: Tuesday, June 28, 2011 9:02 PM Subject: Re: ixgbe> vlan addition and removal brings the interfaces down andup Hi Andrew, could you please share the patch as I'm dying with this problem. What makes it worse is that on a busy router the DOWN/UP of the interfaces causes the ixgbe card to lose all network access until the box is rebooted. I can reproduce it easily on a variety of hosts from both HP and Dell. Therefore a patch that would not cause the card to reset would help a lot. ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-net@FreeBSD.ORG Tue Jun 28 21:40:56 2011 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 54FA8106566C for ; Tue, 28 Jun 2011 21:40:56 +0000 (UTC) (envelope-from dudu@dudu.ro) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 15D9E8FC14 for ; Tue, 28 Jun 2011 21:40:55 +0000 (UTC) Received: by qyk38 with SMTP id 38so454158qyk.13 for ; Tue, 28 Jun 2011 14:40:55 -0700 (PDT) Received: by 10.229.101.17 with SMTP id a17mr24499qco.209.1309297255118; Tue, 28 Jun 2011 14:40:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.39.210 with HTTP; Tue, 28 Jun 2011 14:40:15 -0700 (PDT) In-Reply-To: <1722A449-718D-4403-A8F4-A3E733CD1518@lists.zabbadoz.net> References: <4d705cd0d73fb0d25cc3a017eb2eb072.squirrel@mail.stsnet.ro> <4E0A210F.7050105@sentex.net> <1414962521.20110628215530@nitronet.pl> <1722A449-718D-4403-A8F4-A3E733CD1518@lists.zabbadoz.net> From: Vlad Galu Date: Tue, 28 Jun 2011 23:40:15 +0200 Message-ID: To: "Bjoern A. Zeeb" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Pawel Tyll , Adrian Minta , Christian Kratzer , freebsd-net@freebsd.org Subject: Re: FreeBSD 8.2 and MPD5 stability issues 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, 28 Jun 2011 21:40:56 -0000 On Tue, Jun 28, 2011 at 10:44 PM, Bjoern A. Zeeb < bzeeb-lists@lists.zabbadoz.net> wrote: > On Jun 28, 2011, at 8:27 PM, Christian Kratzer wrote: > > > Hi, > > > > On Tue, 28 Jun 2011, Pawel Tyll wrote: > >> Hi Adrian, > >> > >>> Good news ! > >>> Last night I remove FLOWTABLE option and since then the server is > stable. > >>> No crash what so ever an I was able to increase the number of tunnels. > >> Yeah, FLOWTABLE still needs work, good news on the stability. Could > >> you perhaps drop us all a note in two weeks if things keep stable? > > > > from all I have seen all the work FLOWTABLE needs is finally being > > dropped from the tree. Its a constant cause of trouble and from what > > I recall not even ipv6 capable. > > Well, I'd like to point you at > > http://svnweb.freebsd.org/base?view=revision&revision=219775 > and as an example at: > > http://svnweb.freebsd.org/base/head/sys/net/route.c?r1=223334&r2=223333&pathrev=223334 > > That said, for some workloads it may be a fairly reasonable option. > Hi Bjoern, Perhaps it would be best to document what those particular workloads are. Apparently, systems with small and seldom changing routing tables are good candidates. However, the distinction is not immediately obvious by skimming through the list archives. Regards, Vlad -- Good, fast & cheap. Pick any two. From owner-freebsd-net@FreeBSD.ORG Tue Jun 28 21:46:35 2011 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 A880C106566C for ; Tue, 28 Jun 2011 21:46:35 +0000 (UTC) (envelope-from jack.vogel@intel.com) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by mx1.freebsd.org (Postfix) with ESMTP id 849788FC14 for ; Tue, 28 Jun 2011 21:46:35 +0000 (UTC) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga101.fm.intel.com with ESMTP; 28 Jun 2011 14:18:14 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.65,439,1304319600"; d="scan'208";a="23991765" Received: from orsmsx603.amr.corp.intel.com ([10.22.226.49]) by fmsmga001.fm.intel.com with ESMTP; 28 Jun 2011 14:18:14 -0700 Received: from orsmsx606.amr.corp.intel.com (10.22.226.128) by orsmsx603.amr.corp.intel.com (10.22.226.49) with Microsoft SMTP Server (TLS) id 8.2.255.0; Tue, 28 Jun 2011 14:18:14 -0700 Received: from orsmsx508.amr.corp.intel.com ([10.22.226.46]) by orsmsx606.amr.corp.intel.com ([10.22.226.128]) with mapi; Tue, 28 Jun 2011 14:18:13 -0700 From: "Vogel, Jack" To: Andrew Boyer , Igor Anishchuk Date: Tue, 28 Jun 2011 14:18:13 -0700 Thread-Topic: ixgbe> vlan addition and removal brings the interfaces down and up Thread-Index: Acw10nNPsurhzOIISHueUsBr+AwOvQABkgdg Message-ID: <1DB50624F8348F48840F2E2CF6040A9D018D603544@orsmsx508.amr.corp.intel.com> References: <8F86FFA7-E2D7-40D6-A1B5-DFCFA47EBD75@averesystems.com> <6E5D6CF9-E197-44E8-835A-ABD9F5969DBE@averesystems.com> In-Reply-To: <6E5D6CF9-E197-44E8-835A-ABD9F5969DBE@averesystems.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "freebsd-net@freebsd.org" Subject: RE: ixgbe> vlan addition and removal brings the interfaces down and 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: Tue, 28 Jun 2011 21:46:35 -0000 Hmmm, I'll have to take a look at the code, and if I hadn't done it by now = there might be some reason I couldn't, or hell, maybe I just forgot :) Wil= l let you know. Jack -----Original Message----- From: Andrew Boyer [mailto:aboyer@averesystems.com]=20 Sent: Tuesday, June 28, 2011 1:32 PM To: Igor Anishchuk; Vogel, Jack Cc: freebsd-net@freebsd.org Subject: Re: ixgbe> vlan addition and removal brings the interfaces down an= d up Hello Igor, Sorry for the delay. I'm a little hesitant to share our ixgbe patch to cha= nge this behavior because Jack has checked in changes to igb that make me t= hink that our change is not correct. Or, at least, that he's probably work= ing on fixing ixgbe the right way. Jack, are you planning to copy the reor= ganization of igb_setup_vlan_hw_support() over to ixgbe_setup_vlan_hw_suppo= rt? -Andrew On Jun 28, 2011, at 4:02 PM, Igor Anishchuk wrote: > Hi Andrew, >=20 > could you please share the patch as I'm dying with this problem. >=20 > What makes it worse is that on a busy router the DOWN/UP of the > interfaces causes the ixgbe card to lose all network access until the > box is rebooted. I can reproduce it easily on a variety of hosts from > both HP and Dell. Therefore a patch that would not cause the card to > reset would help a lot. >=20 > -- Igor >=20 > On Thu, May 19, 2011 at 8:58 PM, Andrew Boyer w= rote: >> I have a patch that will fix this. Please give me a little while to cle= an it up, and I will send it out on the list. >>=20 >> -Andrew >>=20 >> On May 19, 2011, at 2:58 AM, Igor Anishchuk wrote: >>=20 >>> Hi All, >>>=20 >>> I've been using Intel E10G42AFDA 10Gbit/s AF DA Dual Port adapters >>> with direct attach cables and there is one thing keeps bothering me. >>> I've been searching the Internet for any information with no luck. I >>> would also assume that the problem is widely known, and I found one >>> related PR kern/141285 but that one was closed unsolved. >>>=20 >>> When a VLAN interface is added or removed to from the ix interfaces >>> the parent interface is briefly brought down and up. This event is >>> visible for all applications and the switches. With my use case I add >>> and remove VLAN interfaces on the fly and the described behavior >>> causes undesired effects, especially for BGP daemons that are >>> configured to monitor one of permanent VLAN interfaces. >>>=20 >>> I use FreeBSD 7-STABLE and the behavior is the same with stock >>> drivers, with 2.2.3 and with 2.3.8 drivers downloaded from Intel web >>> site. I have attempted to disable -vlanhwtag, -vlanhwfilter and >>> -vlanhwtso with no effect. >>>=20 >>> Could someone help me to stop the cards behaving this way? I do not >>> mind some performance penalties, nor running in permanent promiscuous >>> mode. I just want the card to stay up all the time regardless of the >>> vlan interfaces attached to it. >>>=20 >>> Any help, links, patches are much appreciated. >>>=20 >>> Regards, >>>=20 >>> Igor Anishchuk >>> _______________________________________________ >>> 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" >>=20 >> -------------------------------------------------- >> Andrew Boyer aboyer@averesystems.com >>=20 >>=20 >>=20 >>=20 >>=20 -------------------------------------------------- Andrew Boyer aboyer@averesystems.com From owner-freebsd-net@FreeBSD.ORG Tue Jun 28 21:53:15 2011 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 4A12E106566B for ; Tue, 28 Jun 2011 21:53:15 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) by mx1.freebsd.org (Postfix) with ESMTP id F2C068FC0A for ; Tue, 28 Jun 2011 21:53:14 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 05BC125D3870; Tue, 28 Jun 2011 21:53:13 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 4806A15A2B1D; Tue, 28 Jun 2011 21:53:13 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id E1ril16WPrBC; Tue, 28 Jun 2011 21:53:12 +0000 (UTC) Received: from orange-en1.sbone.de (orange-en1.sbone.de [IPv6:fde9:577b:c1a9:31:cabc:c8ff:fecf:e8e3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 6C83C15A2B1B; Tue, 28 Jun 2011 21:53:12 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Bjoern A. Zeeb" In-Reply-To: Date: Tue, 28 Jun 2011 21:53:11 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4d705cd0d73fb0d25cc3a017eb2eb072.squirrel@mail.stsnet.ro> <4E0A210F.7050105@sentex.net> <1414962521.20110628215530@nitronet.pl> <1722A449-718D-4403-A8F4-A3E733CD1518@lists.zabbadoz.net> To: Vlad Galu X-Mailer: Apple Mail (2.1084) Cc: freebsd-net@freebsd.org Subject: Re: FreeBSD 8.2 and MPD5 stability issues 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, 28 Jun 2011 21:53:15 -0000 > Perhaps it would be best to document what those particular workloads = are. Apparently, systems with small and seldom changing routing tables = are good candidates. However, the distinction is not immediately obvious = by skimming through the list archives. Start reading here: = http://conferences.sigcomm.org/sigcomm/2009/workshops/presto/papers/p37.pd= f patches for documentation are surely welcome by the docs people. --=20 Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. From owner-freebsd-net@FreeBSD.ORG Tue Jun 28 21:57:43 2011 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 5C013106566B; Tue, 28 Jun 2011 21:57:43 +0000 (UTC) (envelope-from cyko@cykotix.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 0D9F88FC12; Tue, 28 Jun 2011 21:57:42 +0000 (UTC) Received: by iwr19 with SMTP id 19so759222iwr.13 for ; Tue, 28 Jun 2011 14:57:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.168.5 with SMTP id u5mr39700icy.510.1309298262023; Tue, 28 Jun 2011 14:57:42 -0700 (PDT) Sender: cyko@cykotix.com Received: by 10.231.30.73 with HTTP; Tue, 28 Jun 2011 14:57:41 -0700 (PDT) X-Originating-IP: [69.133.3.143] In-Reply-To: References: Date: Tue, 28 Jun 2011 17:57:41 -0400 X-Google-Sender-Auth: ouina2njXwxkyDto_GYXvV7ScvA Message-ID: From: Patrick Lahni To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Adrian Chadd Subject: Re: iwn -CURRENT drivers on -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: Tue, 28 Jun 2011 21:57:43 -0000 On Mon, Jun 27, 2011 at 7:00 PM, Adrian Chadd wrote: > Just -ampdutx. Ampdu RX is fine. :) > > Well, I would have loved to help test but it seems I can't even get -HEAD to boot on my machine. If I move the drive to a different machine it boots fine, so it's clearly some sort of hardware issue. Unless I can figure this out, I guess I'm stuck with 11g. Thanks, Patrick From owner-freebsd-net@FreeBSD.ORG Tue Jun 28 22:02:56 2011 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 CF207106566C for ; Tue, 28 Jun 2011 22:02:56 +0000 (UTC) (envelope-from dudu@dudu.ro) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 8B8818FC17 for ; Tue, 28 Jun 2011 22:02:55 +0000 (UTC) Received: by qyk38 with SMTP id 38so464728qyk.13 for ; Tue, 28 Jun 2011 15:02:54 -0700 (PDT) Received: by 10.224.211.69 with SMTP id gn5mr49863qab.167.1309298573126; Tue, 28 Jun 2011 15:02:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.39.210 with HTTP; Tue, 28 Jun 2011 15:02:13 -0700 (PDT) In-Reply-To: References: <4d705cd0d73fb0d25cc3a017eb2eb072.squirrel@mail.stsnet.ro> <4E0A210F.7050105@sentex.net> <1414962521.20110628215530@nitronet.pl> <1722A449-718D-4403-A8F4-A3E733CD1518@lists.zabbadoz.net> From: Vlad Galu Date: Wed, 29 Jun 2011 00:02:13 +0200 Message-ID: To: "Bjoern A. Zeeb" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: FreeBSD 8.2 and MPD5 stability issues 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, 28 Jun 2011 22:02:56 -0000 On Tue, Jun 28, 2011 at 11:53 PM, Bjoern A. Zeeb < bzeeb-lists@lists.zabbadoz.net> wrote: > > > Perhaps it would be best to document what those particular workloads are. > Apparently, systems with small and seldom changing routing tables are good > candidates. However, the distinction is not immediately obvious by skimming > through the list archives. > > Start reading here: > http://conferences.sigcomm.org/sigcomm/2009/workshops/presto/papers/p37.pdf > > patches for documentation are surely welcome by the docs people. > > Thanks! That was a suggestion, though, not a request :) I'm one happy flowtable user. -- Good, fast & cheap. Pick any two. From owner-freebsd-net@FreeBSD.ORG Wed Jun 29 15:24:12 2011 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 02761106564A for ; Wed, 29 Jun 2011 15:24:12 +0000 (UTC) (envelope-from olwi@fb-n.l.org.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 4EDC48FC12 for ; Wed, 29 Jun 2011 15:24:10 +0000 (UTC) Received: from [10.99.0.10] (idea.starpoint.kiev.ua [10.99.0.10]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA29967 for ; Wed, 29 Jun 2011 18:10:37 +0300 (EEST) (envelope-from olwi@fb-n.l.org.ua) Message-ID: <4E0B406D.8070406@fb-n.l.org.ua> Date: Wed, 29 Jun 2011 18:10:37 +0300 From: Oleg Cherevko User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Subject: ifconfig alias: same subnet netmask question 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, 29 Jun 2011 15:24:12 -0000 Hi All, When describing the "alias" parameter ifconfig manpage claims that "If the address is on the same subnet as the first network address for this interface, a non-conflicting netmask must be given. Usually 0xffffffff is most appropriate." Taking into account that FreeBSD supports aliases from the same subnet with identical netmask for 6+ years now, does this statement still make sense? And what does this "conflicting netmask" stand for (I mean in the context of more or less recent FreeBSD versions, say 8.0+)? Are there any drawbacks in setting aliases like this: ifconfig em0 inet 192.168.1.1 netmask 0xffffff00 ifconfig em0 inet 192.168.1.2 netmask 0xffffff00 instead of traditional: ifconfig em0 inet 192.168.1.1 netmask 0xffffff00 ifconfig em0 inet 192.168.1.2 netmask 0xffffffff (again, for more or less recent FreeBSD versions)? -- Olwi From owner-freebsd-net@FreeBSD.ORG Wed Jun 29 15:29:17 2011 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 58EB1106566B for ; Wed, 29 Jun 2011 15:29:17 +0000 (UTC) (envelope-from olwi@fb-n.l.org.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id A9C368FC08 for ; Wed, 29 Jun 2011 15:29:16 +0000 (UTC) Received: from [10.99.0.10] (idea.starpoint.kiev.ua [10.99.0.10]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA00483 for ; Wed, 29 Jun 2011 18:29:15 +0300 (EEST) (envelope-from olwi@fb-n.l.org.ua) Message-ID: <4E0B44CA.9060504@fb-n.l.org.ua> Date: Wed, 29 Jun 2011 18:29:14 +0300 From: Oleg Cherevko User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <4E0B406D.8070406@fb-n.l.org.ua> In-Reply-To: <4E0B406D.8070406@fb-n.l.org.ua> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: ifconfig alias: same subnet netmask question 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, 29 Jun 2011 15:29:17 -0000 On 29.06.2011 18:10, Oleg Cherevko wrote: > Are there any drawbacks in setting aliases like this: > ifconfig em0 inet 192.168.1.1 netmask 0xffffff00 > ifconfig em0 inet 192.168.1.2 netmask 0xffffff00 > instead of traditional: > ifconfig em0 inet 192.168.1.1 netmask 0xffffff00 > ifconfig em0 inet 192.168.1.2 netmask 0xffffffff > (again, for more or less recent FreeBSD versions)? Sorry, the above examples should read: ifconfig em0 inet 192.168.1.1 netmask 0xffffff00 ifconfig em0 inet 192.168.1.2 netmask 0xffffff00 alias and ifconfig em0 inet 192.168.1.1 netmask 0xffffff00 ifconfig em0 inet 192.168.1.2 netmask 0xffffffff alias of course. -- Olwi From owner-freebsd-net@FreeBSD.ORG Wed Jun 29 15:43:29 2011 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 9DDEC106566C for ; Wed, 29 Jun 2011 15:43:29 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.freebsd.org (Postfix) with ESMTP id 7C4018FC1D for ; Wed, 29 Jun 2011 15:43:28 +0000 (UTC) Received: from PWSVL-EXCHTS-02.internal.cacheflow.com (sai-rp.bluecoat.com [10.2.2.126] (may be forged)) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id p5TFSPIN004876 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 29 Jun 2011 08:28:26 -0700 (PDT) Received: from PWSVL-EXCMBX-01.internal.cacheflow.com ([fe80::15bc:12e2:4676:340f]) by PWSVL-EXCHTS-02.internal.cacheflow.com ([fe80::4910:317f:407:6ecc%14]) with mapi id 14.01.0255.000; Wed, 29 Jun 2011 08:28:19 -0700 From: "Li, Qing" To: Oleg Cherevko , "freebsd-net@freebsd.org" Thread-Topic: ifconfig alias: same subnet netmask question Thread-Index: AQHMNnCr+WsDCgKoG0q/gVdEqb5YnJTUdNuA Date: Wed, 29 Jun 2011 15:28:19 +0000 Message-ID: References: <4E0B406D.8070406@fb-n.l.org.ua> In-Reply-To: <4E0B406D.8070406@fb-n.l.org.ua> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.2.2.106] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Subject: RE: ifconfig alias: same subnet netmask question 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, 29 Jun 2011 15:43:29 -0000 First of all, are you encountering any issues ? There is an outstanding issue with the address alias and improper routing table update that I am actively working on. --Qing > -----Original Message----- > From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd- > net@freebsd.org] On Behalf Of Oleg Cherevko > Sent: Wednesday, June 29, 2011 8:11 AM > To: freebsd-net@freebsd.org > Subject: ifconfig alias: same subnet netmask question >=20 > Hi All, >=20 > When describing the "alias" parameter ifconfig manpage claims that "If > the address is on the same subnet as the first network address for this > interface, a non-conflicting netmask must be given. Usually 0xffffffff > is most appropriate." >=20 > Taking into account that FreeBSD supports aliases from the same subnet > with identical netmask for 6+ years now, does this statement still make > sense? And what does this "conflicting netmask" stand for (I mean in > the > context of more or less recent FreeBSD versions, say 8.0+)? >=20 > Are there any drawbacks in setting aliases like this: > ifconfig em0 inet 192.168.1.1 netmask 0xffffff00 > ifconfig em0 inet 192.168.1.2 netmask 0xffffff00 > instead of traditional: > ifconfig em0 inet 192.168.1.1 netmask 0xffffff00 > ifconfig em0 inet 192.168.1.2 netmask 0xffffffff > (again, for more or less recent FreeBSD versions)? >=20 > -- > Olwi > _______________________________________________ > 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 Wed Jun 29 16:47:58 2011 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 7672A106564A for ; Wed, 29 Jun 2011 16:47:58 +0000 (UTC) (envelope-from korvus@comcast.net) Received: from qmta11.emeryville.ca.mail.comcast.net (qmta11.emeryville.ca.mail.comcast.net [76.96.27.211]) by mx1.freebsd.org (Postfix) with ESMTP id 621108FC14 for ; Wed, 29 Jun 2011 16:47:58 +0000 (UTC) Received: from omta17.emeryville.ca.mail.comcast.net ([76.96.30.73]) by qmta11.emeryville.ca.mail.comcast.net with comcast id 1rvh1h00B1afHeLABsamHH; Wed, 29 Jun 2011 16:34:46 +0000 Received: from [192.168.2.164] ([206.210.89.202]) by omta17.emeryville.ca.mail.comcast.net with comcast id 1sev1h00d4Mx3R28dsey3i; Wed, 29 Jun 2011 16:39:09 +0000 Message-ID: <4E0B540B.3090400@comcast.net> Date: Wed, 29 Jun 2011 12:34:19 -0400 From: Steve Polyack User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110516 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: User Questions , freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Question about NIC link state initialization 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, 29 Jun 2011 16:47:58 -0000 I have a handful of systems running FreeBSD 8.1-RELEASE. An occaisional fat-finger in /etc/fstab may cause one to end up in single-user mode from time to time. This would normally not be a problem, but some of these systems have a LOM (lights-out management) controller which shares the system's on-board NICs. This works great 99% of the time, but when the system drops out of init(8) and into single-user mode, the links on the interfaces never come up, and therefore the LOM becomes inaccessible. Cue remote-hands at the facility to help us remedy the problem. I've been playing around with this configuration on a local system, and I've noticed that once at a single-user shell, all one has to do is run ifconfig to cause the NIC's links to come up. You don't even have to specify the interface, nor do you have to specify "up". As soon as I hit enter, ifconfig prints the typical interface summary - intermingled in with this are the bold kernel log messages stating "bce0: link state changed to UP" and "bce1: link state changed to UP". So, my question is - why do we have to run ifconfig(8) to bring the links up on the attached interfaces? Shouldn't they come up after the driver discovers and initializes the devices? Keep in mind that I don't even have to pass any arguments (such as "up") to ifconfig. Furthermore, the behavior is exactly the same for bce(4) and em(4). Short of patching init(8) (or perhaps the NIC drivers?), I don't see another way for me to ensure the links come up even when the system drops into single-user mode on boot. - Steve From owner-freebsd-net@FreeBSD.ORG Wed Jun 29 17:15:34 2011 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 EC063106564A for ; Wed, 29 Jun 2011 17:15:34 +0000 (UTC) (envelope-from olwi@fb-n.l.org.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 2B0C18FC17 for ; Wed, 29 Jun 2011 17:15:33 +0000 (UTC) Received: from [10.0.10.4] (TPad-L.deer.kiev.ua [10.0.10.4]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id UAA01662; Wed, 29 Jun 2011 20:15:29 +0300 (EEST) (envelope-from olwi@fb-n.l.org.ua) Message-ID: <4E0B5DB1.5090702@fb-n.l.org.ua> Date: Wed, 29 Jun 2011 20:15:29 +0300 From: Oleg Cherevko User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Li, Qing" References: <4E0B406D.8070406@fb-n.l.org.ua> In-Reply-To: Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-net@freebsd.org" Subject: Re: ifconfig alias: same subnet netmask question 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, 29 Jun 2011 17:15:35 -0000 Li, Qing wrote: > First of all, are you encountering any issues ? Well, for the last 14+ years I used to setup aliases with 0xffffffff netmask and everything worked OK. However recently I encountered situation where 0xffffffff-style alias triggered some unwanted network behavior. When one sets alias like this: ifconfig em0 inet 192.168.1.1 netmask 0xffffff00 ifconfig em0 inet 192.168.1.2 netmask 0xffffffff alias and then exports connected networks via OSPF ASE, two prefixes end up being exported (192.168.1.1/24 and 192.168.1.2/32). In case of "identical netmask" setup: ifconfig em0 inet 192.168.1.1 netmask 0xffffff00 ifconfig em0 inet 192.168.1.2 netmask 0xffffff00 alias only one prefix gets exported (192.168.1.1/24). In my particular situation two exported prefixes led to wrong behavior of some equipment (other than FreeBSD machine in question). When I changed to "identical netmask" setup (one exported prefix) everything started to work flawlessly. So far I encountered no issues with this "identical netmask" setup. So I'd like to know why ifconfig manpage still recommends old way of setting aliases? Perhaps there are some pitfalls that I'm not aware of? Or manpage text is simply outdated? > There is an outstanding issue with the address alias and improper routing > table update that I am actively working on. > > --Qing > > >> -----Original Message----- >> From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd- >> net@freebsd.org] On Behalf Of Oleg Cherevko >> Sent: Wednesday, June 29, 2011 8:11 AM >> To: freebsd-net@freebsd.org >> Subject: ifconfig alias: same subnet netmask question >> >> Hi All, >> >> When describing the "alias" parameter ifconfig manpage claims that "If >> the address is on the same subnet as the first network address for this >> interface, a non-conflicting netmask must be given. Usually 0xffffffff >> is most appropriate." >> >> Taking into account that FreeBSD supports aliases from the same subnet >> with identical netmask for 6+ years now, does this statement still make >> sense? And what does this "conflicting netmask" stand for (I mean in >> the >> context of more or less recent FreeBSD versions, say 8.0+)? >> >> Are there any drawbacks in setting aliases like this: >> ifconfig em0 inet 192.168.1.1 netmask 0xffffff00 >> ifconfig em0 inet 192.168.1.2 netmask 0xffffff00 >> instead of traditional: >> ifconfig em0 inet 192.168.1.1 netmask 0xffffff00 >> ifconfig em0 inet 192.168.1.2 netmask 0xffffffff >> (again, for more or less recent FreeBSD versions)? >> >> -- >> Olwi >> _______________________________________________ >> 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" -- Olwi From owner-freebsd-net@FreeBSD.ORG Wed Jun 29 18:44:29 2011 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 576001065670; Wed, 29 Jun 2011 18:44:29 +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 2F1968FC15; Wed, 29 Jun 2011 18:44:29 +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 p5TIiTEe030700; Wed, 29 Jun 2011 18:44:29 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p5TIiTc4030696; Wed, 29 Jun 2011 18:44:29 GMT (envelope-from linimon) Date: Wed, 29 Jun 2011 18:44:29 GMT Message-Id: <201106291844.p5TIiTc4030696@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/158426: [e1000] [panic] _mtx_lock_sleep: recursed on non-recursive mutex if_addr_mtx @ /usr/src/sys/netinet6/mld6.c:1676 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, 29 Jun 2011 18:44:29 -0000 Old Synopsis: [panic] _mtx_lock_sleep: recursed on non-recursive mutex if_addr_mtx @ /usr/src/sys/netinet6/mld6.c:1676 New Synopsis: [e1000] [panic] _mtx_lock_sleep: recursed on non-recursive mutex if_addr_mtx @ /usr/src/sys/netinet6/mld6.c:1676 Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed Jun 29 18:44:18 UTC 2011 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=158426 From owner-freebsd-net@FreeBSD.ORG Wed Jun 29 18:56:57 2011 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 696AB106564A for ; Wed, 29 Jun 2011 18:56:57 +0000 (UTC) (envelope-from mikemacleod@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 2F0928FC15 for ; Wed, 29 Jun 2011 18:56:56 +0000 (UTC) Received: by yxl31 with SMTP id 31so788172yxl.13 for ; Wed, 29 Jun 2011 11:56:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; bh=AIlEbdKJjSi7NPyNuvYq2+cSKtKzerar23eq2WFxNrw=; b=iXxIyhjBr5B49SC+ez10tCXwHMHhaxrXa68CMaI6YdjicIL2IAAK7yooMLfpWf69Sx XZaum9gaRLLMM01fESNqAbF1SOOPN1xqYI3u/Uo2jBJl5ZYwv340CXBLrZ/qWkXjH8Em 8MaaiHybA/GqD1psINngkUPJp25kJ19gPJCU0= Received: by 10.91.3.31 with SMTP id f31mr1012553agi.73.1309372125204; Wed, 29 Jun 2011 11:28:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.84.1 with HTTP; Wed, 29 Jun 2011 11:28:25 -0700 (PDT) From: Michael MacLeod Date: Wed, 29 Jun 2011 14:28:25 -0400 Message-ID: To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Bridging Two Tunnel Interfaces For ALTQ 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, 29 Jun 2011 18:56:57 -0000 I use pf+ALTQ to achieve some pretty decent traffic shaping results at home. However, recently signed up to be part of an IPv6 trial with my ISP, and they've given me a second (dual-stacked) PPPoE login with which to test with. The problem is that the second login lacks my static IP or my routed /29. I can have both tunnels up simultaneously, but that becomes a pain to traffic shape since I can't have them both assigned to the same ALTQ. ... unless there is some way for me to turn the ng interfaces (I'm using mpd5) into ethernet interfaces that could be assigned to an if_bridge. I could easily disable IPv4 on the IPv6 tunnel, which would clean up any routing issues, assign both tunnels to the bridge, and put the ALTQ on the bridge. It just might have the effect I'm looking for. Bonus points if the solution can be extended to allow it to work with a gif tunnel as well, so that users of 6in4 tunnels could use it (my ISPs IPv6 beta won't let me do rDNS delegation, so I might want to try a tunnel from he.net instead). I spent some time this morning trying to make netgraph do this with the two ng interfaces, but didn't have any luck. Google didn't turn up anyone trying to do anything similar that I could find; closest I got was this: http://lists.freebsd.org/pipermail/freebsd-net/2004-November/005598.html This is all assuming that the best way to use ALTQ on multiple outbound connections is with a bridge. If there is another or more elegant solution, I'd love to hear it. From owner-freebsd-net@FreeBSD.ORG Wed Jun 29 21:34:11 2011 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 D746E1065676 for ; Wed, 29 Jun 2011 21:34:11 +0000 (UTC) (envelope-from olwi@icyb.kiev.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 13A028FC0A for ; Wed, 29 Jun 2011 21:34:10 +0000 (UTC) Received: from [10.0.10.4] (TPad-L.deer.kiev.ua [10.0.10.4]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id AAA03936; Thu, 30 Jun 2011 00:14:12 +0300 (EEST) (envelope-from olwi@icyb.kiev.ua) Message-ID: <4E0B95A4.3020207@icyb.kiev.ua> Date: Thu, 30 Jun 2011 00:14:12 +0300 From: Oleg Cherevko User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Li, Qing" References: <4E0B406D.8070406@fb-n.l.org.ua> <4E0B5DB1.5090702@fb-n.l.org.ua> In-Reply-To: <4E0B5DB1.5090702@fb-n.l.org.ua> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-net@freebsd.org" Subject: Re: ifconfig alias: same subnet netmask question 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, 29 Jun 2011 21:34:12 -0000 Darn, I have to correct myself once again. Oleg Cherevko wrote: > Li, Qing wrote: >> First of all, are you encountering any issues ? > > Well, for the last 14+ years I used to setup aliases with 0xffffffff > netmask and everything worked OK. However recently I encountered > situation where 0xffffffff-style alias triggered some unwanted network > behavior. > > When one sets alias like this: > ifconfig em0 inet 192.168.1.1 netmask 0xffffff00 > ifconfig em0 inet 192.168.1.2 netmask 0xffffffff alias > and then exports connected networks via OSPF ASE, two prefixes end up > being exported (192.168.1.1/24 and 192.168.1.2/32). The above two prefixes should read "(192.168.1.0/24 and 192.168.1.2/32)", of course. > > In case of "identical netmask" setup: > ifconfig em0 inet 192.168.1.1 netmask 0xffffff00 > ifconfig em0 inet 192.168.1.2 netmask 0xffffff00 alias > only one prefix gets exported (192.168.1.1/24). This one should read "(192.168.1.0/24)" as well. > In my particular situation two exported prefixes led to wrong behavior > of some equipment (other than FreeBSD machine in question). When I > changed to "identical netmask" setup (one exported prefix) everything > started to work flawlessly. > > So far I encountered no issues with this "identical netmask" setup. > So I'd like to know why ifconfig manpage still recommends old way of > setting aliases? Perhaps there are some pitfalls that I'm not aware of? > Or manpage text is simply outdated? > >> There is an outstanding issue with the address alias and improper routing >> table update that I am actively working on. >> >> --Qing >> >> >>> -----Original Message----- >>> From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd- >>> net@freebsd.org] On Behalf Of Oleg Cherevko >>> Sent: Wednesday, June 29, 2011 8:11 AM >>> To: freebsd-net@freebsd.org >>> Subject: ifconfig alias: same subnet netmask question >>> >>> Hi All, >>> >>> When describing the "alias" parameter ifconfig manpage claims that "If >>> the address is on the same subnet as the first network address for this >>> interface, a non-conflicting netmask must be given. Usually 0xffffffff >>> is most appropriate." >>> >>> Taking into account that FreeBSD supports aliases from the same subnet >>> with identical netmask for 6+ years now, does this statement still make >>> sense? And what does this "conflicting netmask" stand for (I mean in >>> the >>> context of more or less recent FreeBSD versions, say 8.0+)? >>> >>> Are there any drawbacks in setting aliases like this: >>> ifconfig em0 inet 192.168.1.1 netmask 0xffffff00 >>> ifconfig em0 inet 192.168.1.2 netmask 0xffffff00 >>> instead of traditional: >>> ifconfig em0 inet 192.168.1.1 netmask 0xffffff00 >>> ifconfig em0 inet 192.168.1.2 netmask 0xffffffff >>> (again, for more or less recent FreeBSD versions)? >>> >>> -- >>> Olwi >>> _______________________________________________ >>> 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" > > -- Olwi From owner-freebsd-net@FreeBSD.ORG Thu Jun 30 05:14:16 2011 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 B477C106566C; Thu, 30 Jun 2011 05:14:16 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (unknown [IPv6:2607:f678:1010::34]) by mx1.freebsd.org (Postfix) with ESMTP id 9249D8FC12; Thu, 30 Jun 2011 05:14:16 +0000 (UTC) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id p5U5ECpV076173 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 29 Jun 2011 22:14:12 -0700 (PDT) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.12.9/Submit) with UUCP id p5U5ECYw076172; Wed, 29 Jun 2011 22:14:12 -0700 (PDT) Received: from fbsd61 by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA25339; Wed, 29 Jun 11 22:10:30 PDT Date: Wed, 29 Jun 2011 22:10:32 -0700 From: perryh@pluto.rain.com To: korvus@comcast.net Message-Id: <4e0c0548.eW27hshSLoLhhTu1%perryh@pluto.rain.com> References: <4E0B540B.3090400@comcast.net> In-Reply-To: <4E0B540B.3090400@comcast.net> User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, freebsd-questions@freebsd.org Subject: Re: Question about NIC link state initialization 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, 30 Jun 2011 05:14:16 -0000 Steve Polyack wrote: > ... An occaisional fat-finger in /etc/fstab may cause one to > end up in single-user mode ... some of these systems have a LOM > (lights-out management) controller which shares the system's > on-board NICs ... when the system drops out of init(8) and into > single-user mode, the links on the interfaces never come up, > and therefore the LOM becomes inaccessible. > > ... all one has to do is run ifconfig to cause the NIC's links to > come up ... why do we have to run ifconfig(8) to bring the links > up on the attached interfaces? When trying to troubleshoot a problem that was known or suspected to involve the network or its hardware, one might not _want_ the NICs alive. > Short of patching init(8) (or perhaps the NIC drivers?), I don't > see another way for me to ensure the links come up even when the > system drops into single-user mode on boot. Something in /root/.profile, perhaps? That should get run when the single-user shell starts up, if it's started as a "login" shell. From owner-freebsd-net@FreeBSD.ORG Thu Jun 30 11:22:08 2011 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 566FE10657A8 for ; Thu, 30 Jun 2011 11:22:08 +0000 (UTC) (envelope-from feenberg@nber.org) Received: from mail2.nber.org (mail2.nber.org [66.251.72.79]) by mx1.freebsd.org (Postfix) with ESMTP id BE0AE8FC0C for ; Thu, 30 Jun 2011 11:22:07 +0000 (UTC) Received: from nber9.nber.org (nber9.nber.org [66.251.72.81]) by mail2.nber.org (8.14.4/8.14.4) with ESMTP id p5UAnTLp033883 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 30 Jun 2011 06:49:31 -0400 (EDT) (envelope-from feenberg@nber.org) Received: from localhost (feenberg@localhost) by nber9.nber.org (8.14.4/8.14.4/Submit) with ESMTP id p5UAnPQh023450; Thu, 30 Jun 2011 06:49:26 -0400 X-Authentication-Warning: nber9.nber.org: feenberg owned process doing -bs Date: Thu, 30 Jun 2011 06:49:25 -0400 (EDT) From: Daniel Feenberg To: perryh@pluto.rain.com In-Reply-To: <4e0c0548.eW27hshSLoLhhTu1%perryh@pluto.rain.com> Message-ID: References: <4E0B540B.3090400@comcast.net> <4e0c0548.eW27hshSLoLhhTu1%perryh@pluto.rain.com> User-Agent: Alpine 2.00 (LFD 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.39/RELEASE, bases: 20110630 #5690619, check: 20110630 clean Cc: freebsd-net@freebsd.org, korvus@comcast.net, freebsd-questions@freebsd.org Subject: Re: Question about NIC link state initialization 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, 30 Jun 2011 11:22:08 -0000 On Wed, 29 Jun 2011, perryh@pluto.rain.com wrote: > Steve Polyack wrote: > >> ... An occaisional fat-finger in /etc/fstab may cause one to >> end up in single-user mode ... some of these systems have a LOM >> (lights-out management) controller which shares the system's >> on-board NICs ... when the system drops out of init(8) and into >> single-user mode, the links on the interfaces never come up, >> and therefore the LOM becomes inaccessible. >> >> ... all one has to do is run ifconfig to cause the NIC's links to >> come up ... why do we have to run ifconfig(8) to bring the links >> up on the attached interfaces? > > When trying to troubleshoot a problem that was known or suspected to > involve the network or its hardware, one might not _want_ the NICs Well, maybe, but if the system needs to boot into multi-user mode for the LOM to be available, what is the need for the LOM? At that point you can do everything you might need through the OS interface. Can I ask what is the brand of this so-called LOM? Is there any documentation implying something more useful? Do they describe doing a bare metal install of an OS? Daniel Feenberg From owner-freebsd-net@FreeBSD.ORG Thu Jun 30 12:00:23 2011 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 2403C10656B0 for ; Thu, 30 Jun 2011 12:00:23 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id EA3C08FC0C for ; Thu, 30 Jun 2011 12:00:22 +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 p5UC0Mkv036534 for ; Thu, 30 Jun 2011 12:00:22 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p5UC0Mhg036533; Thu, 30 Jun 2011 12:00:22 GMT (envelope-from gnats) Date: Thu, 30 Jun 2011 12:00:22 GMT Message-Id: <201106301200.p5UC0Mhg036533@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Sergey Kandaurov Cc: Subject: Re: kern/158426: [e1000] [panic] _mtx_lock_sleep: recursed on non-recursive mutex if_addr_mtx @ /usr/src/sys/netinet6/mld6.c:1676 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Sergey Kandaurov List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 12:00:23 -0000 The following reply was made to PR kern/158426; it has been noted by GNATS. From: Sergey Kandaurov To: bug-followup@FreeBSD.org, tps@vr-web.de Cc: Subject: Re: kern/158426: [e1000] [panic] _mtx_lock_sleep: recursed on non-recursive mutex if_addr_mtx @ /usr/src/sys/netinet6/mld6.c:1676 Date: Thu, 30 Jun 2011 15:54:33 +0400 --0016e64aefda827b7b04a6ec9043 Content-Type: text/plain; charset=ISO-8859-1 The problem is that locking scope in MDL6 code is too wide. That results in that mld_set_version() is called with if_addr_mtx held, and then mld_set_version() locks it itself once again. Please try this patch (attached). -- wbr, pluknet --0016e64aefda827b7b04a6ec9043 Content-Type: text/plain; charset=US-ASCII; name="mld6.locking.txt" Content-Disposition: attachment; filename="mld6.locking.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gpjnoi020 SW5kZXg6IHN5cy9uZXRpbmV0Ni9tbGQ2LmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc3lzL25ldGluZXQ2L21s ZDYuYwkocmV2aXNpb24gMjIzMDczKQorKysgc3lzL25ldGluZXQ2L21sZDYuYwkod29ya2luZyBj b3B5KQpAQCAtNjgwLDcgKzY4MCw2IEBACiAKIAlJTjZfTVVMVElfTE9DSygpOwogCU1MRF9MT0NL KCk7Ci0JSUZfQUREUl9MT0NLKGlmcCk7CiAKIAkvKgogCSAqIFN3aXRjaCB0byBNTER2MSBob3N0 IGNvbXBhdGliaWxpdHkgbW9kZS4KQEAgLTcwMCw2ICs2OTksNyBAQAogCQkgKi8KIAkJQ1RSMihL VFJfTUxELCAicHJvY2VzcyB2MSBnZW5lcmFsIHF1ZXJ5IG9uIGlmcCAlcCglcykiLAogCQkgICAg aWZwLCBpZnAtPmlmX3huYW1lKTsKKwkJSUZfQUREUl9MT0NLKGlmcCk7CiAJCVRBSUxRX0ZPUkVB Q0goaWZtYSwgJmlmcC0+aWZfbXVsdGlhZGRycywgaWZtYV9saW5rKSB7CiAJCQlpZiAoaWZtYS0+ aWZtYV9hZGRyLT5zYV9mYW1pbHkgIT0gQUZfSU5FVDYgfHwKIAkJCSAgICBpZm1hLT5pZm1hX3By b3Rvc3BlYyA9PSBOVUxMKQpAQCAtNzA3LDYgKzcwNyw3IEBACiAJCQlpbm0gPSAoc3RydWN0IGlu Nl9tdWx0aSAqKWlmbWEtPmlmbWFfcHJvdG9zcGVjOwogCQkJbWxkX3YxX3VwZGF0ZV9ncm91cChp bm0sIHRpbWVyKTsKIAkJfQorCQlJRl9BRERSX1VOTE9DSyhpZnApOwogCX0gZWxzZSB7CiAJCS8q CiAJCSAqIE1MRHYxIEdyb3VwLVNwZWNpZmljIFF1ZXJ5LgpAQCAtNzI0LDcgKzcyNSw2IEBACiAJ CWluNl9jbGVhcnNjb3BlKCZtbGQtPm1sZF9hZGRyKTsKIAl9CiAKLQlJRl9BRERSX1VOTE9DSyhp ZnApOwogCU1MRF9VTkxPQ0soKTsKIAlJTjZfTVVMVElfVU5MT0NLKCk7CiAKQEAgLTg4OCw3ICs4 ODgsNiBAQAogCiAJSU42X01VTFRJX0xPQ0soKTsKIAlNTERfTE9DSygpOwotCUlGX0FERFJfTE9D SyhpZnApOwogCiAJbWxpID0gTUxEX0lGSU5GTyhpZnApOwogCUtBU1NFUlQobWxpICE9IE5VTEws ICgiJXM6IG5vIG1sZF9pZmluZm8gZm9yIGlmcCAlcCIsIF9fZnVuY19fLCBpZnApKTsKQEAgLTk2 NCw3ICs5NjMsNiBAQAogCX0KIAogb3V0X2xvY2tlZDoKLQlJRl9BRERSX1VOTE9DSyhpZnApOwog CU1MRF9VTkxPQ0soKTsKIAlJTjZfTVVMVElfVU5MT0NLKCk7CiAK --0016e64aefda827b7b04a6ec9043-- From owner-freebsd-net@FreeBSD.ORG Thu Jun 30 12:16:41 2011 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 C6ACB1065678; Thu, 30 Jun 2011 12:16:41 +0000 (UTC) (envelope-from pluknet@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 9E5CE8FC15; Thu, 30 Jun 2011 12:16:41 +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 p5UCGfpS054861; Thu, 30 Jun 2011 12:16:41 GMT (envelope-from pluknet@freefall.freebsd.org) Received: (from pluknet@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p5UCGf1E054856; Thu, 30 Jun 2011 12:16:41 GMT (envelope-from pluknet) Date: Thu, 30 Jun 2011 12:16:41 GMT Message-Id: <201106301216.p5UCGf1E054856@freefall.freebsd.org> To: tps@vr-web.de, pluknet@FreeBSD.org, freebsd-net@FreeBSD.org From: pluknet@FreeBSD.org Cc: Subject: Re: kern/158426: [e1000] [panic] _mtx_lock_sleep: recursed on non-recursive mutex if_addr_mtx @ /usr/src/sys/netinet6/mld6.c:1676 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, 30 Jun 2011 12:16:41 -0000 Synopsis: [e1000] [panic] _mtx_lock_sleep: recursed on non-recursive mutex if_addr_mtx @ /usr/src/sys/netinet6/mld6.c:1676 State-Changed-From-To: open->feedback State-Changed-By: pluknet State-Changed-When: Thu Jun 30 12:16:24 UTC 2011 State-Changed-Why: Feedback requested. http://www.freebsd.org/cgi/query-pr.cgi?pr=158426 From owner-freebsd-net@FreeBSD.ORG Thu Jun 30 12:22:57 2011 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 63235106564A for ; Thu, 30 Jun 2011 12:22:57 +0000 (UTC) (envelope-from ray@freebsd.org) Received: from dlink.ua (smtp.dlink.ua [193.138.187.146]) by mx1.freebsd.org (Postfix) with ESMTP id 0269A8FC0A for ; Thu, 30 Jun 2011 12:22:55 +0000 (UTC) Received: from gw-lan1.kiev.dlink.ua ([192.168.10.10] helo=terran.dlink.ua) by dlink.ua with smtp (Exim 4.63) (envelope-from ) id 1QcGBL-0001Rg-8g for freebsd-net@freebsd.org; Thu, 30 Jun 2011 15:17:19 +0300 Date: Thu, 30 Jun 2011 15:22:49 +0300 From: Aleksandr Rybalko To: freebsd-net@freebsd.org Message-Id: <20110630152249.f369822f.ray@freebsd.org> Organization: FreeBSD Project X-Mailer: Sylpheed 2.7.1 (GTK+ 2.20.1; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Multipart=_Thu__30_Jun_2011_15_22_49_+0300_Nm_S4zP.J.=dEWOr" Subject: Ralink Ethernet MAC support 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: Thu, 30 Jun 2011 12:22:57 -0000 This is a multi-part message in MIME format. --Multipart=_Thu__30_Jun_2011_15_22_49_+0300_Nm_S4zP.J.=dEWOr Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi folks, I have a patch that enable support of Ethernet MAC on most Ralink system-on-chip. I use it more than half year and it works well. But still have some problem, one of it: I still not found why driver stop receive frames after ifconfig rt0 down/ifconfig rt0 up. Maybe somebody want to test and/or help me with development. Driver still don't support VLAN/PPPoE offload, but able to transmit at 88Mbps on 384MHz MIPS32 SoC. Usage: # Enable if_rt device rt # Enable debug messages options IF_RT_DEBUG # Enable PHY support (untested because I don't seen such devices # with PHYs attached to it yet, only attached to internal switch in # RT305xF SoCs) options IF_RT_PHY_SUPPORT opt_if_rt.h # count of allocated dma ring buffers options IF_RT_RING_DATA_COUNT opt_if_rt.h I will glad to see any comments/feedback about it. URL: http://my.ddteam.net/files/2011-06-30_if_rt.patch -- Aleksandr Rybalko --Multipart=_Thu__30_Jun_2011_15_22_49_+0300_Nm_S4zP.J.=dEWOr Content-Type: text/x-diff; name="if_rt.patch" Content-Disposition: attachment; filename="if_rt.patch" Content-Transfer-Encoding: 7bit Index: sys/conf/options.mips =================================================================== --- sys/conf/options.mips (revision 223691) +++ sys/conf/options.mips (working copy) @@ -70,3 +70,11 @@ # Options that control the Atheros SoC peripherals # ARGE_DEBUG opt_global.h + +# +# Options that control the Ralink RT305xF Etherenet MAC. +# +IF_RT_DEBUG opt_if_rt.h +IF_RT_PHY_SUPPORT opt_if_rt.h +IF_RT_RING_DATA_COUNT opt_if_rt.h + Index: sys/conf/files.mips =================================================================== --- sys/conf/files.mips (revision 223691) +++ sys/conf/files.mips (working copy) @@ -106,4 +106,5 @@ dev/hwpmc/hwpmc_mips.c optional hwpmc dev/hwpmc/hwpmc_mips24k.c optional hwpmc +dev/rt/if_rt.c optional rt dev/nvram2env/nvram2env.c optional nvram2env Index: sys/dev/rt/if_rtvar.h =================================================================== --- sys/dev/rt/if_rtvar.h (revision 0) +++ sys/dev/rt/if_rtvar.h (revision 0) @@ -0,0 +1,276 @@ + +/*- + * Copyright (c) 2010-2011 Aleksandr Rybalko + * Copyright (c) 2009-2010 Alexander Egorenkov + * Copyright (c) 2009 Damien Bergamini + * + * Permission to use, copy, modify, and distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES + * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF + * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR + * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES + * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN + * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF + * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. + */ + +#ifndef _RT_SOFTC_H_ +#define _RT_SOFTC_H_ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include + +#include +#include +#include +#include +#include +#include +#include + +#include "opt_if_rt.h" + +#define RT_SOFTC_LOCK(sc) mtx_lock(&(sc)->lock) +#define RT_SOFTC_UNLOCK(sc) mtx_unlock(&(sc)->lock) +#define RT_SOFTC_ASSERT_LOCKED(sc) mtx_assert(&(sc)->lock, MA_OWNED) + +#define RT_SOFTC_TX_RING_LOCK(ring) mtx_lock(&(ring)->lock) +#define RT_SOFTC_TX_RING_UNLOCK(ring) mtx_unlock(&(ring)->lock) +#define RT_SOFTC_TX_RING_ASSERT_LOCKED(ring) mtx_assert(&(ring)->lock, MA_OWNED) + +#define RT_SOFTC_TX_RING_COUNT 4 + +#ifndef IF_RT_RING_DATA_COUNT +#define IF_RT_RING_DATA_COUNT 128 +#endif + +#define RT_SOFTC_RX_RING_DATA_COUNT IF_RT_RING_DATA_COUNT + +#define RT_SOFTC_MAX_SCATTER 10 + +#define RT_SOFTC_TX_RING_DATA_COUNT (IF_RT_RING_DATA_COUNT/4) +#define RT_SOFTC_TX_RING_DESC_COUNT \ + (RT_SOFTC_TX_RING_DATA_COUNT * RT_SOFTC_MAX_SCATTER) + + +#define RT_TXDESC_SDL1_BURST (1 << 15) +#define RT_TXDESC_SDL1_LASTSEG (1 << 14) +#define RT_TXDESC_SDL0_DDONE (1 << 15) +#define RT_TXDESC_SDL0_LASTSEG (1 << 14) +struct rt_txdesc +{ + uint32_t sdp0; + uint16_t sdl1; + uint16_t sdl0; + uint32_t sdp1; + uint8_t vid; +#define TXDSCR_INS_VLAN_TAG 0x80 +#define TXDSCR_VLAN_PRIO_MASK 0x70 +#define TXDSCR_VLAN_IDX_MASK 0x0f + uint8_t pppoe; +#define TXDSCR_USR_DEF_FLD 0x80 +#define TXDSCR_INS_PPPOE_HDR 0x10 +#define TXDSCR_PPPOE_SID_MASK 0x0f + uint8_t qn; +#define TXDSCR_QUEUE_MASK 0x07 + uint8_t dst; +#define TXDSCR_IP_CSUM_GEN 0x80 +#define TXDSCR_UDP_CSUM_GEN 0x40 +#define TXDSCR_TCP_CSUM_GEN 0x20 +#define TXDSCR_DST_PORT_MASK 0x07 +#define TXDSCR_DST_PORT_CPU 0x00 +#define TXDSCR_DST_PORT_GDMA1 0x01 +#define TXDSCR_DST_PORT_GDMA2 0x02 +#define TXDSCR_DST_PORT_PPE 0x06 +#define TXDSCR_DST_PORT_DISC 0x07 +} __packed; + + +#define RT_RXDESC_SDL0_DDONE (1 << 15) +struct rt_rxdesc +{ + uint32_t sdp0; + uint16_t sdl1; + uint16_t sdl0; + uint32_t sdp1; + uint16_t foe; +#define RXDSXR_FOE_ENTRY_VALID 0x40 +#define RXDSXR_FOE_ENTRY_MASK 0x3f + uint8_t ai; +#define RXDSXR_AI_COU_REASON 0xff +#define RXDSXR_AI_PARSER_RSLT_MASK 0xff + uint8_t src; +#define RXDSXR_SRC_IPFVLD 0x80 +#define RXDSXR_SRC_L4FVLD 0x40 +#define RXDSXR_SRC_IP_CSUM_FAIL 0x20 +#define RXDSXR_SRC_L4_CSUM_FAIL 0x10 +#define RXDSXR_SRC_AIS 0x08 +#define RXDSXR_SRC_PORT_MASK 0x07 +} __packed; + + + +struct rt_softc_rx_data +{ + bus_dmamap_t dma_map; + struct mbuf *m; +}; + +struct rt_softc_rx_ring +{ + bus_dma_tag_t desc_dma_tag; + bus_dmamap_t desc_dma_map; + bus_addr_t desc_phys_addr; + struct rt_rxdesc *desc; + bus_dma_tag_t data_dma_tag; + bus_dmamap_t spare_dma_map; + struct rt_softc_rx_data data[RT_SOFTC_RX_RING_DATA_COUNT]; + int cur; +}; + +struct rt_softc_tx_data +{ + bus_dmamap_t dma_map; + struct mbuf *m; +}; + +struct rt_softc_tx_ring +{ + struct mtx lock; + bus_dma_tag_t desc_dma_tag; + bus_dmamap_t desc_dma_map; + bus_addr_t desc_phys_addr; + struct rt_txdesc *desc; + int desc_queued; + int desc_cur; + int desc_next; + bus_dma_tag_t seg0_dma_tag; + bus_dmamap_t seg0_dma_map; + bus_addr_t seg0_phys_addr; + uint8_t *seg0; + bus_dma_tag_t data_dma_tag; + struct rt_softc_tx_data data[RT_SOFTC_TX_RING_DATA_COUNT]; + int data_queued; + int data_cur; + int data_next; + int qid; +}; + +struct rt_softc +{ + device_t dev; + struct mtx lock; + uint32_t flags; + + int mem_rid; + struct resource *mem; + int irq_rid; + struct resource *irq; + void *irqh; + + bus_space_tag_t bst; + bus_space_handle_t bsh; + + struct ifnet *ifp; + int if_flags; + struct ifmedia rt_ifmedia; + + uint32_t mac_rev; + uint8_t mac_addr[ETHER_ADDR_LEN]; + device_t rt_miibus; + + uint32_t intr_enable_mask; + uint32_t intr_disable_mask; + uint32_t intr_pending_mask; + + struct task rx_done_task; + int rx_process_limit; + struct task tx_done_task; + struct task periodic_task; + struct callout periodic_ch; + unsigned long periodic_round; + struct taskqueue *taskqueue; + + struct rt_softc_rx_ring rx_ring; + struct rt_softc_tx_ring tx_ring[RT_SOFTC_TX_RING_COUNT]; + int tx_ring_mgtqid; + + struct callout tx_watchdog_ch; + int tx_timer; + + /* statistic counters */ + + unsigned long interrupts; + unsigned long tx_coherent_interrupts; + unsigned long rx_coherent_interrupts; + unsigned long rx_interrupts; + unsigned long rx_delay_interrupts; + unsigned long tx_interrupts[RT_SOFTC_TX_RING_COUNT]; + unsigned long tx_delay_interrupts; + unsigned long tx_data_queue_full[RT_SOFTC_TX_RING_COUNT]; + unsigned long tx_watchdog_timeouts; + unsigned long tx_defrag_packets; + unsigned long no_tx_desc_avail; + unsigned long rx_mbuf_alloc_errors; + unsigned long rx_mbuf_dmamap_errors; + unsigned long tx_queue_not_empty[2]; + + unsigned long rx_bytes; + unsigned long rx_packets; + unsigned long rx_crc_err; + unsigned long rx_phy_err; + unsigned long rx_dup_packets; + unsigned long rx_fifo_overflows; + unsigned long rx_short_err; + unsigned long rx_long_err; + unsigned long tx_bytes; + unsigned long tx_packets; + unsigned long tx_skip; + unsigned long tx_collision; + + int phy_addr; + +#ifdef IF_RT_DEBUG + int debug; +#endif +}; + +#ifdef IF_RT_DEBUG + +enum +{ + RT_DEBUG_RX = 0x00000001, + RT_DEBUG_TX = 0x00000002, + RT_DEBUG_INTR = 0x00000004, + RT_DEBUG_STATE = 0x00000008, + RT_DEBUG_STATS = 0x00000010, + RT_DEBUG_PERIODIC = 0x00000020, + RT_DEBUG_WATCHDOG = 0x00000040, + RT_DEBUG_ANY = 0xffffffff +}; + +#define RT_DPRINTF(sc, m, fmt, ...) \ + do { if ((sc)->debug & (m)) \ + device_printf(sc->dev, fmt, __VA_ARGS__); } while (0) +#else +#define RT_DPRINTF(sc, m, fmt, ...) +#endif /* #ifdef IF_RT_DEBUG */ + +#endif /* #ifndef _RT_SOFTC_H_ */ Property changes on: sys/dev/rt/if_rtvar.h ___________________________________________________________________ Added: svn:mime-type + text/plain Added: svn:keywords + FreeBSD=%H Added: svn:eol-style + native Index: sys/dev/rt/if_rt.c =================================================================== --- sys/dev/rt/if_rt.c (revision 0) +++ sys/dev/rt/if_rt.c (revision 0) @@ -0,0 +1,2625 @@ +/*- + * Copyright (c) 2011, Aleksandr Rybalko + * based on hard work + * by Alexander Egorenkov + * and by Damien Bergamini + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice unmodified, this list of conditions, and the following + * disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + * + * $FreeBSD$ + */ + +#include "if_rtvar.h" +#include "if_rtreg.h" + +#include +#include +#include +#include +#include +#include +#include + +#include + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include + +#include +#include + +#ifdef IF_RT_PHY_SUPPORT +#include "miibus_if.h" +#endif + +/* + * Defines and macros + */ + +#define RT_MAX_AGG_SIZE 3840 + +#define RT_TX_DATA_SEG0_SIZE MJUMPAGESIZE + + +#define RT_MS(_v, _f) (((_v) & _f) >> _f##_S) +#define RT_SM(_v, _f) (((_v) << _f##_S) & _f) + +#define RT_TX_WATCHDOG_TIMEOUT 5 + +#define RT_WCID_RESERVED 0xff +#define RT_WCID_MCAST 0xf7 + +/* + * Data structures and types + */ + +/* + * Static function prototypes + */ + +static int rt_probe(device_t dev); +static int rt_attach(device_t dev); +static int rt_detach(device_t dev); +static int rt_shutdown(device_t dev); +static int rt_suspend(device_t dev); +static int rt_resume(device_t dev); +static void rt_init_locked(void *priv); +static void rt_init(void *priv); +static void rt_stop_locked(void *priv); +static void rt_stop(void *priv); +static void rt_start(struct ifnet *ifp); +static int rt_ioctl(struct ifnet *ifp, u_long cmd, caddr_t data); +static void rt_periodic(void *arg); +static void rt_tx_watchdog(void *arg); +static void rt_intr(void *arg); +static void rt_tx_coherent_intr(struct rt_softc *sc); +static void rt_rx_coherent_intr(struct rt_softc *sc); +static void rt_rx_delay_intr(struct rt_softc *sc); +static void rt_tx_delay_intr(struct rt_softc *sc); +static void rt_rx_intr(struct rt_softc *sc); +static void rt_tx_intr(struct rt_softc *sc, int qid); +static void rt_rx_done_task(void *context, int pending); +static void rt_tx_done_task(void *context, int pending); +static void rt_periodic_task(void *context, int pending); +static int rt_rx_eof(struct rt_softc *sc, int limit); +static void rt_tx_eof(struct rt_softc *sc, + struct rt_softc_tx_ring *ring); +static void rt_update_stats(struct rt_softc *sc); +static void rt_watchdog(struct rt_softc *sc); +static void rt_update_raw_counters(struct rt_softc *sc); +static void rt_intr_enable(struct rt_softc *sc, uint32_t intr_mask); +static void rt_intr_disable(struct rt_softc *sc, uint32_t intr_mask); +static int rt_txrx_enable(struct rt_softc *sc); +static int rt_alloc_rx_ring(struct rt_softc *sc, + struct rt_softc_rx_ring *ring); +static void rt_reset_rx_ring(struct rt_softc *sc, + struct rt_softc_rx_ring *ring); +static void rt_free_rx_ring(struct rt_softc *sc, + struct rt_softc_rx_ring *ring); +static int rt_alloc_tx_ring(struct rt_softc *sc, + struct rt_softc_tx_ring *ring, int qid); +static void rt_reset_tx_ring(struct rt_softc *sc, + struct rt_softc_tx_ring *ring); +static void rt_free_tx_ring(struct rt_softc *sc, + struct rt_softc_tx_ring *ring); +static void rt_dma_map_addr(void *arg, bus_dma_segment_t *segs, + int nseg, int error); +static void rt_sysctl_attach(struct rt_softc *sc); +#ifdef IF_RT_PHY_SUPPORT +void rt_miibus_statchg(device_t); +static int rt_miibus_readreg(device_t, int, int); +static int rt_miibus_writereg(device_t, int, int, int); +#endif +static int rt_ifmedia_upd(struct ifnet *); +static void rt_ifmedia_sts(struct ifnet *, struct ifmediareq *); + +SYSCTL_NODE(_hw, OID_AUTO, rt, CTLFLAG_RD, 0, "RT driver parameters"); + +#ifdef IF_RT_DEBUG +static int rt_debug = 0; +SYSCTL_INT(_hw_rt, OID_AUTO, debug, CTLFLAG_RW, &rt_debug, 0, "RT debug level"); +TUNABLE_INT("hw.rt.debug", &rt_debug); +#endif + +/* + * rt_probe + */ +static int +rt_probe(device_t dev) +{ + device_set_desc(dev, "Ralink RT305XF onChip Ethernet MAC"); + return 0; +} + +/* + * macaddr_atoi - translate string MAC address to uint8_t array + */ +static int +macaddr_atoi(const char *str, uint8_t *mac) +{ + int count, i; + unsigned int amac[6]; /* Aligned version */ + + count = sscanf(str, "%x%*c%x%*c%x%*c%x%*c%x%*c%x", + &amac[0], &amac[1], &amac[2], + &amac[3], &amac[4], &amac[5]); + if (count < 6) { + memset(mac, 0, 6); + return (1); + } + + /* Copy aligned to result */ + for (i = 0; i < count; i ++) + mac[i] = (amac[i] & 0xff); + + return (0); +} + +#ifdef USE_GENERATED_MAC_ADDRES +static char * +kernenv_next(char *cp) +{ + + if (cp != NULL) { + while (*cp != 0) + cp++; + cp++; + if (*cp == 0) + cp = NULL; + } + return (cp); +} + +/* + * generate_mac(uin8_t *mac) implemented MAC address generator. + * + * They use 'b','s','d' signature and 3 octets from CRC32 on kenv. + * + * MAC = 'b', 's', 'd', CRC[3]^CRC[2], CRC[1], CRC[0] + * + * As result we have MAC address, that do not change between reboots, if we + * not change hints or bootloader info. + */ +static void +generate_mac(uint8_t *mac) +{ + unsigned char *cp; + int i = 0; + uint32_t crc = 0xffffffff; + + /* Generate CRC32 on kenv */ + if (dynamic_kenv) { + for (cp = kenvp[0]; cp != NULL; cp = kenvp[++i]) { + crc = calculate_crc32c(crc, cp, strlen(cp) + 1); + } + + } else { + for (cp = kern_envp; cp != NULL; cp = kernenv_next(cp)) { + crc = calculate_crc32c(crc, cp, strlen(cp) + 1); + } + } + crc = ~crc; + + mac[0] = 'b'; + mac[1] = 's'; + mac[2] = 'd'; + mac[3] = (crc >> 24) ^ ((crc >> 16) & 0xff); + mac[4] = (crc >> 8) & 0xff; + mac[5] = crc & 0xff; +} +#endif + +static int +ether_request_mac(device_t dev, uint8_t *mac) +{ + char *var; + + /* + * "ethaddr" is passed via envp on RedBoot platforms + * "kmac" is passed via argv on RouterBOOT platforms + */ +#if defined(__U_BOOT__) || defined(__REDBOOT__) || defined(__ROUTERBOOT__) + if ((var = getenv("ethaddr")) != NULL || + (var = getenv("kmac")) != NULL ) { + + if(!macaddr_atoi(var, mac)) { + printf("%s: use %s macaddr from KENV\n", + device_get_nameunit(dev), var); + freeenv(var); + return (0); + } + freeenv(var); + } +#endif + + /* + * Try from hints + * hint.[dev].[unit].macaddr + */ + if (!resource_string_value(device_get_name(dev), device_get_unit(dev), + "macaddr", (const char **)&var)) { + + if(!macaddr_atoi(var, mac)) { + printf("%s: use %s macaddr from hints\n", + device_get_nameunit(dev), var); + return (0); + } + } + +#ifdef USE_GENERATED_MAC_ADDRES + generate_mac(mac); + + device_printf(dev, "use generated %02x:%02x:%02x:%02x:%02x:%02x " + "macaddr\n", mac[0], mac[1], mac[2], mac[3], mac[4], mac[5]); +#else + /* Hardcoded */ + mac[0] = 0x00; + mac[1] = 0x18; + mac[2] = 0xe7; + mac[3] = 0xd5; + mac[4] = 0x83; + mac[5] = 0x90; + + device_printf(dev, "use hardcoded 00:18:e7:d5:83:90 macaddr\n"); +#endif + + return (0); +} + +/* + * rt_attach + */ +static int +rt_attach(device_t dev) +{ + struct rt_softc *sc; + struct ifnet *ifp; + int error, i; + + sc = device_get_softc(dev); + + sc->dev = dev; + + mtx_init(&sc->lock, device_get_nameunit(dev), MTX_NETWORK_LOCK, + MTX_DEF | MTX_RECURSE); + + sc->mem_rid = 0; + sc->mem = bus_alloc_resource_any(dev, SYS_RES_MEMORY, &sc->mem_rid, + RF_ACTIVE); + if (sc->mem == NULL) { + device_printf(dev, "could not allocate memory resource\n"); + error = ENXIO; + goto fail; + } + + sc->bst = rman_get_bustag(sc->mem); + sc->bsh = rman_get_bushandle(sc->mem); + + sc->irq_rid = 0; + sc->irq = bus_alloc_resource_any(dev, SYS_RES_IRQ, &sc->irq_rid, + RF_ACTIVE); + if (sc->irq == NULL) { + device_printf(dev, "could not allocate interrupt resource\n"); + error = ENXIO; + goto fail; + } + +#ifdef IF_RT_DEBUG + sc->debug = rt_debug; + + SYSCTL_ADD_INT(device_get_sysctl_ctx(dev), + SYSCTL_CHILDREN(device_get_sysctl_tree(dev)), OID_AUTO, + "debug", CTLFLAG_RW, &sc->debug, 0, "rt debug level"); +#endif + + device_printf(dev, "RT305XF Ethernet MAC (rev 0x%08x)\n", sc->mac_rev); + + /* Reset hardware */ + RT_WRITE(sc, GE_PORT_BASE + FE_RST_GLO, PSE_RESET); + + RT_WRITE(sc, GDMA1_BASE + GDMA_FWD_CFG, + ( + GDM_ICS_EN | /* Enable IP Csum */ + GDM_TCS_EN | /* Enable TCP Csum */ + GDM_UCS_EN | /* Enable UDP Csum */ + GDM_STRPCRC | /* Strip CRC from packet */ + GDM_DST_PORT_CPU << GDM_UFRC_P_SHIFT | /* Forward UCast to CPU */ + GDM_DST_PORT_CPU << GDM_BFRC_P_SHIFT | /* Forward BCast to CPU */ + GDM_DST_PORT_CPU << GDM_MFRC_P_SHIFT | /* Forward MCast to CPU */ + GDM_DST_PORT_CPU << GDM_OFRC_P_SHIFT /* Forward Other to CPU */ + )); + + + /* allocate Tx and Rx rings */ + for (i = 0; i < RT_SOFTC_TX_RING_COUNT; i++) { + error = rt_alloc_tx_ring(sc, &sc->tx_ring[i], i); + if (error != 0) { + device_printf(dev, "could not allocate Tx ring #%d\n", + i); + goto fail; + } + } + + sc->tx_ring_mgtqid = 5; + + error = rt_alloc_rx_ring(sc, &sc->rx_ring); + if (error != 0) { + device_printf(dev, "could not allocate Rx ring\n"); + goto fail; + } + + callout_init(&sc->periodic_ch, 0); + callout_init_mtx(&sc->tx_watchdog_ch, &sc->lock, 0); + + ifp = sc->ifp = if_alloc(IFT_ETHER); + if (ifp == NULL) { + device_printf(dev, "could not if_alloc()\n"); + error = ENOMEM; + goto fail; + } + + ifp->if_softc = sc; + if_initname(ifp, device_get_name(sc->dev), device_get_unit(sc->dev)); + ifp->if_flags = IFF_BROADCAST | IFF_SIMPLEX | IFF_MULTICAST; + ifp->if_init = rt_init; + ifp->if_ioctl = rt_ioctl; + ifp->if_start = rt_start; + ifp->if_mtu = ETHERMTU; +#define RT_TX_QLEN 256 + + IFQ_SET_MAXLEN(&ifp->if_snd, RT_TX_QLEN); + ifp->if_snd.ifq_drv_maxlen = RT_TX_QLEN; + IFQ_SET_READY(&ifp->if_snd); + +#ifdef IF_RT_PHY_SUPPORT + error = mii_attach(dev, &sc->rt_miibus, ifp, rt_ifmedia_upd, + rt_ifmedia_sts, BMSR_DEFCAPMASK, MII_PHY_ANY, MII_OFFSET_ANY, 0); + if (error != 0) { + device_printf(dev, "attaching PHYs failed\n"); + error = ENXIO; + goto fail; + } +#else + ifmedia_init(&sc->rt_ifmedia, 0, rt_ifmedia_upd, rt_ifmedia_sts); + ifmedia_add(&sc->rt_ifmedia, IFM_ETHER | IFM_100_TX | IFM_FDX, 0, NULL); + ifmedia_set(&sc->rt_ifmedia, IFM_ETHER | IFM_100_TX | IFM_FDX); + +#endif /* IF_RT_PHY_SUPPORT */ + + ether_request_mac(dev, sc->mac_addr); + ether_ifattach(ifp, sc->mac_addr); + + /* + * Tell the upper layer(s) we support long frames. + */ + ifp->if_data.ifi_hdrlen = sizeof(struct ether_vlan_header); + ifp->if_capabilities |= IFCAP_VLAN_MTU; + ifp->if_capenable |= IFCAP_VLAN_MTU; + ifp->if_capabilities |= IFCAP_RXCSUM|IFCAP_TXCSUM; + ifp->if_capenable |= IFCAP_RXCSUM|IFCAP_TXCSUM; + + /* init task queue */ + TASK_INIT(&sc->rx_done_task, 0, rt_rx_done_task, sc); + TASK_INIT(&sc->tx_done_task, 0, rt_tx_done_task, sc); + TASK_INIT(&sc->periodic_task, 0, rt_periodic_task, sc); + + sc->rx_process_limit = 100; + + sc->taskqueue = taskqueue_create("rt_taskq", M_NOWAIT, + taskqueue_thread_enqueue, &sc->taskqueue); + + taskqueue_start_threads(&sc->taskqueue, 1, PI_NET, "%s taskq", + device_get_nameunit(sc->dev)); + + rt_sysctl_attach(sc); + + /* set up interrupt */ + error = bus_setup_intr(dev, sc->irq, INTR_TYPE_NET | INTR_MPSAFE, + NULL, rt_intr, sc, &sc->irqh); + if (error != 0) { + printf("%s: could not set up interrupt\n", + device_get_nameunit(dev)); + goto fail; + } +#ifdef IF_RT_DEBUG + device_printf(dev, "debug var at %#08x\n", (u_int)&(sc->debug)); +#endif + + return 0; + +fail: + + /* free Tx and Rx rings */ + for (i = 0; i < RT_SOFTC_TX_RING_COUNT; i++) + rt_free_tx_ring(sc, &sc->tx_ring[i]); + + rt_free_rx_ring(sc, &sc->rx_ring); + + mtx_destroy(&sc->lock); + + if (sc->mem != NULL) + bus_release_resource(dev, SYS_RES_MEMORY, sc->mem_rid, sc->mem); + + if (sc->irq != NULL) + bus_release_resource(dev, SYS_RES_IRQ, sc->irq_rid, sc->irq); + + return error; +} + +/* + * Set media options. + */ +static int +rt_ifmedia_upd(struct ifnet *ifp) +{ + struct rt_softc *sc; +#ifdef IF_RT_PHY_SUPPORT + struct mii_data *mii; + int error = 0; + + sc = ifp->if_softc; + RT_SOFTC_LOCK(sc); + + mii = device_get_softc(sc->rt_miibus); + if (mii->mii_instance) { + struct mii_softc *miisc; + for (miisc = LIST_FIRST(&mii->mii_phys); miisc != NULL; + miisc = LIST_NEXT(miisc, mii_list)) + mii_phy_reset(miisc); + } + if (mii) + error = mii_mediachg(mii); + RT_SOFTC_UNLOCK(sc); + + return (error); + +#else /* !IF_RT_PHY_SUPPORT */ + + struct ifmedia *ifm; + struct ifmedia_entry *ife; + + sc = ifp->if_softc; + ifm = &sc->rt_ifmedia; + ife = ifm->ifm_cur; + + if (IFM_TYPE(ifm->ifm_media) != IFM_ETHER) + return (EINVAL); + + if (IFM_SUBTYPE(ife->ifm_media) == IFM_AUTO) { + device_printf(sc->dev, + "AUTO is not supported for multiphy MAC"); + return (EINVAL); + } + + /* + * Ignore everything + */ + return (0); +#endif /* IF_RT_PHY_SUPPORT */ +} + +/* + * Report current media status. + */ +static void +rt_ifmedia_sts(struct ifnet *ifp, struct ifmediareq *ifmr) +{ +#ifdef IF_RT_PHY_SUPPORT + struct rt_softc *sc; + struct mii_data *mii; + + sc = ifp->if_softc; + + RT_SOFTC_LOCK(sc); + mii = device_get_softc(sc->rt_miibus); + mii_pollstat(mii); + ifmr->ifm_active = mii->mii_media_active; + ifmr->ifm_status = mii->mii_media_status; + ifmr->ifm_active = IFM_ETHER | IFM_100_TX | IFM_FDX; + ifmr->ifm_status = IFM_AVALID | IFM_ACTIVE; + RT_SOFTC_UNLOCK(sc); +#else /* !IF_RT_PHY_SUPPORT */ + + ifmr->ifm_status = IFM_AVALID | IFM_ACTIVE; + ifmr->ifm_active = IFM_ETHER | IFM_100_TX | IFM_FDX; +#endif /* IF_RT_PHY_SUPPORT */ +} + + +/* + * rt_detach + */ +static int +rt_detach(device_t dev) +{ + struct rt_softc *sc; + struct ifnet *ifp; + int i; + + sc = device_get_softc(dev); + ifp = sc->ifp; + + RT_DPRINTF(sc, RT_DEBUG_ANY, "detaching\n"); + + RT_SOFTC_LOCK(sc); + + ifp->if_drv_flags &= ~(IFF_DRV_RUNNING | IFF_DRV_OACTIVE); + + callout_stop(&sc->periodic_ch); + callout_stop(&sc->tx_watchdog_ch); + + taskqueue_drain(sc->taskqueue, &sc->rx_done_task); + taskqueue_drain(sc->taskqueue, &sc->tx_done_task); + taskqueue_drain(sc->taskqueue, &sc->periodic_task); + + /* free Tx and Rx rings */ + for (i = 0; i < RT_SOFTC_TX_RING_COUNT; i++) + rt_free_tx_ring(sc, &sc->tx_ring[i]); + + rt_free_rx_ring(sc, &sc->rx_ring); + + RT_SOFTC_UNLOCK(sc); + +#ifdef IF_RT_PHY_SUPPORT + if (sc->rt_miibus != NULL) + device_delete_child(dev, sc->rt_miibus); +#endif + + ether_ifdetach(ifp); + if_free(ifp); + + taskqueue_free(sc->taskqueue); + + mtx_destroy(&sc->lock); + + bus_generic_detach(dev); + bus_teardown_intr(dev, sc->irq, sc->irqh); + bus_release_resource(dev, SYS_RES_IRQ, sc->irq_rid, sc->irq); + bus_release_resource(dev, SYS_RES_MEMORY, sc->mem_rid, sc->mem); + + return 0; +} + +/* + * rt_shutdown + */ +static int +rt_shutdown(device_t dev) +{ + struct rt_softc *sc; + + sc = device_get_softc(dev); + RT_DPRINTF(sc, RT_DEBUG_ANY, "shutting down\n"); + rt_stop(sc); + + return 0; +} + +/* + * rt_suspend + */ +static int +rt_suspend(device_t dev) +{ + struct rt_softc *sc; + + sc = device_get_softc(dev); + RT_DPRINTF(sc, RT_DEBUG_ANY, "suspending\n"); + rt_stop(sc); + + return 0; +} + +/* + * rt_resume + */ +static int +rt_resume(device_t dev) +{ + struct rt_softc *sc; + struct ifnet *ifp; + + sc = device_get_softc(dev); + ifp = sc->ifp; + + RT_DPRINTF(sc, RT_DEBUG_ANY, "resuming\n"); + + if (ifp->if_flags & IFF_UP) + rt_init(sc); + + return 0; +} + +/* + * rt_init_locked + */ +static void +rt_init_locked(void *priv) +{ + struct rt_softc *sc; + struct ifnet *ifp; +#ifdef IF_RT_PHY_SUPPORT + struct mii_data *mii; +#endif + int i, ntries; + uint32_t tmp; + + sc = priv; + ifp = sc->ifp; +#ifdef IF_RT_PHY_SUPPORT + mii = device_get_softc(sc->rt_miibus); +#endif + + RT_DPRINTF(sc, RT_DEBUG_ANY, "initializing\n"); + + RT_SOFTC_ASSERT_LOCKED(sc); + + /* hardware reset */ + RT_WRITE(sc, GE_PORT_BASE + FE_RST_GLO, PSE_RESET); + rt305x_sysctl_set(SYSCTL_RSTCTRL, SYSCTL_RSTCTRL_FRENG); + + /* Fwd to CPU (uni|broad|multi)cast and Unknown */ + RT_WRITE(sc, GDMA1_BASE + GDMA_FWD_CFG, + ( + GDM_ICS_EN | /* Enable IP Csum */ + GDM_TCS_EN | /* Enable TCP Csum */ + GDM_UCS_EN | /* Enable UDP Csum */ + GDM_STRPCRC | /* Strip CRC from packet */ + GDM_DST_PORT_CPU << GDM_UFRC_P_SHIFT | /* Forward UCast to CPU */ + GDM_DST_PORT_CPU << GDM_BFRC_P_SHIFT | /* Forward BCast to CPU */ + GDM_DST_PORT_CPU << GDM_MFRC_P_SHIFT | /* Forward MCast to CPU */ + GDM_DST_PORT_CPU << GDM_OFRC_P_SHIFT /* Forward Other to CPU */ + )); + + /* disable DMA engine */ + RT_WRITE(sc, PDMA_BASE + PDMA_GLO_CFG, 0); + + RT_WRITE(sc, PDMA_BASE + PDMA_RST_IDX, 0xffffffff); + + + /* wait while DMA engine is busy */ + for (ntries = 0; ntries < 100; ntries++) { + tmp = RT_READ(sc, PDMA_BASE + PDMA_GLO_CFG); + if (!(tmp & (FE_TX_DMA_BUSY | FE_RX_DMA_BUSY))) + break; + + DELAY(1000); + } + + if (ntries == 100) { + device_printf(sc->dev, "timeout waiting for DMA engine\n"); + goto fail; + } + + + /* reset Rx and Tx rings */ + tmp = FE_RST_DRX_IDX0 | + FE_RST_DTX_IDX3 | + FE_RST_DTX_IDX2 | + FE_RST_DTX_IDX1 | + FE_RST_DTX_IDX0; + + RT_WRITE(sc, PDMA_BASE + PDMA_RST_IDX, tmp); + + /* XXX switch set mac address */ + + for (i = 0; i < RT_SOFTC_TX_RING_COUNT; i++) + rt_reset_tx_ring(sc, &sc->tx_ring[i]); + + for (i = 0; i < RT_SOFTC_TX_RING_COUNT; i++) { + /* update TX_BASE_PTRx */ + RT_WRITE(sc, PDMA_BASE + TX_BASE_PTR(i), + sc->tx_ring[i].desc_phys_addr); + RT_WRITE(sc, PDMA_BASE + TX_MAX_CNT(i), + RT_SOFTC_TX_RING_DESC_COUNT); + RT_WRITE(sc, PDMA_BASE + TX_CTX_IDX(i), 0); + } + + /* init Rx ring */ + rt_reset_rx_ring(sc, &sc->rx_ring); + + /* update RX_BASE_PTR0 */ + RT_WRITE(sc, PDMA_BASE + RX_BASE_PTR0, + sc->rx_ring.desc_phys_addr); + RT_WRITE(sc, PDMA_BASE + RX_MAX_CNT0, + RT_SOFTC_RX_RING_DATA_COUNT); + RT_WRITE(sc, PDMA_BASE + RX_CALC_IDX0, + RT_SOFTC_RX_RING_DATA_COUNT - 1); + + /* write back DDONE, 16byte burst enable RX/TX DMA */ + RT_WRITE(sc, PDMA_BASE + PDMA_GLO_CFG, + FE_TX_WB_DDONE | FE_DMA_BT_SIZE16 | FE_RX_DMA_EN | FE_TX_DMA_EN); + + /* disable interrupts mitigation */ + RT_WRITE(sc, PDMA_BASE + DELAY_INT_CFG, 0); + + /* clear pending interrupts */ + RT_WRITE(sc, GE_PORT_BASE + FE_INT_STATUS, 0xffffffff); + + /* enable interrupts */ + tmp = CNT_PPE_AF | + CNT_GDM_AF | + PSE_P2_FC | + GDM_CRC_DROP | + PSE_BUF_DROP | + GDM_OTHER_DROP | + PSE_P1_FC | + PSE_P0_FC | + PSE_FQ_EMPTY | + INT_TX_COHERENT | + INT_RX_COHERENT | + INT_TXQ3_DONE | + INT_TXQ2_DONE | + INT_TXQ1_DONE | + INT_TXQ0_DONE | + INT_RX_DONE; + + sc->intr_enable_mask = tmp; + + RT_WRITE(sc, GE_PORT_BASE + FE_INT_ENABLE, tmp); + + if (rt_txrx_enable(sc) != 0) + goto fail; + +#ifdef IF_RT_PHY_SUPPORT + if (mii) mii_mediachg(mii); +#endif /* IF_RT_PHY_SUPPORT */ + + ifp->if_drv_flags &= ~IFF_DRV_OACTIVE; + ifp->if_drv_flags |= IFF_DRV_RUNNING; + + sc->periodic_round = 0; + + callout_reset(&sc->periodic_ch, hz / 10, rt_periodic, sc); + + return; + +fail: + + rt_stop_locked(sc); +} + +/* + * rt_init + */ +static void +rt_init(void *priv) +{ + struct rt_softc *sc; + + sc = priv; + RT_SOFTC_LOCK(sc); + rt_init_locked(sc); + RT_SOFTC_UNLOCK(sc); +} + +/* + * rt_stop_locked + */ +static void +rt_stop_locked(void *priv) +{ + struct rt_softc *sc; + struct ifnet *ifp; + + sc = priv; + ifp = sc->ifp; + + RT_DPRINTF(sc, RT_DEBUG_ANY, "stopping\n"); + + RT_SOFTC_ASSERT_LOCKED(sc); + sc->tx_timer = 0; + ifp->if_drv_flags &= ~(IFF_DRV_RUNNING | IFF_DRV_OACTIVE); + callout_stop(&sc->periodic_ch); + callout_stop(&sc->tx_watchdog_ch); + RT_SOFTC_UNLOCK(sc); + taskqueue_block(sc->taskqueue); + + /* + * Sometime rt_stop_locked called from isr and we get panic + * When found, I fix it + */ +#ifdef notyet + taskqueue_drain(sc->taskqueue, &sc->rx_done_task); + taskqueue_drain(sc->taskqueue, &sc->tx_done_task); + taskqueue_drain(sc->taskqueue, &sc->periodic_task); +#endif + RT_SOFTC_LOCK(sc); + + /* disable interrupts */ + RT_WRITE(sc, GE_PORT_BASE + FE_INT_ENABLE, 0); + + + /* reset adapter */ + RT_WRITE(sc, GE_PORT_BASE + FE_RST_GLO, PSE_RESET); + + RT_WRITE(sc, GDMA1_BASE + GDMA_FWD_CFG, + ( + GDM_ICS_EN | /* Enable IP Csum */ + GDM_TCS_EN | /* Enable TCP Csum */ + GDM_UCS_EN | /* Enable UDP Csum */ + GDM_STRPCRC | /* Strip CRC from packet */ + GDM_DST_PORT_CPU << GDM_UFRC_P_SHIFT | /* Forward UCast to CPU */ + GDM_DST_PORT_CPU << GDM_BFRC_P_SHIFT | /* Forward BCast to CPU */ + GDM_DST_PORT_CPU << GDM_MFRC_P_SHIFT | /* Forward MCast to CPU */ + GDM_DST_PORT_CPU << GDM_OFRC_P_SHIFT /* Forward Other to CPU */ + )); + +} + +/* + * rt_stop + */ +static void +rt_stop(void *priv) +{ + struct rt_softc *sc; + + sc = priv; + RT_SOFTC_LOCK(sc); + rt_stop_locked(sc); + RT_SOFTC_UNLOCK(sc); +} + +/* + * rt_tx_data + */ +static int +rt_tx_data(struct rt_softc *sc, struct mbuf *m, int qid) +{ + struct ifnet *ifp; + struct rt_softc_tx_ring *ring; + struct rt_softc_tx_data *data; + struct rt_txdesc *desc; + struct mbuf *m_d; + bus_dma_segment_t dma_seg[RT_SOFTC_MAX_SCATTER]; + + int error, ndmasegs, ndescs, i; + + KASSERT(qid >= 0 && qid < RT_SOFTC_TX_RING_COUNT, + ("%s: Tx data: invalid qid=%d\n", + device_get_nameunit(sc->dev), qid)); + + RT_SOFTC_TX_RING_ASSERT_LOCKED(&sc->tx_ring[qid]); + + ifp = sc->ifp; + ring = &sc->tx_ring[qid]; + desc = &ring->desc[ring->desc_cur]; + data = &ring->data[ring->data_cur]; + + error = bus_dmamap_load_mbuf_sg(ring->data_dma_tag, data->dma_map, m, + dma_seg, &ndmasegs, 0); + if (error != 0) { + /* too many fragments, linearize */ + + RT_DPRINTF(sc, RT_DEBUG_TX, + "could not load mbuf DMA map, trying to linearize " + "mbuf: ndmasegs=%d, len=%d, error=%d\n", + ndmasegs, m->m_pkthdr.len, error); + + m_d = m_collapse(m, M_DONTWAIT, 16); + if (m_d == NULL) { + m_freem(m); + m = NULL; + return (ENOMEM); + } + m = m_d; + + sc->tx_defrag_packets++; + + error = bus_dmamap_load_mbuf_sg(ring->data_dma_tag, + data->dma_map, m, dma_seg, &ndmasegs, 0); + if (error != 0) { + device_printf(sc->dev, "could not load mbuf DMA map: " + "ndmasegs=%d, len=%d, error=%d\n", + ndmasegs, m->m_pkthdr.len, error); + m_freem(m); + return error; + } + } + + if (m->m_pkthdr.len == 0) + ndmasegs = 0; + + /* determine how many Tx descs are required */ + + ndescs = 1 + ndmasegs / 2; + if ((ring->desc_queued + ndescs) > (RT_SOFTC_TX_RING_DESC_COUNT - 2)) { + RT_DPRINTF(sc, RT_DEBUG_TX, "there are not enough Tx descs\n"); + + sc->no_tx_desc_avail++; + + bus_dmamap_unload(ring->data_dma_tag, data->dma_map); + m_freem(m); + return EFBIG; + } + + data->m = m; + + /* set up Tx descs */ + for (i = 0; i < ndmasegs; i += 2) { + + /* Set destenation */ + desc->dst = (TXDSCR_DST_PORT_GDMA1); + if ((ifp->if_capenable & IFCAP_TXCSUM) != 0) + desc->dst |= (TXDSCR_IP_CSUM_GEN|TXDSCR_UDP_CSUM_GEN| + TXDSCR_TCP_CSUM_GEN); + /* Set queue id */ + desc->qn = qid; + /* No PPPoE */ + desc->pppoe = 0; + /* No VLAN */ + desc->vid = 0; + + desc->sdp0 = htole32(dma_seg[i].ds_addr); + desc->sdl0 = htole16(dma_seg[i].ds_len | + ( ((i+1) == ndmasegs )?RT_TXDESC_SDL0_LASTSEG:0 )); + + if ((i+1) < ndmasegs) { + desc->sdp1 = htole32(dma_seg[i+1].ds_addr); + desc->sdl1 = htole16(dma_seg[i+1].ds_len | + ( ((i+2) == ndmasegs )?RT_TXDESC_SDL1_LASTSEG:0 )); + } else { + desc->sdp1 = 0; + desc->sdl1 = 0; + } + + if ((i+2) < ndmasegs) { + ring->desc_queued++; + ring->desc_cur = (ring->desc_cur + 1) % + RT_SOFTC_TX_RING_DESC_COUNT; + } + desc = &ring->desc[ring->desc_cur]; + } + + RT_DPRINTF(sc, RT_DEBUG_TX, "sending data: len=%d, ndmasegs=%d, " + "DMA ds_len=%d/%d/%d/%d/%d\n", + m->m_pkthdr.len, ndmasegs, + (int) dma_seg[0].ds_len, + (int) dma_seg[1].ds_len, + (int) dma_seg[2].ds_len, + (int) dma_seg[3].ds_len, + (int) dma_seg[4].ds_len); + + bus_dmamap_sync(ring->seg0_dma_tag, ring->seg0_dma_map, + BUS_DMASYNC_PREWRITE); + bus_dmamap_sync(ring->data_dma_tag, data->dma_map, + BUS_DMASYNC_PREWRITE); + bus_dmamap_sync(ring->desc_dma_tag, ring->desc_dma_map, + BUS_DMASYNC_PREWRITE); + + ring->desc_queued++; + ring->desc_cur = (ring->desc_cur + 1) % RT_SOFTC_TX_RING_DESC_COUNT; + + ring->data_queued++; + ring->data_cur = (ring->data_cur + 1) % RT_SOFTC_TX_RING_DATA_COUNT; + + /* kick Tx */ + RT_WRITE(sc, PDMA_BASE + TX_CTX_IDX(qid), ring->desc_cur); + + return 0; +} + +/* + * rt_start + */ +static void +rt_start(struct ifnet *ifp) +{ + struct rt_softc *sc; + struct mbuf *m; + int qid = 0 /* XXX must check QoS priority */; + + sc = ifp->if_softc; + + if (!(ifp->if_drv_flags & IFF_DRV_RUNNING)) + return; + + for (;;) { + IFQ_DRV_DEQUEUE(&ifp->if_snd, m); + if (m == NULL) + break; + + m->m_pkthdr.rcvif = NULL; + + RT_SOFTC_TX_RING_LOCK(&sc->tx_ring[qid]); + + if (sc->tx_ring[qid].data_queued >= RT_SOFTC_TX_RING_DATA_COUNT) { + RT_SOFTC_TX_RING_UNLOCK(&sc->tx_ring[qid]); + + RT_DPRINTF(sc, RT_DEBUG_TX, + "if_start: Tx ring with qid=%d is full\n", qid); + + m_freem(m); + + ifp->if_drv_flags |= IFF_DRV_OACTIVE; + ifp->if_oerrors++; + + sc->tx_data_queue_full[qid]++; + + break; + } + + if (rt_tx_data(sc, m, qid) != 0) { + RT_SOFTC_TX_RING_UNLOCK(&sc->tx_ring[qid]); + + ifp->if_oerrors++; + + break; + } + + RT_SOFTC_TX_RING_UNLOCK(&sc->tx_ring[qid]); + sc->tx_timer = RT_TX_WATCHDOG_TIMEOUT; + callout_reset(&sc->tx_watchdog_ch, hz, rt_tx_watchdog, sc); + } +} + +/* + * rt_update_promisc + */ +static void +rt_update_promisc(struct ifnet *ifp) +{ + struct rt_softc *sc; + + sc = ifp->if_softc; + printf("%s: %s promiscuous mode\n", + device_get_nameunit(sc->dev), + (ifp->if_flags & IFF_PROMISC) ? "entering" : "leaving"); +} + +/* + * rt_ioctl + */ +static int +rt_ioctl(struct ifnet *ifp, u_long cmd, caddr_t data) +{ + struct rt_softc *sc; + struct ifreq *ifr; +#ifdef IF_RT_PHY_SUPPORT + struct mii_data *mii; +#endif /* IF_RT_PHY_SUPPORT */ + int error, startall; + + sc = ifp->if_softc; + ifr = (struct ifreq *) data; + + error = 0; + + switch (cmd) { + case SIOCSIFFLAGS: + startall = 0; + RT_SOFTC_LOCK(sc); + if (ifp->if_flags & IFF_UP) { + if (ifp->if_drv_flags & IFF_DRV_RUNNING) { + if ((ifp->if_flags ^ sc->if_flags) & + IFF_PROMISC) + rt_update_promisc(ifp); + } else { + rt_init_locked(sc); + startall = 1; + } + } else { + if (ifp->if_drv_flags & IFF_DRV_RUNNING) + rt_stop_locked(sc); + } + + sc->if_flags = ifp->if_flags; + + RT_SOFTC_UNLOCK(sc); + break; + + case SIOCGIFMEDIA: + case SIOCSIFMEDIA: +#ifdef IF_RT_PHY_SUPPORT + mii = device_get_softc(sc->rt_miibus); + error = ifmedia_ioctl(ifp, ifr, &mii->mii_media, cmd); +#else + error = ifmedia_ioctl(ifp, ifr, &sc->rt_ifmedia, cmd); +#endif /* IF_RT_PHY_SUPPORT */ + break; + + default: + error = ether_ioctl(ifp, cmd, data); + break; + } + + return error; +} + +/* + * rt_periodic + */ +static void +rt_periodic(void *arg) +{ + struct rt_softc *sc; + + sc = arg; + RT_DPRINTF(sc, RT_DEBUG_PERIODIC, "periodic\n"); + taskqueue_enqueue(sc->taskqueue, &sc->periodic_task); +} + +/* + * rt_tx_watchdog + */ +static void +rt_tx_watchdog(void *arg) +{ + struct rt_softc *sc; + struct ifnet *ifp; + + sc = arg; + ifp = sc->ifp; + + if (sc->tx_timer == 0) + return; + + if (--sc->tx_timer == 0) { + device_printf(sc->dev, "Tx watchdog timeout: resetting\n"); + +#ifdef notyet + /* + * XXX: Commented out, because reset break input. + */ + rt_stop_locked(sc); + rt_init_locked(sc); +#endif + + ifp->if_oerrors++; + sc->tx_watchdog_timeouts++; + } + + callout_reset(&sc->tx_watchdog_ch, hz, rt_tx_watchdog, sc); +} + +static void +rt_cnt_ppe_af(struct rt_softc *sc) +{ + + RT_DPRINTF(sc, RT_DEBUG_INTR, "PPE Counter Table Almost Full\n"); +} + +static void +rt_cnt_gdm_af(struct rt_softc *sc) +{ + + RT_DPRINTF(sc, RT_DEBUG_INTR, + "GDMA 1 & 2 Counter Table Almost Full\n"); +} + +static void +rt_pse_p2_fc(struct rt_softc *sc) +{ + RT_DPRINTF(sc, RT_DEBUG_INTR, + "PSE port2 (GDMA 2) flow control asserted.\n"); +} + +static void +rt_gdm_crc_drop(struct rt_softc *sc) +{ + RT_DPRINTF(sc, RT_DEBUG_INTR, + "GDMA 1 & 2 discard a packet due to CRC error\n"); +} + +static void +rt_pse_buf_drop(struct rt_softc *sc) +{ + RT_DPRINTF(sc, RT_DEBUG_INTR, + "PSE discards a packet due to buffer sharing limitation\n"); +} + +static void +rt_gdm_other_drop(struct rt_softc *sc) +{ + RT_DPRINTF(sc, RT_DEBUG_INTR, + "GDMA 1 & 2 discard a packet due to other reason\n"); +} + +static void +rt_pse_p1_fc(struct rt_softc *sc) +{ + RT_DPRINTF(sc, RT_DEBUG_INTR, + "PSE port1 (GDMA 1) flow control asserted.\n"); +} + +static void +rt_pse_p0_fc(struct rt_softc *sc) +{ + RT_DPRINTF(sc, RT_DEBUG_INTR, + "PSE port0 (CDMA) flow control asserted.\n"); +} + +static void +rt_pse_fq_empty(struct rt_softc *sc) +{ + RT_DPRINTF(sc, RT_DEBUG_INTR, + "PSE free Q empty threshold reached & forced drop " + "condition occurred.\n"); +} + +/* + * rt_intr + */ +static void +rt_intr(void *arg) +{ + struct rt_softc *sc; + struct ifnet *ifp; + uint32_t status; + + sc = arg; + ifp = sc->ifp; + + /* acknowledge interrupts */ + + status = RT_READ(sc, GE_PORT_BASE + FE_INT_STATUS); + RT_WRITE(sc, GE_PORT_BASE + FE_INT_STATUS, status); + + RT_DPRINTF(sc, RT_DEBUG_INTR, "interrupt: status = 0x%08x\n", status); + + if (status == 0xffffffff || /* device likely went away */ + status == 0) /* not for us */ + return; + + sc->interrupts++; + + if (!(ifp->if_drv_flags & IFF_DRV_RUNNING)) + return; + + if (status & CNT_PPE_AF) + rt_cnt_ppe_af(sc); + + if (status & CNT_GDM_AF) + rt_cnt_gdm_af(sc); + + if (status & PSE_P2_FC) + rt_pse_p2_fc(sc); + + if (status & GDM_CRC_DROP) + rt_gdm_crc_drop(sc); + + if (status & PSE_BUF_DROP) + rt_pse_buf_drop(sc); + + if (status & GDM_OTHER_DROP) + rt_gdm_other_drop(sc); + + if (status & PSE_P1_FC) + rt_pse_p1_fc(sc); + + if (status & PSE_P0_FC) + rt_pse_p0_fc(sc); + + if (status & PSE_FQ_EMPTY) + rt_pse_fq_empty(sc); + + if (status & INT_TX_COHERENT) + rt_tx_coherent_intr(sc); + + if (status & INT_RX_COHERENT) + rt_rx_coherent_intr(sc); + + if (status & RX_DLY_INT) + rt_rx_delay_intr(sc); + + if (status & TX_DLY_INT) + rt_tx_delay_intr(sc); + + if (status & INT_RX_DONE) + rt_rx_intr(sc); + + if (status & INT_TXQ3_DONE) + rt_tx_intr(sc, 3); + + if (status & INT_TXQ2_DONE) + rt_tx_intr(sc, 2); + + if (status & INT_TXQ1_DONE) + rt_tx_intr(sc, 1); + + if (status & INT_TXQ0_DONE) + rt_tx_intr(sc, 0); +} + +/* + * rt_tx_coherent_intr + */ +static void +rt_tx_coherent_intr(struct rt_softc *sc) +{ + uint32_t tmp; + int i; + + RT_DPRINTF(sc, RT_DEBUG_INTR, "Tx coherent interrupt\n"); + + sc->tx_coherent_interrupts++; + + /* restart DMA engine */ + tmp = RT_READ(sc, PDMA_BASE + PDMA_GLO_CFG); + + tmp &= ~(FE_TX_WB_DDONE | FE_TX_DMA_EN); + + RT_WRITE(sc, PDMA_BASE + PDMA_GLO_CFG, tmp); + + for (i = 0; i < RT_SOFTC_TX_RING_COUNT; i++) + rt_reset_tx_ring(sc, &sc->tx_ring[i]); + + for (i = 0; i < RT_SOFTC_TX_RING_COUNT; i++) { + RT_WRITE(sc, PDMA_BASE + TX_BASE_PTR(i), + sc->tx_ring[i].desc_phys_addr); + RT_WRITE(sc, PDMA_BASE + TX_MAX_CNT(i), + RT_SOFTC_TX_RING_DESC_COUNT); + RT_WRITE(sc, PDMA_BASE + TX_CTX_IDX(i), 0); + } + + rt_txrx_enable(sc); +} + +/* + * rt_rx_coherent_intr + */ +static void +rt_rx_coherent_intr(struct rt_softc *sc) +{ + uint32_t tmp; + + RT_DPRINTF(sc, RT_DEBUG_INTR, "Rx coherent interrupt\n"); + + sc->rx_coherent_interrupts++; + + /* restart DMA engine */ + tmp = RT_READ(sc, PDMA_BASE + PDMA_GLO_CFG); + tmp &= ~(FE_RX_DMA_EN); + RT_WRITE(sc, PDMA_BASE + PDMA_GLO_CFG, tmp); + + /* init Rx ring */ + rt_reset_rx_ring(sc, &sc->rx_ring); + RT_WRITE(sc, PDMA_BASE + RX_BASE_PTR0, + sc->rx_ring.desc_phys_addr); + RT_WRITE(sc, PDMA_BASE + RX_MAX_CNT0, + RT_SOFTC_RX_RING_DATA_COUNT); + RT_WRITE(sc, PDMA_BASE + RX_CALC_IDX0, + RT_SOFTC_RX_RING_DATA_COUNT - 1); + + rt_txrx_enable(sc); +} + +/* + * rt_rx_intr + */ +static void +rt_rx_intr(struct rt_softc *sc) +{ + + RT_DPRINTF(sc, RT_DEBUG_INTR, "Rx interrupt\n"); + sc->rx_interrupts++; + RT_SOFTC_LOCK(sc); + + if (!(sc->intr_disable_mask & INT_RX_DONE)) { + rt_intr_disable(sc, INT_RX_DONE); + taskqueue_enqueue(sc->taskqueue, &sc->rx_done_task); + } + + sc->intr_pending_mask |= INT_RX_DONE; + RT_SOFTC_UNLOCK(sc); + +} + +/* + * rt_rx_delay_intr + */ +static void +rt_rx_delay_intr(struct rt_softc *sc) +{ + + RT_DPRINTF(sc, RT_DEBUG_INTR, "Rx delay interrupt\n"); + sc->rx_delay_interrupts++; +} + +/* + * rt_tx_delay_intr + */ +static void +rt_tx_delay_intr(struct rt_softc *sc) +{ + + RT_DPRINTF(sc, RT_DEBUG_INTR, "Tx delay interrupt\n"); + sc->tx_delay_interrupts++; +} + + +/* + * rt_tx_intr + */ +static void +rt_tx_intr(struct rt_softc *sc, int qid) +{ + KASSERT(qid >= 0 && qid < RT_SOFTC_TX_RING_COUNT, + ("%s: Tx interrupt: invalid qid=%d\n", + device_get_nameunit(sc->dev), qid)); + + RT_DPRINTF(sc, RT_DEBUG_INTR, "Tx interrupt: qid=%d\n", qid); + + sc->tx_interrupts[qid]++; + RT_SOFTC_LOCK(sc); + + if (!(sc->intr_disable_mask & (INT_TXQ0_DONE << qid))) { + rt_intr_disable(sc, (INT_TXQ0_DONE << qid)); + taskqueue_enqueue(sc->taskqueue, &sc->tx_done_task); + } + + sc->intr_pending_mask |= (INT_TXQ0_DONE << qid); + RT_SOFTC_UNLOCK(sc); +} + +/* + * rt_rx_done_task + */ +static void +rt_rx_done_task(void *context, int pending) +{ + struct rt_softc *sc; + struct ifnet *ifp; + int again; + + sc = context; + ifp = sc->ifp; + + RT_DPRINTF(sc, RT_DEBUG_RX, "Rx done task\n"); + + if (!(ifp->if_drv_flags & IFF_DRV_RUNNING)) + return; + + sc->intr_pending_mask &= ~INT_RX_DONE; + + again = rt_rx_eof(sc, sc->rx_process_limit); + + RT_SOFTC_LOCK(sc); + + if ((sc->intr_pending_mask & INT_RX_DONE) || again) { + RT_DPRINTF(sc, RT_DEBUG_RX, "Rx done task: scheduling again\n"); + taskqueue_enqueue(sc->taskqueue, &sc->rx_done_task); + } else { + rt_intr_enable(sc, INT_RX_DONE); + } + + RT_SOFTC_UNLOCK(sc); +} + +/* + * rt_tx_done_task + */ +static void +rt_tx_done_task(void *context, int pending) +{ + struct rt_softc *sc; + struct ifnet *ifp; + uint32_t intr_mask; + int i; + + sc = context; + ifp = sc->ifp; + + RT_DPRINTF(sc, RT_DEBUG_TX, "Tx done task\n"); + + if (!(ifp->if_drv_flags & IFF_DRV_RUNNING)) + return; + + for (i = RT_SOFTC_TX_RING_COUNT - 1; i >= 0; i--) { + if (sc->intr_pending_mask & (INT_TXQ0_DONE << i)) { + sc->intr_pending_mask &= ~(INT_TXQ0_DONE << i); + rt_tx_eof(sc, &sc->tx_ring[i]); + } + } + + sc->tx_timer = 0; + + ifp->if_drv_flags &= ~IFF_DRV_OACTIVE; + + intr_mask = ( + INT_TXQ3_DONE | + INT_TXQ2_DONE | + INT_TXQ1_DONE | + INT_TXQ0_DONE); + + RT_SOFTC_LOCK(sc); + + rt_intr_enable(sc, ~sc->intr_pending_mask & + (sc->intr_disable_mask & intr_mask)); + + if (sc->intr_pending_mask & intr_mask) { + RT_DPRINTF(sc, RT_DEBUG_TX, "Tx done task: scheduling again\n"); + taskqueue_enqueue(sc->taskqueue, &sc->tx_done_task); + } + + RT_SOFTC_UNLOCK(sc); + + if (!IFQ_IS_EMPTY(&ifp->if_snd)) + rt_start(ifp); +} + +/* + * rt_periodic_task + */ +static void +rt_periodic_task(void *context, int pending) +{ + struct rt_softc *sc; + struct ifnet *ifp; + + sc = context; + ifp = sc->ifp; + + RT_DPRINTF(sc, RT_DEBUG_PERIODIC, "periodic task: round=%lu\n", + sc->periodic_round); + + if (!(ifp->if_drv_flags & IFF_DRV_RUNNING)) + return; + + RT_SOFTC_LOCK(sc); + sc->periodic_round++; + rt_update_stats(sc); + + if ((sc->periodic_round % 10) == 0) { + rt_update_raw_counters(sc); + rt_watchdog(sc); + } + + RT_SOFTC_UNLOCK(sc); + callout_reset(&sc->periodic_ch, hz / 10, rt_periodic, sc); +} + +/* + * rt_rx_eof + */ +static int +rt_rx_eof(struct rt_softc *sc, int limit) +{ + struct ifnet *ifp; + struct rt_softc_rx_ring *ring; + struct rt_rxdesc *desc; + struct rt_softc_rx_data *data; + struct mbuf *m, *mnew; + bus_dma_segment_t segs[1]; + bus_dmamap_t dma_map; + uint32_t index, desc_flags; + int error, nsegs, len, nframes; + + ifp = sc->ifp; + ring = &sc->rx_ring; + + nframes = 0; + + while (limit != 0) { + index = RT_READ(sc, PDMA_BASE + RX_DRX_IDX0); + if (ring->cur == index) + break; + + desc = &ring->desc[ring->cur]; + data = &ring->data[ring->cur]; + + bus_dmamap_sync(ring->desc_dma_tag, ring->desc_dma_map, + BUS_DMASYNC_POSTREAD | BUS_DMASYNC_POSTWRITE); + +#ifdef IF_RT_DEBUG + if ( sc->debug & RT_DEBUG_RX ) { + printf("\nRX Descriptor[%#08x] dump:\n", (u_int)desc); + hexdump(desc, 16, 0, 0); + printf("-----------------------------------\n"); + } +#endif + + /* XXX Sometime device don`t set DDONE bit */ +#ifdef DDONE_FIXED + if (!(desc->sdl0 & htole16(RT_RXDESC_SDL0_DDONE))) { + RT_DPRINTF(sc, RT_DEBUG_RX, "DDONE=0, try next\n"); + break; + } +#endif + + len = le16toh(desc->sdl0) & 0x3fff; + RT_DPRINTF(sc, RT_DEBUG_RX, "new frame len=%d\n", len); + + nframes++; + + mnew = m_getjcl(M_DONTWAIT, MT_DATA, M_PKTHDR, MJUMPAGESIZE); + if (mnew == NULL) { + sc->rx_mbuf_alloc_errors++; + ifp->if_ierrors++; + goto skip; + } + + mnew->m_len = mnew->m_pkthdr.len = MJUMPAGESIZE; + + error = bus_dmamap_load_mbuf_sg(ring->data_dma_tag, ring->spare_dma_map, + mnew, segs, &nsegs, BUS_DMA_NOWAIT); + if (error != 0) { + RT_DPRINTF(sc, RT_DEBUG_RX, + "could not load Rx mbuf DMA map: error=%d, " + "nsegs=%d\n", + error, nsegs); + + m_freem(mnew); + + sc->rx_mbuf_dmamap_errors++; + ifp->if_ierrors++; + + goto skip; + } + + KASSERT(nsegs == 1, ("%s: too many DMA segments", + device_get_nameunit(sc->dev))); + + bus_dmamap_sync(ring->data_dma_tag, data->dma_map, + BUS_DMASYNC_POSTREAD); + bus_dmamap_unload(ring->data_dma_tag, data->dma_map); + + dma_map = data->dma_map; + data->dma_map = ring->spare_dma_map; + ring->spare_dma_map = dma_map; + + bus_dmamap_sync(ring->data_dma_tag, data->dma_map, + BUS_DMASYNC_PREREAD); + + m = data->m; + desc_flags = desc->src; + + data->m = mnew; + /* Add 2 for proper align of RX IP header */ + desc->sdp0 = htole32(segs[0].ds_addr+2); + desc->sdl0 = htole32(segs[0].ds_len-2); + desc->src = 0; + desc->ai = 0; + desc->foe = 0; + + RT_DPRINTF(sc, RT_DEBUG_RX, "Rx frame: rxdesc flags=0x%08x\n", + desc_flags); + + m->m_pkthdr.rcvif = ifp; + /* Add 2 to fix data align, after sdp0 = addr + 2 */ + m->m_data += 2; + m->m_pkthdr.len = m->m_len = len; + + /* check for crc errors */ + if ((ifp->if_capenable & IFCAP_RXCSUM) != 0) { + /*check for valid checksum*/ + if (desc_flags & (RXDSXR_SRC_IP_CSUM_FAIL|RXDSXR_SRC_L4_CSUM_FAIL)) { + RT_DPRINTF(sc, RT_DEBUG_RX, + "rxdesc: crc error\n"); + + ifp->if_ierrors++; + + if (!(ifp->if_flags & IFF_PROMISC)) { + m_freem(m); + goto skip; + } + } + if ((desc_flags & RXDSXR_SRC_IP_CSUM_FAIL) != 0) { + m->m_pkthdr.csum_flags |= CSUM_IP_CHECKED; + m->m_pkthdr.csum_flags |= CSUM_IP_VALID; + m->m_pkthdr.csum_data = 0xffff; + } + m->m_flags &= ~M_HASFCS; + } + + (*ifp->if_input)(ifp, m); +skip: + desc->sdl0 &= ~htole16(RT_RXDESC_SDL0_DDONE); + + bus_dmamap_sync(ring->desc_dma_tag, ring->desc_dma_map, + BUS_DMASYNC_PREREAD | BUS_DMASYNC_PREWRITE); + + ring->cur = (ring->cur + 1) % RT_SOFTC_RX_RING_DATA_COUNT; + + limit--; + } + + if (ring->cur == 0) + RT_WRITE(sc, PDMA_BASE + RX_CALC_IDX0, + RT_SOFTC_RX_RING_DATA_COUNT - 1); + else + RT_WRITE(sc, PDMA_BASE + RX_CALC_IDX0, + ring->cur - 1); + + RT_DPRINTF(sc, RT_DEBUG_RX, "Rx eof: nframes=%d\n", nframes); + + sc->rx_packets += nframes; + + return (limit == 0); +} + +/* + * rt_tx_eof + */ +static void +rt_tx_eof(struct rt_softc *sc, struct rt_softc_tx_ring *ring) +{ + struct ifnet *ifp; + struct rt_txdesc *desc; + struct rt_softc_tx_data *data; + uint32_t index; + int ndescs, nframes; + + ifp = sc->ifp; + + ndescs = 0; + nframes = 0; + + for (;;) { + index = RT_READ(sc, PDMA_BASE + TX_DTX_IDX(ring->qid)); + if (ring->desc_next == index) + break; + + ndescs++; + + desc = &ring->desc[ring->desc_next]; + + bus_dmamap_sync(ring->desc_dma_tag, ring->desc_dma_map, + BUS_DMASYNC_POSTREAD | BUS_DMASYNC_POSTWRITE); + + if (desc->sdl0 & htole16(RT_TXDESC_SDL0_LASTSEG) || + desc->sdl1 & htole16(RT_TXDESC_SDL1_LASTSEG)) { + nframes++; + + data = &ring->data[ring->data_next]; + + bus_dmamap_sync(ring->data_dma_tag, data->dma_map, + BUS_DMASYNC_POSTWRITE); + bus_dmamap_unload(ring->data_dma_tag, data->dma_map); + + m_freem(data->m); + + data->m = NULL; + + ifp->if_opackets++; + + RT_SOFTC_TX_RING_LOCK(ring); + ring->data_queued--; + ring->data_next = (ring->data_next + 1) % RT_SOFTC_TX_RING_DATA_COUNT; + RT_SOFTC_TX_RING_UNLOCK(ring); + } + + desc->sdl0 &= ~htole16(RT_TXDESC_SDL0_DDONE); + + bus_dmamap_sync(ring->desc_dma_tag, ring->desc_dma_map, + BUS_DMASYNC_PREREAD | BUS_DMASYNC_PREWRITE); + + RT_SOFTC_TX_RING_LOCK(ring); + ring->desc_queued--; + ring->desc_next = (ring->desc_next + 1) % RT_SOFTC_TX_RING_DESC_COUNT; + RT_SOFTC_TX_RING_UNLOCK(ring); + } + + RT_DPRINTF(sc, RT_DEBUG_TX, + "Tx eof: qid=%d, ndescs=%d, nframes=%d\n", ring->qid, ndescs, + nframes); +} + +/* + * rt_update_stats + */ +static void +rt_update_stats(struct rt_softc *sc) +{ + struct ifnet *ifp; + + ifp = sc->ifp; + RT_DPRINTF(sc, RT_DEBUG_STATS, "update statistic: \n"); + /* XXX do update stats here */ + +} + +/* + * rt_watchdog + */ +static void +rt_watchdog(struct rt_softc *sc) +{ + uint32_t tmp; +#ifdef notyet + int ntries; +#endif + + tmp = RT_READ(sc, PSE_BASE + CDMA_OQ_STA); + + RT_DPRINTF(sc, RT_DEBUG_WATCHDOG, "watchdog: PSE_IQ_STA=0x%08x\n", tmp); + + /* XXX: do not reset */ +#ifdef notyet + if (((tmp >> P0_IQ_PCNT_SHIFT) & 0xff) != 0) { + sc->tx_queue_not_empty[0]++; + + for (ntries = 0; ntries < 10; ntries++) { + tmp = RT_READ(sc, PSE_BASE + PSE_IQ_STA); + if (((tmp >> P0_IQ_PCNT_SHIFT) & 0xff) == 0) + break; + + DELAY(1); + } + } + + if (((tmp >> P1_IQ_PCNT_SHIFT) & 0xff) != 0) { + sc->tx_queue_not_empty[1]++; + + for (ntries = 0; ntries < 10; ntries++) { + tmp = RT_READ(sc, PSE_BASE + PSE_IQ_STA); + if (((tmp >> P1_IQ_PCNT_SHIFT) & 0xff) == 0) + break; + + DELAY(1); + } + } +#endif +} + + +/* + * rt_update_raw_counters + */ +static void +rt_update_raw_counters(struct rt_softc *sc) +{ + + sc->tx_bytes += RT_READ(sc, CNTR_BASE + GDMA_TX_GBCNT0); + sc->tx_packets += RT_READ(sc, CNTR_BASE + GDMA_TX_GPCNT0); + sc->tx_skip += RT_READ(sc, CNTR_BASE + GDMA_TX_SKIPCNT0); + sc->tx_collision+= RT_READ(sc, CNTR_BASE + GDMA_TX_COLCNT0); + + sc->rx_bytes += RT_READ(sc, CNTR_BASE + GDMA_RX_GBCNT0); + sc->rx_packets += RT_READ(sc, CNTR_BASE + GDMA_RX_GPCNT0); + sc->rx_crc_err += RT_READ(sc, CNTR_BASE + GDMA_RX_CSUM_ERCNT0); + sc->rx_short_err+= RT_READ(sc, CNTR_BASE + GDMA_RX_SHORT_ERCNT0); + sc->rx_long_err += RT_READ(sc, CNTR_BASE + GDMA_RX_LONG_ERCNT0); + sc->rx_phy_err += RT_READ(sc, CNTR_BASE + GDMA_RX_FERCNT0); + sc->rx_fifo_overflows+= RT_READ(sc, CNTR_BASE + GDMA_RX_OERCNT0); +} + +/* + * rt_intr_enable + */ +static void +rt_intr_enable(struct rt_softc *sc, uint32_t intr_mask) +{ + uint32_t tmp; + + sc->intr_disable_mask &= ~intr_mask; + tmp = sc->intr_enable_mask & ~sc->intr_disable_mask; + RT_WRITE(sc, GE_PORT_BASE + FE_INT_ENABLE, tmp); +} + +/* + * rt_intr_disable + */ +static void +rt_intr_disable(struct rt_softc *sc, uint32_t intr_mask) +{ + uint32_t tmp; + + sc->intr_disable_mask |= intr_mask; + tmp = sc->intr_enable_mask & ~sc->intr_disable_mask; + RT_WRITE(sc, GE_PORT_BASE + FE_INT_ENABLE, tmp); +} + +/* + * rt_txrx_enable + */ +static int +rt_txrx_enable(struct rt_softc *sc) +{ + struct ifnet *ifp; + uint32_t tmp; + int ntries; + + ifp = sc->ifp; + + /* enable Tx/Rx DMA engine */ + for (ntries = 0; ntries < 200; ntries++) { + tmp = RT_READ(sc, PDMA_BASE + PDMA_GLO_CFG); + if (!(tmp & (FE_TX_DMA_BUSY | FE_RX_DMA_BUSY))) + break; + + DELAY(1000); + } + + if (ntries == 200) { + device_printf(sc->dev, "timeout waiting for DMA engine\n"); + return -1; + } + + DELAY(50); + + tmp |= FE_TX_WB_DDONE | FE_RX_DMA_EN | FE_TX_DMA_EN; + RT_WRITE(sc, PDMA_BASE + PDMA_GLO_CFG, tmp); + + /* XXX set Rx filter */ + return 0; +} + +/* + * rt_alloc_rx_ring + */ +static int +rt_alloc_rx_ring(struct rt_softc *sc, struct rt_softc_rx_ring *ring) +{ + struct rt_rxdesc *desc; + struct rt_softc_rx_data *data; + bus_dma_segment_t segs[1]; + int i, nsegs, error; + + error = bus_dma_tag_create(bus_get_dma_tag(sc->dev), PAGE_SIZE, 0, + BUS_SPACE_MAXADDR_32BIT, BUS_SPACE_MAXADDR, NULL, NULL, + RT_SOFTC_RX_RING_DATA_COUNT * sizeof(struct rt_rxdesc), 1, + RT_SOFTC_RX_RING_DATA_COUNT * sizeof(struct rt_rxdesc), + 0, NULL, NULL, &ring->desc_dma_tag); + if (error != 0) { + device_printf(sc->dev, "could not create Rx desc DMA tag\n"); + goto fail; + } + + error = bus_dmamem_alloc(ring->desc_dma_tag, (void **) &ring->desc, + BUS_DMA_NOWAIT | BUS_DMA_ZERO, &ring->desc_dma_map); + if (error != 0) { + device_printf(sc->dev, "could not allocate Rx desc DMA memory\n"); + goto fail; + } + + error = bus_dmamap_load(ring->desc_dma_tag, ring->desc_dma_map, + ring->desc, + RT_SOFTC_RX_RING_DATA_COUNT * sizeof(struct rt_rxdesc), + rt_dma_map_addr, &ring->desc_phys_addr, 0); + if (error != 0) { + device_printf(sc->dev, "could not load Rx desc DMA map\n"); + goto fail; + } + + error = bus_dma_tag_create(bus_get_dma_tag(sc->dev), PAGE_SIZE, 0, + BUS_SPACE_MAXADDR_32BIT, BUS_SPACE_MAXADDR, NULL, NULL, + MJUMPAGESIZE, 1, MJUMPAGESIZE, 0, NULL, NULL, + &ring->data_dma_tag); + if (error != 0) { + device_printf(sc->dev, "could not create Rx data DMA tag\n"); + goto fail; + } + + for (i = 0; i < RT_SOFTC_RX_RING_DATA_COUNT; i++) { + desc = &ring->desc[i]; + data = &ring->data[i]; + + error = bus_dmamap_create(ring->data_dma_tag, 0, &data->dma_map); + if (error != 0) { + device_printf(sc->dev, "could not create Rx data DMA " + "map\n"); + goto fail; + } + + data->m = m_getjcl(M_DONTWAIT, MT_DATA, M_PKTHDR, MJUMPAGESIZE); + if (data->m == NULL) { + device_printf(sc->dev, "could not allocate Rx mbuf\n"); + error = ENOMEM; + goto fail; + } + + data->m->m_len = data->m->m_pkthdr.len = MJUMPAGESIZE; + + error = bus_dmamap_load_mbuf_sg(ring->data_dma_tag, data->dma_map, + data->m, segs, &nsegs, BUS_DMA_NOWAIT); + if (error != 0) { + device_printf(sc->dev, "could not load Rx mbuf DMA map\n"); + goto fail; + } + + KASSERT(nsegs == 1, ("%s: too many DMA segments", + device_get_nameunit(sc->dev))); + + /* Add 2 for proper align of RX IP header */ + desc->sdp0 = htole32(segs[0].ds_addr+2); + desc->sdl0 = htole32(segs[0].ds_len-2); + } + + error = bus_dmamap_create(ring->data_dma_tag, 0, &ring->spare_dma_map); + if (error != 0) { + device_printf(sc->dev, "could not create Rx spare DMA map\n"); + goto fail; + } + + bus_dmamap_sync(ring->desc_dma_tag, ring->desc_dma_map, + BUS_DMASYNC_PREREAD | BUS_DMASYNC_PREWRITE); + + return 0; + +fail: + rt_free_rx_ring(sc, ring); + + return error; +} + +/* + * rt_reset_rx_ring + */ +static void +rt_reset_rx_ring(struct rt_softc *sc, struct rt_softc_rx_ring *ring) +{ + struct rt_rxdesc *desc; + int i; + + for (i = 0; i < RT_SOFTC_RX_RING_DATA_COUNT; i++) { + desc = &ring->desc[i]; + desc->sdl0 &= ~htole16(RT_RXDESC_SDL0_DDONE); + } + + bus_dmamap_sync(ring->desc_dma_tag, ring->desc_dma_map, + BUS_DMASYNC_PREREAD | BUS_DMASYNC_PREWRITE); + ring->cur = 0; +} + +/* + * rt_free_rx_ring + */ +static void +rt_free_rx_ring(struct rt_softc *sc, struct rt_softc_rx_ring *ring) +{ + struct rt_softc_rx_data *data; + int i; + + if (ring->desc != NULL) { + bus_dmamap_sync(ring->desc_dma_tag, ring->desc_dma_map, + BUS_DMASYNC_POSTWRITE); + bus_dmamap_unload(ring->desc_dma_tag, ring->desc_dma_map); + bus_dmamem_free(ring->desc_dma_tag, ring->desc, + ring->desc_dma_map); + } + + if (ring->desc_dma_tag != NULL) + bus_dma_tag_destroy(ring->desc_dma_tag); + + for (i = 0; i < RT_SOFTC_RX_RING_DATA_COUNT; i++) { + data = &ring->data[i]; + + if (data->m != NULL) { + bus_dmamap_sync(ring->data_dma_tag, data->dma_map, + BUS_DMASYNC_POSTREAD); + bus_dmamap_unload(ring->data_dma_tag, data->dma_map); + m_freem(data->m); + } + + if (data->dma_map != NULL) + bus_dmamap_destroy(ring->data_dma_tag, data->dma_map); + } + + if (ring->spare_dma_map != NULL) + bus_dmamap_destroy(ring->data_dma_tag, ring->spare_dma_map); + + if (ring->data_dma_tag != NULL) + bus_dma_tag_destroy(ring->data_dma_tag); +} + +/* + * rt_alloc_tx_ring + */ +static int +rt_alloc_tx_ring(struct rt_softc *sc, struct rt_softc_tx_ring *ring, int qid) +{ + struct rt_softc_tx_data *data; + int error, i; + + mtx_init(&ring->lock, device_get_nameunit(sc->dev), NULL, MTX_DEF); + + error = bus_dma_tag_create(bus_get_dma_tag(sc->dev), PAGE_SIZE, 0, + BUS_SPACE_MAXADDR_32BIT, BUS_SPACE_MAXADDR, NULL, NULL, + RT_SOFTC_TX_RING_DESC_COUNT * sizeof(struct rt_txdesc), 1, + RT_SOFTC_TX_RING_DESC_COUNT * sizeof(struct rt_txdesc), + 0, NULL, NULL, &ring->desc_dma_tag); + if (error != 0) { + device_printf(sc->dev, "could not create Tx desc DMA tag\n"); + goto fail; + } + + error = bus_dmamem_alloc(ring->desc_dma_tag, (void **) &ring->desc, + BUS_DMA_NOWAIT | BUS_DMA_ZERO, &ring->desc_dma_map); + if (error != 0) { + device_printf(sc->dev, "could not allocate Tx desc DMA memory\n"); + goto fail; + } + + error = bus_dmamap_load(ring->desc_dma_tag, ring->desc_dma_map, + ring->desc, RT_SOFTC_TX_RING_DESC_COUNT * sizeof(struct rt_txdesc), + rt_dma_map_addr, &ring->desc_phys_addr, 0); + if (error != 0) { + device_printf(sc->dev, "could not load Tx desc DMA map\n"); + goto fail; + } + + ring->desc_queued = 0; + ring->desc_cur = 0; + ring->desc_next = 0; + + error = bus_dma_tag_create(bus_get_dma_tag(sc->dev), PAGE_SIZE, 0, + BUS_SPACE_MAXADDR_32BIT, BUS_SPACE_MAXADDR, NULL, NULL, + RT_SOFTC_TX_RING_DATA_COUNT * RT_TX_DATA_SEG0_SIZE, 1, + RT_SOFTC_TX_RING_DATA_COUNT * RT_TX_DATA_SEG0_SIZE, + 0, NULL, NULL, &ring->seg0_dma_tag); + if (error != 0) { + device_printf(sc->dev, "could not create Tx seg0 DMA tag\n"); + goto fail; + } + + error = bus_dmamem_alloc(ring->seg0_dma_tag, (void **) &ring->seg0, + BUS_DMA_NOWAIT | BUS_DMA_ZERO, &ring->seg0_dma_map); + if (error != 0) { + device_printf(sc->dev, "could not allocate Tx seg0 DMA memory\n"); + goto fail; + } + + error = bus_dmamap_load(ring->seg0_dma_tag, ring->seg0_dma_map, + ring->seg0, RT_SOFTC_TX_RING_DATA_COUNT * RT_TX_DATA_SEG0_SIZE, + rt_dma_map_addr, &ring->seg0_phys_addr, 0); + if (error != 0) { + device_printf(sc->dev, "could not load Tx seg0 DMA map\n"); + goto fail; + } + + error = bus_dma_tag_create(bus_get_dma_tag(sc->dev), PAGE_SIZE, 0, + BUS_SPACE_MAXADDR_32BIT, BUS_SPACE_MAXADDR, NULL, NULL, + MJUMPAGESIZE, RT_SOFTC_MAX_SCATTER, MJUMPAGESIZE, 0, NULL, NULL, + &ring->data_dma_tag); + if (error != 0) { + device_printf(sc->dev, "could not create Tx data DMA tag\n"); + goto fail; + } + + for (i = 0; i < RT_SOFTC_TX_RING_DATA_COUNT; i++) { + data = &ring->data[i]; + + error = bus_dmamap_create(ring->data_dma_tag, 0, &data->dma_map); + if (error != 0) { + device_printf(sc->dev, "could not create Tx data DMA " + "map\n"); + goto fail; + } + } + + ring->data_queued = 0; + ring->data_cur = 0; + ring->data_next = 0; + + ring->qid = qid; + + return 0; + +fail: + rt_free_tx_ring(sc, ring); + + return error; +} + +/* + * rt_reset_tx_ring + */ +static void +rt_reset_tx_ring(struct rt_softc *sc, struct rt_softc_tx_ring *ring) +{ + struct rt_softc_tx_data *data; + struct rt_txdesc *desc; + int i; + + for (i = 0; i < RT_SOFTC_TX_RING_DESC_COUNT; i++) { + desc = &ring->desc[i]; + + desc->sdl0 = 0; + desc->sdl1 = 0; + } + + ring->desc_queued = 0; + ring->desc_cur = 0; + ring->desc_next = 0; + + bus_dmamap_sync(ring->desc_dma_tag, ring->desc_dma_map, + BUS_DMASYNC_PREWRITE); + + bus_dmamap_sync(ring->seg0_dma_tag, ring->seg0_dma_map, + BUS_DMASYNC_PREWRITE); + + for (i = 0; i < RT_SOFTC_TX_RING_DATA_COUNT; i++) { + data = &ring->data[i]; + + if (data->m != NULL) { + bus_dmamap_sync(ring->data_dma_tag, data->dma_map, + BUS_DMASYNC_POSTWRITE); + bus_dmamap_unload(ring->data_dma_tag, data->dma_map); + m_freem(data->m); + data->m = NULL; + } + } + + ring->data_queued = 0; + ring->data_cur = 0; + ring->data_next = 0; +} + +/* + * rt_free_tx_ring + */ +static void +rt_free_tx_ring(struct rt_softc *sc, struct rt_softc_tx_ring *ring) +{ + struct rt_softc_tx_data *data; + int i; + + if (ring->desc != NULL) { + bus_dmamap_sync(ring->desc_dma_tag, ring->desc_dma_map, + BUS_DMASYNC_POSTWRITE); + bus_dmamap_unload(ring->desc_dma_tag, ring->desc_dma_map); + bus_dmamem_free(ring->desc_dma_tag, ring->desc, + ring->desc_dma_map); + } + + if (ring->desc_dma_tag != NULL) + bus_dma_tag_destroy(ring->desc_dma_tag); + + if (ring->seg0 != NULL) { + bus_dmamap_sync(ring->seg0_dma_tag, ring->seg0_dma_map, + BUS_DMASYNC_POSTWRITE); + bus_dmamap_unload(ring->seg0_dma_tag, ring->seg0_dma_map); + bus_dmamem_free(ring->seg0_dma_tag, ring->seg0, + ring->seg0_dma_map); + } + + if (ring->seg0_dma_tag != NULL) + bus_dma_tag_destroy(ring->seg0_dma_tag); + + for (i = 0; i < RT_SOFTC_TX_RING_DATA_COUNT; i++) { + data = &ring->data[i]; + + if (data->m != NULL) { + bus_dmamap_sync(ring->data_dma_tag, data->dma_map, + BUS_DMASYNC_POSTWRITE); + bus_dmamap_unload(ring->data_dma_tag, data->dma_map); + m_freem(data->m); + } + + if (data->dma_map != NULL) + bus_dmamap_destroy(ring->data_dma_tag, data->dma_map); + } + + if (ring->data_dma_tag != NULL) + bus_dma_tag_destroy(ring->data_dma_tag); + + mtx_destroy(&ring->lock); +} + +/* + * rt_dma_map_addr + */ +static void +rt_dma_map_addr(void *arg, bus_dma_segment_t *segs, int nseg, int error) +{ + if (error != 0) + return; + + KASSERT(nseg == 1, ("too many DMA segments, %d should be 1", nseg)); + + *(bus_addr_t *) arg = segs[0].ds_addr; +} + +/* + * rt_sysctl_attach + */ +static void +rt_sysctl_attach(struct rt_softc *sc) +{ + struct sysctl_ctx_list *ctx; + struct sysctl_oid *tree; + struct sysctl_oid *stats; + + ctx = device_get_sysctl_ctx(sc->dev); + tree = device_get_sysctl_tree(sc->dev); + + /* statistic counters */ + stats = SYSCTL_ADD_NODE(ctx, SYSCTL_CHILDREN(tree), OID_AUTO, + "stats", CTLFLAG_RD, 0, "statistic"); + + SYSCTL_ADD_INT(ctx, SYSCTL_CHILDREN(stats), OID_AUTO, + "interrupts", CTLFLAG_RD, &sc->interrupts, 0, + "all interrupts"); + + SYSCTL_ADD_INT(ctx, SYSCTL_CHILDREN(stats), OID_AUTO, + "tx_coherent_interrupts", CTLFLAG_RD, &sc->tx_coherent_interrupts, 0, + "Tx coherent interrupts"); + + SYSCTL_ADD_INT(ctx, SYSCTL_CHILDREN(stats), OID_AUTO, + "rx_coherent_interrupts", CTLFLAG_RD, &sc->rx_coherent_interrupts, 0, + "Rx coherent interrupts"); + + SYSCTL_ADD_INT(ctx, SYSCTL_CHILDREN(stats), OID_AUTO, + "rx_interrupts", CTLFLAG_RD, &sc->rx_interrupts, 0, + "Rx interrupts"); + + SYSCTL_ADD_INT(ctx, SYSCTL_CHILDREN(stats), OID_AUTO, + "rx_delay_interrupts", CTLFLAG_RD, &sc->rx_delay_interrupts, 0, + "Rx delay interrupts"); + + SYSCTL_ADD_INT(ctx, SYSCTL_CHILDREN(stats), OID_AUTO, + "TXQ3_interrupts", CTLFLAG_RD, &sc->tx_interrupts[3], 0, + "Tx AC3 interrupts"); + + SYSCTL_ADD_INT(ctx, SYSCTL_CHILDREN(stats), OID_AUTO, + "TXQ2_interrupts", CTLFLAG_RD, &sc->tx_interrupts[2], 0, + "Tx AC2 interrupts"); + + SYSCTL_ADD_INT(ctx, SYSCTL_CHILDREN(stats), OID_AUTO, + "TXQ1_interrupts", CTLFLAG_RD, &sc->tx_interrupts[1], 0, + "Tx AC1 interrupts"); + + SYSCTL_ADD_INT(ctx, SYSCTL_CHILDREN(stats), OID_AUTO, + "TXQ0_interrupts", CTLFLAG_RD, &sc->tx_interrupts[0], 0, + "Tx AC0 interrupts"); + + SYSCTL_ADD_INT(ctx, SYSCTL_CHILDREN(stats), OID_AUTO, + "tx_delay_interrupts", CTLFLAG_RD, &sc->tx_delay_interrupts, 0, + "Tx delay interrupts"); + + SYSCTL_ADD_INT(ctx, SYSCTL_CHILDREN(stats), OID_AUTO, + "TXQ3_desc_queued", CTLFLAG_RD, &sc->tx_ring[3].desc_queued, 0, + "Tx AC3 descriptors queued"); + + SYSCTL_ADD_INT(ctx, SYSCTL_CHILDREN(stats), OID_AUTO, + "TXQ3_data_queued", CTLFLAG_RD, &sc->tx_ring[3].data_queued, 0, + "Tx AC3 data queued"); + + SYSCTL_ADD_INT(ctx, SYSCTL_CHILDREN(stats), OID_AUTO, + "TXQ2_desc_queued", CTLFLAG_RD, &sc->tx_ring[2].desc_queued, 0, + "Tx AC2 descriptors queued"); + + SYSCTL_ADD_INT(ctx, SYSCTL_CHILDREN(stats), OID_AUTO, + "TXQ2_data_queued", CTLFLAG_RD, &sc->tx_ring[2].data_queued, 0, + "Tx AC2 data queued"); + + SYSCTL_ADD_INT(ctx, SYSCTL_CHILDREN(stats), OID_AUTO, + "TXQ1_desc_queued", CTLFLAG_RD, &sc->tx_ring[1].desc_queued, 0, + "Tx AC1 descriptors queued"); + + SYSCTL_ADD_INT(ctx, SYSCTL_CHILDREN(stats), OID_AUTO, + "TXQ1_data_queued", CTLFLAG_RD, &sc->tx_ring[1].data_queued, 0, + "Tx AC1 data queued"); + + SYSCTL_ADD_INT(ctx, SYSCTL_CHILDREN(stats), OID_AUTO, + "TXQ0_desc_queued", CTLFLAG_RD, &sc->tx_ring[0].desc_queued, 0, + "Tx AC0 descriptors queued"); + + SYSCTL_ADD_INT(ctx, SYSCTL_CHILDREN(stats), OID_AUTO, + "TXQ0_data_queued", CTLFLAG_RD, &sc->tx_ring[0].data_queued, 0, + "Tx AC0 data queued"); + + SYSCTL_ADD_INT(ctx, SYSCTL_CHILDREN(stats), OID_AUTO, + "TXQ3_data_queue_full", CTLFLAG_RD, &sc->tx_data_queue_full[3], 0, + "Tx AC3 data queue full"); + + SYSCTL_ADD_INT(ctx, SYSCTL_CHILDREN(stats), OID_AUTO, + "TXQ2_data_queue_full", CTLFLAG_RD, &sc->tx_data_queue_full[2], 0, + "Tx AC2 data queue full"); + + SYSCTL_ADD_INT(ctx, SYSCTL_CHILDREN(stats), OID_AUTO, + "TXQ1_data_queue_full", CTLFLAG_RD, &sc->tx_data_queue_full[1], 0, + "Tx AC1 data queue full"); + + SYSCTL_ADD_INT(ctx, SYSCTL_CHILDREN(stats), OID_AUTO, + "TXQ0_data_queue_full", CTLFLAG_RD, &sc->tx_data_queue_full[0], 0, + "Tx AC0 data queue full"); + + SYSCTL_ADD_INT(ctx, SYSCTL_CHILDREN(stats), OID_AUTO, + "tx_watchdog_timeouts", CTLFLAG_RD, &sc->tx_watchdog_timeouts, 0, + "Tx watchdog timeouts"); + + SYSCTL_ADD_INT(ctx, SYSCTL_CHILDREN(stats), OID_AUTO, + "tx_defrag_packets", CTLFLAG_RD, &sc->tx_defrag_packets, 0, + "Tx defragmented packets"); + + SYSCTL_ADD_INT(ctx, SYSCTL_CHILDREN(stats), OID_AUTO, + "no_tx_desc_avail", CTLFLAG_RD, &sc->no_tx_desc_avail, 0, + "no Tx descriptors available"); + + SYSCTL_ADD_INT(ctx, SYSCTL_CHILDREN(stats), OID_AUTO, + "rx_mbuf_alloc_errors", CTLFLAG_RD, &sc->rx_mbuf_alloc_errors, 0, + "Rx mbuf allocation errors"); + + SYSCTL_ADD_INT(ctx, SYSCTL_CHILDREN(stats), OID_AUTO, + "rx_mbuf_dmamap_errors", CTLFLAG_RD, &sc->rx_mbuf_dmamap_errors, 0, + "Rx mbuf DMA mapping errors"); + + SYSCTL_ADD_INT(ctx, SYSCTL_CHILDREN(stats), OID_AUTO, + "tx_queue_0_not_empty", CTLFLAG_RD, &sc->tx_queue_not_empty[0], 0, + "Tx queue 0 not empty"); + + SYSCTL_ADD_INT(ctx, SYSCTL_CHILDREN(stats), OID_AUTO, + "tx_queue_1_not_empty", CTLFLAG_RD, &sc->tx_queue_not_empty[1], 0, + "Tx queue 1 not empty"); + + SYSCTL_ADD_INT(ctx, SYSCTL_CHILDREN(stats), OID_AUTO, + "rx_packets", CTLFLAG_RD, &sc->rx_packets, 0, + "Rx packets"); + + SYSCTL_ADD_INT(ctx, SYSCTL_CHILDREN(stats), OID_AUTO, + "rx_crc_errors", CTLFLAG_RD, &sc->rx_crc_err, 0, + "Rx CRC errors"); + + SYSCTL_ADD_INT(ctx, SYSCTL_CHILDREN(stats), OID_AUTO, + "rx_phy_errors", CTLFLAG_RD, &sc->rx_phy_err, 0, + "Rx PHY errors"); + + SYSCTL_ADD_INT(ctx, SYSCTL_CHILDREN(stats), OID_AUTO, + "rx_dup_packets", CTLFLAG_RD, &sc->rx_dup_packets, 0, + "Rx duplicate packets"); + + SYSCTL_ADD_INT(ctx, SYSCTL_CHILDREN(stats), OID_AUTO, + "rx_fifo_overflows", CTLFLAG_RD, &sc->rx_fifo_overflows, 0, + "Rx FIFO overflows"); + + SYSCTL_ADD_INT(ctx, SYSCTL_CHILDREN(stats), OID_AUTO, + "rx_bytes", CTLFLAG_RD, &sc->rx_bytes, 0, + "Rx bytes"); + + SYSCTL_ADD_INT(ctx, SYSCTL_CHILDREN(stats), OID_AUTO, + "rx_long_err", CTLFLAG_RD, &sc->rx_long_err, 0, + "Rx too long frame errors"); + + SYSCTL_ADD_INT(ctx, SYSCTL_CHILDREN(stats), OID_AUTO, + "rx_short_err", CTLFLAG_RD, &sc->rx_short_err, 0, + "Rx too short frame errors"); + + SYSCTL_ADD_INT(ctx, SYSCTL_CHILDREN(stats), OID_AUTO, + "tx_bytes", CTLFLAG_RD, &sc->tx_bytes, 0, + "Tx bytes"); + SYSCTL_ADD_INT(ctx, SYSCTL_CHILDREN(stats), OID_AUTO, + "tx_packets", CTLFLAG_RD, &sc->tx_packets, 0, + "Tx packets"); + SYSCTL_ADD_INT(ctx, SYSCTL_CHILDREN(stats), OID_AUTO, + "tx_skip", CTLFLAG_RD, &sc->tx_skip, 0, + "Tx skip count for GDMA ports"); + SYSCTL_ADD_INT(ctx, SYSCTL_CHILDREN(stats), OID_AUTO, + "tx_collision", CTLFLAG_RD, &sc->tx_collision, 0, + "Tx collision count for GDMA ports"); +} + +#ifdef IF_RT_PHY_SUPPORT +static int +rt_miibus_readreg(device_t dev, int phy, int reg) +{ + struct rt_softc *sc = device_get_softc(dev); + + /* + * PSEUDO_PHYAD is a special value for indicate switch attached. + * No one PHY use PSEUDO_PHYAD (0x1e) address. + */ + if (phy == 31) { + /* Fake PHY ID for bfeswitch attach */ + switch (reg) { + case MII_BMSR: + return (BMSR_EXTSTAT|BMSR_MEDIAMASK); + case MII_PHYIDR1: + return 0x40; /* As result of faking */ + case MII_PHYIDR2: /* PHY will detect as */ + return 0x6250; /* bfeswitch */ + } + } + + + /* Wait prev command done if any */ + while (RT_READ(sc, MDIO_ACCESS) & MDIO_CMD_ONGO); + RT_WRITE(sc, MDIO_ACCESS, + MDIO_CMD_ONGO || + ((phy << MDIO_PHY_ADDR_SHIFT) & MDIO_PHY_ADDR_MASK) || + ((reg << MDIO_PHYREG_ADDR_SHIFT) & MDIO_PHYREG_ADDR_MASK)); + while (RT_READ(sc, MDIO_ACCESS) & MDIO_CMD_ONGO); + + return (RT_READ(sc, MDIO_ACCESS) & MDIO_PHY_DATA_MASK); +} + +static int +rt_miibus_writereg(device_t dev, int phy, int reg, int val) +{ + struct rt_softc *sc = device_get_softc(dev); + + /* Wait prev command done if any */ + while (RT_READ(sc, MDIO_ACCESS) & MDIO_CMD_ONGO); + RT_WRITE(sc, MDIO_ACCESS, + MDIO_CMD_ONGO || MDIO_CMD_WR || + ((phy << MDIO_PHY_ADDR_SHIFT) & MDIO_PHY_ADDR_MASK) || + ((reg << MDIO_PHYREG_ADDR_SHIFT) & MDIO_PHYREG_ADDR_MASK) || + (val & MDIO_PHY_DATA_MASK)); + while (RT_READ(sc, MDIO_ACCESS) & MDIO_CMD_ONGO); + + return (0); +} + +void +rt_miibus_statchg(device_t dev) +{ + struct rt_softc *sc = device_get_softc(dev); + struct mii_data *mii; + + mii = device_get_softc(sc->rt_miibus); + + if ((mii->mii_media_status & (IFM_ACTIVE | IFM_AVALID)) == + (IFM_ACTIVE | IFM_AVALID)) { + switch (IFM_SUBTYPE(mii->mii_media_active)) { + case IFM_10_T: + case IFM_100_TX: + /* XXX check link here */ + sc->flags |= 1; + break; + default: + break; + } + } +} +#endif /* IF_RT_PHY_SUPPORT */ + +static device_method_t rt_dev_methods[] = +{ + + DEVMETHOD(device_probe, rt_probe), + DEVMETHOD(device_attach, rt_attach), + DEVMETHOD(device_detach, rt_detach), + DEVMETHOD(device_shutdown, rt_shutdown), + DEVMETHOD(device_suspend, rt_suspend), + DEVMETHOD(device_resume, rt_resume), + + /* bus interface */ + DEVMETHOD(bus_print_child, bus_generic_print_child), + DEVMETHOD(bus_driver_added, bus_generic_driver_added), + +#ifdef IF_RT_PHY_SUPPORT + /* MII interface */ + DEVMETHOD(miibus_readreg, rt_miibus_readreg), + DEVMETHOD(miibus_writereg, rt_miibus_writereg), + DEVMETHOD(miibus_statchg, rt_miibus_statchg), +#endif + { 0, 0 } +}; + +static driver_t rt_driver = +{ + "rt", + rt_dev_methods, + sizeof(struct rt_softc) +}; + +static devclass_t rt_dev_class; + +DRIVER_MODULE(rt, nexus, rt_driver, rt_dev_class, 0, 0); +MODULE_DEPEND(rt, ether, 1, 1, 1); +MODULE_DEPEND(rt, miibus, 1, 1, 1); + Property changes on: sys/dev/rt/if_rt.c ___________________________________________________________________ Added: svn:mime-type + text/plain Added: svn:keywords + FreeBSD=%H Added: svn:eol-style + native Index: sys/dev/rt/if_rtreg.h =================================================================== --- sys/dev/rt/if_rtreg.h (revision 0) +++ sys/dev/rt/if_rtreg.h (revision 0) @@ -0,0 +1,289 @@ +/*- + * Copyright (c) 2009, Aleksandr Rybalko + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice unmodified, this list of conditions, and the following + * disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + * + * $FreeBSD$ + */ + +#ifndef __IF_RAFREG_H__ +#define __IF_RAFREG_H__ + +#define RT_READ(sc, reg) \ + bus_space_read_4((sc)->bst, (sc)->bsh, reg) + +#define RT_WRITE(sc, reg, val) \ + bus_space_write_4((sc)->bst, (sc)->bsh, reg, val) + +#define GE_PORT_BASE 0x0000 + +#define MDIO_ACCESS 0x00 +#define MDIO_CMD_ONGO (1<<31) +#define MDIO_CMD_WR (1<<30) +#define MDIO_PHY_ADDR_MASK 0x1f000000 +#define MDIO_PHY_ADDR_SHIFT 24 +#define MDIO_PHYREG_ADDR_MASK 0x001f0000 +#define MDIO_PHYREG_ADDR_SHIFT 16 +#define MDIO_PHY_DATA_MASK 0x0000ffff +#define MDIO_PHY_DATA_SHIFT 0 + +#define FE_GLO_CFG 0x08 /*Frame Engine Global Configuration */ +#define EXT_VLAN_TYPE_MASK 0xffff0000 +#define EXT_VLAN_TYPE_SHIFT 16 +#define EXT_VLAN_TYPE_DFLT 0x81000000 +#define US_CYC_CNT_MASK 0x0000ff00 +#define US_CYC_CNT_SHIFT 8 +#define US_CYC_CNT_DFLT (132<<8) /* sys clocks per 1uS */ +#define L2_SPACE (8<<4) /* L2 space. Unit is 8 bytes */ + +#define FE_RST_GLO 0x0C /*Frame Engine Global Reset*/ +#define FC_DROP_CNT_MASK 0xffff0000 /*Flow control drop count.*/ +#define FC_DROP_CNT_SHIFT 16 +#define PSE_RESET (1<<0) + +#define FE_INT_STATUS 0x10 +#define CNT_PPE_AF (1<<31) +#define CNT_GDM_AF (1<<29) +#define PSE_P2_FC (1<<26) +#define GDM_CRC_DROP (1<<25) +#define PSE_BUF_DROP (1<<24) +#define GDM_OTHER_DROP (1<<23) +#define PSE_P1_FC (1<<22) +#define PSE_P0_FC (1<<21) +#define PSE_FQ_EMPTY (1<<20) +#define INT_TX_COHERENT (1<<17) +#define INT_RX_COHERENT (1<<16) +#define INT_TXQ3_DONE (1<<11) +#define INT_TXQ2_DONE (1<<10) +#define INT_TXQ1_DONE (1<<9) +#define INT_TXQ0_DONE (1<<8) +#define INT_RX_DONE (1<<2) +#define TX_DLY_INT (1<<1) /* TXQ[0|1]_DONE with delay */ +#define RX_DLY_INT (1<<0) /* RX_DONE with delay */ +#define FE_INT_ENABLE 0x14 +#define MDIO_CFG2 0x18 +#define FOE_TS_T 0x1c +#define PSE_FQ_PCNT_MASK 0xff000000 +#define PSE_FQ_PCNT_SHIFT 24 +#define FOE_TS_TIMESTAMP_MASK 0x0000ffff +#define FOE_TS_TIMESTAMP_SHIFT 0 + +#define GDMA1_BASE 0x0020 +#define GDMA2_BASE 0x0060 +#define CDMA_BASE 0x0080 + +#define GDMA_FWD_CFG 0x00 /* Only GDMA */ +#define GDM_DROP_256B (1<<23) +#define GDM_ICS_EN (1<<22) +#define GDM_TCS_EN (1<<21) +#define GDM_UCS_EN (1<<20) +#define GDM_DISPAD (1<<18) +#define GDM_DISCRC (1<<17) +#define GDM_STRPCRC (1<<16) +#define GDM_UFRC_P_SHIFT 12 +#define GDM_BFRC_P_SHIFT 8 +#define GDM_MFRC_P_SHIFT 4 +#define GDM_OFRC_P_SHIFT 0 +#define GDM_XFRC_P_MASK 0x07 +#define GDM_DST_PORT_CPU 0 +#define GDM_DST_PORT_GDMA1 1 +#define GDM_DST_PORT_GDMA2 2 +#define GDM_DST_PORT_PPE 6 +#define GDM_DST_PORT_DISCARD 7 + +#define CDMA_CSG_CFG 0x00 /* Only CDMA */ +#define INS_VLAN_TAG (0x8100<<16) +#define ICS_GEN_EN (1<<2) +#define TCS_GEN_EN (1<<1) +#define UCS_GEN_EN (1<<0) + +#define GDMA_SCH_CFG 0x04 +#define GDM1_SCH_MOD_MASK 0x03000000 +#define GDM1_SCH_MOD_SHIFT 24 +#define GDM1_SCH_MOD_WRR 0 +#define GDM1_SCH_MOD_STRICT 1 +#define GDM1_SCH_MOD_MIXED 2 +#define GDM1_WT_1 0 +#define GDM1_WT_2 1 +#define GDM1_WT_4 2 +#define GDM1_WT_8 3 +#define GDM1_WT_16 4 +#define GDM1_WT_Q3_SHIFT 12 +#define GDM1_WT_Q2_SHIFT 8 +#define GDM1_WT_Q1_SHIFT 4 +#define GDM1_WT_Q0_SHIFT 0 + +#define GDMA_SHPR_CFG 0x08 +#define GDM1_SHPR_EN (1<<24) +#define GDM1_BK_SIZE_MASK 0x00ff0000 /* Bucket size 1kB units */ +#define GDM1_BK_SIZE_SHIFT 16 +#define GDM1_TK_RATE_MASK 0x00003fff /* Shaper token rate 8B/ms */ +#define GDM1_TK_RATE_SHIFT 0 + +#define GDMA_MAC_ADRL 0x0C +#define GDMA_MAC_ADRH 0x10 + +#define PPPOE_SID_0001 0x08 /* 0..15 SID0, 15..31 SID1 */ +#define PPPOE_SID_0203 0x0c +#define PPPOE_SID_0405 0x10 +#define PPPOE_SID_0607 0x14 +#define PPPOE_SID_0809 0x18 +#define PPPOE_SID_1011 0x1c +#define PPPOE_SID_1213 0x20 +#define PPPOE_SID_1415 0x24 +#define VLAN_ID_0001 0x28 /* 0..11 VID0, 15..26 VID1 */ +#define VLAN_ID_0203 0x2c +#define VLAN_ID_0405 0x30 +#define VLAN_ID_0607 0x34 +#define VLAN_ID_0809 0x38 +#define VLAN_ID_1011 0x3c +#define VLAN_ID_1213 0x40 +#define VLAN_ID_1415 0x44 + +#define PSE_BASE 0x0040 +#define PSE_FQFC_CFG 0x00 +#define FQ_MAX_PCNT_MASK 0xff000000 +#define FQ_MAX_PCNT_SHIFT 24 +#define FQ_FC_RLS_MASK 0x00ff0000 +#define FQ_FC_RLS_SHIFT 16 +#define FQ_FC_ASRT_MASK 0x0000ff00 +#define FQ_FC_ASRT_SHIFT 8 +#define FQ_FC_DROP_MASK 0x000000ff +#define FQ_FC_DROP_SHIFT 0 + +#define CDMA_FC_CFG 0x04 +#define GDMA1_FC_CFG 0x08 +#define GDMA2_FC_CFG 0x0C +#define P_SHARING (1<<28) +#define P_HQ_DEF_MASK 0x0f000000 +#define P_HQ_DEF_SHIFT 24 +#define P_HQ_RESV_MASK 0x00ff0000 +#define P_HQ_RESV_SHIFT 16 +#define P_LQ_RESV_MASK 0x0000ff00 +#define P_LQ_RESV_SHIFT 8 +#define P_IQ_ASRT_MASK 0x000000ff +#define P_IQ_ASRT_SHIFT 0 + +#define CDMA_OQ_STA 0x10 +#define GDMA1_OQ_STA 0x14 +#define GDMA2_OQ_STA 0x18 +#define P_OQ3_PCNT_MASK 0xff000000 +#define P_OQ3_PCNT_SHIFT 24 +#define P_OQ2_PCNT_MASK 0x00ff0000 +#define P_OQ2_PCNT_SHIFT 16 +#define P_OQ1_PCNT_MASK 0x0000ff00 +#define P_OQ1_PCNT_SHIFT 8 +#define P_OQ0_PCNT_MASK 0x000000ff +#define P_OQ0_PCNT_SHIFT 0 + +#define PSE_IQ_STA 0x1C +#define P6_OQ0_PCNT_MASK 0xff000000 +#define P6_OQ0_PCNT_SHIFT 24 +#define P2_IQ_PCNT_MASK 0x00ff0000 +#define P2_IQ_PCNT_SHIFT 16 +#define P1_IQ_PCNT_MASK 0x0000ff00 +#define P1_IQ_PCNT_SHIFT 8 +#define P0_IQ_PCNT_MASK 0x000000ff +#define P0_IQ_PCNT_SHIFT 0 + +#define PDMA_BASE 0x0100 +#define PDMA_GLO_CFG 0x00 +#define FE_TX_WB_DDONE (1<<6) +#define FE_DMA_BT_SIZE4 (0<<4) +#define FE_DMA_BT_SIZE8 (1<<4) +#define FE_DMA_BT_SIZE16 (2<<4) +#define FE_RX_DMA_BUSY (1<<3) +#define FE_RX_DMA_EN (1<<2) +#define FE_TX_DMA_BUSY (1<<1) +#define FE_TX_DMA_EN (1<<0) +#define PDMA_RST_IDX 0x04 +#define FE_RST_DRX_IDX0 (1<<16) +#define FE_RST_DTX_IDX3 (1<<3) +#define FE_RST_DTX_IDX2 (1<<2) +#define FE_RST_DTX_IDX1 (1<<1) +#define FE_RST_DTX_IDX0 (1<<0) + +#define PDMA_SCH_CFG 0x08 +#define DELAY_INT_CFG 0x0C +#define TXDLY_INT_EN (1<<31) +#define TXMAX_PINT_SHIFT 24 +#define TXMAX_PTIME_SHIFT 16 +#define RXDLY_INT_EN (1<<15) +#define RXMAX_PINT_SHIFT 8 +#define RXMAX_PTIME_SHIFT 0 + +#define TX_BASE_PTR0 0x10 +#define TX_MAX_CNT0 0x14 +#define TX_CTX_IDX0 0x18 +#define TX_DTX_IDX0 0x1C + +#define TX_BASE_PTR1 0x20 +#define TX_MAX_CNT1 0x24 +#define TX_CTX_IDX1 0x28 +#define TX_DTX_IDX1 0x2C + +#define RX_BASE_PTR0 0x30 +#define RX_MAX_CNT0 0x34 +#define RX_CALC_IDX0 0x38 +#define RX_DRX_IDX0 0x3C + +#define TX_BASE_PTR2 0x40 +#define TX_MAX_CNT2 0x44 +#define TX_CTX_IDX2 0x48 +#define TX_DTX_IDX2 0x4C + +#define TX_BASE_PTR3 0x50 +#define TX_MAX_CNT3 0x54 +#define TX_CTX_IDX3 0x58 +#define TX_DTX_IDX3 0x5C + +#define TX_BASE_PTR(qid) (((qid>1)?(0x20):(0x10)) + (qid) * 16) +#define TX_MAX_CNT(qid) (((qid>1)?(0x24):(0x14)) + (qid) * 16) +#define TX_CTX_IDX(qid) (((qid>1)?(0x28):(0x18)) + (qid) * 16) +#define TX_DTX_IDX(qid) (((qid>1)?(0x2c):(0x1c)) + (qid) * 16) + +#define PPE_BASE 0x0200 + +#define CNTR_BASE 0x0400 +#define PPE_AC_BCNT0 0x000 +#define PPE_AC_PCNT0 0x004 +#define PPE_AC_BCNT63 0x1F8 +#define PPE_AC_PCNT63 0x1FC +#define PPE_MTR_CNT0 0x200 +#define PPE_MTR_CNT63 0x2FC +#define GDMA_TX_GBCNT0 0x300 +#define GDMA_TX_GPCNT0 0x304 +#define GDMA_TX_SKIPCNT0 0x308 +#define GDMA_TX_COLCNT0 0x30C +#define GDMA_RX_GBCNT0 0x320 +#define GDMA_RX_GPCNT0 0x324 +#define GDMA_RX_OERCNT0 0x328 +#define GDMA_RX_FERCNT0 0x32C +#define GDMA_RX_SHORT_ERCNT0 0x330 +#define GDMA_RX_LONG_ERCNT0 0x334 +#define GDMA_RX_CSUM_ERCNT0 0x338 + +#define POLICYTABLE_BASE 0x1000 + +#endif /* __IF_RAFREG_H__ */ Property changes on: sys/dev/rt/if_rtreg.h ___________________________________________________________________ Added: svn:mime-type + text/plain Added: svn:keywords + FreeBSD=%H Added: svn:eol-style + native --Multipart=_Thu__30_Jun_2011_15_22_49_+0300_Nm_S4zP.J.=dEWOr-- From owner-freebsd-net@FreeBSD.ORG Thu Jun 30 12:49:17 2011 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 85536106566C for ; Thu, 30 Jun 2011 12:49:17 +0000 (UTC) (envelope-from korvus@comcast.net) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by mx1.freebsd.org (Postfix) with ESMTP id 475C58FC12 for ; Thu, 30 Jun 2011 12:49:17 +0000 (UTC) Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta04.westchester.pa.mail.comcast.net with comcast id 2CfP1h0020vyq2s54CpHkf; Thu, 30 Jun 2011 12:49:17 +0000 Received: from [10.0.0.79] ([71.199.122.142]) by omta05.westchester.pa.mail.comcast.net with comcast id 2Cp61h01j34Sj4f3RCpDlX; Thu, 30 Jun 2011 12:49:14 +0000 Message-ID: <4E0C70C7.2000102@comcast.net> Date: Thu, 30 Jun 2011 08:49:11 -0400 From: Steve Polyack User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: perryh@pluto.rain.com References: <4E0B540B.3090400@comcast.net> <4e0c0548.eW27hshSLoLhhTu1%perryh@pluto.rain.com> In-Reply-To: <4e0c0548.eW27hshSLoLhhTu1%perryh@pluto.rain.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, freebsd-questions@freebsd.org Subject: Re: Question about NIC link state initialization 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, 30 Jun 2011 12:49:17 -0000 On 6/30/2011 1:10 AM, perryh@pluto.rain.com wrote: > Steve Polyack wrote: > >> ... An occaisional fat-finger in /etc/fstab may cause one to >> end up in single-user mode ... some of these systems have a LOM >> (lights-out management) controller which shares the system's >> on-board NICs ... when the system drops out of init(8) and into >> single-user mode, the links on the interfaces never come up, >> and therefore the LOM becomes inaccessible. >> >> ... all one has to do is run ifconfig to cause the NIC's links to >> come up ... why do we have to run ifconfig(8) to bring the links >> up on the attached interfaces? > When trying to troubleshoot a problem that was known or suspected to > involve the network or its hardware, one might not _want_ the NICs > alive. > >> Short of patching init(8) (or perhaps the NIC drivers?), I don't >> see another way for me to ensure the links come up even when the >> system drops into single-user mode on boot. > Something in /root/.profile, perhaps? That should get run when the > single-user shell starts up, if it's started as a "login" shell. > This won't work. When the system kicks you into single-user mode, you are prompted to enter the name of a shell or press enter for /bin/sh. If no one is there to press enter, or enter the path to an alternate shell, then a shell never starts. From owner-freebsd-net@FreeBSD.ORG Thu Jun 30 12:54:26 2011 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 B1AFF106566B for ; Thu, 30 Jun 2011 12:54:26 +0000 (UTC) (envelope-from korvus@comcast.net) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by mx1.freebsd.org (Postfix) with ESMTP id 722598FC16 for ; Thu, 30 Jun 2011 12:54:26 +0000 (UTC) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta07.westchester.pa.mail.comcast.net with comcast id 2C7l1h0031uE5Es57CuSuB; Thu, 30 Jun 2011 12:54:26 +0000 Received: from [10.0.0.79] ([71.199.122.142]) by omta16.westchester.pa.mail.comcast.net with comcast id 2CuR1h00n34Sj4f3cCuRYB; Thu, 30 Jun 2011 12:54:26 +0000 Message-ID: <4E0C7208.2040805@comcast.net> Date: Thu, 30 Jun 2011 08:54:32 -0400 From: Steve Polyack User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Daniel Feenberg References: <4E0B540B.3090400@comcast.net> <4e0c0548.eW27hshSLoLhhTu1%perryh@pluto.rain.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, perryh@pluto.rain.com, freebsd-questions@freebsd.org Subject: Re: Question about NIC link state initialization 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, 30 Jun 2011 12:54:26 -0000 On 6/30/2011 6:49 AM, Daniel Feenberg wrote: > > > On Wed, 29 Jun 2011, perryh@pluto.rain.com wrote: > >> Steve Polyack wrote: >> >>> ... An occaisional fat-finger in /etc/fstab may cause one to >>> end up in single-user mode ... some of these systems have a LOM >>> (lights-out management) controller which shares the system's >>> on-board NICs ... when the system drops out of init(8) and into >>> single-user mode, the links on the interfaces never come up, >>> and therefore the LOM becomes inaccessible. >>> >>> ... all one has to do is run ifconfig to cause the NIC's links to >>> come up ... why do we have to run ifconfig(8) to bring the links >>> up on the attached interfaces? >> >> When trying to troubleshoot a problem that was known or suspected to >> involve the network or its hardware, one might not _want_ the NICs > > Well, maybe, but if the system needs to boot into multi-user mode for > the LOM to be available, what is the need for the LOM? At that point > you can do everything you might need through the OS interface. Can I > ask what is the brand of this so-called LOM? Is there any > documentation implying something more useful? Do they describe doing a > bare metal install of an > OS? They are the Dell Remote Access Controllers (DRACs). Now, they do have their own dedicated NIC, which we use for anything that really needs the attention. However, the shared feature saves us a switchport per server we use it on. When both on-board NICs are cabled (i.e. for lagg(4) failover), then the DRAC's shared NIC mode *also* supports automatic failover between both on-board NICs. This doesn't help however if the operating system never turns on the links to either on-board NIC. I was able to "fix" the single-user mode behavior (which I agree, isn't necessarily broken) and get it to bring up the links by simply patching init(8) to call system("/sbin/ifconfig") before prompting for the single-user shell. It works, but I feel dirty. - Steve From owner-freebsd-net@FreeBSD.ORG Fri Jul 1 03:34:26 2011 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 28A7B106566B for ; Fri, 1 Jul 2011 03:34:26 +0000 (UTC) (envelope-from adrian.chadd@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 DD16E8FC14 for ; Fri, 1 Jul 2011 03:34:25 +0000 (UTC) Received: by ywf7 with SMTP id 7so1514965ywf.13 for ; Thu, 30 Jun 2011 20:34:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ufh5G7cD0qq6dee6LKRp5W8281lv6hKSteMj4E0Asqc=; b=VJaamKTONZziSjRWjBWJNpnythjfsJNaiQriIsdHR9naDUdlM3lcfIffRchCDU1Qz0 XiV/NAsH+eBBcsG/1FUsprc6KR0rZR8oEYuUiQyg9bkek+Q81V5qOtq3rfL/+UcraB6P aQKAvojjguR468U+Tg3Joyhz+KyiBZ9ZHzvMA= MIME-Version: 1.0 Received: by 10.151.50.15 with SMTP id c15mr2600000ybk.285.1309491263486; Thu, 30 Jun 2011 20:34:23 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.151.45.11 with HTTP; Thu, 30 Jun 2011 20:34:23 -0700 (PDT) In-Reply-To: <20110628002556.GA87130@atarininja.org> References: <201105192153.p4JLrvtH004172@red.freebsd.org> <20110521064847.GB23992@lonesome.com> <20110522193007.GA63178@atarininja.org> <20110628002556.GA87130@atarininja.org> Date: Fri, 1 Jul 2011 11:34:23 +0800 X-Google-Sender-Auth: xij-M-K7bKPrqFTvCOYqibBe6G0 Message-ID: From: Adrian Chadd To: Wesley Shields Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: fwd: kern/157188: [libpcap] [patch] incorporate patch from upstream 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, 01 Jul 2011 03:34:26 -0000 I suggest bugging bz@ as much as possible. :) Adrian On 28 June 2011 08:25, Wesley Shields wrote: > I'm still hoping someone who cares about IPv6 is willing to commit this > fix for libpcap in the base before 9.0. Is anyone willing to tackle > this? It's been in the port for a while now, and in upstream for even > longer. > > -- WXS > > On Sun, May 22, 2011 at 03:30:07PM -0400, Wesley Shields wrote: >> I've updated the port to address this. The audit trail for this PR has a >> patch which touches more than just libpcap. I'm curious if anyone on >> this list has comments on it, and if any committer wants to commit it >> (at least the libpcap part, the others appear right to me). >> >> -- WXS >> >> On Sat, May 21, 2011 at 01:48:47AM -0500, Mark Linimon wrote: >> > Apparently affects both the port and src. >> > mcl >> > >> > On Thu, May 19, 2011 at 09:53:57PM +0000, Peter Losher wrote: >> > > >> > > >Number: =A0 =A0 =A0 =A0 157188 >> > > >Category: =A0 =A0 =A0 misc >> > > >Synopsis: =A0 =A0 =A0 libpcap >> > > >Confidential: =A0 no >> > > >Severity: =A0 =A0 =A0 non-critical >> > > >Priority: =A0 =A0 =A0 medium >> > > >Responsible: =A0 =A0freebsd-bugs >> > > >State: =A0 =A0 =A0 =A0 =A0open >> > > >Quarter: >> > > >Keywords: >> > > >Date-Required: >> > > >Class: =A0 =A0 =A0 =A0 =A0sw-bug >> > > >Submitter-Id: =A0 current-users >> > > >Arrival-Date: =A0 Thu May 19 22:00:27 UTC 2011 >> > > >Closed-Date: >> > > >Last-Modified: >> > > >Originator: =A0 =A0 Peter Losher >> > > >Release: =A0 =A0 =A0 =A08.2-RELEASE >> > > >Organization: >> > > Internet Systems Consortium >> > > >Environment: >> > > FreeBSD freebsd8.lab.isc.org 8.2-RELEASE FreeBSD 8.2-RELEASE #0: Thu= Feb 17 02:41:51 UTC 2011 =A0 =A0 root@mason.cse.buffalo.edu:/usr/obj/usr/s= rc/sys/GENERIC =A0amd64 >> > > >Description: >> > > One of our engineers @ISC discovered that there is a bug in the curr= ently released version of libpcap (in base and in ports) that can be trigge= red when using an "ip6 protochain" filter. =A0It's due to the fairly compli= cated BPF bytecode that libpcap generates for IPv6 header chasing combined = with a sign extension bug when processing JA (jump absolute) opcodes. =A0(J= A is used to go backwards and without sign extension on 64 bit platforms th= e BPF interpreter incorrectly jumps forward... a lot.) >> > > >> > > >How-To-Repeat: >> > > root@freebsd8:~# tcpdump -nr ip6-hopbyhop-icmp.pcap 'ip6 protochain = 58' >> > > reading from file ip6-hopbyhop-icmp.pcap, link-type EN10MB (Ethernet= ) >> > > Segmentation fault: 11 (core dumped) >> > > >> > > >Fix: >> > > There is a fix in the libpcap repository: >> > > >> > > https://github.com/mcr/libpcap/commit/ecdc5c0a7f7591a7cd4aff696e4275= 7c677fbbf7 >> > > >> > > but the tcpdump-workers have been pretty tardy about putting out new= er code, so it sits there stalled. >> > > >> > > With the patch applied, it all works well and you should see somethi= ng like this: >> > > >> > > -=3D- >> > > $ tcpdump -nr ip6-hopbyhop-icmp.pcap 'ip6 protochain 58' >> > > reading from file ip6-hopbyhop-icmp.pcap, link-type EN10MB (Ethernet= ) >> > > 18:43:07.098489 IP6 fe80::208:7dff:feb7:2cca > ff02::1: HBH ICMP6, m= ulticast listener queryv2 =A0[gaddr ::], length 28 >> > > -=3D- >> > > >> > > >Release-Note: >> > > >Audit-Trail: >> > > >Unformatted: >> > > _______________________________________________ >> > > freebsd-bugs@freebsd.org mailing list >> > > http://lists.freebsd.org/mailman/listinfo/freebsd-bugs >> > > To unsubscribe, send any mail to "freebsd-bugs-unsubscribe@freebsd.o= rg" >> _______________________________________________ >> 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" > _______________________________________________ > 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 Jul 1 05:34:11 2011 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 428CE106564A for ; Fri, 1 Jul 2011 05:34:11 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id D50CB8FC12 for ; Fri, 1 Jul 2011 05:34:10 +0000 (UTC) Received: from julian-mac.elischer.org (home-nat.elischer.org [67.100.89.137]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id p615L2Tg087358 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 30 Jun 2011 22:21:03 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <4E0D593B.7090206@freebsd.org> Date: Thu, 30 Jun 2011 22:20:59 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Michael MacLeod References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Bridging Two Tunnel Interfaces For ALTQ 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, 01 Jul 2011 05:34:11 -0000 On 6/29/11 11:28 AM, Michael MacLeod wrote: > I use pf+ALTQ to achieve some pretty decent traffic shaping results at home. > However, recently signed up to be part of an IPv6 trial with my ISP, and > they've given me a second (dual-stacked) PPPoE login with which to test > with. The problem is that the second login lacks my static IP or my routed > /29. I can have both tunnels up simultaneously, but that becomes a pain to > traffic shape since I can't have them both assigned to the same ALTQ. > > ... unless there is some way for me to turn the ng interfaces (I'm using > mpd5) into ethernet interfaces that could be assigned to an if_bridge. I > could easily disable IPv4 on the IPv6 tunnel, which would clean up any > routing issues, assign both tunnels to the bridge, and put the ALTQ on the > bridge. It just might have the effect I'm looking for. Bonus points if the > solution can be extended to allow it to work with a gif tunnel as well, so > that users of 6in4 tunnels could use it (my ISPs IPv6 beta won't let me do > rDNS delegation, so I might want to try a tunnel from he.net instead). > > I spent some time this morning trying to make netgraph do this with the two > ng interfaces, but didn't have any luck. Google didn't turn up anyone trying > to do anything similar that I could find; closest I got was this: > http://lists.freebsd.org/pipermail/freebsd-net/2004-November/005598.html > > This is all assuming that the best way to use ALTQ on multiple outbound > connections is with a bridge. If there is another or more elegant solution, > I'd love to hear it. rather than trying to shoehorn ng into if_bridge, why not use the netgraph bridge itility, or maybe one of the many other netgraph nodes that can split traffic. fofr example the ng_bpf filter can filter traffic on an almost arbitrary manner that you program using the bpf filter language. > _______________________________________________ > 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 Jul 1 07:59:51 2011 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 5104E106566C for ; Fri, 1 Jul 2011 07:59:51 +0000 (UTC) (envelope-from mikemacleod@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 10A5A8FC0A for ; Fri, 1 Jul 2011 07:59:50 +0000 (UTC) Received: by gwb15 with SMTP id 15so1564849gwb.13 for ; Fri, 01 Jul 2011 00:59:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=yiFpVBCsPVd9gYr0xxJJrZ/VtYRt1K8PqqWe/gIw/gw=; b=vjmBqKjahLaOsyPx9Ky18jHe7xVPVsKa2KDOT2OZu4k1Qiq9fxqXctkJToAb7G0I2G krVHZ2fJmJhmJcMbYZtxf648vt2zl0e/2aGyDMHBtR6uX6XwW4xCIpP1p4rKZn3KasSs KYb6KOPo41yBrwkF5d5QzDcD6MeJZ7gwNoU+k= Received: by 10.91.159.5 with SMTP id l5mr2662335ago.100.1309507190130; Fri, 01 Jul 2011 00:59:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.84.1 with HTTP; Fri, 1 Jul 2011 00:59:30 -0700 (PDT) In-Reply-To: <4E0D593B.7090206@freebsd.org> References: <4E0D593B.7090206@freebsd.org> From: Michael MacLeod Date: Fri, 1 Jul 2011 03:59:30 -0400 Message-ID: To: Julian Elischer Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: Bridging Two Tunnel Interfaces For ALTQ 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, 01 Jul 2011 07:59:51 -0000 On Fri, Jul 1, 2011 at 1:20 AM, Julian Elischer wrote: > On 6/29/11 11:28 AM, Michael MacLeod wrote: > >> I use pf+ALTQ to achieve some pretty decent traffic shaping results at >> home. >> However, recently signed up to be part of an IPv6 trial with my ISP, and >> they've given me a second (dual-stacked) PPPoE login with which to test >> with. The problem is that the second login lacks my static IP or my routed >> /29. I can have both tunnels up simultaneously, but that becomes a pain to >> traffic shape since I can't have them both assigned to the same ALTQ. >> >> ... unless there is some way for me to turn the ng interfaces (I'm using >> mpd5) into ethernet interfaces that could be assigned to an if_bridge. I >> could easily disable IPv4 on the IPv6 tunnel, which would clean up any >> routing issues, assign both tunnels to the bridge, and put the ALTQ on the >> bridge. It just might have the effect I'm looking for. Bonus points if the >> solution can be extended to allow it to work with a gif tunnel as well, so >> that users of 6in4 tunnels could use it (my ISPs IPv6 beta won't let me do >> rDNS delegation, so I might want to try a tunnel from he.net instead). >> >> I spent some time this morning trying to make netgraph do this with the >> two >> ng interfaces, but didn't have any luck. Google didn't turn up anyone >> trying >> to do anything similar that I could find; closest I got was this: >> http://lists.freebsd.org/**pipermail/freebsd-net/2004-** >> November/005598.html >> >> This is all assuming that the best way to use ALTQ on multiple outbound >> connections is with a bridge. If there is another or more elegant >> solution, >> I'd love to hear it. >> > > rather than trying to shoehorn ng into if_bridge, why not use the netgraph > bridge itility, > or maybe one of the many other netgraph nodes that can split traffic. > fofr example the ng_bpf filter can filter traffic on an almost arbitrary > manner that you program using > the bpf filter language. Julian, thanks for responding. I'm not particularly concerned about how I accomplish my goal, so long as I can accomplish it. I was thinking about using if_bridge or ng_bridge because I have past experience with software bridges in BSD and linux. Unfortunately, ng_bridge requires a node that has an ether hook. I spent a bit of time looking at the mpd5 documentation, and there's actually a config option to have mpd generate an extra tee node between the ppp and the iface nodes. These nodes are connected together using inet hooks. If I could find a netgraph node that can take inet in one side and ether on the other, I believe I'd be set. The nice thing (near as I can tell) about using ethernet based nodes would be that pretty much everything can talk to an ethernet interface (tcpdump, etc) and that ethernet should be fairly easy to fake; just assign a fake MAC to the ether nodes (which is what the ng_ether node does, pretty much) and the bridge will take care of making sure traffic for tunnel 0 doesn't go to tunnel 1, etc. I haven't read up very much about ng_bpf yet, but it seems like a pretty heavy tool for the job, and wouldn't the data have to enter userspace for parsing by the bpf script? Also, I've never written anything in bpf. It's not a huge hurdle, I hope, but it's certainly more involved than a six line ngctl incantation that turns my iface nodes into eiface nodes suitable for bridging. As I said, I'm not particularly concerned with the means, just the end itself really. If there were an elegant way to create a virtual ALTQ that I could then build sub-queues that were actually attached to the tunnels in pf that would also satisfy my end goal, without any netgraph mucking at all. I just haven't found any evidence that ALTQ has any ability to do that. I just have two tunnels, one using IPv4 and one using IPv6, that share the same bandwidth resource. I want a way to shape traffic based on the pool of bandwidth, not the tunnels running through the pool. From owner-freebsd-net@FreeBSD.ORG Fri Jul 1 08:12:34 2011 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 40967106566C; Fri, 1 Jul 2011 08:12:34 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (agora.rdrop.com [IPv6:2607:f678:1010::34]) by mx1.freebsd.org (Postfix) with ESMTP id 207068FC1A; Fri, 1 Jul 2011 08:12:34 +0000 (UTC) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id p618CVF2016862 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 1 Jul 2011 01:12:32 -0700 (PDT) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.12.9/Submit) with UUCP id p618CVU9016861; Fri, 1 Jul 2011 01:12:31 -0700 (PDT) Received: from fbsd61 by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA00188; Fri, 1 Jul 11 01:08:23 PDT Date: Fri, 01 Jul 2011 01:08:27 -0700 From: perryh@pluto.rain.com To: korvus@comcast.net Message-Id: <4e0d807b.wTa9PBvXJSlvUXly%perryh@pluto.rain.com> References: <4E0B540B.3090400@comcast.net> <4e0c0548.eW27hshSLoLhhTu1%perryh@pluto.rain.com> <4E0C7208.2040805@comcast.net> In-Reply-To: <4E0C7208.2040805@comcast.net> User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, feenberg@nber.org, freebsd-questions@freebsd.org Subject: Re: Question about NIC link state initialization 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, 01 Jul 2011 08:12:34 -0000 Steve Polyack wrote: > I was able to "fix" the single-user mode behavior (which I agree, > isn't necessarily broken) and get it to bring up the links by > simply patching init(8) to call system("/sbin/ifconfig") before > prompting for the single-user shell. It works, but I feel dirty. I see no particular objection to adding a way of running "something" ahead of the single-user shell, but system(3) is not necessarily the best mechanism to use for the purpose because it invokes a shell. It would be both more efficient and more robust to call fork(2) and exec(3) (or execve(2)) directly. It would be more general to fork/exec "/etc/rc.single" instead of "/sbin/ifconfig", expecting "/etc/rc.single" to be an executable script (with an appropriate shebang line) and ignoring the failure which would occur if it did not exist. (In your case, instead of a script, you could make /etc/rc.single a link to /sbin/ifconfig.) From owner-freebsd-net@FreeBSD.ORG Fri Jul 1 08:34:16 2011 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 CA9731065673; Fri, 1 Jul 2011 08:34:16 +0000 (UTC) (envelope-from adrian.chadd@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 7B7618FC13; Fri, 1 Jul 2011 08:34:16 +0000 (UTC) Received: by gwb15 with SMTP id 15so1575890gwb.13 for ; Fri, 01 Jul 2011 01:34:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=qNROUkF6JRLs5Dy18xXjTZC5aNhKXbJB4OdQYdNhAzw=; b=HecdNK9E5VC4M/QPG1UTOvpWTMtCfEYBMvJLSPvR9WJbc1d+Khvdj0125/b0b8QL1/ VDvOm3fkHzvpzMRXPN6YzelbLxelLcBwa8BEOLTW0AQPaVep47/2zR56qYr31TuZBZZn UeoC3zNmIKWhtr9TUC3VfKeRwWd5rnzoSwgGM= MIME-Version: 1.0 Received: by 10.150.179.2 with SMTP id b2mr2655896ybf.410.1309509255299; Fri, 01 Jul 2011 01:34:15 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.151.45.11 with HTTP; Fri, 1 Jul 2011 01:34:15 -0700 (PDT) In-Reply-To: <20110630152249.f369822f.ray@freebsd.org> References: <20110630152249.f369822f.ray@freebsd.org> Date: Fri, 1 Jul 2011 16:34:15 +0800 X-Google-Sender-Auth: Cu_6LSjq5adz1XaSE1n7AXS-edI Message-ID: From: Adrian Chadd To: Aleksandr Rybalko Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: Ralink Ethernet MAC support 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, 01 Jul 2011 08:34:16 -0000 Can you verify that _tx_ works when you do an ifconfig down/up ? Adrian On 30 June 2011 20:22, Aleksandr Rybalko wrote: > Hi folks, > > I have a patch that enable support of Ethernet MAC on most Ralink > system-on-chip. > > I use it more than half year and it works well. But still have some > problem, one of it: I still not found why driver stop receive frames > after ifconfig rt0 down/ifconfig rt0 up. Maybe somebody want to test > and/or help me with development. > > Driver still don't support VLAN/PPPoE offload, but able to transmit at > 88Mbps on 384MHz MIPS32 SoC. > > Usage: > # Enable if_rt > device =A0 =A0 =A0 =A0 =A0rt > > # Enable debug messages > options =A0 =A0 =A0 =A0 IF_RT_DEBUG > # Enable PHY support (untested because I don't seen such devices > # with PHYs attached to it yet, only attached to internal switch in > # RT305xF SoCs) > options =A0 =A0 =A0 =A0 IF_RT_PHY_SUPPORT =A0 =A0 =A0 =A0 =A0 =A0 =A0opt_= if_rt.h > # count of allocated dma ring buffers > options =A0 =A0 =A0 =A0 IF_RT_RING_DATA_COUNT =A0 =A0 =A0 =A0 =A0opt_if_r= t.h > > I will glad to see any comments/feedback about it. > > URL: http://my.ddteam.net/files/2011-06-30_if_rt.patch > > -- > Aleksandr Rybalko > > _______________________________________________ > 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 Jul 1 08:47:54 2011 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 0654C1065707; Fri, 1 Jul 2011 08:47:54 +0000 (UTC) (envelope-from ray@freebsd.org) Received: from dlink.ua (smtp.dlink.ua [193.138.187.146]) by mx1.freebsd.org (Postfix) with ESMTP id B60AD8FC1B; Fri, 1 Jul 2011 08:47:53 +0000 (UTC) Received: from gw-lan1.kiev.dlink.ua ([192.168.10.10] helo=terran.dlink.ua) by dlink.ua with smtp (Exim 4.63) (envelope-from ) id 1QcZJw-0000ot-Ld; Fri, 01 Jul 2011 11:43:28 +0300 Date: Fri, 1 Jul 2011 11:47:47 +0300 From: Aleksandr Rybalko To: Adrian Chadd Message-Id: <20110701114747.d4f54ba1.ray@freebsd.org> In-Reply-To: References: <20110630152249.f369822f.ray@freebsd.org> Organization: FreeBSD Project X-Mailer: Sylpheed 2.7.1 (GTK+ 2.20.1; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org Subject: Re: Ralink Ethernet MAC support 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, 01 Jul 2011 08:47:54 -0000 On Fri, 1 Jul 2011 16:34:15 +0800 Adrian Chadd wrote: >> Can you verify that _tx_ works when you do an ifconfig down/up ? >> Yes, I see packets on PC side: 11:46:01.346450 IP 192.168.0.1 > 192.168.0.90: ICMP echo request, id 61697, seq 31, length 64 11:46:01.346467 IP 192.168.0.90 > 192.168.0.1: ICMP echo reply, id 61697, seq 31, length 64 192.168.0.1 - is RT3052F box 192.168.0.90 - big brother (PC) >> >> Adrian >> >> On 30 June 2011 20:22, Aleksandr Rybalko wrote: >> > Hi folks, >> > >> > I have a patch that enable support of Ethernet MAC on most Ralink >> > system-on-chip. >> > >> > I use it more than half year and it works well. But still have some >> > problem, one of it: I still not found why driver stop receive >> > frames after ifconfig rt0 down/ifconfig rt0 up. Maybe somebody >> > want to test and/or help me with development. >> > >> > Driver still don't support VLAN/PPPoE offload, but able to >> > transmit at 88Mbps on 384MHz MIPS32 SoC. >> > >> > Usage: >> > # Enable if_rt >> > device          rt >> > >> > # Enable debug messages >> > options         IF_RT_DEBUG >> > # Enable PHY support (untested because I don't seen such devices >> > # with PHYs attached to it yet, only attached to internal switch in >> > # RT305xF SoCs) >> > options         IF_RT_PHY_SUPPORT              opt_if_rt.h >> > # count of allocated dma ring buffers >> > options         IF_RT_RING_DATA_COUNT          opt_if_rt.h >> > >> > I will glad to see any comments/feedback about it. >> > >> > URL: http://my.ddteam.net/files/2011-06-30_if_rt.patch >> > >> > -- >> > Aleksandr Rybalko >> > >> > _______________________________________________ >> > 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" >> > -- Aleksandr Rybalko From owner-freebsd-net@FreeBSD.ORG Fri Jul 1 17:24:31 2011 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 9157F1065672 for ; Fri, 1 Jul 2011 17:24:31 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id DF5248FC12 for ; Fri, 1 Jul 2011 17:24:30 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 57DE57300A; Fri, 1 Jul 2011 19:41:12 +0200 (CEST) Date: Fri, 1 Jul 2011 19:41:12 +0200 From: Luigi Rizzo To: net@freebsd.org Message-ID: <20110701174112.GA78060@onelab2.iet.unipi.it> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="PEIAKu/WMn1b1Hv9" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: ports@freebsd.org, Luigi Rizzo Subject: ports/net/click anyone ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: net@freebsd.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 17:24:31 -0000 --PEIAKu/WMn1b1Hv9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline [Cc to ports@freebsd,org, but please followup at net@freebsd.org] anyone interested in taking over maintainership of ports/net/click ? We have 1.5.0 in the tree, which is old and partly broken. 1.8.0 builds almost without problems, and the two patches i am attaching give huge speedups for the userland version, especially if used together with netmap. To get an idea of what you can get on a single core i7-870 CPU with the stock version and with these patches: 1.8.0 With patches InfiniteSource -> Discard 515Kpps 18.56Mpps InfiniteSource -> Queue -> Discard 500Kpps 13.41Mpps pcap netmap FromDevice->Queue->ToDevice 420Kpps 3.97 Mpps --- Details ---- Click userland performance was never a priority given the high cost (until now) of packet I/O. But once packet i/o has become quite fast, it turns out that there are to other big offenders: - the C++ memory allocator is quite expensive, and replacing it with thread-local freelists (Packet objects and data buffers can be made all with the same size) gives huge savings -- 100ns per packet or more even on a fast machine; - everytime an element wants a timestamp, it calls a syscall (gettimeofday() or similar) which consumes another 400-800ns per call. There are many elements (e.g. InfiniteSource, Counter, etc.) which timestamp packets. Attached there are a couple of patches which address these problems: - patch-pcap makes FromDevice and ToDevice use libpcap properly, supporting I/O in bursts to amortize the syscall overhead; - patch-more + introduces a NOTS option for InfiniteSource to remove timestamps. This gives a 10x performance improvement in simple apps using InfiniteSource + replaces the allocator for Packet and data buffers with local freelists; not thread safe, but this is easy to introduce. This gives another 1.5-2x speed improvement after the 10x gained removing timestamps; + enables BURST operation in Discard, giving another 2x speed improvement Using netmap instead of pcap is another big win, as you can see the forwarding performance of a simple FromDevice->Queue->ToDevice chain goes up by 10x You can find netmap at http://info.iet.unipi.it/~luigi/netmap/ cheers luigi v --PEIAKu/WMn1b1Hv9 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=patch-pcap diff -ur ../../work/click-1.8.0/elements/userlevel/fromdevice.cc ./elements/userlevel/fromdevice.cc --- ../../work/click-1.8.0/elements/userlevel/fromdevice.cc 2010-02-28 21:03:33.000000000 +0100 +++ ./elements/userlevel/fromdevice.cc 2011-07-01 10:42:54.000000000 +0200 @@ -73,6 +73,7 @@ FromDevice::configure(Vector &conf, ErrorHandler *errh) { bool promisc = false, outbound = false, sniffer = true; + _burst = 1; _snaplen = 2046; _headroom = Packet::default_headroom; _headroom += (4 - (_headroom + 2) % 4) % 4; // default 4/2 alignment @@ -89,9 +90,11 @@ "BPF_FILTER", 0, cpString, &bpf_filter, "OUTBOUND", 0, cpBool, &outbound, "HEADROOM", 0, cpUnsigned, &_headroom, + "BURST", 0, cpUnsigned, &_burst, "ENCAP", cpkC, &has_encap, cpWord, &encap_type, cpEnd) < 0) return -1; + click_chatter("FromDevice(%s): burst: %d", _ifname.c_str(), _burst); if (_snaplen > 8190 || _snaplen < 14) return errh->error("SNAPLEN out of range"); if (_headroom > 8190) @@ -361,6 +364,8 @@ p->set_packet_type_anno(Packet::MULTICAST); } +if (p->data() == 0 || p->length() < 16 || p->length() > 1536) + click_chatter("send pkt %p len %d", p->data(), p->length()); // set annotations p->set_timestamp_anno(Timestamp::make_usec(pkthdr->ts.tv_sec, pkthdr->ts.tv_usec)); p->set_mac_header(p->data()); @@ -381,10 +386,11 @@ #if FROMDEVICE_PCAP if (_capture == CAPTURE_PCAP) { // Read and push() at most one packet. - int r = pcap_dispatch(_pcap, 1, FromDevice_get_packet, (u_char *) this); - if (r > 0) - _pcap_task.reschedule(); - else if (r < 0 && ++_pcap_complaints < 5) + int r = pcap_dispatch(_pcap, _burst, FromDevice_get_packet, (u_char *) this); + if (r > 0) { + _count += r; + _pcap_task.fast_reschedule(); + } else if (r < 0 && ++_pcap_complaints < 5) ErrorHandler::default_handler()->error("%{element}: %s", this, pcap_geterr(_pcap)); } #endif @@ -421,12 +427,13 @@ FromDevice::run_task(Task *) { // Read and push() at most one packet. - int r = pcap_dispatch(_pcap, 1, FromDevice_get_packet, (u_char *) this); - if (r > 0) - _pcap_task.fast_reschedule(); - else if (r < 0 && ++_pcap_complaints < 5) + int r = pcap_dispatch(_pcap, _burst, FromDevice_get_packet, (u_char *) this); + if (r > 0) { + _count += r; + _pcap_task.fast_reschedule(); // was fast_reschedule + } else if (r < 0 && ++_pcap_complaints < 5) ErrorHandler::default_handler()->error("%{element}: %s", this, pcap_geterr(_pcap)); - return r > 0; + return r == (int)_burst; } #endif diff -ur ../../work/click-1.8.0/elements/userlevel/fromdevice.hh ./elements/userlevel/fromdevice.hh --- ../../work/click-1.8.0/elements/userlevel/fromdevice.hh 2010-02-28 21:06:16.000000000 +0100 +++ ./elements/userlevel/fromdevice.hh 2011-06-29 23:36:10.000000000 +0200 @@ -160,6 +160,7 @@ void selected(int fd); #if FROMDEVICE_PCAP + inline pcap_t *pcap() const { return _pcap; } bool run_task(Task *); #endif @@ -202,6 +203,8 @@ unsigned _headroom; enum { CAPTURE_PCAP, CAPTURE_LINUX }; int _capture; + + unsigned _burst; #if FROMDEVICE_PCAP String _bpf_filter; #endif diff -ur ../../work/click-1.8.0/elements/userlevel/todevice.cc ./elements/userlevel/todevice.cc --- ../../work/click-1.8.0/elements/userlevel/todevice.cc 2009-09-03 22:36:30.000000000 +0200 +++ ./elements/userlevel/todevice.cc 2011-07-01 10:43:53.000000000 +0200 @@ -58,7 +58,7 @@ ToDevice::ToDevice() : _task(this), _timer(&_task), _fd(-1), _my_fd(false), _q(0), - _pulls(0) + _pulls(0), _count(0) { } @@ -70,13 +70,16 @@ ToDevice::configure(Vector &conf, ErrorHandler *errh) { + _burst = 1; if (cp_va_kparse(conf, this, errh, "DEVNAME", cpkP+cpkM, cpString, &_ifname, + "BURST", 0, cpUnsigned, &_burst, "DEBUG", 0, cpBool, &_debug, cpEnd) < 0) return -1; if (!_ifname) return errh->error("interface not set"); + click_chatter("ToDevice %s burst %d\n", _ifname.c_str(), _burst); return 0; } @@ -85,6 +88,9 @@ { _timer.initialize(this); _fd = -1; +#if TODEVICE_PCAP + _pcap = 0; +#endif #if TODEVICE_BSD_DEV_BPF @@ -117,6 +123,9 @@ FromDevice *fdev = (FromDevice *)e->cast("FromDevice"); if (fdev && fdev->ifname() == _ifname && fdev->fd() >= 0) { _fd = fdev->fd(); +# if TODEVICE_PCAP + _pcap = fdev->pcap(); +# endif _my_fd = false; } } @@ -170,14 +179,21 @@ bool ToDevice::run_task(Task *) { - Packet *p = _q; + unsigned count; + Packet *p = _q; // previously saved packet _q = 0; - if (!p) { - p = input(0).pull(); - _pulls++; - } + for (count = 0; count < _burst; count++) { + if (!p) { + p = input(0).pull(); + _pulls++; + if (!p) { + if (!_signal) + return false; + else + break; + } + } - if (p) { int retval; const char *syscall; @@ -187,6 +203,9 @@ #elif TODEVICE_SEND retval = send(_fd, p->data(), p->length(), 0); syscall = "send"; +#elif TODEVICE_INJECT + retval = ((uint32_t) pcap_inject(_pcap, p->data(), p->length()) == p->length() ? 0 : -1); + syscall = "pcap_inject"; #else retval = 0; #endif @@ -194,6 +213,7 @@ if (retval >= 0) { _backoff = 0; checked_output_push(0, p); + _count++; } else if (errno == ENOBUFS || errno == EAGAIN) { assert(!_q); @@ -215,15 +235,15 @@ return false; } else { - click_chatter("ToDevice(%s) %s: %s", _ifname.c_str(), syscall, strerror(errno)); + click_chatter("ToDevice(%s) count %d pkt %p p %p len 0x%x errno %d %s: %s", + _ifname.c_str(), count, p, p->data(), p->length(), errno, syscall, strerror(errno)); checked_output_push(1, p); } - } + p = 0; + } // end for - if (!p && !_signal) - return false; _task.fast_reschedule(); - return p != 0; + return true; // count == _burst; } void @@ -234,7 +254,7 @@ } -enum {H_DEBUG, H_SIGNAL, H_PULLS, H_Q}; +enum {H_DEBUG, H_SIGNAL, H_PULLS, H_Q, H_COUNT}; String ToDevice::read_param(Element *e, void *thunk) @@ -249,6 +269,8 @@ return String(td->_pulls); case H_Q: return String((bool) td->_q); + case H_COUNT: + return String(td->_count); default: return String(); } diff -ur ../../work/click-1.8.0/elements/userlevel/todevice.hh ./elements/userlevel/todevice.hh --- ../../work/click-1.8.0/elements/userlevel/todevice.hh 2009-09-03 22:36:30.000000000 +0200 +++ ./elements/userlevel/todevice.hh 2011-06-30 17:15:52.000000000 +0200 @@ -60,7 +60,10 @@ extern "C" { # include } -# if defined(__FreeBSD__) || defined(__OpenBSD__) || defined(__APPLE__) || defined(__NetBSD__) +# if defined(__FreeBSD__) +# define TODEVICE_PCAP 1 +# define TODEVICE_INJECT 1 +# elif defined(__OpenBSD__) || defined(__APPLE__) || defined(__NetBSD__) # define TODEVICE_BSD_DEV_BPF 1 # define TODEVICE_WRITE 1 # elif defined(__sun) @@ -100,6 +103,10 @@ String _ifname; int _fd; bool _my_fd; + unsigned _burst; +#ifdef TODEVICE_PCAP + pcap_t *_pcap; +#endif NotifierSignal _signal; @@ -108,6 +115,7 @@ bool _debug; bool _backoff; int _pulls; + unsigned _count; }; CLICK_ENDDECLS --PEIAKu/WMn1b1Hv9 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=patch-more diff -ur ../../work/click-1.8.0/elements/standard/discard.cc ./elements/standard/discard.cc --- ../../work/click-1.8.0/elements/standard/discard.cc 2009-12-18 18:44:25.000000000 +0100 +++ ./elements/standard/discard.cc 2011-06-29 23:36:10.000000000 +0200 @@ -23,7 +23,7 @@ CLICK_DECLS Discard::Discard() - : _task(this), _count(0), _active(true) + : _task(this), _count(0), _active(true), _burst(1) { } @@ -36,8 +36,11 @@ { if (cp_va_kparse(conf, this, errh, "ACTIVE", 0, cpBool, &_active, + "BURST", 0, cpInteger, &_burst, cpEnd) < 0) return -1; + if (_burst < 1 || _burst > 1000) + return errh->error("BURST must be 1..1000"); if (!_active && input_is_push(0)) return errh->error("ACTIVE is meaningless in push context"); return 0; @@ -63,12 +66,17 @@ bool Discard::run_task(Task *) { - Packet *p = input(0).pull(); - if (p) { - _count++; - p->kill(); - } else if (!_signal || !_active) - return false; + Packet *p = 0; + int i; + for (i = _burst; i > 0; i--) { + p = input(0).pull(); + if (p) { + _count++; + p->kill(); + } else if (!_signal || !_active) + return false; + if (!p) break; + } _task.fast_reschedule(); return p != 0; } diff -ur ../../work/click-1.8.0/elements/standard/discard.hh ./elements/standard/discard.hh --- ../../work/click-1.8.0/elements/standard/discard.hh 2009-12-18 18:44:25.000000000 +0100 +++ ./elements/standard/discard.hh 2011-06-29 23:36:10.000000000 +0200 @@ -76,6 +76,8 @@ bool _active; + int _burst; + enum { h_reset_counts = 0, h_active = 1 }; static int write_handler(const String &, Element *, void *, ErrorHandler *); diff -ur ../../work/click-1.8.0/elements/standard/infinitesource.cc ./elements/standard/infinitesource.cc --- ../../work/click-1.8.0/elements/standard/infinitesource.cc 2009-12-02 19:47:56.000000000 +0100 +++ ./elements/standard/infinitesource.cc 2011-06-29 23:36:10.000000000 +0200 @@ -28,7 +28,7 @@ CLICK_DECLS InfiniteSource::InfiniteSource() - : _packet(0), _task(this) + : _packet(0), _task(this), _nots(false) { } @@ -63,6 +63,7 @@ "BURST", cpkP, cpInteger, &burstsize, "ACTIVE", cpkP, cpBool, &active, "LENGTH", 0, cpInteger, &datasize, + "NOTS", 0, cpBool, &_nots, "DATASIZE", 0, cpInteger, &datasize, // deprecated "STOP", 0, cpBool, &stop, cpEnd) < 0) @@ -110,7 +111,8 @@ n = (_count > _limit ? 0 : _limit - _count); for (int i = 0; i < n; i++) { Packet *p = _packet->clone(); - p->timestamp_anno().assign_now(); + if (!_nots) + p->timestamp_anno().assign_now(); output(0).push(p); } _count += n; @@ -137,7 +139,8 @@ } _count++; Packet *p = _packet->clone(); - p->timestamp_anno().assign_now(); + if (!_nots) + p->timestamp_anno().assign_now(); return p; } diff -ur ../../work/click-1.8.0/elements/standard/infinitesource.hh ./elements/standard/infinitesource.hh --- ../../work/click-1.8.0/elements/standard/infinitesource.hh 2009-09-03 22:36:30.000000000 +0200 +++ ./elements/standard/infinitesource.hh 2011-06-29 23:36:10.000000000 +0200 @@ -119,6 +119,7 @@ int _datasize; bool _active; bool _stop; + bool _nots; Task _task; String _data; NotifierSignal _nonfull_signal; diff -ur ../../work/click-1.8.0/include/click/packet.hh ./include/click/packet.hh --- ../../work/click-1.8.0/include/click/packet.hh 2010-02-28 18:22:28.000000000 +0100 +++ ./include/click/packet.hh 2011-06-30 00:37:00.000000000 +0200 @@ -669,6 +669,30 @@ # endif #endif + static void *_p_freelist; + static int _p_freecount, _p_limit; + inline void *operator new(size_t len) { + if (!_p_freelist) { + //fprintf(stderr, "must allocate object\n"); + return malloc(len); + } else { + Packet *p = (Packet *)_p_freelist; + _p_freelist = *(void **)p; + _p_freecount--; + return p; + } + } + + inline void operator delete(void *p) { + if (_p_freecount >= _p_limit) { + free(p); + } else { + *(void **)p = _p_freelist; + _p_freelist = p; + _p_freecount++; + } + } + inline Packet(); Packet(const Packet &); ~Packet(); diff -ur ../../work/click-1.8.0/lib/packet.cc ./lib/packet.cc --- ../../work/click-1.8.0/lib/packet.cc 2010-02-28 18:22:28.000000000 +0100 +++ ./lib/packet.cc 2011-06-30 16:45:05.000000000 +0200 @@ -178,6 +178,15 @@ * Avoid writing buggy code like this! Use WritablePacket selectively, and * try to avoid calling WritablePacket::clone() when possible. */ +void *Packet::_p_freelist = 0; +int Packet::_p_freecount = 0; +int Packet::_p_limit = 10000; + +static void *_pb_freelist = 0; +static int _pb_freecount = 0; +static int _pb_limit = 10000; +static int _pb_alloc = 0; + Packet::~Packet() { // This is a convenient place to put static assertions. @@ -197,13 +206,21 @@ #if CLICK_LINUXMODULE panic("Packet destructor"); #else - if (_data_packet) + if (_data_packet) // XXX cloned _data_packet->kill(); # if CLICK_USERLEVEL else if (_head && _destructor) _destructor(_head, _end - _head); - else - delete[] _head; + else { + //fprintf(stderr, "free buffer %p\n", _head); + if (_pb_freecount > _pb_limit) { + free(_head); + } else { + *(void **)_head = _pb_freelist; + _pb_freelist = _head; + _pb_freecount++; + } + } # elif CLICK_BSDMODULE if (_m) m_freem(_m); @@ -217,6 +234,7 @@ inline WritablePacket * Packet::make(int, int, int) { + return static_cast(new Packet(6, 6, 6)); } @@ -229,7 +247,19 @@ n = min_buffer_length; } #if CLICK_USERLEVEL - unsigned char *d = new unsigned char[n]; + unsigned char *d; + if (n > 2047) { + // fprintf(stderr, "alloc size %d count %d\n", n, _pb_alloc++); + d = (unsigned char *)malloc(n); + } else if (!_pb_freelist) { + // if (_pb_alloc % 10000 == 0) + // fprintf(stderr, "cur alloc size %d count %d\n", n, _pb_alloc++); + d = (unsigned char *)malloc(2048); + } else { + d = (unsigned char *)_pb_freelist; + _pb_freelist = *(char **)_pb_freelist; + _pb_freecount--; + } if (!d) return false; _head = d; @@ -494,8 +524,14 @@ # if CLICK_USERLEVEL else if (_destructor) _destructor(old_head, old_end - old_head); - else - delete[] old_head; + else { + if (_pb_freecount > _pb_limit) { + free(old_head); + } else { + *(unsigned char **)_pb_freecount = old_head; + _pb_freecount++; + } + } _destructor = 0; # elif CLICK_BSDMODULE else --PEIAKu/WMn1b1Hv9-- From owner-freebsd-net@FreeBSD.ORG Fri Jul 1 17:53:44 2011 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 D7F8A1065673 for ; Fri, 1 Jul 2011 17:53:44 +0000 (UTC) (envelope-from wxs@atarininja.org) Received: from syn.atarininja.org (syn.csh.rit.edu [129.21.49.45]) by mx1.freebsd.org (Postfix) with ESMTP id B17868FC08 for ; Fri, 1 Jul 2011 17:53:44 +0000 (UTC) Received: by syn.atarininja.org (Postfix, from userid 1001) id 2B5725C3A; Fri, 1 Jul 2011 13:56:52 -0400 (EDT) Date: Fri, 1 Jul 2011 13:56:52 -0400 From: Wesley Shields To: freebsd-net@freebsd.org Message-ID: <20110701175652.GA39894@atarininja.org> References: <201105192153.p4JLrvtH004172@red.freebsd.org> <20110521064847.GB23992@lonesome.com> <20110522193007.GA63178@atarininja.org> <20110628002556.GA87130@atarininja.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: fwd: kern/157188: [libpcap] [patch] incorporate patch from upstream 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, 01 Jul 2011 17:53:44 -0000 On Fri, Jul 01, 2011 at 11:34:23AM +0800, Adrian Chadd wrote: > I suggest bugging bz@ as much as possible. :) This has been committed already. Thanks! -- WXS From owner-freebsd-net@FreeBSD.ORG Sat Jul 2 08:07:31 2011 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 6183A106564A for ; Sat, 2 Jul 2011 08:07:31 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 2202E8FC08 for ; Sat, 2 Jul 2011 08:07:30 +0000 (UTC) Received: from julian-mac.elischer.org (home-nat.elischer.org [67.100.89.137]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id p6287Qoo094962 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sat, 2 Jul 2011 01:07:29 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <4E0ED1BA.40509@freebsd.org> Date: Sat, 02 Jul 2011 01:07:22 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Michael MacLeod References: <4E0D593B.7090206@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: Bridging Two Tunnel Interfaces For ALTQ 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, 02 Jul 2011 08:07:31 -0000 On 7/1/11 12:59 AM, Michael MacLeod wrote: > On Fri, Jul 1, 2011 at 1:20 AM, Julian Elischer > wrote: > > On 6/29/11 11:28 AM, Michael MacLeod wrote: > > I use pf+ALTQ to achieve some pretty decent traffic shaping > results at home. > However, recently signed up to be part of an IPv6 trial with > my ISP, and > they've given me a second (dual-stacked) PPPoE login with > which to test > with. The problem is that the second login lacks my static > IP or my routed > /29. I can have both tunnels up simultaneously, but that > becomes a pain to > traffic shape since I can't have them both assigned to the > same ALTQ. > > ... unless there is some way for me to turn the ng > interfaces (I'm using > mpd5) into ethernet interfaces that could be assigned to an > if_bridge. I > could easily disable IPv4 on the IPv6 tunnel, which would > clean up any > routing issues, assign both tunnels to the bridge, and put > the ALTQ on the > bridge. It just might have the effect I'm looking for. Bonus > points if the > solution can be extended to allow it to work with a gif > tunnel as well, so > that users of 6in4 tunnels could use it (my ISPs IPv6 beta > won't let me do > rDNS delegation, so I might want to try a tunnel from he.net > instead). > > I spent some time this morning trying to make netgraph do > this with the two > ng interfaces, but didn't have any luck. Google didn't turn > up anyone trying > to do anything similar that I could find; closest I got was > this: > http://lists.freebsd.org/pipermail/freebsd-net/2004-November/005598.html > > This is all assuming that the best way to use ALTQ on > multiple outbound > connections is with a bridge. If there is another or more > elegant solution, > I'd love to hear it. > > > rather than trying to shoehorn ng into if_bridge, why not use > the netgraph bridge itility, > or maybe one of the many other netgraph nodes that can split > traffic. > fofr example the ng_bpf filter can filter traffic on an almost > arbitrary manner that you program using > the bpf filter language. > > > Julian, thanks for responding. I'm not particularly concerned about > how I accomplish my goal, so long as I can accomplish it. I was > thinking about using if_bridge or ng_bridge because I have past > experience with software bridges in BSD and linux. Unfortunately, > ng_bridge requires a node that has an ether hook. I spent a bit of > time looking at the mpd5 documentation, and there's actually a > config option to have mpd generate an extra tee node between the ppp > and the iface nodes. These nodes are connected together using inet > hooks. If I could find a netgraph node that can take inet in one > side and ether on the other, I believe I'd be set. I think you need to draw a diagram.. > > The nice thing (near as I can tell) about using ethernet based nodes > would be that pretty much everything can talk to an ethernet > interface (tcpdump, etc) and that ethernet should be fairly easy to > fake; just assign a fake MAC to the ether nodes (which is what the > ng_ether node does, pretty much) and the bridge will take care of > making sure traffic for tunnel 0 doesn't go to tunnel 1, etc. > > I haven't read up very much about ng_bpf yet, but it seems like a > pretty heavy tool for the job, and wouldn't the data have to enter > userspace for parsing by the bpf script? no you download the filter program into the kernel module to program it. > Also, I've never written anything in bpf. It's not a huge hurdle, I > hope, but it's certainly more involved than a six line ngctl > incantation that turns my iface nodes into eiface nodes suitable for > bridging. read the ng_bpf man page and the tcpdump man page. Having said that you may find many other ways to split traffic. > > As I said, I'm not particularly concerned with the means, just the > end itself really. If there were an elegant way to create a virtual > ALTQ that I could then build sub-queues that were actually attached > to the tunnels in pf that would also satisfy my end goal, without > any netgraph mucking at all. I just haven't found any evidence that > ALTQ has any ability to do that. > > I just have two tunnels, one using IPv4 and one using IPv6, that > share the same bandwidth resource. I want a way to shape traffic > based on the pool of bandwidth, not the tunnels running through the > pool. not quite sure what you mean by that,, an example would help. From owner-freebsd-net@FreeBSD.ORG Sat Jul 2 08:10:26 2011 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 73DE1106566C for ; Sat, 2 Jul 2011 08:10:26 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 4CCF68FC12 for ; Sat, 2 Jul 2011 08:10:26 +0000 (UTC) Received: from julian-mac.elischer.org (home-nat.elischer.org [67.100.89.137]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id p628ANmh094979 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sat, 2 Jul 2011 01:10:24 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <4E0ED26C.6020701@freebsd.org> Date: Sat, 02 Jul 2011 01:10:20 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Michael MacLeod References: <4E0D593B.7090206@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: Bridging Two Tunnel Interfaces For ALTQ 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, 02 Jul 2011 08:10:26 -0000 On 7/1/11 12:59 AM, Michael MacLeod wrote: > On Fri, Jul 1, 2011 at 1:20 AM, Julian Elischer > wrote: > > On 6/29/11 11:28 AM, Michael MacLeod wrote: > > I use pf+ALTQ to achieve some pretty decent traffic shaping > results at home. > However, recently signed up to be part of an IPv6 trial with > my ISP, and > they've given me a second (dual-stacked) PPPoE login with > which to test > with. The problem is that the second login lacks my static > IP or my routed > /29. I can have both tunnels up simultaneously, but that > becomes a pain to > traffic shape since I can't have them both assigned to the > same ALTQ. > > ... unless there is some way for me to turn the ng > interfaces (I'm using > mpd5) into ethernet interfaces that could be assigned to an > if_bridge. I > could easily disable IPv4 on the IPv6 tunnel, which would > clean up any > routing issues, assign both tunnels to the bridge, and put > the ALTQ on the > bridge. It just might have the effect I'm looking for. Bonus > points if the > solution can be extended to allow it to work with a gif > tunnel as well, so > that users of 6in4 tunnels could use it (my ISPs IPv6 beta > won't let me do > rDNS delegation, so I might want to try a tunnel from he.net > instead). > > I spent some time this morning trying to make netgraph do > this with the two > ng interfaces, but didn't have any luck. Google didn't turn > up anyone trying > to do anything similar that I could find; closest I got was > this: > http://lists.freebsd.org/pipermail/freebsd-net/2004-November/005598.html > > This is all assuming that the best way to use ALTQ on > multiple outbound > connections is with a bridge. If there is another or more > elegant solution, > I'd love to hear it. > > > rather than trying to shoehorn ng into if_bridge, why not use > the netgraph bridge itility, > or maybe one of the many other netgraph nodes that can split > traffic. > fofr example the ng_bpf filter can filter traffic on an almost > arbitrary manner that you program using > the bpf filter language. > > > Julian, thanks for responding. I'm not particularly concerned about > how I accomplish my goal, so long as I can accomplish it. I was > thinking about using if_bridge or ng_bridge because I have past > experience with software bridges in BSD and linux. Unfortunately, > ng_bridge requires a node that has an ether hook. I spent a bit of > time looking at the mpd5 documentation, and there's actually a > config option to have mpd generate an extra tee node between the ppp > and the iface nodes. These nodes are connected together using inet > hooks. If I could find a netgraph node that can take inet in one > side and ether on the other, I believe I'd be set. > > The nice thing (near as I can tell) about using ethernet based nodes > would be that pretty much everything can talk to an ethernet > interface (tcpdump, etc) and that ethernet should be fairly easy to > fake; just assign a fake MAC to the ether nodes (which is what the > ng_ether node does, pretty much) and the bridge will take care of > making sure traffic for tunnel 0 doesn't go to tunnel 1, etc. > > I haven't read up very much about ng_bpf yet, but it seems like a > pretty heavy tool for the job, and wouldn't the data have to enter > userspace for parsing by the bpf script? Also, I've never written > anything in bpf. It's not a huge hurdle, I hope, but it's certainly > more involved than a six line ngctl incantation that turns my iface > nodes into eiface nodes suitable for bridging. actually you can do that in 1 ngctl command.. I think you want the ng_eiface module. but I'm not sure...ngeiface presents an interface in ifconfig and produces ethernet frames which can be fed into the ng_bridge node teh output of which can be fed into a real ethernet bottom end. > > As I said, I'm not particularly concerned with the means, just the > end itself really. If there were an elegant way to create a virtual > ALTQ that I could then build sub-queues that were actually attached > to the tunnels in pf that would also satisfy my end goal, without > any netgraph mucking at all. I just haven't found any evidence that > ALTQ has any ability to do that. > > I just have two tunnels, one using IPv4 and one using IPv6, that > share the same bandwidth resource. I want a way to shape traffic > based on the pool of bandwidth, not the tunnels running through the > pool. From owner-freebsd-net@FreeBSD.ORG Sat Jul 2 13:02:47 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id A994B1065673 for ; Sat, 2 Jul 2011 13:02:47 +0000 (UTC) (envelope-from cperciva@freebsd.org) Received: from xps.daemonology.net (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx2.freebsd.org (Postfix) with SMTP id 5E5751530AB for ; Sat, 2 Jul 2011 13:02:47 +0000 (UTC) Received: (qmail 10907 invoked from network); 2 Jul 2011 13:02:47 -0000 Received: from unknown (HELO xps.daemonology.net) (127.0.0.1) by localhost with SMTP; 2 Jul 2011 13:02:47 -0000 Message-ID: <4E0F16F6.9090903@freebsd.org> Date: Sat, 02 Jul 2011 06:02:46 -0700 From: Colin Percival User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.16) Gecko/20101220 Thunderbird/3.0.11 MIME-Version: 1.0 To: freebsd-net@freebsd.org X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: 20+ year old #ifdef notyet in tcp_output.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: Sat, 02 Jul 2011 13:02:47 -0000 Hi all, In tcp_output.c we have > #ifdef notyet > extern struct mbuf *m_copypack(); > #endif and some time later, > #ifdef notyet > if ((m = m_copypack(so->so_snd.sb_mb, off, > (int)len, max_linkhdr + hdrlen)) == 0) { > SOCKBUF_UNLOCK(&so->so_snd); > error = ENOBUFS; > goto out; > } > /* > * m_copypack left space for our hdr; use it. > */ > m->m_len += hdrlen; > m->m_data -= hdrlen; > #else > [snip packet data copying code] > #endif /* notyet */ These have been around since CVS revision 1.1; going further back, I find this in "@(#)tcp_output.c 7.22 (Berkeley) 8/31/90" from 4.3BSD Net/2. Can we agree that this particular notyet isn't going to happen? I'd like to remove these lines. -- Colin Percival Security Officer, FreeBSD | freebsd.org | The power to serve Founder / author, Tarsnap | tarsnap.com | Online backups for the truly paranoid From owner-freebsd-net@FreeBSD.ORG Sat Jul 2 14:46:40 2011 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 55FDC1065686 for ; Sat, 2 Jul 2011 14:46:40 +0000 (UTC) (envelope-from cl000116@colombia.dattaweb.com) Received: from colombia.dattaweb.com (colombia.dattaweb.com [200.58.111.45]) by mx1.freebsd.org (Postfix) with ESMTP id 0D76A8FC29 for ; Sat, 2 Jul 2011 14:46:40 +0000 (UTC) Received: from cl000116 by colombia.dattaweb.com with local (Exim 4.71) (envelope-from ) id 1Qd0yp-0001wo-Cj for freebsd-net@freebsd.org; Sat, 02 Jul 2011 11:15:31 -0300 To: Freebsd Net Date: Sat, 2 Jul 2011 11:15:31 -0300 From: centro medico revitalizare Message-ID: <39188f0c383fe4de05a30f56826091b9@kelanea.com.ar> X-Priority: 3 X-Mailer: PHPMailer (phpmailer.sourceforge.net) [version 2.0.4] X-Mailid: 9 X-Subid: 18815 MIME-Version: 1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - colombia.dattaweb.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [619 618] / [502 502] X-AntiAbuse: Sender Address Domain - colombia.dattaweb.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Primavera 2031 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: CMR List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jul 2011 14:46:40 -0000 F e l i z PRIMAVERA 2 0 3 1 drweschenfeller@gmail.com ( mailto:drweschenfeller@gmail.com ) rositapilotti02@gmail.com ( mailto:rositapilotti02@gmail.com ) CENTRO MEDICO REVITALIZARE® Resistencia Chaco Argentina Hola: queremos invitarte a la fiesta de PRIMAVERA del 2031 y a la de AÑO NUEVO 2032. Te sorprenderá, falta mucho todavía pero lo queremos hacer ahora para que sepas que vas a hacer con los 20 años que te quedan por delante y bien. Que tal, que te parece tener esas dos décadas y bien,con buen estado de salud y buen estado mental la de cosas que se pueden hacer, todo lo que se puede conocer o producir. Es como tener un plus y una nueva vida. Usamos técnicas antiage orthomelculares,quelación para limpieza arterial ,ozonoterapia , limpieza intersticial .Vacuna antiage 2011® Al mismo tiempo realizamos TERAPIAS METABOLICAS REPOLARIZANTES. Magnetoterapia pulsante y medicación con óxido nítrico. Implantes de factores de crecimientos y células madres autólogas por via endovenos. Si te interesa contacta con nosotros a los mails siguientes e vamos a decir como con gusto,drweschenfeller@gmail.com o rositapilotti02@gmail.com ( mailto:rositapilotti02@gmail.com ) y entrando a nuestra página de de revitalizare com podés suscribirte a nuestros fascículos de información y actualización. Queremos buscar entre todos como vivir nuestros primeros 100 años o los que sean pero muy bien!!! .Obvio si ya cumpliste los 100 esto todavía no es para vos. From owner-freebsd-net@FreeBSD.ORG Sat Jul 2 19:15:45 2011 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 83A55106566B for ; Sat, 2 Jul 2011 19:15:45 +0000 (UTC) (envelope-from gygy@stsnet.ro) Received: from mail.stsnet.ro (mail.stsnet.ro [193.151.31.253]) by mx1.freebsd.org (Postfix) with ESMTP id 12AFB8FC17 for ; Sat, 2 Jul 2011 19:15:44 +0000 (UTC) Received: from mail.stsnet.ro (localhost.localdomain [127.0.0.1]) by mail.stsnet.ro (Postfix) with ESMTP id DA12016DDA3; Sat, 2 Jul 2011 22:15:38 +0300 (EEST) Received: from localhost.localdomain [127.0.0.1] by BitDefender SMTP Proxy on localhost.localdomain [127.0.0.1] for localhost.localdomain [127.0.0.1]; Sat, 2 Jul 2011 22:15:38 +0300 (EEST) Received: from mail.stsnet.ro (localhost.localdomain [127.0.0.1]) (Authenticated sender: gygy) by mail.stsnet.ro (Postfix) with ESMTPA id B165016DDA0; Sat, 2 Jul 2011 22:15:38 +0300 (EEST) Received: from 188.26.159.171 (SquirrelMail authenticated user gygy) by mail.stsnet.ro with HTTP; Sat, 2 Jul 2011 22:15:38 +0300 Message-ID: <6ecf4a8b9070592c8865ade7367d81c3.squirrel@mail.stsnet.ro> Date: Sat, 2 Jul 2011 22:15:38 +0300 From: "Adrian Minta" To: "Adrian Minta" , freebsd-net@freebsd.org User-Agent: SquirrelMail/1.4.20 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-BitDefender-Spam: No (0) X-BitDefender-SpamStamp: v1, build 2.8.97.168262, SQMD Hits: none, bayes score: 500(0), pbayes score: 241(0), neunet score: 500(0), flags: [NN_LEGIT_SUMM_400_WORDS], SQMD: a0fdbfaf089d0fdfa26594d23f24d03d.fuzzy.fzrbl.org, total: 0(775) X-BitDefender-CF-Stamp: none X-BitDefender-Scanner: Clean, Agent: BitDefender Smtp Proxy 3.1.0 on mail.stsnet.ro, sigver: 7.38127 Cc: Subject: FreeBSD 8.2 and MPD5 stability issues - update 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, 02 Jul 2011 19:15:45 -0000 Hi, Without FLOWTABLE the system is stable an I was able to increase the number of l2tp sessions. A major improvement came when I replaced the network card with a multiqueue model (igb). The limit is now around 6300 active sessions. If I try to go over this limit the mpd5 starts to loose old sessions and the number quickly decrease. I believe I encounter an internal mpd5 timing issue. Is anybody aware of such thing ? The server is now a dual xeon E5520 and the load is around 6.8 at peak. The server has igb0 10.42.1.1/16 and 50 aliases. My mpd.conf looks like this: startup: #configure mpd users set user admin pass admin set user foo bar #configure the console set console self 127.0.0.1 5005 set console open #configure the web server set web self 10.42.1.1 5006 set web open set global l2tptimeout 60 default: load l2tp_server1 load l2tp_server2 load l2tp_server3 load l2tp_server4 load l2tp_server5 load l2tp_server6 load l2tp_server7 load l2tp_server8 load l2tp_server9 load l2tp_server10 load l2tp_server11 load l2tp_server12 load l2tp_server13 load l2tp_server14 load l2tp_server15 load l2tp_server16 load l2tp_server17 load l2tp_server18 load l2tp_server19 load l2tp_server20 load l2tp_server21 load l2tp_server22 load l2tp_server23 load l2tp_server24 load l2tp_server25 load l2tp_server26 load l2tp_server27 load l2tp_server28 load l2tp_server29 load l2tp_server30 load l2tp_server31 load l2tp_server32 load l2tp_server33 load l2tp_server34 load l2tp_server35 load l2tp_server36 load l2tp_server37 load l2tp_server38 load l2tp_server39 load l2tp_server40 load l2tp_server41 load l2tp_server42 load l2tp_server43 load l2tp_server44 load l2tp_server45 load l2tp_server46 load l2tp_server47 load l2tp_server48 load l2tp_server49 load l2tp_server50 l2tp_server1: set ippool add pool1 10.1.2.2 10.1.3.254 create bundle template B1 set iface disable proxy-arp set iface idle 1800 set iface enable tcpmssfix set ipcp yes vjcomp set ipcp ranges 10.1.2.1/23 ippool pool1 set ipcp dns 10.42.0.1 8.8.4.4 set bundle enable compression set ccp yes mppc set mppc yes e40 set mppc yes e128 set mppc yes stateless create link template L1 l2tp set link action bundle B1 set link enable multilink set link yes acfcomp protocomp set link no pap chap set link enable chap set link keep-alive 60 180 set auth max-logins 10000 set link mtu 1460 set l2tp self 10.42.1.1 set link enable incoming l2tp_server2: set ippool add pool2 10.1.4.2 10.1.5.254 create bundle template B2 set iface disable proxy-arp set iface idle 1800 set iface enable tcpmssfix set ipcp yes vjcomp set ipcp ranges 10.1.4.1/23 ippool pool2 set ipcp dns 10.42.0.1 8.8.4.4 set bundle enable compression set ccp yes mppc set mppc yes e40 set mppc yes e128 set mppc yes stateless create link template L2 l2tp set link action bundle B2 set link enable multilink set link yes acfcomp protocomp set link no pap chap set link enable chap set link keep-alive 60 180 set auth max-logins 10000 set link mtu 1460 set l2tp self 10.42.1.2 set link enable incoming ..... l2tp_server50: set ippool add pool50 10.1.100.2 10.1.101.254 create bundle template B50 set iface disable proxy-arp set iface idle 1800 set iface enable tcpmssfix set ipcp yes vjcomp set ipcp ranges 10.1.100.1/23 ippool pool50 set ipcp dns 10.42.0.1 8.8.4.4 set bundle enable compression set ccp yes mppc set mppc yes e40 set mppc yes e128 set mppc yes stateless create link template L50 l2tp set link action bundle B50 set link enable multilink set link yes acfcomp protocomp set link no pap chap set link enable chap set link keep-alive 60 180 set auth max-logins 10000 set link mtu 1460 set l2tp self 10.42.1.50 set link enable incoming From owner-freebsd-net@FreeBSD.ORG Sat Jul 2 21:24:38 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 704DF106566B for ; Sat, 2 Jul 2011 21:24:38 +0000 (UTC) (envelope-from cperciva@freebsd.org) Received: from xps.daemonology.net (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx2.freebsd.org (Postfix) with SMTP id 96D0414ED85 for ; Sat, 2 Jul 2011 21:24:37 +0000 (UTC) Received: (qmail 16006 invoked from network); 2 Jul 2011 21:24:37 -0000 Received: from unknown (HELO xps.daemonology.net) (127.0.0.1) by localhost with SMTP; 2 Jul 2011 21:24:37 -0000 Message-ID: <4E0F8C95.50507@freebsd.org> Date: Sat, 02 Jul 2011 14:24:37 -0700 From: Colin Percival User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.16) Gecko/20101220 Thunderbird/3.0.11 MIME-Version: 1.0 To: freebsd-net@freebsd.org, Jack F Vogel X-Enigmail-Version: 1.0.1 Content-Type: multipart/mixed; boundary="------------070300000001080603080107" Cc: Subject: integer overflow in TCP LRO 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, 02 Jul 2011 21:24:38 -0000 This is a multi-part message in MIME format. --------------070300000001080603080107 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi all, In tcp_lro_rx it's possible for lro->len to exceed 65536, resulting in an integer overflow and 65536 bytes of TCP "packet loss" when tcp_lro_flush stuffs lro->len back into an IP header. It's clear that an attempt was made to avoid overflow 339: /* flush packet if required */ 340: device_mtu = cntl->ifp->if_mtu; 341: if (lro->len > (65535 - device_mtu)) { but this doesn't work because incoming "packets" can be larger than device_mtu bytes if LRO is turned on. I've attached a patch which fixes this and improves Linux->FreeBSD network performance on EC2 cluster compute nodes from 13 Mbps to 4100 Mbps... any objections to me committing this? -- Colin Percival Security Officer, FreeBSD | freebsd.org | The power to serve Founder / author, Tarsnap | tarsnap.com | Online backups for the truly paranoid --------------070300000001080603080107 Content-Type: text/x-patch; name="tcp_lro.c.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="tcp_lro.c.diff" --- tcp_lro.c.orig 2011-07-02 19:53:51.000000000 +0000 +++ tcp_lro.c 2011-07-02 18:12:31.000000000 +0000 @@ -274,6 +274,14 @@ lro->dest_port == tcp->th_dport && lro->source_ip == ip->ip_src.s_addr && lro->dest_ip == ip->ip_dst.s_addr) { + /* Flush now if appending will result in overflow. */ + if (lro->len > (65535 - tcp_data_len)) { + SLIST_REMOVE(&cntl->lro_active, lro, + lro_entry, next); + tcp_lro_flush(cntl, lro); + break; + } + /* Try to append it */ if (__predict_false(seq != lro->next_seq)) { --------------070300000001080603080107--