From owner-freebsd-net@FreeBSD.ORG Sun Apr 29 13:06:59 2012 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 59CD2106566B for ; Sun, 29 Apr 2012 13:06:59 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id E78ED8FC0C for ; Sun, 29 Apr 2012 13:06:58 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (89.112.15.178.pppoe.eltel.net [89.112.15.178]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id EDDFE4AC2D for ; Sun, 29 Apr 2012 17:06:57 +0400 (MSK) Date: Sun, 29 Apr 2012 17:06:56 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <1606941405.20120429170656@serebryakov.spb.ru> To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Hetzner.de IPv6 and FreeBSD -- default gateway is on other prefix, need to add static route before default -- how? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Apr 2012 13:06:59 -0000 Hello, Freebsd-net. "Famous" dedicated server provider Hetzner provides native IPv6 for servers, but with rather strange routing configuration: you need to configure static interface route and make this route default. If I add such lines in /etc/rc.conf: ifconfig_re0_ipv6="inet6 2a01:4f8:131:60a2::2 prefixlen 64 auto_linklocal accept_rtadv" ipv6_static_routes="ipv6defgw" ipv6_route_ipv6defgw="2a01:4f8:131:60a0:: -prefixlen 59 -iface re0" ipv6_defaultrouter="2a01:4f8:131:60a0::1" ipv6_default_interface="re0" It doesn't work, because default route added first and it fails to be added, as route to 2a01:4f8:131:60a0::1 is not known yet. If I replace this line in /etc/rc.d/routing: ipv6_static_routes="default ${ipv6_static_routes}" with ipv6_static_routes="${ipv6_static_routes} default" Everything works, but it is ugly hack -- to change system startup script, and I don't like it (for FreeBSD 8 I needed to change /etc/network.subr in similar way). Is here any good way to configure such routing without changes in scripts, only with /etc/rc.conf? -- // Black Lion AKA Lev Serebryakov From owner-freebsd-net@FreeBSD.ORG Sun Apr 29 14:36:01 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D01FB106566B for ; Sun, 29 Apr 2012 14:36:01 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [46.4.40.135]) by mx1.freebsd.org (Postfix) with ESMTP id 8F4C78FC08 for ; Sun, 29 Apr 2012 14:36:01 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (89.112.15.178.pppoe.eltel.net [89.112.15.178]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 941EC4AC2D for ; Sun, 29 Apr 2012 18:36:00 +0400 (MSK) Date: Sun, 29 Apr 2012 18:35:59 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <75233009.20120429183559@serebryakov.spb.ru> To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: IPv6 MTU discrovery -- how should it work? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Apr 2012 14:36:01 -0000 Hello, Freebsd-net. My home network is connected to IPv6 world with Hurricane Electric's tunnel (IPv6 over IPv6, "gif"). It has MTU 1280. Everything works till packets are small -- for example, interactive shell (ssh) session over IPv6 works great. But when I need to transfer buil of bytes from server to local network (scp, or even fast scrolling of man page in interactive session) traffic hangs. It starts to work after couple (5-10) minutes, but many applications has timeouts less, that that, and it is very annoying in any case. When I connect to external server twice, and run tcpdump in one session for another one, and then try to use second (sniffed) session for bulk transfer, I can clearly see, that server tries to send IPv6 packets with size 1420 to my local network many times and doesn't get any answer, so it is MTU problem for sure, but how it could be fixed? Also, Youtube doesn't work over IPv6 with same symptoms, so it is not only my servers' problem, it looks like my local network (and tunnel) problem. How should it work? Maybe, I'm filtering out something mandatory on firewall? -- // Black Lion AKA Lev Serebryakov From owner-freebsd-net@FreeBSD.ORG Sun Apr 29 14:47:54 2012 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 662BB1065678 for ; Sun, 29 Apr 2012 14:47:54 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 2377B8FC19 for ; Sun, 29 Apr 2012 14:47:54 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (89.112.15.178.pppoe.eltel.net [89.112.15.178]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 6C5C44AC32 for ; Sun, 29 Apr 2012 18:47:53 +0400 (MSK) Date: Sun, 29 Apr 2012 18:47:52 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <1311430753.20120429184752@serebryakov.spb.ru> To: freebsd-net@freebsd.org In-Reply-To: <75233009.20120429183559@serebryakov.spb.ru> References: <75233009.20120429183559@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: IPv6 MTU discrovery -- how should it work? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Apr 2012 14:47:54 -0000 Hello, Lev. You wrote 29 =D0=B0=D0=BF=D1=80=D0=B5=D0=BB=D1=8F 2012 =D0=B3., 18:35:59: LS> When I connect to external server twice, and run tcpdump in one LS> session for another one, and then try to use second (sniffed) session LS> for bulk transfer, I can clearly see, that server tries to send IPv6 LS> packets with size 1420 to my local network many times and doesn't LS> get any answer, so it is MTU problem for sure, but how it could be fixe= d? But server# ping6 -D -s 1420 Works! I don't understand, what happens here :( --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-net@FreeBSD.ORG Sun Apr 29 16:02:51 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1DA2A10657A5 for ; Sun, 29 Apr 2012 16:02:51 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [46.4.40.135]) by mx1.freebsd.org (Postfix) with ESMTP id CE6928FC0A for ; Sun, 29 Apr 2012 16:02:50 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (89.112.15.178.pppoe.eltel.net [89.112.15.178]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id E13B14AC32 for ; Sun, 29 Apr 2012 20:02:49 +0400 (MSK) Date: Sun, 29 Apr 2012 20:02:48 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <1561150913.20120429200248@serebryakov.spb.ru> To: freebsd-net@freebsd.org In-Reply-To: <1311430753.20120429184752@serebryakov.spb.ru> References: <75233009.20120429183559@serebryakov.spb.ru> <1311430753.20120429184752@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: IPv6 MTU discrovery -- how should it work? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Apr 2012 16:02:51 -0000 Hello, Lev. You wrote 29 =D0=B0=D0=BF=D1=80=D0=B5=D0=BB=D1=8F 2012 =D0=B3., 18:47:52: LS>> When I connect to external server twice, and run tcpdump in one LS>> session for another one, and then try to use second (sniffed) session LS>> for bulk transfer, I can clearly see, that server tries to send IPv6 LS>> packets with size 1420 to my local network many times and doesn't LS>> get any answer, so it is MTU problem for sure, but how it could be fix= ed? And I can not set mtu less than 1280 on gif0, and my IPv4 interface only have 1460, as it is PPPoE interface. Maybe, problem is here, as MTU 1280 assumes outer MTU is 1500? --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-net@FreeBSD.ORG Sun Apr 29 16:09:05 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 44AAF1065674; Sun, 29 Apr 2012 16:09:05 +0000 (UTC) (envelope-from remko@elvandar.org) Received: from mailout.jr-hosting.nl (mailout.jr-hosting.nl [78.47.69.236]) by mx1.freebsd.org (Postfix) with ESMTP id F37908FC16; Sun, 29 Apr 2012 16:09:04 +0000 (UTC) Received: from mail.jr-hosting.nl (mail.jr-hosting.nl [IPv6:2a01:4f8:141:5ffd::25]) by mailout.jr-hosting.nl (Postfix) with ESMTP id 202AA390267D; Sun, 29 Apr 2012 18:09:04 +0200 (CEST) Received: from [10.0.2.10] (a44084.upc-a.chello.nl [62.163.44.84]) by mail.jr-hosting.nl (Postfix) with ESMTPSA id D7BCC38B1945; Sun, 29 Apr 2012 18:09:03 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Remko Lodder X-Priority: 3 (Normal) In-Reply-To: <1606941405.20120429170656@serebryakov.spb.ru> Date: Sun, 29 Apr 2012 18:09:02 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <371FBC4E-E124-47E8-AE45-E20FB076C4AF@elvandar.org> References: <1606941405.20120429170656@serebryakov.spb.ru> To: lev@FreeBSD.org X-Mailer: Apple Mail (2.1257) Cc: freebsd-net@freebsd.org Subject: Re: Hetzner.de IPv6 and FreeBSD -- default gateway is on other prefix, need to add static route before default -- how? 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, 29 Apr 2012 16:09:05 -0000 > Hello, Freebsd-net. >=20 > "Famous" dedicated server provider Hetzner provides native IPv6 for > servers, but with rather strange routing configuration: you need to > configure static interface route and make this route default. >=20 Hi Lev, I have the same "problem". I made an additional static route which does = the same ;-) But it might be even better if all FreeBSD users that have this problem = ask Hetzner to change this. I know that at least Bjoern (bz) tried this. The way = they do this is very ugly and doesn't warrant a price (in this regard). Cheers Remko --=20 /"\ With kind regards, | remko@elvandar.org \ / Remko Lodder | remko@FreeBSD.org X FreeBSD | = http://www.evilcoder.org / \ The Power to Serve | Quis custodiet ipsos custodes From owner-freebsd-net@FreeBSD.ORG Sun Apr 29 16:17:52 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8A5691065673; Sun, 29 Apr 2012 16:17:52 +0000 (UTC) (envelope-from seth.mos@dds.nl) Received: from rotring.dds.nl (rotring.dds.nl [85.17.178.138]) by mx1.freebsd.org (Postfix) with ESMTP id 46A4D8FC08; Sun, 29 Apr 2012 16:17:52 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by rotring.dds.nl (Postfix) with ESMTP id 3B75258D44; Sun, 29 Apr 2012 18:17:51 +0200 (CEST) Received: from localhost (unknown [91.93.32.67]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by rotring.dds.nl (Postfix) with ESMTPSA id 6511C58B84; Sun, 29 Apr 2012 18:17:46 +0200 (CEST) Date: Sun, 29 Apr 2012 19:17:41 +0300 Message-ID: From: Seth Mos To: lev@FreeBSD.org, freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 X-Virus-Scanned: clamav-milter 0.97.3 at rotring X-Virus-Status: Clean Cc: Subject: Re: Hetzner.de IPv6 and FreeBSD -- default gateway is on other prefix, need to add static route before default -- how? 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, 29 Apr 2012 16:17:52 -0000 VXNlIHRoZSBsaW5rIGxvY2FsIGFkZHJlZXMgb2YgdGhlIGdhdGV3YXkuIFRoYXQgc2hvdWxkIGp1 c3Qgd29yay4KCkNoZWVycywKU2V0aAoKdHlwZWQgb24gYSB0aW55IHRvdWNoc2NyZWVuLCB3aHkg ZXhhY3RseT8KCkxldiBTZXJlYnJ5YWtvdiA8bGV2QEZyZWVCU0Qub3JnPnNjaHJlZWY6Cgo+SGVs bG8sIEZyZWVic2QtbmV0Lgo+Cj4gIkZhbW91cyIgZGVkaWNhdGVkIHNlcnZlciBwcm92aWRlciBI ZXR6bmVyIHByb3ZpZGVzIG5hdGl2ZSBJUHY2IGZvcgo+c2VydmVycywgYnV0IHdpdGggcmF0aGVy IHN0cmFuZ2Ugcm91dGluZyBjb25maWd1cmF0aW9uOiB5b3UgbmVlZCB0bwo+Y29uZmlndXJlIHN0 YXRpYyBpbnRlcmZhY2Ugcm91dGUgYW5kIG1ha2UgdGhpcyByb3V0ZSBkZWZhdWx0Lgo+Cj4gSWYg SSBhZGQgc3VjaCBsaW5lcyBpbiAvZXRjL3JjLmNvbmY6Cj4KPmlmY29uZmlnX3JlMF9pcHY2PSJp bmV0NiAyYTAxOjRmODoxMzE6NjBhMjo6MiBwcmVmaXhsZW4gNjQgYXV0b19saW5rbG9jYWwgYWNj ZXB0X3J0YWR2Igo+aXB2Nl9zdGF0aWNfcm91dGVzPSJpcHY2ZGVmZ3ciCj5pcHY2X3JvdXRlX2lw djZkZWZndz0iMmEwMTo0Zjg6MTMxOjYwYTA6OiAtcHJlZml4bGVuIDU5IC1pZmFjZSByZTAiCj5p cHY2X2RlZmF1bHRyb3V0ZXI9IjJhMDE6NGY4OjEzMTo2MGEwOjoxIgo+aXB2Nl9kZWZhdWx0X2lu dGVyZmFjZT0icmUwIgo+Cj4gIEl0IGRvZXNuJ3Qgd29yaywgYmVjYXVzZSBkZWZhdWx0IHJvdXRl IGFkZGVkIGZpcnN0IGFuZCBpdCBmYWlscyB0bwo+YmUgYWRkZWQsIGFzIHJvdXRlIHRvIDJhMDE6 NGY4OjEzMTo2MGEwOjoxIGlzIG5vdCBrbm93biB5ZXQuCj4KPiAgSWYgSSByZXBsYWNlIHRoaXMg bGluZSBpbiAvZXRjL3JjLmQvcm91dGluZzoKPgo+aXB2Nl9zdGF0aWNfcm91dGVzPSJkZWZhdWx0 ICR7aXB2Nl9zdGF0aWNfcm91dGVzfSIKPgo+ICB3aXRoCj4KPmlwdjZfc3RhdGljX3JvdXRlcz0i JHtpcHY2X3N0YXRpY19yb3V0ZXN9IGRlZmF1bHQiCj4KPiAgRXZlcnl0aGluZyB3b3JrcywgYnV0 IGl0IGlzIHVnbHkgaGFjayAtLSB0byBjaGFuZ2Ugc3lzdGVtIHN0YXJ0dXAKPnNjcmlwdCwgYW5k IEkgZG9uJ3QgbGlrZSBpdCAoZm9yIEZyZWVCU0QgOCBJIG5lZWRlZCB0byBjaGFuZ2UKPi9ldGMv bmV0d29yay5zdWJyIGluIHNpbWlsYXIgd2F5KS4KPgo+ICBJcyBoZXJlIGFueSBnb29kIHdheSB0 byBjb25maWd1cmUgc3VjaCByb3V0aW5nIHdpdGhvdXQgY2hhbmdlcyBpbgo+c2NyaXB0cywgb25s eSB3aXRoIC9ldGMvcmMuY29uZj8KPgo+LS0gCj4vLyBCbGFjayBMaW9uIEFLQSBMZXYgU2VyZWJy eWFrb3YgPGxldkBGcmVlQlNELm9yZz4KPgo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18KPmZyZWVic2QtbmV0QGZyZWVic2Qub3JnIG1haWxpbmcgbGlzdAo+ aHR0cDovL2xpc3RzLmZyZWVic2Qub3JnL21haWxtYW4vbGlzdGluZm8vZnJlZWJzZC1uZXQKPlRv IHVuc3Vic2NyaWJlLCBzZW5kIGFueSBtYWlsIHRvICJmcmVlYnNkLW5ldC11bnN1YnNjcmliZUBm cmVlYnNkLm9yZyIK From owner-freebsd-net@FreeBSD.ORG Sun Apr 29 16:21:04 2012 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 47C93106566C; Sun, 29 Apr 2012 16:21:04 +0000 (UTC) (envelope-from seth.mos@dds.nl) Received: from rotring.dds.nl (rotring.dds.nl [85.17.178.138]) by mx1.freebsd.org (Postfix) with ESMTP id 04FC48FC1B; Sun, 29 Apr 2012 16:21:04 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by rotring.dds.nl (Postfix) with ESMTP id 0E70458D4E; Sun, 29 Apr 2012 18:21:03 +0200 (CEST) Received: from localhost (unknown [91.93.32.67]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by rotring.dds.nl (Postfix) with ESMTPSA id 62C5457F63; Sun, 29 Apr 2012 18:20:58 +0200 (CEST) Date: Sun, 29 Apr 2012 19:20:54 +0300 Message-ID: <2vl4qolvow9yktrrufp56o2n.1335716454950@email.android.com> From: Seth Mos To: lev@FreeBSD.org, freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 X-Virus-Scanned: clamav-milter 0.97.3 at rotring X-Virus-Status: Clean Cc: Subject: Re: IPv6 MTU discrovery -- how should it work? 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, 29 Apr 2012 16:21:04 -0000 TWFrZSBzdXJlIHlvdSBkbyBub3QgYmxvY2sgaWNtcDYuIE9yIGF0bGVhc3QgbWFrZSBzdXJlIHRo YXQgdW5yZWFjaGFibGUgYW5kIHRvb2JpZyBwYWNrZXRzIGNvbWUgdGhyb3VnaCBldmVuIGlmIHlv dSBkbyBub3Qgd2FudCBlY2hvLgoKQ2hlZXJzLApTZXRoCgp0eXBlZCBvbiBhIHRpbnkgdG91Y2hz Y3JlZW4sIHdoeSBleGFjdGx5PwoKTGV2IFNlcmVicnlha292IDxsZXZARnJlZUJTRC5vcmc+c2No cmVlZjoKCj5IZWxsbywgRnJlZWJzZC1uZXQuCj4KPiBNeSAgaG9tZSBuZXR3b3JrIGlzIGNvbm5l Y3RlZCB0byBJUHY2IHdvcmxkIHdpdGggSHVycmljYW5lIEVsZWN0cmljJ3MKPnR1bm5lbCAoSVB2 NiBvdmVyIElQdjYsICJnaWYiKS4KPiBJdCBoYXMgTVRVIDEyODAuCj4KPiBFdmVyeXRoaW5nICB3 b3JrcyB0aWxsIHBhY2tldHMgYXJlIHNtYWxsIC0tIGZvciBleGFtcGxlLCBpbnRlcmFjdGl2ZQo+ c2hlbGwgKHNzaCkgc2Vzc2lvbiBvdmVyIElQdjYgd29ya3MgZ3JlYXQuIEJ1dCB3aGVuIEkgbmVl ZCB0byB0cmFuc2Zlcgo+YnVpbCAgb2YgIGJ5dGVzICBmcm9tICBzZXJ2ZXIgIHRvICBsb2NhbCAg bmV0d29yayAgKHNjcCwgIG9yIGV2ZW4gZmFzdAo+c2Nyb2xsaW5nIG9mIG1hbiBwYWdlIGluIGlu dGVyYWN0aXZlIHNlc3Npb24pIHRyYWZmaWMgaGFuZ3MuIEl0IHN0YXJ0cwo+dG8gd29yayBhZnRl ciBjb3VwbGUgKDUtMTApIG1pbnV0ZXMsIGJ1dCBtYW55IGFwcGxpY2F0aW9ucyBoYXMgdGltZW91 dHMKPmxlc3MsIHRoYXQgdGhhdCwgYW5kIGl0IGlzIHZlcnkgYW5ub3lpbmcgaW4gYW55IGNhc2Uu Cj4KPiAgV2hlbiBJIGNvbm5lY3QgdG8gZXh0ZXJuYWwgc2VydmVyIHR3aWNlLCBhbmQgcnVuIHRj cGR1bXAgaW4gb25lCj5zZXNzaW9uIGZvciBhbm90aGVyIG9uZSwgYW5kIHRoZW4gdHJ5IHRvIHVz ZSBzZWNvbmQgKHNuaWZmZWQpIHNlc3Npb24KPmZvciBidWxrIHRyYW5zZmVyLCBJIGNhbiBjbGVh cmx5IHNlZSwgdGhhdCBzZXJ2ZXIgdHJpZXMgdG8gc2VuZCBJUHY2Cj5wYWNrZXRzIHdpdGggc2l6 ZSAxNDIwIHRvIG15IGxvY2FsICBuZXR3b3JrICBtYW55ICB0aW1lcyAgYW5kICBkb2Vzbid0Cj5n ZXQgYW55IGFuc3dlciwgc28gaXQgaXMgTVRVIHByb2JsZW0gZm9yIHN1cmUsIGJ1dCBob3cgaXQg Y291bGQgYmUgZml4ZWQ/Cj4KPiBBbHNvLCBZb3V0dWJlIGRvZXNuJ3Qgd29yayBvdmVyIElQdjYg d2l0aCBzYW1lIHN5bXB0b21zLCBzbyBpdCBpcyBub3QKPm9ubHkgIG15IHNlcnZlcnMnIHByb2Js ZW0sIGl0IGxvb2tzIGxpa2UgbXkgbG9jYWwgbmV0d29yayAoYW5kIHR1bm5lbCkKPnByb2JsZW0u Cj4KPiBIb3cgc2hvdWxkIGl0IHdvcms/IE1heWJlLCBJJ20gZmlsdGVyaW5nIG91dCBzb21ldGhp bmcgbWFuZGF0b3J5IG9uIGZpcmV3YWxsPwo+Cj4tLSAKPi8vIEJsYWNrIExpb24gQUtBIExldiBT ZXJlYnJ5YWtvdiA8bGV2QEZyZWVCU0Qub3JnPgo+Cj5fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXwo+ZnJlZWJzZC1uZXRAZnJlZWJzZC5vcmcgbWFpbGluZyBs aXN0Cj5odHRwOi8vbGlzdHMuZnJlZWJzZC5vcmcvbWFpbG1hbi9saXN0aW5mby9mcmVlYnNkLW5l dAo+VG8gdW5zdWJzY3JpYmUsIHNlbmQgYW55IG1haWwgdG8gImZyZWVic2QtbmV0LXVuc3Vic2Ny aWJlQGZyZWVic2Qub3JnIgo= From owner-freebsd-net@FreeBSD.ORG Sun Apr 29 16:21:25 2012 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 B632A106566C for ; Sun, 29 Apr 2012 16:21:25 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [46.4.40.135]) by mx1.freebsd.org (Postfix) with ESMTP id 75DF48FC19 for ; Sun, 29 Apr 2012 16:21:25 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (89.112.15.178.pppoe.eltel.net [89.112.15.178]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id B3BC14AC2D for ; Sun, 29 Apr 2012 20:21:24 +0400 (MSK) Date: Sun, 29 Apr 2012 20:21:23 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <1683134664.20120429202123@serebryakov.spb.ru> To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: IPv6 tunnel MTU problems: it seems to be gif problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Apr 2012 16:21:25 -0000 Hello, Freebsd-net. man gif says: If the outer protocol is IPv4, gif does not try to perform path MTU dis- covery for the encapsulated packet (DF bit is set to 0). If the outer protocol is IPv6, path MTU discovery for encapsulated pack- ets may affect communication over the interface. The first bigger-than- pmtu packet may be lost. To avoid the problem, you may want to set the interface MTU for gif to 1240 or smaller, when the outer header is IPv6 and the inner header is IPv4. So, it seems, when "outer" interface has MTU less than 1500 (1460, for example, as in my case), MTU on gif interface should be set less (even if outer protocol is IPv4, and inner one is IPv6). But gif doesn't allow MTU less than default 1280 (if_gif.h contains this constant)... Could it be source with my problems with IPv6-over-IPv4-over-PPPoE tunnel? Should sources of if_gif be fixed? Or man page? -- // Black Lion AKA Lev Serebryakov From owner-freebsd-net@FreeBSD.ORG Sun Apr 29 16:25:24 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5C71C1065689 for ; Sun, 29 Apr 2012 16:25:24 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [46.4.40.135]) by mx1.freebsd.org (Postfix) with ESMTP id 184AC8FC12 for ; Sun, 29 Apr 2012 16:25:24 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (89.112.15.178.pppoe.eltel.net [89.112.15.178]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 41A724AC32; Sun, 29 Apr 2012 20:25:23 +0400 (MSK) Date: Sun, 29 Apr 2012 20:25:22 +0400 From: Lev Serebryakov Organization: FreeBSD Project X-Priority: 3 (Normal) Message-ID: <882834004.20120429202522@serebryakov.spb.ru> To: Seth Mos In-Reply-To: <2vl4qolvow9yktrrufp56o2n.1335716454950@email.android.com> References: <2vl4qolvow9yktrrufp56o2n.1335716454950@email.android.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: IPv6 MTU discrovery -- how should it work? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Apr 2012 16:25:24 -0000 Hello, Seth. You wrote 29 =D0=B0=D0=BF=D1=80=D0=B5=D0=BB=D1=8F 2012 =D0=B3., 20:20:54: SM> Make sure you do not block icmp6. Or atleast make sure that SM> unreachable and toobig packets come through even if you do not want ech= o. icmp6 enabled in firewall. It seems to be problem in "gif" interface, which has this words in BUGS section in man page: If the outer protocol is IPv4, gif does not try to perform path MTU di= s- covery for the encapsulated packet (DF bit is set to 0). If the outer protocol is IPv6, path MTU discovery for encapsulated pac= k- ets may affect communication over the interface. The first bigger-tha= n- pmtu packet may be lost. To avoid the problem, you may want to set the interface MTU for gif to 1240 or smaller, when the outer header is IPv6 and the inner header is IPv4. I have MTU 1460 on my "outer" interface (it is PPPoE connection to my IPv4 provider), and gif0 doesn't allow me to set mtu 1240 on it. --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-net@FreeBSD.ORG Sun Apr 29 21:33:13 2012 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 8917A1065673 for ; Sun, 29 Apr 2012 21:33:13 +0000 (UTC) (envelope-from mlists+freebsd-net=freebsd-net=freebsd.org=ljksjktw@daemonground.de) Received: from mx.daemonground.de (mx.daemonground.de [IPv6:2a01:4f8:131:33e1::325]) by mx1.freebsd.org (Postfix) with ESMTP id 9A9A88FC15 for ; Sun, 29 Apr 2012 21:33:12 +0000 (UTC) Received: from [2001:4dd0:f88e:0:5dd:9690:2e32:3ad5] (helo=[IPv6:::1]) by mx.daemonground.de with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim) (envelope-from ) id 1SObjz-000PHu-Lv; Sun, 29 Apr 2012 23:33:11 +0200 Message-ID: <4F9DB397.2090104@daemonground.de> Date: Sun, 29 Apr 2012 23:33:11 +0200 From: Sascha Holzleiter User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: lev@FreeBSD.org References: <1606941405.20120429170656@serebryakov.spb.ru> In-Reply-To: <1606941405.20120429170656@serebryakov.spb.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Hetzner.de IPv6 and FreeBSD -- default gateway is on other prefix, need to add static route before default -- how? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sascha@root-login.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Apr 2012 21:33:13 -0000 On 29.04.2012 15:06, Lev Serebryakov wrote: > Hello, Freebsd-net. > > "Famous" dedicated server provider Hetzner provides native IPv6 for > servers, but with rather strange routing configuration: you need to > configure static interface route and make this route default. > > If I add such lines in /etc/rc.conf: > > ifconfig_re0_ipv6="inet6 2a01:4f8:131:60a2::2 prefixlen 64 auto_linklocal accept_rtadv" > ipv6_static_routes="ipv6defgw" > ipv6_route_ipv6defgw="2a01:4f8:131:60a0:: -prefixlen 59 -iface re0" > ipv6_defaultrouter="2a01:4f8:131:60a0::1" > ipv6_default_interface="re0" > > It doesn't work, because default route added first and it fails to > be added, as route to 2a01:4f8:131:60a0::1 is not known yet. > > If I replace this line in /etc/rc.d/routing: > > ipv6_static_routes="default ${ipv6_static_routes}" > > with > > ipv6_static_routes="${ipv6_static_routes} default" > > Everything works, but it is ugly hack -- to change system startup > script, and I don't like it (for FreeBSD 8 I needed to change > /etc/network.subr in similar way). > > Is here any good way to configure such routing without changes in > scripts, only with /etc/rc.conf? Hi Lev, just use another static route instead of the ipv6_defaultroute entry: ipv6_static_routes="ipv6defgw ipv6defgwroute" ipv6_route_ipv6defgw="2a01:4f8:131:60a0:: -prefixlen 59 -iface re0" ipv6_route_ipv6defgwroute="default 2a01:4f8:131:60a0::1" It's not pretty but works without having to modify the rc scripts. Greetings, Sascha From owner-freebsd-net@FreeBSD.ORG Sun Apr 29 21:42:57 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 112D7106566B; Sun, 29 Apr 2012 21:42:57 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper-int.allbsd.org [IPv6:2001:2f0:104:e002::2]) by mx1.freebsd.org (Postfix) with ESMTP id 6B09D8FC0A; Sun, 29 Apr 2012 21:42:56 +0000 (UTC) Received: from alph.allbsd.org (p4242-ipbf1504funabasi.chiba.ocn.ne.jp [118.7.211.242]) (authenticated bits=128) by mail.allbsd.org (8.14.4/8.14.4) with ESMTP id q3TLgaNa008044; Mon, 30 Apr 2012 06:42:46 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.allbsd.org (8.14.4/8.14.4) with ESMTP id q3TLgYbY059724; Mon, 30 Apr 2012 06:42:36 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Mon, 30 Apr 2012 06:42:29 +0900 (JST) Message-Id: <20120430.064229.855968812732421988.hrs@allbsd.org> To: lev@FreeBSD.org From: Hiroki Sato In-Reply-To: <1606941405.20120429170656@serebryakov.spb.ru> References: <1606941405.20120429170656@serebryakov.spb.ru> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.4.50 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Mon_Apr_30_06_42_29_2012_929)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.3 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.allbsd.org [133.31.130.32]); Mon, 30 Apr 2012 06:42:50 +0900 (JST) X-Spam-Status: No, score=-101.9 required=13.0 tests=BAYES_00, CONTENT_TYPE_PRESENT,FSL_RU_URL,RCVD_IN_RP_RNBL,SPF_SOFTFAIL, USER_IN_WHITELIST autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on gatekeeper.allbsd.org Cc: freebsd-net@FreeBSD.org Subject: Re: Hetzner.de IPv6 and FreeBSD -- default gateway is on other prefix, need to add static route before default -- how? 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, 29 Apr 2012 21:42:57 -0000 ----Security_Multipart(Mon_Apr_30_06_42_29_2012_929)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lev Serebryakov wrote in <1606941405.20120429170656@serebryakov.spb.ru>: le> Hello, Freebsd-net. le> le> "Famous" dedicated server provider Hetzner provides native IPv6 for le> servers, but with rather strange routing configuration: you need to le> configure static interface route and make this route default. le> le> If I add such lines in /etc/rc.conf: le> le> ifconfig_re0_ipv6="inet6 2a01:4f8:131:60a2::2 prefixlen 64 auto_linklocal accept_rtadv" le> ipv6_static_routes="ipv6defgw" le> ipv6_route_ipv6defgw="2a01:4f8:131:60a0:: -prefixlen 59 -iface re0" le> ipv6_defaultrouter="2a01:4f8:131:60a0::1" le> ipv6_default_interface="re0" le> le> It doesn't work, because default route added first and it fails to le> be added, as route to 2a01:4f8:131:60a0::1 is not known yet. Why do you need to configure the default route manually? If accepting RA on re0 it should be configured automatically. -- Hiroki ----Security_Multipart(Mon_Apr_30_06_42_29_2012_929)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAk+dtcUACgkQTyzT2CeTzy0OpQCfay6ov5pi8WSFs6qBR7h77Hu7 W9UAoJPmBRmO8WuSNxlBmmyCN00lxig2 =2opH -----END PGP SIGNATURE----- ----Security_Multipart(Mon_Apr_30_06_42_29_2012_929)---- From owner-freebsd-net@FreeBSD.ORG Mon Apr 30 00:03:49 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D99C1106566C for ; Mon, 30 Apr 2012 00:03:49 +0000 (UTC) (envelope-from mikemacleod@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 A14498FC0A for ; Mon, 30 Apr 2012 00:03:49 +0000 (UTC) Received: by iahk25 with SMTP id k25so4820970iah.13 for ; Sun, 29 Apr 2012 17:03:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=kWQszmu5sxiLNY5XF4z/JpwEsnUadOnKyaHJv3R4ET4=; b=EgQ9Ua18Ksl9WNS1WlzHFadXb/294ymd1p8p0W6WNFtz+zor3sca2Oxk8MH6USG1H/ CPDFUU04kXDYA4KvahjiTdaVshqJirD43D4wxDsKAFk9ljg+c/R77Ol2MSYML+hsBvLr n3aN/hlEexbKWVMOf+b5aMBYPGLZTteofKRCQXv4WuQrm/N24/znpTyeFwlAwxghPNuK v+2T9L3ATa18kqT3ZVOLyoxn6BUeN5pf0wu/1edrpUAm6aipCPCeiLVQ4uJ1+/IoCJG7 vNNcYGhUBfRRzYVSbfnNA0798QeKQ2UopIvfQnH9bh7k1xoWJAZ1ONOWWATKeNz1FkyD cpkw== Received: by 10.50.193.132 with SMTP id ho4mr8713831igc.17.1335744223384; Sun, 29 Apr 2012 17:03:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.133.6 with HTTP; Sun, 29 Apr 2012 17:03:23 -0700 (PDT) From: Michael MacLeod Date: Sun, 29 Apr 2012 20:03:23 -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: Full Cone NAT In PF 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, 30 Apr 2012 00:03:50 -0000 Hello FreeBSD-Net, Every once and a while I run into an issue wherein the symmetric NAT of pf causes me grief. I've found some older mailing list entries asking about PF and Cone or Full Cone NAT (such as this one from 2005: http://www.mail-archive.com/freebsd-pf@freebsd.org/msg00804.html), but I haven't seen anything new in a while. Almost all discussion I can find suggests to use static-port on the NAT rule entry, but this doesn't seem to be entirely the same thing. Adding static-port will prevent PF from randomizing the source port used for outbound TCP and UDP traffic, but I don't see any mention of it enabling actual Cone behaviour with regards to inbound traffic destined for the now-not-random port. It appears that a NAT table entry, even with the static-port option, will still not accept an inbound packet from external IP B when the NAT rule was originally created for external IP A, which I gather is the main thrust of cone NAT. I understand that cone NAT is a generally terrible and insecure way to do NAT, but game and application developers seem hell-bent on depending on cone NAT behaviour. Is there a way to make it work with PF? Regards, Mike From owner-freebsd-net@FreeBSD.ORG Mon Apr 30 02:47:25 2012 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 16F9C106566B for ; Mon, 30 Apr 2012 02:47:24 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 554B38FC08 for ; Mon, 30 Apr 2012 02:47:24 +0000 (UTC) Received: by bkvi17 with SMTP id i17so1105167bkv.13 for ; Sun, 29 Apr 2012 19:47:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JJltr+8NwGjvmGhRbs3qEgi+LBbh5AwwGhsSWAnaw+c=; b=OC14UikKoYRnBR68V9HYTtkPoxTbCeAX8gS/yf4hOSHfY/kWlD25/90DZl40xbEe3m pTEYcmlwQwGpVf4OJ8lkWDkh8GdRgjG2YKwIhvSXxMldsVc0zIOIseLK6rFPWA/CZEdC UoQAgDyinPYvSpkzoAljDEOhtCv7mCCBAYSmv8XRvHKCOUOeXFTjPDtztYhVGZ95bosR 4t1ap1PNTshjRK3a+JrIncGokprUYZ//JDkq52Xuz/kpAczXm8X6OTmopcr56aJTIN/8 s2ibuaX1gB419LOjc/1L3aWeKMXjfOSlkcYOvpX9/deEd68PhUuLj9sxGpzVdfIHl87/ q0iA== MIME-Version: 1.0 Received: by 10.204.152.137 with SMTP id g9mr5268713bkw.95.1335754043123; Sun, 29 Apr 2012 19:47:23 -0700 (PDT) Received: by 10.204.179.65 with HTTP; Sun, 29 Apr 2012 19:47:23 -0700 (PDT) In-Reply-To: References: Date: Sun, 29 Apr 2012 22:47:23 -0400 Message-ID: From: Zaphod Beeblebrox To: Michael MacLeod Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org Subject: Re: Full Cone NAT In PF 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, 30 Apr 2012 02:47:25 -0000 On Sun, Apr 29, 2012 at 8:03 PM, Michael MacLeod wrote: > Every once and a while I run into an issue wherein the symmetric NAT of pf > causes me grief. I've found some older mailing list entries asking about PF > and Cone or Full Cone NAT (such as this one from 2005: > http://www.mail-archive.com/freebsd-pf@freebsd.org/msg00804.html), but I > haven't seen anything new in a while. > > Almost all discussion I can find suggests to use static-port on the NAT > rule entry, but this doesn't seem to be entirely the same thing. Adding > static-port will prevent PF from randomizing the source port used for > outbound TCP and UDP traffic, but I don't see any mention of it enabling > actual Cone behaviour with regards to inbound traffic destined for the > now-not-random port. It appears that a NAT table entry, even with the > static-port option, will still not accept an inbound packet from external > IP B when the NAT rule was originally created for external IP A, which I > gather is the main thrust of cone NAT. > > I understand that cone NAT is a generally terrible and insecure way to do > NAT, but game and application developers seem hell-bent on depending on > cone NAT behaviour. Is there a way to make it work with PF? You might want this because some of your internal machines play video games. The unfortunate thing is that some video games are "somewhat" smart about getting around NAT and others are exceedingly dumb. In the end, what you do will depend on what resources you have. I found that: nat on $ext_if inet from $int_net to any -> ($ext_if) static-port is best paired by: rdr on $ext_if inet from any to $ext_ip -> $workstation_ip now... this works well for one gaming workstation. Also be clear that the outside world is free to attack it. You might want to put in a bunch of rules to protect it's SMB and whatnot ports. With just the 'nat' rule as above, CoD will call your NAT "strict" (in red). With both rules, CoD will call your NAT "moderate" in grey. With just the first rule and borderlands, you'll be able to join but not host games. With both rules, you'll be able to host games. I don't see an easy way to open only ports that are active with other traffic on pf. From owner-freebsd-net@FreeBSD.ORG Mon Apr 30 05:45:57 2012 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 AAE6E106566B for ; Mon, 30 Apr 2012 05:45:57 +0000 (UTC) (envelope-from darren.pilgrim@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 79EF18FC08 for ; Mon, 30 Apr 2012 05:45:57 +0000 (UTC) Received: by pbbro2 with SMTP id ro2so1912267pbb.13 for ; Sun, 29 Apr 2012 22:45:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=8k9bY1g5sVyEOSFnBpSKYuWnrmu67dvI8zZ0NMRcSa4=; b=hF4H7h1l1IrkODezqmkRwDBWZY6SJeJJHrb3Z2cLf7PoPHiuAi8WjmpCwm+Jg1SlHR a1L+lPoFdaXNWDDmWsKaCJPL26Gn8gZ+ajVHHWaY9gqH8GXkVwQnnDjIdyb/1+rZjbBE Mab0KbxI+FVnIW9X3MzxXw3pfB4JWM/MDZfrJ+vBxOSk34+dIuEFMlXhH6E0XbvEBT/t SIGQtWEv6qfmdJSvaNcDuTE4IvFFy685TxdFc3nzj3YDd0Lyomke+gt/7DP+vrJMlv7/ an5AGCZWGyBz+U5f4ALDFYGe/tjTg/yuWFc5kmGENHVzF+D6SQObiolTcDnuDo2Fwz0q 4tDQ== Received: by 10.68.230.131 with SMTP id sy3mr7865629pbc.17.1335764756950; Sun, 29 Apr 2012 22:45:56 -0700 (PDT) Received: from [127.0.0.1] (c-71-236-141-77.hsd1.wa.comcast.net. [71.236.141.77]) by mx.google.com with ESMTPS id i5sm15004512pbf.19.2012.04.29.22.45.53 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 29 Apr 2012 22:45:55 -0700 (PDT) Message-ID: <4F9E270F.3070605@gmail.com> Date: Sun, 29 Apr 2012 22:45:51 -0700 From: Darren Pilgrim User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.3) Gecko/20120306 Thunderbird/10.0.3 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: Full Cone NAT In PF 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, 30 Apr 2012 05:45:57 -0000 On 2012-04-29 17:03, Michael MacLeod wrote: > I understand that cone NAT is a generally terrible and insecure way to do > NAT, but game and application developers seem hell-bent on depending on > cone NAT behaviour. Is there a way to make it work with PF? Not directly, no. In most cases where the application/device will not work through symmetric NAT, all that is necessary is a port forward, not true full-cone NAT. Have a look at the net/miniupnpd port. It is a UPnP daemon that anchors to pf and maintains rdr rules for dynamic port forwarding. You can do the same thing on a static basis by maintaining your own nat static-port and rdr rules if your SIP devices do not support UPnP. For those who search mail archives, this is also how you get a FreeBSD router to make your PS3 show NAT type 2 instead of type 3 or your Xbox show NAT type open instead of strict or moderate. From owner-freebsd-net@FreeBSD.ORG Mon Apr 30 06:02:45 2012 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 02410106566B; Mon, 30 Apr 2012 06:02:45 +0000 (UTC) (envelope-from adrian@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id C95C78FC0A; Mon, 30 Apr 2012 06:02:44 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q3U62i7b043068; Mon, 30 Apr 2012 06:02:44 GMT (envelope-from adrian@freefall.freebsd.org) Received: (from adrian@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q3U62ivR043064; Mon, 30 Apr 2012 06:02:44 GMT (envelope-from adrian) Date: Mon, 30 Apr 2012 06:02:44 GMT Message-Id: <201204300602.q3U62ivR043064@freefall.freebsd.org> To: adrian@FreeBSD.org, freebsd-net@FreeBSD.org, freebsd-wireless@FreeBSD.org From: adrian@FreeBSD.org Cc: Subject: Re: kern/146425: [mwl] mwl dropping all packets during and after high usage on 802.11n 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, 30 Apr 2012 06:02:45 -0000 Synopsis: [mwl] mwl dropping all packets during and after high usage on 802.11n Responsible-Changed-From-To: freebsd-net->freebsd-wireless Responsible-Changed-By: adrian Responsible-Changed-When: Mon Apr 30 06:02:18 UTC 2012 Responsible-Changed-Why: Switch over http://www.freebsd.org/cgi/query-pr.cgi?pr=146425 From owner-freebsd-net@FreeBSD.ORG Mon Apr 30 06:03:21 2012 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 917FF1065674; Mon, 30 Apr 2012 06:03:21 +0000 (UTC) (envelope-from adrian@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 659748FC1D; Mon, 30 Apr 2012 06:03:21 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q3U63LWt043208; Mon, 30 Apr 2012 06:03:21 GMT (envelope-from adrian@freefall.freebsd.org) Received: (from adrian@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q3U63L2i043204; Mon, 30 Apr 2012 06:03:21 GMT (envelope-from adrian) Date: Mon, 30 Apr 2012 06:03:21 GMT Message-Id: <201204300603.q3U63L2i043204@freefall.freebsd.org> To: adrian@FreeBSD.org, freebsd-net@FreeBSD.org, freebsd-wireless@FreeBSD.org From: adrian@FreeBSD.org Cc: Subject: Re: kern/146426: [mwl] 802.11n rates not possible on mwl 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, 30 Apr 2012 06:03:21 -0000 Synopsis: [mwl] 802.11n rates not possible on mwl Responsible-Changed-From-To: freebsd-net->freebsd-wireless Responsible-Changed-By: adrian Responsible-Changed-When: Mon Apr 30 06:02:49 UTC 2012 Responsible-Changed-Why: Flip to -wireless http://www.freebsd.org/cgi/query-pr.cgi?pr=146426 From owner-freebsd-net@FreeBSD.ORG Mon Apr 30 08:55:23 2012 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 78EBA106564A; Mon, 30 Apr 2012 08:55:23 +0000 (UTC) (envelope-from melifaro@FreeBSD.org) Received: from mail.ipfw.ru (unknown [IPv6:2a01:4f8:120:6141::2]) by mx1.freebsd.org (Postfix) with ESMTP id 0AC768FC17; Mon, 30 Apr 2012 08:55:23 +0000 (UTC) Received: from v6.mpls.in ([2a02:978:2::5] helo=ws.su29.net) by mail.ipfw.ru with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1SOmOH-0001ME-QR; Mon, 30 Apr 2012 12:55:29 +0400 Message-ID: <4F9E531B.6020203@FreeBSD.org> Date: Mon, 30 Apr 2012 12:53:47 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20120121 Thunderbird/9.0 MIME-Version: 1.0 To: Adrian Chadd References: <201204060653.q366rwLa096182@svn.freebsd.org> <4F7E9413.20602@FreeBSD.org> <4F8BBD4E.1040106@FreeBSD.org> <4F91240C.3050703@ipfw.ru> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: svn-src-head@freebsd.org, freebsd-net@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r233937 - in head/sys: kern net security/mac 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, 30 Apr 2012 08:55:23 -0000 On 28.04.2012 00:42, Adrian Chadd wrote: > Hi Alex, Hello! > > I don't want to be demanding, but would you please consider committing > your fixes? I've asked glebius@ for the review for a while ago, but it seems it is a bit staled.. > > And if you could, would you please do it as a set of commits, one per > 'thing', rather than one big monolithic commit that does half a dozen > different things? That way if there are any further regressions, > I/others could test things out. Ok, I'll try to commit fixes today. > > This is breaking bpf for a few people - ladv causes a crash, wifi also > causes a crash. > > Thanks! > > > Adrian > From owner-freebsd-net@FreeBSD.ORG Mon Apr 30 11:07:37 2012 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 96E8C1065677 for ; Mon, 30 Apr 2012 11:07:37 +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 7F6F18FC24 for ; Mon, 30 Apr 2012 11:07:37 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q3UB7b6q053966 for ; Mon, 30 Apr 2012 11:07:37 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q3UB7aMT053962 for freebsd-net@FreeBSD.org; Mon, 30 Apr 2012 11:07:36 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 30 Apr 2012 11:07:36 GMT Message-Id: <201204301107.q3UB7aMT053962@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, 30 Apr 2012 11:07:37 -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/167325 net [netinet] [patch] sosend sometimes return EINVAL with o kern/167202 net [igmp]: Sending multiple IGMP packets crashes kernel o kern/167059 net [tcp] [panic] System does panic in in_pcbbind() and ha o kern/166940 net [ipfilter] [panic] Double fault in kern 8.2 o kern/166550 net [netinet] [patch] Some log lines about arp do not incl o kern/166462 net [gre] gre(4) when using a tunnel source address from c o kern/166372 net [patch] ipfilter drops UDP packets with zero checksum o kern/166285 net [arp] FreeBSD v8.1 REL p8 arp: unknown hardware addres o kern/166255 net [net] [patch] It should be possible to disable "promis o kern/165963 net [panic] [ipf] ipfilter/nat NULL pointer deference o kern/165903 net mbuf leak o kern/165863 net [panic] [netinet] [patch] in_lltable_prefix_free() rac o kern/165643 net [net] [patch] Missing vnet restores in net/if_ethersub o kern/165622 net [ndis][panic][patch] Unregistered use of FPU in kernel s kern/165562 net [request] add support for Intel i350 in FreeBSD 7.4 o kern/165526 net [bxe] UDP packets checksum calculation whithin if_bxe o kern/165488 net [ppp] [panic] Fatal trap 12 jails and ppp , kernel wit o kern/165305 net [ip6] [request] Feature parity between IP_TOS and IPV6 o kern/165296 net [vlan] [patch] Fix EVL_APPLY_VLID, update EVL_APPLY_PR o kern/165181 net [igb] igb freezes after about 2 weeks of uptime o kern/165174 net [patch] [tap] allow tap(4) to keep its address on clos o kern/165152 net [ip6] Does not work through the issue of ipv6 addresse o kern/164495 net [igb] connect double head igb to switch cause system t o kern/164490 net [pfil] Incorrect IP checksum on pfil pass from ip_outp o kern/164475 net [gre] gre misses RUNNING flag after a reboot o kern/164400 net [ipsec] immediate crash after the start of ipsec proce o kern/164265 net [netinet] [patch] tcp_lro_rx computes wrong checksum i o kern/163903 net [igb] "igb0:tx(0)","bpf interface lock" v2.2.5 9-STABL o kern/163481 net freebsd do not add itself to ping route packet o kern/162927 net [tun] Modem-PPP error ppp[1538]: tun0: Phase: Clearing o kern/162926 net [ipfilter] Infinite loop in ipfilter with fragmented I o kern/162558 net [dummynet] [panic] seldom dummynet panics o kern/162153 net [em] intel em driver 7.2.4 don't compile o kern/162110 net [igb] [panic] RELENG_9 panics on boot in IGB driver - o kern/162028 net [ixgbe] [patch] misplaced #endif in ixgbe.c o kern/161381 net [re] RTL8169SC - re0: PHY write failed o kern/161277 net [em] [patch] BMC cannot receive IPMI traffic after loa o kern/160873 net [igb] igb(4) from HEAD fails to build on 7-STABLE o kern/160750 net Intel PRO/1000 connection breaks under load until rebo o kern/160693 net [gif] [em] Multicast packet are not passed from GIF0 t o kern/160420 net [msk] phy write timeout on HP 5310m o kern/160293 net [ieee80211] ppanic] kernel panic during network setup o kern/160206 net [gif] gifX stops working after a while (IPv6 tunnel) o kern/159817 net [udp] write UDPv4: No buffer space available (code=55) o kern/159629 net [ipsec] [panic] kernel panic with IPsec in transport m o kern/159621 net [tcp] [panic] panic: soabort: so_count o kern/159603 net [netinet] [patch] in_ifscrubprefix() - network route c o kern/159601 net [netinet] [patch] in_scrubprefix() - loopback route re o kern/159294 net [em] em watchdog timeouts o kern/159203 net [wpi] Intel 3945ABG Wireless LAN not support IBSS o kern/158930 net [bpf] BPF element leak in ifp->bpf_if->bif_dlist o kern/158726 net [ip6] [patch] ICMPv6 Router Announcement flooding limi o kern/158694 net [ix] [lagg] ix0 is not working within lagg(4) o kern/158665 net [ip6] [panic] kernel pagefault in in6_setscope() o kern/158635 net [em] TSO breaks BPF packet captures with em driver f kern/157802 net [dummynet] [panic] kernel panic in dummynet o kern/157785 net amd64 + jail + ipfw + natd = very slow outbound traffi o kern/157418 net [em] em driver lockup during boot on Supermicro X9SCM- o kern/157410 net [ip6] IPv6 Router Advertisements Cause Excessive CPU U o kern/157287 net [re] [panic] INVARIANTS panic (Memory modified after f o kern/157209 net [ip6] [patch] locking error in rip6_input() (sys/netin o kern/157200 net [network.subr] [patch] stf(4) can not communicate betw o kern/157182 net [lagg] lagg interface not working together with epair o kern/156877 net [dummynet] [panic] dummynet move_pkt() null ptr derefe o kern/156667 net [em] em0 fails to init on CURRENT after March 17 o kern/156408 net [vlan] Routing failure when using VLANs vs. Physical e o kern/156328 net [icmp]: host can ping other subnet but no have IP from o kern/156317 net [ip6] Wrong order of IPv6 NS DAD/MLD Report o kern/156283 net [ip6] [patch] nd6_ns_input - rtalloc_mpath does not re o kern/156279 net [if_bridge][divert][ipfw] unable to correctly re-injec o kern/156226 net [lagg]: failover does not announce the failover to swi o kern/156030 net [ip6] [panic] Crash in nd6_dad_start() due to null ptr o kern/155772 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/155597 net [panic] Kernel panics with "sbdrop" message o kern/155420 net [vlan] adding vlan break existent vlan o kern/155177 net [route] [panic] Panic when inject routes in kernel o kern/155030 net [igb] igb(4) DEVICE_POLLING does not work with carp(4) o kern/155010 net [msk] ntfs-3g via iscsi using msk driver cause kernel o kern/154943 net [gif] ifconfig gifX create on existing gifX clears IP s kern/154851 net [request]: Port brcm80211 driver from Linux to FreeBSD o kern/154850 net [netgraph] [patch] ng_ether fails to name nodes when t o kern/154679 net [em] Fatal trap 12: "em1 taskq" only at startup (8.1-R o kern/154600 net [tcp] [panic] Random kernel panics 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/152036 net [libc] getifaddrs(3) returns truncated sockaddrs for n 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 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 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 kern/145825 net [panic] panic: soabort: so_count o kern/145728 net [lagg] Stops working lagg between two servers. p kern/145600 net TCP/ECN behaves different to CE/CWR than ns2 reference 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 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/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/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 f kern/138029 net [bpf] [panic] periodically kernel panic and reboot o kern/137881 net [netgraph] [panic] ng_pppoe fatal trap 12 p 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 kern/136618 net [pf][stf] panic on cloning interface without unit numb o kern/135502 net [periodic] Warning message raised by rtfree function i 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 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/132277 net [crypto] [ipsec] poor performance using cryptodevice f 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 f 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 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/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy 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/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 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 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/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 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/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 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 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 399 problems total. From owner-freebsd-net@FreeBSD.ORG Tue May 1 00:44:34 2012 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 3518E106564A for ; Tue, 1 May 2012 00:44:34 +0000 (UTC) (envelope-from mikemacleod@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 EE1138FC12 for ; Tue, 1 May 2012 00:44:33 +0000 (UTC) Received: by iahk25 with SMTP id k25so6768654iah.13 for ; Mon, 30 Apr 2012 17:44:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Juw7r+033eJai4TOKO5QfxhIWLMacrNrpgEVp6gUT6g=; b=eTxs/tM8TbnrJAzk9vliYfpP3A3IiNfHD6OMTQkt9yY9H++t0V7sGq5ukTUQeBtFGa fmjQb9fa5xgQfuuLfNrmFbCMNttgv0/4S2obuP8a+6WpSu6AsfX/UHVmt6BKbGGl52GY rRRcNV7labv5jmdQcx0yO8mUH1ombV+D08V8nqZj4tA3Fk5l9DNvnSj4inLaCfi9ydOs u1gZZca632Nl0Wq9dlY74NI6KRbulGsr8J5BWa0yTzgJewgYOSCze+bAd9N44aJ51iyi 7ckaB8O6KM2BujsB1Cjbv7Mlk0xFBFS/UbYisGHOdZ2eIkOcek4DV18jaTR/+ZAVCZJS MwwA== Received: by 10.43.49.3 with SMTP id uy3mr3369133icb.2.1335833073633; Mon, 30 Apr 2012 17:44:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.133.6 with HTTP; Mon, 30 Apr 2012 17:44:13 -0700 (PDT) In-Reply-To: <4F9E270F.3070605@gmail.com> References: <4F9E270F.3070605@gmail.com> From: Michael MacLeod Date: Mon, 30 Apr 2012 20:44:13 -0400 Message-ID: To: Darren Pilgrim Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: Full Cone NAT In PF 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, 01 May 2012 00:44:34 -0000 Darren and Zaphod, Thanks for the response. If I understand full-cone NAT it's basically like opening a port forward in the firewall, since any packets arriving on the WAN interface for that particular external port from any source address will be forwarded to the internal host. And you are correct that UPnP should enable this type of connectivity as well, by explicitly opening a port in the firewall. I have both static-port and miniupnpd enabled on my router. According to the Microsoft Internet Evaluation Tool, my NAT Type is symmetrical but UPnP is supported. I'm currently having a problem with Battlefield 3 co-op play, so I'm using that to test. I can play regular online games fine, and I can play co-op games with friends who have Linux (mostly DD-WRT based) routers. But I configured a FreeBSD firewall at one particular friends place that uses a largely similar configuration as my own. They get the same results from the MS Eval Tool, but I cannot successfully play a co-op game with any of the people in that house. We can all play regular online games hosted on third party servers, but cannot play co-op matches. At the end of the day we could solve it by getting our ISP to route a /29 to their house and using binat (I already have a /29), but it would be nice if there was the option to use 'nat on $wan_if from -> ($wan_if) full-cone' in a ruleset to achieve the correct behaviour. On Mon, Apr 30, 2012 at 1:45 AM, Darren Pilgrim wrote: > On 2012-04-29 17:03, Michael MacLeod wrote: > >> I understand that cone NAT is a generally terrible and insecure way to do >> NAT, but game and application developers seem hell-bent on depending on >> cone NAT behaviour. Is there a way to make it work with PF? >> > > Not directly, no. In most cases where the application/device will not > work through symmetric NAT, all that is necessary is a port forward, not > true full-cone NAT. > > Have a look at the net/miniupnpd port. It is a UPnP daemon that anchors > to pf and maintains rdr rules for dynamic port forwarding. You can do the > same thing on a static basis by maintaining your own nat static-port and > rdr rules if your SIP devices do not support UPnP. > > For those who search mail archives, this is also how you get a FreeBSD > router to make your PS3 show NAT type 2 instead of type 3 or your Xbox show > NAT type open instead of strict or moderate. > From owner-freebsd-net@FreeBSD.ORG Tue May 1 00:46:31 2012 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 7CE87106564A for ; Tue, 1 May 2012 00:46:31 +0000 (UTC) (envelope-from prabhakar.lakhera@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 364F48FC0C for ; Tue, 1 May 2012 00:46:31 +0000 (UTC) Received: by yenl9 with SMTP id l9so2035178yen.13 for ; Mon, 30 Apr 2012 17:46:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=JOFkYGMyX1T3dh67qXEeR4FGbbXtg77S4UwqCM3/iuw=; b=L6fDnaKUtEZN60EsuDU0im0bJl1yszBTUtgx67ZzVyuWR7Ya9eME5bWovmrMTTGNtK tGbCln+6rGNxWLai+QDYSK6X6iUMxeppp+iVKpy2zxDuB8jrmoOF1W5cd11s4uXe+3a3 mgbCj/hNrvN/HXVh5MPl5HeMY6aiMLsHyBhriKCn1UCyjeMLRU669ttAdy6ZeIJWdWAz KDymbXQfkJMQiiJNWG/5ui89i+ySgZUrJzAuu+9hwfnxFjMb+YlHBqWikLZdBvOyjitH /L5Ayu0zK+j1HlkUNR2tu8QDBXeVVTJc2rrPkZ14v2VulJg8mN+TNcOguSaQwiyCbrxf mZFA== MIME-Version: 1.0 Received: by 10.236.78.74 with SMTP id f50mr23969259yhe.26.1335833190523; Mon, 30 Apr 2012 17:46:30 -0700 (PDT) Received: by 10.100.205.10 with HTTP; Mon, 30 Apr 2012 17:46:30 -0700 (PDT) Date: Mon, 30 Apr 2012 17:46:30 -0700 Message-ID: From: prabhakar lakhera To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Question on rtredirect code 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, 01 May 2012 00:46:31 -0000 Hi, The rtredirect code has the following code lines: */* verify the gateway is directly reachable */* 521 if ((ifa = ifa_ifwithnet (gateway , 0)) == NULL ) { 522 error = ENETUNREACH ; 523 goto out ; 524 } Later on we check for the validity of the redirect message. One of the criteria is the comparison of rt_ifa with ifa: */** 527 * * If the redirect isn't from our current router for this dst,* 528 * * it's either old or wrong. If it redirects us to ourselves,* 529 * * we have a routing loop, perhaps as a result of an interface* 530 * * going down recently.* 531 * */* 532 if (!(flags & RTF_DONE ) && rt && 533 (!sa_equal (src , rt ->rt_gateway) || rt ->rt_ifa != ifa)) 534 error = EINVAL ; TCP IP illustrated vol 2 comments on the code: "The interface for the new gateway (the fia returned by ifa_ifwithnet) must equal the curent interface for destination (rt_ifa), that is new gateway must be on the same network as the current gateway." One thing to note here is that we are comparing ifa to compare for interface (ifp). It could be that the code was not revisited in later BSD releases but it seems to suggest that when the code was written hosting multiple ifa in same ifp or different ifp was not thought of/supported. Does the above code still stand good? To me it seems that it needs to be corrected. Comments are welcome. Best, Prabhakar From owner-freebsd-net@FreeBSD.ORG Tue May 1 01:48:20 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AF4FC106566C for ; Tue, 1 May 2012 01:48:20 +0000 (UTC) (envelope-from jdavidlists@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 6A9068FC1A for ; Tue, 1 May 2012 01:48:20 +0000 (UTC) Received: by yhgm50 with SMTP id m50so2054867yhg.13 for ; Mon, 30 Apr 2012 18:48:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=0eFe1eJDfP4IVEruOMnNCfuTI8NyCGW3i0y1lOzQzpY=; b=pnMdZE3XKu4w9ahUd9S2nQwmdOABtmB/sHN0aO9vEthIgk/nd3PIiOAlRnd6DYZYui 8F0QwNeYAVQi0ezcB0D7xA0d7W5UqwOSg3fZLe/a0sovoAlSmNVuUznJSXi3F3BmbuDb Ek+iA3a8oz8awZqcLU67I7jARNVd4rVE8wEcGNYa7xzg8Kt7D6eW4PqvESl/kxO/gGaw xi3Jd9TwUMLgSNEiyQRqw2P/ZYk3GRC1z4IFqkz74qeBrAJgUl0rpIS0X8TwBWYmdejG ZmaF5QIa8Po02obbOXGQaPQDX3pSst/pqHbjF31OTvpvEXaB2oHshlDSnik8TTz0lwG0 0Vtg== MIME-Version: 1.0 Received: by 10.236.75.74 with SMTP id y50mr24727978yhd.42.1335836899723; Mon, 30 Apr 2012 18:48:19 -0700 (PDT) Sender: jdavidlists@gmail.com Received: by 10.236.30.164 with HTTP; Mon, 30 Apr 2012 18:48:19 -0700 (PDT) Date: Mon, 30 Apr 2012 21:48:19 -0400 X-Google-Sender-Auth: Gg-KxWCRt2CkADytS-KcqyBvldc Message-ID: From: J David To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Panics in 8.3 with em & pf 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, 01 May 2012 01:48:20 -0000 Hello, I have started getting frequent panics related to the em driver on 8.3-STABLE (about every 8 hours). Fatal trap 9: general protection fault while in kernel mode cpuid = 1; apic id = 01 instruction pointer = 0x20:0xffffffff806cd1d5 stack pointer = 0x28:0xffffff80000f1450 frame pointer = 0x28:0xffffff80000f1470 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 0 (em1 que) trap number = 9 panic: general protection fault cpuid = 1 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a kdb_backtrace() at kdb_backtrace+0x37 panic() at panic+0x183 trap_fatal() at trap_fatal+0x290 trap() at trap+0x105 calltrap() at calltrap+0x8 --- trap 0x9, rip = 0xffffffff806cd1d5, rsp = 0xffffff80000f1450, rbp = 0xffffff80000f1470 --- m_freem() at m_freem+0x25 em_txeof() at em_txeof+0x164 em_start_locked() at em_start_locked+0x718 em_start() at em_start+0x5c if_transmit() at if_transmit+0xea lagg_start() at lagg_start+0x17b if_transmit() at if_transmit+0xea vlan_transmit() at vlan_transmit+0x11d ether_output_frame() at ether_output_frame+0x33 ether_output() at ether_output+0x518 ip_fastforward() at ip_fastforward+0x4a5 ether_demux() at ether_demux+0x198 ether_input() at ether_input+0x197 ether_demux() at ether_demux+0x6f ether_input() at ether_input+0x197 em_rxeof() at em_rxeof+0x1c7 em_handle_que() at em_handle_que+0x52 taskqueue_run_locked() at taskqueue_run_locked+0x85 taskqueue_thread_loop() at taskqueue_thread_loop+0x4e fork_exit() at fork_exit+0x11f fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff80000f1d00, rbp = 0 --- Uptime: 9h55m2s Cannot dump. Device not defined or unavailable. Automatic reboot in 15 seconds - press a key on the console to abort --> Press a key on the console to reboot, em2: discard frame w/o packet header Fatal trap 9: general protection fault while in kernel mode cpuid = 1; apic id = 01 instruction pointer = 0x20:0xffffffff806cd1d5 stack pointer = 0x28:0xffffff800011ba50 frame pointer = 0x28:0xffffff800011ba70 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 0 (em2 que) trap number = 9 panic: general protection fault cpuid = 1 This machine is a pf firewall under a pretty heavy traffic load. The line "em2: discard frame w/o packet header" seems to be the most informative diagnostic, because all that interface does is pfsync to the another machine; it's under very light load compared to em0, em1, and em3. The uname is: FreeBSD r1 8.3-STABLE FreeBSD 8.3-STABLE #5 r234781: Sun Apr 29 21:28:10 UTC 2012 root@r1:/data/r1/freebsd/obj/data/r1/freebsd/8-STABLE/sys/ROUTER64 amd64 I don't know if it's relevant, but I have also noticed behavior on this machine that's been reported elsewhere -- heavy load on the "busy" interfaces makes it prone to neglect the less-busy ones, even though it is not bound by any resource I can see.. it's a dual core that runs ~25% CPU utilized at its busiest. I've tried to tune it to prevent this to no real effect so far. Could anyone point me in the right direction on this? Thanks! From owner-freebsd-net@FreeBSD.ORG Tue May 1 02:24:13 2012 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 5C5E0106566B for ; Tue, 1 May 2012 02:24:13 +0000 (UTC) (envelope-from darren.pilgrim@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 26A4A8FC08 for ; Tue, 1 May 2012 02:24:13 +0000 (UTC) Received: by pbbro2 with SMTP id ro2so3076747pbb.13 for ; Mon, 30 Apr 2012 19:24:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=3ck6q+A2PYY8OxuwxM32/j0F8+J7twOhmpkuOhcLnM4=; b=okSCMw8pO7milZLWVKnop1UJPO0HqM0yce4Jz3NG1EBs7b+VdLleCQygR3A72+nKsC Wn0GtYWS2R+umrpZLsoYzAeGOgmFVQkFTlorwT7D0g8ECUooNZxfLkzpguf30SWkMeZj 44ncTqsfbsjoliJLmwhmmVvbnH1Yxfb+NpL/MTnyoq4aXPU+3J+mnWQx6Q/erULcj/r5 ftclgnpR7RXX5mHrA3xsgr53+9JoJ02UhKKA91x29M1Wr0LM+SkWW7e0L9DUl7sIp8Dq 1k7wcT4vJlVMixmLfbVarRgzre0p1u6tltCJfCE/twJbbnTSaZtHjtbJ3z43A2Q/qAC2 DlSQ== Received: by 10.68.191.130 with SMTP id gy2mr10601669pbc.62.1335839052975; Mon, 30 Apr 2012 19:24:12 -0700 (PDT) Received: from [127.0.0.1] (c-71-236-141-77.hsd1.wa.comcast.net. [71.236.141.77]) by mx.google.com with ESMTPS id 2sm17776427pbw.57.2012.04.30.19.24.09 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 30 Apr 2012 19:24:11 -0700 (PDT) Message-ID: <4F9F4949.20706@gmail.com> Date: Mon, 30 Apr 2012 19:24:09 -0700 From: Darren Pilgrim User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.3) Gecko/20120306 Thunderbird/10.0.3 MIME-Version: 1.0 To: Michael MacLeod References: <4F9E270F.3070605@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Full Cone NAT In PF 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, 01 May 2012 02:24:13 -0000 On 2012-04-30 17:44, Michael MacLeod wrote: > At the end of the day we could solve it by getting our ISP to route a > /29 to their house and using binat (I already have a /29), but it would > be nice if there was the option to use 'nat on $wan_if from -> > ($wan_if) full-cone' in a ruleset to achieve the correct behaviour. Patches welcome. :) Facetiousness aside, you can make the rules more broad, even create "DMZ host" rules on a per-remote-IP basis. If you post your pf.conf (a pastie URI would be best), we can look and see if there's something amiss. From owner-freebsd-net@FreeBSD.ORG Tue May 1 12:35:12 2012 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 A31F6106564A for ; Tue, 1 May 2012 12:35:12 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by mx1.freebsd.org (Postfix) with ESMTP id 5E46F8FC17 for ; Tue, 1 May 2012 12:35:12 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1SPCIP-0002R0-FT for freebsd-net@freebsd.org; Tue, 01 May 2012 14:35:09 +0200 Received: from w4964.dip.tu-dresden.de ([141.76.187.196]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 01 May 2012 14:35:09 +0200 Received: from js by w4964.dip.tu-dresden.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 01 May 2012 14:35:09 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: Julian Stecklina Date: Tue, 01 May 2012 14:34:51 +0200 Lines: 26 Message-ID: <87vckg84gk.fsf@alien8.de> References: <201204251241.04752.zec@fer.hr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: w4964.dip.tu-dresden.de User-Agent: Gnus/5.13 (Gnus v5.13) Cancel-Lock: sha1:M9DRSFIHC2gJnSQMfzTck6VmlbQ= Subject: Re: Intel 10 GbE cards (ixgbe) 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, 01 May 2012 12:35:12 -0000 Thus spake Marko Zec : > Hi all, > > Although the ixgbe driver appears to have code for both 82598 and 82599 > chipsets, the manual page stil lists only 82598 based cards as officially > supported. Does anybody have first-hand experiences with 82599 based cards > and recent versions of the ixgbe driver (-CURRENT, 9.0, 8.3)? We recently bought one: ix0@pci0:34:0:0: class=0x020000 card=0xa02c8086 chip=0x151c8086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82599EB 10 Gigabit TN Network Connection' class = network subclass = ethernet ix1@pci0:34:0:1: class=0x020000 card=0xa02c8086 chip=0x151c8086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82599EB 10 Gigabit TN Network Connection' class = network subclass = ethernet It's currently used on 9.0 for benchmarking another box. Never had any problems. Can someone say whether the X540 support in CURRENT is stable? Regards, Julian From owner-freebsd-net@FreeBSD.ORG Tue May 1 13:09:04 2012 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 C2A27106564A for ; Tue, 1 May 2012 13:09:04 +0000 (UTC) (envelope-from mikemacleod@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 85B318FC0C for ; Tue, 1 May 2012 13:09:04 +0000 (UTC) Received: by iahk25 with SMTP id k25so7642005iah.13 for ; Tue, 01 May 2012 06:09:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=/RabKJNuO61KKfoEYDUEnNuJ+T5MwlAQ/HARxiQhyMA=; b=k/8MkTNByyQRAks92RqoA7RAOIrkvzD+TjPNC3Snmx/UP938j4sWhrS+NcyPWpQPjM KRTmBoPTXocypVurBvaT/QANYxyWkn9wkH8tU9OtsOBVkAI/aNQaqNwI4CXKKrIXR6yU mcMLLw0RXiHBd4MRWyOiTunQNm89cOLJWqLJpuNgoqQO65nMb4QPzO8aIgB97HQniCDb HJgjqTrugtBuAZGTVWV3fY1fz3eOKQsMVehmTa4nXn30sawWkUwFe1qX8xshBwcy/6ER xtDWSQFXpjE3uf05aXUa7Jq5SUkC5UqTSiivu3ezZ99BP0/NUQuqbjQBHfvnptdl0Q9/ AfFA== Received: by 10.50.193.132 with SMTP id ho4mr1712750igc.17.1335877744181; Tue, 01 May 2012 06:09:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.133.6 with HTTP; Tue, 1 May 2012 06:08:44 -0700 (PDT) In-Reply-To: <4F9F4949.20706@gmail.com> References: <4F9E270F.3070605@gmail.com> <4F9F4949.20706@gmail.com> From: Michael MacLeod Date: Tue, 1 May 2012 09:08:44 -0400 Message-ID: To: Darren Pilgrim Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: Full Cone NAT In PF 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, 01 May 2012 13:09:04 -0000 Alright, here's a copy of my pf.conf: http://pastie.org/private/yt7h3erbowgg4pf5v7fh5a As for patches... unfortunately I'm not too sharp with C. On Mon, Apr 30, 2012 at 10:24 PM, Darren Pilgrim wrote: > On 2012-04-30 17:44, Michael MacLeod wrote: > >> At the end of the day we could solve it by getting our ISP to route a >> /29 to their house and using binat (I already have a /29), but it would >> be nice if there was the option to use 'nat on $wan_if from -> >> ($wan_if) full-cone' in a ruleset to achieve the correct behaviour. >> > > Patches welcome. :) > > Facetiousness aside, you can make the rules more broad, even create "DMZ > host" rules on a per-remote-IP basis. If you post your pf.conf (a pastie > URI would be best), we can look and see if there's something amiss. > From owner-freebsd-net@FreeBSD.ORG Tue May 1 14:27:41 2012 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 C4979106566C; Tue, 1 May 2012 14:27:41 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from vps.hungerhost.com (vps.hungerhost.com [216.38.53.176]) by mx1.freebsd.org (Postfix) with ESMTP id 960968FC0A; Tue, 1 May 2012 14:27:41 +0000 (UTC) Received: from [209.249.190.124] (port=56103 helo=[10.2.212.229]) by vps.hungerhost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1SPE3I-0007HC-O8; Tue, 01 May 2012 10:27:40 -0400 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: George Neville-Neil In-Reply-To: <20120420190309.GA5617@onelab2.iet.unipi.it> Date: Tue, 1 May 2012 10:27:42 -0400 Content-Transfer-Encoding: 7bit Message-Id: References: <20120419133018.GA91364@onelab2.iet.unipi.it> <20120420190309.GA5617@onelab2.iet.unipi.it> To: Luigi Rizzo X-Mailer: Apple Mail (2.1257) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - vps.hungerhost.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - neville-neil.com Cc: current@freebsd.org, net@freebsd.org Subject: Re: more network performance info: ether_output() 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, 01 May 2012 14:27:41 -0000 On Apr 20, 2012, at 15:03 , Luigi Rizzo wrote: > Continuing my profiling on network performance, another place > were we waste a lot of time is if_ethersubr.c::ether_output() > > In particular, from the beginning of ether_output() to the > final call to ether_output_frame() the code takes slightly > more than 210ns on my i7-870 CPU running at 2.93 GHz + TurboBoost. > In particular: > > - the route does not have a MAC address (lle) attached, which causes > arpresolve() to be called all the times. This consumes about 100ns. > It happens also with locally sourced TCP. > Using the flowtable cuts this time down to about 30-40ns > > - another 100ns is spend to copy the MAC header into the mbuf, > and then check whether a local copy should be looped back. > Unfortunately the code here is a bit convoluted so the > header fields are copied twice, and using memcpy on the > individual pieces. > > Note that all the above happens not just with my udp flooding > tests, but also with regular TCP traffic. Hi Luigi, I'm really glad you're working on this. I may have missed this in a thread but are you tracking these somewhere so we can pick them up and fix them? Also, how are you doing the measurements. Sorry, if these have been answered before. Best, George From owner-freebsd-net@FreeBSD.ORG Tue May 1 15:20:48 2012 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 2AF41106564A; Tue, 1 May 2012 15:20:48 +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 DBF5A8FC16; Tue, 1 May 2012 15:20:47 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id A54C87300A; Tue, 1 May 2012 17:40:31 +0200 (CEST) Date: Tue, 1 May 2012 17:40:31 +0200 From: Luigi Rizzo To: George Neville-Neil Message-ID: <20120501154031.GB80942@onelab2.iet.unipi.it> References: <20120419133018.GA91364@onelab2.iet.unipi.it> <20120420190309.GA5617@onelab2.iet.unipi.it> 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: current@freebsd.org, net@freebsd.org Subject: Re: more network performance info: ether_output() 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, 01 May 2012 15:20:48 -0000 On Tue, May 01, 2012 at 10:27:42AM -0400, George Neville-Neil wrote: > > On Apr 20, 2012, at 15:03 , Luigi Rizzo wrote: > > > Continuing my profiling on network performance, another place > > were we waste a lot of time is if_ethersubr.c::ether_output() > > > > In particular, from the beginning of ether_output() to the > > final call to ether_output_frame() the code takes slightly > > more than 210ns on my i7-870 CPU running at 2.93 GHz + TurboBoost. > > In particular: > > > > - the route does not have a MAC address (lle) attached, which causes > > arpresolve() to be called all the times. This consumes about 100ns. > > It happens also with locally sourced TCP. > > Using the flowtable cuts this time down to about 30-40ns > > > > - another 100ns is spend to copy the MAC header into the mbuf, > > and then check whether a local copy should be looped back. > > Unfortunately the code here is a bit convoluted so the > > header fields are copied twice, and using memcpy on the > > individual pieces. > > > > Note that all the above happens not just with my udp flooding > > tests, but also with regular TCP traffic. > > Hi Luigi, > > I'm really glad you're working on this. I may have missed this in a thread > but are you tracking these somewhere so we can pick them up and fix them? > > Also, how are you doing the measurements. The measurements are done with tools/tools/netrate/netsend and kernel patches to return from sendto() at various places in the stack (from the syscall entry point down to the device driver). A patch is attached. You don't really need netmap to run it, it was just a convenient place to put the variables. I am not sure how much we can "fix", there are multiple expensive functions on the tx path, and probably also on the rx path. My hope at least for the tx path is that we can find out a way to install a "fastpath" handler in the socket. When there is no handler installed (e.g. on the first packet or unsupported protocols/interfaces) everything works as usual. Then when the packet reaches the bottom of the stack, we try to update the socket with a copy of the headers generated in the process, and the name of the fastpath function to be called. Next transmissions will then be able to shortcut the stack and go straight to the device output routine. I don't have data on the receive path or good ideas on how to proceed -- the advantage of the tx path is that traffic is implicitly classified, whereas it might not be the case for incoming traffic, and classification might be the expensive step. Hopefully we'll have time to discuss this next week in ottawa. cheers luigi From owner-freebsd-net@FreeBSD.ORG Tue May 1 15:42:46 2012 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 1D5181065670 for ; Tue, 1 May 2012 15:42:46 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id A32D78FC17 for ; Tue, 1 May 2012 15:42:45 +0000 (UTC) Received: by wgbds12 with SMTP id ds12so337632wgb.31 for ; Tue, 01 May 2012 08:42:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=O3F47BTsWpX/bz1Lpwpsyj+Fn2f6b9VRmSGzCvI6xug=; b=pFJR+UHxXgBZwxw/lCVSxJ8RfP9aWXV7qHWsYhjKulT3u+dS3hhISSuA/T/BvpwN5d f0E2aKen9zX5BNSDODzWQdYrMI5jh3x4Vz96mQGgz29exRAOehTMcZ7wFq4D7PP7xQHt 3ctgLTA9gd3/htvh3jGlWdS0JWuCZETcEZnifSsR0LgdkU0UoMXHT2OndQ18az6TwtP1 5QtWyaBUaPm3X0ER1xV/GFudH2Ubz54G7S1FJlwjwqpjFsZqcAj5Y47auDQuSrnjfy6B R99ICofdAZd7ITf3Hk1pHFLOfalQhW6w65fBY73t6kyAssTCI2x9AfmNOxrXsh0mGAkq K7Sg== MIME-Version: 1.0 Received: by 10.216.137.22 with SMTP id x22mr2201550wei.69.1335886958902; Tue, 01 May 2012 08:42:38 -0700 (PDT) Received: by 10.180.7.103 with HTTP; Tue, 1 May 2012 08:42:38 -0700 (PDT) In-Reply-To: <87vckg84gk.fsf@alien8.de> References: <201204251241.04752.zec@fer.hr> <87vckg84gk.fsf@alien8.de> Date: Tue, 1 May 2012 08:42:38 -0700 Message-ID: From: Jack Vogel To: Julian Stecklina Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: Intel 10 GbE cards (ixgbe) 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, 01 May 2012 15:42:46 -0000 The 82599 is and has been officially supported for some time, the manual tends to lag, I will try and get it updated. In fact, given a choice I would always go with the 599. And yes, the X540 should be stable, its just not yet being used as much yet. Jack On Tue, May 1, 2012 at 5:34 AM, Julian Stecklina wrote: > Thus spake Marko Zec : > > > Hi all, > > > > Although the ixgbe driver appears to have code for both 82598 and 82599 > > chipsets, the manual page stil lists only 82598 based cards as officially > > supported. Does anybody have first-hand experiences with 82599 based > cards > > and recent versions of the ixgbe driver (-CURRENT, 9.0, 8.3)? > > We recently bought one: > > ix0@pci0:34:0:0: class=0x020000 card=0xa02c8086 chip=0x151c8086 > rev=0x01 hdr=0x00 > vendor = 'Intel Corporation' > device = '82599EB 10 Gigabit TN Network Connection' > class = network > subclass = ethernet > ix1@pci0:34:0:1: class=0x020000 card=0xa02c8086 chip=0x151c8086 > rev=0x01 hdr=0x00 > vendor = 'Intel Corporation' > device = '82599EB 10 Gigabit TN Network Connection' > class = network > subclass = ethernet > > It's currently used on 9.0 for benchmarking another box. Never had any > problems. Can someone say whether the X540 support in CURRENT is stable? > > Regards, Julian > > _______________________________________________ > 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 May 1 16:21:33 2012 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 54493106566B; Tue, 1 May 2012 16:21:33 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 960718FC0A; Tue, 1 May 2012 16:21:32 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q41GLMnn066883; Tue, 1 May 2012 19:21:22 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q41GLLSn048871; Tue, 1 May 2012 19:21:21 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q41GLLwr048870; Tue, 1 May 2012 19:21:21 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 1 May 2012 19:21:21 +0300 From: Konstantin Belousov To: net@freebsd.org Message-ID: <20120501162121.GV2358@deviant.kiev.zoral.com.ua> References: <20120407133715.GU2358@deviant.kiev.zoral.com.ua> <20120408051125.GA2358@deviant.kiev.zoral.com.ua> <201204091219.39580.jhb@freebsd.org> <20120412183849.GA2358@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qBJg7ibC5PRC7M9v" Content-Disposition: inline In-Reply-To: <20120412183849.GA2358@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: jfv@freebsd.org, Jack Vogel , John Baldwin Subject: Re: 82574L hangs (with r233708 e1000 driver). X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 16:21:33 -0000 --qBJg7ibC5PRC7M9v Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Apr 12, 2012 at 09:38:49PM +0300, Konstantin Belousov wrote: > On Mon, Apr 09, 2012 at 12:19:39PM -0400, John Baldwin wrote: > > On Sunday, April 08, 2012 1:11:25 am Konstantin Belousov wrote: > > > On Sat, Apr 07, 2012 at 04:22:07PM -0700, Jack Vogel wrote: > > > > Make sure you have any firmware up to the latest available, if that= doesn't > > > > help > > > > let me know and I'll check internally to see if there are any outst= anding > > > > issues > > > > in shared code, that will be after the weekend. > > >=20 > > > I had BIOS rev. 151, after you hint I found rev. 154 on the site. > > > Now BIOS reports itself as MTCDT10N.86A.0154.2012.0323.1601, > > > March 23. > > >=20 > > > Unfortunately, upgrade did not changed anything in regard of hanging > > > interface. > >=20 > > Does reverting 233708 make any difference? Have you tried futzing arou= nd with > > kgdb when it is hung to see what state the device is in (software state= at > > least)? > It does, in a sense that without r233708 the interface becomes stuck > almost immediately. I just upgraded to the e1000@r234154, which does not > change much. >=20 > I fiddled with the adapter state after the hang in kgdb more, and I > noted something interesting. Apparently, tx works. When I ping the remote > host from my suffering atom machine, remote host sees the packet. Also > remote machine sees some udp traffic originating from the tom, like > ntp queries. >=20 > And, on receive, the atom board does receive interrupts, em0:rx 0 counter > in vmstat -i increases. Even more fun, the sysctl dev.em.0.debug > shows increasing hw rdh (as I understand, this is hardware 'last > received' packet pointer for rx ring). So I looked at the packet > descriptor at hw rdt index, and there I see > (kgdb) p/x ((struct adapter *)0xffffff80010e4000)->rx_rings->rx_base[78] > $11 =3D {buffer_addr =3D 0x12a128800, length =3D 0x5ea, csum =3D 0x3c2b, = status =3D 0x0,=20 > errors =3D 0x0, special =3D 0x0} >=20 > Apparently, the Descriptor Done bit is clear, so the em_rxeof() function > breaks from the loop, not consuming the current packet. Also, it returns > false due to DD bit clear. This prevents em_msix_rx() from scheduling > taskqueue for processing. So apparent cause for the hang is missing > DD bit in descriptor. >=20 > I am not sure isn't all this is obvious for anybody who knows em > internals, and were to go from there. Ok, nobody cares. Below is the workaround I use to prevent the interface wedging. It seems that the sole PCI register read (namely, the rx ring head read) and consequent recheck of the descriptor status greatly reduce the likelihood of the issue. Unfortunately, the read does not eliminate the hang completely. So it is not some PCIe coherency problem. With the patch applied, I am able to copy around blu-ray images, while previously the interface hang in 20-30 seconds of 100Mbit/s traffic. Sometimes the messages are printed: em0: Workaround: head 1018 tail 1002 cur 1010 em0: Workaround: head 976 tail 973 cur 974 em0: Workaround: head 950 tail 939 cur 946 em0: Workaround: head 435 tail 419 cur 426 Machine is still dead due to random memory corruption which I see, in particular, pmap sometimes read garbage from PTEs. I have no idea is it related to em0 rx descriptor missed writes, or is a different issue. diff --git a/sys/dev/e1000/if_em.c b/sys/dev/e1000/if_em.c index 9c31dad..b2e76cc 100644 --- a/sys/dev/e1000/if_em.c +++ b/sys/dev/e1000/if_em.c @@ -335,6 +335,11 @@ MODULE_DEPEND(em, ether, 1, 1, 1); =20 static SYSCTL_NODE(_hw, OID_AUTO, em, CTLFLAG_RD, 0, "EM driver parameters= "); =20 +static int em_rx_workaround; +TUNABLE_INT("hw.em.rx_workaround", &em_rx_workaround); +SYSCTL_INT(_hw_em, OID_AUTO, rx_workaround, CTLFLAG_RDTUN, &em_rx_workarou= nd, + 0, "Activate workaround for missed DD in rx ring"); + static int em_tx_int_delay_dflt =3D EM_TICKS_TO_USECS(EM_TIDV); static int em_rx_int_delay_dflt =3D EM_TICKS_TO_USECS(EM_RDTR); TUNABLE_INT("hw.em.tx_int_delay", &em_tx_int_delay_dflt); @@ -4422,14 +4427,60 @@ em_rxeof(struct rx_ring *rxr, int count, int *done) status =3D cur->status; mp =3D sendmp =3D NULL; =20 - if ((status & E1000_RXD_STAT_DD) =3D=3D 0) + if ((status & E1000_RXD_STAT_DD) =3D=3D 0) { + /* + * From PCI/PCI-X Family of Gigabit Ethernet + * Controllers Software Developer's Manual, + * rev. 2.5, p. 306. + * + * Reading the descriptor head to determine + * which buffers are finished is not reliable. + */ + if (em_rx_workaround) { + int head, next; + + head =3D E1000_READ_REG(&adapter->hw, + E1000_RDH(rxr->me)); + next =3D i + 1; + if (next =3D=3D adapter->num_rx_desc) + next =3D 0; + if (next =3D=3D head) + break; + /* + * Re-read the status for the typical + * case of head advanced due to + * received packet. + */ + status =3D cur->status; + if ((status & E1000_RXD_STAT_DD) !=3D 0) + continue; + /* + * Be extra-paranoid and only activate + * the workaround if the next + * descriptor in the rx ring has the + * Descriptor Done bit set, which + * clearly indicates missed write to + * the current descriptor status. + */ + if ((rxr->rx_base[next].status & + E1000_RXD_STAT_DD) =3D=3D 0) + break; + eop =3D 1; /* XXX */ + device_printf(adapter->dev, + "Workaround: head %d tail %d cur %d\n", + head, E1000_READ_REG(&adapter->hw, + E1000_RDT(rxr->me)), i); + goto boom; + } break; + } =20 len =3D le16toh(cur->length); eop =3D (status & E1000_RXD_STAT_EOP) !=3D 0; =20 if ((cur->errors & E1000_RXD_ERR_FRAME_ERR_MASK) || (rxr->discard =3D=3D TRUE)) { +boom: ifp->if_ierrors++; ++rxr->rx_discarded; if (!eop) /* Catch subsequent segs */ --qBJg7ibC5PRC7M9v Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk+gDYEACgkQC3+MBN1Mb4hRNgCeL3KZ+GwLgQ6GFG6Cb6Du46bO JJEAmgNkddwterImVF2VjVwmBcqg9cpd =lTt9 -----END PGP SIGNATURE----- --qBJg7ibC5PRC7M9v-- From owner-freebsd-net@FreeBSD.ORG Tue May 1 17:10:12 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6F3B91065672 for ; Tue, 1 May 2012 17:10:12 +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 417758FC0C for ; Tue, 1 May 2012 17:10:12 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q41HACjA077076 for ; Tue, 1 May 2012 17:10:12 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q41HACc2077075; Tue, 1 May 2012 17:10:12 GMT (envelope-from gnats) Date: Tue, 1 May 2012 17:10:12 GMT Message-Id: <201205011710.q41HACc2077075@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Ed Maste Cc: Subject: kern/138620 [patch] Sysctl for direct BPF writes to lagg child ports X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Ed Maste List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 17:10:12 -0000 The following reply was made to PR kern/138620; it has been noted by GNATS. From: Ed Maste To: , Cc: Subject: kern/138620 [patch] Sysctl for direct BPF writes to lagg child ports Date: Tue, 1 May 2012 13:08:01 -0400 --jRHKVT23PllUwdXP Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline The attached patch adds a sysctl to enable or disable the behaviour you're looking for (direct BPF writes to the underlying lagg child ports). I intend to commit it shortly after review / test. --jRHKVT23PllUwdXP Content-Type: text/plain; charset="us-ascii" Content-Disposition: attachment; filename="if_lagg.c.diff" Index: if_lagg.c =================================================================== --- if_lagg.c (revision 234896) +++ if_lagg.c (working copy) @@ -177,6 +177,10 @@ SYSCTL_INT(_net_link_lagg, OID_AUTO, default_use_flowid, CTLFLAG_RW, &def_use_flowid, 0, "Default setting for using flow id for load sharing"); +static int lagg_tx_child = 0; /* Direct tx to child interface */ +SYSCTL_INT(_net_link_lagg, OID_AUTO, lagg_tx_child, CTLFLAG_RW, + &lagg_tx_child, 0, + "Allow direct writes to child ports (e.g. via BPF)"); static int lagg_modevent(module_t mod, int type, void *data) @@ -764,6 +768,9 @@ return (EINVAL); } +/* + * For direct output to child ports. + */ static int lagg_port_output(struct ifnet *ifp, struct mbuf *m, struct sockaddr *dst, struct route *ro) @@ -775,6 +782,8 @@ switch (dst->sa_family) { case pseudo_AF_HDRCMPLT: case AF_UNSPEC: + if (lagg_tx_child) + goto sendit; eh = (struct ether_header *)dst->sa_data; type = eh->ether_type; break; @@ -786,12 +795,15 @@ */ switch (ntohs(type)) { case ETHERTYPE_PAE: /* EAPOL PAE/802.1x */ - return ((*lp->lp_output)(ifp, m, dst, ro)); + goto sendit; } /* drop any other frames */ m_freem(m); return (EBUSY); + +sendit: + return ((*lp->lp_output)(ifp, m, dst, ro)); } static void --jRHKVT23PllUwdXP-- From owner-freebsd-net@FreeBSD.ORG Tue May 1 17:34:11 2012 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 D2C251065670; Tue, 1 May 2012 17:34:11 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from vps.hungerhost.com (vps.hungerhost.com [216.38.53.176]) by mx1.freebsd.org (Postfix) with ESMTP id 8A8158FC17; Tue, 1 May 2012 17:34:11 +0000 (UTC) Received: from [209.249.190.124] (port=59026 helo=[10.2.212.229]) by vps.hungerhost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1SPGxm-0005n9-MF; Tue, 01 May 2012 13:34:10 -0400 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: George Neville-Neil In-Reply-To: <20120501154031.GB80942@onelab2.iet.unipi.it> Date: Tue, 1 May 2012 13:34:12 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <265D6A39-2F35-4D31-91EF-16146E77E92E@neville-neil.com> References: <20120419133018.GA91364@onelab2.iet.unipi.it> <20120420190309.GA5617@onelab2.iet.unipi.it> <20120501154031.GB80942@onelab2.iet.unipi.it> To: Luigi Rizzo X-Mailer: Apple Mail (2.1257) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - vps.hungerhost.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - neville-neil.com Cc: current@freebsd.org, net@freebsd.org Subject: Re: more network performance info: ether_output() 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, 01 May 2012 17:34:12 -0000 On May 1, 2012, at 11:40 , Luigi Rizzo wrote: > On Tue, May 01, 2012 at 10:27:42AM -0400, George Neville-Neil wrote: >>=20 >> On Apr 20, 2012, at 15:03 , Luigi Rizzo wrote: >>=20 >>> Continuing my profiling on network performance, another place >>> were we waste a lot of time is if_ethersubr.c::ether_output() >>>=20 >>> In particular, from the beginning of ether_output() to the >>> final call to ether_output_frame() the code takes slightly >>> more than 210ns on my i7-870 CPU running at 2.93 GHz + TurboBoost. >>> In particular: >>>=20 >>> - the route does not have a MAC address (lle) attached, which causes >>> arpresolve() to be called all the times. This consumes about 100ns. >>> It happens also with locally sourced TCP. >>> Using the flowtable cuts this time down to about 30-40ns >>>=20 >>> - another 100ns is spend to copy the MAC header into the mbuf, >>> and then check whether a local copy should be looped back. >>> Unfortunately the code here is a bit convoluted so the >>> header fields are copied twice, and using memcpy on the >>> individual pieces. >>>=20 >>> Note that all the above happens not just with my udp flooding >>> tests, but also with regular TCP traffic. >>=20 >> Hi Luigi, >>=20 >> I'm really glad you're working on this. I may have missed this in a = thread >> but are you tracking these somewhere so we can pick them up and fix = them? >>=20 >> Also, how are you doing the measurements. >=20 > The measurements are done with tools/tools/netrate/netsend and > kernel patches to return from sendto() at various places in the > stack (from the syscall entry point down to the device driver). > A patch is attached. You don't really need netmap to run it, > it was just a convenient place to put the variables. >=20 > I am not sure how much we can "fix", there are multiple expensive > functions on the tx path, and probably also on the rx path. >=20 > My hope at least for the tx path is that we can find out a way to = install a > "fastpath" handler in the socket. > When there is no handler installed (e.g. on the first packet or > unsupported protocols/interfaces) everything works as usual. Then > when the packet reaches the bottom of the stack, we try to update > the socket with a copy of the headers generated in the process, and > the name of the fastpath function to be called. Next transmissions > will then be able to shortcut the stack and go straight to the > device output routine. >=20 > I don't have data on the receive path or good ideas on how to proceed = -- the > advantage of the tx path is that traffic is implicitly classified, > whereas it might not be the case for incoming traffic, and = classification > might be the expensive step. >=20 > Hopefully we'll have time to discuss this next week in ottawa. Yes, I think we should. Best, George From owner-freebsd-net@FreeBSD.ORG Tue May 1 17:47:10 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7767D106566B for ; Tue, 1 May 2012 17:47:10 +0000 (UTC) (envelope-from sodynet1@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 397148FC16 for ; Tue, 1 May 2012 17:47:10 +0000 (UTC) Received: by obcni5 with SMTP id ni5so7274690obc.13 for ; Tue, 01 May 2012 10:47:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BYr7miUm8OK3PsUHaAmKzhsZuX3LLB7BizDqkzUkOxQ=; b=vx4nMEvYHYWfOENVi6kG/8/2AWZiH3Z1pRlZNW8WaVZMk7M9zcFjT8tlw8oRTZyMNK wTzYo8t9S+nVyhW7Ahsv45CZFa3KRwrGxCQECNrY02aTY9sf0Twqc4VVOjhN7IzGShQ4 ikx/B7a664POfh5RA1oQvEubrTmHIUz/8GTxlFUXz1ci/sapk8ytZHClZQI2ELKvka46 TSdIxDd4w01+aEfIWtbW7dY52j5Zqmg/IiErBnP+woTMSz894WFIe9EELgYbl3Ly2ZZp MeVGuXz5d8YIjeJoKaVN1s799UjaT3FDTnpgdHwalKTb65vozrBh3BMGIaQ7pfjzUwkc L0Ag== MIME-Version: 1.0 Received: by 10.60.9.232 with SMTP id d8mr6645781oeb.66.1335894429833; Tue, 01 May 2012 10:47:09 -0700 (PDT) Received: by 10.182.166.100 with HTTP; Tue, 1 May 2012 10:47:09 -0700 (PDT) In-Reply-To: References: <201204251241.04752.zec@fer.hr> <87vckg84gk.fsf@alien8.de> Date: Tue, 1 May 2012 20:47:09 +0300 Message-ID: From: Sami Halabi To: Jack Vogel Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, Julian Stecklina Subject: Re: Intel 10 GbE cards (ixgbe) 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, 01 May 2012 17:47:10 -0000 x540has no fbsd driver Sami On Tue, May 1, 2012 at 6:42 PM, Jack Vogel wrote: > The 82599 is and has been officially supported for some time, the manual > tends to lag, I will try and get it updated. In fact, given a choice I > would always > go with the 599. And yes, the X540 should be stable, its just not yet being > used as much yet. > > Jack > > > On Tue, May 1, 2012 at 5:34 AM, Julian Stecklina wrote: > > > Thus spake Marko Zec : > > > > > Hi all, > > > > > > Although the ixgbe driver appears to have code for both 82598 and 82599 > > > chipsets, the manual page stil lists only 82598 based cards as > officially > > > supported. Does anybody have first-hand experiences with 82599 based > > cards > > > and recent versions of the ixgbe driver (-CURRENT, 9.0, 8.3)? > > > > We recently bought one: > > > > ix0@pci0:34:0:0: class=0x020000 card=0xa02c8086 chip=0x151c8086 > > rev=0x01 hdr=0x00 > > vendor = 'Intel Corporation' > > device = '82599EB 10 Gigabit TN Network Connection' > > class = network > > subclass = ethernet > > ix1@pci0:34:0:1: class=0x020000 card=0xa02c8086 chip=0x151c8086 > > rev=0x01 hdr=0x00 > > vendor = 'Intel Corporation' > > device = '82599EB 10 Gigabit TN Network Connection' > > class = network > > subclass = ethernet > > > > It's currently used on 9.0 for benchmarking another box. Never had any > > problems. Can someone say whether the X540 support in CURRENT is stable? > > > > Regards, Julian > > > > _______________________________________________ > > 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" > -- Sami Halabi Information Systems Engineer NMS Projects Expert From owner-freebsd-net@FreeBSD.ORG Tue May 1 18:06:23 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2E7C9106564A for ; Tue, 1 May 2012 18:06:23 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by mx1.freebsd.org (Postfix) with ESMTP id AFEE28FC1E for ; Tue, 1 May 2012 18:06:22 +0000 (UTC) Received: by wibhj6 with SMTP id hj6so3127717wib.13 for ; Tue, 01 May 2012 11:06:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xGvDBNCYxs555ih536nLlb6VyCtCm45ghIczY7NVlk4=; b=GHej6byLUn9rtQ7GRAdTIWEBWly+KGXOsGWfg1kwzmXUdYyTqWFsOASKvg+mP6Hblr ln8lz9hXepEHykoisvRZeuT0/p6oAOW7hyM6RqIv20psYwCoBuw+HY/nhH6BgQQ6023F 8VgjkE8mn/peckL7TtRvztOdSDewYcWgc7p/SgoJJfAPzVhrlrmNnf2rN/bHaltvxown kMCmmGhFz0+SME/xTfJ6wyKUIqYQgWhEOBKeZNK5z14pcU2MwXerxIyLJ5JVIkr3OKkM EgGEKYEpa8XUa838Lzr7J8IMZllfd+qJRRTwTfwMdQQYUHOGJutW+STPseAQFHriaYcR ZWYA== MIME-Version: 1.0 Received: by 10.180.24.35 with SMTP id r3mr6978846wif.7.1335895581701; Tue, 01 May 2012 11:06:21 -0700 (PDT) Received: by 10.180.7.103 with HTTP; Tue, 1 May 2012 11:06:21 -0700 (PDT) In-Reply-To: References: <201204251241.04752.zec@fer.hr> <87vckg84gk.fsf@alien8.de> Date: Tue, 1 May 2012 11:06:21 -0700 Message-ID: From: Jack Vogel To: Sami Halabi Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, Julian Stecklina Subject: Re: Intel 10 GbE cards (ixgbe) 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, 01 May 2012 18:06:23 -0000 Funny, since I own the driver, one would think I'd know :) If you go look in the source directory for ixgbe you'll find a couple files in there: ixgbe_x540.[ch]. That should be a clue... Jack On Tue, May 1, 2012 at 10:47 AM, Sami Halabi wrote: > x540has no fbsd driver > > Sami > > > On Tue, May 1, 2012 at 6:42 PM, Jack Vogel wrote: > >> The 82599 is and has been officially supported for some time, the manual >> tends to lag, I will try and get it updated. In fact, given a choice I >> would always >> go with the 599. And yes, the X540 should be stable, its just not yet >> being >> used as much yet. >> >> Jack >> >> >> On Tue, May 1, 2012 at 5:34 AM, Julian Stecklina wrote: >> >> > Thus spake Marko Zec : >> > >> > > Hi all, >> > > >> > > Although the ixgbe driver appears to have code for both 82598 and >> 82599 >> > > chipsets, the manual page stil lists only 82598 based cards as >> officially >> > > supported. Does anybody have first-hand experiences with 82599 based >> > cards >> > > and recent versions of the ixgbe driver (-CURRENT, 9.0, 8.3)? >> > >> > We recently bought one: >> > >> > ix0@pci0:34:0:0: class=0x020000 card=0xa02c8086 chip=0x151c8086 >> > rev=0x01 hdr=0x00 >> > vendor = 'Intel Corporation' >> > device = '82599EB 10 Gigabit TN Network Connection' >> > class = network >> > subclass = ethernet >> > ix1@pci0:34:0:1: class=0x020000 card=0xa02c8086 chip=0x151c8086 >> > rev=0x01 hdr=0x00 >> > vendor = 'Intel Corporation' >> > device = '82599EB 10 Gigabit TN Network Connection' >> > class = network >> > subclass = ethernet >> > >> > It's currently used on 9.0 for benchmarking another box. Never had any >> > problems. Can someone say whether the X540 support in CURRENT is stable? >> > >> > Regards, Julian >> > >> > _______________________________________________ >> > 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" >> > > > > -- > Sami Halabi > Information Systems Engineer > NMS Projects Expert > > From owner-freebsd-net@FreeBSD.ORG Tue May 1 18:10:27 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B017C1065689 for ; Tue, 1 May 2012 18:10:27 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 39EBD8FC1B for ; Tue, 1 May 2012 18:10:27 +0000 (UTC) Received: by wgbds12 with SMTP id ds12so455287wgb.31 for ; Tue, 01 May 2012 11:10:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=SpzmdEG63NopESO6uxuRIbhBgNWuEFymP4gupiyFGhE=; b=KUoJKE82q3Ja7QtUrrGU/4FEFPhf6QRWzc9RgoOPxMaG44arnMarGpdt/NrmN+h8ks 5wTalyQHz8CIU/sdYamYGrRPSR5EZ1O6oFzbc8vJPRruztKSUpGiRmlk8+gIbN2hHUud CJImLDWTmgrc4UzjfB9Fow7apHyxWuq/kuR+7yq+7no6P/f5nzQkFnYBtzmIdaQJ6Lqg 8TN59dcowqcbtpUsy6dYqPavpHuuRgsCNTJgRSlf0bQmwcJmzRvD+8BOMmTB/VDOiPP0 vcNTkzgD0ev8j+zxv7CzGTvZj4MB3iS26eH2l/JMGKAI3uKh825X1gMXXjDYGnpQYDMa iLbQ== MIME-Version: 1.0 Received: by 10.180.24.35 with SMTP id r3mr7002746wif.7.1335895826185; Tue, 01 May 2012 11:10:26 -0700 (PDT) Received: by 10.180.7.103 with HTTP; Tue, 1 May 2012 11:10:26 -0700 (PDT) In-Reply-To: References: <201204251241.04752.zec@fer.hr> <87vckg84gk.fsf@alien8.de> Date: Tue, 1 May 2012 11:10:26 -0700 Message-ID: From: Jack Vogel To: Sami Halabi Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, Julian Stecklina Subject: Re: Intel 10 GbE cards (ixgbe) 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, 01 May 2012 18:10:27 -0000 Just so everyone is clear, the ixgbe driver in 8.3 has X540 support, as well as HEAD, stable/9 has not yet been MFC'd, its on my 'todo' list. Jack On Tue, May 1, 2012 at 11:06 AM, Jack Vogel wrote: > Funny, since I own the driver, one would think I'd know :) > > If you go look in the source directory for ixgbe you'll find a couple files > in there: ixgbe_x540.[ch]. That should be a clue... > > Jack > > > > On Tue, May 1, 2012 at 10:47 AM, Sami Halabi wrote: > >> x540has no fbsd driver >> >> Sami >> >> >> On Tue, May 1, 2012 at 6:42 PM, Jack Vogel wrote: >> >>> The 82599 is and has been officially supported for some time, the manual >>> tends to lag, I will try and get it updated. In fact, given a choice I >>> would always >>> go with the 599. And yes, the X540 should be stable, its just not yet >>> being >>> used as much yet. >>> >>> Jack >>> >>> >>> On Tue, May 1, 2012 at 5:34 AM, Julian Stecklina wrote: >>> >>> > Thus spake Marko Zec : >>> > >>> > > Hi all, >>> > > >>> > > Although the ixgbe driver appears to have code for both 82598 and >>> 82599 >>> > > chipsets, the manual page stil lists only 82598 based cards as >>> officially >>> > > supported. Does anybody have first-hand experiences with 82599 based >>> > cards >>> > > and recent versions of the ixgbe driver (-CURRENT, 9.0, 8.3)? >>> > >>> > We recently bought one: >>> > >>> > ix0@pci0:34:0:0: class=0x020000 card=0xa02c8086 chip=0x151c8086 >>> > rev=0x01 hdr=0x00 >>> > vendor = 'Intel Corporation' >>> > device = '82599EB 10 Gigabit TN Network Connection' >>> > class = network >>> > subclass = ethernet >>> > ix1@pci0:34:0:1: class=0x020000 card=0xa02c8086 chip=0x151c8086 >>> > rev=0x01 hdr=0x00 >>> > vendor = 'Intel Corporation' >>> > device = '82599EB 10 Gigabit TN Network Connection' >>> > class = network >>> > subclass = ethernet >>> > >>> > It's currently used on 9.0 for benchmarking another box. Never had any >>> > problems. Can someone say whether the X540 support in CURRENT is >>> stable? >>> > >>> > Regards, Julian >>> > >>> > _______________________________________________ >>> > 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" >>> >> >> >> >> -- >> Sami Halabi >> Information Systems Engineer >> NMS Projects Expert >> >> > From owner-freebsd-net@FreeBSD.ORG Tue May 1 18:13:10 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CF139106567B for ; Tue, 1 May 2012 18:13:10 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from nm34-vm3.bullet.mail.ne1.yahoo.com (nm34-vm3.bullet.mail.ne1.yahoo.com [98.138.229.83]) by mx1.freebsd.org (Postfix) with SMTP id 7EB968FC12 for ; Tue, 1 May 2012 18:13:10 +0000 (UTC) Received: from [98.138.90.56] by nm34.bullet.mail.ne1.yahoo.com with NNFMP; 01 May 2012 18:13:04 -0000 Received: from [98.138.89.246] by tm9.bullet.mail.ne1.yahoo.com with NNFMP; 01 May 2012 18:13:04 -0000 Received: from [127.0.0.1] by omp1060.mail.ne1.yahoo.com with NNFMP; 01 May 2012 18:13:03 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 997636.72044.bm@omp1060.mail.ne1.yahoo.com Received: (qmail 92156 invoked by uid 60001); 1 May 2012 18:13:03 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1335895983; bh=fAoefYrbc0os7GZz6pkiZFujACZeWeqdlwZciTEzxbE=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=0TozZCoFzJE/JdUk9Dd39MRXlzS07a5xb4N8tOQorydfjgQs3Ziit2KYV56IFOdTagdeWhnnuCYwPDkohCC8H9qgjR7n1SxcSTS0su0fvD10QqQPwQHlfh7Yt/FYcbHxExoIOddqzi+T3BZ8YJTI2pJx2q5h7z13MZELcEc1Oho= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=LBfvWjRJjxVGHpO/7CVNlyOpMgUMXNuX8q2Jt8iLvh6VnsPlLCrvxAKNBfyUdPXMCHlsMp+G5gAw4SM9jp2NgAwAxOsbmV9LTnI6EKjLu9/k078O0RpyUKGDEx+qP3Fqqp0UHjud9ygxNJ30sb7OYsuklNm/mAyfwwWM1tJbBOo=; X-YMail-OSG: lBs4cM0VM1mJ6jzvkTqokX8lQklIcAxuKTpVoo57XDuswfh VhKDrVAmhY76l0HdRT02BzbMGrfUGm9kzmGSbdgbB_O4Ce1U7KUpygnSyGur 3NwnQanw8zCrrxYDAEtVnnB5s8xtImjQb4ZaeVAB6zbX4jW5LtDZP4tCHkOd 3UDiRuJIeJ2tEtfAkuPzpzyxVadfXGxkJQw7FeegGbDanSqlX0RbBBnSNR.I 7iKMHkvrT0tSLOYAHn1i5rYp47haNbuwMv9zRyT3.hqEbsw80OegVmb7PGra itfrEBdQAz5TR46D7Wy9ZRYBix0sV5opLFCstyPkB4BtkWi_VpJYjtXWoyGF 3F5g.GyeEPyX1IQHbxNY9Cm7e.F6xrwTaCBn2JM8oZQPw.LFTt7E7QLJPi9s Hb2upJC8DiRjIKpWdeP3.kFj3Oq4JsjqdWZxUHAYz3L_G4iooNdwVR6vBy.Y .df9zbw8A.eWvOPQ2JkjmTbFVtqBGkURN018- Received: from [174.48.129.108] by web126001.mail.ne1.yahoo.com via HTTP; Tue, 01 May 2012 11:13:03 PDT X-Mailer: YahooMailClassic/15.0.6 YahooMailWebService/0.8.117.340979 Message-ID: <1335895983.68943.YahooMailClassic@web126001.mail.ne1.yahoo.com> Date: Tue, 1 May 2012 11:13:03 -0700 (PDT) From: Barney Cordoba To: Sean Bruno , Juli Mallett In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-net@freebsd.org" Subject: Re: igb(4) at peak in big purple 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, 01 May 2012 18:13:10 -0000 =0A=0A--- On Fri, 4/27/12, Juli Mallett wrote:=0A=0A= > From: Juli Mallett =0A> Subject: Re: igb(4) at peak= in big purple=0A> To: "Sean Bruno" =0A> Cc: "freebs= d-net@freebsd.org" =0A> Date: Friday, April 27, 20= 12, 4:00 PM=0A> On Fri, Apr 27, 2012 at 12:29, Sean=0A> Bruno =0A> wrote:=0A> > On Thu, 2012-04-26 at 11:13 -0700, Juli Mallett= wrote:=0A> >> Queue splitting in Intel cards is done using a hash=0A> of p= rotocol=0A> >> headers, so this is expected behavior. =A0This also=0A> help= s with TCP and=0A> >> UDP performance, in terms of keeping packets for=0A> = the same protocol=0A> >> control block on the same core, but for other=0A> = applications it's not=0A> >> ideal. =A0If your application does not require= that=0A> kind of locality,=0A> >> there are things that can be done in the= driver to=0A> make it easier to=0A> >> balance packets between all queues = about-evenly.=0A> >=0A> > Oh? :-)=0A> >=0A> > What should I be looking at t= o balance more evenly?=0A> =0A> Dirty hacks are involved :)=A0 I've sent so= me code to=0A> Luigi that I think=0A> would make sense in netmap (since for= many tasks one's going=0A> to do=0A> with netmap, you want to use as many = cores as possible, and=0A> maybe=0A> don't care about locality so much) but= it could be useful=0A> in=0A> conjunction with the network stack, too, for= tasks that=0A> don't need a=0A> lot of locality.=0A> =0A> Basically this i= s the deal: the Intel NICs hash of various=0A> header=0A> fields.=A0 Then, = some bits from that hash are used to=0A> index a table.=0A> That table indi= cates what queue the received packet should=0A> go to.=0A> Ideally you'd wa= nt to use some sort of counter to index that=0A> table and=0A> get round-ro= bin queue usage if you wanted to evenly saturate=0A> all=0A> cores.=A0 Unfo= rtunately there doesn't seem to be a way to=0A> do that.=0A> =0A> What you = can do, though, is regularly update the table that=0A> is indexed=0A> by ha= sh.=A0 Very frequently, in fact, it's a pretty fast=0A> operation.=A0 So=0A= > what I've done, for example, is to go through an rotate all=0A> of the=0A= > entries every N packets, where N is something like the=0A> number of=0A> = receive descriptors per queue divided by the number of=0A> queues.=A0 So=0A= > bucket 0 goes to queue 0 and bucket 1 goes to queue 1 at=0A> first.=A0 Th= en=0A> a few hundred packets are received, and the table is=0A> reprogramme= d, so=0A> now bucket 0 goes to queue 1 and bucket 1 goes to queue 0.=0A> = =0A> I can provide code to do this, but I don't want to post it=0A> publicl= y=0A> (unless it is actually going to become an option for netmap)=0A> for = fear=0A> that people will use it in scenarios where it's harmful and=0A> th= en=0A> complain.=A0 It's potentially one more painful variation=0A> for the= Intel=0A> drivers that Intel can't support, and that just makes=0A> everyo= ne=0A> miserable.=0A> =0A> Thanks,=0A> Juli.=0A=0AThat seems like a pretty = naive approach. First, you want all of the packets in the same flows/connec= tions to use the same channels, otherwise you'll=0Abe sending a lot of stuf= f out of sequence. You want to balance your flows,=0Ayes, but not balance b= ased on packets, unless all of your traffic is icmp.=0AYou also want to bal= ance bits, not packets; sending 50 60 byte packets=0Ato queue 1 and 50 1500= byte packets to queue 2 isn't balancing. They'll=0Abe wildly out of order = as well.=0A=0AAlso, using as many cores as possible isn't necessarily what = you want to =0Ado, depending on your architecture. If you have 8 cores on 2= cpus, then you=0A probable want to do all of your networking on four cores= on one cpu. There's a big price to pay to shuffle memory between caches of= separate =0Acpus, splitting transactions that use the same memory space is= =0Acounterproductive. More queues mean more locks, and in the end, lock c= ontention is your biggest enemy, not cpu cycles.=0A=0AThe idea that splitti= ng packets that use the same memory and code space =0Aamong cpus isn't a ve= ry good one; a better approach, assuming you can=0Amicromanage, is to alloc= ate X cores (as much as you need for your peaks)=0Ato networking, and use o= ther cores for user space to minimize the=0Ainterruptions.=0A=0ABC From owner-freebsd-net@FreeBSD.ORG Tue May 1 18:22:20 2012 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 9CAFE1065688 for ; Tue, 1 May 2012 18:22:20 +0000 (UTC) (envelope-from joshruehlig@gmail.com) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) by mx1.freebsd.org (Postfix) with ESMTP id 727A68FC18 for ; Tue, 1 May 2012 18:22:20 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1SPHiN-0006xd-IG for freebsd-net@freebsd.org; Tue, 01 May 2012 11:22:19 -0700 Date: Tue, 1 May 2012 11:22:19 -0700 (PDT) From: josh4trunks To: freebsd-net@freebsd.org Message-ID: <1335896539559-5678671.post@n5.nabble.com> In-Reply-To: <20120501162121.GV2358@deviant.kiev.zoral.com.ua> References: <20120407133715.GU2358@deviant.kiev.zoral.com.ua> <20120408051125.GA2358@deviant.kiev.zoral.com.ua> <201204091219.39580.jhb@freebsd.org> <20120412183849.GA2358@deviant.kiev.zoral.com.ua> <20120501162121.GV2358@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: 82574L hangs (with r233708 e1000 driver). X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 18:22:20 -0000 I believe I have the same problem, using a similar chip (but not exact chip number). Interface is unusable because it hangs whenever I use it for NFS/iscsi. Here's a thread I have in the FreeBSD forum http://forums.freebsd.org/showthread.php?t=31745 Thanks for the patch, I might look into using it sometime in the future (or if I'm lazy just buy another NIC). -- View this message in context: http://freebsd.1045724.n5.nabble.com/82574L-hangs-with-r233708-e1000-driver-tp5624584p5678671.html Sent from the freebsd-net mailing list archive at Nabble.com. From owner-freebsd-net@FreeBSD.ORG Tue May 1 18:54:03 2012 Return-Path: Delivered-To: net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3B39F106566C; Tue, 1 May 2012 18:54:03 +0000 (UTC) (envelope-from emaste@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 0EFAE8FC12; Tue, 1 May 2012 18:54:03 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q41Is2Mx078454; Tue, 1 May 2012 18:54:02 GMT (envelope-from emaste@freefall.freebsd.org) Received: (from emaste@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q41Is2rs078450; Tue, 1 May 2012 18:54:02 GMT (envelope-from emaste) Date: Tue, 1 May 2012 18:54:02 GMT Message-Id: <201205011854.q41Is2rs078450@freefall.freebsd.org> To: emaste@FreeBSD.org, jfv@FreeBSD.org, net@FreeBSD.org From: emaste@FreeBSD.org Cc: Subject: Re: kern/142518: [em] [lagg] Problem on 8.0-STABLE with em and lagg 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, 01 May 2012 18:54:03 -0000 Synopsis: [em] [lagg] Problem on 8.0-STABLE with em and lagg Responsible-Changed-From-To: jfv->net Responsible-Changed-By: emaste Responsible-Changed-When: Tue May 1 18:53:35 UTC 2012 Responsible-Changed-Why: It sounds like this is a problem with lagg(4) not em(4) and so shouldn't be assigned to jfv. http://www.freebsd.org/cgi/query-pr.cgi?pr=142518 From owner-freebsd-net@FreeBSD.ORG Tue May 1 19:26:50 2012 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 84296106564A for ; Tue, 1 May 2012 19:26:50 +0000 (UTC) (envelope-from sodynet1@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 361E18FC08 for ; Tue, 1 May 2012 19:26:50 +0000 (UTC) Received: by obcni5 with SMTP id ni5so7409700obc.13 for ; Tue, 01 May 2012 12:26:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1yRnzvNp+pwJRuywBa3bQDOcWl6irf1/U4y/TEjmdaY=; b=hM2d3s3KyDH/9egjMYmFB4GH/BIjR+oQzqp4KP7Qhk2OyXKtvb0yOAYcd+z3OYVz/B 2iaAqp81ykI29GYvlHyyhD9lbfnItTYTmCor3EnHr6Sr3n076SZ1Q38ibMSnKf07yYE8 aOxLz/yIVv0YxX+O3ABvixczcALAQT4FekvfEDG1ug3bNV2//aGVZf4bwSvoCiQBhGw7 fzKn5PMp+F2Ju80zqNsMvoIiiZQaeGYd6EHlhhpA/WjjovFJt4is00gRLGllxwzkbQPH 9A9ZCPGljkiM4sDrz4mdxnRJYnweGGySzTog2PZ+m1o+Mkt/UZJpWs44n+AoBF3QOf6U bz4Q== MIME-Version: 1.0 Received: by 10.182.47.105 with SMTP id c9mr10082552obn.49.1335900407716; Tue, 01 May 2012 12:26:47 -0700 (PDT) Received: by 10.182.166.100 with HTTP; Tue, 1 May 2012 12:26:46 -0700 (PDT) In-Reply-To: References: <201204251241.04752.zec@fer.hr> <87vckg84gk.fsf@alien8.de> Date: Tue, 1 May 2012 22:26:46 +0300 Message-ID: From: Sami Halabi To: Jack Vogel Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, Julian Stecklina Subject: Re: Intel 10 GbE cards (ixgbe) 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, 01 May 2012 19:26:50 -0000 Hi, I KNOW you own the driver,i just mentioned that because its not listed on intel's site,and that would be a base for decisions when someone want to pick a card that works on fbsd:) so its better get listed as well, no one is going to check *.c files. Sami On Tue, May 1, 2012 at 9:06 PM, Jack Vogel wrote: > Funny, since I own the driver, one would think I'd know :) > > If you go look in the source directory for ixgbe you'll find a couple files > in there: ixgbe_x540.[ch]. That should be a clue... > > Jack > > > > On Tue, May 1, 2012 at 10:47 AM, Sami Halabi wrote: > >> x540has no fbsd driver >> >> Sami >> >> >> On Tue, May 1, 2012 at 6:42 PM, Jack Vogel wrote: >> >>> The 82599 is and has been officially supported for some time, the manual >>> tends to lag, I will try and get it updated. In fact, given a choice I >>> would always >>> go with the 599. And yes, the X540 should be stable, its just not yet >>> being >>> used as much yet. >>> >>> Jack >>> >>> >>> On Tue, May 1, 2012 at 5:34 AM, Julian Stecklina wrote: >>> >>> > Thus spake Marko Zec : >>> > >>> > > Hi all, >>> > > >>> > > Although the ixgbe driver appears to have code for both 82598 and >>> 82599 >>> > > chipsets, the manual page stil lists only 82598 based cards as >>> officially >>> > > supported. Does anybody have first-hand experiences with 82599 based >>> > cards >>> > > and recent versions of the ixgbe driver (-CURRENT, 9.0, 8.3)? >>> > >>> > We recently bought one: >>> > >>> > ix0@pci0:34:0:0: class=0x020000 card=0xa02c8086 chip=0x151c8086 >>> > rev=0x01 hdr=0x00 >>> > vendor = 'Intel Corporation' >>> > device = '82599EB 10 Gigabit TN Network Connection' >>> > class = network >>> > subclass = ethernet >>> > ix1@pci0:34:0:1: class=0x020000 card=0xa02c8086 chip=0x151c8086 >>> > rev=0x01 hdr=0x00 >>> > vendor = 'Intel Corporation' >>> > device = '82599EB 10 Gigabit TN Network Connection' >>> > class = network >>> > subclass = ethernet >>> > >>> > It's currently used on 9.0 for benchmarking another box. Never had any >>> > problems. Can someone say whether the X540 support in CURRENT is >>> stable? >>> > >>> > Regards, Julian >>> > >>> > _______________________________________________ >>> > 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" >>> >> >> >> >> -- >> Sami Halabi >> Information Systems Engineer >> NMS Projects Expert >> >> > -- Sami Halabi Information Systems Engineer NMS Projects Expert From owner-freebsd-net@FreeBSD.ORG Tue May 1 21:09:10 2012 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 AFA7B106564A; Tue, 1 May 2012 21:09:10 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (bird.sbone.de [46.4.1.90]) by mx1.freebsd.org (Postfix) with ESMTP id 4E7268FC0A; Tue, 1 May 2012 21:09:10 +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 EF43825D389C; Tue, 1 May 2012 21:09:08 +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 1E181BE609F; Tue, 1 May 2012 21:09:08 +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 A+i8h3SLwvPG; Tue, 1 May 2012 21:09:06 +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 2AADCBE609D; Tue, 1 May 2012 21:09:05 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Bjoern A. Zeeb" In-Reply-To: <20120501154031.GB80942@onelab2.iet.unipi.it> Date: Tue, 1 May 2012 21:09:05 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <6BF3F3EE-23CF-4FF6-B513-93E985CEE07E@lists.zabbadoz.net> References: <20120419133018.GA91364@onelab2.iet.unipi.it> <20120420190309.GA5617@onelab2.iet.unipi.it> <20120501154031.GB80942@onelab2.iet.unipi.it> To: Luigi Rizzo X-Mailer: Apple Mail (2.1084) Cc: current@freebsd.org, net@freebsd.org Subject: Re: more network performance info: ether_output() 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, 01 May 2012 21:09:10 -0000 On 1. May 2012, at 15:40 , Luigi Rizzo wrote: > On Tue, May 01, 2012 at 10:27:42AM -0400, George Neville-Neil wrote: >>=20 >> On Apr 20, 2012, at 15:03 , Luigi Rizzo wrote: >>=20 >>> Continuing my profiling on network performance, another place >>> were we waste a lot of time is if_ethersubr.c::ether_output() >>>=20 >>> In particular, from the beginning of ether_output() to the >>> final call to ether_output_frame() the code takes slightly >>> more than 210ns on my i7-870 CPU running at 2.93 GHz + TurboBoost. >>> In particular: >>>=20 >>> - the route does not have a MAC address (lle) attached, which causes >>> arpresolve() to be called all the times. This consumes about 100ns. >>> It happens also with locally sourced TCP. >>> Using the flowtable cuts this time down to about 30-40ns >>>=20 >>> - another 100ns is spend to copy the MAC header into the mbuf, >>> and then check whether a local copy should be looped back. >>> Unfortunately the code here is a bit convoluted so the >>> header fields are copied twice, and using memcpy on the >>> individual pieces. >>>=20 >>> Note that all the above happens not just with my udp flooding >>> tests, but also with regular TCP traffic. >>=20 >> Hi Luigi, >>=20 >> I'm really glad you're working on this. I may have missed this in a = thread >> but are you tracking these somewhere so we can pick them up and fix = them? >>=20 >> Also, how are you doing the measurements. >=20 > The measurements are done with tools/tools/netrate/netsend and > kernel patches to return from sendto() at various places in the > stack (from the syscall entry point down to the device driver). > A patch is attached. I think that was lost on the way. Can you mail it or put it somewhere and send a link? > You don't really need netmap to run it, > it was just a convenient place to put the variables. >=20 > I am not sure how much we can "fix", there are multiple expensive > functions on the tx path, and probably also on the rx path. >=20 > My hope at least for the tx path is that we can find out a way to = install a > "fastpath" handler in the socket. > When there is no handler installed (e.g. on the first packet or > unsupported protocols/interfaces) everything works as usual. Then > when the packet reaches the bottom of the stack, we try to update > the socket with a copy of the headers generated in the process, and > the name of the fastpath function to be called. Next transmissions > will then be able to shortcut the stack and go straight to the > device output routine. >=20 > I don't have data on the receive path or good ideas on how to proceed = -- the > advantage of the tx path is that traffic is implicitly classified, > whereas it might not be the case for incoming traffic, and = classification > might be the expensive step. >=20 > Hopefully we'll have time to discuss this next week in ottawa. Yepp:) --=20 Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! From owner-freebsd-net@FreeBSD.ORG Tue May 1 21:21:51 2012 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 694FA106566B; Tue, 1 May 2012 21:21:51 +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 25A8B8FC08; Tue, 1 May 2012 21:21:51 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id A12377300A; Tue, 1 May 2012 23:41:40 +0200 (CEST) Date: Tue, 1 May 2012 23:41:40 +0200 From: Luigi Rizzo To: "Bjoern A. Zeeb" Message-ID: <20120501214140.GA83902@onelab2.iet.unipi.it> References: <20120419133018.GA91364@onelab2.iet.unipi.it> <20120420190309.GA5617@onelab2.iet.unipi.it> <20120501154031.GB80942@onelab2.iet.unipi.it> <6BF3F3EE-23CF-4FF6-B513-93E985CEE07E@lists.zabbadoz.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6BF3F3EE-23CF-4FF6-B513-93E985CEE07E@lists.zabbadoz.net> User-Agent: Mutt/1.4.2.3i Cc: current@freebsd.org, net@freebsd.org Subject: Re: more network performance info: ether_output() 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, 01 May 2012 21:21:51 -0000 On Tue, May 01, 2012 at 09:09:05PM +0000, Bjoern A. Zeeb wrote: > > On 1. May 2012, at 15:40 , Luigi Rizzo wrote: > > > On Tue, May 01, 2012 at 10:27:42AM -0400, George Neville-Neil wrote: ... > >> Also, how are you doing the measurements. > > > > The measurements are done with tools/tools/netrate/netsend and > > kernel patches to return from sendto() at various places in the > > stack (from the syscall entry point down to the device driver). > > A patch is attached. > > I think that was lost on the way. Can you mail it or put it somewhere > and send a link? nope, my fault, i forgot to put the attachment. I have now put it at http://info.iet.unipi.it/~luigi/netmap/20120501-netmap_drop.diff cheers luigi From owner-freebsd-net@FreeBSD.ORG Tue May 1 21:51:26 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 19431106564A for ; Tue, 1 May 2012 21:51:26 +0000 (UTC) (envelope-from juli@clockworksquid.com) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by mx1.freebsd.org (Postfix) with ESMTP id 999078FC15 for ; Tue, 1 May 2012 21:51:25 +0000 (UTC) Received: by wibhj6 with SMTP id hj6so3257100wib.13 for ; Tue, 01 May 2012 14:51:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=d3xG4KUwX2lE2PPBYY+utjIzfSDyhPSEyT4SqfJYFzA=; b=og20vnXPrVWXAJg1lVE16a1E3rjFDY+EqT1VU7K5d81fxInni4VxOCcI/7+DzxnymF ThsmpvXpwqQsSXxM3pt8i0mM7L/YVtaU2PhU+g+qqXF+jPYA9RH2viOoYAMYvQoFUcCa Fkn6Q80nVcLInTQExWCpV/ETNePA8IDEowp/tBfogWdwPuh8SYUHX0K+RFIKY+vASrJM t/YruG6GSgN6SzrwTqcqqB35vuDmpOW3gg5+QTdlORhhzuIKAMHvLENjsQ0eviPAxOel LnBGsdeNQFcN58bTJJY71P+a0IlnL+ShH0PPhWef53F4hei/fm/FqQDrlUHnHkmxRL8w jgKg== Received: by 10.180.101.230 with SMTP id fj6mr8304346wib.13.1335909079106; Tue, 01 May 2012 14:51:19 -0700 (PDT) MIME-Version: 1.0 Sender: juli@clockworksquid.com Received: by 10.216.110.67 with HTTP; Tue, 1 May 2012 14:50:58 -0700 (PDT) In-Reply-To: <1335895983.68943.YahooMailClassic@web126001.mail.ne1.yahoo.com> References: <1335895983.68943.YahooMailClassic@web126001.mail.ne1.yahoo.com> From: Juli Mallett Date: Tue, 1 May 2012 14:50:58 -0700 X-Google-Sender-Auth: o4SgxHAtI4WtdlZVTfa4U_ZTJEQ Message-ID: To: Barney Cordoba Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnTWVBfl82htu1diK272geHxKaJegPZ7k/5Ynbpr3h3ss7wLdDNvS+jwJ3nv8QduKafHI66 Cc: "freebsd-net@freebsd.org" , Sean Bruno Subject: Re: igb(4) at peak in big purple 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, 01 May 2012 21:51:26 -0000 Hey Barney, On Tue, May 1, 2012 at 11:13, Barney Cordoba wro= te: > --- On Fri, 4/27/12, Juli Mallett wrote: > > [Tricking Intel's cards into giving something like round-robin packet > > delivery to multiple queues. ] > > That seems like a pretty naive approach. First, you want all of the packe= ts in the same flows/connections to use the same channels, otherwise you'll > be sending a lot of stuff out of sequence. I wouldn't call it naive, I'd call it "oblivious". I feel like I went to some lengths to indicate that it was not the right solution to many problems, but that it was a worthwhile approach in the case where one doesn't care about anything but evenly distributing packets by number (although size is also possible, by using a size-based watermark rather than a count-based one) to as many queues as possible. Not every application requires in-sequence packets (indeed, out-of-sequence traffic can be a problem even with flow affinity approaches.) My note was simply about the case where you need to evenly saturate queues to divide up the work as much as possible, on hardware that doesn't make it possible to get the behavior you want (round-robin by packet) for that case. Intel's hardware has the redirection table, which makes it possible (with a very application-aware approach that is anything but naive) to get functionality from the hardware that isn't otherwise available at a low-level. Few of the things you assert are better are available from Intel's cards =E2=80=94 if you want to talk about optimal hardware multi-queue strategies, or queue-splitting in software, that's a good conversation to have and this may even be the right list, but I'd encourage you to just build your own silicon or use something with programmable firmware. For those of us saddled with Intel NICs, it's useful to share information on how to get behavior that may be desirable (and I promise you it is for a large class of applications) but not marketed :) > You want to balance your flows, > yes, but not balance based on packets, unless all of your traffic is icmp= . > You also want to balance bits, not packets; sending 50 60 byte packets > to queue 1 and 50 1500 byte packets to queue 2 isn't balancing. They'll > be wildly out of order as well. This is where the obliviousness is useful. Traffic has its own statistical distributions in terms of inter-packet gaps, packet sizes, etc. Assume your application just keeps very accurate counters of how many packets have been seen with each Ethernet protocol type. This is a reasonable approximation of some real applications that are interesting and that people use FreeBSD for. You don't care how big the packets are, assuming your memory bandwidth is infinite (or at least greater than what you need) =E2=80=94 you just want to be sure to see each one of them, and that means making the most of the resources you have to ensure that even under peak loads you cannot possibly drop any traffic. Again, not every application is like that, and there's a reason I didn't post a patch and encourage the premature-tuning crowd to give this sort of thing a try. When you don't care about distributing packets evenly by size, you want an algorithm that doesn't factor them in. Also, I've had the same concern that you now have previously, and in my experience it's mostly magical thinking. With many kinds of application and many kinds of real-world traffic it really doesn't matter, even if in theory it's a possibility. There's no universal solution to packet capture that's going to be optimal for every application. > Also, using as many cores as possible isn't necessarily what you want to > do, depending on your architecture. I think Sean and I, at least, know that, and it's a point that I have gone on about at great length when people endorse the go-faster stripes of using as many cores as possible, rather than as many cores as necessary. > If you have 8 cores on 2 cpus, then you > =C2=A0probable want to do all of your networking on four cores on one cpu= . > There's a big price to pay to shuffle memory between caches of separate > cpus, splitting transactions that use the same memory space is > counterproductive. Not necessarily =E2=80=94 you may not need to split transactions with all kinds of applications. > More =C2=A0queues mean more locks, and in the end, lock contention is you= r biggest enemy, not cpu cycles. Again, this depends on your application, and that's a very naive assertion :) Lock contention may be your biggest enemy, but it's only occasionally mine :) > The idea that splitting packets that use the same memory and code space > among cpus isn't a very good one; a better approach, assuming you can You're making an assumption that wasn't part of the conversation, though. Who said anything about using the same memory? > micromanage, is to allocate X cores (as much as you need for your peaks) > to networking, and use other cores for user space to minimize the > interruptions. Who said anything about user space? :) And actually, this is wrong in even those applications where it's right that you need to dedicate some cores for networking, too. In my experience, it's much better to have the control path stuff on the same cores you're handling interrupts on if you're using something like netmap. Interrupts kill the cores that are doing real work with each packet. Thanks, Juli. From owner-freebsd-net@FreeBSD.ORG Tue May 1 23:12:50 2012 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 C8D6F106566C; Tue, 1 May 2012 23:12:50 +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 9C0CD8FC08; Tue, 1 May 2012 23:12:50 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q41NCo0x018977; Tue, 1 May 2012 23:12:50 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q41NCo3P018973; Tue, 1 May 2012 23:12:50 GMT (envelope-from linimon) Date: Tue, 1 May 2012 23:12:50 GMT Message-Id: <201205012312.q41NCo3P018973@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/167500: [em] [panic] Kernel panics in em driver X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 23:12:50 -0000 Old Synopsis: Kernel panics in em driver New Synopsis: [em] [panic] Kernel panics in em driver Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Tue May 1 23:12:34 UTC 2012 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=167500 From owner-freebsd-net@FreeBSD.ORG Wed May 2 00:01:49 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 554D0106564A for ; Wed, 2 May 2012 00:01:49 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from nm2-vm1.bullet.mail.ne1.yahoo.com (nm2-vm1.bullet.mail.ne1.yahoo.com [98.138.91.33]) by mx1.freebsd.org (Postfix) with SMTP id F21838FC0A for ; Wed, 2 May 2012 00:01:48 +0000 (UTC) Received: from [98.138.90.53] by nm2.bullet.mail.ne1.yahoo.com with NNFMP; 02 May 2012 00:01:48 -0000 Received: from [98.138.87.6] by tm6.bullet.mail.ne1.yahoo.com with NNFMP; 02 May 2012 00:01:48 -0000 Received: from [127.0.0.1] by omp1006.mail.ne1.yahoo.com with NNFMP; 02 May 2012 00:01:48 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 102136.84486.bm@omp1006.mail.ne1.yahoo.com Received: (qmail 15362 invoked by uid 60001); 2 May 2012 00:01:48 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1335916908; bh=QKCJL95YLU020ONhbL3OxoLMjb0+4rbgDsanYbRZfpM=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=E8GJNfIbjsM62Qpm8GFP6KvoQuTGcNNrCc5bEL9hYIk0/x4MGHb9lk/3CzDjheZys9pNwk4jFYNQWlLe+fyqyODyPV0aZrMD187aoFoho5HJ4aGObp1YezaMFQl+9l3jeB6X2nJXlEh54aGacRBE3SKLoeW5fP2HF4n3zhIzCUg= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=vYA3hQ2RzN3nd0dYXHCz7CqTFxmU25o8Ex/Kiu81g5N4D6MPUknO9BUsd6gEBUfBgZpD80DQzhToN6YBhje6ZT3uo/Bv+cWCA/q8fBXzDCB4piYWhLSM9l9x/nRjuFGB6M6aFQC5hd8FCpTqX7JnH/RLxUdOYCdvrMRsBZGxZH8=; X-YMail-OSG: MBnoMoEVM1nHtBGiioZRf6NozHer6YsYiRQh0VK6JvcTDC1 VHewNrnyXmQd5fITYlvnFZps8p8b0hiRaCBtSU5Q66gUZ7Hux4V2VHhWS2jF SwQm_GsXPa04yiK_mfLyX_7rn.PltXQd9BiNE_IMd6OMJFz06Axb4MVvaGwc M3aIHQdTA2OeCUeto7LkUGcBSZcB62LE_NXSlyR5c0U4fQIGeGKAOJoBTtw6 5VW8KTlpcHiDKxpBj1ejZTDL2HPLJxdmeXBkmYeTgXmcazh4W0hnumErud2z R4qgSvsEgCFf1B1WZ3FzznmxjmEdu6TuPCm5uP0KzVltDRlRT7MmQj5jZ3DQ I6EUpd3Up1hl5ZguQQDiXCqHBlBAQXEROG5Fr8texpI3tkCSKbFG3ys5Qtfo EpFK0l66bArOEfYXCow.uy4lamWCw8SwGLO0CQOYIfLbqHKq1DlKoEluVozM DLRHtwmZljJdw Received: from [174.48.129.108] by web126006.mail.ne1.yahoo.com via HTTP; Tue, 01 May 2012 17:01:47 PDT X-Mailer: YahooMailClassic/15.0.6 YahooMailWebService/0.8.117.340979 Message-ID: <1335916907.11454.YahooMailClassic@web126006.mail.ne1.yahoo.com> Date: Tue, 1 May 2012 17:01:47 -0700 (PDT) From: Barney Cordoba To: Juli Mallett MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-net@freebsd.org" , Sean Bruno Subject: Re: igb(4) at peak in big purple 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, 02 May 2012 00:01:49 -0000 =0A--- On Tue, 5/1/12, Juli Mallett wrote:=0A=0A> Fr= om: Juli Mallett =0A> Subject: Re: igb(4) at peak in = big purple=0A> To: "Barney Cordoba" =0A> Cc: "Sea= n Bruno" , "freebsd-net@freebsd.org" =0A> Date: Tuesday, May 1, 2012, 5:50 PM=0A> Hey Barney,=0A> =0A>= On Tue, May 1, 2012 at 11:13, Barney Cordoba =0A= > wrote:=0A> > --- On Fri, 4/27/12, Juli Mallett =0A>= wrote:=0A> > > [Tricking Intel's cards into giving something like=0A> roun= d-robin packet=0A> > >=C2=A0 delivery to multiple queues.=C2=A0 ]=0A> >=0A>= > That seems like a pretty naive approach. First, you=0A> want all of the = packets in the same flows/connections to use=0A> the same channels, otherwi= se you'll=0A> > be sending a lot of stuff out of sequence.=0A> =0A> I would= n't call it naive, I'd call it "oblivious".=C2=A0 I=0A> feel like I went=0A= > to some lengths to indicate that it was not the right=0A> solution to man= y=0A> problems, but that it was a worthwhile approach in the case=0A> where= one=0A> doesn't care about anything but evenly distributing packets=0A> by= number=0A> (although size is also possible, by using a size-based=0A> wate= rmark=0A> rather than a count-based one) to as many queues as=0A> possible.= =C2=A0 Not=0A> every application requires in-sequence packets (indeed,=0A> = out-of-sequence traffic can be a problem even with flow=0A> affinity=0A> ap= proaches.)=0A> =0A> My note was simply about the case where you need to eve= nly=0A> saturate=0A> queues to divide up the work as much as possible, on= =0A> hardware that=0A> doesn't make it possible to get the behavior you wan= t=0A> (round-robin by=0A> packet) for that case.=C2=A0 Intel's hardware has= the=0A> redirection table,=0A> which makes it possible (with a very applic= ation-aware=0A> approach that=0A> is anything but naive) to get functionali= ty from the=0A> hardware that=0A> isn't otherwise available at a low-level.= =C2=A0 Few of the=0A> things you=0A> assert are better are available from I= ntel's cards =E2=80=94 if=0A> you want to=0A> talk about optimal hardware m= ulti-queue strategies, or=0A> queue-splitting=0A> in software, that's a goo= d conversation to have and this may=0A> even be=0A> the right list, but I'd= encourage you to just build your own=0A> silicon=0A> or use something with= programmable firmware.=C2=A0 For those=0A> of us saddled=0A> with Intel NI= Cs, it's useful to share information on how to=0A> get=0A> behavior that ma= y be desirable (and I promise you it is for=0A> a large=0A> class of applic= ations) but not marketed :)=0A> =0A> > You want to balance your flows,=0A> = > yes, but not balance based on packets, unless all of=0A> your traffic is = icmp.=0A> > You also want to balance bits, not packets; sending 50=0A> 60 b= yte packets=0A> > to queue 1 and 50 1500 byte packets to queue 2 isn't=0A> = balancing. They'll=0A> > be wildly out of order as well.=0A> =0A> This is w= here the obliviousness is useful.=C2=A0 Traffic has=0A> its own=0A> statist= ical distributions in terms of inter-packet gaps,=0A> packet sizes,=0A> etc= .=C2=A0 Assume your application just keeps very accurate=0A> counters of ho= w=0A> many packets have been seen with each Ethernet protocol=0A> type.=C2= =A0 This is=0A> a reasonable approximation of some real applications that= =0A> are=0A> interesting and that people use FreeBSD for.=C2=A0 You don't= =0A> care how big=0A> the packets are, assuming your memory bandwidth is in= finite=0A> (or at=0A> least greater than what you need) =E2=80=94 you just = want to be=0A> sure to see=0A> each one of them, and that means making the = most of the=0A> resources you=0A> have to ensure that even under peak loads= you cannot=0A> possibly drop any=0A> traffic.=0A> =0A> Again, not every ap= plication is like that, and there's a=0A> reason I=0A> didn't post a patch = and encourage the premature-tuning crowd=0A> to give=0A> this sort of thing= a try.=C2=A0 When you don't care about=0A> distributing=0A> packets evenly= by size, you want an algorithm that doesn't=0A> factor them=0A> in.=C2=A0 = Also, I've had the same concern that you now have=0A> previously, and=0A> i= n my experience it's mostly magical thinking.=C2=A0 With=0A> many kinds of= =0A> application and many kinds of real-world traffic it really=0A> doesn't= =0A> matter, even if in theory it's a possibility.=C2=A0 There's=0A> no uni= versal=0A> solution to packet capture that's going to be optimal for=0A> ev= ery=0A> application.=0A> =0A> > Also, using as many cores as possible isn't= necessarily=0A> what you want to=0A> > do, depending on your architecture.= =0A> =0A> I think Sean and I, at least, know that, and it's a point=0A> tha= t I have=0A> gone on about at great length when people endorse the=0A> go-f= aster=0A> stripes of using as many cores as possible, rather than as=0A> ma= ny cores=0A> as necessary.=0A> =0A> > If you have 8 cores on 2 cpus, then y= ou=0A> > =C2=A0probable want to do all of your networking on four=0A> cores= on one cpu.=0A> > There's a big price to pay to shuffle memory between=0A>= caches of separate=0A> > cpus, splitting transactions that use the same me= mory=0A> space is=0A> > counterproductive.=0A> =0A> Not necessarily =E2=80= =94 you may not need to split transactions=0A> with all=0A> kinds of applic= ations.=0A> =0A> > More =C2=A0queues mean more locks, and in the end, lock= =0A> contention is your biggest enemy, not cpu cycles.=0A> =0A> Again, this= depends on your application, and that's a very=0A> naive=0A> assertion :)= =C2=A0 Lock contention may be your biggest=0A> enemy, but it's only=0A> occ= asionally mine :)=0A> =0A> > The idea that splitting packets that use the s= ame=0A> memory and code space=0A> > among cpus isn't a very good one; a bet= ter approach,=0A> assuming you can=0A> =0A> You're making an assumption tha= t wasn't part of the=0A> conversation,=0A> though.=C2=A0 Who said anything = about using the same=0A> memory?=0A> =0A> > micromanage, is to allocate X c= ores (as much as you=0A> need for your peaks)=0A> > to networking, and use = other cores for user space to=0A> minimize the=0A> > interruptions.=0A> =0A= > Who said anything about user space?=C2=A0 :)=0A> =0A> And actually, this = is wrong in even those applications where=0A> it's=0A> right that you need = to dedicate some cores for networking,=0A> too.=C2=A0 In my=0A> experience,= it's much better to have the control path stuff=0A> on the=0A> same cores = you're handling interrupts on if you're using=0A> something=0A> like netmap= .=C2=A0 Interrupts kill the cores that are doing=0A> real work with=0A> eac= h packet.=0A> =0A> Thanks,=0A> Juli.=0A> =0AWell he said it was not causing= issues, so it seems to me to give him =0Aa hack that's likely to be less e= fficient overall isn't the right answer.=0AHis lopsidedness is not normal.= =0A=0AMake sure the interrupt moderation is tuned properly, it can make a h= uge=0Adifference. Interrupts on intel devices are really just polls; you ca= n set=0Athe poll to any interval you want.=0A=0AI'd be interested in seeing= the usage numbers with and without the hack.=0AIntel's hashing gives prett= y even distribution on a router or bridge; =0Athe only time you'd see a rea= lly lopsided distribution would be if you =0Awere running a traffic generat= or with a small number of flows. The answer=0Ais to use more flows in that = case. The same client/server pair is always=0Agoing to use the same queue.= =0A=0ABC=0A From owner-freebsd-net@FreeBSD.ORG Wed May 2 11:38:31 2012 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 2E6A9106564A for ; Wed, 2 May 2012 11:38:31 +0000 (UTC) (envelope-from annonymouse@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id D60B68FC08 for ; Wed, 2 May 2012 11:38:30 +0000 (UTC) Received: by vcmm1 with SMTP id m1so418202vcm.13 for ; Wed, 02 May 2012 04:38:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type:content-transfer-encoding; bh=/K7QL6SK2dntURQ36DA8XXOI6298+RXRhxreG5YsJRg=; b=HRmefbzzy2ixoSw0OVUpBhL0F3eR67hvFDvNUJkzaFXd6QXhFwkYjsiAX6i8THnbC3 LJV2GGsOinkP46o3Yxxbp9o9uM8OJcnxeZ7XXabUcGhRV4vxMPLDaun3LOsaAV2RMy1l PLfZKNX8YdIC0sALcSr2gM63ZG7PjDrXHPT96YbuOrfCXl0f4jBzT1IOx6pWEEcGN1JF jzAyvjzTcUnDGPh+VROF1xa+Wvk3Mp6xlcde/+RjQ/WXvY3vXPGU+d8Os9tm6wnOIa6L /CTOpaQT5BHRyx1jYCuvP1BgtbposAxasuCRPla63kDDZldr1gWGKSI3/UkWWiYfMj0T 7EkA== MIME-Version: 1.0 Received: by 10.52.19.193 with SMTP id h1mr4119035vde.18.1335958710037; Wed, 02 May 2012 04:38:30 -0700 (PDT) Sender: annonymouse@gmail.com Received: by 10.220.204.143 with HTTP; Wed, 2 May 2012 04:38:29 -0700 (PDT) Date: Wed, 2 May 2012 12:38:29 +0100 X-Google-Sender-Auth: tPTbY2R2A8Nj3OQnTOsDE87m0_Q Message-ID: From: Alex Yong To: freebsd-net@freebsd.org Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: [patch] Strong ES model in IPv6 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, 02 May 2012 11:38:31 -0000 Hi all, I have some questions regarding accomplishing the strong model for ingress IPv6 traffic with FreeBSD, as implemented in ip6_input.c. Does it make sense to have a strong ES model in IPv6 *at all*? I=92ve yet to find any wording in the RFC=92s referring to this =96 although nothing explicitly disallowing it. Given that addresses that are globally scoped are =93global=94 I could understand why a stack might make the choice to not do this, as the address may be considered attached to the =93system=94 rather than the interface. However for separating networks at a basic level this isn=92t appropriate. I realise that pF is an option in this case, but arguably it=92s an option in ipv4 too =96 so why default ipv4 to strong model? Also of note, the KAME code in NetBSD reference=92s a sysctl =93net.inet6.ip6.sourcecheck=94 which is never used, but seems to indicate an intention to implement something like this. Was the intention to implement the strong model for ingress IPv6 traffic with this switch? This patch attempts to implement the strong model using the same sysctl as in NetBSD, note that multicast listeners already handle which interface they arrive at. There=92s some thought that probably needs to go into using it in combination with ip_forwarding and other sysctls, but it wasn=92t too difficult given the interface address list is already traversed upfront before the routeing table lookup. Does anybody know why this is, was something else intended here? I=92ve hammered my code with isic6/tcpsic6/udpsic6 for a few hours with and without listening sockets and nothing caught fire. I haven=92t tried using TAHI yet although given my rig it=92s a bit more complicated to setup. Any guidance is greatly appreciated. -- This patch is on release 8.2, although if necessary I can port it up if this is unacceptably old now :). It implements the =93net.inet6.ip6.sourcecheck=94 sysctl which when set to 1 will drop packets if they=92re not for addresses configured on the interface on which they arrived. This is intended to implement RFC 1122=92s =93Strong end system model=94 for IPv6. -- diff -r 8b21c9a98cbd src/sys/netinet6/ip6_input.c --- a/src/sys/netinet6/ip6_input.c Mon Apr 02 14:15:19 2012 +0100 +++ b/src/sys/netinet6/ip6_input.c Tue May 01 14:32:30 2012 +0100 @@ -80,6 +80,7 @@ #include #include #include +#include #include #include @@ -125,6 +126,11 @@ .nh_policy =3D NETISR_POLICY_FLOW, }; +/* Take this variable name from NetBSD, but exposing it as a sysctl */ +static unsigned ip6_sourcecheck =3D 0; SYSCTL_DECL(_net_inet6); +SYSCTL_UINT(_net_inet6, OID_AUTO, sourcecheck, CTLFLAG_RW, +&ip6_sourcecheck, 0, "Check packets destination address is configured +on the incoming interface RFC1122"); + VNET_DECLARE(struct callout, in6_tmpaddrtimer_ch); #define V_in6_tmpaddrtimer_ch VNET(in6_tmpaddrtimer_ch) @@ -599,6 +605,10 @@ if (lle !=3D NULL) LLE_RUNLOCK(lle); + /*XXX AlexY if ip6_sourcecheck is set we immediately assume it's ba= d*/ + if (0 !=3D ip6_sourcecheck) + goto bad; + dst =3D &rin6.ro_dst; dst->sin6_len =3D sizeof(struct sockaddr_in6); dst->sin6_family =3D AF_INET6; From owner-freebsd-net@FreeBSD.ORG Wed May 2 21:53:02 2012 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 3844A1065670; Wed, 2 May 2012 21:53:02 +0000 (UTC) (envelope-from snatreju@googlemail.com) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by mx1.freebsd.org (Postfix) with ESMTP id 981138FC1C; Wed, 2 May 2012 21:53:01 +0000 (UTC) Received: by wibhj6 with SMTP id hj6so4182756wib.13 for ; Wed, 02 May 2012 14:52:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=date:from:to:cc:subject:message-id:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=dzjzKXtp5wSal789PEtOy/Nd5/P8p5l8c9/HUFAGrRM=; b=Z7PN6V3lxe+PmQ/qz7ZWkRvDT12xQs/2XCj9itLqJSckqnaybVsxw4uJsoo17zBVye D46osO0zity7KFxVzEtTjs5YMRF2OwnbBT2yNf7Vklz7jC8VF6kJUhbaNRbuapzKRTtU eYeRFVsIuKhKaG1SRe9Un0G8AYVGFT/qctLgRmtg2L4B5pLN6sn+P8zuw2vbUsedQ/B3 CDrGuF+PyokUR9RP9Bn6WE/hTdZuFe9ocf9q4sJ89j39um6BtJVntCn/CKfnq5hOreMP pARaNtB6/fp3T5o2SLR8bYxPmkWURZI3CLqnDvQP2c5aLGcbjG6yCU5zVKtjWpN8H11i sVHQ== Received: by 10.180.79.72 with SMTP id h8mr952158wix.1.1335995575314; Wed, 02 May 2012 14:52:55 -0700 (PDT) Received: from sherwood.local ([89.204.154.196]) by mx.google.com with ESMTPS id fl2sm10956872wib.2.2012.05.02.14.52.53 (version=SSLv3 cipher=OTHER); Wed, 02 May 2012 14:52:54 -0700 (PDT) Date: Wed, 2 May 2012 23:52:49 +0200 From: Steven Atreju To: Luigi Rizzo Message-ID: <20120502215249.GT633@sherwood.local> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20120502182557.GA93838@onelab2.iet.unipi.it> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: current@freebsd.org, net@freebsd.org Subject: Re: fast bcopy... 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, 02 May 2012 21:53:02 -0000 Luigi Rizzo wrote: > 2. apparently, bcopy is not the fastest way to copy memory. http://now.cs.berkeley.edu/Td/bcopy.html Best Regards. Steven. From owner-freebsd-net@FreeBSD.ORG Thu May 3 00:58:06 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 91F00106566B; Thu, 3 May 2012 00:58:06 +0000 (UTC) (envelope-from kmacybsd@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 37AFB8FC18; Thu, 3 May 2012 00:58:06 +0000 (UTC) Received: by yenl9 with SMTP id l9so1702712yen.13 for ; Wed, 02 May 2012 17:58:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; 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=FUKwYALkR5tq7eyIr11FU09V46czQs+VXa3OC299OKA=; b=fAcmKMglFQxbZd4m6WdtUsGZVGkLwan9UeipRHaRZVIQPC15xoDnRWw42lbJsh5VR6 iRjC/wL+CfkrpZLnDW8Ht3yo5cubANnd1FjjGAJAWErIcgBxfhLBUJE2xEB7hBE1KZoC dCTF5z/3TVqsgDPCl/++OaFrDU/yjqn1RynTlRKxUKrjErJamtWQuCPUSYbnN6iEzLkr uYmqcfRJEVmiSfHsEvF31VR8fl6XoUKGlCHf94uJGM1CKoXrfcrQtk6qoGHCf40jG8Xj YYn/hUQ6cbQE8Iwr3vVlBSRm9FnZ37ZASXn4RMDNVgWH+3U84+sKxq1MKem/9F0HIVab Zw/Q== MIME-Version: 1.0 Received: by 10.50.194.232 with SMTP id hz8mr115119igc.38.1336006685367; Wed, 02 May 2012 17:58:05 -0700 (PDT) Sender: kmacybsd@gmail.com Received: by 10.50.129.39 with HTTP; Wed, 2 May 2012 17:58:05 -0700 (PDT) In-Reply-To: <20120502215249.GT633@sherwood.local> References: <20120502182557.GA93838@onelab2.iet.unipi.it> <20120502215249.GT633@sherwood.local> Date: Thu, 3 May 2012 02:58:05 +0200 X-Google-Sender-Auth: PsoKud2b--Af30RLbY-2r4lysso Message-ID: From: "K. Macy" To: Steven Atreju Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: Luigi Rizzo , current@freebsd.org, net@freebsd.org Subject: Re: fast bcopy... 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, 03 May 2012 00:58:06 -0000 It's highly chipset and processor dependent what works best. Intel now has non-temporal loads and stores which work much better in some cases but provide little benefit in others. -Kip On Wed, May 2, 2012 at 11:52 PM, Steven Atreju wr= ote: > Luigi Rizzo wrote: >> 2. apparently, bcopy is not the fastest way to copy memory. > > http://now.cs.berkeley.edu/Td/bcopy.html > > Best Regards. > > Steven. > _______________________________________________ > 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 =A0 =A0=93The real damage is done by those millions who want to 'get by.' The ordinary men who just want to be left in peace. Those who don=92t want their little lives disturbed by anything bigger than themselves. Those with no sides and no causes. Those who won=92t take measure of their own strength, for fear of antagonizing their own weakness. Those who don=92t like to make waves=97or enemies. =A0 =A0Those for whom freedom, honour, truth, and principles are only literature. Those who live small, love small, die small. It=92s the reductionist approach to life: if you keep it small, you=92ll keep it under control. If you don=92t make any noise, the bogeyman won=92t find you. =A0 =A0But it=92s all an illusion, because they die too, those people who roll up their spirits into tiny little balls so as to be safe. Safe?! >From what? Life is always on the edge of death; narrow streets lead to the same place as wide avenues, and a little candle burns itself out just like a flaming torch does. =A0 =A0I choose my own way to burn.=94 =A0 =A0Sophie Scholl From owner-freebsd-net@FreeBSD.ORG Thu May 3 01:11:18 2012 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 383101065670; Thu, 3 May 2012 01:11:18 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 8E5AB8FC0C; Thu, 3 May 2012 01:11:17 +0000 (UTC) Received: by wgbds12 with SMTP id ds12so1216548wgb.31 for ; Wed, 02 May 2012 18:11:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=//vnWyl0pLbMOQIt4OQO7Yp/P00TxNcdEVdVeGb/uGE=; b=dTl51GoEe+FGYnDN8KmHy9s2Nv7He4Jah39ICbrNBT3ZL+osX+CcJL3bomnM+ZQ5ym COipOeClgq0LdZnCQXM0OUX0Ov9MOcFrthbLZsffqY8ur1S2pu3zAVCsYg/Deugg2GUF aPlZPatbjsLvUnbA1nhDf8hxGCPC6XxEYK3Ax2nvLaKc/HhuZStQtGG3FjWxCKYGQx5p 1wlnuDBnfQgyIUdciwbQULIq1bhU/u0qqXG72ZInjtFuybEt7ZJvd/wLEHkRjXuO/f2e X17zV9ymaV56DQMx6eyGqXldQ3fJw7rZmfRk7KIMxkB/CYoePZ36mqiiUTfiiD4ZEgaA uinA== MIME-Version: 1.0 Received: by 10.180.100.230 with SMTP id fb6mr897818wib.3.1336007476710; Wed, 02 May 2012 18:11:16 -0700 (PDT) Received: by 10.216.193.220 with HTTP; Wed, 2 May 2012 18:11:16 -0700 (PDT) In-Reply-To: <20120502215249.GT633@sherwood.local> References: <20120502182557.GA93838@onelab2.iet.unipi.it> <20120502215249.GT633@sherwood.local> Date: Wed, 2 May 2012 21:11:16 -0400 Message-ID: From: Arnaud Lacombe To: Steven Atreju Content-Type: text/plain; charset=ISO-8859-1 Cc: Luigi Rizzo , current@freebsd.org, net@freebsd.org Subject: Re: fast bcopy... 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, 03 May 2012 01:11:18 -0000 Hi, On Wed, May 2, 2012 at 5:52 PM, Steven Atreju wrote: > Luigi Rizzo wrote: >> 2. apparently, bcopy is not the fastest way to copy memory. > > http://now.cs.berkeley.edu/Td/bcopy.html > "Pentium 166, Triton Chipset, EDO memory"... ahem. - Arnaud > Best Regards. > > Steven. > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Thu May 3 01:41:53 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D4803106564A; Thu, 3 May 2012 01:41:53 +0000 (UTC) (envelope-from emaste@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id A9AB98FC08; Thu, 3 May 2012 01:41:53 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q431fr9M040246; Thu, 3 May 2012 01:41:53 GMT (envelope-from emaste@freefall.freebsd.org) Received: (from emaste@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q431frvI040242; Thu, 3 May 2012 01:41:53 GMT (envelope-from emaste) Date: Thu, 3 May 2012 01:41:53 GMT Message-Id: <201205030141.q431frvI040242@freefall.freebsd.org> To: sten@blinkenlights.nl, emaste@FreeBSD.org, freebsd-net@FreeBSD.org From: emaste@FreeBSD.org Cc: Subject: Re: kern/138620: [lagg] [patch] lagg port bpf-writes blocked 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, 03 May 2012 01:41:53 -0000 Synopsis: [lagg] [patch] lagg port bpf-writes blocked State-Changed-From-To: open->patched State-Changed-By: emaste State-Changed-When: Thu May 3 01:41:29 UTC 2012 State-Changed-Why: Committed revision 234936. http://www.freebsd.org/cgi/query-pr.cgi?pr=138620 From owner-freebsd-net@FreeBSD.ORG Thu May 3 01:50:15 2012 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 6B166106564A for ; Thu, 3 May 2012 01:50:15 +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 568118FC0A for ; Thu, 3 May 2012 01:50:15 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q431oFdL041081 for ; Thu, 3 May 2012 01:50:15 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q431oFdd041080; Thu, 3 May 2012 01:50:15 GMT (envelope-from gnats) Date: Thu, 3 May 2012 01:50:15 GMT Message-Id: <201205030150.q431oFdd041080@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: dfilter@FreeBSD.ORG (dfilter service) Cc: Subject: Re: kern/138620: commit references a PR X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dfilter service List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2012 01:50:15 -0000 The following reply was made to PR kern/138620; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/138620: commit references a PR Date: Thu, 3 May 2012 01:41:22 +0000 (UTC) Author: emaste Date: Thu May 3 01:41:12 2012 New Revision: 234936 URL: http://svn.freebsd.org/changeset/base/234936 Log: Relax restriction on direct tx to child ports Lagg(4) restricts the type of packet that may be sent directly to a child port, to avoid undesired output from accidental misconfiguration. Previously only ETHERTYPE_PAE was permitted. BPF writes to a lagg(4) child port are presumably intentional, so just allow them, while still blocking other packets that should take the aggregation path. PR: kern/138620 Approved by: thompsa@ Modified: head/sys/net/if_lagg.c Modified: head/sys/net/if_lagg.c ============================================================================== --- head/sys/net/if_lagg.c Wed May 2 21:50:13 2012 (r234935) +++ head/sys/net/if_lagg.c Thu May 3 01:41:12 2012 (r234936) @@ -764,28 +764,18 @@ fallback: return (EINVAL); } +/* + * For direct output to child ports. + */ static int lagg_port_output(struct ifnet *ifp, struct mbuf *m, struct sockaddr *dst, struct route *ro) { struct lagg_port *lp = ifp->if_lagg; - struct ether_header *eh; - short type = 0; switch (dst->sa_family) { case pseudo_AF_HDRCMPLT: case AF_UNSPEC: - eh = (struct ether_header *)dst->sa_data; - type = eh->ether_type; - break; - } - - /* - * Only allow ethernet types required to initiate or maintain the link, - * aggregated frames take a different path. - */ - switch (ntohs(type)) { - case ETHERTYPE_PAE: /* EAPOL PAE/802.1x */ return ((*lp->lp_output)(ifp, m, dst, ro)); } _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Thu May 3 07:48:34 2012 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 DF6E910657C3; Thu, 3 May 2012 07:48:34 +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 655B28FC0C; Thu, 3 May 2012 07:48:34 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q437mYNn000809; Thu, 3 May 2012 07:48:34 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q437mYvj000805; Thu, 3 May 2012 07:48:34 GMT (envelope-from linimon) Date: Thu, 3 May 2012 07:48:34 GMT Message-Id: <201205030748.q437mYvj000805@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/167551: [vimage] Fatal trap 12 jails, vimage, ifconfig destroy epair*a 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, 03 May 2012 07:48:35 -0000 Old Synopsis: Fatal trap 12 jails, vimage, ifconfig destroy epair*a New Synopsis: [vimage] Fatal trap 12 jails, vimage, ifconfig destroy epair*a Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Thu May 3 07:47:53 UTC 2012 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=167551 From owner-freebsd-net@FreeBSD.ORG Thu May 3 08:00:33 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A2A5A1065679 for ; Thu, 3 May 2012 08:00:33 +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 8B0188FC18 for ; Thu, 3 May 2012 08:00:33 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q4380XET010133 for ; Thu, 3 May 2012 08:00:33 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q4380X6S010126; Thu, 3 May 2012 08:00:33 GMT (envelope-from gnats) Date: Thu, 3 May 2012 08:00:33 GMT Message-Id: <201205030800.q4380X6S010126@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Sten Spans Cc: Subject: Re: kern/138620 [patch] Sysctl for direct BPF writes to lagg child ports X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Sten Spans List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2012 08:00:33 -0000 The following reply was made to PR kern/138620; it has been noted by GNATS. From: Sten Spans To: Ed Maste Cc: bug-followup@freebsd.org Subject: Re: kern/138620 [patch] Sysctl for direct BPF writes to lagg child ports Date: Thu, 3 May 2012 09:57:04 +0200 (CEST) On Tue, 1 May 2012, Ed Maste wrote: > The attached patch adds a sysctl to enable or disable the behaviour > you're looking for (direct BPF writes to the underlying lagg child > ports). I intend to commit it shortly after review / test. Awesome, I'll try testing it this weekend. -- Sten Spans "There is a crack in everything, that's how the light gets in." Leonard Cohen - Anthem From owner-freebsd-net@FreeBSD.ORG Thu May 3 10:28:52 2012 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 8E2631065670; Thu, 3 May 2012 10:28:52 +0000 (UTC) (envelope-from snatreju@googlemail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id AEA778FC0A; Thu, 3 May 2012 10:28:51 +0000 (UTC) Received: by bkvi17 with SMTP id i17so1687587bkv.13 for ; Thu, 03 May 2012 03:28:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=zcxGotwkR+HeIibL63OsKVMTBP8p2seI1+OQEQj9D8o=; b=wNkb75IfCmlE+XpjZCN6SyYjkcyaIje9Gt4muiJFLEr4pvm6wUitk8Zgx8U2hK41/c o3ozDIlKcZw5UUcM5e2YGrh+igWmrE3+AlvXHDgmRKvnPabqT32AG6GxITDl79grxL7w qUksHqVGcsoqmPn7Ec3rDqp69XrOLTSz+OsC1tpEuzvY1wmlx89p6ZjlaTBLQUxfajW0 7oejLBByIU0BK4yRWC78HAQZfqs3K0rb8qC7s9abaFlKEYPq1xjx1FwuhyicuAKEkuXZ oVuuYtW7nmyx6DDtUSUjAvQAP0PChgo8pwGU5kE1wy95Fdtn/pk9pHj+3c//AqNWncjn vu9g== Received: by 10.204.131.84 with SMTP id w20mr538439bks.65.1336040930536; Thu, 03 May 2012 03:28:50 -0700 (PDT) Received: from sherwood.local ([89.204.155.34]) by mx.google.com with ESMTPS id gm18sm9414285bkc.7.2012.05.03.03.28.47 (version=SSLv3 cipher=OTHER); Thu, 03 May 2012 03:28:49 -0700 (PDT) Date: Thu, 3 May 2012 12:28:44 +0200 From: Steven Atreju To: "K. Macy" Message-ID: <20120503102844.GU633@sherwood.local> References: <20120502182557.GA93838@onelab2.iet.unipi.it> <20120502215249.GT633@sherwood.local> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Luigi Rizzo , current@freebsd.org, net@freebsd.org Subject: Re: fast bcopy... 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, 03 May 2012 10:28:52 -0000 K. Macy wrote [2012-05-03 02:58+0200]: > It's highly chipset and processor dependent what works best. Yes, of course. Though i was kinda, even shocked, once i've seen this first: http://marc.info/?l=dragonfly-commits&m=132241713812022&w=2 So we don't use our assembler version for new gccs and HAMMER or SSE3+ (the decision for these was rather arbitrarily, except they were yet existent for an instant implementation). > Intel now has non-temporal loads and stores which work much > better in some cases but provide little benefit in others. Yes, our 2002 tests have shown that these were *extremely* dependent upon alignment. (Note: 2002. o-) Hmm, it doesn't really matter, but i guess this is a good time to thank the FreeBSD hackers for that FPU stack FILD/FISTP idea! I'll append the copy related notes of our doc/memperf.txt. Thanks, > -Kip Steven. I. x86 (AMD Athlon 1600+, 256MB DDR, 133/133 FSB) ------------------------------------------------- COPY .... The basic idea is always the same: - Branch off to REPZ MOVSB if less than 16 bytes to go. - Align at least one pointer on a nice boundary (&3 or &7). (Done by a byte loop; one 4/8 store is more expensive here.) We always align the _from pointer due to test experience. - DEPENDENT. - Do the remaining maximally 3 bytes in an unrolled MOVSB way. DEPENDENT: - !SF_FPU && !defined(SF_X86_MMX): just a matter of REPZ MOVSL. - Otherwise we use three different loops over 64, 16 and 8 bytes, respectively. If more than 4 bytes remain after that we use one additional MOVSL. Note that the 8 byte loop is not a loop but executes once only. The big loop uses pairs of MOVNTQ/MOVQ, MOVQ/MOVQ and FILD/FISTP, if _SSE, _MMX or _FPU, respectively. The _SSE loop exists in addition and is never used if the non-aligned (the _to) pointer is not also aligned. The two smaller ones never use SSE's non-temporal moves; this way we simply can go no matter wether the to pointer is aligned or not. Tests demonstrated that non-temporal is no win for them anyway. At the end we add additional SFENCE (if _SSE) and EMMS (_MMX) or FEMMS (if _3DNOW) to serialize the non-temporal moves and clear the MMX state, respectively. The SFENCE should not be needed, however. Prefetching is not used (very bad on Athlon (or i don't understand it)). 1. !_MMX && !_FPU 2. _MMX 3. _FPU (thanks to the FreeBSD crew for this idea!) 4. _MMX+_3DNOW+_SSE implementation (all we have). ([*] times in brackets show which time has been measured if the from pointer alignment loop has a leading '.ALIGN 2' statement; note especially the value for 4096... note this value in general.) UNT: unaligned pointers, to pointer alignment goal UNF: unaligned pointers, from pointer alignment goal 1000 loops; times in (averaged) microseconds P.S.: 03-04-01: SSE stuff disabled because speed for smaller ranges considered to be more important than for large and even more largest ranges. (And small difference for non-perfect ranges and non-aligned pointers.) --------------------------------------------------------------------------- |bytes| 1./ UNT/ UNF | 2./ UNT/ UNF | 3./ UNT/ UNF | 4.[*] / UNF | |-------------------------------------------------------------------------- |16 | 34/ / | 19/ / 37 | 21/ / 37 | 24[ 26]/ 37 | |15 | 40/ / | 39/ / 35 | 37/ / 35 | 38[ 39]/ 35 | |32 | 36/ / | 23/ / 30 | 23/ / 30 | 27[ 30]/ 33 | |31 | 43/ / | 37/ / 28 | 36/ / 28 | 38[ 42]/ 31 | |64 | 45/ / | 17/ / 38 | 17/ / 36 | 21[ 23]/ 39 | |63 | 50/ / | 46/ / 35 | 44/ / 34 | 47[ 50]/ 37 | |128 | 59/ 70/ 74 | 31/ / 45 | 34/ / 47 | 34[ 36]/ 50 | |127 | 67/ 82/ 62 | 53/ / 45 | 51/ / 44 | 62[ 63]/ 50 | |256 | 89/ 111/ 108 | 52/ / 74 | 53/ / 77 | 50[ 50]/ 76 | |255 | 99/ 123/ 96 | 67/ / 73 | 73/ / 75 | 68[ 70]/ 74 | |512 | 151/ 197/ 177 | 95/ / 131 | 98/ / 137 | 84[103]/ 137 | |511 | 158/ 208/ 166 | 100/ / 132 | 117/ / 134 | 99[112]/ 135 | |1024 | 274/ 395/ 314 | 179/ / 255 | 211/ / 270 | 166[207]/ 257 | |1023 | 280/ 408/ 303 | 196/ / 253 | 225/ / 267 | 184[185]/ 253 | |2048 | 579/ 765/ 966 | 350/ / 485 | 394/ / 511 | 389[388]/ 486 | |2047 | 585/ 777/ 942 | 368/ / 484 | 410/ / 520 | 323[398]/ 484 | |4096 | 1009/1385/1140 | 704/ /1036 | 761/ /1040 | 671[583]/1038 | |4095 | 1027/1386/1130 | 721/ /1034 | 776/ /1037 | 602[604]/1035 | |-------------------------------------------------------------------------- P.S.: ooops - i've really forgotten that the SSE stuff has been completely disabled at a later time! I guess we'll have to redo some testing eventually! From owner-freebsd-net@FreeBSD.ORG Thu May 3 10:49:40 2012 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 80710106564A; Thu, 3 May 2012 10:49:40 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 85E268FC08; Thu, 3 May 2012 10:49:39 +0000 (UTC) Received: by lagv3 with SMTP id v3so1563843lag.13 for ; Thu, 03 May 2012 03:49:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=c5db86wHEhm02qq6fQ2SecJmHD8Aq0D32Oblle5MatA=; b=tANeaMcTEAeCo0vRhWXOZ6VqPr8fl2ulFbLIVOUJKZzs6SPRgrsxtREeHKqYcrCQf7 fzYb29R/ZG6TQSNO12uLkNtpvriYibvMcY2BgS/UYK2F6ZEc0r5e04v7ghVTEKaqiJif B6rwJnaCpF2ngLaM5NKCNs1xDrxXCDfCyegkNcmrDhP+FF9EnTPG8DjUA2HBc+N0sowJ 8Iun/Cn1/vhVuGcv+q4qoshf0/2yQhOYYHkW02DyVH8yLEP0KbpQdPQo2bSdxg5jIOJC Ri6PGvkaXrJQuJPSDTYE0epq5S+MFAh7BUGaMq/rYjQh0MnbJZvR7xzaCglNWk2BBE38 utOQ== MIME-Version: 1.0 Received: by 10.152.132.166 with SMTP id ov6mr1757981lab.35.1336042178447; Thu, 03 May 2012 03:49:38 -0700 (PDT) Sender: asmrookie@gmail.com Received: by 10.112.27.65 with HTTP; Thu, 3 May 2012 03:49:38 -0700 (PDT) In-Reply-To: <20120503102844.GU633@sherwood.local> References: <20120502182557.GA93838@onelab2.iet.unipi.it> <20120502215249.GT633@sherwood.local> <20120503102844.GU633@sherwood.local> Date: Thu, 3 May 2012 11:49:38 +0100 X-Google-Sender-Auth: Woi8Qh4LWGNtIwv5ifqXkdsIsHY Message-ID: From: Attilio Rao To: Steven Atreju Content-Type: text/plain; charset=UTF-8 Cc: net@freebsd.org, Luigi Rizzo , "K. Macy" , current@freebsd.org Subject: Re: fast bcopy... 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, 03 May 2012 10:49:40 -0000 2012/5/3, Steven Atreju : > K. Macy wrote [2012-05-03 02:58+0200]: >> It's highly chipset and processor dependent what works best. > > Yes, of course. > Though i was kinda, even shocked, once i've seen this first: > > http://marc.info/?l=dragonfly-commits&m=132241713812022&w=2 > > So we don't use our assembler version for new gccs and HAMMER or > SSE3+ (the decision for these was rather arbitrarily, except they > were yet existent for an instant implementation). > >> Intel now has non-temporal loads and stores which work much >> better in some cases but provide little benefit in others. > > Yes, our 2002 tests have shown that these were *extremely* > dependent upon alignment. (Note: 2002. o-) > Hmm, it doesn't really matter, but i guess this is a good time to > thank the FreeBSD hackers for that FPU stack FILD/FISTP idea! > I'll append the copy related notes of our doc/memperf.txt. > Thanks, I made an implementation of fpu unwinding and mmx copy to see if they were really making a difference years ago (reimplementing bcopy, memcopy, etc.). What really mattered with hw available at that time (pentium4) was the alignment and use of non-temporal operations on heavilly contended cache-lines. In few words it is more important we engineer the "buffer" layout rather than the functions themselves. Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-net@FreeBSD.ORG Thu May 3 12:48:25 2012 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 A3F55106564A; Thu, 3 May 2012 12:48:25 +0000 (UTC) (envelope-from gabor@FreeBSD.org) Received: from server.mypc.hu (server.mypc.hu [87.229.73.95]) by mx1.freebsd.org (Postfix) with ESMTP id 518568FC12; Thu, 3 May 2012 12:48:25 +0000 (UTC) Received: from server.mypc.hu (localhost [127.0.0.1]) by server.mypc.hu (Postfix) with ESMTP id ED81614E7489; Thu, 3 May 2012 14:48:15 +0200 (CEST) X-Virus-Scanned: amavisd-new at server.mypc.hu Received: from server.mypc.hu ([127.0.0.1]) by server.mypc.hu (server.mypc.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id FhLi_YgRQdce; Thu, 3 May 2012 14:48:14 +0200 (CEST) Received: from [84.224.160.154] (netacc-gpn-4-160-154.pool.telenor.hu [84.224.160.154]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by server.mypc.hu (Postfix) with ESMTPSA id 4771A14E730B; Thu, 3 May 2012 14:48:14 +0200 (CEST) Message-ID: <4FA27E8F.2040402@FreeBSD.org> Date: Thu, 03 May 2012 14:48:15 +0200 From: Gabor Kovesdan User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Steven Atreju References: <20120502182557.GA93838@onelab2.iet.unipi.it> <20120502215249.GT633@sherwood.local> <20120503102844.GU633@sherwood.local> In-Reply-To: <20120503102844.GU633@sherwood.local> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: net@freebsd.org, Luigi Rizzo , "K. Macy" , current@freebsd.org Subject: Re: fast bcopy... 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, 03 May 2012 12:48:25 -0000 Em 03-05-2012 12:28, Steven Atreju escreveu: > Yes, of course. > Though i was kinda, even shocked, once i've seen this first: > > http://marc.info/?l=dragonfly-commits&m=132241713812022&w=2 I also experimented a bit with some trivial libc functions when testing a change for memcpy (still in queue, will send it out for review once I have some more detailed benchamrks) and I also noticed that sometimes the trivial C version performed just like the assembly code. It is definitely something that needs some cleanup and I'm interested in working on it but cannot afford too much time at the moment. Gabor From owner-freebsd-net@FreeBSD.ORG Thu May 3 16:17:44 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4303A1065675; Thu, 3 May 2012 16:17:44 +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 F39DE8FC0A; Thu, 3 May 2012 16:17:43 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 6779D7300A; Thu, 3 May 2012 18:37:36 +0200 (CEST) Date: Thu, 3 May 2012 18:37:36 +0200 From: Luigi Rizzo To: net@freebsd.org, current@freebsd.org Message-ID: <20120503163736.GA4920@onelab2.iet.unipi.it> References: <20120419133018.GA91364@onelab2.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120419133018.GA91364@onelab2.iet.unipi.it> User-Agent: Mutt/1.4.2.3i Cc: Subject: Re: Some performance measurements on the FreeBSD network stack 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, 03 May 2012 16:17:44 -0000 On Thu, Apr 19, 2012 at 03:30:18PM +0200, Luigi Rizzo wrote: > I have been running some performance tests on UDP sockets, > using the netsend program in tools/tools/netrate/netsend > and instrumenting the source code and the kernel do return in > various points of the path. Here are some results which > I hope you find interesting. ... I have summarized the info on this thread in the camera ready version of an upcoming Usenix paper, which you can find here: http://info.iet.unipi.it/~luigi/papers/20120503-netmap-atc12.pdf cheers luigi From owner-freebsd-net@FreeBSD.ORG Thu May 3 16:24:29 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DB7E51065677; Thu, 3 May 2012 16:24:29 +0000 (UTC) (envelope-from rozhuk.im@gmail.com) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id E75D88FC0C; Thu, 3 May 2012 16:24:28 +0000 (UTC) Received: by eekd17 with SMTP id d17so639557eek.13 for ; Thu, 03 May 2012 09:24:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=reply-to:from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=y/Wk57otpV9B6GISLYgcWSvou9kxLcd/XtAwj+JdFaQ=; b=ZkcgigvcArswmkRsN5lG5UwKFN6Mn5Us5sbOrMQxPen/PxcXkBqTy0ulPcirvaSSV8 erSBKKek/d94ygvBB1Kgu1wEUi++onGshH3A8yp7KRzSv+Qzxrrlrnkuv/qiOdBokf3D MR+xqZ2kC6RaOsvjCJHxV49Novkw6zTLkJ5J3/OMm9rU+TBEdPpCBUI+S3MtRhdhIqEw 5vuejnxmjcaRzDIQgtplb73rQz27LURf2fIYPPfgXJrSL8H5dLwmrd7WE2BPyRqXd8r6 615UC8do7jNPm+LxmKWQvtpQIZ2F4ZeFKcmqJHUZeLO3kpAS6BFZi3YZnhbypwlGPHtx 1law== Received: by 10.213.25.220 with SMTP id a28mr428495ebc.88.1336062262470; Thu, 03 May 2012 09:24:22 -0700 (PDT) Received: from rimwks1w7x64 ([164.215.95.17]) by mx.google.com with ESMTPS id r44sm27684927eef.2.2012.05.03.09.24.18 (version=SSLv3 cipher=OTHER); Thu, 03 May 2012 09:24:21 -0700 (PDT) From: rozhuk.im@gmail.com To: "'Attilio Rao'" , "'Steven Atreju'" References: <20120502182557.GA93838@onelab2.iet.unipi.it> <20120502215249.GT633@sherwood.local> <20120503102844.GU633@sherwood.local> In-Reply-To: Date: Fri, 4 May 2012 01:24:11 +0900 Message-ID: <4fa2b135.c4600e0a.153f.03f9@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 thread-index: Ac0pGs90ju5hdBweRg2lwkSX0/opcQALSi1A Content-Language: ru Cc: current@freebsd.org, 'Luigi Rizzo' , "'K. Macy'" , net@freebsd.org Subject: RE: fast bcopy... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Rozhuk.IM@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2012 16:24:30 -0000 > > guess this is a good time to thank the FreeBSD hackers for that FPU > > stack FILD/FISTP idea! > > I'll append the copy related notes of our doc/memperf.txt. > > Thanks, >=20 > I made an implementation of fpu unwinding and mmx copy to see if they > were really making a difference years ago (reimplementing bcopy, > memcopy, etc.). Codecs, such as Ffdshow often contain their own functions to work with = memory. From owner-freebsd-net@FreeBSD.ORG Thu May 3 16:53:43 2012 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 28A971065677 for ; Thu, 3 May 2012 16:53:43 +0000 (UTC) (envelope-from bschmidt@techwires.net) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 1C9598FC1B for ; Thu, 3 May 2012 16:53:41 +0000 (UTC) Received: by bkvi17 with SMTP id i17so2157766bkv.13 for ; Thu, 03 May 2012 09:53:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:from:to:subject:date:user-agent:cc:mime-version:content-type :message-id:x-gm-message-state; bh=VplpBaQaz3xbxMIJBQoY8jBMjG4qj5HfUV2360/mDXw=; b=BcyuSP94UDMIFZzN79wql8HqpVkDd6qUVPm3VzE3/BZSQj5ozpeqqmsZHcrZWDSQ6/ fQpg7jDlJUc1Q4Cpy58SuTVQhAMnkFlgGspI1ubcM9LDTmAT9gN2cfGLdtmupf7eMFHH dbfoZqkE7k5TgiaaDqDCyz+T/zHKubXXZCuYAXDttIhXZE7h7HfUESSfv/ypFGubc0vl k3/r1U2HaxQyPsl5H4dFQRu5bXIjyIKg4uK1MblMb/W4ZJq1QmH8Mn4DIUHptrQ4O2dD B6rWZhl1Q1NJI6AsATjFQ5IwbKLz79dX/Cdw48DR786KNfHKFSXlhnFkEFOJfL1aPcns IJDg== Received: by 10.204.141.25 with SMTP id k25mr934691bku.72.1336064020804; Thu, 03 May 2012 09:53:40 -0700 (PDT) Received: from amy.lab.techwires.net (dslb-094-217-143-073.pools.arcor-ip.net. [94.217.143.73]) by mx.google.com with ESMTPS id n17sm11904912bkw.5.2012.05.03.09.53.27 (version=SSLv3 cipher=OTHER); Thu, 03 May 2012 09:53:40 -0700 (PDT) Sender: Bernhard Schmidt From: Bernhard Schmidt To: freebsd-wireless@freebsd.org Date: Thu, 3 May 2012 18:53:52 +0200 User-Agent: KMail/1.13.7 (FreeBSD/9.0-STABLE; KDE/4.7.4; amd64; ; ) MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_ggroP1S39UUHyDC" Message-Id: <201205031853.53102.bschmidt@freebsd.org> X-Gm-Message-State: ALoCoQli8aVWsrUl1OjKlY1Xgn7hQX1D2OJqD0Vca4p3geLedG8cL2soHRgUxLftyaUBFwPMc/oz Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org Subject: [CFT] Ralink RT2860, RT2870, RT3060, RT3090 support 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, 03 May 2012 16:53:43 -0000 --Boundary-00=_ggroP1S39UUHyDC Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi folks, As some of you might know there has been some work going on porting support for new Ralink chipsets from OpenBSD. Several different drivers where floating around but nothing seemed to be decent enough to be committed. ray@ and I had been working on cleaning up one of those to get it into a good enough shape, but abandoned this approach as it resulted in more work than starting from scratch. So, attached diff [1] is a from-scratch effort to port over support for the new chipsets. It doesn't contain fancy stuff like 802.11n support as of yet (this will be worked one once the legacy stuff is in HEAD), nonetheless it showed pretty decent performance during the basic sta/adhoc/hostap tests I've done. I'd appreciate testing and feedback ;) The diff requires HEAD due to the firmware being available only there, though, if there are enough requests, I might consider looking into getting it merged to 9. (Simply pulling sys/modules/ralfw/ and sys/contrib/dev/ral/ from HEAD might be enough I guess.) [1] http://techwires.net/~bschmidt/rt2860.diff -- Bernhard --Boundary-00=_ggroP1S39UUHyDC Content-Type: text/x-patch; charset="UTF-8"; name="rt2860.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="rt2860.diff" Index: sys/conf/files =================================================================== --- sys/conf/files (revision 234847) +++ sys/conf/files (working copy) @@ -1759,6 +1759,7 @@ dev/puc/pucdata.c optional puc pci dev/quicc/quicc_core.c optional quicc dev/ral/rt2560.c optional ral dev/ral/rt2661.c optional ral +dev/ral/rt2860.c optional ral dev/ral/if_ral_pci.c optional ral pci rt2561fw.c optional rt2561fw | ralfw \ compile-with "${AWK} -f $S/tools/fw_stub.awk rt2561.fw:rt2561fw -mrt2561 -c${.TARGET}" \ Index: sys/modules/ral/Makefile =================================================================== --- sys/modules/ral/Makefile (revision 234847) +++ sys/modules/ral/Makefile (working copy) @@ -3,7 +3,7 @@ .PATH: ${.CURDIR}/../../dev/ral KMOD= if_ral -SRCS= rt2560.c rt2661.c if_ral_pci.c +SRCS= rt2560.c rt2661.c rt2860.c if_ral_pci.c SRCS+= device_if.h bus_if.h pci_if.h .include Index: sys/dev/ral/rt2860.c =================================================================== --- sys/dev/ral/rt2860.c (revision 0) +++ sys/dev/ral/rt2860.c (working copy) @@ -0,0 +1,4110 @@ +/* $FreeBSD$ */ +/* $OpenBSD: rt2860.c,v 1.65 2010/10/23 14:24:54 damien Exp $ */ + +/*- + * Copyright (c) 2007-2010 Damien Bergamini + * Copyright (c) 2012 Bernhard Schmidt + * + * 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. + */ + +#include +__FBSDID("$FreeBSD$"); + +/*- + * Ralink Technology RT2860/RT3090/RT3390/RT3562 chipset driver + * http://www.ralinktech.com/ + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include + +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include + +#include +#include +#include +#include +#include + +#include +#include + +#define RAL_DEBUG +#ifdef RAL_DEBUG +#define DPRINTF(x) do { if (sc->sc_debug > 0) printf x; } while (0) +#define DPRINTFN(n, x) do { if (sc->sc_debug >= (n)) printf x; } while (0) +int rt2860_debug = 0; +#else +#define DPRINTF(x) +#define DPRINTFN(n, x) +#endif + +static struct ieee80211vap *rt2860_vap_create(struct ieee80211com *, + const char [IFNAMSIZ], int, enum ieee80211_opmode, + int, const uint8_t [IEEE80211_ADDR_LEN], + const uint8_t [IEEE80211_ADDR_LEN]); +static void rt2860_vap_delete(struct ieee80211vap *); +static void rt2860_dma_map_addr(void *, bus_dma_segment_t *, int, int); +static int rt2860_alloc_tx_ring(struct rt2860_softc *, + struct rt2860_tx_ring *); +static void rt2860_reset_tx_ring(struct rt2860_softc *, + struct rt2860_tx_ring *); +static void rt2860_free_tx_ring(struct rt2860_softc *, + struct rt2860_tx_ring *); +static int rt2860_alloc_tx_pool(struct rt2860_softc *); +static void rt2860_free_tx_pool(struct rt2860_softc *); +static int rt2860_alloc_rx_ring(struct rt2860_softc *, + struct rt2860_rx_ring *); +static void rt2860_reset_rx_ring(struct rt2860_softc *, + struct rt2860_rx_ring *); +static void rt2860_free_rx_ring(struct rt2860_softc *, + struct rt2860_rx_ring *); +static void rt2860_updatestats(struct rt2860_softc *); +static void rt2860_newassoc(struct ieee80211_node *, int); +static void rt2860_node_free(struct ieee80211_node *); +#ifdef IEEE80211_HT +static int rt2860_ampdu_rx_start(struct ieee80211com *, + struct ieee80211_node *, uint8_t); +static void rt2860_ampdu_rx_stop(struct ieee80211com *, + struct ieee80211_node *, uint8_t); +#endif +static int rt2860_newstate(struct ieee80211vap *, enum ieee80211_state, + int); +static uint16_t rt3090_efuse_read_2(struct rt2860_softc *, uint16_t); +static uint16_t rt2860_eeprom_read_2(struct rt2860_softc *, uint16_t); +static void rt2860_intr_coherent(struct rt2860_softc *); +static void rt2860_drain_stats_fifo(struct rt2860_softc *); +static void rt2860_tx_intr(struct rt2860_softc *, int); +static void rt2860_rx_intr(struct rt2860_softc *); +static void rt2860_tbtt_intr(struct rt2860_softc *); +static void rt2860_gp_intr(struct rt2860_softc *); +static int rt2860_tx(struct rt2860_softc *, struct mbuf *, + struct ieee80211_node *); +static int rt2860_raw_xmit(struct ieee80211_node *, struct mbuf *, + const struct ieee80211_bpf_params *); +static int rt2860_tx_raw(struct rt2860_softc *, struct mbuf *, + struct ieee80211_node *, + const struct ieee80211_bpf_params *params); +static void rt2860_start(struct ifnet *); +static void rt2860_start_locked(struct ifnet *); +static void rt2860_watchdog(void *); +static int rt2860_ioctl(struct ifnet *, u_long, caddr_t); +static void rt2860_mcu_bbp_write(struct rt2860_softc *, uint8_t, uint8_t); +static uint8_t rt2860_mcu_bbp_read(struct rt2860_softc *, uint8_t); +static void rt2860_rf_write(struct rt2860_softc *, uint8_t, uint32_t); +static uint8_t rt3090_rf_read(struct rt2860_softc *, uint8_t); +static void rt3090_rf_write(struct rt2860_softc *, uint8_t, uint8_t); +static int rt2860_mcu_cmd(struct rt2860_softc *, uint8_t, uint16_t, int); +static void rt2860_enable_mrr(struct rt2860_softc *); +static void rt2860_set_txpreamble(struct rt2860_softc *); +static void rt2860_set_basicrates(struct rt2860_softc *, + const struct ieee80211_rateset *); +static void rt2860_scan_start(struct ieee80211com *); +static void rt2860_scan_end(struct ieee80211com *); +static void rt2860_set_channel(struct ieee80211com *); +static void rt2860_select_chan_group(struct rt2860_softc *, int); +static void rt2860_set_chan(struct rt2860_softc *, u_int); +static void rt3090_set_chan(struct rt2860_softc *, u_int); +static int rt3090_rf_init(struct rt2860_softc *); +static void rt3090_rf_wakeup(struct rt2860_softc *); +static int rt3090_filter_calib(struct rt2860_softc *, uint8_t, uint8_t, + uint8_t *); +static void rt3090_rf_setup(struct rt2860_softc *); +static void rt2860_set_leds(struct rt2860_softc *, uint16_t); +static void rt2860_set_gp_timer(struct rt2860_softc *, int); +static void rt2860_set_bssid(struct rt2860_softc *, const uint8_t *); +static void rt2860_set_macaddr(struct rt2860_softc *, const uint8_t *); +static void rt2860_update_promisc(struct ifnet *); +static void rt2860_updateslot(struct ifnet *); +static void rt2860_updateprot(struct ifnet *); +static int rt2860_updateedca(struct ieee80211com *); +#ifdef HW_CRYPTO +static int rt2860_set_key(struct ieee80211com *, struct ieee80211_node *, + struct ieee80211_key *); +static void rt2860_delete_key(struct ieee80211com *, + struct ieee80211_node *, struct ieee80211_key *); +#endif +static int8_t rt2860_rssi2dbm(struct rt2860_softc *, uint8_t, uint8_t); +static const char *rt2860_get_rf(uint8_t); +static int rt2860_read_eeprom(struct rt2860_softc *, + uint8_t macaddr[IEEE80211_ADDR_LEN]); +static int rt2860_bbp_init(struct rt2860_softc *); +static int rt2860_txrx_enable(struct rt2860_softc *); +static void rt2860_init(void *); +static void rt2860_init_locked(struct rt2860_softc *); +static void rt2860_stop(void *); +static void rt2860_stop_locked(struct rt2860_softc *); +static int rt2860_load_microcode(struct rt2860_softc *); +#ifdef NOT_YET +static void rt2860_calib(struct rt2860_softc *); +#endif +static void rt3090_set_rx_antenna(struct rt2860_softc *, int); +static void rt2860_switch_chan(struct rt2860_softc *, + struct ieee80211_channel *); +static int rt2860_setup_beacon(struct rt2860_softc *, + struct ieee80211vap *); +static void rt2860_enable_tsf_sync(struct rt2860_softc *); + +static const struct { + uint32_t reg; + uint32_t val; +} rt2860_def_mac[] = { + RT2860_DEF_MAC +}; + +static const struct { + uint8_t reg; + uint8_t val; +} rt2860_def_bbp[] = { + RT2860_DEF_BBP +}; + +static const struct rfprog { + uint8_t chan; + uint32_t r1, r2, r3, r4; +} rt2860_rf2850[] = { + RT2860_RF2850 +}; + +struct { + uint8_t n, r, k; +} rt3090_freqs[] = { + RT3070_RF3052 +}; + +static const struct { + uint8_t reg; + uint8_t val; +} rt3090_def_rf[] = { + RT3070_DEF_RF +}; + +int +rt2860_attach(device_t dev, int id) +{ + struct rt2860_softc *sc = device_get_softc(dev); + struct ieee80211com *ic; + struct ifnet *ifp; + uint32_t tmp; + int error, ntries, qid; + uint8_t bands; + uint8_t macaddr[IEEE80211_ADDR_LEN]; + + sc->sc_dev = dev; + + ifp = sc->sc_ifp = if_alloc(IFT_IEEE80211); + if (ifp == NULL) { + device_printf(sc->sc_dev, "can not if_alloc()\n"); + return ENOMEM; + } + ic = ifp->if_l2com; + + mtx_init(&sc->sc_mtx, device_get_nameunit(dev), MTX_NETWORK_LOCK, + MTX_DEF | MTX_RECURSE); + + callout_init_mtx(&sc->watchdog_ch, &sc->sc_mtx, 0); + + /* wait for NIC to initialize */ + for (ntries = 0; ntries < 100; ntries++) { + tmp = RAL_READ(sc, RT2860_ASIC_VER_ID); + if (tmp != 0 && tmp != 0xffffffff) + break; + DELAY(10); + } + if (ntries == 100) { + device_printf(sc->sc_dev, + "timeout waiting for NIC to initialize\n"); + error = EIO; + goto fail1; + } + sc->mac_ver = tmp >> 16; + sc->mac_rev = tmp & 0xffff; + + if (sc->mac_ver != 0x2860 && + (id == 0x0681 || id == 0x0781 || id == 0x1059)) + sc->sc_flags |= RT2860_ADVANCED_PS; + + /* retrieve RF rev. no and various other things from EEPROM */ + rt2860_read_eeprom(sc, macaddr); + device_printf(sc->sc_dev, + "MAC/BBP RT%X (rev 0x%04X), RF %s (MIMO %dT%dR)\n", + sc->mac_ver, sc->mac_rev, rt2860_get_rf(sc->rf_rev), + sc->ntxchains, sc->nrxchains); + + /* + * Allocate Tx (4 EDCAs + HCCA + Mgt) and Rx rings. + */ + for (qid = 0; qid < 6; qid++) { + if ((error = rt2860_alloc_tx_ring(sc, &sc->txq[qid])) != 0) { + device_printf(sc->sc_dev, + "could not allocate Tx ring %d\n", qid); + goto fail2; + } + } + + if ((error = rt2860_alloc_rx_ring(sc, &sc->rxq)) != 0) { + device_printf(sc->sc_dev, "could not allocate Rx ring\n"); + goto fail2; + } + + if ((error = rt2860_alloc_tx_pool(sc)) != 0) { + device_printf(sc->sc_dev, "could not allocate Tx pool\n"); + goto fail3; + } + + /* mgmt ring is broken on RT2860C, use EDCA AC VO ring instead */ + sc->mgtqid = (sc->mac_ver == 0x2860 && sc->mac_rev == 0x0100) ? + WME_AC_VO : 5; + + ifp->if_softc = sc; + if_initname(ifp, device_get_name(dev), device_get_unit(dev)); + ifp->if_flags = IFF_BROADCAST | IFF_SIMPLEX | IFF_MULTICAST; + ifp->if_init = rt2860_init; + ifp->if_ioctl = rt2860_ioctl; + ifp->if_start = rt2860_start; + IFQ_SET_MAXLEN(&ifp->if_snd, ifqmaxlen); + ifp->if_snd.ifq_drv_maxlen = ifqmaxlen; + IFQ_SET_READY(&ifp->if_snd); + + ic->ic_ifp = ifp; + ic->ic_opmode = IEEE80211_M_STA; + ic->ic_phytype = IEEE80211_T_OFDM; /* not only, but not used */ + + /* set device capabilities */ + ic->ic_caps = + IEEE80211_C_STA /* station mode */ + | IEEE80211_C_IBSS /* ibss, nee adhoc, mode */ + | IEEE80211_C_HOSTAP /* hostap mode */ + | IEEE80211_C_MONITOR /* monitor mode */ + | IEEE80211_C_AHDEMO /* adhoc demo mode */ + | IEEE80211_C_WDS /* 4-address traffic works */ + | IEEE80211_C_MBSS /* mesh point link mode */ + | IEEE80211_C_SHPREAMBLE /* short preamble supported */ + | IEEE80211_C_SHSLOT /* short slot time supported */ + | IEEE80211_C_WPA /* capable of WPA1+WPA2 */ + | IEEE80211_C_BGSCAN /* capable of bg scanning */ + | IEEE80211_C_WME /* 802.11e */ + ; + + bands = 0; + setbit(&bands, IEEE80211_MODE_11B); + setbit(&bands, IEEE80211_MODE_11G); + if (sc->rf_rev == RT2860_RF_2750 || sc->rf_rev == RT2860_RF_2850) + setbit(&bands, IEEE80211_MODE_11A); + ieee80211_init_channels(ic, NULL, &bands); + + ieee80211_ifattach(ic, macaddr); + + ic->ic_wme.wme_update = rt2860_updateedca; + ic->ic_scan_start = rt2860_scan_start; + ic->ic_scan_end = rt2860_scan_end; + ic->ic_set_channel = rt2860_set_channel; + ic->ic_updateslot = rt2860_updateslot; + ic->ic_update_promisc = rt2860_update_promisc; + ic->ic_raw_xmit = rt2860_raw_xmit; + sc->sc_node_free = ic->ic_node_free; + ic->ic_node_free = rt2860_node_free; + ic->ic_newassoc = rt2860_newassoc; + + ic->ic_vap_create = rt2860_vap_create; + ic->ic_vap_delete = rt2860_vap_delete; + + ieee80211_radiotap_attach(ic, + &sc->sc_txtap.wt_ihdr, sizeof(sc->sc_txtap), + RT2860_TX_RADIOTAP_PRESENT, + &sc->sc_rxtap.wr_ihdr, sizeof(sc->sc_rxtap), + RT2860_RX_RADIOTAP_PRESENT); + +#ifdef RAL_DEBUG + SYSCTL_ADD_INT(device_get_sysctl_ctx(dev), + SYSCTL_CHILDREN(device_get_sysctl_tree(dev)), OID_AUTO, + "debug", CTLFLAG_RW, &sc->sc_debug, 0, "debug msgs"); +#endif + if (bootverbose) + ieee80211_announce(ic); + + return 0; + +fail3: rt2860_free_rx_ring(sc, &sc->rxq); +fail2: while (--qid >= 0) + rt2860_free_tx_ring(sc, &sc->txq[qid]); +fail1: mtx_destroy(&sc->sc_mtx); + if_free(ifp); + return error; +} + +int +rt2860_detach(void *xsc) +{ + struct rt2860_softc *sc = xsc; + struct ifnet *ifp = sc->sc_ifp; + struct ieee80211com *ic = ifp->if_l2com; + int qid; + + RAL_LOCK(sc); + rt2860_stop_locked(sc); + RAL_UNLOCK(sc); + + ieee80211_ifdetach(ic); + + for (qid = 0; qid < 6; qid++) + rt2860_free_tx_ring(sc, &sc->txq[qid]); + rt2860_free_rx_ring(sc, &sc->rxq); + rt2860_free_tx_pool(sc); + + if_free(ifp); + + mtx_destroy(&sc->sc_mtx); + + return 0; +} + +void +rt2860_shutdown(void *xsc) +{ + struct rt2860_softc *sc = xsc; + + rt2860_stop(sc); +} + +void +rt2860_suspend(void *xsc) +{ + struct rt2860_softc *sc = xsc; + + rt2860_stop(sc); +} + +void +rt2860_resume(void *xsc) +{ + struct rt2860_softc *sc = xsc; + struct ifnet *ifp = sc->sc_ifp; + + if (ifp->if_flags & IFF_UP) + rt2860_init(sc); +} + +static struct ieee80211vap * +rt2860_vap_create(struct ieee80211com *ic, const char name[IFNAMSIZ], int unit, + enum ieee80211_opmode opmode, int flags, + const uint8_t bssid[IEEE80211_ADDR_LEN], + const uint8_t mac[IEEE80211_ADDR_LEN]) +{ + struct ifnet *ifp = ic->ic_ifp; + struct rt2860_vap *rvp; + struct ieee80211vap *vap; + + switch (opmode) { + case IEEE80211_M_STA: + case IEEE80211_M_IBSS: + case IEEE80211_M_AHDEMO: + case IEEE80211_M_MONITOR: + case IEEE80211_M_HOSTAP: + case IEEE80211_M_MBSS: + /* XXXRP: TBD */ + if (!TAILQ_EMPTY(&ic->ic_vaps)) { + if_printf(ifp, "only 1 vap supported\n"); + return NULL; + } + if (opmode == IEEE80211_M_STA) + flags |= IEEE80211_CLONE_NOBEACONS; + break; + case IEEE80211_M_WDS: + if (TAILQ_EMPTY(&ic->ic_vaps) || + ic->ic_opmode != IEEE80211_M_HOSTAP) { + if_printf(ifp, "wds only supported in ap mode\n"); + return NULL; + } + /* + * Silently remove any request for a unique + * bssid; WDS vap's always share the local + * mac address. + */ + flags &= ~IEEE80211_CLONE_BSSID; + break; + default: + if_printf(ifp, "unknown opmode %d\n", opmode); + return NULL; + } + rvp = malloc(sizeof(struct rt2860_vap), M_80211_VAP, M_NOWAIT | M_ZERO); + if (rvp == NULL) + return NULL; + vap = &rvp->ral_vap; + ieee80211_vap_setup(ic, vap, name, unit, opmode, flags, bssid, mac); + + /* override state transition machine */ + rvp->ral_newstate = vap->iv_newstate; + vap->iv_newstate = rt2860_newstate; +#if 0 + vap->iv_update_beacon = rt2860_beacon_update; +#endif + + /* HW supports up to 255 STAs (0-254) in HostAP and IBSS modes */ + vap->iv_max_aid = min(IEEE80211_AID_MAX, RT2860_WCID_MAX); + + ieee80211_ratectl_init(vap); + /* complete setup */ + ieee80211_vap_attach(vap, ieee80211_media_change, ieee80211_media_status); + if (TAILQ_FIRST(&ic->ic_vaps) == vap) + ic->ic_opmode = opmode; + return vap; +} + +static void +rt2860_vap_delete(struct ieee80211vap *vap) +{ + struct rt2860_vap *rvp = RT2860_VAP(vap); + + ieee80211_ratectl_deinit(vap); + ieee80211_vap_detach(vap); + free(rvp, M_80211_VAP); +} + +static void +rt2860_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; +} + + +static int +rt2860_alloc_tx_ring(struct rt2860_softc *sc, struct rt2860_tx_ring *ring) +{ + int size, error; + + size = RT2860_TX_RING_COUNT * sizeof (struct rt2860_txd); + + error = bus_dma_tag_create(bus_get_dma_tag(sc->sc_dev), 16, 0, + BUS_SPACE_MAXADDR_32BIT, BUS_SPACE_MAXADDR, NULL, NULL, + size, 1, size, 0, NULL, NULL, &ring->desc_dmat); + if (error != 0) { + device_printf(sc->sc_dev, "could not create desc DMA map\n"); + goto fail; + } + + error = bus_dmamem_alloc(ring->desc_dmat, (void **)&ring->txd, + BUS_DMA_NOWAIT | BUS_DMA_ZERO, &ring->desc_map); + if (error != 0) { + device_printf(sc->sc_dev, "could not allocate DMA memory\n"); + goto fail; + } + + error = bus_dmamap_load(ring->desc_dmat, ring->desc_map, ring->txd, + size, rt2860_dma_map_addr, &ring->paddr, 0); + if (error != 0) { + device_printf(sc->sc_dev, "could not load desc DMA map\n"); + goto fail; + } + + bus_dmamap_sync(ring->desc_dmat, ring->desc_map, BUS_DMASYNC_PREWRITE); + + error = bus_dma_tag_create(bus_get_dma_tag(sc->sc_dev), 1, 0, + BUS_SPACE_MAXADDR_32BIT, BUS_SPACE_MAXADDR, NULL, NULL, MCLBYTES, + RT2860_MAX_SCATTER, MCLBYTES, 0, NULL, NULL, &ring->data_dmat); + if (error != 0) { + device_printf(sc->sc_dev, "could not create data DMA tag\n"); + goto fail; + } + + return 0; + +fail: rt2860_free_tx_ring(sc, ring); + return error; +} + +void +rt2860_reset_tx_ring(struct rt2860_softc *sc, struct rt2860_tx_ring *ring) +{ + struct rt2860_tx_data *data; + int i; + + for (i = 0; i < RT2860_TX_RING_COUNT; i++) { + if ((data = ring->data[i]) == NULL) + continue; /* nothing mapped in this slot */ + + if (data->m != NULL) { + bus_dmamap_sync(ring->data_dmat, data->map, + BUS_DMASYNC_POSTWRITE); + bus_dmamap_unload(ring->data_dmat, data->map); + m_freem(data->m); + data->m = NULL; + } + if (data->ni != NULL) { + ieee80211_free_node(data->ni); + data->ni = NULL; + } + + SLIST_INSERT_HEAD(&sc->data_pool, data, next); + ring->data[i] = NULL; + } + + ring->queued = 0; + ring->cur = ring->next = 0; +} + +void +rt2860_free_tx_ring(struct rt2860_softc *sc, struct rt2860_tx_ring *ring) +{ + struct rt2860_tx_data *data; + int i; + + if (ring->txd != NULL) { + bus_dmamap_sync(ring->desc_dmat, ring->desc_map, + BUS_DMASYNC_POSTWRITE); + bus_dmamap_unload(ring->desc_dmat, ring->desc_map); + bus_dmamem_free(ring->desc_dmat, ring->txd, ring->desc_map); + } + if (ring->desc_dmat != NULL) + bus_dma_tag_destroy(ring->desc_dmat); + + for (i = 0; i < RT2860_TX_RING_COUNT; i++) { + if ((data = ring->data[i]) == NULL) + continue; /* nothing mapped in this slot */ + + if (data->m != NULL) { + bus_dmamap_sync(ring->data_dmat, data->map, + BUS_DMASYNC_POSTWRITE); + bus_dmamap_unload(ring->data_dmat, data->map); + m_freem(data->m); + } + if (data->ni != NULL) + ieee80211_free_node(data->ni); + + SLIST_INSERT_HEAD(&sc->data_pool, data, next); + } +} + +/* + * Allocate a pool of TX Wireless Information blocks. + */ +int +rt2860_alloc_tx_pool(struct rt2860_softc *sc) +{ + caddr_t vaddr; + bus_addr_t paddr; + int i, size, error; + + size = RT2860_TX_POOL_COUNT * RT2860_TXWI_DMASZ; + + /* init data_pool early in case of failure.. */ + SLIST_INIT(&sc->data_pool); + + error = bus_dma_tag_create(bus_get_dma_tag(sc->sc_dev), 1, 0, + BUS_SPACE_MAXADDR_32BIT, BUS_SPACE_MAXADDR, NULL, NULL, + size, 1, size, 0, NULL, NULL, &sc->txwi_dmat); + if (error != 0) { + device_printf(sc->sc_dev, "could not create txwi DMA tag\n"); + goto fail; + } + + error = bus_dmamem_alloc(sc->txwi_dmat, (void **)&sc->txwi_vaddr, + BUS_DMA_NOWAIT | BUS_DMA_ZERO, &sc->txwi_map); + if (error != 0) { + device_printf(sc->sc_dev, "could not allocate DMA memory\n"); + goto fail; + } + + error = bus_dmamap_load(sc->txwi_dmat, sc->txwi_map, + sc->txwi_vaddr, size, rt2860_dma_map_addr, &paddr, 0); + if (error != 0) { + device_printf(sc->sc_dev, "could not load txwi DMA map\n"); + goto fail; + } + + bus_dmamap_sync(sc->txwi_dmat, sc->txwi_map, BUS_DMASYNC_PREWRITE); + + vaddr = sc->txwi_vaddr; + for (i = 0; i < RT2860_TX_POOL_COUNT; i++) { + struct rt2860_tx_data *data = &sc->data[i]; + + error = bus_dmamap_create(sc->txwi_dmat, 0, &data->map); + if (error != 0) { + device_printf(sc->sc_dev, "could not create DMA map\n"); + goto fail; + } + data->txwi = (struct rt2860_txwi *)vaddr; + data->paddr = paddr; + vaddr += RT2860_TXWI_DMASZ; + paddr += RT2860_TXWI_DMASZ; + + SLIST_INSERT_HEAD(&sc->data_pool, data, next); + } + + return 0; + +fail: rt2860_free_tx_pool(sc); + return error; +} + +void +rt2860_free_tx_pool(struct rt2860_softc *sc) +{ + if (sc->txwi_vaddr != NULL) { + bus_dmamap_sync(sc->txwi_dmat, sc->txwi_map, + BUS_DMASYNC_POSTWRITE); + bus_dmamap_unload(sc->txwi_dmat, sc->txwi_map); + bus_dmamem_free(sc->txwi_dmat, sc->txwi_vaddr, sc->txwi_map); + } + if (sc->txwi_dmat != NULL) + bus_dma_tag_destroy(sc->txwi_dmat); + + while (!SLIST_EMPTY(&sc->data_pool)) { + struct rt2860_tx_data *data; + data = SLIST_FIRST(&sc->data_pool); + bus_dmamap_destroy(sc->txwi_dmat, data->map); + SLIST_REMOVE_HEAD(&sc->data_pool, next); + } +} + +int +rt2860_alloc_rx_ring(struct rt2860_softc *sc, struct rt2860_rx_ring *ring) +{ + bus_addr_t physaddr; + int i, size, error; + + size = RT2860_RX_RING_COUNT * sizeof (struct rt2860_rxd); + + error = bus_dma_tag_create(bus_get_dma_tag(sc->sc_dev), 16, 0, + BUS_SPACE_MAXADDR_32BIT, BUS_SPACE_MAXADDR, NULL, NULL, + size, 1, size, 0, NULL, NULL, &ring->desc_dmat); + if (error != 0) { + device_printf(sc->sc_dev, "could not create desc DMA tag\n"); + goto fail; + } + + error = bus_dmamem_alloc(ring->desc_dmat, (void **)&ring->rxd, + BUS_DMA_NOWAIT | BUS_DMA_ZERO, &ring->desc_map); + if (error != 0) { + device_printf(sc->sc_dev, "could not allocate DMA memory\n"); + goto fail; + } + + error = bus_dmamap_load(ring->desc_dmat, ring->desc_map, ring->rxd, + size, rt2860_dma_map_addr, &ring->paddr, 0); + if (error != 0) { + device_printf(sc->sc_dev, "could not load desc DMA map\n"); + goto fail; + } + + error = bus_dma_tag_create(bus_get_dma_tag(sc->sc_dev), 1, 0, + BUS_SPACE_MAXADDR_32BIT, BUS_SPACE_MAXADDR, NULL, NULL, MCLBYTES, + 1, MCLBYTES, 0, NULL, NULL, &ring->data_dmat); + if (error != 0) { + device_printf(sc->sc_dev, "could not create data DMA tag\n"); + goto fail; + } + + for (i = 0; i < RT2860_RX_RING_COUNT; i++) { + struct rt2860_rx_data *data = &ring->data[i]; + struct rt2860_rxd *rxd = &ring->rxd[i]; + + error = bus_dmamap_create(ring->data_dmat, 0, &data->map); + if (error != 0) { + device_printf(sc->sc_dev, "could not create DMA map\n"); + goto fail; + } + + data->m = m_getcl(M_DONTWAIT, MT_DATA, M_PKTHDR); + if (data->m == NULL) { + device_printf(sc->sc_dev, + "could not allocate rx mbuf\n"); + error = ENOMEM; + goto fail; + } + + error = bus_dmamap_load(ring->data_dmat, data->map, + mtod(data->m, void *), MCLBYTES, rt2860_dma_map_addr, + &physaddr, 0); + if (error != 0) { + device_printf(sc->sc_dev, + "could not load rx buf DMA map"); + goto fail; + } + + rxd->sdp0 = htole32(physaddr); + rxd->sdl0 = htole16(MCLBYTES); + } + + bus_dmamap_sync(ring->desc_dmat, ring->desc_map, BUS_DMASYNC_PREWRITE); + + return 0; + +fail: rt2860_free_rx_ring(sc, ring); + return error; +} + +void +rt2860_reset_rx_ring(struct rt2860_softc *sc, struct rt2860_rx_ring *ring) +{ + int i; + + for (i = 0; i < RT2860_RX_RING_COUNT; i++) + ring->rxd[i].sdl0 &= ~htole16(RT2860_RX_DDONE); + + bus_dmamap_sync(ring->desc_dmat, ring->desc_map, BUS_DMASYNC_PREWRITE); + + ring->cur = 0; +} + +void +rt2860_free_rx_ring(struct rt2860_softc *sc, struct rt2860_rx_ring *ring) +{ + int i; + + if (ring->rxd != NULL) { + bus_dmamap_sync(ring->desc_dmat, ring->desc_map, + BUS_DMASYNC_POSTWRITE); + bus_dmamap_unload(ring->desc_dmat, ring->desc_map); + bus_dmamem_free(ring->desc_dmat, ring->rxd, ring->desc_map); + } + if (ring->desc_dmat != NULL) + bus_dma_tag_destroy(ring->desc_dmat); + + for (i = 0; i < RT2860_RX_RING_COUNT; i++) { + struct rt2860_rx_data *data = &ring->data[i]; + + if (data->m != NULL) { + bus_dmamap_sync(ring->data_dmat, data->map, + BUS_DMASYNC_POSTREAD); + bus_dmamap_unload(ring->data_dmat, data->map); + m_freem(data->m); + } + if (data->map != NULL) + bus_dmamap_destroy(ring->data_dmat, data->map); + } + if (ring->data_dmat != NULL) + bus_dma_tag_destroy(ring->data_dmat); +} + +static void +rt2860_updatestats(struct rt2860_softc *sc) +{ + struct ieee80211com *ic = sc->sc_ifp->if_l2com; + + /* + * In IBSS or HostAP modes (when the hardware sends beacons), the + * MAC can run into a livelock and start sending CTS-to-self frames + * like crazy if protection is enabled. Fortunately, we can detect + * when such a situation occurs and reset the MAC. + */ + if (ic->ic_curmode != IEEE80211_M_STA) { + /* check if we're in a livelock situation.. */ + uint32_t tmp = RAL_READ(sc, RT2860_DEBUG); + if ((tmp & (1 << 29)) && (tmp & (1 << 7 | 1 << 5))) { + /* ..and reset MAC/BBP for a while.. */ + DPRINTF(("CTS-to-self livelock detected\n")); + RAL_WRITE(sc, RT2860_MAC_SYS_CTRL, RT2860_MAC_SRST); + RAL_BARRIER_WRITE(sc); + DELAY(1); + RAL_WRITE(sc, RT2860_MAC_SYS_CTRL, + RT2860_MAC_RX_EN | RT2860_MAC_TX_EN); + } + } +} + +static void +rt2860_newassoc(struct ieee80211_node *ni, int isnew) +{ + struct ieee80211com *ic = ni->ni_ic; + struct rt2860_softc *sc = ic->ic_ifp->if_softc; + uint8_t wcid; + + wcid = IEEE80211_AID(ni->ni_associd); + if (isnew && ni->ni_associd != 0) { + sc->wcid2ni[wcid] = ni; + + /* init WCID table entry */ + RAL_WRITE_REGION_1(sc, RT2860_WCID_ENTRY(wcid), + ni->ni_macaddr, IEEE80211_ADDR_LEN); + } + DPRINTF(("new assoc isnew=%d addr=%s WCID=%d\n", + isnew, ether_sprintf(ni->ni_macaddr), wcid)); +} + +static void +rt2860_node_free(struct ieee80211_node *ni) +{ + struct ieee80211com *ic = ni->ni_ic; + struct rt2860_softc *sc = ic->ic_ifp->if_softc; + uint8_t wcid; + + if (ni->ni_associd != 0) { + wcid = IEEE80211_AID(ni->ni_associd); + + /* clear Rx WCID search table entry */ + RAL_SET_REGION_4(sc, RT2860_WCID_ENTRY(wcid), 0, 2); + } + sc->sc_node_free(ni); +} + +#ifdef IEEE80211_HT +static int +rt2860_ampdu_rx_start(struct ieee80211com *ic, struct ieee80211_node *ni, + uint8_t tid) +{ + struct rt2860_softc *sc = ic->ic_softc; + uint8_t wcid = ((struct rt2860_node *)ni)->wcid; + uint32_t tmp; + + /* update BA session mask */ + tmp = RAL_READ(sc, RT2860_WCID_ENTRY(wcid) + 4); + tmp |= (1 << tid) << 16; + RAL_WRITE(sc, RT2860_WCID_ENTRY(wcid) + 4, tmp); + return 0; +} + +static void +rt2860_ampdu_rx_stop(struct ieee80211com *ic, struct ieee80211_node *ni, + uint8_t tid) +{ + struct rt2860_softc *sc = ic->ic_softc; + uint8_t wcid = ((struct rt2860_node *)ni)->wcid; + uint32_t tmp; + + /* update BA session mask */ + tmp = RAL_READ(sc, RT2860_WCID_ENTRY(wcid) + 4); + tmp &= ~((1 << tid) << 16); + RAL_WRITE(sc, RT2860_WCID_ENTRY(wcid) + 4, tmp); +} +#endif + +int +rt2860_newstate(struct ieee80211vap *vap, enum ieee80211_state nstate, int arg) +{ + struct rt2860_vap *rvp = RT2860_VAP(vap); + struct ieee80211com *ic = vap->iv_ic; + struct rt2860_softc *sc = ic->ic_ifp->if_softc; + uint32_t tmp; + int error; + + if (vap->iv_state == IEEE80211_S_RUN) { + /* turn link LED off */ + rt2860_set_leds(sc, RT2860_LED_RADIO); + } + + if (nstate == IEEE80211_S_INIT && vap->iv_state == IEEE80211_S_RUN) { + /* abort TSF synchronization */ + tmp = RAL_READ(sc, RT2860_BCN_TIME_CFG); + RAL_WRITE(sc, RT2860_BCN_TIME_CFG, + tmp & ~(RT2860_BCN_TX_EN | RT2860_TSF_TIMER_EN | + RT2860_TBTT_TIMER_EN)); + } + + rt2860_set_gp_timer(sc, 0); + + error = rvp->ral_newstate(vap, nstate, arg); + if (error != 0) + return (error); + + if (nstate == IEEE80211_S_RUN) { + struct ieee80211_node *ni = vap->iv_bss; + + if (ic->ic_opmode != IEEE80211_M_MONITOR) { + rt2860_enable_mrr(sc); + rt2860_set_txpreamble(sc); + rt2860_set_basicrates(sc, &ni->ni_rates); + rt2860_set_bssid(sc, ni->ni_bssid); + } + + if (vap->iv_opmode == IEEE80211_M_HOSTAP || + vap->iv_opmode == IEEE80211_M_IBSS || + vap->iv_opmode == IEEE80211_M_MBSS) { + error = rt2860_setup_beacon(sc, vap); + if (error != 0) + return error; + } + + if (ic->ic_opmode != IEEE80211_M_MONITOR) { + rt2860_enable_tsf_sync(sc); + rt2860_set_gp_timer(sc, 500); + } + + /* turn link LED on */ + rt2860_set_leds(sc, RT2860_LED_RADIO | + (IEEE80211_IS_CHAN_2GHZ(ni->ni_chan) ? + RT2860_LED_LINK_2GHZ : RT2860_LED_LINK_5GHZ)); + } + return error; +} + +/* Read 16-bit from eFUSE ROM (>=RT3071 only.) */ +static uint16_t +rt3090_efuse_read_2(struct rt2860_softc *sc, uint16_t addr) +{ + uint32_t tmp; + uint16_t reg; + int ntries; + + addr *= 2; + /*- + * Read one 16-byte block into registers EFUSE_DATA[0-3]: + * DATA0: F E D C + * DATA1: B A 9 8 + * DATA2: 7 6 5 4 + * DATA3: 3 2 1 0 + */ + tmp = RAL_READ(sc, RT3070_EFUSE_CTRL); + tmp &= ~(RT3070_EFSROM_MODE_MASK | RT3070_EFSROM_AIN_MASK); + tmp |= (addr & ~0xf) << RT3070_EFSROM_AIN_SHIFT | RT3070_EFSROM_KICK; + RAL_WRITE(sc, RT3070_EFUSE_CTRL, tmp); + for (ntries = 0; ntries < 500; ntries++) { + tmp = RAL_READ(sc, RT3070_EFUSE_CTRL); + if (!(tmp & RT3070_EFSROM_KICK)) + break; + DELAY(2); + } + if (ntries == 500) + return 0xffff; + + if ((tmp & RT3070_EFUSE_AOUT_MASK) == RT3070_EFUSE_AOUT_MASK) + return 0xffff; /* address not found */ + + /* determine to which 32-bit register our 16-bit word belongs */ + reg = RT3070_EFUSE_DATA3 - (addr & 0xc); + tmp = RAL_READ(sc, reg); + + return (addr & 2) ? tmp >> 16 : tmp & 0xffff; +} + +/* + * Read 16 bits at address 'addr' from the serial EEPROM (either 93C46, + * 93C66 or 93C86). + */ +static uint16_t +rt2860_eeprom_read_2(struct rt2860_softc *sc, uint16_t addr) +{ + uint32_t tmp; + uint16_t val; + int n; + + /* clock C once before the first command */ + RT2860_EEPROM_CTL(sc, 0); + + RT2860_EEPROM_CTL(sc, RT2860_S); + RT2860_EEPROM_CTL(sc, RT2860_S | RT2860_C); + RT2860_EEPROM_CTL(sc, RT2860_S); + + /* write start bit (1) */ + RT2860_EEPROM_CTL(sc, RT2860_S | RT2860_D); + RT2860_EEPROM_CTL(sc, RT2860_S | RT2860_D | RT2860_C); + + /* write READ opcode (10) */ + RT2860_EEPROM_CTL(sc, RT2860_S | RT2860_D); + RT2860_EEPROM_CTL(sc, RT2860_S | RT2860_D | RT2860_C); + RT2860_EEPROM_CTL(sc, RT2860_S); + RT2860_EEPROM_CTL(sc, RT2860_S | RT2860_C); + + /* write address (A5-A0 or A7-A0) */ + n = ((RAL_READ(sc, RT2860_PCI_EECTRL) & 0x30) == 0) ? 5 : 7; + for (; n >= 0; n--) { + RT2860_EEPROM_CTL(sc, RT2860_S | + (((addr >> n) & 1) << RT2860_SHIFT_D)); + RT2860_EEPROM_CTL(sc, RT2860_S | + (((addr >> n) & 1) << RT2860_SHIFT_D) | RT2860_C); + } + + RT2860_EEPROM_CTL(sc, RT2860_S); + + /* read data Q15-Q0 */ + val = 0; + for (n = 15; n >= 0; n--) { + RT2860_EEPROM_CTL(sc, RT2860_S | RT2860_C); + tmp = RAL_READ(sc, RT2860_PCI_EECTRL); + val |= ((tmp & RT2860_Q) >> RT2860_SHIFT_Q) << n; + RT2860_EEPROM_CTL(sc, RT2860_S); + } + + RT2860_EEPROM_CTL(sc, 0); + + /* clear Chip Select and clock C */ + RT2860_EEPROM_CTL(sc, RT2860_S); + RT2860_EEPROM_CTL(sc, 0); + RT2860_EEPROM_CTL(sc, RT2860_C); + + return val; +} + +static __inline uint16_t +rt2860_srom_read(struct rt2860_softc *sc, uint8_t addr) +{ + /* either eFUSE ROM or EEPROM */ + return sc->sc_srom_read(sc, addr); +} + +static void +rt2860_intr_coherent(struct rt2860_softc *sc) +{ + uint32_t tmp; + + /* DMA finds data coherent event when checking the DDONE bit */ + + DPRINTF(("Tx/Rx Coherent interrupt\n")); + + /* restart DMA engine */ + tmp = RAL_READ(sc, RT2860_WPDMA_GLO_CFG); + tmp &= ~(RT2860_TX_WB_DDONE | RT2860_RX_DMA_EN | RT2860_TX_DMA_EN); + RAL_WRITE(sc, RT2860_WPDMA_GLO_CFG, tmp); + + (void)rt2860_txrx_enable(sc); +} + +static void +rt2860_drain_stats_fifo(struct rt2860_softc *sc) +{ + struct ifnet *ifp = sc->sc_ifp; + struct ieee80211_node *ni; + uint32_t stat; + int retrycnt; + uint8_t wcid, mcs, pid; + + /* drain Tx status FIFO (maxsize = 16) */ + while ((stat = RAL_READ(sc, RT2860_TX_STAT_FIFO)) & RT2860_TXQ_VLD) { + DPRINTFN(4, ("tx stat 0x%08x\n", stat)); + + wcid = (stat >> RT2860_TXQ_WCID_SHIFT) & 0xff; + ni = sc->wcid2ni[wcid]; + + /* if no ACK was requested, no feedback is available */ + if (!(stat & RT2860_TXQ_ACKREQ) || wcid == 0xff || ni == NULL) + continue; + + /* update per-STA AMRR stats */ + if (stat & RT2860_TXQ_OK) { + /* + * Check if there were retries, ie if the Tx success + * rate is different from the requested rate. Note + * that it works only because we do not allow rate + * fallback from OFDM to CCK. + */ + mcs = (stat >> RT2860_TXQ_MCS_SHIFT) & 0x7f; + pid = (stat >> RT2860_TXQ_PID_SHIFT) & 0xf; + if (mcs + 1 != pid) + retrycnt = 1; + else + retrycnt = 0; + ieee80211_ratectl_tx_complete(ni->ni_vap, ni, + IEEE80211_RATECTL_TX_SUCCESS, &retrycnt, NULL); + } else { + ieee80211_ratectl_tx_complete(ni->ni_vap, ni, + IEEE80211_RATECTL_TX_FAILURE, &retrycnt, NULL); + ifp->if_oerrors++; + } + } +} + +static void +rt2860_tx_intr(struct rt2860_softc *sc, int qid) +{ + struct ifnet *ifp = sc->sc_ifp; + struct rt2860_tx_ring *ring = &sc->txq[qid]; + uint32_t hw; + + rt2860_drain_stats_fifo(sc); + + hw = RAL_READ(sc, RT2860_TX_DTX_IDX(qid)); + while (ring->next != hw) { + struct rt2860_tx_data *data = ring->data[ring->next]; + + if (data != NULL) { + bus_dmamap_sync(ring->data_dmat, data->map, + BUS_DMASYNC_POSTWRITE); + bus_dmamap_unload(ring->data_dmat, data->map); + if (data->m->m_flags & M_TXCB) { + ieee80211_process_callback(data->ni, data->m, + 0); + } + m_freem(data->m); + ieee80211_free_node(data->ni); + data->m = NULL; + data->ni = NULL; + + SLIST_INSERT_HEAD(&sc->data_pool, data, next); + ring->data[ring->next] = NULL; + + ifp->if_opackets++; + } + ring->queued--; + ring->next = (ring->next + 1) % RT2860_TX_RING_COUNT; + } + + sc->sc_tx_timer = 0; + if (ring->queued < RT2860_TX_RING_COUNT) + sc->qfullmsk &= ~(1 << qid); + ifp->if_drv_flags &= ~IFF_DRV_OACTIVE; + rt2860_start_locked(ifp); +} + +/* + * Return the Rx chain with the highest RSSI for a given frame. + */ +static __inline uint8_t +rt2860_maxrssi_chain(struct rt2860_softc *sc, const struct rt2860_rxwi *rxwi) +{ + uint8_t rxchain = 0; + + if (sc->nrxchains > 1) { + if (rxwi->rssi[1] > rxwi->rssi[rxchain]) + rxchain = 1; + if (sc->nrxchains > 2) + if (rxwi->rssi[2] > rxwi->rssi[rxchain]) + rxchain = 2; + } + return rxchain; +} + +static void +rt2860_rx_intr(struct rt2860_softc *sc) +{ + struct rt2860_rx_radiotap_header *tap; + struct ifnet *ifp = sc->sc_ifp; + struct ieee80211com *ic = ifp->if_l2com; + struct ieee80211_frame *wh; + struct ieee80211_node *ni; + struct mbuf *m, *m1; + bus_addr_t physaddr; + uint32_t hw; + uint16_t phy; + uint8_t ant; + int8_t rssi, nf; + int error; + + hw = RAL_READ(sc, RT2860_FS_DRX_IDX) & 0xfff; + while (sc->rxq.cur != hw) { + struct rt2860_rx_data *data = &sc->rxq.data[sc->rxq.cur]; + struct rt2860_rxd *rxd = &sc->rxq.rxd[sc->rxq.cur]; + struct rt2860_rxwi *rxwi; + + bus_dmamap_sync(sc->rxq.desc_dmat, sc->rxq.desc_map, + BUS_DMASYNC_POSTREAD); + + if (__predict_false(!(rxd->sdl0 & htole16(RT2860_RX_DDONE)))) { + DPRINTF(("RXD DDONE bit not set!\n")); + break; /* should not happen */ + } + + if (__predict_false(rxd->flags & + htole32(RT2860_RX_CRCERR | RT2860_RX_ICVERR))) { + ifp->if_ierrors++; + goto skip; + } + +#ifdef HW_CRYPTO + if (__predict_false(rxd->flags & htole32(RT2860_RX_MICERR))) { + /* report MIC failures to net80211 for TKIP */ + ic->ic_stats.is_rx_locmicfail++; + ieee80211_michael_mic_failure(ic, 0/* XXX */); + ifp->if_ierrors++; + goto skip; + } +#endif + + m1 = m_getcl(M_DONTWAIT, MT_DATA, M_PKTHDR); + if (__predict_false(m1 == NULL)) { + ifp->if_ierrors++; + goto skip; + } + + bus_dmamap_sync(sc->rxq.data_dmat, data->map, + BUS_DMASYNC_POSTREAD); + bus_dmamap_unload(sc->rxq.data_dmat, data->map); + + error = bus_dmamap_load(sc->rxq.data_dmat, data->map, + mtod(m1, void *), MCLBYTES, rt2860_dma_map_addr, + &physaddr, 0); + if (__predict_false(error != 0)) { + m_freem(m1); + + /* try to reload the old mbuf */ + error = bus_dmamap_load(sc->rxq.data_dmat, data->map, + mtod(data->m, void *), MCLBYTES, + rt2860_dma_map_addr, &physaddr, 0); + if (__predict_false(error != 0)) { + panic("%s: could not load old rx mbuf", + device_get_name(sc->sc_dev)); + } + /* physical address may have changed */ + rxd->sdp0 = htole32(physaddr); + ifp->if_ierrors++; + goto skip; + } + + /* + * New mbuf successfully loaded, update Rx ring and continue + * processing. + */ + m = data->m; + data->m = m1; + rxd->sdp0 = htole32(physaddr); + + rxwi = mtod(m, struct rt2860_rxwi *); + + /* finalize mbuf */ + m->m_pkthdr.rcvif = ifp; + m->m_data = (caddr_t)(rxwi + 1); + m->m_pkthdr.len = m->m_len = le16toh(rxwi->len) & 0xfff; + + wh = mtod(m, struct ieee80211_frame *); +#ifdef HW_CRYPTO + if (wh->i_fc[1] & IEEE80211_FC1_WEP) { + /* frame is decrypted by hardware */ + wh->i_fc[1] &= ~IEEE80211_FC1_WEP; + } +#endif + + /* HW may insert 2 padding bytes after 802.11 header */ + if (rxd->flags & htole32(RT2860_RX_L2PAD)) { + u_int hdrlen = ieee80211_hdrsize(wh); + ovbcopy(wh, (caddr_t)wh + 2, hdrlen); + m->m_data += 2; + wh = mtod(m, struct ieee80211_frame *); + } + + ant = rt2860_maxrssi_chain(sc, rxwi); + rssi = rt2860_rssi2dbm(sc, rxwi->rssi[ant], ant); + nf = RT2860_NOISE_FLOOR; + + if (ieee80211_radiotap_active(ic)) { + tap = &sc->sc_rxtap; + tap->wr_flags = 0; + tap->wr_antenna = ant; + tap->wr_antsignal = nf + rssi; + tap->wr_antnoise = nf; + /* in case it can't be found below */ + tap->wr_rate = 2; + phy = le16toh(rxwi->phy); + switch (phy & RT2860_PHY_MODE) { + case RT2860_PHY_CCK: + switch ((phy & RT2860_PHY_MCS) & ~RT2860_PHY_SHPRE) { + case 0: tap->wr_rate = 2; break; + case 1: tap->wr_rate = 4; break; + case 2: tap->wr_rate = 11; break; + case 3: tap->wr_rate = 22; break; + } + if (phy & RT2860_PHY_SHPRE) + tap->wr_flags |= IEEE80211_RADIOTAP_F_SHORTPRE; + break; + case RT2860_PHY_OFDM: + switch (phy & RT2860_PHY_MCS) { + case 0: tap->wr_rate = 12; break; + case 1: tap->wr_rate = 18; break; + case 2: tap->wr_rate = 24; break; + case 3: tap->wr_rate = 36; break; + case 4: tap->wr_rate = 48; break; + case 5: tap->wr_rate = 72; break; + case 6: tap->wr_rate = 96; break; + case 7: tap->wr_rate = 108; break; + } + break; + } + } + + RAL_UNLOCK(sc); + wh = mtod(m, struct ieee80211_frame *); + + /* send the frame to the 802.11 layer */ + ni = ieee80211_find_rxnode(ic, + (struct ieee80211_frame_min *)wh); + if (ni != NULL) { + (void)ieee80211_input(ni, m, rssi - nf, nf); + ieee80211_free_node(ni); + } else + (void)ieee80211_input_all(ic, m, rssi - nf, nf); + + RAL_LOCK(sc); + +skip: rxd->sdl0 &= ~htole16(RT2860_RX_DDONE); + + bus_dmamap_sync(sc->rxq.desc_dmat, sc->rxq.desc_map, + BUS_DMASYNC_PREWRITE); + + sc->rxq.cur = (sc->rxq.cur + 1) % RT2860_RX_RING_COUNT; + } + + /* tell HW what we have processed */ + RAL_WRITE(sc, RT2860_RX_CALC_IDX, + (sc->rxq.cur - 1) % RT2860_RX_RING_COUNT); +} + +static void +rt2860_tbtt_intr(struct rt2860_softc *sc) +{ +#if 0 + struct ieee80211com *ic = &sc->sc_ic; + +#ifndef IEEE80211_STA_ONLY + if (ic->ic_opmode == IEEE80211_M_HOSTAP) { + /* one less beacon until next DTIM */ + if (ic->ic_dtim_count == 0) + ic->ic_dtim_count = ic->ic_dtim_period - 1; + else + ic->ic_dtim_count--; + + /* update dynamic parts of beacon */ + rt2860_setup_beacon(sc); + + /* flush buffered multicast frames */ + if (ic->ic_dtim_count == 0) + ieee80211_notify_dtim(ic); + } +#endif + /* check if protection mode has changed */ + if ((sc->sc_ic_flags ^ ic->ic_flags) & IEEE80211_F_USEPROT) { + rt2860_updateprot(ic); + sc->sc_ic_flags = ic->ic_flags; + } +#endif +} + +static void +rt2860_gp_intr(struct rt2860_softc *sc) +{ + struct ieee80211com *ic = sc->sc_ifp->if_l2com; + struct ieee80211vap *vap = TAILQ_FIRST(&ic->ic_vaps); + + DPRINTFN(2, ("GP timeout state=%d\n", vap->iv_state)); + + if (vap->iv_state == IEEE80211_S_RUN) + rt2860_updatestats(sc); +} + +void +rt2860_intr(void *arg) +{ + struct rt2860_softc *sc = arg; + uint32_t r; + + RAL_LOCK(sc); + + r = RAL_READ(sc, RT2860_INT_STATUS); + if (__predict_false(r == 0xffffffff)) { + RAL_UNLOCK(sc); + return; /* device likely went away */ + } + if (r == 0) { + RAL_UNLOCK(sc); + return; /* not for us */ + } + + /* acknowledge interrupts */ + RAL_WRITE(sc, RT2860_INT_STATUS, r); + + if (r & RT2860_TX_RX_COHERENT) + rt2860_intr_coherent(sc); + + if (r & RT2860_MAC_INT_2) /* TX status */ + rt2860_drain_stats_fifo(sc); + + if (r & RT2860_TX_DONE_INT5) + rt2860_tx_intr(sc, 5); + + if (r & RT2860_RX_DONE_INT) + rt2860_rx_intr(sc); + + if (r & RT2860_TX_DONE_INT4) + rt2860_tx_intr(sc, 4); + + if (r & RT2860_TX_DONE_INT3) + rt2860_tx_intr(sc, 3); + + if (r & RT2860_TX_DONE_INT2) + rt2860_tx_intr(sc, 2); + + if (r & RT2860_TX_DONE_INT1) + rt2860_tx_intr(sc, 1); + + if (r & RT2860_TX_DONE_INT0) + rt2860_tx_intr(sc, 0); + + if (r & RT2860_MAC_INT_0) /* TBTT */ + rt2860_tbtt_intr(sc); + + if (r & RT2860_MAC_INT_3) /* Auto wakeup */ + /* TBD wakeup */; + + if (r & RT2860_MAC_INT_4) /* GP timer */ + rt2860_gp_intr(sc); + + RAL_UNLOCK(sc); +} + +static int +rt2860_tx(struct rt2860_softc *sc, struct mbuf *m, struct ieee80211_node *ni) +{ + struct ifnet *ifp = sc->sc_ifp; + struct ieee80211com *ic = ifp->if_l2com; + struct ieee80211vap *vap = ni->ni_vap; + struct rt2860_tx_ring *ring; + struct rt2860_tx_data *data; + struct rt2860_txd *txd; + struct rt2860_txwi *txwi; + struct ieee80211_frame *wh; + const struct ieee80211_txparam *tp; + struct ieee80211_key *k; + struct mbuf *m1; + bus_dma_segment_t segs[RT2860_MAX_SCATTER]; + bus_dma_segment_t *seg; + u_int hdrlen; + uint16_t qos, dur; + uint8_t type, qsel, mcs, pid, tid, qid; + int i, nsegs, ntxds, pad, rate, ridx, error; + + /* the data pool contains at least one element, pick the first */ + data = SLIST_FIRST(&sc->data_pool); + + wh = mtod(m, struct ieee80211_frame *); + + if (wh->i_fc[1] & IEEE80211_FC1_WEP) { + k = ieee80211_crypto_encap(ni, m); + if (k == NULL) { + m_freem(m); + return ENOBUFS; + } + + /* packet header may have moved, reset our local pointer */ + wh = mtod(m, struct ieee80211_frame *); + } + + hdrlen = ieee80211_anyhdrsize(wh); + type = wh->i_fc[0] & IEEE80211_FC0_TYPE_MASK; + + tp = &vap->iv_txparms[ieee80211_chan2mode(ni->ni_chan)]; + if (IEEE80211_IS_MULTICAST(wh->i_addr1)) { + rate = tp->mcastrate; + } else if (m->m_flags & M_EAPOL) { + rate = tp->mgmtrate; + } else if (tp->ucastrate != IEEE80211_FIXED_RATE_NONE) { + rate = tp->ucastrate; + } else { + (void) ieee80211_ratectl_rate(ni, NULL, 0); + rate = ni->ni_txrate; + } + rate &= IEEE80211_RATE_VAL; + + qid = M_WME_GETAC(m); + if (IEEE80211_QOS_HAS_SEQ(wh)) { + qos = ((const struct ieee80211_qosframe *)wh)->i_qos[0]; + tid = qos & IEEE80211_QOS_TID; + } else { + qos = 0; + tid = 0; + } + ring = &sc->txq[qid]; + ridx = ic->ic_rt->rateCodeToIndex[rate]; + + /* get MCS code from rate index */ + mcs = rt2860_rates[ridx].mcs; + + /* setup TX Wireless Information */ + txwi = data->txwi; + txwi->flags = 0; + /* let HW generate seq numbers for non-QoS frames */ + txwi->xflags = qos ? 0 : RT2860_TX_NSEQ; + if (type == IEEE80211_FC0_TYPE_DATA) + txwi->wcid = IEEE80211_AID(ni->ni_associd); + else + txwi->wcid = 0xff; + txwi->len = htole16(m->m_pkthdr.len); + if (rt2860_rates[ridx].phy == IEEE80211_T_DS) { + txwi->phy = htole16(RT2860_PHY_CCK); + if (ridx != RT2860_RIDX_CCK1 && + (ic->ic_flags & IEEE80211_F_SHPREAMBLE)) + mcs |= RT2860_PHY_SHPRE; + } else + txwi->phy = htole16(RT2860_PHY_OFDM); + txwi->phy |= htole16(mcs); + + /* + * We store the MCS code into the driver-private PacketID field. + * The PacketID is latched into TX_STAT_FIFO when Tx completes so + * that we know at which initial rate the frame was transmitted. + * We add 1 to the MCS code because setting the PacketID field to + * 0 means that we don't want feedback in TX_STAT_FIFO. + */ + pid = (mcs + 1) & 0xf; + txwi->len |= htole16(pid << RT2860_TX_PID_SHIFT); + + /* check if RTS/CTS or CTS-to-self protection is required */ + if (!IEEE80211_IS_MULTICAST(wh->i_addr1) && + (m->m_pkthdr.len + IEEE80211_CRC_LEN > vap->iv_rtsthreshold || + ((ic->ic_flags & IEEE80211_F_USEPROT) && + rt2860_rates[ridx].phy == IEEE80211_T_OFDM))) + txwi->txop = RT2860_TX_TXOP_HT; + else + txwi->txop = RT2860_TX_TXOP_BACKOFF; + + if (!IEEE80211_IS_MULTICAST(wh->i_addr1) && + (!qos || (qos & IEEE80211_QOS_ACKPOLICY) != + IEEE80211_QOS_ACKPOLICY_NOACK)) { + txwi->xflags |= RT2860_TX_ACK; + + if (ic->ic_flags & IEEE80211_F_SHPREAMBLE) + dur = rt2860_rates[ridx].sp_ack_dur; + else + dur = rt2860_rates[ridx].lp_ack_dur; + *(uint16_t *)wh->i_dur = htole16(dur); + } + /* ask MAC to insert timestamp into probe responses */ + if ((wh->i_fc[0] & + (IEEE80211_FC0_TYPE_MASK | IEEE80211_FC0_SUBTYPE_MASK)) == + (IEEE80211_FC0_TYPE_MGT | IEEE80211_FC0_SUBTYPE_PROBE_RESP)) + /* NOTE: beacons do not pass through tx_data() */ + txwi->flags |= RT2860_TX_TS; + + if (ieee80211_radiotap_active_vap(vap)) { + struct rt2860_tx_radiotap_header *tap = &sc->sc_txtap; + + tap->wt_flags = 0; + tap->wt_rate = rate; + if (mcs & RT2860_PHY_SHPRE) + tap->wt_flags |= IEEE80211_RADIOTAP_F_SHORTPRE; + + ieee80211_radiotap_tx(vap, m); + } + + if (hdrlen & 3) + pad = 4 - (hdrlen & 3); + else + pad = 0; + + /* copy and trim 802.11 header */ + memcpy(txwi + 1, wh, hdrlen); + m_adj(m, hdrlen); + + error = bus_dmamap_load_mbuf_sg(ring->data_dmat, data->map, m, segs, + &nsegs, 0); + if (__predict_false(error != 0 && error != EFBIG)) { + device_printf(sc->sc_dev, "can't map mbuf (error %d)\n", + error); + m_freem(m); + return error; + } + if (__predict_true(error == 0)) { + /* determine how many TXDs are required */ + ntxds = 1 + (nsegs / 2); + + if (ring->queued + ntxds >= RT2860_TX_RING_COUNT) { + /* not enough free TXDs, force mbuf defrag */ + bus_dmamap_unload(ring->data_dmat, data->map); + error = EFBIG; + } + } + if (__predict_false(error != 0)) { + m1 = m_defrag(m, M_DONTWAIT); + if (m1 == NULL) { + device_printf(sc->sc_dev, + "could not defragment mbuf\n"); + m_freem(m); + return ENOBUFS; + } + m = m1; + + error = bus_dmamap_load_mbuf_sg(ring->data_dmat, data->map, m, + segs, &nsegs, 0); + if (__predict_false(error != 0)) { + device_printf(sc->sc_dev, "can't map mbuf (error %d)\n", + error); + m_freem(m); + return error; + } + + /* determine how many TXDs are now required */ + ntxds = 1 + (nsegs / 2); + + if (ring->queued + ntxds >= RT2860_TX_RING_COUNT) { + /* this is a hopeless case, drop the mbuf! */ + bus_dmamap_unload(ring->data_dmat, data->map); + m_freem(m); + return ENOBUFS; + } + } + + qsel = (qid < WME_NUM_AC) ? RT2860_TX_QSEL_EDCA : RT2860_TX_QSEL_MGMT; + + /* first segment is TXWI + 802.11 header */ + txd = &ring->txd[ring->cur]; + txd->sdp0 = htole32(data->paddr); + txd->sdl0 = htole16(sizeof (struct rt2860_txwi) + hdrlen + pad); + txd->flags = qsel; + + /* setup payload segments */ + seg = &segs[0]; + for (i = nsegs; i >= 2; i -= 2) { + txd->sdp1 = htole32(seg->ds_addr); + txd->sdl1 = htole16(seg->ds_len); + seg++; + ring->cur = (ring->cur + 1) % RT2860_TX_RING_COUNT; + /* grab a new Tx descriptor */ + txd = &ring->txd[ring->cur]; + txd->sdp0 = htole32(seg->ds_addr); + txd->sdl0 = htole16(seg->ds_len); + txd->flags = qsel; + seg++; + } + /* finalize last segment */ + if (i > 0) { + txd->sdp1 = htole32(seg->ds_addr); + txd->sdl1 = htole16(seg->ds_len | RT2860_TX_LS1); + } else { + txd->sdl0 |= htole16(RT2860_TX_LS0); + txd->sdl1 = 0; + } + + /* remove from the free pool and link it into the SW Tx slot */ + SLIST_REMOVE_HEAD(&sc->data_pool, next); + data->m = m; + data->ni = ni; + ring->data[ring->cur] = data; + + bus_dmamap_sync(sc->txwi_dmat, sc->txwi_map, BUS_DMASYNC_PREWRITE); + bus_dmamap_sync(ring->data_dmat, data->map, BUS_DMASYNC_PREWRITE); + bus_dmamap_sync(ring->desc_dmat, ring->desc_map, BUS_DMASYNC_PREWRITE); + + DPRINTFN(4, ("sending frame qid=%d wcid=%d nsegs=%d ridx=%d\n", + qid, txwi->wcid, nsegs, ridx)); + + ring->cur = (ring->cur + 1) % RT2860_TX_RING_COUNT; + ring->queued += ntxds; + if (ring->queued >= RT2860_TX_RING_COUNT) + sc->qfullmsk |= 1 << qid; + + /* kick Tx */ + RAL_WRITE(sc, RT2860_TX_CTX_IDX(qid), ring->cur); + + return 0; +} + +static int +rt2860_raw_xmit(struct ieee80211_node *ni, struct mbuf *m, + const struct ieee80211_bpf_params *params) +{ + struct ieee80211com *ic = ni->ni_ic; + struct ifnet *ifp = ic->ic_ifp; + struct rt2860_softc *sc = ifp->if_softc; + int error; + + RAL_LOCK(sc); + + /* prevent management frames from being sent if we're not ready */ + if (!(ifp->if_drv_flags & IFF_DRV_RUNNING)) { + RAL_UNLOCK(sc); + m_freem(m); + ieee80211_free_node(ni); + return ENETDOWN; + } + if (params == NULL) { + /* + * Legacy path; interpret frame contents to decide + * precisely how to send the frame. + */ + error = rt2860_tx(sc, m, ni); + } else { + /* + * Caller supplied explicit parameters to use in + * sending the frame. + */ + error = rt2860_tx_raw(sc, m, ni, params); + } + if (error != 0) { + /* NB: m is reclaimed on tx failure */ + ieee80211_free_node(ni); + ifp->if_oerrors++; + } + sc->sc_tx_timer = 5; + RAL_UNLOCK(sc); + return error; +} + +static int +rt2860_tx_raw(struct rt2860_softc *sc, struct mbuf *m, + struct ieee80211_node *ni, const struct ieee80211_bpf_params *params) +{ + struct ifnet *ifp = sc->sc_ifp; + struct ieee80211com *ic = ifp->if_l2com; + struct ieee80211vap *vap = ni->ni_vap; + struct rt2860_tx_ring *ring; + struct rt2860_tx_data *data; + struct rt2860_txd *txd; + struct rt2860_txwi *txwi; + struct ieee80211_frame *wh; + struct mbuf *m1; + bus_dma_segment_t segs[RT2860_MAX_SCATTER]; + bus_dma_segment_t *seg; + u_int hdrlen; + uint16_t dur; + uint8_t type, qsel, mcs, pid, tid, qid; + int i, nsegs, ntxds, rate, ridx, error; + + /* the data pool contains at least one element, pick the first */ + data = SLIST_FIRST(&sc->data_pool); + + wh = mtod(m, struct ieee80211_frame *); + hdrlen = ieee80211_hdrsize(wh); + type = wh->i_fc[0] & IEEE80211_FC0_TYPE_MASK; + + /* Choose a TX rate index. */ + rate = params->ibp_rate0; + ridx = ic->ic_rt->rateCodeToIndex[rate]; + if (ridx == (uint8_t)-1) { + /* XXX fall back to mcast/mgmt rate? */ + m_freem(m); + return EINVAL; + } + + qid = params->ibp_pri & 3; + tid = 0; + ring = &sc->txq[qid]; + + /* get MCS code from rate index */ + mcs = rt2860_rates[ridx].mcs; + + /* setup TX Wireless Information */ + txwi = data->txwi; + txwi->flags = 0; + /* let HW generate seq numbers for non-QoS frames */ + txwi->xflags = params->ibp_pri & 3 ? 0 : RT2860_TX_NSEQ; + txwi->wcid = 0xff; + txwi->len = htole16(m->m_pkthdr.len); + if (rt2860_rates[ridx].phy == IEEE80211_T_DS) { + txwi->phy = htole16(RT2860_PHY_CCK); + if (ridx != RT2860_RIDX_CCK1 && + (ic->ic_flags & IEEE80211_F_SHPREAMBLE)) + mcs |= RT2860_PHY_SHPRE; + } else + txwi->phy = htole16(RT2860_PHY_OFDM); + txwi->phy |= htole16(mcs); + + /* + * We store the MCS code into the driver-private PacketID field. + * The PacketID is latched into TX_STAT_FIFO when Tx completes so + * that we know at which initial rate the frame was transmitted. + * We add 1 to the MCS code because setting the PacketID field to + * 0 means that we don't want feedback in TX_STAT_FIFO. + */ + pid = (mcs + 1) & 0xf; + txwi->len |= htole16(pid << RT2860_TX_PID_SHIFT); + + /* check if RTS/CTS or CTS-to-self protection is required */ + if (params->ibp_flags & IEEE80211_BPF_RTS || + params->ibp_flags & IEEE80211_BPF_CTS) + txwi->txop = RT2860_TX_TXOP_HT; + else + txwi->txop = RT2860_TX_TXOP_BACKOFF; + if ((params->ibp_flags & IEEE80211_BPF_NOACK) == 0) { + txwi->xflags |= RT2860_TX_ACK; + + if (ic->ic_flags & IEEE80211_F_SHPREAMBLE) + dur = rt2860_rates[ridx].sp_ack_dur; + else + dur = rt2860_rates[ridx].lp_ack_dur; + *(uint16_t *)wh->i_dur = htole16(dur); + } + /* ask MAC to insert timestamp into probe responses */ + if ((wh->i_fc[0] & + (IEEE80211_FC0_TYPE_MASK | IEEE80211_FC0_SUBTYPE_MASK)) == + (IEEE80211_FC0_TYPE_MGT | IEEE80211_FC0_SUBTYPE_PROBE_RESP)) + /* NOTE: beacons do not pass through tx_data() */ + txwi->flags |= RT2860_TX_TS; + + if (ieee80211_radiotap_active_vap(vap)) { + struct rt2860_tx_radiotap_header *tap = &sc->sc_txtap; + + tap->wt_flags = 0; + tap->wt_rate = rate; + if (mcs & RT2860_PHY_SHPRE) + tap->wt_flags |= IEEE80211_RADIOTAP_F_SHORTPRE; + + ieee80211_radiotap_tx(vap, m); + } + + /* copy and trim 802.11 header */ + memcpy(txwi + 1, wh, hdrlen); + m_adj(m, hdrlen); + + error = bus_dmamap_load_mbuf_sg(ring->data_dmat, data->map, m, segs, + &nsegs, 0); + if (__predict_false(error != 0 && error != EFBIG)) { + device_printf(sc->sc_dev, "can't map mbuf (error %d)\n", + error); + m_freem(m); + return error; + } + if (__predict_true(error == 0)) { + /* determine how many TXDs are required */ + ntxds = 1 + (nsegs / 2); + + if (ring->queued + ntxds >= RT2860_TX_RING_COUNT) { + /* not enough free TXDs, force mbuf defrag */ + bus_dmamap_unload(ring->data_dmat, data->map); + error = EFBIG; + } + } + if (__predict_false(error != 0)) { + m1 = m_defrag(m, M_DONTWAIT); + if (m1 == NULL) { + device_printf(sc->sc_dev, + "could not defragment mbuf\n"); + m_freem(m); + return ENOBUFS; + } + m = m1; + + error = bus_dmamap_load_mbuf_sg(ring->data_dmat, data->map, m, + segs, &nsegs, 0); + if (__predict_false(error != 0)) { + device_printf(sc->sc_dev, "can't map mbuf (error %d)\n", + error); + m_freem(m); + return error; + } + + /* determine how many TXDs are now required */ + ntxds = 1 + (nsegs / 2); + + if (ring->queued + ntxds >= RT2860_TX_RING_COUNT) { + /* this is a hopeless case, drop the mbuf! */ + bus_dmamap_unload(ring->data_dmat, data->map); + m_freem(m); + return ENOBUFS; + } + } + + qsel = (qid < WME_NUM_AC) ? RT2860_TX_QSEL_EDCA : RT2860_TX_QSEL_MGMT; + + /* first segment is TXWI + 802.11 header */ + txd = &ring->txd[ring->cur]; + txd->sdp0 = htole32(data->paddr); + txd->sdl0 = htole16(sizeof (struct rt2860_txwi) + hdrlen); + txd->flags = qsel; + + /* setup payload segments */ + seg = &segs[0]; + for (i = nsegs; i >= 2; i -= 2) { + txd->sdp1 = htole32(seg->ds_addr); + txd->sdl1 = htole16(seg->ds_len); + seg++; + ring->cur = (ring->cur + 1) % RT2860_TX_RING_COUNT; + /* grab a new Tx descriptor */ + txd = &ring->txd[ring->cur]; + txd->sdp0 = htole32(seg->ds_addr); + txd->sdl0 = htole16(seg->ds_len); + txd->flags = qsel; + seg++; + } + /* finalize last segment */ + if (i > 0) { + txd->sdp1 = htole32(seg->ds_addr); + txd->sdl1 = htole16(seg->ds_len | RT2860_TX_LS1); + } else { + txd->sdl0 |= htole16(RT2860_TX_LS0); + txd->sdl1 = 0; + } + + /* remove from the free pool and link it into the SW Tx slot */ + SLIST_REMOVE_HEAD(&sc->data_pool, next); + data->m = m; + data->ni = ni; + ring->data[ring->cur] = data; + + bus_dmamap_sync(sc->txwi_dmat, sc->txwi_map, BUS_DMASYNC_PREWRITE); + bus_dmamap_sync(ring->data_dmat, data->map, BUS_DMASYNC_PREWRITE); + bus_dmamap_sync(ring->desc_dmat, ring->desc_map, BUS_DMASYNC_PREWRITE); + + DPRINTFN(4, ("sending frame qid=%d wcid=%d nsegs=%d ridx=%d\n", + qid, txwi->wcid, nsegs, ridx)); + + ring->cur = (ring->cur + 1) % RT2860_TX_RING_COUNT; + ring->queued += ntxds; + if (ring->queued >= RT2860_TX_RING_COUNT) + sc->qfullmsk |= 1 << qid; + + /* kick Tx */ + RAL_WRITE(sc, RT2860_TX_CTX_IDX(qid), ring->cur); + + return 0; +} + +static void +rt2860_start(struct ifnet *ifp) +{ + struct rt2860_softc *sc = ifp->if_softc; + + RAL_LOCK(sc); + rt2860_start_locked(ifp); + RAL_UNLOCK(sc); +} + +static void +rt2860_start_locked(struct ifnet *ifp) +{ + struct rt2860_softc *sc = ifp->if_softc; + struct ieee80211_node *ni; + struct mbuf *m; + + RAL_LOCK_ASSERT(sc); + + if ((ifp->if_drv_flags & IFF_DRV_RUNNING) == 0 || + (ifp->if_drv_flags & IFF_DRV_OACTIVE)) + return; + + for (;;) { + if (SLIST_EMPTY(&sc->data_pool) || sc->qfullmsk != 0) { + ifp->if_drv_flags |= IFF_DRV_OACTIVE; + break; + } + IFQ_DRV_DEQUEUE(&ifp->if_snd, m); + if (m == NULL) + break; + ni = (struct ieee80211_node *)m->m_pkthdr.rcvif; + if (rt2860_tx(sc, m, ni) != 0) { + ieee80211_free_node(ni); + ifp->if_oerrors++; + continue; + } + sc->sc_tx_timer = 5; + } +} + +static void +rt2860_watchdog(void *arg) +{ + struct rt2860_softc *sc = arg; + struct ifnet *ifp = sc->sc_ifp; + + RAL_LOCK_ASSERT(sc); + + KASSERT(ifp->if_drv_flags & IFF_DRV_RUNNING, ("not running")); + + if (sc->sc_invalid) /* card ejected */ + return; + + if (sc->sc_tx_timer > 0 && --sc->sc_tx_timer == 0) { + if_printf(ifp, "device timeout\n"); + rt2860_stop_locked(sc); + rt2860_init_locked(sc); + ifp->if_oerrors++; + return; + } + callout_reset(&sc->watchdog_ch, hz, rt2860_watchdog, sc); +} + +static int +rt2860_ioctl(struct ifnet *ifp, u_long cmd, caddr_t data) +{ + struct rt2860_softc *sc = ifp->if_softc; + struct ieee80211com *ic = ifp->if_l2com; + struct ifreq *ifr = (struct ifreq *)data; + int error = 0, startall = 0; + + switch (cmd) { + case SIOCSIFFLAGS: + RAL_LOCK(sc); + if (ifp->if_flags & IFF_UP) { + if (!(ifp->if_drv_flags & IFF_DRV_RUNNING)) { + rt2860_init_locked(sc); + startall = 1; + } else + rt2860_update_promisc(ifp); + } else { + if (ifp->if_drv_flags & IFF_DRV_RUNNING) + rt2860_stop_locked(sc); + } + RAL_UNLOCK(sc); + if (startall) + ieee80211_start_all(ic); + break; + case SIOCGIFMEDIA: + error = ifmedia_ioctl(ifp, ifr, &ic->ic_media, cmd); + break; + case SIOCSIFADDR: + error = ether_ioctl(ifp, cmd, data); + break; + default: + error = EINVAL; + break; + } + return error; +} + +/* + * Reading and writing from/to the BBP is different from RT2560 and RT2661. + * We access the BBP through the 8051 microcontroller unit which means that + * the microcode must be loaded first. + */ +void +rt2860_mcu_bbp_write(struct rt2860_softc *sc, uint8_t reg, uint8_t val) +{ + int ntries; + + for (ntries = 0; ntries < 100; ntries++) { + if (!(RAL_READ(sc, RT2860_H2M_BBPAGENT) & RT2860_BBP_CSR_KICK)) + break; + DELAY(1); + } + if (ntries == 100) { + device_printf(sc->sc_dev, + "could not write to BBP through MCU\n"); + return; + } + + RAL_WRITE(sc, RT2860_H2M_BBPAGENT, RT2860_BBP_RW_PARALLEL | + RT2860_BBP_CSR_KICK | reg << 8 | val); + RAL_BARRIER_WRITE(sc); + + rt2860_mcu_cmd(sc, RT2860_MCU_CMD_BBP, 0, 0); + DELAY(1000); +} + +uint8_t +rt2860_mcu_bbp_read(struct rt2860_softc *sc, uint8_t reg) +{ + uint32_t val; + int ntries; + + for (ntries = 0; ntries < 100; ntries++) { + if (!(RAL_READ(sc, RT2860_H2M_BBPAGENT) & RT2860_BBP_CSR_KICK)) + break; + DELAY(1); + } + if (ntries == 100) { + device_printf(sc->sc_dev, + "could not read from BBP through MCU\n"); + return 0; + } + + RAL_WRITE(sc, RT2860_H2M_BBPAGENT, RT2860_BBP_RW_PARALLEL | + RT2860_BBP_CSR_KICK | RT2860_BBP_CSR_READ | reg << 8); + RAL_BARRIER_WRITE(sc); + + rt2860_mcu_cmd(sc, RT2860_MCU_CMD_BBP, 0, 0); + DELAY(1000); + + for (ntries = 0; ntries < 100; ntries++) { + val = RAL_READ(sc, RT2860_H2M_BBPAGENT); + if (!(val & RT2860_BBP_CSR_KICK)) + return val & 0xff; + DELAY(1); + } + device_printf(sc->sc_dev, "could not read from BBP through MCU\n"); + + return 0; +} + +/* + * Write to one of the 4 programmable 24-bit RF registers. + */ +static void +rt2860_rf_write(struct rt2860_softc *sc, uint8_t reg, uint32_t val) +{ + uint32_t tmp; + int ntries; + + for (ntries = 0; ntries < 100; ntries++) { + if (!(RAL_READ(sc, RT2860_RF_CSR_CFG0) & RT2860_RF_REG_CTRL)) + break; + DELAY(1); + } + if (ntries == 100) { + device_printf(sc->sc_dev, "could not write to RF\n"); + return; + } + + /* RF registers are 24-bit on the RT2860 */ + tmp = RT2860_RF_REG_CTRL | 24 << RT2860_RF_REG_WIDTH_SHIFT | + (val & 0x3fffff) << 2 | (reg & 3); + RAL_WRITE(sc, RT2860_RF_CSR_CFG0, tmp); +} + +static uint8_t +rt3090_rf_read(struct rt2860_softc *sc, uint8_t reg) +{ + uint32_t tmp; + int ntries; + + for (ntries = 0; ntries < 100; ntries++) { + if (!(RAL_READ(sc, RT3070_RF_CSR_CFG) & RT3070_RF_KICK)) + break; + DELAY(1); + } + if (ntries == 100) { + device_printf(sc->sc_dev, "could not read RF register\n"); + return 0xff; + } + tmp = RT3070_RF_KICK | reg << 8; + RAL_WRITE(sc, RT3070_RF_CSR_CFG, tmp); + + for (ntries = 0; ntries < 100; ntries++) { + tmp = RAL_READ(sc, RT3070_RF_CSR_CFG); + if (!(tmp & RT3070_RF_KICK)) + break; + DELAY(1); + } + if (ntries == 100) { + device_printf(sc->sc_dev, "could not read RF register\n"); + return 0xff; + } + return tmp & 0xff; +} + +void +rt3090_rf_write(struct rt2860_softc *sc, uint8_t reg, uint8_t val) +{ + uint32_t tmp; + int ntries; + + for (ntries = 0; ntries < 10; ntries++) { + if (!(RAL_READ(sc, RT3070_RF_CSR_CFG) & RT3070_RF_KICK)) + break; + DELAY(10); + } + if (ntries == 10) { + device_printf(sc->sc_dev, "could not write to RF\n"); + return; + } + + tmp = RT3070_RF_WRITE | RT3070_RF_KICK | reg << 8 | val; + RAL_WRITE(sc, RT3070_RF_CSR_CFG, tmp); +} + +/* + * Send a command to the 8051 microcontroller unit. + */ +int +rt2860_mcu_cmd(struct rt2860_softc *sc, uint8_t cmd, uint16_t arg, int wait) +{ + int slot, ntries; + uint32_t tmp; + uint8_t cid; + + for (ntries = 0; ntries < 100; ntries++) { + if (!(RAL_READ(sc, RT2860_H2M_MAILBOX) & RT2860_H2M_BUSY)) + break; + DELAY(2); + } + if (ntries == 100) + return EIO; + + cid = wait ? cmd : RT2860_TOKEN_NO_INTR; + RAL_WRITE(sc, RT2860_H2M_MAILBOX, RT2860_H2M_BUSY | cid << 16 | arg); + RAL_BARRIER_WRITE(sc); + RAL_WRITE(sc, RT2860_HOST_CMD, cmd); + + if (!wait) + return 0; + /* wait for the command to complete */ + for (ntries = 0; ntries < 200; ntries++) { + tmp = RAL_READ(sc, RT2860_H2M_MAILBOX_CID); + /* find the command slot */ + for (slot = 0; slot < 4; slot++, tmp >>= 8) + if ((tmp & 0xff) == cid) + break; + if (slot < 4) + break; + DELAY(100); + } + if (ntries == 200) { + /* clear command and status */ + RAL_WRITE(sc, RT2860_H2M_MAILBOX_STATUS, 0xffffffff); + RAL_WRITE(sc, RT2860_H2M_MAILBOX_CID, 0xffffffff); + return ETIMEDOUT; + } + /* get command status (1 means success) */ + tmp = RAL_READ(sc, RT2860_H2M_MAILBOX_STATUS); + tmp = (tmp >> (slot * 8)) & 0xff; + DPRINTF(("MCU command=0x%02x slot=%d status=0x%02x\n", + cmd, slot, tmp)); + /* clear command and status */ + RAL_WRITE(sc, RT2860_H2M_MAILBOX_STATUS, 0xffffffff); + RAL_WRITE(sc, RT2860_H2M_MAILBOX_CID, 0xffffffff); + return (tmp == 1) ? 0 : EIO; +} + +static void +rt2860_enable_mrr(struct rt2860_softc *sc) +{ +#define CCK(mcs) (mcs) +#define OFDM(mcs) (1 << 3 | (mcs)) + RAL_WRITE(sc, RT2860_LG_FBK_CFG0, + OFDM(6) << 28 | /* 54->48 */ + OFDM(5) << 24 | /* 48->36 */ + OFDM(4) << 20 | /* 36->24 */ + OFDM(3) << 16 | /* 24->18 */ + OFDM(2) << 12 | /* 18->12 */ + OFDM(1) << 8 | /* 12-> 9 */ + OFDM(0) << 4 | /* 9-> 6 */ + OFDM(0)); /* 6-> 6 */ + + RAL_WRITE(sc, RT2860_LG_FBK_CFG1, + CCK(2) << 12 | /* 11->5.5 */ + CCK(1) << 8 | /* 5.5-> 2 */ + CCK(0) << 4 | /* 2-> 1 */ + CCK(0)); /* 1-> 1 */ +#undef OFDM +#undef CCK +} + +static void +rt2860_set_txpreamble(struct rt2860_softc *sc) +{ + struct ifnet *ifp = sc->sc_ifp; + struct ieee80211com *ic = ifp->if_l2com; + uint32_t tmp; + + tmp = RAL_READ(sc, RT2860_AUTO_RSP_CFG); + tmp &= ~RT2860_CCK_SHORT_EN; + if (ic->ic_flags & IEEE80211_F_SHPREAMBLE) + tmp |= RT2860_CCK_SHORT_EN; + RAL_WRITE(sc, RT2860_AUTO_RSP_CFG, tmp); +} + +void +rt2860_set_basicrates(struct rt2860_softc *sc, + const struct ieee80211_rateset *rs) +{ +#define RV(r) ((r) & IEEE80211_RATE_VAL) + struct ifnet *ifp = sc->sc_ifp; + struct ieee80211com *ic = ifp->if_l2com; + uint32_t mask = 0; + uint8_t rate; + int i; + + for (i = 0; i < rs->rs_nrates; i++) { + rate = rs->rs_rates[i]; + + if (!(rate & IEEE80211_RATE_BASIC)) + continue; + + mask |= 1 << ic->ic_rt->rateCodeToIndex[RV(rate)]; + } + + RAL_WRITE(sc, RT2860_LEGACY_BASIC_RATE, mask); +#undef RV +} + +static void +rt2860_scan_start(struct ieee80211com *ic) +{ + struct ifnet *ifp = ic->ic_ifp; + struct rt2860_softc *sc = ifp->if_softc; + uint32_t tmp; + + tmp = RAL_READ(sc, RT2860_BCN_TIME_CFG); + RAL_WRITE(sc, RT2860_BCN_TIME_CFG, + tmp & ~(RT2860_BCN_TX_EN | RT2860_TSF_TIMER_EN | + RT2860_TBTT_TIMER_EN)); + rt2860_set_gp_timer(sc, 0); + rt2860_set_bssid(sc, ifp->if_broadcastaddr); +} + +static void +rt2860_scan_end(struct ieee80211com *ic) +{ + struct ifnet *ifp = ic->ic_ifp; + struct rt2860_softc *sc = ifp->if_softc; + struct ieee80211vap *vap = TAILQ_FIRST(&ic->ic_vaps); + + rt2860_enable_tsf_sync(sc); + /* XXX keep local copy */ + rt2860_set_bssid(sc, vap->iv_bss->ni_bssid); + rt2860_set_gp_timer(sc, 500); +} + +static void +rt2860_set_channel(struct ieee80211com *ic) +{ + struct ifnet *ifp = ic->ic_ifp; + struct rt2860_softc *sc = ifp->if_softc; + + RAL_LOCK(sc); + rt2860_set_chan(sc, ieee80211_chan2ieee(ic, ic->ic_curchan)); + RAL_UNLOCK(sc); +} + +static void +rt2860_select_chan_group(struct rt2860_softc *sc, int group) +{ + uint32_t tmp; + uint8_t agc; + + rt2860_mcu_bbp_write(sc, 62, 0x37 - sc->lna[group]); + rt2860_mcu_bbp_write(sc, 63, 0x37 - sc->lna[group]); + rt2860_mcu_bbp_write(sc, 64, 0x37 - sc->lna[group]); + rt2860_mcu_bbp_write(sc, 86, 0x00); + + if (group == 0) { + if (sc->ext_2ghz_lna) { + rt2860_mcu_bbp_write(sc, 82, 0x62); + rt2860_mcu_bbp_write(sc, 75, 0x46); + } else { + rt2860_mcu_bbp_write(sc, 82, 0x84); + rt2860_mcu_bbp_write(sc, 75, 0x50); + } + } else { + if (sc->ext_5ghz_lna) { + rt2860_mcu_bbp_write(sc, 82, 0xf2); + rt2860_mcu_bbp_write(sc, 75, 0x46); + } else { + rt2860_mcu_bbp_write(sc, 82, 0xf2); + rt2860_mcu_bbp_write(sc, 75, 0x50); + } + } + + tmp = RAL_READ(sc, RT2860_TX_BAND_CFG); + tmp &= ~(RT2860_5G_BAND_SEL_N | RT2860_5G_BAND_SEL_P); + tmp |= (group == 0) ? RT2860_5G_BAND_SEL_N : RT2860_5G_BAND_SEL_P; + RAL_WRITE(sc, RT2860_TX_BAND_CFG, tmp); + + /* enable appropriate Power Amplifiers and Low Noise Amplifiers */ + tmp = RT2860_RFTR_EN | RT2860_TRSW_EN | RT2860_LNA_PE0_EN; + if (sc->nrxchains > 1) + tmp |= RT2860_LNA_PE1_EN; + if (sc->mac_ver == 0x3593 && sc->nrxchains > 2) + tmp |= RT3593_LNA_PE2_EN; + if (group == 0) { /* 2GHz */ + tmp |= RT2860_PA_PE_G0_EN; + if (sc->ntxchains > 1) + tmp |= RT2860_PA_PE_G1_EN; + if (sc->mac_ver == 0x3593 && sc->ntxchains > 2) + tmp |= RT3593_PA_PE_G2_EN; + } else { /* 5GHz */ + tmp |= RT2860_PA_PE_A0_EN; + if (sc->ntxchains > 1) + tmp |= RT2860_PA_PE_A1_EN; + if (sc->mac_ver == 0x3593 && sc->ntxchains > 2) + tmp |= RT3593_PA_PE_A2_EN; + } + RAL_WRITE(sc, RT2860_TX_PIN_CFG, tmp); + + if (sc->mac_ver == 0x3593) { + tmp = RAL_READ(sc, RT2860_GPIO_CTRL); + if (sc->sc_flags & RT2860_PCIE) { + tmp &= ~0x01010000; + if (group == 0) + tmp |= 0x00010000; + } else { + tmp &= ~0x00008080; + if (group == 0) + tmp |= 0x00000080; + } + tmp = (tmp & ~0x00001000) | 0x00000010; + RAL_WRITE(sc, RT2860_GPIO_CTRL, tmp); + } + + /* set initial AGC value */ + if (group == 0) { /* 2GHz band */ + if (sc->mac_ver >= 0x3071) + agc = 0x1c + sc->lna[0] * 2; + else + agc = 0x2e + sc->lna[0]; + } else { /* 5GHz band */ + agc = 0x32 + (sc->lna[group] * 5) / 3; + } + rt2860_mcu_bbp_write(sc, 66, agc); + + DELAY(1000); +} + +static void +rt2860_set_chan(struct rt2860_softc *sc, u_int chan) +{ + const struct rfprog *rfprog = rt2860_rf2850; + uint32_t r2, r3, r4; + int8_t txpow1, txpow2; + u_int i; + + /* find the settings for this channel (we know it exists) */ + for (i = 0; rfprog[i].chan != chan; i++); + + r2 = rfprog[i].r2; + if (sc->ntxchains == 1) + r2 |= 1 << 12; /* 1T: disable Tx chain 2 */ + if (sc->nrxchains == 1) + r2 |= 1 << 15 | 1 << 4; /* 1R: disable Rx chains 2 & 3 */ + else if (sc->nrxchains == 2) + r2 |= 1 << 4; /* 2R: disable Rx chain 3 */ + + /* use Tx power values from EEPROM */ + txpow1 = sc->txpow1[i]; + txpow2 = sc->txpow2[i]; + if (chan > 14) { + if (txpow1 >= 0) + txpow1 = txpow1 << 1 | 1; + else + txpow1 = (7 + txpow1) << 1; + if (txpow2 >= 0) + txpow2 = txpow2 << 1 | 1; + else + txpow2 = (7 + txpow2) << 1; + } + r3 = rfprog[i].r3 | txpow1 << 7; + r4 = rfprog[i].r4 | sc->freq << 13 | txpow2 << 4; + + rt2860_rf_write(sc, RT2860_RF1, rfprog[i].r1); + rt2860_rf_write(sc, RT2860_RF2, r2); + rt2860_rf_write(sc, RT2860_RF3, r3); + rt2860_rf_write(sc, RT2860_RF4, r4); + + DELAY(200); + + rt2860_rf_write(sc, RT2860_RF1, rfprog[i].r1); + rt2860_rf_write(sc, RT2860_RF2, r2); + rt2860_rf_write(sc, RT2860_RF3, r3 | 1); + rt2860_rf_write(sc, RT2860_RF4, r4); + + DELAY(200); + + rt2860_rf_write(sc, RT2860_RF1, rfprog[i].r1); + rt2860_rf_write(sc, RT2860_RF2, r2); + rt2860_rf_write(sc, RT2860_RF3, r3); + rt2860_rf_write(sc, RT2860_RF4, r4); +} + +static void +rt3090_set_chan(struct rt2860_softc *sc, u_int chan) +{ + int8_t txpow1, txpow2; + uint8_t rf; + int i; + + /* RT3090 is 2GHz only */ + KASSERT(chan >= 1 && chan <= 14, ("chan %d not support", chan)); + + /* find the settings for this channel (we know it exists) */ + for (i = 0; rt2860_rf2850[i].chan != chan; i++); + + /* use Tx power values from EEPROM */ + txpow1 = sc->txpow1[i]; + txpow2 = sc->txpow2[i]; + + rt3090_rf_write(sc, 2, rt3090_freqs[i].n); + rf = rt3090_rf_read(sc, 3); + rf = (rf & ~0x0f) | rt3090_freqs[i].k; + rt3090_rf_write(sc, 3, rf); + rf = rt3090_rf_read(sc, 6); + rf = (rf & ~0x03) | rt3090_freqs[i].r; + rt3090_rf_write(sc, 6, rf); + + /* set Tx0 power */ + rf = rt3090_rf_read(sc, 12); + rf = (rf & ~0x1f) | txpow1; + rt3090_rf_write(sc, 12, rf); + + /* set Tx1 power */ + rf = rt3090_rf_read(sc, 13); + rf = (rf & ~0x1f) | txpow2; + rt3090_rf_write(sc, 13, rf); + + rf = rt3090_rf_read(sc, 1); + rf &= ~0xfc; + if (sc->ntxchains == 1) + rf |= RT3070_TX1_PD | RT3070_TX2_PD; + else if (sc->ntxchains == 2) + rf |= RT3070_TX2_PD; + if (sc->nrxchains == 1) + rf |= RT3070_RX1_PD | RT3070_RX2_PD; + else if (sc->nrxchains == 2) + rf |= RT3070_RX2_PD; + rt3090_rf_write(sc, 1, rf); + + /* set RF offset */ + rf = rt3090_rf_read(sc, 23); + rf = (rf & ~0x7f) | sc->freq; + rt3090_rf_write(sc, 23, rf); + + /* program RF filter */ + rf = rt3090_rf_read(sc, 24); /* Tx */ + rf = (rf & ~0x3f) | sc->rf24_20mhz; + rt3090_rf_write(sc, 24, rf); + rf = rt3090_rf_read(sc, 31); /* Rx */ + rf = (rf & ~0x3f) | sc->rf24_20mhz; + rt3090_rf_write(sc, 31, rf); + + /* enable RF tuning */ + rf = rt3090_rf_read(sc, 7); + rt3090_rf_write(sc, 7, rf | RT3070_TUNE); +} + +static int +rt3090_rf_init(struct rt2860_softc *sc) +{ +#define N(a) (sizeof (a) / sizeof ((a)[0])) + uint32_t tmp; + uint8_t rf, bbp; + int i; + + rf = rt3090_rf_read(sc, 30); + /* toggle RF R30 bit 7 */ + rt3090_rf_write(sc, 30, rf | 0x80); + DELAY(1000); + rt3090_rf_write(sc, 30, rf & ~0x80); + + tmp = RAL_READ(sc, RT3070_LDO_CFG0); + tmp &= ~0x1f000000; + if (sc->patch_dac && sc->mac_rev < 0x0211) + tmp |= 0x0d000000; /* 1.35V */ + else + tmp |= 0x01000000; /* 1.2V */ + RAL_WRITE(sc, RT3070_LDO_CFG0, tmp); + + /* patch LNA_PE_G1 */ + tmp = RAL_READ(sc, RT3070_GPIO_SWITCH); + RAL_WRITE(sc, RT3070_GPIO_SWITCH, tmp & ~0x20); + + /* initialize RF registers to default value */ + for (i = 0; i < N(rt3090_def_rf); i++) { + rt3090_rf_write(sc, rt3090_def_rf[i].reg, + rt3090_def_rf[i].val); + } + + /* select 20MHz bandwidth */ + rt3090_rf_write(sc, 31, 0x14); + + rf = rt3090_rf_read(sc, 6); + rt3090_rf_write(sc, 6, rf | 0x40); + + if (sc->mac_ver != 0x3593) { + /* calibrate filter for 20MHz bandwidth */ + sc->rf24_20mhz = 0x1f; /* default value */ + rt3090_filter_calib(sc, 0x07, 0x16, &sc->rf24_20mhz); + + /* select 40MHz bandwidth */ + bbp = rt2860_mcu_bbp_read(sc, 4); + rt2860_mcu_bbp_write(sc, 4, (bbp & ~0x08) | 0x10); + rf = rt3090_rf_read(sc, 31); + rt3090_rf_write(sc, 31, rf | 0x20); + + /* calibrate filter for 40MHz bandwidth */ + sc->rf24_40mhz = 0x2f; /* default value */ + rt3090_filter_calib(sc, 0x27, 0x19, &sc->rf24_40mhz); + + /* go back to 20MHz bandwidth */ + bbp = rt2860_mcu_bbp_read(sc, 4); + rt2860_mcu_bbp_write(sc, 4, bbp & ~0x18); + } + if (sc->mac_rev < 0x0211) + rt3090_rf_write(sc, 27, 0x03); + + tmp = RAL_READ(sc, RT3070_OPT_14); + RAL_WRITE(sc, RT3070_OPT_14, tmp | 1); + + if (sc->rf_rev == RT3070_RF_3020) + rt3090_set_rx_antenna(sc, 0); + + bbp = rt2860_mcu_bbp_read(sc, 138); + if (sc->mac_ver == 0x3593) { + if (sc->ntxchains == 1) + bbp |= 0x60; /* turn off DAC1 and DAC2 */ + else if (sc->ntxchains == 2) + bbp |= 0x40; /* turn off DAC2 */ + if (sc->nrxchains == 1) + bbp &= ~0x06; /* turn off ADC1 and ADC2 */ + else if (sc->nrxchains == 2) + bbp &= ~0x04; /* turn off ADC2 */ + } else { + if (sc->ntxchains == 1) + bbp |= 0x20; /* turn off DAC1 */ + if (sc->nrxchains == 1) + bbp &= ~0x02; /* turn off ADC1 */ + } + rt2860_mcu_bbp_write(sc, 138, bbp); + + rf = rt3090_rf_read(sc, 1); + rf &= ~(RT3070_RX0_PD | RT3070_TX0_PD); + rf |= RT3070_RF_BLOCK | RT3070_RX1_PD | RT3070_TX1_PD; + rt3090_rf_write(sc, 1, rf); + + rf = rt3090_rf_read(sc, 15); + rt3090_rf_write(sc, 15, rf & ~RT3070_TX_LO2); + + rf = rt3090_rf_read(sc, 17); + rf &= ~RT3070_TX_LO1; + if (sc->mac_rev >= 0x0211 && !sc->ext_2ghz_lna) + rf |= 0x20; /* fix for long range Rx issue */ + if (sc->txmixgain_2ghz >= 2) + rf = (rf & ~0x7) | sc->txmixgain_2ghz; + rt3090_rf_write(sc, 17, rf); + + rf = rt3090_rf_read(sc, 20); + rt3090_rf_write(sc, 20, rf & ~RT3070_RX_LO1); + + rf = rt3090_rf_read(sc, 21); + rt3090_rf_write(sc, 21, rf & ~RT3070_RX_LO2); + + return 0; +#undef N +} + +void +rt3090_rf_wakeup(struct rt2860_softc *sc) +{ + uint32_t tmp; + uint8_t rf; + + if (sc->mac_ver == 0x3593) { + /* enable VCO */ + rf = rt3090_rf_read(sc, 1); + rt3090_rf_write(sc, 1, rf | RT3593_VCO); + + /* initiate VCO calibration */ + rf = rt3090_rf_read(sc, 3); + rt3090_rf_write(sc, 3, rf | RT3593_VCOCAL); + + /* enable VCO bias current control */ + rf = rt3090_rf_read(sc, 6); + rt3090_rf_write(sc, 6, rf | RT3593_VCO_IC); + + /* initiate res calibration */ + rf = rt3090_rf_read(sc, 2); + rt3090_rf_write(sc, 2, rf | RT3593_RESCAL); + + /* set reference current control to 0.33 mA */ + rf = rt3090_rf_read(sc, 22); + rf &= ~RT3593_CP_IC_MASK; + rf |= 1 << RT3593_CP_IC_SHIFT; + rt3090_rf_write(sc, 22, rf); + + /* enable RX CTB */ + rf = rt3090_rf_read(sc, 46); + rt3090_rf_write(sc, 46, rf | RT3593_RX_CTB); + + rf = rt3090_rf_read(sc, 20); + rf &= ~(RT3593_LDO_RF_VC_MASK | RT3593_LDO_PLL_VC_MASK); + rt3090_rf_write(sc, 20, rf); + } else { + /* enable RF block */ + rf = rt3090_rf_read(sc, 1); + rt3090_rf_write(sc, 1, rf | RT3070_RF_BLOCK); + + /* enable VCO bias current control */ + rf = rt3090_rf_read(sc, 7); + rt3090_rf_write(sc, 7, rf | 0x30); + + rf = rt3090_rf_read(sc, 9); + rt3090_rf_write(sc, 9, rf | 0x0e); + + /* enable RX CTB */ + rf = rt3090_rf_read(sc, 21); + rt3090_rf_write(sc, 21, rf | RT3070_RX_CTB); + + /* fix Tx to Rx IQ glitch by raising RF voltage */ + rf = rt3090_rf_read(sc, 27); + rf &= ~0x77; + if (sc->mac_rev < 0x0211) + rf |= 0x03; + rt3090_rf_write(sc, 27, rf); + } + if (sc->patch_dac && sc->mac_rev < 0x0211) { + tmp = RAL_READ(sc, RT3070_LDO_CFG0); + tmp = (tmp & ~0x1f000000) | 0x0d000000; + RAL_WRITE(sc, RT3070_LDO_CFG0, tmp); + } +} + +int +rt3090_filter_calib(struct rt2860_softc *sc, uint8_t init, uint8_t target, + uint8_t *val) +{ + uint8_t rf22, rf24; + uint8_t bbp55_pb, bbp55_sb, delta; + int ntries; + + /* program filter */ + rf24 = rt3090_rf_read(sc, 24); + rf24 = (rf24 & 0xc0) | init; /* initial filter value */ + rt3090_rf_write(sc, 24, rf24); + + /* enable baseband loopback mode */ + rf22 = rt3090_rf_read(sc, 22); + rt3090_rf_write(sc, 22, rf22 | RT3070_BB_LOOPBACK); + + /* set power and frequency of passband test tone */ + rt2860_mcu_bbp_write(sc, 24, 0x00); + for (ntries = 0; ntries < 100; ntries++) { + /* transmit test tone */ + rt2860_mcu_bbp_write(sc, 25, 0x90); + DELAY(1000); + /* read received power */ + bbp55_pb = rt2860_mcu_bbp_read(sc, 55); + if (bbp55_pb != 0) + break; + } + if (ntries == 100) + return ETIMEDOUT; + + /* set power and frequency of stopband test tone */ + rt2860_mcu_bbp_write(sc, 24, 0x06); + for (ntries = 0; ntries < 100; ntries++) { + /* transmit test tone */ + rt2860_mcu_bbp_write(sc, 25, 0x90); + DELAY(1000); + /* read received power */ + bbp55_sb = rt2860_mcu_bbp_read(sc, 55); + + delta = bbp55_pb - bbp55_sb; + if (delta > target) + break; + + /* reprogram filter */ + rf24++; + rt3090_rf_write(sc, 24, rf24); + } + if (ntries < 100) { + if (rf24 != init) + rf24--; /* backtrack */ + *val = rf24; + rt3090_rf_write(sc, 24, rf24); + } + + /* restore initial state */ + rt2860_mcu_bbp_write(sc, 24, 0x00); + + /* disable baseband loopback mode */ + rf22 = rt3090_rf_read(sc, 22); + rt3090_rf_write(sc, 22, rf22 & ~RT3070_BB_LOOPBACK); + + return 0; +} + +static void +rt3090_rf_setup(struct rt2860_softc *sc) +{ + uint8_t bbp; + int i; + + if (sc->mac_rev >= 0x0211) { + /* enable DC filter */ + rt2860_mcu_bbp_write(sc, 103, 0xc0); + + /* improve power consumption */ + bbp = rt2860_mcu_bbp_read(sc, 31); + rt2860_mcu_bbp_write(sc, 31, bbp & ~0x03); + } + + RAL_WRITE(sc, RT2860_TX_SW_CFG1, 0); + if (sc->mac_rev < 0x0211) { + RAL_WRITE(sc, RT2860_TX_SW_CFG2, + sc->patch_dac ? 0x2c : 0x0f); + } else + RAL_WRITE(sc, RT2860_TX_SW_CFG2, 0); + + /* initialize RF registers from ROM */ + for (i = 0; i < 10; i++) { + if (sc->rf[i].reg == 0 || sc->rf[i].reg == 0xff) + continue; + rt3090_rf_write(sc, sc->rf[i].reg, sc->rf[i].val); + } +} + +static void +rt2860_set_leds(struct rt2860_softc *sc, uint16_t which) +{ + rt2860_mcu_cmd(sc, RT2860_MCU_CMD_LEDS, + which | (sc->leds & 0x7f), 0); +} + +/* + * Hardware has a general-purpose programmable timer interrupt that can + * periodically raise MAC_INT_4. + */ +static void +rt2860_set_gp_timer(struct rt2860_softc *sc, int ms) +{ + uint32_t tmp; + + /* disable GP timer before reprogramming it */ + tmp = RAL_READ(sc, RT2860_INT_TIMER_EN); + RAL_WRITE(sc, RT2860_INT_TIMER_EN, tmp & ~RT2860_GP_TIMER_EN); + + if (ms == 0) + return; + + tmp = RAL_READ(sc, RT2860_INT_TIMER_CFG); + ms *= 16; /* Unit: 64us */ + tmp = (tmp & 0xffff) | ms << RT2860_GP_TIMER_SHIFT; + RAL_WRITE(sc, RT2860_INT_TIMER_CFG, tmp); + + /* enable GP timer */ + tmp = RAL_READ(sc, RT2860_INT_TIMER_EN); + RAL_WRITE(sc, RT2860_INT_TIMER_EN, tmp | RT2860_GP_TIMER_EN); +} + +static void +rt2860_set_bssid(struct rt2860_softc *sc, const uint8_t *bssid) +{ + RAL_WRITE(sc, RT2860_MAC_BSSID_DW0, + bssid[0] | bssid[1] << 8 | bssid[2] << 16 | bssid[3] << 24); + RAL_WRITE(sc, RT2860_MAC_BSSID_DW1, + bssid[4] | bssid[5] << 8); +} + +static void +rt2860_set_macaddr(struct rt2860_softc *sc, const uint8_t *addr) +{ + RAL_WRITE(sc, RT2860_MAC_ADDR_DW0, + addr[0] | addr[1] << 8 | addr[2] << 16 | addr[3] << 24); + RAL_WRITE(sc, RT2860_MAC_ADDR_DW1, + addr[4] | addr[5] << 8 | 0xff << 16); +} + +static void +rt2860_updateslot(struct ifnet *ifp) +{ + struct rt2860_softc *sc = ifp->if_softc; + struct ieee80211com *ic = ifp->if_l2com; + uint32_t tmp; + + tmp = RAL_READ(sc, RT2860_BKOFF_SLOT_CFG); + tmp &= ~0xff; + tmp |= (ic->ic_flags & IEEE80211_F_SHSLOT) ? 9 : 20; + RAL_WRITE(sc, RT2860_BKOFF_SLOT_CFG, tmp); +} + +static void +rt2860_updateprot(struct ifnet *ifp) +{ + struct rt2860_softc *sc = ifp->if_softc; + struct ieee80211com *ic = ifp->if_l2com; + uint32_t tmp; + + tmp = RT2860_RTSTH_EN | RT2860_PROT_NAV_SHORT | RT2860_TXOP_ALLOW_ALL; + /* setup protection frame rate (MCS code) */ + tmp |= IEEE80211_IS_CHAN_5GHZ(ic->ic_curchan) ? + rt2860_rates[RT2860_RIDX_OFDM6].mcs : + rt2860_rates[RT2860_RIDX_CCK11].mcs; + + /* CCK frames don't require protection */ + RAL_WRITE(sc, RT2860_CCK_PROT_CFG, tmp); + + if (ic->ic_flags & IEEE80211_F_USEPROT) { + if (ic->ic_protmode == IEEE80211_PROT_RTSCTS) + tmp |= RT2860_PROT_CTRL_RTS_CTS; + else if (ic->ic_protmode == IEEE80211_PROT_CTSONLY) + tmp |= RT2860_PROT_CTRL_CTS; + } + RAL_WRITE(sc, RT2860_OFDM_PROT_CFG, tmp); +} + +static void +rt2860_update_promisc(struct ifnet *ifp) +{ + struct rt2860_softc *sc = ifp->if_softc; + uint32_t tmp; + + tmp = RAL_READ(sc, RT2860_RX_FILTR_CFG); + tmp &= ~RT2860_DROP_NOT_MYBSS; + if (!(ifp->if_flags & IFF_PROMISC)) + tmp |= RT2860_DROP_NOT_MYBSS; + RAL_WRITE(sc, RT2860_RX_FILTR_CFG, tmp); +} + +static int +rt2860_updateedca(struct ieee80211com *ic) +{ + struct rt2860_softc *sc = ic->ic_ifp->if_softc; + const struct wmeParams *wmep; + int aci; + + wmep = ic->ic_wme.wme_chanParams.cap_wmeParams; + + /* update MAC TX configuration registers */ + for (aci = 0; aci < WME_NUM_AC; aci++) { + RAL_WRITE(sc, RT2860_EDCA_AC_CFG(aci), + wmep[aci].wmep_logcwmax << 16 | + wmep[aci].wmep_logcwmin << 12 | + wmep[aci].wmep_aifsn << 8 | + wmep[aci].wmep_txopLimit); + } + + /* update SCH/DMA registers too */ + RAL_WRITE(sc, RT2860_WMM_AIFSN_CFG, + wmep[WME_AC_VO].wmep_aifsn << 12 | + wmep[WME_AC_VI].wmep_aifsn << 8 | + wmep[WME_AC_BK].wmep_aifsn << 4 | + wmep[WME_AC_BE].wmep_aifsn); + RAL_WRITE(sc, RT2860_WMM_CWMIN_CFG, + wmep[WME_AC_VO].wmep_logcwmin << 12 | + wmep[WME_AC_VI].wmep_logcwmin << 8 | + wmep[WME_AC_BK].wmep_logcwmin << 4 | + wmep[WME_AC_BE].wmep_logcwmin); + RAL_WRITE(sc, RT2860_WMM_CWMAX_CFG, + wmep[WME_AC_VO].wmep_logcwmax << 12 | + wmep[WME_AC_VI].wmep_logcwmax << 8 | + wmep[WME_AC_BK].wmep_logcwmax << 4 | + wmep[WME_AC_BE].wmep_logcwmax); + RAL_WRITE(sc, RT2860_WMM_TXOP0_CFG, + wmep[WME_AC_BK].wmep_txopLimit << 16 | + wmep[WME_AC_BE].wmep_txopLimit); + RAL_WRITE(sc, RT2860_WMM_TXOP1_CFG, + wmep[WME_AC_VO].wmep_txopLimit << 16 | + wmep[WME_AC_VI].wmep_txopLimit); + + return 0; +} + +#ifdef HW_CRYPTO +static int +rt2860_set_key(struct ieee80211com *ic, struct ieee80211_node *ni, + struct ieee80211_key *k) +{ + struct rt2860_softc *sc = ic->ic_softc; + bus_size_t base; + uint32_t attr; + uint8_t mode, wcid, iv[8]; + + /* defer setting of WEP keys until interface is brought up */ + if ((ic->ic_if.if_flags & (IFF_UP | IFF_RUNNING)) != + (IFF_UP | IFF_RUNNING)) + return 0; + + /* map net80211 cipher to RT2860 security mode */ + switch (k->k_cipher) { + case IEEE80211_CIPHER_WEP40: + mode = RT2860_MODE_WEP40; + break; + case IEEE80211_CIPHER_WEP104: + mode = RT2860_MODE_WEP104; + break; + case IEEE80211_CIPHER_TKIP: + mode = RT2860_MODE_TKIP; + break; + case IEEE80211_CIPHER_CCMP: + mode = RT2860_MODE_AES_CCMP; + break; + default: + return EINVAL; + } + + if (k->k_flags & IEEE80211_KEY_GROUP) { + wcid = 0; /* NB: update WCID0 for group keys */ + base = RT2860_SKEY(0, k->k_id); + } else { + wcid = ((struct rt2860_node *)ni)->wcid; + base = RT2860_PKEY(wcid); + } + + if (k->k_cipher == IEEE80211_CIPHER_TKIP) { + RAL_WRITE_REGION_1(sc, base, k->k_key, 16); +#ifndef IEEE80211_STA_ONLY + if (ic->ic_opmode == IEEE80211_M_HOSTAP) { + RAL_WRITE_REGION_1(sc, base + 16, &k->k_key[16], 8); + RAL_WRITE_REGION_1(sc, base + 24, &k->k_key[24], 8); + } else +#endif + { + RAL_WRITE_REGION_1(sc, base + 16, &k->k_key[24], 8); + RAL_WRITE_REGION_1(sc, base + 24, &k->k_key[16], 8); + } + } else + RAL_WRITE_REGION_1(sc, base, k->k_key, k->k_len); + + if (!(k->k_flags & IEEE80211_KEY_GROUP) || + (k->k_flags & IEEE80211_KEY_TX)) { + /* set initial packet number in IV+EIV */ + if (k->k_cipher == IEEE80211_CIPHER_WEP40 || + k->k_cipher == IEEE80211_CIPHER_WEP104) { + uint32_t val = arc4random(); + /* skip weak IVs from Fluhrer/Mantin/Shamir */ + if (val >= 0x03ff00 && (val & 0xf8ff00) == 0x00ff00) + val += 0x000100; + iv[0] = val; + iv[1] = val >> 8; + iv[2] = val >> 16; + iv[3] = k->k_id << 6; + iv[4] = iv[5] = iv[6] = iv[7] = 0; + } else { + if (k->k_cipher == IEEE80211_CIPHER_TKIP) { + iv[0] = k->k_tsc >> 8; + iv[1] = (iv[0] | 0x20) & 0x7f; + iv[2] = k->k_tsc; + } else /* CCMP */ { + iv[0] = k->k_tsc; + iv[1] = k->k_tsc >> 8; + iv[2] = 0; + } + iv[3] = k->k_id << 6 | IEEE80211_WEP_EXTIV; + iv[4] = k->k_tsc >> 16; + iv[5] = k->k_tsc >> 24; + iv[6] = k->k_tsc >> 32; + iv[7] = k->k_tsc >> 40; + } + RAL_WRITE_REGION_1(sc, RT2860_IVEIV(wcid), iv, 8); + } + + if (k->k_flags & IEEE80211_KEY_GROUP) { + /* install group key */ + attr = RAL_READ(sc, RT2860_SKEY_MODE_0_7); + attr &= ~(0xf << (k->k_id * 4)); + attr |= mode << (k->k_id * 4); + RAL_WRITE(sc, RT2860_SKEY_MODE_0_7, attr); + } else { + /* install pairwise key */ + attr = RAL_READ(sc, RT2860_WCID_ATTR(wcid)); + attr = (attr & ~0xf) | (mode << 1) | RT2860_RX_PKEY_EN; + RAL_WRITE(sc, RT2860_WCID_ATTR(wcid), attr); + } + return 0; +} + +static void +rt2860_delete_key(struct ieee80211com *ic, struct ieee80211_node *ni, + struct ieee80211_key *k) +{ + struct rt2860_softc *sc = ic->ic_softc; + uint32_t attr; + uint8_t wcid; + + if (k->k_flags & IEEE80211_KEY_GROUP) { + /* remove group key */ + attr = RAL_READ(sc, RT2860_SKEY_MODE_0_7); + attr &= ~(0xf << (k->k_id * 4)); + RAL_WRITE(sc, RT2860_SKEY_MODE_0_7, attr); + + } else { + /* remove pairwise key */ + wcid = ((struct rt2860_node *)ni)->wcid; + attr = RAL_READ(sc, RT2860_WCID_ATTR(wcid)); + attr &= ~0xf; + RAL_WRITE(sc, RT2860_WCID_ATTR(wcid), attr); + } +} +#endif + +static int8_t +rt2860_rssi2dbm(struct rt2860_softc *sc, uint8_t rssi, uint8_t rxchain) +{ + struct ifnet *ifp = sc->sc_ifp; + struct ieee80211com *ic = ifp->if_l2com; + struct ieee80211_channel *c = ic->ic_curchan; + int delta; + + if (IEEE80211_IS_CHAN_5GHZ(c)) { + u_int chan = ieee80211_chan2ieee(ic, c); + delta = sc->rssi_5ghz[rxchain]; + + /* determine channel group */ + if (chan <= 64) + delta -= sc->lna[1]; + else if (chan <= 128) + delta -= sc->lna[2]; + else + delta -= sc->lna[3]; + } else + delta = sc->rssi_2ghz[rxchain] - sc->lna[0]; + + return -12 - delta - rssi; +} + +/* + * Add `delta' (signed) to each 4-bit sub-word of a 32-bit word. + * Used to adjust per-rate Tx power registers. + */ +static __inline uint32_t +b4inc(uint32_t b32, int8_t delta) +{ + int8_t i, b4; + + for (i = 0; i < 8; i++) { + b4 = b32 & 0xf; + b4 += delta; + if (b4 < 0) + b4 = 0; + else if (b4 > 0xf) + b4 = 0xf; + b32 = b32 >> 4 | b4 << 28; + } + return b32; +} + +static const char * +rt2860_get_rf(uint8_t rev) +{ + switch (rev) { + case RT2860_RF_2820: return "RT2820"; + case RT2860_RF_2850: return "RT2850"; + case RT2860_RF_2720: return "RT2720"; + case RT2860_RF_2750: return "RT2750"; + case RT3070_RF_3020: return "RT3020"; + case RT3070_RF_2020: return "RT2020"; + case RT3070_RF_3021: return "RT3021"; + case RT3070_RF_3022: return "RT3022"; + case RT3070_RF_3052: return "RT3052"; + case RT3070_RF_3320: return "RT3320"; + case RT3070_RF_3053: return "RT3053"; + default: return "unknown"; + } +} + +static int +rt2860_read_eeprom(struct rt2860_softc *sc, uint8_t macaddr[IEEE80211_ADDR_LEN]) +{ + int8_t delta_2ghz, delta_5ghz; + uint32_t tmp; + uint16_t val; + int ridx, ant, i; + + /* check whether the ROM is eFUSE ROM or EEPROM */ + sc->sc_srom_read = rt2860_eeprom_read_2; + if (sc->mac_ver >= 0x3071) { + tmp = RAL_READ(sc, RT3070_EFUSE_CTRL); + DPRINTF(("EFUSE_CTRL=0x%08x\n", tmp)); + if (tmp & RT3070_SEL_EFUSE) + sc->sc_srom_read = rt3090_efuse_read_2; + } + + /* read EEPROM version */ + val = rt2860_srom_read(sc, RT2860_EEPROM_VERSION); + DPRINTF(("EEPROM rev=%d, FAE=%d\n", val & 0xff, val >> 8)); + + /* read MAC address */ + val = rt2860_srom_read(sc, RT2860_EEPROM_MAC01); + macaddr[0] = val & 0xff; + macaddr[1] = val >> 8; + val = rt2860_srom_read(sc, RT2860_EEPROM_MAC23); + macaddr[2] = val & 0xff; + macaddr[3] = val >> 8; + val = rt2860_srom_read(sc, RT2860_EEPROM_MAC45); + macaddr[4] = val & 0xff; + macaddr[5] = val >> 8; + + /* read country code */ + val = rt2860_srom_read(sc, RT2860_EEPROM_COUNTRY); + DPRINTF(("EEPROM region code=0x%04x\n", val)); + + /* read vendor BBP settings */ + for (i = 0; i < 8; i++) { + val = rt2860_srom_read(sc, RT2860_EEPROM_BBP_BASE + i); + sc->bbp[i].val = val & 0xff; + sc->bbp[i].reg = val >> 8; + DPRINTF(("BBP%d=0x%02x\n", sc->bbp[i].reg, sc->bbp[i].val)); + } + if (sc->mac_ver >= 0x3071) { + /* read vendor RF settings */ + for (i = 0; i < 10; i++) { + val = rt2860_srom_read(sc, RT3071_EEPROM_RF_BASE + i); + sc->rf[i].val = val & 0xff; + sc->rf[i].reg = val >> 8; + DPRINTF(("RF%d=0x%02x\n", sc->rf[i].reg, + sc->rf[i].val)); + } + } + + /* read RF frequency offset from EEPROM */ + val = rt2860_srom_read(sc, RT2860_EEPROM_FREQ_LEDS); + sc->freq = ((val & 0xff) != 0xff) ? val & 0xff : 0; + DPRINTF(("EEPROM freq offset %d\n", sc->freq & 0xff)); + if ((val >> 8) != 0xff) { + /* read LEDs operating mode */ + sc->leds = val >> 8; + sc->led[0] = rt2860_srom_read(sc, RT2860_EEPROM_LED1); + sc->led[1] = rt2860_srom_read(sc, RT2860_EEPROM_LED2); + sc->led[2] = rt2860_srom_read(sc, RT2860_EEPROM_LED3); + } else { + /* broken EEPROM, use default settings */ + sc->leds = 0x01; + sc->led[0] = 0x5555; + sc->led[1] = 0x2221; + sc->led[2] = 0xa9f8; + } + DPRINTF(("EEPROM LED mode=0x%02x, LEDs=0x%04x/0x%04x/0x%04x\n", + sc->leds, sc->led[0], sc->led[1], sc->led[2])); + + /* read RF information */ + val = rt2860_srom_read(sc, RT2860_EEPROM_ANTENNA); + if (val == 0xffff) { + DPRINTF(("invalid EEPROM antenna info, using default\n")); + if (sc->mac_ver == 0x3593) { + /* default to RF3053 3T3R */ + sc->rf_rev = RT3070_RF_3053; + sc->ntxchains = 3; + sc->nrxchains = 3; + } else if (sc->mac_ver >= 0x3071) { + /* default to RF3020 1T1R */ + sc->rf_rev = RT3070_RF_3020; + sc->ntxchains = 1; + sc->nrxchains = 1; + } else { + /* default to RF2820 1T2R */ + sc->rf_rev = RT2860_RF_2820; + sc->ntxchains = 1; + sc->nrxchains = 2; + } + } else { + sc->rf_rev = (val >> 8) & 0xf; + sc->ntxchains = (val >> 4) & 0xf; + sc->nrxchains = val & 0xf; + } + DPRINTF(("EEPROM RF rev=0x%02x chains=%dT%dR\n", + sc->rf_rev, sc->ntxchains, sc->nrxchains)); + + /* check if RF supports automatic Tx access gain control */ + val = rt2860_srom_read(sc, RT2860_EEPROM_CONFIG); + DPRINTF(("EEPROM CFG 0x%04x\n", val)); + /* check if driver should patch the DAC issue */ + if ((val >> 8) != 0xff) + sc->patch_dac = (val >> 15) & 1; + if ((val & 0xff) != 0xff) { + sc->ext_5ghz_lna = (val >> 3) & 1; + sc->ext_2ghz_lna = (val >> 2) & 1; + /* check if RF supports automatic Tx access gain control */ + sc->calib_2ghz = sc->calib_5ghz = 0; /* XXX (val >> 1) & 1 */; + /* check if we have a hardware radio switch */ + sc->rfswitch = val & 1; + } + if (sc->sc_flags & RT2860_ADVANCED_PS) { + /* read PCIe power save level */ + val = rt2860_srom_read(sc, RT2860_EEPROM_PCIE_PSLEVEL); + if ((val & 0xff) != 0xff) { + sc->pslevel = val & 0x3; + val = rt2860_srom_read(sc, RT2860_EEPROM_REV); + if ((val & 0xff80) != 0x9280) + sc->pslevel = MIN(sc->pslevel, 1); + DPRINTF(("EEPROM PCIe PS Level=%d\n", sc->pslevel)); + } + } + + /* read power settings for 2GHz channels */ + for (i = 0; i < 14; i += 2) { + val = rt2860_srom_read(sc, + RT2860_EEPROM_PWR2GHZ_BASE1 + i / 2); + sc->txpow1[i + 0] = (int8_t)(val & 0xff); + sc->txpow1[i + 1] = (int8_t)(val >> 8); + + val = rt2860_srom_read(sc, + RT2860_EEPROM_PWR2GHZ_BASE2 + i / 2); + sc->txpow2[i + 0] = (int8_t)(val & 0xff); + sc->txpow2[i + 1] = (int8_t)(val >> 8); + } + /* fix broken Tx power entries */ + for (i = 0; i < 14; i++) { + if (sc->txpow1[i] < 0 || sc->txpow1[i] > 31) + sc->txpow1[i] = 5; + if (sc->txpow2[i] < 0 || sc->txpow2[i] > 31) + sc->txpow2[i] = 5; + DPRINTF(("chan %d: power1=%d, power2=%d\n", + rt2860_rf2850[i].chan, sc->txpow1[i], sc->txpow2[i])); + } + /* read power settings for 5GHz channels */ + for (i = 0; i < 40; i += 2) { + val = rt2860_srom_read(sc, + RT2860_EEPROM_PWR5GHZ_BASE1 + i / 2); + sc->txpow1[i + 14] = (int8_t)(val & 0xff); + sc->txpow1[i + 15] = (int8_t)(val >> 8); + + val = rt2860_srom_read(sc, + RT2860_EEPROM_PWR5GHZ_BASE2 + i / 2); + sc->txpow2[i + 14] = (int8_t)(val & 0xff); + sc->txpow2[i + 15] = (int8_t)(val >> 8); + } + /* fix broken Tx power entries */ + for (i = 0; i < 40; i++) { + if (sc->txpow1[14 + i] < -7 || sc->txpow1[14 + i] > 15) + sc->txpow1[14 + i] = 5; + if (sc->txpow2[14 + i] < -7 || sc->txpow2[14 + i] > 15) + sc->txpow2[14 + i] = 5; + DPRINTF(("chan %d: power1=%d, power2=%d\n", + rt2860_rf2850[14 + i].chan, sc->txpow1[14 + i], + sc->txpow2[14 + i])); + } + + /* read Tx power compensation for each Tx rate */ + val = rt2860_srom_read(sc, RT2860_EEPROM_DELTAPWR); + delta_2ghz = delta_5ghz = 0; + if ((val & 0xff) != 0xff && (val & 0x80)) { + delta_2ghz = val & 0xf; + if (!(val & 0x40)) /* negative number */ + delta_2ghz = -delta_2ghz; + } + val >>= 8; + if ((val & 0xff) != 0xff && (val & 0x80)) { + delta_5ghz = val & 0xf; + if (!(val & 0x40)) /* negative number */ + delta_5ghz = -delta_5ghz; + } + DPRINTF(("power compensation=%d (2GHz), %d (5GHz)\n", + delta_2ghz, delta_5ghz)); + + for (ridx = 0; ridx < 5; ridx++) { + uint32_t reg; + + val = rt2860_srom_read(sc, RT2860_EEPROM_RPWR + ridx * 2); + reg = val; + val = rt2860_srom_read(sc, RT2860_EEPROM_RPWR + ridx * 2 + 1); + reg |= (uint32_t)val << 16; + + sc->txpow20mhz[ridx] = reg; + sc->txpow40mhz_2ghz[ridx] = b4inc(reg, delta_2ghz); + sc->txpow40mhz_5ghz[ridx] = b4inc(reg, delta_5ghz); + + DPRINTF(("ridx %d: power 20MHz=0x%08x, 40MHz/2GHz=0x%08x, " + "40MHz/5GHz=0x%08x\n", ridx, sc->txpow20mhz[ridx], + sc->txpow40mhz_2ghz[ridx], sc->txpow40mhz_5ghz[ridx])); + } + + /* read factory-calibrated samples for temperature compensation */ + val = rt2860_srom_read(sc, RT2860_EEPROM_TSSI1_2GHZ); + sc->tssi_2ghz[0] = val & 0xff; /* [-4] */ + sc->tssi_2ghz[1] = val >> 8; /* [-3] */ + val = rt2860_srom_read(sc, RT2860_EEPROM_TSSI2_2GHZ); + sc->tssi_2ghz[2] = val & 0xff; /* [-2] */ + sc->tssi_2ghz[3] = val >> 8; /* [-1] */ + val = rt2860_srom_read(sc, RT2860_EEPROM_TSSI3_2GHZ); + sc->tssi_2ghz[4] = val & 0xff; /* [+0] */ + sc->tssi_2ghz[5] = val >> 8; /* [+1] */ + val = rt2860_srom_read(sc, RT2860_EEPROM_TSSI4_2GHZ); + sc->tssi_2ghz[6] = val & 0xff; /* [+2] */ + sc->tssi_2ghz[7] = val >> 8; /* [+3] */ + val = rt2860_srom_read(sc, RT2860_EEPROM_TSSI5_2GHZ); + sc->tssi_2ghz[8] = val & 0xff; /* [+4] */ + sc->step_2ghz = val >> 8; + DPRINTF(("TSSI 2GHz: 0x%02x 0x%02x 0x%02x 0x%02x 0x%02x 0x%02x 0x%02x " + "0x%02x 0x%02x step=%d\n", sc->tssi_2ghz[0], sc->tssi_2ghz[1], + sc->tssi_2ghz[2], sc->tssi_2ghz[3], sc->tssi_2ghz[4], + sc->tssi_2ghz[5], sc->tssi_2ghz[6], sc->tssi_2ghz[7], + sc->tssi_2ghz[8], sc->step_2ghz)); + /* check that ref value is correct, otherwise disable calibration */ + if (sc->tssi_2ghz[4] == 0xff) + sc->calib_2ghz = 0; + + val = rt2860_srom_read(sc, RT2860_EEPROM_TSSI1_5GHZ); + sc->tssi_5ghz[0] = val & 0xff; /* [-4] */ + sc->tssi_5ghz[1] = val >> 8; /* [-3] */ + val = rt2860_srom_read(sc, RT2860_EEPROM_TSSI2_5GHZ); + sc->tssi_5ghz[2] = val & 0xff; /* [-2] */ + sc->tssi_5ghz[3] = val >> 8; /* [-1] */ + val = rt2860_srom_read(sc, RT2860_EEPROM_TSSI3_5GHZ); + sc->tssi_5ghz[4] = val & 0xff; /* [+0] */ + sc->tssi_5ghz[5] = val >> 8; /* [+1] */ + val = rt2860_srom_read(sc, RT2860_EEPROM_TSSI4_5GHZ); + sc->tssi_5ghz[6] = val & 0xff; /* [+2] */ + sc->tssi_5ghz[7] = val >> 8; /* [+3] */ + val = rt2860_srom_read(sc, RT2860_EEPROM_TSSI5_5GHZ); + sc->tssi_5ghz[8] = val & 0xff; /* [+4] */ + sc->step_5ghz = val >> 8; + DPRINTF(("TSSI 5GHz: 0x%02x 0x%02x 0x%02x 0x%02x 0x%02x 0x%02x 0x%02x " + "0x%02x 0x%02x step=%d\n", sc->tssi_5ghz[0], sc->tssi_5ghz[1], + sc->tssi_5ghz[2], sc->tssi_5ghz[3], sc->tssi_5ghz[4], + sc->tssi_5ghz[5], sc->tssi_5ghz[6], sc->tssi_5ghz[7], + sc->tssi_5ghz[8], sc->step_5ghz)); + /* check that ref value is correct, otherwise disable calibration */ + if (sc->tssi_5ghz[4] == 0xff) + sc->calib_5ghz = 0; + + /* read RSSI offsets and LNA gains from EEPROM */ + val = rt2860_srom_read(sc, RT2860_EEPROM_RSSI1_2GHZ); + sc->rssi_2ghz[0] = val & 0xff; /* Ant A */ + sc->rssi_2ghz[1] = val >> 8; /* Ant B */ + val = rt2860_srom_read(sc, RT2860_EEPROM_RSSI2_2GHZ); + if (sc->mac_ver >= 0x3071) { + /* + * On RT3090 chips (limited to 2 Rx chains), this ROM + * field contains the Tx mixer gain for the 2GHz band. + */ + if ((val & 0xff) != 0xff) + sc->txmixgain_2ghz = val & 0x7; + DPRINTF(("tx mixer gain=%u (2GHz)\n", sc->txmixgain_2ghz)); + } else + sc->rssi_2ghz[2] = val & 0xff; /* Ant C */ + sc->lna[2] = val >> 8; /* channel group 2 */ + + val = rt2860_srom_read(sc, RT2860_EEPROM_RSSI1_5GHZ); + sc->rssi_5ghz[0] = val & 0xff; /* Ant A */ + sc->rssi_5ghz[1] = val >> 8; /* Ant B */ + val = rt2860_srom_read(sc, RT2860_EEPROM_RSSI2_5GHZ); + sc->rssi_5ghz[2] = val & 0xff; /* Ant C */ + sc->lna[3] = val >> 8; /* channel group 3 */ + + val = rt2860_srom_read(sc, RT2860_EEPROM_LNA); + if (sc->mac_ver >= 0x3071) + sc->lna[0] = RT3090_DEF_LNA; + else /* channel group 0 */ + sc->lna[0] = val & 0xff; + sc->lna[1] = val >> 8; /* channel group 1 */ + + /* fix broken 5GHz LNA entries */ + if (sc->lna[2] == 0 || sc->lna[2] == 0xff) { + DPRINTF(("invalid LNA for channel group %d\n", 2)); + sc->lna[2] = sc->lna[1]; + } + if (sc->lna[3] == 0 || sc->lna[3] == 0xff) { + DPRINTF(("invalid LNA for channel group %d\n", 3)); + sc->lna[3] = sc->lna[1]; + } + + /* fix broken RSSI offset entries */ + for (ant = 0; ant < 3; ant++) { + if (sc->rssi_2ghz[ant] < -10 || sc->rssi_2ghz[ant] > 10) { + DPRINTF(("invalid RSSI%d offset: %d (2GHz)\n", + ant + 1, sc->rssi_2ghz[ant])); + sc->rssi_2ghz[ant] = 0; + } + if (sc->rssi_5ghz[ant] < -10 || sc->rssi_5ghz[ant] > 10) { + DPRINTF(("invalid RSSI%d offset: %d (5GHz)\n", + ant + 1, sc->rssi_5ghz[ant])); + sc->rssi_5ghz[ant] = 0; + } + } + + return 0; +} + +int +rt2860_bbp_init(struct rt2860_softc *sc) +{ +#define N(a) (sizeof (a) / sizeof ((a)[0])) + int i, ntries; + + /* wait for BBP to wake up */ + for (ntries = 0; ntries < 20; ntries++) { + uint8_t bbp0 = rt2860_mcu_bbp_read(sc, 0); + if (bbp0 != 0 && bbp0 != 0xff) + break; + } + if (ntries == 20) { + device_printf(sc->sc_dev, + "timeout waiting for BBP to wake up\n"); + return ETIMEDOUT; + } + + /* initialize BBP registers to default values */ + for (i = 0; i < N(rt2860_def_bbp); i++) { + rt2860_mcu_bbp_write(sc, rt2860_def_bbp[i].reg, + rt2860_def_bbp[i].val); + } + + /* fix BBP84 for RT2860E */ + if (sc->mac_ver == 0x2860 && sc->mac_rev != 0x0101) + rt2860_mcu_bbp_write(sc, 84, 0x19); + + if (sc->mac_ver >= 0x3071) { + rt2860_mcu_bbp_write(sc, 79, 0x13); + rt2860_mcu_bbp_write(sc, 80, 0x05); + rt2860_mcu_bbp_write(sc, 81, 0x33); + } else if (sc->mac_ver == 0x2860 && sc->mac_rev == 0x0100) { + rt2860_mcu_bbp_write(sc, 69, 0x16); + rt2860_mcu_bbp_write(sc, 73, 0x12); + } + + return 0; +#undef N +} + +static int +rt2860_txrx_enable(struct rt2860_softc *sc) +{ + struct ifnet *ifp = sc->sc_ifp; + struct ieee80211com *ic = ifp->if_l2com; + uint32_t tmp; + int ntries; + + /* enable Tx/Rx DMA engine */ + RAL_WRITE(sc, RT2860_MAC_SYS_CTRL, RT2860_MAC_TX_EN); + RAL_BARRIER_READ_WRITE(sc); + for (ntries = 0; ntries < 200; ntries++) { + tmp = RAL_READ(sc, RT2860_WPDMA_GLO_CFG); + if ((tmp & (RT2860_TX_DMA_BUSY | RT2860_RX_DMA_BUSY)) == 0) + break; + DELAY(1000); + } + if (ntries == 200) { + device_printf(sc->sc_dev, "timeout waiting for DMA engine\n"); + return ETIMEDOUT; + } + + DELAY(50); + + tmp |= RT2860_RX_DMA_EN | RT2860_TX_DMA_EN | + RT2860_WPDMA_BT_SIZE64 << RT2860_WPDMA_BT_SIZE_SHIFT; + RAL_WRITE(sc, RT2860_WPDMA_GLO_CFG, tmp); + + /* set Rx filter */ + tmp = RT2860_DROP_CRC_ERR | RT2860_DROP_PHY_ERR; + if (ic->ic_opmode != IEEE80211_M_MONITOR) { + tmp |= RT2860_DROP_UC_NOME | RT2860_DROP_DUPL | + RT2860_DROP_CTS | RT2860_DROP_BA | RT2860_DROP_ACK | + RT2860_DROP_VER_ERR | RT2860_DROP_CTRL_RSV | + RT2860_DROP_CFACK | RT2860_DROP_CFEND; + if (ic->ic_opmode == IEEE80211_M_STA) + tmp |= RT2860_DROP_RTS | RT2860_DROP_PSPOLL; + } + RAL_WRITE(sc, RT2860_RX_FILTR_CFG, tmp); + + RAL_WRITE(sc, RT2860_MAC_SYS_CTRL, + RT2860_MAC_RX_EN | RT2860_MAC_TX_EN); + + return 0; +} + +static void +rt2860_init(void *arg) +{ + struct rt2860_softc *sc = arg; + struct ifnet *ifp = sc->sc_ifp; + struct ieee80211com *ic = ifp->if_l2com; + + RAL_LOCK(sc); + rt2860_init_locked(sc); + RAL_UNLOCK(sc); + + if (ifp->if_drv_flags & IFF_DRV_RUNNING) + ieee80211_start_all(ic); +} + +static void +rt2860_init_locked(struct rt2860_softc *sc) +{ +#define N(a) (sizeof (a) / sizeof ((a)[0])) + struct ifnet *ifp = sc->sc_ifp; + struct ieee80211com *ic = ifp->if_l2com; + uint32_t tmp; + uint8_t bbp1, bbp3; + int i, qid, ridx, ntries, error; + + RAL_LOCK_ASSERT(sc); + + if (sc->rfswitch) { + /* hardware has a radio switch on GPIO pin 2 */ + if (!(RAL_READ(sc, RT2860_GPIO_CTRL) & (1 << 2))) { + device_printf(sc->sc_dev, + "radio is disabled by hardware switch\n"); +#ifdef notyet + rt2860_stop_locked(sc); + return; +#endif + } + } + RAL_WRITE(sc, RT2860_PWR_PIN_CFG, RT2860_IO_RA_PE); + + /* disable DMA */ + tmp = RAL_READ(sc, RT2860_WPDMA_GLO_CFG); + tmp &= 0xff0; + RAL_WRITE(sc, RT2860_WPDMA_GLO_CFG, tmp); + + /* PBF hardware reset */ + RAL_WRITE(sc, RT2860_SYS_CTRL, 0xe1f); + RAL_BARRIER_WRITE(sc); + RAL_WRITE(sc, RT2860_SYS_CTRL, 0xe00); + + if ((error = rt2860_load_microcode(sc)) != 0) { + device_printf(sc->sc_dev, "could not load 8051 microcode\n"); + rt2860_stop_locked(sc); + return; + } + + rt2860_set_macaddr(sc, IF_LLADDR(ifp)); + + /* init Tx power for all Tx rates (from EEPROM) */ + for (ridx = 0; ridx < 5; ridx++) { + if (sc->txpow20mhz[ridx] == 0xffffffff) + continue; + RAL_WRITE(sc, RT2860_TX_PWR_CFG(ridx), sc->txpow20mhz[ridx]); + } + + for (ntries = 0; ntries < 100; ntries++) { + tmp = RAL_READ(sc, RT2860_WPDMA_GLO_CFG); + if ((tmp & (RT2860_TX_DMA_BUSY | RT2860_RX_DMA_BUSY)) == 0) + break; + DELAY(1000); + } + if (ntries == 100) { + device_printf(sc->sc_dev, "timeout waiting for DMA engine\n"); + rt2860_stop_locked(sc); + return; + } + tmp &= 0xff0; + RAL_WRITE(sc, RT2860_WPDMA_GLO_CFG, tmp); + + /* reset Rx ring and all 6 Tx rings */ + RAL_WRITE(sc, RT2860_WPDMA_RST_IDX, 0x1003f); + + /* PBF hardware reset */ + RAL_WRITE(sc, RT2860_SYS_CTRL, 0xe1f); + RAL_BARRIER_WRITE(sc); + RAL_WRITE(sc, RT2860_SYS_CTRL, 0xe00); + + RAL_WRITE(sc, RT2860_PWR_PIN_CFG, RT2860_IO_RA_PE | RT2860_IO_RF_PE); + + RAL_WRITE(sc, RT2860_MAC_SYS_CTRL, RT2860_BBP_HRST | RT2860_MAC_SRST); + RAL_BARRIER_WRITE(sc); + RAL_WRITE(sc, RT2860_MAC_SYS_CTRL, 0); + + for (i = 0; i < N(rt2860_def_mac); i++) + RAL_WRITE(sc, rt2860_def_mac[i].reg, rt2860_def_mac[i].val); + if (sc->mac_ver >= 0x3071) { + /* set delay of PA_PE assertion to 1us (unit of 0.25us) */ + RAL_WRITE(sc, RT2860_TX_SW_CFG0, + 4 << RT2860_DLY_PAPE_EN_SHIFT); + } + + if (!(RAL_READ(sc, RT2860_PCI_CFG) & RT2860_PCI_CFG_PCI)) { + sc->sc_flags |= RT2860_PCIE; + /* PCIe has different clock cycle count than PCI */ + tmp = RAL_READ(sc, RT2860_US_CYC_CNT); + tmp = (tmp & ~0xff) | 0x7d; + RAL_WRITE(sc, RT2860_US_CYC_CNT, tmp); + } + + /* wait while MAC is busy */ + for (ntries = 0; ntries < 100; ntries++) { + if (!(RAL_READ(sc, RT2860_MAC_STATUS_REG) & + (RT2860_RX_STATUS_BUSY | RT2860_TX_STATUS_BUSY))) + break; + DELAY(1000); + } + if (ntries == 100) { + device_printf(sc->sc_dev, "timeout waiting for MAC\n"); + rt2860_stop_locked(sc); + return; + } + + /* clear Host to MCU mailbox */ + RAL_WRITE(sc, RT2860_H2M_BBPAGENT, 0); + RAL_WRITE(sc, RT2860_H2M_MAILBOX, 0); + + rt2860_mcu_cmd(sc, RT2860_MCU_CMD_RFRESET, 0, 0); + DELAY(1000); + + if ((error = rt2860_bbp_init(sc)) != 0) { + rt2860_stop_locked(sc); + return; + } + + /* clear RX WCID search table */ + RAL_SET_REGION_4(sc, RT2860_WCID_ENTRY(0), 0, 512); + /* clear pairwise key table */ + RAL_SET_REGION_4(sc, RT2860_PKEY(0), 0, 2048); + /* clear IV/EIV table */ + RAL_SET_REGION_4(sc, RT2860_IVEIV(0), 0, 512); + /* clear WCID attribute table */ + RAL_SET_REGION_4(sc, RT2860_WCID_ATTR(0), 0, 256); + /* clear shared key table */ + RAL_SET_REGION_4(sc, RT2860_SKEY(0, 0), 0, 8 * 32); + /* clear shared key mode */ + RAL_SET_REGION_4(sc, RT2860_SKEY_MODE_0_7, 0, 4); + + /* init Tx rings (4 EDCAs + HCCA + Mgt) */ + for (qid = 0; qid < 6; qid++) { + RAL_WRITE(sc, RT2860_TX_BASE_PTR(qid), sc->txq[qid].paddr); + RAL_WRITE(sc, RT2860_TX_MAX_CNT(qid), RT2860_TX_RING_COUNT); + RAL_WRITE(sc, RT2860_TX_CTX_IDX(qid), 0); + } + + /* init Rx ring */ + RAL_WRITE(sc, RT2860_RX_BASE_PTR, sc->rxq.paddr); + RAL_WRITE(sc, RT2860_RX_MAX_CNT, RT2860_RX_RING_COUNT); + RAL_WRITE(sc, RT2860_RX_CALC_IDX, RT2860_RX_RING_COUNT - 1); + + /* setup maximum buffer sizes */ + RAL_WRITE(sc, RT2860_MAX_LEN_CFG, 1 << 12 | + (MCLBYTES - sizeof (struct rt2860_rxwi) - 2)); + + for (ntries = 0; ntries < 100; ntries++) { + tmp = RAL_READ(sc, RT2860_WPDMA_GLO_CFG); + if ((tmp & (RT2860_TX_DMA_BUSY | RT2860_RX_DMA_BUSY)) == 0) + break; + DELAY(1000); + } + if (ntries == 100) { + device_printf(sc->sc_dev, "timeout waiting for DMA engine\n"); + rt2860_stop_locked(sc); + return; + } + tmp &= 0xff0; + RAL_WRITE(sc, RT2860_WPDMA_GLO_CFG, tmp); + + /* disable interrupts mitigation */ + RAL_WRITE(sc, RT2860_DELAY_INT_CFG, 0); + + /* write vendor-specific BBP values (from EEPROM) */ + for (i = 0; i < 8; i++) { + if (sc->bbp[i].reg == 0 || sc->bbp[i].reg == 0xff) + continue; + rt2860_mcu_bbp_write(sc, sc->bbp[i].reg, sc->bbp[i].val); + } + + /* select Main antenna for 1T1R devices */ + if (sc->rf_rev == RT3070_RF_2020 || + sc->rf_rev == RT3070_RF_3020 || + sc->rf_rev == RT3070_RF_3320) + rt3090_set_rx_antenna(sc, 0); + + /* send LEDs operating mode to microcontroller */ + rt2860_mcu_cmd(sc, RT2860_MCU_CMD_LED1, sc->led[0], 0); + rt2860_mcu_cmd(sc, RT2860_MCU_CMD_LED2, sc->led[1], 0); + rt2860_mcu_cmd(sc, RT2860_MCU_CMD_LED3, sc->led[2], 0); + + if (sc->mac_ver >= 0x3071) + rt3090_rf_init(sc); + + rt2860_mcu_cmd(sc, RT2860_MCU_CMD_SLEEP, 0x02ff, 1); + rt2860_mcu_cmd(sc, RT2860_MCU_CMD_WAKEUP, 0, 1); + + if (sc->mac_ver >= 0x3071) + rt3090_rf_wakeup(sc); + + /* disable non-existing Rx chains */ + bbp3 = rt2860_mcu_bbp_read(sc, 3); + bbp3 &= ~(1 << 3 | 1 << 4); + if (sc->nrxchains == 2) + bbp3 |= 1 << 3; + else if (sc->nrxchains == 3) + bbp3 |= 1 << 4; + rt2860_mcu_bbp_write(sc, 3, bbp3); + + /* disable non-existing Tx chains */ + bbp1 = rt2860_mcu_bbp_read(sc, 1); + if (sc->ntxchains == 1) + bbp1 = (bbp1 & ~(1 << 3 | 1 << 4)); + else if (sc->mac_ver == 0x3593 && sc->ntxchains == 2) + bbp1 = (bbp1 & ~(1 << 4)) | 1 << 3; + else if (sc->mac_ver == 0x3593 && sc->ntxchains == 3) + bbp1 = (bbp1 & ~(1 << 3)) | 1 << 4; + rt2860_mcu_bbp_write(sc, 1, bbp1); + + if (sc->mac_ver >= 0x3071) + rt3090_rf_setup(sc); + + /* select default channel */ + rt2860_switch_chan(sc, ic->ic_curchan); + + /* reset RF from MCU */ + rt2860_mcu_cmd(sc, RT2860_MCU_CMD_RFRESET, 0, 0); + + /* set RTS threshold */ + tmp = RAL_READ(sc, RT2860_TX_RTS_CFG); + tmp &= ~0xffff00; + tmp |= IEEE80211_RTS_DEFAULT << 8; + RAL_WRITE(sc, RT2860_TX_RTS_CFG, tmp); + + /* setup initial protection mode */ + rt2860_updateprot(ifp); + + /* turn radio LED on */ + rt2860_set_leds(sc, RT2860_LED_RADIO); + + /* enable Tx/Rx DMA engine */ + if ((error = rt2860_txrx_enable(sc)) != 0) { + rt2860_stop_locked(sc); + return; + } + + /* clear pending interrupts */ + RAL_WRITE(sc, RT2860_INT_STATUS, 0xffffffff); + /* enable interrupts */ + RAL_WRITE(sc, RT2860_INT_MASK, 0x3fffc); + + if (sc->sc_flags & RT2860_ADVANCED_PS) + rt2860_mcu_cmd(sc, RT2860_MCU_CMD_PSLEVEL, sc->pslevel, 0); + + ifp->if_drv_flags &= ~IFF_DRV_OACTIVE; + ifp->if_drv_flags |= IFF_DRV_RUNNING; + + callout_reset(&sc->watchdog_ch, hz, rt2860_watchdog, sc); +#undef N +} + +static void +rt2860_stop(void *arg) +{ + struct rt2860_softc *sc = arg; + + RAL_LOCK(sc); + rt2860_stop_locked(sc); + RAL_UNLOCK(sc); +} + +static void +rt2860_stop_locked(struct rt2860_softc *sc) +{ + struct ifnet *ifp = sc->sc_ifp; + uint32_t tmp; + int qid; + + if (ifp->if_drv_flags & IFF_DRV_RUNNING) + rt2860_set_leds(sc, 0); /* turn all LEDs off */ + + callout_stop(&sc->watchdog_ch); + sc->sc_tx_timer = 0; + ifp->if_drv_flags &= ~(IFF_DRV_RUNNING | IFF_DRV_OACTIVE); + + /* disable interrupts */ + RAL_WRITE(sc, RT2860_INT_MASK, 0); + + /* disable GP timer */ + rt2860_set_gp_timer(sc, 0); + + /* disable Rx */ + tmp = RAL_READ(sc, RT2860_MAC_SYS_CTRL); + tmp &= ~(RT2860_MAC_RX_EN | RT2860_MAC_TX_EN); + RAL_WRITE(sc, RT2860_MAC_SYS_CTRL, tmp); + + /* reset adapter */ + RAL_WRITE(sc, RT2860_MAC_SYS_CTRL, RT2860_BBP_HRST | RT2860_MAC_SRST); + RAL_BARRIER_WRITE(sc); + RAL_WRITE(sc, RT2860_MAC_SYS_CTRL, 0); + + /* reset Tx and Rx rings (and reclaim TXWIs) */ + sc->qfullmsk = 0; + for (qid = 0; qid < 6; qid++) + rt2860_reset_tx_ring(sc, &sc->txq[qid]); + rt2860_reset_rx_ring(sc, &sc->rxq); +} + +int +rt2860_load_microcode(struct rt2860_softc *sc) +{ + const struct firmware *fp; + int ntries, error; + + RAL_LOCK_ASSERT(sc); + + RAL_UNLOCK(sc); + fp = firmware_get("rt2860fw"); + RAL_LOCK(sc); + if (fp == NULL) { + device_printf(sc->sc_dev, + "unable to receive rt2860fw firmware image\n"); + return EINVAL; + } + + /* set "host program ram write selection" bit */ + RAL_WRITE(sc, RT2860_SYS_CTRL, RT2860_HST_PM_SEL); + /* write microcode image */ + RAL_WRITE_REGION_1(sc, RT2860_FW_BASE, fp->data, fp->datasize); + /* kick microcontroller unit */ + RAL_WRITE(sc, RT2860_SYS_CTRL, 0); + RAL_BARRIER_WRITE(sc); + RAL_WRITE(sc, RT2860_SYS_CTRL, RT2860_MCU_RESET); + + RAL_WRITE(sc, RT2860_H2M_BBPAGENT, 0); + RAL_WRITE(sc, RT2860_H2M_MAILBOX, 0); + + /* wait until microcontroller is ready */ + RAL_BARRIER_READ_WRITE(sc); + for (ntries = 0; ntries < 1000; ntries++) { + if (RAL_READ(sc, RT2860_SYS_CTRL) & RT2860_MCU_READY) + break; + DELAY(1000); + } + if (ntries == 1000) { + device_printf(sc->sc_dev, + "timeout waiting for MCU to initialize\n"); + error = ETIMEDOUT; + } else + error = 0; + + firmware_put(fp, FIRMWARE_UNLOAD); + return error; +} + +/* + * This function is called periodically to adjust Tx power based on + * temperature variation. + */ +#ifdef NOT_YET +static void +rt2860_calib(struct rt2860_softc *sc) +{ + struct ieee80211com *ic = &sc->sc_ic; + const uint8_t *tssi; + uint8_t step, bbp49; + int8_t ridx, d; + + /* read current temperature */ + bbp49 = rt2860_mcu_bbp_read(sc, 49); + + if (IEEE80211_IS_CHAN_2GHZ(ic->ic_bss->ni_chan)) { + tssi = &sc->tssi_2ghz[4]; + step = sc->step_2ghz; + } else { + tssi = &sc->tssi_5ghz[4]; + step = sc->step_5ghz; + } + + if (bbp49 < tssi[0]) { /* lower than reference */ + /* use higher Tx power than default */ + for (d = 0; d > -4 && bbp49 <= tssi[d - 1]; d--); + } else if (bbp49 > tssi[0]) { /* greater than reference */ + /* use lower Tx power than default */ + for (d = 0; d < +4 && bbp49 >= tssi[d + 1]; d++); + } else { + /* use default Tx power */ + d = 0; + } + d *= step; + + DPRINTF(("BBP49=0x%02x, adjusting Tx power by %d\n", bbp49, d)); + + /* write adjusted Tx power values for each Tx rate */ + for (ridx = 0; ridx < 5; ridx++) { + if (sc->txpow20mhz[ridx] == 0xffffffff) + continue; + RAL_WRITE(sc, RT2860_TX_PWR_CFG(ridx), + b4inc(sc->txpow20mhz[ridx], d)); + } +} +#endif + +static void +rt3090_set_rx_antenna(struct rt2860_softc *sc, int aux) +{ + uint32_t tmp; + + if (aux) { + tmp = RAL_READ(sc, RT2860_PCI_EECTRL); + RAL_WRITE(sc, RT2860_PCI_EECTRL, tmp & ~RT2860_C); + tmp = RAL_READ(sc, RT2860_GPIO_CTRL); + RAL_WRITE(sc, RT2860_GPIO_CTRL, (tmp & ~0x0808) | 0x08); + } else { + tmp = RAL_READ(sc, RT2860_PCI_EECTRL); + RAL_WRITE(sc, RT2860_PCI_EECTRL, tmp | RT2860_C); + tmp = RAL_READ(sc, RT2860_GPIO_CTRL); + RAL_WRITE(sc, RT2860_GPIO_CTRL, tmp & ~0x0808); + } +} + +static void +rt2860_switch_chan(struct rt2860_softc *sc, struct ieee80211_channel *c) +{ + struct ifnet *ifp = sc->sc_ifp; + struct ieee80211com *ic = ifp->if_l2com; + u_int chan, group; + + chan = ieee80211_chan2ieee(ic, c); + if (chan == 0 || chan == IEEE80211_CHAN_ANY) + return; + + if (sc->mac_ver >= 0x3071) + rt3090_set_chan(sc, chan); + else + rt2860_set_chan(sc, chan); + + /* determine channel group */ + if (chan <= 14) + group = 0; + else if (chan <= 64) + group = 1; + else if (chan <= 128) + group = 2; + else + group = 3; + + /* XXX necessary only when group has changed! */ + rt2860_select_chan_group(sc, group); + + DELAY(1000); +} + +static int +rt2860_setup_beacon(struct rt2860_softc *sc, struct ieee80211vap *vap) +{ + struct ieee80211com *ic = vap->iv_ic; + struct ieee80211_beacon_offsets bo; + struct rt2860_txwi txwi; + struct mbuf *m; + int ridx; + + if ((m = ieee80211_beacon_alloc(vap->iv_bss, &bo)) == NULL) + return ENOBUFS; + + memset(&txwi, 0, sizeof txwi); + txwi.wcid = 0xff; + txwi.len = htole16(m->m_pkthdr.len); + /* send beacons at the lowest available rate */ + ridx = IEEE80211_IS_CHAN_5GHZ(ic->ic_bsschan) ? + RT2860_RIDX_OFDM6 : RT2860_RIDX_CCK1; + txwi.phy = htole16(rt2860_rates[ridx].mcs); + if (rt2860_rates[ridx].phy == IEEE80211_T_OFDM) + txwi.phy |= htole16(RT2860_PHY_OFDM); + txwi.txop = RT2860_TX_TXOP_HT; + txwi.flags = RT2860_TX_TS; + txwi.xflags = RT2860_TX_NSEQ; + + RAL_WRITE_REGION_1(sc, RT2860_BCN_BASE(0), + (uint8_t *)&txwi, sizeof txwi); + RAL_WRITE_REGION_1(sc, RT2860_BCN_BASE(0) + sizeof txwi, + mtod(m, uint8_t *), m->m_pkthdr.len); + + m_freem(m); + + return 0; +} + +static void +rt2860_enable_tsf_sync(struct rt2860_softc *sc) +{ + struct ifnet *ifp = sc->sc_ifp; + struct ieee80211com *ic = ifp->if_l2com; + struct ieee80211vap *vap = TAILQ_FIRST(&ic->ic_vaps); + uint32_t tmp; + + tmp = RAL_READ(sc, RT2860_BCN_TIME_CFG); + + tmp &= ~0x1fffff; + tmp |= vap->iv_bss->ni_intval * 16; + tmp |= RT2860_TSF_TIMER_EN | RT2860_TBTT_TIMER_EN; + if (vap->iv_opmode == IEEE80211_M_STA) { + /* + * Local TSF is always updated with remote TSF on beacon + * reception. + */ + tmp |= 1 << RT2860_TSF_SYNC_MODE_SHIFT; + } + else if (vap->iv_opmode == IEEE80211_M_IBSS || + vap->iv_opmode == IEEE80211_M_MBSS) { + tmp |= RT2860_BCN_TX_EN; + /* + * Local TSF is updated with remote TSF on beacon reception + * only if the remote TSF is greater than local TSF. + */ + tmp |= 2 << RT2860_TSF_SYNC_MODE_SHIFT; + } else if (vap->iv_opmode == IEEE80211_M_HOSTAP) { + tmp |= RT2860_BCN_TX_EN; + /* SYNC with nobody */ + tmp |= 3 << RT2860_TSF_SYNC_MODE_SHIFT; + } + + RAL_WRITE(sc, RT2860_BCN_TIME_CFG, tmp); +} Property changes on: sys/dev/ral/rt2860.c ___________________________________________________________________ Added: svn:mime-type ## -0,0 +1 ## +text/plain \ No newline at end of property Added: svn:keywords ## -0,0 +1 ## +FreeBSD=%H \ No newline at end of property Added: svn:eol-style ## -0,0 +1 ## +native \ No newline at end of property Index: sys/dev/ral/rt2860reg.h =================================================================== --- sys/dev/ral/rt2860reg.h (revision 0) +++ sys/dev/ral/rt2860reg.h (working copy) @@ -0,0 +1,1255 @@ +/* $OpenBSD: rt2860reg.h,v 1.30 2010/05/10 18:17:10 damien Exp $ */ + +/*- + * Copyright (c) 2007 + * 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. + */ + + +#define RT2860_NOISE_FLOOR -95 + +/* PCI registers */ +#define RT2860_PCI_CFG 0x0000 +#define RT2860_PCI_EECTRL 0x0004 +#define RT2860_PCI_MCUCTRL 0x0008 +#define RT2860_PCI_SYSCTRL 0x000c +#define RT2860_PCIE_JTAG 0x0010 + +#define RT3090_AUX_CTRL 0x010c + +#define RT3070_OPT_14 0x0114 + +/* SCH/DMA registers */ +#define RT2860_INT_STATUS 0x0200 +#define RT2860_INT_MASK 0x0204 +#define RT2860_WPDMA_GLO_CFG 0x0208 +#define RT2860_WPDMA_RST_IDX 0x020c +#define RT2860_DELAY_INT_CFG 0x0210 +#define RT2860_WMM_AIFSN_CFG 0x0214 +#define RT2860_WMM_CWMIN_CFG 0x0218 +#define RT2860_WMM_CWMAX_CFG 0x021c +#define RT2860_WMM_TXOP0_CFG 0x0220 +#define RT2860_WMM_TXOP1_CFG 0x0224 +#define RT2860_GPIO_CTRL 0x0228 +#define RT2860_MCU_CMD_REG 0x022c +#define RT2860_TX_BASE_PTR(qid) (0x0230 + (qid) * 16) +#define RT2860_TX_MAX_CNT(qid) (0x0234 + (qid) * 16) +#define RT2860_TX_CTX_IDX(qid) (0x0238 + (qid) * 16) +#define RT2860_TX_DTX_IDX(qid) (0x023c + (qid) * 16) +#define RT2860_RX_BASE_PTR 0x0290 +#define RT2860_RX_MAX_CNT 0x0294 +#define RT2860_RX_CALC_IDX 0x0298 +#define RT2860_FS_DRX_IDX 0x029c +#define RT2860_USB_DMA_CFG 0x02a0 /* RT2870 only */ +#define RT2860_US_CYC_CNT 0x02a4 + +/* PBF registers */ +#define RT2860_SYS_CTRL 0x0400 +#define RT2860_HOST_CMD 0x0404 +#define RT2860_PBF_CFG 0x0408 +#define RT2860_MAX_PCNT 0x040c +#define RT2860_BUF_CTRL 0x0410 +#define RT2860_MCU_INT_STA 0x0414 +#define RT2860_MCU_INT_ENA 0x0418 +#define RT2860_TXQ_IO(qid) (0x041c + (qid) * 4) +#define RT2860_RX0Q_IO 0x0424 +#define RT2860_BCN_OFFSET0 0x042c +#define RT2860_BCN_OFFSET1 0x0430 +#define RT2860_TXRXQ_STA 0x0434 +#define RT2860_TXRXQ_PCNT 0x0438 +#define RT2860_PBF_DBG 0x043c +#define RT2860_CAP_CTRL 0x0440 + +/* RT3070 registers */ +#define RT3070_RF_CSR_CFG 0x0500 +#define RT3070_EFUSE_CTRL 0x0580 +#define RT3070_EFUSE_DATA0 0x0590 +#define RT3070_EFUSE_DATA1 0x0594 +#define RT3070_EFUSE_DATA2 0x0598 +#define RT3070_EFUSE_DATA3 0x059c +#define RT3090_OSC_CTRL 0x05a4 +#define RT3070_LDO_CFG0 0x05d4 +#define RT3070_GPIO_SWITCH 0x05dc + +/* MAC registers */ +#define RT2860_ASIC_VER_ID 0x1000 +#define RT2860_MAC_SYS_CTRL 0x1004 +#define RT2860_MAC_ADDR_DW0 0x1008 +#define RT2860_MAC_ADDR_DW1 0x100c +#define RT2860_MAC_BSSID_DW0 0x1010 +#define RT2860_MAC_BSSID_DW1 0x1014 +#define RT2860_MAX_LEN_CFG 0x1018 +#define RT2860_BBP_CSR_CFG 0x101c +#define RT2860_RF_CSR_CFG0 0x1020 +#define RT2860_RF_CSR_CFG1 0x1024 +#define RT2860_RF_CSR_CFG2 0x1028 +#define RT2860_LED_CFG 0x102c + +/* undocumented registers */ +#define RT2860_DEBUG 0x10f4 + +/* MAC Timing control registers */ +#define RT2860_XIFS_TIME_CFG 0x1100 +#define RT2860_BKOFF_SLOT_CFG 0x1104 +#define RT2860_NAV_TIME_CFG 0x1108 +#define RT2860_CH_TIME_CFG 0x110c +#define RT2860_PBF_LIFE_TIMER 0x1110 +#define RT2860_BCN_TIME_CFG 0x1114 +#define RT2860_TBTT_SYNC_CFG 0x1118 +#define RT2860_TSF_TIMER_DW0 0x111c +#define RT2860_TSF_TIMER_DW1 0x1120 +#define RT2860_TBTT_TIMER 0x1124 +#define RT2860_INT_TIMER_CFG 0x1128 +#define RT2860_INT_TIMER_EN 0x112c +#define RT2860_CH_IDLE_TIME 0x1130 + +/* MAC Power Save configuration registers */ +#define RT2860_MAC_STATUS_REG 0x1200 +#define RT2860_PWR_PIN_CFG 0x1204 +#define RT2860_AUTO_WAKEUP_CFG 0x1208 + +/* MAC TX configuration registers */ +#define RT2860_EDCA_AC_CFG(aci) (0x1300 + (aci) * 4) +#define RT2860_EDCA_TID_AC_MAP 0x1310 +#define RT2860_TX_PWR_CFG(ridx) (0x1314 + (ridx) * 4) +#define RT2860_TX_PIN_CFG 0x1328 +#define RT2860_TX_BAND_CFG 0x132c +#define RT2860_TX_SW_CFG0 0x1330 +#define RT2860_TX_SW_CFG1 0x1334 +#define RT2860_TX_SW_CFG2 0x1338 +#define RT2860_TXOP_THRES_CFG 0x133c +#define RT2860_TXOP_CTRL_CFG 0x1340 +#define RT2860_TX_RTS_CFG 0x1344 +#define RT2860_TX_TIMEOUT_CFG 0x1348 +#define RT2860_TX_RTY_CFG 0x134c +#define RT2860_TX_LINK_CFG 0x1350 +#define RT2860_HT_FBK_CFG0 0x1354 +#define RT2860_HT_FBK_CFG1 0x1358 +#define RT2860_LG_FBK_CFG0 0x135c +#define RT2860_LG_FBK_CFG1 0x1360 +#define RT2860_CCK_PROT_CFG 0x1364 +#define RT2860_OFDM_PROT_CFG 0x1368 +#define RT2860_MM20_PROT_CFG 0x136c +#define RT2860_MM40_PROT_CFG 0x1370 +#define RT2860_GF20_PROT_CFG 0x1374 +#define RT2860_GF40_PROT_CFG 0x1378 +#define RT2860_EXP_CTS_TIME 0x137c +#define RT2860_EXP_ACK_TIME 0x1380 + +/* MAC RX configuration registers */ +#define RT2860_RX_FILTR_CFG 0x1400 +#define RT2860_AUTO_RSP_CFG 0x1404 +#define RT2860_LEGACY_BASIC_RATE 0x1408 +#define RT2860_HT_BASIC_RATE 0x140c +#define RT2860_HT_CTRL_CFG 0x1410 +#define RT2860_SIFS_COST_CFG 0x1414 +#define RT2860_RX_PARSER_CFG 0x1418 + +/* MAC Security configuration registers */ +#define RT2860_TX_SEC_CNT0 0x1500 +#define RT2860_RX_SEC_CNT0 0x1504 +#define RT2860_CCMP_FC_MUTE 0x1508 + +/* MAC HCCA/PSMP configuration registers */ +#define RT2860_TXOP_HLDR_ADDR0 0x1600 +#define RT2860_TXOP_HLDR_ADDR1 0x1604 +#define RT2860_TXOP_HLDR_ET 0x1608 +#define RT2860_QOS_CFPOLL_RA_DW0 0x160c +#define RT2860_QOS_CFPOLL_A1_DW1 0x1610 +#define RT2860_QOS_CFPOLL_QC 0x1614 + +/* MAC Statistics Counters */ +#define RT2860_RX_STA_CNT0 0x1700 +#define RT2860_RX_STA_CNT1 0x1704 +#define RT2860_RX_STA_CNT2 0x1708 +#define RT2860_TX_STA_CNT0 0x170c +#define RT2860_TX_STA_CNT1 0x1710 +#define RT2860_TX_STA_CNT2 0x1714 +#define RT2860_TX_STAT_FIFO 0x1718 + +/* RX WCID search table */ +#define RT2860_WCID_ENTRY(wcid) (0x1800 + (wcid) * 8) + +#define RT2860_FW_BASE 0x2000 +#define RT2870_FW_BASE 0x3000 + +/* Pair-wise key table */ +#define RT2860_PKEY(wcid) (0x4000 + (wcid) * 32) + +/* IV/EIV table */ +#define RT2860_IVEIV(wcid) (0x6000 + (wcid) * 8) + +/* WCID attribute table */ +#define RT2860_WCID_ATTR(wcid) (0x6800 + (wcid) * 4) + +/* Shared Key Table */ +#define RT2860_SKEY(vap, kidx) (0x6c00 + (vap) * 128 + (kidx) * 32) + +/* Shared Key Mode */ +#define RT2860_SKEY_MODE_0_7 0x7000 +#define RT2860_SKEY_MODE_8_15 0x7004 +#define RT2860_SKEY_MODE_16_23 0x7008 +#define RT2860_SKEY_MODE_24_31 0x700c + +/* Shared Memory between MCU and host */ +#define RT2860_H2M_MAILBOX 0x7010 +#define RT2860_H2M_MAILBOX_CID 0x7014 +#define RT2860_H2M_MAILBOX_STATUS 0x701c +#define RT2860_H2M_BBPAGENT 0x7028 +#define RT2860_BCN_BASE(vap) (0x7800 + (vap) * 512) + + +/* possible flags for RT2860_PCI_CFG */ +#define RT2860_PCI_CFG_USB (1 << 17) +#define RT2860_PCI_CFG_PCI (1 << 16) + +/* possible flags for register RT2860_PCI_EECTRL */ +#define RT2860_C (1 << 0) +#define RT2860_S (1 << 1) +#define RT2860_D (1 << 2) +#define RT2860_SHIFT_D 2 +#define RT2860_Q (1 << 3) +#define RT2860_SHIFT_Q 3 + +/* possible flags for registers INT_STATUS/INT_MASK */ +#define RT2860_TX_COHERENT (1 << 17) +#define RT2860_RX_COHERENT (1 << 16) +#define RT2860_MAC_INT_4 (1 << 15) +#define RT2860_MAC_INT_3 (1 << 14) +#define RT2860_MAC_INT_2 (1 << 13) +#define RT2860_MAC_INT_1 (1 << 12) +#define RT2860_MAC_INT_0 (1 << 11) +#define RT2860_TX_RX_COHERENT (1 << 10) +#define RT2860_MCU_CMD_INT (1 << 9) +#define RT2860_TX_DONE_INT5 (1 << 8) +#define RT2860_TX_DONE_INT4 (1 << 7) +#define RT2860_TX_DONE_INT3 (1 << 6) +#define RT2860_TX_DONE_INT2 (1 << 5) +#define RT2860_TX_DONE_INT1 (1 << 4) +#define RT2860_TX_DONE_INT0 (1 << 3) +#define RT2860_RX_DONE_INT (1 << 2) +#define RT2860_TX_DLY_INT (1 << 1) +#define RT2860_RX_DLY_INT (1 << 0) + +/* possible flags for register WPDMA_GLO_CFG */ +#define RT2860_HDR_SEG_LEN_SHIFT 8 +#define RT2860_BIG_ENDIAN (1 << 7) +#define RT2860_TX_WB_DDONE (1 << 6) +#define RT2860_WPDMA_BT_SIZE_SHIFT 4 +#define RT2860_WPDMA_BT_SIZE16 0 +#define RT2860_WPDMA_BT_SIZE32 1 +#define RT2860_WPDMA_BT_SIZE64 2 +#define RT2860_WPDMA_BT_SIZE128 3 +#define RT2860_RX_DMA_BUSY (1 << 3) +#define RT2860_RX_DMA_EN (1 << 2) +#define RT2860_TX_DMA_BUSY (1 << 1) +#define RT2860_TX_DMA_EN (1 << 0) + +/* possible flags for register DELAY_INT_CFG */ +#define RT2860_TXDLY_INT_EN (1 << 31) +#define RT2860_TXMAX_PINT_SHIFT 24 +#define RT2860_TXMAX_PTIME_SHIFT 16 +#define RT2860_RXDLY_INT_EN (1 << 15) +#define RT2860_RXMAX_PINT_SHIFT 8 +#define RT2860_RXMAX_PTIME_SHIFT 0 + +/* possible flags for register GPIO_CTRL */ +#define RT2860_GPIO_D_SHIFT 8 +#define RT2860_GPIO_O_SHIFT 0 + +/* possible flags for register USB_DMA_CFG */ +#define RT2860_USB_TX_BUSY (1 << 31) +#define RT2860_USB_RX_BUSY (1 << 30) +#define RT2860_USB_EPOUT_VLD_SHIFT 24 +#define RT2860_USB_TX_EN (1 << 23) +#define RT2860_USB_RX_EN (1 << 22) +#define RT2860_USB_RX_AGG_EN (1 << 21) +#define RT2860_USB_TXOP_HALT (1 << 20) +#define RT2860_USB_TX_CLEAR (1 << 19) +#define RT2860_USB_PHY_WD_EN (1 << 16) +#define RT2860_USB_PHY_MAN_RST (1 << 15) +#define RT2860_USB_RX_AGG_LMT(x) ((x) << 8) /* in unit of 1KB */ +#define RT2860_USB_RX_AGG_TO(x) ((x) & 0xff) /* in unit of 33ns */ + +/* possible flags for register US_CYC_CNT */ +#define RT2860_TEST_EN (1 << 24) +#define RT2860_TEST_SEL_SHIFT 16 +#define RT2860_BT_MODE_EN (1 << 8) +#define RT2860_US_CYC_CNT_SHIFT 0 + +/* possible flags for register SYS_CTRL */ +#define RT2860_HST_PM_SEL (1 << 16) +#define RT2860_CAP_MODE (1 << 14) +#define RT2860_PME_OEN (1 << 13) +#define RT2860_CLKSELECT (1 << 12) +#define RT2860_PBF_CLK_EN (1 << 11) +#define RT2860_MAC_CLK_EN (1 << 10) +#define RT2860_DMA_CLK_EN (1 << 9) +#define RT2860_MCU_READY (1 << 7) +#define RT2860_ASY_RESET (1 << 4) +#define RT2860_PBF_RESET (1 << 3) +#define RT2860_MAC_RESET (1 << 2) +#define RT2860_DMA_RESET (1 << 1) +#define RT2860_MCU_RESET (1 << 0) + +/* possible values for register HOST_CMD */ +#define RT2860_MCU_CMD_SLEEP 0x30 +#define RT2860_MCU_CMD_WAKEUP 0x31 +#define RT2860_MCU_CMD_LEDS 0x50 +#define RT2860_MCU_CMD_LED_RSSI 0x51 +#define RT2860_MCU_CMD_LED1 0x52 +#define RT2860_MCU_CMD_LED2 0x53 +#define RT2860_MCU_CMD_LED3 0x54 +#define RT2860_MCU_CMD_RFRESET 0x72 +#define RT2860_MCU_CMD_ANTSEL 0x73 +#define RT2860_MCU_CMD_BBP 0x80 +#define RT2860_MCU_CMD_PSLEVEL 0x83 + +/* possible flags for register PBF_CFG */ +#define RT2860_TX1Q_NUM_SHIFT 21 +#define RT2860_TX2Q_NUM_SHIFT 16 +#define RT2860_NULL0_MODE (1 << 15) +#define RT2860_NULL1_MODE (1 << 14) +#define RT2860_RX_DROP_MODE (1 << 13) +#define RT2860_TX0Q_MANUAL (1 << 12) +#define RT2860_TX1Q_MANUAL (1 << 11) +#define RT2860_TX2Q_MANUAL (1 << 10) +#define RT2860_RX0Q_MANUAL (1 << 9) +#define RT2860_HCCA_EN (1 << 8) +#define RT2860_TX0Q_EN (1 << 4) +#define RT2860_TX1Q_EN (1 << 3) +#define RT2860_TX2Q_EN (1 << 2) +#define RT2860_RX0Q_EN (1 << 1) + +/* possible flags for register BUF_CTRL */ +#define RT2860_WRITE_TXQ(qid) (1 << (11 - (qid))) +#define RT2860_NULL0_KICK (1 << 7) +#define RT2860_NULL1_KICK (1 << 6) +#define RT2860_BUF_RESET (1 << 5) +#define RT2860_READ_TXQ(qid) (1 << (3 - (qid)) +#define RT2860_READ_RX0Q (1 << 0) + +/* possible flags for registers MCU_INT_STA/MCU_INT_ENA */ +#define RT2860_MCU_MAC_INT_8 (1 << 24) +#define RT2860_MCU_MAC_INT_7 (1 << 23) +#define RT2860_MCU_MAC_INT_6 (1 << 22) +#define RT2860_MCU_MAC_INT_4 (1 << 20) +#define RT2860_MCU_MAC_INT_3 (1 << 19) +#define RT2860_MCU_MAC_INT_2 (1 << 18) +#define RT2860_MCU_MAC_INT_1 (1 << 17) +#define RT2860_MCU_MAC_INT_0 (1 << 16) +#define RT2860_DTX0_INT (1 << 11) +#define RT2860_DTX1_INT (1 << 10) +#define RT2860_DTX2_INT (1 << 9) +#define RT2860_DRX0_INT (1 << 8) +#define RT2860_HCMD_INT (1 << 7) +#define RT2860_N0TX_INT (1 << 6) +#define RT2860_N1TX_INT (1 << 5) +#define RT2860_BCNTX_INT (1 << 4) +#define RT2860_MTX0_INT (1 << 3) +#define RT2860_MTX1_INT (1 << 2) +#define RT2860_MTX2_INT (1 << 1) +#define RT2860_MRX0_INT (1 << 0) + +/* possible flags for register TXRXQ_PCNT */ +#define RT2860_RX0Q_PCNT_MASK 0xff000000 +#define RT2860_TX2Q_PCNT_MASK 0x00ff0000 +#define RT2860_TX1Q_PCNT_MASK 0x0000ff00 +#define RT2860_TX0Q_PCNT_MASK 0x000000ff + +/* possible flags for register CAP_CTRL */ +#define RT2860_CAP_ADC_FEQ (1 << 31) +#define RT2860_CAP_START (1 << 30) +#define RT2860_MAN_TRIG (1 << 29) +#define RT2860_TRIG_OFFSET_SHIFT 16 +#define RT2860_START_ADDR_SHIFT 0 + +/* possible flags for register RF_CSR_CFG */ +#define RT3070_RF_KICK (1 << 17) +#define RT3070_RF_WRITE (1 << 16) + +/* possible flags for register EFUSE_CTRL */ +#define RT3070_SEL_EFUSE (1 << 31) +#define RT3070_EFSROM_KICK (1 << 30) +#define RT3070_EFSROM_AIN_MASK 0x03ff0000 +#define RT3070_EFSROM_AIN_SHIFT 16 +#define RT3070_EFSROM_MODE_MASK 0x000000c0 +#define RT3070_EFUSE_AOUT_MASK 0x0000003f + +/* possible flags for register MAC_SYS_CTRL */ +#define RT2860_RX_TS_EN (1 << 7) +#define RT2860_WLAN_HALT_EN (1 << 6) +#define RT2860_PBF_LOOP_EN (1 << 5) +#define RT2860_CONT_TX_TEST (1 << 4) +#define RT2860_MAC_RX_EN (1 << 3) +#define RT2860_MAC_TX_EN (1 << 2) +#define RT2860_BBP_HRST (1 << 1) +#define RT2860_MAC_SRST (1 << 0) + +/* possible flags for register MAC_BSSID_DW1 */ +#define RT2860_MULTI_BCN_NUM_SHIFT 18 +#define RT2860_MULTI_BSSID_MODE_SHIFT 16 + +/* possible flags for register MAX_LEN_CFG */ +#define RT2860_MIN_MPDU_LEN_SHIFT 16 +#define RT2860_MAX_PSDU_LEN_SHIFT 12 +#define RT2860_MAX_PSDU_LEN8K 0 +#define RT2860_MAX_PSDU_LEN16K 1 +#define RT2860_MAX_PSDU_LEN32K 2 +#define RT2860_MAX_PSDU_LEN64K 3 +#define RT2860_MAX_MPDU_LEN_SHIFT 0 + +/* possible flags for registers BBP_CSR_CFG/H2M_BBPAGENT */ +#define RT2860_BBP_RW_PARALLEL (1 << 19) +#define RT2860_BBP_PAR_DUR_112_5 (1 << 18) +#define RT2860_BBP_CSR_KICK (1 << 17) +#define RT2860_BBP_CSR_READ (1 << 16) +#define RT2860_BBP_ADDR_SHIFT 8 +#define RT2860_BBP_DATA_SHIFT 0 + +/* possible flags for register RF_CSR_CFG0 */ +#define RT2860_RF_REG_CTRL (1 << 31) +#define RT2860_RF_LE_SEL1 (1 << 30) +#define RT2860_RF_LE_STBY (1 << 29) +#define RT2860_RF_REG_WIDTH_SHIFT 24 +#define RT2860_RF_REG_0_SHIFT 0 + +/* possible flags for register RF_CSR_CFG1 */ +#define RT2860_RF_DUR_5 (1 << 24) +#define RT2860_RF_REG_1_SHIFT 0 + +/* possible flags for register LED_CFG */ +#define RT2860_LED_POL (1 << 30) +#define RT2860_Y_LED_MODE_SHIFT 28 +#define RT2860_G_LED_MODE_SHIFT 26 +#define RT2860_R_LED_MODE_SHIFT 24 +#define RT2860_LED_MODE_OFF 0 +#define RT2860_LED_MODE_BLINK_TX 1 +#define RT2860_LED_MODE_SLOW_BLINK 2 +#define RT2860_LED_MODE_ON 3 +#define RT2860_SLOW_BLK_TIME_SHIFT 16 +#define RT2860_LED_OFF_TIME_SHIFT 8 +#define RT2860_LED_ON_TIME_SHIFT 0 + +/* possible flags for register XIFS_TIME_CFG */ +#define RT2860_BB_RXEND_EN (1 << 29) +#define RT2860_EIFS_TIME_SHIFT 20 +#define RT2860_OFDM_XIFS_TIME_SHIFT 16 +#define RT2860_OFDM_SIFS_TIME_SHIFT 8 +#define RT2860_CCK_SIFS_TIME_SHIFT 0 + +/* possible flags for register BKOFF_SLOT_CFG */ +#define RT2860_CC_DELAY_TIME_SHIFT 8 +#define RT2860_SLOT_TIME 0 + +/* possible flags for register NAV_TIME_CFG */ +#define RT2860_NAV_UPD (1 << 31) +#define RT2860_NAV_UPD_VAL_SHIFT 16 +#define RT2860_NAV_CLR_EN (1 << 15) +#define RT2860_NAV_TIMER_SHIFT 0 + +/* possible flags for register CH_TIME_CFG */ +#define RT2860_EIFS_AS_CH_BUSY (1 << 4) +#define RT2860_NAV_AS_CH_BUSY (1 << 3) +#define RT2860_RX_AS_CH_BUSY (1 << 2) +#define RT2860_TX_AS_CH_BUSY (1 << 1) +#define RT2860_CH_STA_TIMER_EN (1 << 0) + +/* possible values for register BCN_TIME_CFG */ +#define RT2860_TSF_INS_COMP_SHIFT 24 +#define RT2860_BCN_TX_EN (1 << 20) +#define RT2860_TBTT_TIMER_EN (1 << 19) +#define RT2860_TSF_SYNC_MODE_SHIFT 17 +#define RT2860_TSF_SYNC_MODE_DIS 0 +#define RT2860_TSF_SYNC_MODE_STA 1 +#define RT2860_TSF_SYNC_MODE_IBSS 2 +#define RT2860_TSF_SYNC_MODE_HOSTAP 3 +#define RT2860_TSF_TIMER_EN (1 << 16) +#define RT2860_BCN_INTVAL_SHIFT 0 + +/* possible flags for register TBTT_SYNC_CFG */ +#define RT2860_BCN_CWMIN_SHIFT 20 +#define RT2860_BCN_AIFSN_SHIFT 16 +#define RT2860_BCN_EXP_WIN_SHIFT 8 +#define RT2860_TBTT_ADJUST_SHIFT 0 + +/* possible flags for register INT_TIMER_CFG */ +#define RT2860_GP_TIMER_SHIFT 16 +#define RT2860_PRE_TBTT_TIMER_SHIFT 0 + +/* possible flags for register INT_TIMER_EN */ +#define RT2860_GP_TIMER_EN (1 << 1) +#define RT2860_PRE_TBTT_INT_EN (1 << 0) + +/* possible flags for register MAC_STATUS_REG */ +#define RT2860_RX_STATUS_BUSY (1 << 1) +#define RT2860_TX_STATUS_BUSY (1 << 0) + +/* possible flags for register PWR_PIN_CFG */ +#define RT2860_IO_ADDA_PD (1 << 3) +#define RT2860_IO_PLL_PD (1 << 2) +#define RT2860_IO_RA_PE (1 << 1) +#define RT2860_IO_RF_PE (1 << 0) + +/* possible flags for register AUTO_WAKEUP_CFG */ +#define RT2860_AUTO_WAKEUP_EN (1 << 15) +#define RT2860_SLEEP_TBTT_NUM_SHIFT 8 +#define RT2860_WAKEUP_LEAD_TIME_SHIFT 0 + +/* possible flags for register TX_PIN_CFG */ +#define RT3593_LNA_PE_G2_POL (1 << 31) +#define RT3593_LNA_PE_A2_POL (1 << 30) +#define RT3593_LNA_PE_G2_EN (1 << 29) +#define RT3593_LNA_PE_A2_EN (1 << 28) +#define RT3593_LNA_PE2_EN (RT3593_LNA_PE_A2_EN | RT3593_LNA_PE_G2_EN) +#define RT3593_PA_PE_G2_POL (1 << 27) +#define RT3593_PA_PE_A2_POL (1 << 26) +#define RT3593_PA_PE_G2_EN (1 << 25) +#define RT3593_PA_PE_A2_EN (1 << 24) +#define RT2860_TRSW_POL (1 << 19) +#define RT2860_TRSW_EN (1 << 18) +#define RT2860_RFTR_POL (1 << 17) +#define RT2860_RFTR_EN (1 << 16) +#define RT2860_LNA_PE_G1_POL (1 << 15) +#define RT2860_LNA_PE_A1_POL (1 << 14) +#define RT2860_LNA_PE_G0_POL (1 << 13) +#define RT2860_LNA_PE_A0_POL (1 << 12) +#define RT2860_LNA_PE_G1_EN (1 << 11) +#define RT2860_LNA_PE_A1_EN (1 << 10) +#define RT2860_LNA_PE1_EN (RT2860_LNA_PE_A1_EN | RT2860_LNA_PE_G1_EN) +#define RT2860_LNA_PE_G0_EN (1 << 9) +#define RT2860_LNA_PE_A0_EN (1 << 8) +#define RT2860_LNA_PE0_EN (RT2860_LNA_PE_A0_EN | RT2860_LNA_PE_G0_EN) +#define RT2860_PA_PE_G1_POL (1 << 7) +#define RT2860_PA_PE_A1_POL (1 << 6) +#define RT2860_PA_PE_G0_POL (1 << 5) +#define RT2860_PA_PE_A0_POL (1 << 4) +#define RT2860_PA_PE_G1_EN (1 << 3) +#define RT2860_PA_PE_A1_EN (1 << 2) +#define RT2860_PA_PE_G0_EN (1 << 1) +#define RT2860_PA_PE_A0_EN (1 << 0) + +/* possible flags for register TX_BAND_CFG */ +#define RT2860_5G_BAND_SEL_N (1 << 2) +#define RT2860_5G_BAND_SEL_P (1 << 1) +#define RT2860_TX_BAND_SEL (1 << 0) + +/* possible flags for register TX_SW_CFG0 */ +#define RT2860_DLY_RFTR_EN_SHIFT 24 +#define RT2860_DLY_TRSW_EN_SHIFT 16 +#define RT2860_DLY_PAPE_EN_SHIFT 8 +#define RT2860_DLY_TXPE_EN_SHIFT 0 + +/* possible flags for register TX_SW_CFG1 */ +#define RT2860_DLY_RFTR_DIS_SHIFT 16 +#define RT2860_DLY_TRSW_DIS_SHIFT 8 +#define RT2860_DLY_PAPE_DIS SHIFT 0 + +/* possible flags for register TX_SW_CFG2 */ +#define RT2860_DLY_LNA_EN_SHIFT 24 +#define RT2860_DLY_LNA_DIS_SHIFT 16 +#define RT2860_DLY_DAC_EN_SHIFT 8 +#define RT2860_DLY_DAC_DIS_SHIFT 0 + +/* possible flags for register TXOP_THRES_CFG */ +#define RT2860_TXOP_REM_THRES_SHIFT 24 +#define RT2860_CF_END_THRES_SHIFT 16 +#define RT2860_RDG_IN_THRES 8 +#define RT2860_RDG_OUT_THRES 0 + +/* possible flags for register TXOP_CTRL_CFG */ +#define RT2860_EXT_CW_MIN_SHIFT 16 +#define RT2860_EXT_CCA_DLY_SHIFT 8 +#define RT2860_EXT_CCA_EN (1 << 7) +#define RT2860_LSIG_TXOP_EN (1 << 6) +#define RT2860_TXOP_TRUN_EN_MIMOPS (1 << 4) +#define RT2860_TXOP_TRUN_EN_TXOP (1 << 3) +#define RT2860_TXOP_TRUN_EN_RATE (1 << 2) +#define RT2860_TXOP_TRUN_EN_AC (1 << 1) +#define RT2860_TXOP_TRUN_EN_TIMEOUT (1 << 0) + +/* possible flags for register TX_RTS_CFG */ +#define RT2860_RTS_FBK_EN (1 << 24) +#define RT2860_RTS_THRES_SHIFT 8 +#define RT2860_RTS_RTY_LIMIT_SHIFT 0 + +/* possible flags for register TX_TIMEOUT_CFG */ +#define RT2860_TXOP_TIMEOUT_SHIFT 16 +#define RT2860_RX_ACK_TIMEOUT_SHIFT 8 +#define RT2860_MPDU_LIFE_TIME_SHIFT 4 + +/* possible flags for register TX_RTY_CFG */ +#define RT2860_TX_AUTOFB_EN (1 << 30) +#define RT2860_AGG_RTY_MODE_TIMER (1 << 29) +#define RT2860_NAG_RTY_MODE_TIMER (1 << 28) +#define RT2860_LONG_RTY_THRES_SHIFT 16 +#define RT2860_LONG_RTY_LIMIT_SHIFT 8 +#define RT2860_SHORT_RTY_LIMIT_SHIFT 0 + +/* possible flags for register TX_LINK_CFG */ +#define RT2860_REMOTE_MFS_SHIFT 24 +#define RT2860_REMOTE_MFB_SHIFT 16 +#define RT2860_TX_CFACK_EN (1 << 12) +#define RT2860_TX_RDG_EN (1 << 11) +#define RT2860_TX_MRQ_EN (1 << 10) +#define RT2860_REMOTE_UMFS_EN (1 << 9) +#define RT2860_TX_MFB_EN (1 << 8) +#define RT2860_REMOTE_MFB_LT_SHIFT 0 + +/* possible flags for registers *_PROT_CFG */ +#define RT2860_RTSTH_EN (1 << 26) +#define RT2860_TXOP_ALLOW_GF40 (1 << 25) +#define RT2860_TXOP_ALLOW_GF20 (1 << 24) +#define RT2860_TXOP_ALLOW_MM40 (1 << 23) +#define RT2860_TXOP_ALLOW_MM20 (1 << 22) +#define RT2860_TXOP_ALLOW_OFDM (1 << 21) +#define RT2860_TXOP_ALLOW_CCK (1 << 20) +#define RT2860_TXOP_ALLOW_ALL (0x3f << 20) +#define RT2860_PROT_NAV_SHORT (1 << 18) +#define RT2860_PROT_NAV_LONG (2 << 18) +#define RT2860_PROT_CTRL_RTS_CTS (1 << 16) +#define RT2860_PROT_CTRL_CTS (2 << 16) + +/* possible flags for registers EXP_{CTS,ACK}_TIME */ +#define RT2860_EXP_OFDM_TIME_SHIFT 16 +#define RT2860_EXP_CCK_TIME_SHIFT 0 + +/* possible flags for register RX_FILTR_CFG */ +#define RT2860_DROP_CTRL_RSV (1 << 16) +#define RT2860_DROP_BAR (1 << 15) +#define RT2860_DROP_BA (1 << 14) +#define RT2860_DROP_PSPOLL (1 << 13) +#define RT2860_DROP_RTS (1 << 12) +#define RT2860_DROP_CTS (1 << 11) +#define RT2860_DROP_ACK (1 << 10) +#define RT2860_DROP_CFEND (1 << 9) +#define RT2860_DROP_CFACK (1 << 8) +#define RT2860_DROP_DUPL (1 << 7) +#define RT2860_DROP_BC (1 << 6) +#define RT2860_DROP_MC (1 << 5) +#define RT2860_DROP_VER_ERR (1 << 4) +#define RT2860_DROP_NOT_MYBSS (1 << 3) +#define RT2860_DROP_UC_NOME (1 << 2) +#define RT2860_DROP_PHY_ERR (1 << 1) +#define RT2860_DROP_CRC_ERR (1 << 0) + +/* possible flags for register AUTO_RSP_CFG */ +#define RT2860_CTRL_PWR_BIT (1 << 7) +#define RT2860_BAC_ACK_POLICY (1 << 6) +#define RT2860_CCK_SHORT_EN (1 << 4) +#define RT2860_CTS_40M_REF_EN (1 << 3) +#define RT2860_CTS_40M_MODE_EN (1 << 2) +#define RT2860_BAC_ACKPOLICY_EN (1 << 1) +#define RT2860_AUTO_RSP_EN (1 << 0) + +/* possible flags for register SIFS_COST_CFG */ +#define RT2860_OFDM_SIFS_COST_SHIFT 8 +#define RT2860_CCK_SIFS_COST_SHIFT 0 + +/* possible flags for register TXOP_HLDR_ET */ +#define RT2860_TXOP_ETM1_EN (1 << 25) +#define RT2860_TXOP_ETM0_EN (1 << 24) +#define RT2860_TXOP_ETM_THRES_SHIFT 16 +#define RT2860_TXOP_ETO_EN (1 << 8) +#define RT2860_TXOP_ETO_THRES_SHIFT 1 +#define RT2860_PER_RX_RST_EN (1 << 0) + +/* possible flags for register TX_STAT_FIFO */ +#define RT2860_TXQ_MCS_SHIFT 16 +#define RT2860_TXQ_WCID_SHIFT 8 +#define RT2860_TXQ_ACKREQ (1 << 7) +#define RT2860_TXQ_AGG (1 << 6) +#define RT2860_TXQ_OK (1 << 5) +#define RT2860_TXQ_PID_SHIFT 1 +#define RT2860_TXQ_VLD (1 << 0) + +/* possible flags for register WCID_ATTR */ +#define RT2860_MODE_NOSEC 0 +#define RT2860_MODE_WEP40 1 +#define RT2860_MODE_WEP104 2 +#define RT2860_MODE_TKIP 3 +#define RT2860_MODE_AES_CCMP 4 +#define RT2860_MODE_CKIP40 5 +#define RT2860_MODE_CKIP104 6 +#define RT2860_MODE_CKIP128 7 +#define RT2860_RX_PKEY_EN (1 << 0) + +/* possible flags for register H2M_MAILBOX */ +#define RT2860_H2M_BUSY (1 << 24) +#define RT2860_TOKEN_NO_INTR 0xff + + +/* possible flags for MCU command RT2860_MCU_CMD_LEDS */ +#define RT2860_LED_RADIO (1 << 13) +#define RT2860_LED_LINK_2GHZ (1 << 14) +#define RT2860_LED_LINK_5GHZ (1 << 15) + + +/* possible flags for RT3020 RF register 1 */ +#define RT3070_RF_BLOCK (1 << 0) +#define RT3070_RX0_PD (1 << 2) +#define RT3070_TX0_PD (1 << 3) +#define RT3070_RX1_PD (1 << 4) +#define RT3070_TX1_PD (1 << 5) +#define RT3070_RX2_PD (1 << 6) +#define RT3070_TX2_PD (1 << 7) + +/* possible flags for RT3020 RF register 7 */ +#define RT3070_TUNE (1 << 0) + +/* possible flags for RT3020 RF register 15 */ +#define RT3070_TX_LO2 (1 << 3) + +/* possible flags for RT3020 RF register 17 */ +#define RT3070_TX_LO1 (1 << 3) + +/* possible flags for RT3020 RF register 20 */ +#define RT3070_RX_LO1 (1 << 3) + +/* possible flags for RT3020 RF register 21 */ +#define RT3070_RX_LO2 (1 << 3) +#define RT3070_RX_CTB (1 << 7) + +/* possible flags for RT3020 RF register 22 */ +#define RT3070_BB_LOOPBACK (1 << 0) + +/* possible flags for RT3053 RF register 1 */ +#define RT3593_VCO (1 << 0) + +/* possible flags for RT3053 RF register 2 */ +#define RT3593_RESCAL (1 << 7) + +/* possible flags for RT3053 RF register 3 */ +#define RT3593_VCOCAL (1 << 7) + +/* possible flags for RT3053 RF register 6 */ +#define RT3593_VCO_IC (1 << 6) + +/* possible flags for RT3053 RF register 20 */ +#define RT3593_LDO_PLL_VC_MASK 0x0e +#define RT3593_LDO_RF_VC_MASK 0xe0 + +/* possible flags for RT3053 RF register 22 */ +#define RT3593_CP_IC_MASK 0xe0 +#define RT3593_CP_IC_SHIFT 5 + +/* possible flags for RT3053 RF register 46 */ +#define RT3593_RX_CTB (1 << 5) + +#define RT3090_DEF_LNA 10 + +/* RT2860 TX descriptor */ +struct rt2860_txd { + uint32_t sdp0; /* Segment Data Pointer 0 */ + uint16_t sdl1; /* Segment Data Length 1 */ +#define RT2860_TX_BURST (1 << 15) +#define RT2860_TX_LS1 (1 << 14) /* SDP1 is the last segment */ + + uint16_t sdl0; /* Segment Data Length 0 */ +#define RT2860_TX_DDONE (1 << 15) +#define RT2860_TX_LS0 (1 << 14) /* SDP0 is the last segment */ + + uint32_t sdp1; /* Segment Data Pointer 1 */ + uint8_t reserved[3]; + uint8_t flags; +#define RT2860_TX_QSEL_SHIFT 1 +#define RT2860_TX_QSEL_MGMT (0 << 1) +#define RT2860_TX_QSEL_HCCA (1 << 1) +#define RT2860_TX_QSEL_EDCA (2 << 1) +#define RT2860_TX_WIV (1 << 0) +} __packed; + +/* RT2870 TX descriptor */ +struct rt2870_txd { + uint16_t len; + uint8_t pad; + uint8_t flags; +} __packed; + +/* TX Wireless Information */ +struct rt2860_txwi { + uint8_t flags; +#define RT2860_TX_MPDU_DSITY_SHIFT 5 +#define RT2860_TX_AMPDU (1 << 4) +#define RT2860_TX_TS (1 << 3) +#define RT2860_TX_CFACK (1 << 2) +#define RT2860_TX_MMPS (1 << 1) +#define RT2860_TX_FRAG (1 << 0) + + uint8_t txop; +#define RT2860_TX_TXOP_HT 0 +#define RT2860_TX_TXOP_PIFS 1 +#define RT2860_TX_TXOP_SIFS 2 +#define RT2860_TX_TXOP_BACKOFF 3 + + uint16_t phy; +#define RT2860_PHY_MODE 0xc000 +#define RT2860_PHY_CCK (0 << 14) +#define RT2860_PHY_OFDM (1 << 14) +#define RT2860_PHY_HT (2 << 14) +#define RT2860_PHY_HT_GF (3 << 14) +#define RT2860_PHY_SGI (1 << 8) +#define RT2860_PHY_BW40 (1 << 7) +#define RT2860_PHY_MCS 0x7f +#define RT2860_PHY_SHPRE (1 << 3) + + uint8_t xflags; +#define RT2860_TX_BAWINSIZE_SHIFT 2 +#define RT2860_TX_NSEQ (1 << 1) +#define RT2860_TX_ACK (1 << 0) + + uint8_t wcid; /* Wireless Client ID */ + uint16_t len; +#define RT2860_TX_PID_SHIFT 12 + + uint32_t iv; + uint32_t eiv; +} __packed; + +/* RT2860 RX descriptor */ +struct rt2860_rxd { + uint32_t sdp0; + uint16_t sdl1; /* unused */ + uint16_t sdl0; +#define RT2860_RX_DDONE (1 << 15) +#define RT2860_RX_LS0 (1 << 14) + + uint32_t sdp1; /* unused */ + uint32_t flags; +#define RT2860_RX_DEC (1 << 16) +#define RT2860_RX_AMPDU (1 << 15) +#define RT2860_RX_L2PAD (1 << 14) +#define RT2860_RX_RSSI (1 << 13) +#define RT2860_RX_HTC (1 << 12) +#define RT2860_RX_AMSDU (1 << 11) +#define RT2860_RX_MICERR (1 << 10) +#define RT2860_RX_ICVERR (1 << 9) +#define RT2860_RX_CRCERR (1 << 8) +#define RT2860_RX_MYBSS (1 << 7) +#define RT2860_RX_BC (1 << 6) +#define RT2860_RX_MC (1 << 5) +#define RT2860_RX_UC2ME (1 << 4) +#define RT2860_RX_FRAG (1 << 3) +#define RT2860_RX_NULL (1 << 2) +#define RT2860_RX_DATA (1 << 1) +#define RT2860_RX_BA (1 << 0) +} __packed; + +/* RT2870 RX descriptor */ +struct rt2870_rxd { + /* single 32-bit field */ + uint32_t flags; +} __packed; + +/* RX Wireless Information */ +struct rt2860_rxwi { + uint8_t wcid; + uint8_t keyidx; +#define RT2860_RX_UDF_SHIFT 5 +#define RT2860_RX_BSS_IDX_SHIFT 2 + + uint16_t len; +#define RT2860_RX_TID_SHIFT 12 + + uint16_t seq; + uint16_t phy; + uint8_t rssi[3]; + uint8_t reserved1; + uint8_t snr[2]; + uint16_t reserved2; +} __packed; + + +/* first DMA segment contains TXWI + 802.11 header + 32-bit padding */ +#define RT2860_TXWI_DMASZ \ + (sizeof (struct rt2860_txwi) + \ + sizeof (struct ieee80211_frame) + 6 + \ + sizeof (uint16_t)) + +#define RT2860_RF1 0 +#define RT2860_RF2 2 +#define RT2860_RF3 1 +#define RT2860_RF4 3 + +#define RT2860_RF_2820 1 /* 2T3R */ +#define RT2860_RF_2850 2 /* dual-band 2T3R */ +#define RT2860_RF_2720 3 /* 1T2R */ +#define RT2860_RF_2750 4 /* dual-band 1T2R */ +#define RT3070_RF_3020 5 /* 1T1R */ +#define RT3070_RF_2020 6 /* b/g */ +#define RT3070_RF_3021 7 /* 1T2R */ +#define RT3070_RF_3022 8 /* 2T2R */ +#define RT3070_RF_3052 9 /* dual-band 2T2R */ +#define RT3070_RF_3320 11 /* 1T1R */ +#define RT3070_RF_3053 13 /* dual-band 3T3R */ + +/* USB commands for RT2870 only */ +#define RT2870_RESET 1 +#define RT2870_WRITE_2 2 +#define RT2870_WRITE_REGION_1 6 +#define RT2870_READ_REGION_1 7 +#define RT2870_EEPROM_READ 9 + +#define RT2860_EEPROM_DELAY 1 /* minimum hold time (microsecond) */ + +#define RT2860_EEPROM_VERSION 0x01 +#define RT2860_EEPROM_MAC01 0x02 +#define RT2860_EEPROM_MAC23 0x03 +#define RT2860_EEPROM_MAC45 0x04 +#define RT2860_EEPROM_PCIE_PSLEVEL 0x11 +#define RT2860_EEPROM_REV 0x12 +#define RT2860_EEPROM_ANTENNA 0x1a +#define RT2860_EEPROM_CONFIG 0x1b +#define RT2860_EEPROM_COUNTRY 0x1c +#define RT2860_EEPROM_FREQ_LEDS 0x1d +#define RT2860_EEPROM_LED1 0x1e +#define RT2860_EEPROM_LED2 0x1f +#define RT2860_EEPROM_LED3 0x20 +#define RT2860_EEPROM_LNA 0x22 +#define RT2860_EEPROM_RSSI1_2GHZ 0x23 +#define RT2860_EEPROM_RSSI2_2GHZ 0x24 +#define RT2860_EEPROM_RSSI1_5GHZ 0x25 +#define RT2860_EEPROM_RSSI2_5GHZ 0x26 +#define RT2860_EEPROM_DELTAPWR 0x28 +#define RT2860_EEPROM_PWR2GHZ_BASE1 0x29 +#define RT2860_EEPROM_PWR2GHZ_BASE2 0x30 +#define RT2860_EEPROM_TSSI1_2GHZ 0x37 +#define RT2860_EEPROM_TSSI2_2GHZ 0x38 +#define RT2860_EEPROM_TSSI3_2GHZ 0x39 +#define RT2860_EEPROM_TSSI4_2GHZ 0x3a +#define RT2860_EEPROM_TSSI5_2GHZ 0x3b +#define RT2860_EEPROM_PWR5GHZ_BASE1 0x3c +#define RT2860_EEPROM_PWR5GHZ_BASE2 0x53 +#define RT2860_EEPROM_TSSI1_5GHZ 0x6a +#define RT2860_EEPROM_TSSI2_5GHZ 0x6b +#define RT2860_EEPROM_TSSI3_5GHZ 0x6c +#define RT2860_EEPROM_TSSI4_5GHZ 0x6d +#define RT2860_EEPROM_TSSI5_5GHZ 0x6e +#define RT2860_EEPROM_RPWR 0x6f +#define RT2860_EEPROM_BBP_BASE 0x78 +#define RT3071_EEPROM_RF_BASE 0x82 + +#define RT2860_RIDX_CCK1 0 +#define RT2860_RIDX_CCK11 3 +#define RT2860_RIDX_OFDM6 4 +#define RT2860_RIDX_MAX 11 +static const struct rt2860_rate { + uint8_t rate; + uint8_t mcs; + enum ieee80211_phytype phy; + uint8_t ctl_ridx; + uint16_t sp_ack_dur; + uint16_t lp_ack_dur; +} rt2860_rates[] = { + { 2, 0, IEEE80211_T_DS, 0, 314, 314 }, + { 4, 1, IEEE80211_T_DS, 1, 258, 162 }, + { 11, 2, IEEE80211_T_DS, 2, 223, 127 }, + { 22, 3, IEEE80211_T_DS, 3, 213, 117 }, + { 12, 0, IEEE80211_T_OFDM, 4, 60, 60 }, + { 18, 1, IEEE80211_T_OFDM, 4, 52, 52 }, + { 24, 2, IEEE80211_T_OFDM, 6, 48, 48 }, + { 36, 3, IEEE80211_T_OFDM, 6, 44, 44 }, + { 48, 4, IEEE80211_T_OFDM, 8, 44, 44 }, + { 72, 5, IEEE80211_T_OFDM, 8, 40, 40 }, + { 96, 6, IEEE80211_T_OFDM, 8, 40, 40 }, + { 108, 7, IEEE80211_T_OFDM, 8, 40, 40 } +}; + +/* + * Control and status registers access macros. + */ +#define RAL_READ(sc, reg) \ + bus_space_read_4((sc)->sc_st, (sc)->sc_sh, (reg)) + +#define RAL_WRITE(sc, reg, val) \ + bus_space_write_4((sc)->sc_st, (sc)->sc_sh, (reg), (val)) + +#define RAL_BARRIER_WRITE(sc) \ + bus_space_barrier((sc)->sc_st, (sc)->sc_sh, 0, 0x1800, \ + BUS_SPACE_BARRIER_WRITE) + +#define RAL_BARRIER_READ_WRITE(sc) \ + bus_space_barrier((sc)->sc_st, (sc)->sc_sh, 0, 0x1800, \ + BUS_SPACE_BARRIER_READ | BUS_SPACE_BARRIER_WRITE) + +#define RAL_WRITE_REGION_1(sc, offset, datap, count) \ + bus_space_write_region_1((sc)->sc_st, (sc)->sc_sh, (offset), \ + (datap), (count)) + +#define RAL_SET_REGION_4(sc, offset, val, count) \ + bus_space_set_region_4((sc)->sc_st, (sc)->sc_sh, (offset), \ + (val), (count)) + +/* + * EEPROM access macro. + */ +#define RT2860_EEPROM_CTL(sc, val) do { \ + RAL_WRITE((sc), RT2860_PCI_EECTRL, (val)); \ + RAL_BARRIER_READ_WRITE((sc)); \ + DELAY(RT2860_EEPROM_DELAY); \ +} while (/* CONSTCOND */0) + +/* + * Default values for MAC registers; values taken from the reference driver. + */ +#define RT2860_DEF_MAC \ + { RT2860_BCN_OFFSET0, 0xf8f0e8e0 }, \ + { RT2860_LEGACY_BASIC_RATE, 0x0000013f }, \ + { RT2860_HT_BASIC_RATE, 0x00008003 }, \ + { RT2860_MAC_SYS_CTRL, 0x00000000 }, \ + { RT2860_BKOFF_SLOT_CFG, 0x00000209 }, \ + { RT2860_TX_SW_CFG0, 0x00000000 }, \ + { RT2860_TX_SW_CFG1, 0x00080606 }, \ + { RT2860_TX_LINK_CFG, 0x00001020 }, \ + { RT2860_TX_TIMEOUT_CFG, 0x000a2090 }, \ + { RT2860_LED_CFG, 0x7f031e46 }, \ + { RT2860_WMM_AIFSN_CFG, 0x00002273 }, \ + { RT2860_WMM_CWMIN_CFG, 0x00002344 }, \ + { RT2860_WMM_CWMAX_CFG, 0x000034aa }, \ + { RT2860_MAX_PCNT, 0x1f3fbf9f }, \ + { RT2860_TX_RTY_CFG, 0x47d01f0f }, \ + { RT2860_AUTO_RSP_CFG, 0x00000013 }, \ + { RT2860_CCK_PROT_CFG, 0x05740003 }, \ + { RT2860_OFDM_PROT_CFG, 0x05740003 }, \ + { RT2860_GF20_PROT_CFG, 0x01744004 }, \ + { RT2860_GF40_PROT_CFG, 0x03f44084 }, \ + { RT2860_MM20_PROT_CFG, 0x01744004 }, \ + { RT2860_MM40_PROT_CFG, 0x03f54084 }, \ + { RT2860_TXOP_CTRL_CFG, 0x0000583f }, \ + { RT2860_TXOP_HLDR_ET, 0x00000002 }, \ + { RT2860_TX_RTS_CFG, 0x00092b20 }, \ + { RT2860_EXP_ACK_TIME, 0x002400ca }, \ + { RT2860_XIFS_TIME_CFG, 0x33a41010 }, \ + { RT2860_PWR_PIN_CFG, 0x00000003 } + +/* XXX only a few registers differ from above, try to merge? */ +#define RT2870_DEF_MAC \ + { RT2860_BCN_OFFSET0, 0xf8f0e8e0 }, \ + { RT2860_LEGACY_BASIC_RATE, 0x0000013f }, \ + { RT2860_HT_BASIC_RATE, 0x00008003 }, \ + { RT2860_MAC_SYS_CTRL, 0x00000000 }, \ + { RT2860_BKOFF_SLOT_CFG, 0x00000209 }, \ + { RT2860_TX_SW_CFG0, 0x00000000 }, \ + { RT2860_TX_SW_CFG1, 0x00080606 }, \ + { RT2860_TX_LINK_CFG, 0x00001020 }, \ + { RT2860_TX_TIMEOUT_CFG, 0x000a2090 }, \ + { RT2860_LED_CFG, 0x7f031e46 }, \ + { RT2860_WMM_AIFSN_CFG, 0x00002273 }, \ + { RT2860_WMM_CWMIN_CFG, 0x00002344 }, \ + { RT2860_WMM_CWMAX_CFG, 0x000034aa }, \ + { RT2860_MAX_PCNT, 0x1f3fbf9f }, \ + { RT2860_TX_RTY_CFG, 0x47d01f0f }, \ + { RT2860_AUTO_RSP_CFG, 0x00000013 }, \ + { RT2860_CCK_PROT_CFG, 0x05740003 }, \ + { RT2860_OFDM_PROT_CFG, 0x05740003 }, \ + { RT2860_PBF_CFG, 0x00f40006 }, \ + { RT2860_WPDMA_GLO_CFG, 0x00000030 }, \ + { RT2860_GF20_PROT_CFG, 0x01744004 }, \ + { RT2860_GF40_PROT_CFG, 0x03f44084 }, \ + { RT2860_MM20_PROT_CFG, 0x01744004 }, \ + { RT2860_MM40_PROT_CFG, 0x03f44084 }, \ + { RT2860_TXOP_CTRL_CFG, 0x0000583f }, \ + { RT2860_TXOP_HLDR_ET, 0x00000002 }, \ + { RT2860_TX_RTS_CFG, 0x00092b20 }, \ + { RT2860_EXP_ACK_TIME, 0x002400ca }, \ + { RT2860_XIFS_TIME_CFG, 0x33a41010 }, \ + { RT2860_PWR_PIN_CFG, 0x00000003 } + +/* + * Default values for BBP registers; values taken from the reference driver. + */ +#define RT2860_DEF_BBP \ + { 65, 0x2c }, \ + { 66, 0x38 }, \ + { 69, 0x12 }, \ + { 70, 0x0a }, \ + { 73, 0x10 }, \ + { 81, 0x37 }, \ + { 82, 0x62 }, \ + { 83, 0x6a }, \ + { 84, 0x99 }, \ + { 86, 0x00 }, \ + { 91, 0x04 }, \ + { 92, 0x00 }, \ + { 103, 0x00 }, \ + { 105, 0x05 }, \ + { 106, 0x35 } + +/* + * Default settings for RF registers; values derived from the reference driver. + */ +#define RT2860_RF2850 \ + { 1, 0x100bb3, 0x1301e1, 0x05a014, 0x001402 }, \ + { 2, 0x100bb3, 0x1301e1, 0x05a014, 0x001407 }, \ + { 3, 0x100bb3, 0x1301e2, 0x05a014, 0x001402 }, \ + { 4, 0x100bb3, 0x1301e2, 0x05a014, 0x001407 }, \ + { 5, 0x100bb3, 0x1301e3, 0x05a014, 0x001402 }, \ + { 6, 0x100bb3, 0x1301e3, 0x05a014, 0x001407 }, \ + { 7, 0x100bb3, 0x1301e4, 0x05a014, 0x001402 }, \ + { 8, 0x100bb3, 0x1301e4, 0x05a014, 0x001407 }, \ + { 9, 0x100bb3, 0x1301e5, 0x05a014, 0x001402 }, \ + { 10, 0x100bb3, 0x1301e5, 0x05a014, 0x001407 }, \ + { 11, 0x100bb3, 0x1301e6, 0x05a014, 0x001402 }, \ + { 12, 0x100bb3, 0x1301e6, 0x05a014, 0x001407 }, \ + { 13, 0x100bb3, 0x1301e7, 0x05a014, 0x001402 }, \ + { 14, 0x100bb3, 0x1301e8, 0x05a014, 0x001404 }, \ + { 36, 0x100bb3, 0x130266, 0x056014, 0x001408 }, \ + { 38, 0x100bb3, 0x130267, 0x056014, 0x001404 }, \ + { 40, 0x100bb2, 0x1301a0, 0x056014, 0x001400 }, \ + { 44, 0x100bb2, 0x1301a0, 0x056014, 0x001408 }, \ + { 46, 0x100bb2, 0x1301a1, 0x056014, 0x001402 }, \ + { 48, 0x100bb2, 0x1301a1, 0x056014, 0x001406 }, \ + { 52, 0x100bb2, 0x1301a2, 0x056014, 0x001404 }, \ + { 54, 0x100bb2, 0x1301a2, 0x056014, 0x001408 }, \ + { 56, 0x100bb2, 0x1301a3, 0x056014, 0x001402 }, \ + { 60, 0x100bb2, 0x1301a4, 0x056014, 0x001400 }, \ + { 62, 0x100bb2, 0x1301a4, 0x056014, 0x001404 }, \ + { 64, 0x100bb2, 0x1301a4, 0x056014, 0x001408 }, \ + { 100, 0x100bb2, 0x1301ac, 0x05e014, 0x001400 }, \ + { 102, 0x100bb2, 0x1701ac, 0x15e014, 0x001404 }, \ + { 104, 0x100bb2, 0x1701ac, 0x15e014, 0x001408 }, \ + { 108, 0x100bb3, 0x17028c, 0x15e014, 0x001404 }, \ + { 110, 0x100bb3, 0x13028d, 0x05e014, 0x001400 }, \ + { 112, 0x100bb3, 0x13028d, 0x05e014, 0x001406 }, \ + { 116, 0x100bb3, 0x13028e, 0x05e014, 0x001408 }, \ + { 118, 0x100bb3, 0x13028f, 0x05e014, 0x001404 }, \ + { 120, 0x100bb1, 0x1300e0, 0x05e014, 0x001400 }, \ + { 124, 0x100bb1, 0x1300e0, 0x05e014, 0x001404 }, \ + { 126, 0x100bb1, 0x1300e0, 0x05e014, 0x001406 }, \ + { 128, 0x100bb1, 0x1300e0, 0x05e014, 0x001408 }, \ + { 132, 0x100bb1, 0x1300e1, 0x05e014, 0x001402 }, \ + { 134, 0x100bb1, 0x1300e1, 0x05e014, 0x001404 }, \ + { 136, 0x100bb1, 0x1300e1, 0x05e014, 0x001406 }, \ + { 140, 0x100bb1, 0x1300e2, 0x05e014, 0x001400 }, \ + { 149, 0x100bb1, 0x1300e2, 0x05e014, 0x001409 }, \ + { 151, 0x100bb1, 0x1300e3, 0x05e014, 0x001401 }, \ + { 153, 0x100bb1, 0x1300e3, 0x05e014, 0x001403 }, \ + { 157, 0x100bb1, 0x1300e3, 0x05e014, 0x001407 }, \ + { 159, 0x100bb1, 0x1300e3, 0x05e014, 0x001409 }, \ + { 161, 0x100bb1, 0x1300e4, 0x05e014, 0x001401 }, \ + { 165, 0x100bb1, 0x1300e4, 0x05e014, 0x001405 }, \ + { 167, 0x100bb1, 0x1300f4, 0x05e014, 0x001407 }, \ + { 169, 0x100bb1, 0x1300f4, 0x05e014, 0x001409 }, \ + { 171, 0x100bb1, 0x1300f5, 0x05e014, 0x001401 }, \ + { 173, 0x100bb1, 0x1300f5, 0x05e014, 0x001403 } + +#define RT3070_RF3052 \ + { 0xf1, 2, 2 }, \ + { 0xf1, 2, 7 }, \ + { 0xf2, 2, 2 }, \ + { 0xf2, 2, 7 }, \ + { 0xf3, 2, 2 }, \ + { 0xf3, 2, 7 }, \ + { 0xf4, 2, 2 }, \ + { 0xf4, 2, 7 }, \ + { 0xf5, 2, 2 }, \ + { 0xf5, 2, 7 }, \ + { 0xf6, 2, 2 }, \ + { 0xf6, 2, 7 }, \ + { 0xf7, 2, 2 }, \ + { 0xf8, 2, 4 }, \ + { 0x56, 0, 4 }, \ + { 0x56, 0, 6 }, \ + { 0x56, 0, 8 }, \ + { 0x57, 0, 0 }, \ + { 0x57, 0, 2 }, \ + { 0x57, 0, 4 }, \ + { 0x57, 0, 8 }, \ + { 0x57, 0, 10 }, \ + { 0x58, 0, 0 }, \ + { 0x58, 0, 4 }, \ + { 0x58, 0, 6 }, \ + { 0x58, 0, 8 }, \ + { 0x5b, 0, 8 }, \ + { 0x5b, 0, 10 }, \ + { 0x5c, 0, 0 }, \ + { 0x5c, 0, 4 }, \ + { 0x5c, 0, 6 }, \ + { 0x5c, 0, 8 }, \ + { 0x5d, 0, 0 }, \ + { 0x5d, 0, 2 }, \ + { 0x5d, 0, 4 }, \ + { 0x5d, 0, 8 }, \ + { 0x5d, 0, 10 }, \ + { 0x5e, 0, 0 }, \ + { 0x5e, 0, 4 }, \ + { 0x5e, 0, 6 }, \ + { 0x5e, 0, 8 }, \ + { 0x5f, 0, 0 }, \ + { 0x5f, 0, 9 }, \ + { 0x5f, 0, 11 }, \ + { 0x60, 0, 1 }, \ + { 0x60, 0, 5 }, \ + { 0x60, 0, 7 }, \ + { 0x60, 0, 9 }, \ + { 0x61, 0, 1 }, \ + { 0x61, 0, 3 }, \ + { 0x61, 0, 5 }, \ + { 0x61, 0, 7 }, \ + { 0x61, 0, 9 } + +#define RT3070_DEF_RF \ + { 4, 0x40 }, \ + { 5, 0x03 }, \ + { 6, 0x02 }, \ + { 7, 0x70 }, \ + { 9, 0x0f }, \ + { 10, 0x41 }, \ + { 11, 0x21 }, \ + { 12, 0x7b }, \ + { 14, 0x90 }, \ + { 15, 0x58 }, \ + { 16, 0xb3 }, \ + { 17, 0x92 }, \ + { 18, 0x2c }, \ + { 19, 0x02 }, \ + { 20, 0xba }, \ + { 21, 0xdb }, \ + { 24, 0x16 }, \ + { 25, 0x01 }, \ + { 29, 0x1f } + +#define RT3572_DEF_RF \ + { 0, 0x70 }, \ + { 1, 0x81 }, \ + { 2, 0xf1 }, \ + { 3, 0x02 }, \ + { 4, 0x4c }, \ + { 5, 0x05 }, \ + { 6, 0x4a }, \ + { 7, 0xd8 }, \ + { 9, 0xc3 }, \ + { 10, 0xf1 }, \ + { 11, 0xb9 }, \ + { 12, 0x70 }, \ + { 13, 0x65 }, \ + { 14, 0xa0 }, \ + { 15, 0x53 }, \ + { 16, 0x4c }, \ + { 17, 0x23 }, \ + { 18, 0xac }, \ + { 19, 0x93 }, \ + { 20, 0xb3 }, \ + { 21, 0xd0 }, \ + { 22, 0x00 }, \ + { 23, 0x3c }, \ + { 24, 0x16 }, \ + { 25, 0x15 }, \ + { 26, 0x85 }, \ + { 27, 0x00 }, \ + { 28, 0x00 }, \ + { 29, 0x9b }, \ + { 30, 0x09 }, \ + { 31, 0x10 } Property changes on: sys/dev/ral/rt2860reg.h ___________________________________________________________________ Added: svn:mime-type ## -0,0 +1 ## +text/plain \ No newline at end of property Added: svn:keywords ## -0,0 +1 ## +FreeBSD=%H \ No newline at end of property Added: svn:eol-style ## -0,0 +1 ## +native \ No newline at end of property Index: sys/dev/ral/rt2860var.h =================================================================== --- sys/dev/ral/rt2860var.h (revision 0) +++ sys/dev/ral/rt2860var.h (working copy) @@ -0,0 +1,210 @@ +/* $OpenBSD: rt2860var.h,v 1.20 2010/09/07 16:21:42 deraadt Exp $ */ + +/*- + * Copyright (c) 2007 + * 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. + */ + +#define RT2860_TX_RING_COUNT 64 +#define RT2860_RX_RING_COUNT 128 +#define RT2860_TX_POOL_COUNT (RT2860_TX_RING_COUNT * 2) + +#define RT2860_MAX_SCATTER ((RT2860_TX_RING_COUNT * 2) - 1) + +/* HW supports up to 255 STAs */ +#define RT2860_WCID_MAX 254 +#define RT2860_AID2WCID(aid) ((aid) & 0xff) + +struct rt2860_rx_radiotap_header { + struct ieee80211_radiotap_header wr_ihdr; + uint64_t wr_tsf; + uint8_t wr_flags; + uint8_t wr_rate; + uint16_t wr_chan_freq; + uint16_t wr_chan_flags; + uint8_t wr_antenna; + int8_t wr_antsignal; + int8_t wr_antnoise; +} __packed; + +#define RT2860_RX_RADIOTAP_PRESENT \ + ((1 << IEEE80211_RADIOTAP_TSFT) | \ + (1 << IEEE80211_RADIOTAP_FLAGS) | \ + (1 << IEEE80211_RADIOTAP_RATE) | \ + (1 << IEEE80211_RADIOTAP_CHANNEL) | \ + (1 << IEEE80211_RADIOTAP_ANTENNA) | \ + (1 << IEEE80211_RADIOTAP_DBM_ANTSIGNAL) | \ + (1 << IEEE80211_RADIOTAP_DBM_ANTNOISE)) + +struct rt2860_tx_radiotap_header { + struct ieee80211_radiotap_header wt_ihdr; + uint8_t wt_flags; + uint8_t wt_rate; + uint16_t wt_chan_freq; + uint16_t wt_chan_flags; +} __packed; + +#define RT2860_TX_RADIOTAP_PRESENT \ + ((1 << IEEE80211_RADIOTAP_FLAGS) | \ + (1 << IEEE80211_RADIOTAP_RATE) | \ + (1 << IEEE80211_RADIOTAP_CHANNEL)) + +struct rt2860_tx_data { + struct rt2860_txwi *txwi; + struct mbuf *m; + struct ieee80211_node *ni; + bus_dmamap_t map; + bus_addr_t paddr; + SLIST_ENTRY(rt2860_tx_data) next; +}; + +struct rt2860_tx_ring { + struct rt2860_txd *txd; + bus_addr_t paddr; + bus_dma_tag_t desc_dmat; + bus_dmamap_t desc_map; + bus_dma_tag_t data_dmat; + bus_dma_segment_t seg; + struct rt2860_tx_data *data[RT2860_TX_RING_COUNT]; + int cur; + int next; + int queued; +}; + +struct rt2860_rx_data { + struct mbuf *m; + bus_dmamap_t map; +}; + +struct rt2860_rx_ring { + struct rt2860_rxd *rxd; + bus_addr_t paddr; + bus_dma_tag_t desc_dmat; + bus_dmamap_t desc_map; + bus_dma_tag_t data_dmat; + bus_dma_segment_t seg; + unsigned int cur; /* must be unsigned */ + struct rt2860_rx_data data[RT2860_RX_RING_COUNT]; +}; + +struct rt2860_node { + struct ieee80211_node ni; + uint8_t wcid; + uint8_t ridx[IEEE80211_RATE_MAXSIZE]; + uint8_t ctl_ridx[IEEE80211_RATE_MAXSIZE]; +}; + +struct rt2860_vap { + struct ieee80211vap ral_vap; + + int (*ral_newstate)(struct ieee80211vap *, + enum ieee80211_state, int); +}; +#define RT2860_VAP(vap) ((struct rt2860_vap *)(vap)) + +struct rt2860_softc { + struct ifnet *sc_ifp; + device_t sc_dev; + bus_space_tag_t sc_st; + bus_space_handle_t sc_sh; + + struct mtx sc_mtx; + + struct callout watchdog_ch; + + int sc_invalid; + int sc_debug; +/* + * The same in both up to here + * ------------------------------------------------ + */ + + uint16_t (*sc_srom_read)(struct rt2860_softc *, + uint16_t); + void (*sc_node_free)(struct ieee80211_node *); + + int sc_flags; +#define RT2860_ENABLED (1 << 0) +#define RT2860_ADVANCED_PS (1 << 1) +#define RT2860_PCIE (1 << 2) + + struct ieee80211_node *wcid2ni[RT2860_WCID_MAX]; + + struct rt2860_tx_ring txq[6]; + struct rt2860_rx_ring rxq; + + SLIST_HEAD(, rt2860_tx_data) data_pool; + struct rt2860_tx_data data[RT2860_TX_POOL_COUNT]; + bus_dma_tag_t txwi_dmat; + bus_dmamap_t txwi_map; + bus_dma_segment_t txwi_seg; + caddr_t txwi_vaddr; + + int sc_tx_timer; + int mgtqid; + uint8_t qfullmsk; + + uint16_t mac_ver; + uint16_t mac_rev; + uint8_t rf_rev; + uint8_t freq; + uint8_t ntxchains; + uint8_t nrxchains; + uint8_t pslevel; + int8_t txpow1[54]; + int8_t txpow2[54]; + int8_t rssi_2ghz[3]; + int8_t rssi_5ghz[3]; + uint8_t lna[4]; + uint8_t rf24_20mhz; + uint8_t rf24_40mhz; + uint8_t patch_dac; + uint8_t rfswitch; + uint8_t ext_2ghz_lna; + uint8_t ext_5ghz_lna; + uint8_t calib_2ghz; + uint8_t calib_5ghz; + uint8_t txmixgain_2ghz; + uint8_t txmixgain_5ghz; + uint8_t tssi_2ghz[9]; + uint8_t tssi_5ghz[9]; + uint8_t step_2ghz; + uint8_t step_5ghz; + struct { + uint8_t reg; + uint8_t val; + } bbp[8], rf[10]; + uint8_t leds; + uint16_t led[3]; + uint32_t txpow20mhz[5]; + uint32_t txpow40mhz_2ghz[5]; + uint32_t txpow40mhz_5ghz[5]; + + struct rt2860_rx_radiotap_header sc_rxtap; + int sc_rxtap_len; + struct rt2860_tx_radiotap_header sc_txtap; + int sc_txtap_len; +}; + +int rt2860_attach(device_t, int); +int rt2860_detach(void *); +void rt2860_shutdown(void *); +void rt2860_suspend(void *); +void rt2860_resume(void *); +void rt2860_intr(void *); + +#define RAL_LOCK(sc) mtx_lock(&(sc)->sc_mtx) +#define RAL_LOCK_ASSERT(sc) mtx_assert(&(sc)->sc_mtx, MA_OWNED) +#define RAL_UNLOCK(sc) mtx_unlock(&(sc)->sc_mtx) Property changes on: sys/dev/ral/rt2860var.h ___________________________________________________________________ Added: svn:mime-type ## -0,0 +1 ## +text/plain \ No newline at end of property Added: svn:keywords ## -0,0 +1 ## +FreeBSD=%H \ No newline at end of property Added: svn:eol-style ## -0,0 +1 ## +native \ No newline at end of property Index: sys/dev/ral/if_ral_pci.c =================================================================== --- sys/dev/ral/if_ral_pci.c (revision 234847) +++ sys/dev/ral/if_ral_pci.c (working copy) @@ -21,7 +21,7 @@ __FBSDID("$FreeBSD$"); /* - * PCI/Cardbus front-end for the Ralink RT2560/RT2561/RT2561S/RT2661 driver. + * PCI/Cardbus front-end for the Ralink RT2xxx wireless driver. */ #include @@ -57,6 +57,7 @@ __FBSDID("$FreeBSD$"); #include #include +#include MODULE_DEPEND(ral, pci, 1, 1, 1); MODULE_DEPEND(ral, firmware, 1, 1, 1); @@ -74,6 +75,12 @@ static const struct ral_pci_ident ral_pci_ids[] = { 0x1814, 0x0301, "Ralink Technology RT2561S" }, { 0x1814, 0x0302, "Ralink Technology RT2561" }, { 0x1814, 0x0401, "Ralink Technology RT2661" }, + { 0x1814, 0x0601, "Ralink Technology RT2860 PCI" }, + { 0x1814, 0x0681, "Ralink Technology RT2860 PCIe" }, + { 0x1814, 0x0701, "Ralink Technology RT2870 PCI" }, + { 0x1814, 0x0781, "Ralink Technology RT2870 PCIe" }, + { 0x1814, 0x3060, "Ralink Technology RT3060 PCI" }, + { 0x1814, 0x3090, "Ralink Technology RT3090 PCIe" }, { 0, 0, NULL } }; @@ -101,12 +108,20 @@ static struct ral_opns { rt2661_suspend, rt2661_resume, rt2661_intr +}, ral_rt2860_opns = { + rt2860_attach, + rt2860_detach, + rt2860_shutdown, + rt2860_suspend, + rt2860_resume, + rt2860_intr }; struct ral_pci_softc { union { struct rt2560_softc sc_rt2560; struct rt2661_softc sc_rt2661; + struct rt2860_softc sc_rt2860; } u; struct ral_opns *sc_opns; @@ -180,8 +195,28 @@ ral_pci_attach(device_t dev) /* enable bus-mastering */ pci_enable_busmaster(dev); - psc->sc_opns = (pci_get_device(dev) == 0x0201) ? &ral_rt2560_opns : - &ral_rt2661_opns; + switch (pci_get_device(dev)) { + case 0x0201: + psc->sc_opns = &ral_rt2560_opns; + break; + case 0x0301: + case 0x0302: + case 0x0401: + psc->sc_opns = &ral_rt2661_opns; + break; + case 0x0601: + case 0x0681: + case 0x0701: + case 0x0781: + case 0x3060: + case 0x3090: + psc->sc_opns = &ral_rt2860_opns; + break; + default: + device_printf(dev, "ERROR: Unknown card 0x%04x\n", + pci_get_device(dev)); + return (ENXIO); + } psc->mem_rid = RAL_PCI_BAR0; psc->mem = bus_alloc_resource_any(dev, SYS_RES_MEMORY, &psc->mem_rid, --Boundary-00=_ggroP1S39UUHyDC-- From owner-freebsd-net@FreeBSD.ORG Thu May 3 18:18:14 2012 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 8E0E6106564A; Thu, 3 May 2012 18:18:14 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pz0-f49.google.com (mail-pz0-f49.google.com [209.85.210.49]) by mx1.freebsd.org (Postfix) with ESMTP id 3C3158FC08; Thu, 3 May 2012 18:18:14 +0000 (UTC) Received: by dadm1 with SMTP id m1so2156310dad.8 for ; Thu, 03 May 2012 11:18:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=YKr2oFQRGQPVSFyFIqfxB5af9PQEIpqJqdOpa2x2Zhk=; b=zQRivqR7HhgVYO5He7XhcOEjOtSd4/NmmgPRPWcLfbw3EMb90r/GeVt4kQUhqUQ4Bv Fcc29g8pkLeOsASOHAuuvwPFaUv4i6dH706KcKJ7p868y8viRJqQ0NWo9xcuHjPPUppP 9cQx+M4nnIX2Iso3Zkh+F66FsnvYWefr/C9QkAvCAD8vKAOfYeeP6qwjHmLSzb0wCbPA W5VZlyyltbsoqkAaNIx3QZWJuhOpNFWauKTSN/iONx3pDPOlq/QFNiaPcaye1Q1nMcC9 pO8nuqbFhemrAzO+MpwS/fTrorSOMBi46QnrAe5dVf4smnKJu5icBr/1+55kMrtbFAjK 9kQQ== MIME-Version: 1.0 Received: by 10.68.130.67 with SMTP id oc3mr10371720pbb.68.1336069093901; Thu, 03 May 2012 11:18:13 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.142.101.9 with HTTP; Thu, 3 May 2012 11:18:13 -0700 (PDT) In-Reply-To: <201205031853.53102.bschmidt@freebsd.org> References: <201205031853.53102.bschmidt@freebsd.org> Date: Thu, 3 May 2012 11:18:13 -0700 X-Google-Sender-Auth: jpgQmh-GQ3bx-v5gphI3ItfCs1E Message-ID: From: Adrian Chadd To: Bernhard Schmidt Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org, freebsd-wireless@freebsd.org, freebsd-current@freebsd.org Subject: Re: [CFT] Ralink RT2860, RT2870, RT3060, RT3090 support 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, 03 May 2012 18:18:14 -0000 Hi, First off, let me say "thankyou" to you, ray@ and all the people who have chipped away at this little problem. I look very forward to having rt2xxx 802.11n support, as do many users on the forums. :) I haven't yet done a pass or two to see what the state of the locking/concurrency handling is. Don't let that stop you from committing it though, I'm sure we can find/fix whatever issues creep up post-commit. Thanks again! Adrian From owner-freebsd-net@FreeBSD.ORG Thu May 3 22:33:54 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0CAD5106566C; Thu, 3 May 2012 22:33:54 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout1-b.corp.bf1.yahoo.com (mrout1-b.corp.bf1.yahoo.com [98.139.253.104]) by mx1.freebsd.org (Postfix) with ESMTP id BE3858FC08; Thu, 3 May 2012 22:33:53 +0000 (UTC) Received: from [IPv6:::1] (rideseveral.corp.yahoo.com [10.73.160.231]) by mrout1-b.corp.bf1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id q43MXcwu065325; Thu, 3 May 2012 15:33:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1336084419; bh=aJivQP/l8ZF5ns2Pt5ngFfycEU1p9CKLvMdIaSwq3hE=; h=Subject:From:To:Cc:In-Reply-To:References:Content-Type:Date: Message-ID:Mime-Version:Content-Transfer-Encoding; b=bjWbTu5m8gRtH/PlRSy4KBbmqNQym/oe1fhlGvWUUkAMKGqPl1y76u6sk+pRDU6jo 3SZWvY4lD/q1c9HQWBp8CwUZe7OQida/X1Fe5sgHDwj3ei4Q4CIRFSHzYDWuZdpkRa 9u4Fv3jTtz7c4M6e8TZ5kJjRWPRqSdRRk6xQc4RA= From: Sean Bruno To: John Baldwin In-Reply-To: <1335382225.2722.6.camel@powernoodle-l7.corp.yahoo.com> References: <1335312667.11564.13.camel@powernoodle-l7.corp.yahoo.com> <201204250932.21378.jhb@freebsd.org> <1335382225.2722.6.camel@powernoodle-l7.corp.yahoo.com> Content-Type: text/plain; charset="UTF-8" Date: Thu, 03 May 2012 15:33:38 -0700 Message-ID: <1336084418.3077.21.camel@powernoodle-l7.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 084418003 Cc: "freebsd-net@freebsd.org" , Jack Vogel Subject: Re: igb(4) Pondering a bind to cpu 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, 03 May 2012 22:33:54 -0000 On Wed, 2012-04-25 at 12:30 -0700, Sean Bruno wrote: > On Wed, 2012-04-25 at 06:32 -0700, John Baldwin wrote: > > CPU IDs are not guaranteed to be dense. However, you can use > > CPU_FIRST() and > > CPU_NEXT() with your static global instead. > > > Ah, does CPU_NEXT() reset to 0 when it reaches the end of its list of > CPUs? > Ah, I see. So, yeah, here's a v2 of the patch that does "the right" thing with non-sparse cpus, mulitple queues, and mulitple physical interfaces. http://people.freebsd.org/~sbruno/if_igb.c.txt > > > OTOH, if igb were to just leave the interrupts alone instead of > > binding them > > by hand, they would get round-robin assigned among available cores > > already. I > > think in this case the best approach might be to add a tunable to > > disable > > igb's manual binding and instead let the default system round-robin > > be > > preserved. > > also, yes. Why *are* we binding to CPUs in the first place? Are we > afraid that the scheduler won't do the right thing and we're trying to > work around some unknown performance issue ? > > Sean > Still haven't seen a good reason to bind the queues by default in the first place. Sean From owner-freebsd-net@FreeBSD.ORG Thu May 3 22:34:00 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1D37A1065689; Thu, 3 May 2012 22:34:00 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (bird.sbone.de [46.4.1.90]) by mx1.freebsd.org (Postfix) with ESMTP id B6B858FC0A; Thu, 3 May 2012 22:33:59 +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 9159E25D3AC2; Thu, 3 May 2012 22:33:58 +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 B4739BE62EE; Thu, 3 May 2012 22:33:57 +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 QjCmUvO7Hr+R; Thu, 3 May 2012 22:33:56 +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 D3EA5BE62F0; Thu, 3 May 2012 22:33:56 +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: Thu, 3 May 2012 22:33:55 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <540794CD-1BD4-4044-8934-B1782FC27FD4@lists.zabbadoz.net> References: To: Seth Mos X-Mailer: Apple Mail (2.1084) Cc: freebsd-net@freebsd.org, lev@FreeBSD.org Subject: Re: Hetzner.de IPv6 and FreeBSD -- default gateway is on other prefix, need to add static route before default -- how? 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, 03 May 2012 22:34:00 -0000 On 29. Apr 2012, at 16:17 , Seth Mos wrote: > Use the link local addrees of the gateway. That should just work. Until they replace the interface, the router, ... and it's changed and = your connectivity is gone. But yes that's what I am currently doing and = I suggested to them to just use a fe80::1 or the like as default gateway = for users to avoid all the not directly connected crap that they even = document to be a problem even in linux land. That ticket I never got a = reply for... /bz --=20 Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! From owner-freebsd-net@FreeBSD.ORG Thu May 3 22:35:20 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1905B106566C; Thu, 3 May 2012 22:35:20 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (bird.sbone.de [46.4.1.90]) by mx1.freebsd.org (Postfix) with ESMTP id B7F598FC17; Thu, 3 May 2012 22:35:19 +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 D342125D3A82; Thu, 3 May 2012 22:35:18 +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 51132BE62EF; Thu, 3 May 2012 22:35:18 +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 Oea8vA4Yzxht; Thu, 3 May 2012 22:35:16 +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 37B5BBE62EE; Thu, 3 May 2012 22:35:16 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Bjoern A. Zeeb" In-Reply-To: <20120430.064229.855968812732421988.hrs@allbsd.org> Date: Thu, 3 May 2012 22:35:15 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <33D6E066-2458-4A4D-B79A-3563D5683437@lists.zabbadoz.net> References: <1606941405.20120429170656@serebryakov.spb.ru> <20120430.064229.855968812732421988.hrs@allbsd.org> To: Hiroki Sato X-Mailer: Apple Mail (2.1084) Cc: freebsd-net@FreeBSD.org, lev@FreeBSD.org Subject: Re: Hetzner.de IPv6 and FreeBSD -- default gateway is on other prefix, need to add static route before default -- how? 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, 03 May 2012 22:35:20 -0000 On 29. Apr 2012, at 21:42 , Hiroki Sato wrote: > Lev Serebryakov wrote > in <1606941405.20120429170656@serebryakov.spb.ru>: >=20 > le> Hello, Freebsd-net. > le> > le> "Famous" dedicated server provider Hetzner provides native IPv6 = for > le> servers, but with rather strange routing configuration: you need = to > le> configure static interface route and make this route default. > le> > le> If I add such lines in /etc/rc.conf: > le> > le> ifconfig_re0_ipv6=3D"inet6 2a01:4f8:131:60a2::2 prefixlen 64 = auto_linklocal accept_rtadv" > le> ipv6_static_routes=3D"ipv6defgw" > le> ipv6_route_ipv6defgw=3D"2a01:4f8:131:60a0:: -prefixlen 59 -iface = re0" > le> ipv6_defaultrouter=3D"2a01:4f8:131:60a0::1" > le> ipv6_default_interface=3D"re0" > le> > le> It doesn't work, because default route added first and it fails = to > le> be added, as route to 2a01:4f8:131:60a0::1 is not known yet. >=20 > Why do you need to configure the default route manually? If > accepting RA on re0 it should be configured automatically.' the accept_rtadv is pointless as they do not advertise - at least not = yet. --=20 Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! From owner-freebsd-net@FreeBSD.ORG Thu May 3 22:38:46 2012 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 6A8251065678; Thu, 3 May 2012 22:38:46 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 3D1898FC17; Thu, 3 May 2012 22:38:46 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q43MckOv040388; Thu, 3 May 2012 22:38:46 GMT (envelope-from bz@freefall.freebsd.org) Received: (from bz@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q43MckON040384; Thu, 3 May 2012 22:38:46 GMT (envelope-from bz) Date: Thu, 3 May 2012 22:38:46 GMT Message-Id: <201205032238.q43MckON040384@freefall.freebsd.org> To: bz@FreeBSD.org, freebsd-net@FreeBSD.org, freebsd-virtualization@FreeBSD.org From: bz@FreeBSD.org Cc: Subject: Re: kern/167551: [vimage] Fatal trap 12 jails, vimage, ifconfig destroy epair*a 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, 03 May 2012 22:38:46 -0000 Synopsis: [vimage] Fatal trap 12 jails, vimage, ifconfig destroy epair*a Responsible-Changed-From-To: freebsd-net->freebsd-virtualization Responsible-Changed-By: bz Responsible-Changed-When: Thu May 3 22:38:31 UTC 2012 Responsible-Changed-Why: other list; it's vimage http://www.freebsd.org/cgi/query-pr.cgi?pr=167551 From owner-freebsd-net@FreeBSD.ORG Fri May 4 06:55:43 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 39DDF106566B for ; Fri, 4 May 2012 06:55:43 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) by mx1.freebsd.org (Postfix) with ESMTP id B88968FC0C for ; Fri, 4 May 2012 06:55:42 +0000 (UTC) Received: by wgbds11 with SMTP id ds11so947767wgb.1 for ; Thu, 03 May 2012 23:55:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:date:subject:to :message-id:mime-version:x-mailer; bh=vUGizerEcWtaALGzb+XgU6Q0tqAbZj7gbGNaADMbMXs=; b=BTAhlQWNrPNwMu1ZwsH2G9DmhWj4bA/w/RpA7ygga6mZkIDrVYChnppuQ+fgnQaapC LY0hBSrYyjtrM478RjgpXY9PmyFqyad7zWNC2+3h877P9PLR4m/EXP8tng47X5PXTdir Fos60cKHeXXhUM1Ltn7YE8/im5BccpQxwZ4Qp4wCe3vCFFvc9JL+cgMFoT8OPpa1LsS0 IR5BKhR1wqdlGSTtC07mRN+gSMn29xzkl5QlzEOn1Cc6VpDOGajcpdaHFunQyqWS3U1m qMiM1/zKXydolotKba3RjgytBZputKjouoF/lW9sUDyv6Psp2czCXu6/XW0J0bkBp1eP Nvrg== Received: by 10.216.212.78 with SMTP id x56mr3080610weo.36.1336114535675; Thu, 03 May 2012 23:55:35 -0700 (PDT) Received: from imba-brutale.totalterror.net ([93.152.152.135]) by mx.google.com with ESMTPS id o2sm11963455wiv.11.2012.05.03.23.55.33 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 03 May 2012 23:55:34 -0700 (PDT) From: Nikolay Denev Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 4 May 2012 09:55:32 +0300 To: freebsd-net@freebsd.org Message-Id: <0EF89766-3EA6-4454-AA55-C0573F7CBDFB@gmail.com> Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Subject: NETMAP on 9-STABLE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 06:55:43 -0000 Hello, What is required to get NETMAP running on 9-STABLE, as the patches seem = a bit stale. I see that the core functionality is there, but the driver support is = missing. Is just using dev/ixgbe from -CURRENT sufficient? Thanks, Nikolay= From owner-freebsd-net@FreeBSD.ORG Fri May 4 07:06:15 2012 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 E783C106566B for ; Fri, 4 May 2012 07:06:15 +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 A379B8FC08 for ; Fri, 4 May 2012 07:06:15 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 091547300A; Fri, 4 May 2012 09:26:09 +0200 (CEST) Date: Fri, 4 May 2012 09:26:09 +0200 From: Luigi Rizzo To: Nikolay Denev Message-ID: <20120504072609.GB12652@onelab2.iet.unipi.it> References: <0EF89766-3EA6-4454-AA55-C0573F7CBDFB@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0EF89766-3EA6-4454-AA55-C0573F7CBDFB@gmail.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: NETMAP on 9-STABLE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 07:06:16 -0000 On Fri, May 04, 2012 at 09:55:32AM +0300, Nikolay Denev wrote: > Hello, > > What is required to get NETMAP running on 9-STABLE, as the patches seem a bit stale. > I see that the core functionality is there, but the driver support is missing. > Is just using dev/ixgbe from -CURRENT sufficient? I meant to do a MFC but was waiting for the device drivers to be sync'ed first (especially, e1000/ is still a bit behind what is in HEAD and 8-STABLE) Importing the relevant files from -CURRENT should be ok, possibly just resolving minor glitches in compiling the device drivers. This includes the following files and directories sys/net/netmap.h sys/net/netmap_user.h sys/dev/netmap/ tools/tools/netmap/ and the device drivers sys/dev/ixgbe/ sys/dev/e1000/ sys/dev/re/ cheers luigi From owner-freebsd-net@FreeBSD.ORG Fri May 4 07:10:05 2012 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 6D1D3106564A for ; Fri, 4 May 2012 07:10:05 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by mx1.freebsd.org (Postfix) with ESMTP id E1E898FC0A for ; Fri, 4 May 2012 07:10:04 +0000 (UTC) Received: by wibhr7 with SMTP id hr7so898784wib.13 for ; Fri, 04 May 2012 00:10:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=jdXgWZJCIdfZC7nP/4GF+L1UWtj9s/H1pLee2xnhBeI=; b=mxqxrYr6TJstOqBKWA9JxinvAY/iXbQupI17ORW/E1DXT3QgMJJZzf7xjTrppaU6Qs 5ypb5SzABznmw71mvnASwQi8KtA7Hws9qs/zcDm9inf9CTRDlLqkF/Htf1XW5NdWvuSQ k8oOkNHH+4/LaAeCFyYGqNm8GxrSplT7MNw39BzpBFr666Hj0w9fMdRl7rfRpfjwHkGJ JVeebH9aXmY5SbKG0kkJO/5kVY9EGMXelhTdR0JA0jLUm+kEIw+3SdXl2fxs07QyTjkh LEjRrjL2KrO4TjVwjLd8t6zBiklqD+dAgQGDFUteG2wVzdShNW7gj63B4mm+EvB6Gyfs uxgA== Received: by 10.180.107.104 with SMTP id hb8mr10074790wib.8.1336115403618; Fri, 04 May 2012 00:10:03 -0700 (PDT) Received: from imba-brutale.totalterror.net ([93.152.152.135]) by mx.google.com with ESMTPS id o2sm12086313wiv.11.2012.05.04.00.10.01 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 04 May 2012 00:10:02 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Nikolay Denev In-Reply-To: <20120504072609.GB12652@onelab2.iet.unipi.it> Date: Fri, 4 May 2012 10:10:00 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <85937945-3EAE-49F5-94A7-7C10C6E652A0@gmail.com> References: <0EF89766-3EA6-4454-AA55-C0573F7CBDFB@gmail.com> <20120504072609.GB12652@onelab2.iet.unipi.it> To: Luigi Rizzo X-Mailer: Apple Mail (2.1257) Cc: freebsd-net@freebsd.org Subject: Re: NETMAP on 9-STABLE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 07:10:05 -0000 On May 4, 2012, at 10:26 AM, Luigi Rizzo wrote: > On Fri, May 04, 2012 at 09:55:32AM +0300, Nikolay Denev wrote: >> Hello, >>=20 >> What is required to get NETMAP running on 9-STABLE, as the patches = seem a bit stale. >> I see that the core functionality is there, but the driver support is = missing. >> Is just using dev/ixgbe from -CURRENT sufficient? >=20 > I meant to do a MFC but was waiting for the device drivers > to be sync'ed first (especially, e1000/ is still a bit behind > what is in HEAD and 8-STABLE) >=20 > Importing the relevant files from -CURRENT should be ok, > possibly just resolving minor glitches in compiling the device > drivers. >=20 > This includes the following files and directories > sys/net/netmap.h > sys/net/netmap_user.h > sys/dev/netmap/ > tools/tools/netmap/ > and the device drivers > sys/dev/ixgbe/ > sys/dev/e1000/ > sys/dev/re/ >=20 > cheers > luigi Thanks Luigi! I'll try this. Regards, Nikolay= From owner-freebsd-net@FreeBSD.ORG Fri May 4 15:35:02 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E17CB106566B; Fri, 4 May 2012 15:35:01 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id AFBB68FC18; Fri, 4 May 2012 15:35:01 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 03FBBB997; Fri, 4 May 2012 11:35:01 -0400 (EDT) From: John Baldwin To: Konstantin Belousov Date: Fri, 4 May 2012 11:30:22 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p13; KDE/4.5.5; amd64; ; ) References: <20120407133715.GU2358@deviant.kiev.zoral.com.ua> <20120412183849.GA2358@deviant.kiev.zoral.com.ua> <20120501162121.GV2358@deviant.kiev.zoral.com.ua> In-Reply-To: <20120501162121.GV2358@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201205041130.22202.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 04 May 2012 11:35:01 -0400 (EDT) Cc: jfv@freebsd.org, Jack Vogel , net@freebsd.org Subject: Re: 82574L hangs (with r233708 e1000 driver). X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 15:35:02 -0000 On Tuesday, May 01, 2012 12:21:21 pm Konstantin Belousov wrote: > On Thu, Apr 12, 2012 at 09:38:49PM +0300, Konstantin Belousov wrote: > > On Mon, Apr 09, 2012 at 12:19:39PM -0400, John Baldwin wrote: > > > On Sunday, April 08, 2012 1:11:25 am Konstantin Belousov wrote: > > > > On Sat, Apr 07, 2012 at 04:22:07PM -0700, Jack Vogel wrote: > > > > > Make sure you have any firmware up to the latest available, if that doesn't > > > > > help > > > > > let me know and I'll check internally to see if there are any outstanding > > > > > issues > > > > > in shared code, that will be after the weekend. > > > > > > > > I had BIOS rev. 151, after you hint I found rev. 154 on the site. > > > > Now BIOS reports itself as MTCDT10N.86A.0154.2012.0323.1601, > > > > March 23. > > > > > > > > Unfortunately, upgrade did not changed anything in regard of hanging > > > > interface. > > > > > > Does reverting 233708 make any difference? Have you tried futzing around with > > > kgdb when it is hung to see what state the device is in (software state at > > > least)? > > It does, in a sense that without r233708 the interface becomes stuck > > almost immediately. I just upgraded to the e1000@r234154, which does not > > change much. > > > > I fiddled with the adapter state after the hang in kgdb more, and I > > noted something interesting. Apparently, tx works. When I ping the remote > > host from my suffering atom machine, remote host sees the packet. Also > > remote machine sees some udp traffic originating from the tom, like > > ntp queries. > > > > And, on receive, the atom board does receive interrupts, em0:rx 0 counter > > in vmstat -i increases. Even more fun, the sysctl dev.em.0.debug > > shows increasing hw rdh (as I understand, this is hardware 'last > > received' packet pointer for rx ring). So I looked at the packet > > descriptor at hw rdt index, and there I see > > (kgdb) p/x ((struct adapter *)0xffffff80010e4000)->rx_rings->rx_base[78] > > $11 = {buffer_addr = 0x12a128800, length = 0x5ea, csum = 0x3c2b, status = 0x0, > > errors = 0x0, special = 0x0} > > > > Apparently, the Descriptor Done bit is clear, so the em_rxeof() function > > breaks from the loop, not consuming the current packet. Also, it returns > > false due to DD bit clear. This prevents em_msix_rx() from scheduling > > taskqueue for processing. So apparent cause for the hang is missing > > DD bit in descriptor. > > > > I am not sure isn't all this is obvious for anybody who knows em > > internals, and were to go from there. > > Ok, nobody cares. > > Below is the workaround I use to prevent the interface wedging. > It seems that the sole PCI register read (namely, the rx ring head read) > and consequent recheck of the descriptor status greatly reduce the > likelihood of the issue. Unfortunately, the read does not eliminate > the hang completely. So it is not some PCIe coherency problem. > > With the patch applied, I am able to copy around blu-ray images, while > previously the interface hang in 20-30 seconds of 100Mbit/s traffic. > Sometimes the messages are printed: > em0: Workaround: head 1018 tail 1002 cur 1010 > em0: Workaround: head 976 tail 973 cur 974 > em0: Workaround: head 950 tail 939 cur 946 > em0: Workaround: head 435 tail 419 cur 426 > > Machine is still dead due to random memory corruption which I see, in > particular, pmap sometimes read garbage from PTEs. I have no idea is > it related to em0 rx descriptor missed writes, or is a different issue. Humm, so if I'm reading this correctly, the card "skips" a receive descriptor and stores a packet at the next descriptor? That's just bizarre. -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Fri May 4 17:06:29 2012 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 20072106564A for ; Fri, 4 May 2012 17:06:29 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id A5F128FC0A for ; Fri, 4 May 2012 17:06:28 +0000 (UTC) Received: by weyt57 with SMTP id t57so2527359wey.13 for ; Fri, 04 May 2012 10:06:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=nu2L0sBE+FM4+NJ9eVq9yduPeyQQsZNm05YX5nMj8i8=; b=G8YkuEJ8uxkJB9K8OOGYEPIt/353q6Ihxwn4tHRW7mToQ2SGssxJeaiEuw3YQUhouA Aa+tmptx0ZRTC9mEcZj/QG2NG3nTvOE5djwp9wa9nzQD5Ti0MeKV+IQ9n4ZDm7C3ucR1 jYC1gDra3LrgUxl/dRZw7nHrKtlQiFyZiS3tQvio1I94f4txI22hrNj4mBYsmOxNrEyi jAXfXSkHLG+ThXtWoklHq17ZcV3KTfN3sKq2nUvFq+ln9WWzxHOoRAOjjdRZwWmQsRVB WwAUlPe1R2sW3jox5NoSbho4/2M85CT0yvz4yVpN8hZSFjTi0U2MxR33nCjxNg0gr0pQ BNqQ== MIME-Version: 1.0 Received: by 10.180.100.230 with SMTP id fb6mr16785264wib.3.1336151181883; Fri, 04 May 2012 10:06:21 -0700 (PDT) Received: by 10.216.193.220 with HTTP; Fri, 4 May 2012 10:06:21 -0700 (PDT) Date: Fri, 4 May 2012 13:06:21 -0400 Message-ID: From: Arnaud Lacombe To: FreeBSD Net Content-Type: text/plain; charset=ISO-8859-1 Subject: High interrupt load on idle igb interfaces 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, 04 May 2012 17:06:29 -0000 Hi, We are currently evaluating a new hardware platform using 4 Intel 82580 interfaces. System is running FreeBSD 7.1 with backported igb(4) from HEAD (v2.2.5). After about 12h routing around 155Mbps of traffic, vmstat(1) shows a high constant interrupt rate on igb0 and igb3: # vmstat -i irq260: igb0 672410485 11084 irq261: igb0 86304338 1422 irq262: igb0 86262625 1421 irq263: igb0 86356261 1423 irq264: igb0 86374226 1423 irq265: igb0 86202637 1421 irq266: igb0 86290286 1422 irq267: igb0 86415203 1424 irq268: igb0 10 0 [...] irq287: igb3 294639203 4856 irq288: igb3 112026336 1846 irq289: igb3 112503183 1854 irq290: igb3 112154972 1848 irq291: igb3 112441454 1853 irq292: igb3 112224418 1849 irq293: igb3 112485042 1854 irq294: igb3 112290634 1851 irq295: igb3 9 0 Despite the relatively high rate, top(1) does not show anything relevant taking CPU time, and no traffic seems to actually flow: # netstat -i | grep 'igb[03]'; sleep 10; netstat -i | grep 'igb[03]' igb0 1500 00:90:0b:1e:df:f0 807511568 4325295 872538069 0 0 igb0 1500 10.4.4.0 10.4.4.4 0 - 864121185 - - igb3 1500 00:90:0b:1e:df:f3 906072418 0 616715810 0 0 igb3 1500 10.3.3.0 10.3.3.4 0 - 609718187 - - [...] igb0 1500 00:90:0b:1e:df:f0 807511568 4325295 872538069 0 0 igb0 1500 10.4.4.0 10.4.4.4 0 - 864121185 - - igb3 1500 00:90:0b:1e:df:f3 906072418 0 616715810 0 0 igb3 1500 10.3.3.0 10.3.3.4 0 - 609718187 - - Here is some device stat, for igb0: # sysctl dev.igb.0 | grep -v ' 0$' dev.igb.0.%desc: Intel(R) PRO/1000 Network Connection version - 2.2.5 dev.igb.0.%driver: igb dev.igb.0.%location: slot=0 function=0 dev.igb.0.%pnpinfo: vendor=0x8086 device=0x150e subvendor=0x8086 subdevice=0x0000 class=0x020000 dev.igb.0.%parent: pci6 dev.igb.0.nvm: -1 dev.igb.0.enable_aim: 1 dev.igb.0.fc: 65536003 dev.igb.0.rx_processing_limit: 100 dev.igb.0.link_irq: 10 dev.igb.0.device_control: 1087373889 dev.igb.0.rx_control: 67141634 dev.igb.0.interrupt_mask: 4 dev.igb.0.extended_int_mask: 2147484159 dev.igb.0.fc_high_water: 33168 dev.igb.0.fc_low_water: 33152 dev.igb.0.queue0.interrupt_rate: 111111 dev.igb.0.queue0.txd_head: 454 dev.igb.0.queue0.txd_tail: 454 dev.igb.0.queue0.tx_packets: 872538069 dev.igb.0.queue0.rxd_head: 349 dev.igb.0.queue0.rxd_tail: 348 dev.igb.0.queue0.rx_packets: 100975965 dev.igb.0.queue0.rx_bytes: 106639501004 dev.igb.0.queue1.interrupt_rate: 100000 dev.igb.0.queue1.rxd_head: 176 dev.igb.0.queue1.rxd_tail: 175 dev.igb.0.queue1.rx_packets: 101202096 dev.igb.0.queue1.rx_bytes: 106788129111 dev.igb.0.queue2.interrupt_rate: 100000 dev.igb.0.queue2.rxd_head: 1010 dev.igb.0.queue2.rxd_tail: 1009 dev.igb.0.queue2.rx_packets: 100999154 dev.igb.0.queue2.rx_bytes: 106597010381 dev.igb.0.queue3.interrupt_rate: 100000 dev.igb.0.queue3.rxd_head: 918 dev.igb.0.queue3.rxd_tail: 917 dev.igb.0.queue3.rx_packets: 101185430 dev.igb.0.queue3.rx_bytes: 106764061444 dev.igb.0.queue4.interrupt_rate: 100000 dev.igb.0.queue4.rxd_head: 504 dev.igb.0.queue4.rxd_tail: 503 dev.igb.0.queue4.rx_packets: 101162488 dev.igb.0.queue4.rx_bytes: 106772530472 dev.igb.0.queue5.interrupt_rate: 100000 dev.igb.0.queue5.rxd_head: 967 dev.igb.0.queue5.rxd_tail: 966 dev.igb.0.queue5.rx_packets: 100960199 dev.igb.0.queue5.rx_bytes: 106548050559 dev.igb.0.queue6.interrupt_rate: 100000 dev.igb.0.queue6.rxd_head: 457 dev.igb.0.queue6.rxd_tail: 456 dev.igb.0.queue6.rx_packets: 101045705 dev.igb.0.queue6.rx_bytes: 106654181280 dev.igb.0.queue7.interrupt_rate: 100000 dev.igb.0.queue7.rxd_head: 409 dev.igb.0.queue7.rxd_tail: 408 dev.igb.0.queue7.rx_packets: 101220761 dev.igb.0.queue7.rx_bytes: 106820232038 dev.igb.0.mac_stats.missed_packets: 4325192 dev.igb.0.mac_stats.recv_no_buff: 963 dev.igb.0.mac_stats.recv_jabber: 15 dev.igb.0.mac_stats.recv_errs: 18 dev.igb.0.mac_stats.crc_errs: 85 dev.igb.0.mac_stats.total_pkts_recvd: 813077091 dev.igb.0.mac_stats.good_pkts_recvd: 808751798 dev.igb.0.mac_stats.bcast_pkts_recvd: 428 dev.igb.0.mac_stats.rx_frames_64: 221567998 dev.igb.0.mac_stats.rx_frames_65_127: 17124186 dev.igb.0.mac_stats.rx_frames_128_255: 5804200 dev.igb.0.mac_stats.rx_frames_256_511: 7252691 dev.igb.0.mac_stats.rx_frames_512_1023: 6689701 dev.igb.0.mac_stats.rx_frames_1024_1522: 550313022 dev.igb.0.mac_stats.good_octets_recvd: 856818703481 dev.igb.0.mac_stats.good_octets_txd: 59929870623 dev.igb.0.mac_stats.total_pkts_txd: 872538069 dev.igb.0.mac_stats.good_pkts_txd: 872538069 dev.igb.0.mac_stats.bcast_pkts_txd: 3913 dev.igb.0.mac_stats.tx_frames_64: 834225325 dev.igb.0.mac_stats.tx_frames_65_127: 25282920 dev.igb.0.mac_stats.tx_frames_256_511: 13029824 dev.igb.0.interrupts.asserts: 1276620451 dev.igb.0.interrupts.rx_pkt_timer: 808744060 dev.igb.0.interrupts.tx_queue_empty: 872532141 dev.igb.0.interrupts.tx_queue_min_thresh: 809033732 dev.igb.0.host.rx_pkt: 7738 dev.igb.0.host.tx_good_pkt: 5928 dev.igb.0.host.rx_good_bytes: 856818710661 dev.igb.0.host.tx_good_bytes: 59929870623 Over a 10s period, the following changes happens: dev.igb.0.mac_stats.tx_frames_64: 834225325 dev.igb.0.mac_stats.tx_frames_65_127: 25282920 dev.igb.0.mac_stats.tx_frames_256_511: 13029824 -dev.igb.0.interrupts.asserts: 1276621739 +dev.igb.0.interrupts.asserts: 1276621819 dev.igb.0.interrupts.rx_pkt_timer: 808744060 dev.igb.0.interrupts.tx_queue_empty: 872532141 -dev.igb.0.interrupts.tx_queue_min_thresh: 809034668 +dev.igb.0.interrupts.tx_queue_min_thresh: 809034719 dev.igb.0.host.rx_pkt: 7738 dev.igb.0.host.tx_good_pkt: 5928 dev.igb.0.host.rx_good_bytes: 856818710661 Moreover, igb3 is not showing any `missed_packets' Here is relevant dmesg(8) except: igb0: port 0xb880-0xb89f mem 0xfb980000-0xfb9fffff,0xfba78000-0xfba7bfff irq 16 at device 0.0 on pci6 igb0: Using MSIX interrupts with 9 vectors igb0: [ITHREAD] [...] igb0: Ethernet address: 00:90:0b:1e:df:f0 igb1: port 0xbc00-0xbc1f mem 0xfba80000-0xfbafffff,0xfba7c000-0xfba7ffff irq 17 at device 0.1 on pci6 igb1: Using MSIX interrupts with 9 vectors igb1: [ITHREAD] [...] igb1: Ethernet address: 00:90:0b:1e:df:f1 igb2: port 0xc880-0xc89f mem 0xfbb80000-0xfbbfffff,0xfbc78000-0xfbc7bfff irq 16 at device 0.0 on pci7 igb2: Using MSIX interrupts with 9 vectors igb2: [ITHREAD] [...] igb2: Ethernet address: 00:90:0b:1e:df:f2 igb3: port 0xcc00-0xcc1f mem 0xfbc80000-0xfbcfffff,0xfbc7c000-0xfbc7ffff irq 17 at device 0.1 on pci7 igb3: Using MSIX interrupts with 9 vectors igb3: [ITHREAD] [...] as well as pciconf(8): igb0@pci0:6:0:0: class=0x020000 card=0x00008086 chip=0x150e8086 rev=0x01 hdr=0x00 igb1@pci0:6:0:1: class=0x020000 card=0x00008086 chip=0x150e8086 rev=0x01 hdr=0x00 igb2@pci0:7:0:0: class=0x020000 card=0x00008086 chip=0x150e8086 rev=0x01 hdr=0x00 igb3@pci0:7:0:1: class=0x020000 card=0x00008086 chip=0x150e8086 rev=0x01 hdr=0x00 So why would vmstat show such an high interrupt rate on idle interfaces ? Thanks, - Arnaud From owner-freebsd-net@FreeBSD.ORG Fri May 4 21:32:45 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3E79F1065675; Fri, 4 May 2012 21:32:45 +0000 (UTC) (envelope-from sendtomatt@gmail.com) Received: from mail-pz0-f48.google.com (mail-pz0-f48.google.com [209.85.210.48]) by mx1.freebsd.org (Postfix) with ESMTP id E6A548FC1F; Fri, 4 May 2012 21:32:44 +0000 (UTC) Received: by dadz8 with SMTP id z8so507011dad.7 for ; Fri, 04 May 2012 14:32:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=zggD3QEw5AqCQByY3MCF5NGF1g2mcoBnbpOX7UYmhuQ=; b=muehpCr+5fr4zzwWVAoblxruzmjfPpxAy9hytAQy9ePH28mdEka/bTX8RNUQc5FbQ5 99MODjb31PRrIQOfxgOZy5wPopgp3qB4LhYwhrcvig3SnsOOz80DmP0XVnDTltj6qI3V GL+9Eucjpc3gVYVVugYFBN8yWovttxebwV6Cpp4QAzKtuH0BRqWG9TjkR/hwcZ3cZPYo wwUbxWm7FyqOvrWb2mlk+Gy1nwwtLiTH8V/wud8VvlNhJGoUsE/UQHi1GMFoHt07muwn cBP+i9Fl6mdB2Fl/R5q6Ba/YXEbQsa/sp8cereg9Y64FWkiXV6WPnS7S2O1PVLFeUmUD rrSw== Received: by 10.68.129.98 with SMTP id nv2mr22402036pbb.140.1336167164766; Fri, 04 May 2012 14:32:44 -0700 (PDT) Received: from flatline.local (70-36-223-239.dsl.dynamic.sonic.net. [70.36.223.239]) by mx.google.com with ESMTPS id vl10sm9704488pbc.37.2012.05.04.14.32.42 (version=SSLv3 cipher=OTHER); Fri, 04 May 2012 14:32:43 -0700 (PDT) Message-ID: <4FA44AEB.4050704@gmail.com> Date: Fri, 04 May 2012 14:32:27 -0700 From: matt User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:11.0) Gecko/20120422 Thunderbird/11.0.1 MIME-Version: 1.0 To: Adrian Chadd References: <201205031853.53102.bschmidt@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, freebsd-wireless@freebsd.org, freebsd-current@freebsd.org, Bernhard Schmidt Subject: Re: [CFT] Ralink RT2860, RT2870, RT3060, RT3090 support 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, 04 May 2012 21:32:45 -0000 On 05/03/12 11:18, Adrian Chadd wrote: > Hi, > > First off, let me say "thankyou" to you, ray@ and all the people who > have chipped away at this little problem. I look very forward to > having rt2xxx 802.11n support, as do many users on the forums. :) > > I haven't yet done a pass or two to see what the state of the > locking/concurrency handling is. Don't let that stop you from > committing it though, I'm sure we can find/fix whatever issues creep > up post-commit. > > Thanks again! > > > > Adrian > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > Thanks Bernhard! I'm sure there are many people with this chipset that are going to be very happy. It's good that we have something homegrown as well. I'll try to test it this weekend on my rt3090. Matt From owner-freebsd-net@FreeBSD.ORG Fri May 4 21:54:08 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 70F81106566B for ; Fri, 4 May 2012 21:54:08 +0000 (UTC) (envelope-from hapvbk@yahoo.co.uk) Received: from nm25-vm1.bullet.mail.ird.yahoo.com (nm25-vm1.bullet.mail.ird.yahoo.com [212.82.109.202]) by mx1.freebsd.org (Postfix) with SMTP id D47AE8FC1B for ; Fri, 4 May 2012 21:54:07 +0000 (UTC) Received: from [77.238.189.53] by nm25.bullet.mail.ird.yahoo.com with NNFMP; 04 May 2012 21:54:01 -0000 Received: from [212.82.108.237] by tm6.bullet.mail.ird.yahoo.com with NNFMP; 04 May 2012 21:54:01 -0000 Received: from [127.0.0.1] by omp1002.mail.ird.yahoo.com with NNFMP; 04 May 2012 21:54:01 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 240749.88472.bm@omp1002.mail.ird.yahoo.com Received: (qmail 88644 invoked by uid 60001); 4 May 2012 21:54:01 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.uk; s=s1024; t=1336168441; bh=b06bLCjSgTTKVqi/4WmCMbu2JJ+MNH+nvgpL+EEYci8=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=NlQxH2L+IaaeWUvyL5t1iQ+oZzEPmmQN/NSBEDbUm3a7Dt8eE2KLUePHxfEsAKb3a7HmOC9J+mW4fn57rBGxnOQB18ca7VbQeZa1JTRdFRkPUCFfUpcCf99aPiot4in8uINllQ//dVuw9qH4qfdL/YWxiqtw8ThDKQqyFvkkiJ0= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.uk; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=zI7Kbs0gJxobByMK+Y7pH6IYa4lPNh3pDkEjAcInL2fss7g5KTi2nC0qjY1C9dhdqY88IBMmDNXQcp36bSDXAVA5nN0UsVLmWODM5+fFSciZSkWq9Nujimj7SV7Ugz75p8j9771Ure11KALBj7li3gtE0bCmooEWtjFhaYmJaS8=; X-YMail-OSG: khLTNc0VM1nvoNLpY4oELAFnzzX02Z3QMgYpIg2P1X1S9k_ npQCFSB6Img2iLFpJaDgKBfrh3BAoLhfKl3qMbRwcT1xxW6noU_bRY_rhb6V b7j77FJBZRlWGYO6y.g8Q66WVCd_v3RJR8mQRZmX_WHe.UY1H6EucUOdiKPY tMqHLjOKEW9oxHnJ5.2Y8ryhqBo4wBXN5wW.lKC4dK26uWonr09_jeRdq2Aq cK6mXsh2D9Itro18X8tNspMF_dDNFyS2uRQNZmmPq.kPsRTJyNUBLw1Z0Lun Qov5Pve5zPt9uFRaE0GMw9f.dPYfgWabkmyUMgVHX5AfkeWF1ZgzmtpSmgRj 5UhU5x0J.7ALNzCl5ODTvDb_GeXD7Xh5QR9fxFwZHrFo8ua_fvV.qLN8.wec IcKIZHiMvXoxH8.eXUWXC8GlnyXPBNl1Z7CY- Received: from [204.138.59.246] by web28805.mail.ir2.yahoo.com via HTTP; Fri, 04 May 2012 22:54:00 BST X-Mailer: YahooMailWebService/0.8.117.340979 References: <1336168076.28222.YahooMailNeo@web28802.mail.ir2.yahoo.com> Message-ID: <1336168440.88161.YahooMailNeo@web28805.mail.ir2.yahoo.com> Date: Fri, 4 May 2012 22:54:00 +0100 (BST) From: Pham Viet Ha To: "net@freebsd.org" , "freebsd-net@freebsd.org" In-Reply-To: <1336168076.28222.YahooMailNeo@web28802.mail.ir2.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: sysctl command with struct X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Pham Viet Ha List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 21:54:08 -0000 Hi all,=0A=0AI am writing a code using sysctl to manipulate a kernel variab= le. The variable is a data structure with two fields, protocol number (uint= 16_t) and description (char *).=0A=0AI have some difficulties with sysctl c= ommand to pass both protocol number and description at a time to the kernel= . I used CTLTYPE_OPAQUE in SYSCTL_ADD_PROC call, then I used=A0sysctl_handl= e_opaque to read data.=A0=0A=0AIt does not work correctly. I don't know how= what is the format I have to use when I type in "sysctl ..." at the prompt= .=A0=0A=0Astruct protodesc {=A0=0Auint16_t protonumber;=A0=0Achar descripti= on[256];=0A}Add the proc:=A0=0A=0ASYSCTL_ADD_PROC(&ctx, SYSCTL_CHILDREN(tre= e_oidp), OID_AUTO,=0A =A0 =A0"protodesc", CTLTYPE_OPAQUE | CTLFLAG_RW, 0, 0= ,=0A =A0 =A0sysctl_protodesc_update, "S,protodesc",=0A =A0 =A0"To update pr= otocol and description");=0A=0AIn=A0sysctl_protodesc_update, a call to=A0sy= sctl_handle_opaque:=A0=0A=0Aerror =3D sysctl_handle_opaque(oidp, &entry, si= zeof entry, req);=0A=0Aentry is of type protodesc.=A0=0A=0ACompilation and = running both ok. The only issue is that I cannot type in the values for pro= todesc at sysctl command. I don't know what the format is.=A0=0AError messa= ge:=A0sysctl: oid 'protodesc' is type 5, cannot set that.=A0=0A=0A=0AThanks= for any help.=A0=0A=0AP/S: I sent an=A0incomplete=A0email by accident. Sor= ry for that.=A0=0A=0AHAPVBK From owner-freebsd-net@FreeBSD.ORG Fri May 4 21:54:08 2012 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 8ACAC106566C for ; Fri, 4 May 2012 21:54:08 +0000 (UTC) (envelope-from hapvbk@yahoo.co.uk) Received: from nm5.bullet.mail.ird.yahoo.com (nm5.bullet.mail.ird.yahoo.com [77.238.189.62]) by mx1.freebsd.org (Postfix) with SMTP id B9DB88FC19 for ; Fri, 4 May 2012 21:54:07 +0000 (UTC) Received: from [77.238.189.50] by nm5.bullet.mail.ird.yahoo.com with NNFMP; 04 May 2012 21:54:01 -0000 Received: from [212.82.108.237] by tm3.bullet.mail.ird.yahoo.com with NNFMP; 04 May 2012 21:54:01 -0000 Received: from [127.0.0.1] by omp1002.mail.ird.yahoo.com with NNFMP; 04 May 2012 21:54:01 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 340527.71671.bm@omp1002.mail.ird.yahoo.com Received: (qmail 88644 invoked by uid 60001); 4 May 2012 21:54:01 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.uk; s=s1024; t=1336168441; bh=b06bLCjSgTTKVqi/4WmCMbu2JJ+MNH+nvgpL+EEYci8=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=NlQxH2L+IaaeWUvyL5t1iQ+oZzEPmmQN/NSBEDbUm3a7Dt8eE2KLUePHxfEsAKb3a7HmOC9J+mW4fn57rBGxnOQB18ca7VbQeZa1JTRdFRkPUCFfUpcCf99aPiot4in8uINllQ//dVuw9qH4qfdL/YWxiqtw8ThDKQqyFvkkiJ0= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.uk; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=zI7Kbs0gJxobByMK+Y7pH6IYa4lPNh3pDkEjAcInL2fss7g5KTi2nC0qjY1C9dhdqY88IBMmDNXQcp36bSDXAVA5nN0UsVLmWODM5+fFSciZSkWq9Nujimj7SV7Ugz75p8j9771Ure11KALBj7li3gtE0bCmooEWtjFhaYmJaS8=; X-YMail-OSG: khLTNc0VM1nvoNLpY4oELAFnzzX02Z3QMgYpIg2P1X1S9k_ npQCFSB6Img2iLFpJaDgKBfrh3BAoLhfKl3qMbRwcT1xxW6noU_bRY_rhb6V b7j77FJBZRlWGYO6y.g8Q66WVCd_v3RJR8mQRZmX_WHe.UY1H6EucUOdiKPY tMqHLjOKEW9oxHnJ5.2Y8ryhqBo4wBXN5wW.lKC4dK26uWonr09_jeRdq2Aq cK6mXsh2D9Itro18X8tNspMF_dDNFyS2uRQNZmmPq.kPsRTJyNUBLw1Z0Lun Qov5Pve5zPt9uFRaE0GMw9f.dPYfgWabkmyUMgVHX5AfkeWF1ZgzmtpSmgRj 5UhU5x0J.7ALNzCl5ODTvDb_GeXD7Xh5QR9fxFwZHrFo8ua_fvV.qLN8.wec IcKIZHiMvXoxH8.eXUWXC8GlnyXPBNl1Z7CY- Received: from [204.138.59.246] by web28805.mail.ir2.yahoo.com via HTTP; Fri, 04 May 2012 22:54:00 BST X-Mailer: YahooMailWebService/0.8.117.340979 References: <1336168076.28222.YahooMailNeo@web28802.mail.ir2.yahoo.com> Message-ID: <1336168440.88161.YahooMailNeo@web28805.mail.ir2.yahoo.com> Date: Fri, 4 May 2012 22:54:00 +0100 (BST) From: Pham Viet Ha To: "net@freebsd.org" , "freebsd-net@freebsd.org" In-Reply-To: <1336168076.28222.YahooMailNeo@web28802.mail.ir2.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: sysctl command with struct X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Pham Viet Ha List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 21:54:08 -0000 Hi all,=0A=0AI am writing a code using sysctl to manipulate a kernel variab= le. The variable is a data structure with two fields, protocol number (uint= 16_t) and description (char *).=0A=0AI have some difficulties with sysctl c= ommand to pass both protocol number and description at a time to the kernel= . I used CTLTYPE_OPAQUE in SYSCTL_ADD_PROC call, then I used=A0sysctl_handl= e_opaque to read data.=A0=0A=0AIt does not work correctly. I don't know how= what is the format I have to use when I type in "sysctl ..." at the prompt= .=A0=0A=0Astruct protodesc {=A0=0Auint16_t protonumber;=A0=0Achar descripti= on[256];=0A}Add the proc:=A0=0A=0ASYSCTL_ADD_PROC(&ctx, SYSCTL_CHILDREN(tre= e_oidp), OID_AUTO,=0A =A0 =A0"protodesc", CTLTYPE_OPAQUE | CTLFLAG_RW, 0, 0= ,=0A =A0 =A0sysctl_protodesc_update, "S,protodesc",=0A =A0 =A0"To update pr= otocol and description");=0A=0AIn=A0sysctl_protodesc_update, a call to=A0sy= sctl_handle_opaque:=A0=0A=0Aerror =3D sysctl_handle_opaque(oidp, &entry, si= zeof entry, req);=0A=0Aentry is of type protodesc.=A0=0A=0ACompilation and = running both ok. The only issue is that I cannot type in the values for pro= todesc at sysctl command. I don't know what the format is.=A0=0AError messa= ge:=A0sysctl: oid 'protodesc' is type 5, cannot set that.=A0=0A=0A=0AThanks= for any help.=A0=0A=0AP/S: I sent an=A0incomplete=A0email by accident. Sor= ry for that.=A0=0A=0AHAPVBK From owner-freebsd-net@FreeBSD.ORG Fri May 4 21:47:58 2012 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 8C963106564A for ; Fri, 4 May 2012 21:47:58 +0000 (UTC) (envelope-from hapvbk@yahoo.co.uk) Received: from nm7-vm0.bullet.mail.ird.yahoo.com (nm7-vm0.bullet.mail.ird.yahoo.com [77.238.189.222]) by mx1.freebsd.org (Postfix) with SMTP id CEB1D8FC08 for ; Fri, 4 May 2012 21:47:57 +0000 (UTC) Received: from [77.238.189.53] by nm7.bullet.mail.ird.yahoo.com with NNFMP; 04 May 2012 21:47:56 -0000 Received: from [212.82.108.247] by tm6.bullet.mail.ird.yahoo.com with NNFMP; 04 May 2012 21:47:56 -0000 Received: from [127.0.0.1] by omp1012.mail.ird.yahoo.com with NNFMP; 04 May 2012 21:47:56 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 696828.35002.bm@omp1012.mail.ird.yahoo.com Received: (qmail 41105 invoked by uid 60001); 4 May 2012 21:47:56 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.uk; s=s1024; t=1336168076; bh=sZ7J9Imdroh2RhH72KpKmNjUy/tr1BBg5S6RbMvh9FY=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=EouST/7CoqQkZEOIM/VT5Ye7HGXSUnk4ANTjyneV4K5JIpflTWjgRWaPcP45oDenpo9AQ3NNJS12E3LH1Yb64canJRUHk3XuvOGGdo++OpC4y5wTkQvU9aylnO6lSNTP+sAsNXCj/o+vIwy6hh6FFRMdsPLGDJHMMZka46eifVk= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.uk; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=RVh/y8tk3crZDLCu0ctVI+D5Hu0UxNJEXLyThndvbFZTqh3QiWOHwqp3dub6qTcQb1RH6pXZGq6tULyZxQpPJI7cM00YoeE4YxyMjIeeP36aB7CcurMgmym4QgVfrU/jQvCfAwenxQgUWva3cAYDwehcrRCu3goyT37y6PKMm5o=; X-YMail-OSG: oPItnFwVM1lwIgaj3uh5Rttq907UHgVxU4r.nW84knQHuts opl0xEkylqdxclLVokDEf02MGrvehu0g6dgVHpuCUqCWDEylH5qMxzI9RXLn MT6rAN9JSdN0FL49LRgF0xJPflcNq7zfJ.lgFtvRYasrqk4LVe7ZeMvqHFVt KALvuyCrbYpFGLgj1Dq.U74FUJXVrEa6oA7YbZu0ULqUZlvZtnDjonOU7dNa T6KhRJggYiu4hO52x7HmTrVVTk3FCWy6KVgb3JmtAdKodpPI7Qe7rPuY2HJD rQO.5H8ZVHQ__4QC7Su15rzv05IbJPe4rrE1eKcuzq6LlqJCrYJEd0ugZYvm hl0Bhtt1MVpxr6kTXgC_iukfezteRkIlU2O_t_8jBuMQOMuppgNEk4PtRkki kobssclbPiayyVuCZ067CdTOzNZWiEyJQEJI- Received: from [204.138.59.246] by web28802.mail.ir2.yahoo.com via HTTP; Fri, 04 May 2012 22:47:56 BST X-Mailer: YahooMailWebService/0.8.117.340979 Message-ID: <1336168076.28222.YahooMailNeo@web28802.mail.ir2.yahoo.com> Date: Fri, 4 May 2012 22:47:56 +0100 (BST) From: Pham Viet Ha To: "net@freebsd.org" , "freebsd-net@freebsd.org" MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 04 May 2012 22:06:56 +0000 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: sysctl command with struct X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Pham Viet Ha List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 21:47:58 -0000 Hi all,=0A=0AI am writing a code using sysctl to manipulate a kernel variab= le. The variable is a data structure with two fields, protocol number (uint= 16_t) and description (char *).=0A=0AI have some difficulties with sysctl c= ommand to pass both protocol number and description at a time to the kernel= . I used CTLTYPE_OPAQUE in SYSCTL_ADD_PROC call, then I used=A0sysctl_handl= e_opaque to read data.=A0=0A=0AIt does not work correctly. I don't know how= what is the format I have to use when I type in "sysctl ..." at the prompt= .=A0=0A=0Astruct protodesc {=A0=0Auint16_t protonumber;=A0=0Achar descripti= on[256];=0A} From owner-freebsd-net@FreeBSD.ORG Fri May 4 21:48:04 2012 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 6D2551065742 for ; Fri, 4 May 2012 21:48:04 +0000 (UTC) (envelope-from hapvbk@yahoo.co.uk) Received: from nm10-vm0.bullet.mail.ird.yahoo.com (nm10-vm0.bullet.mail.ird.yahoo.com [77.238.189.90]) by mx1.freebsd.org (Postfix) with SMTP id B0DF28FC19 for ; Fri, 4 May 2012 21:48:03 +0000 (UTC) Received: from [77.238.189.56] by nm10.bullet.mail.ird.yahoo.com with NNFMP; 04 May 2012 21:47:56 -0000 Received: from [212.82.108.254] by tm9.bullet.mail.ird.yahoo.com with NNFMP; 04 May 2012 21:47:56 -0000 Received: from [127.0.0.1] by omp1019.mail.ird.yahoo.com with NNFMP; 04 May 2012 21:47:56 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 696897.18508.bm@omp1019.mail.ird.yahoo.com Received: (qmail 41105 invoked by uid 60001); 4 May 2012 21:47:56 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.uk; s=s1024; t=1336168076; bh=sZ7J9Imdroh2RhH72KpKmNjUy/tr1BBg5S6RbMvh9FY=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=EouST/7CoqQkZEOIM/VT5Ye7HGXSUnk4ANTjyneV4K5JIpflTWjgRWaPcP45oDenpo9AQ3NNJS12E3LH1Yb64canJRUHk3XuvOGGdo++OpC4y5wTkQvU9aylnO6lSNTP+sAsNXCj/o+vIwy6hh6FFRMdsPLGDJHMMZka46eifVk= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.uk; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=RVh/y8tk3crZDLCu0ctVI+D5Hu0UxNJEXLyThndvbFZTqh3QiWOHwqp3dub6qTcQb1RH6pXZGq6tULyZxQpPJI7cM00YoeE4YxyMjIeeP36aB7CcurMgmym4QgVfrU/jQvCfAwenxQgUWva3cAYDwehcrRCu3goyT37y6PKMm5o=; X-YMail-OSG: oPItnFwVM1lwIgaj3uh5Rttq907UHgVxU4r.nW84knQHuts opl0xEkylqdxclLVokDEf02MGrvehu0g6dgVHpuCUqCWDEylH5qMxzI9RXLn MT6rAN9JSdN0FL49LRgF0xJPflcNq7zfJ.lgFtvRYasrqk4LVe7ZeMvqHFVt KALvuyCrbYpFGLgj1Dq.U74FUJXVrEa6oA7YbZu0ULqUZlvZtnDjonOU7dNa T6KhRJggYiu4hO52x7HmTrVVTk3FCWy6KVgb3JmtAdKodpPI7Qe7rPuY2HJD rQO.5H8ZVHQ__4QC7Su15rzv05IbJPe4rrE1eKcuzq6LlqJCrYJEd0ugZYvm hl0Bhtt1MVpxr6kTXgC_iukfezteRkIlU2O_t_8jBuMQOMuppgNEk4PtRkki kobssclbPiayyVuCZ067CdTOzNZWiEyJQEJI- Received: from [204.138.59.246] by web28802.mail.ir2.yahoo.com via HTTP; Fri, 04 May 2012 22:47:56 BST X-Mailer: YahooMailWebService/0.8.117.340979 Message-ID: <1336168076.28222.YahooMailNeo@web28802.mail.ir2.yahoo.com> Date: Fri, 4 May 2012 22:47:56 +0100 (BST) From: Pham Viet Ha To: "net@freebsd.org" , "freebsd-net@freebsd.org" MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 04 May 2012 22:14:01 +0000 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: sysctl command with struct X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Pham Viet Ha List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 21:48:04 -0000 Hi all,=0A=0AI am writing a code using sysctl to manipulate a kernel variab= le. The variable is a data structure with two fields, protocol number (uint= 16_t) and description (char *).=0A=0AI have some difficulties with sysctl c= ommand to pass both protocol number and description at a time to the kernel= . I used CTLTYPE_OPAQUE in SYSCTL_ADD_PROC call, then I used=A0sysctl_handl= e_opaque to read data.=A0=0A=0AIt does not work correctly. I don't know how= what is the format I have to use when I type in "sysctl ..." at the prompt= .=A0=0A=0Astruct protodesc {=A0=0Auint16_t protonumber;=A0=0Achar descripti= on[256];=0A} From owner-freebsd-net@FreeBSD.ORG Fri May 4 22:18:43 2012 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 6B4511065674; Fri, 4 May 2012 22:18:43 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 05E3F8FC1B; Fri, 4 May 2012 22:18:41 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q44MIJ9e098946; Sat, 5 May 2012 01:18:19 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q44MIJsg072764; Sat, 5 May 2012 01:18:19 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q44MIJWx072763; Sat, 5 May 2012 01:18:19 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 5 May 2012 01:18:19 +0300 From: Konstantin Belousov To: John Baldwin Message-ID: <20120504221819.GS2358@deviant.kiev.zoral.com.ua> References: <20120407133715.GU2358@deviant.kiev.zoral.com.ua> <20120412183849.GA2358@deviant.kiev.zoral.com.ua> <20120501162121.GV2358@deviant.kiev.zoral.com.ua> <201205041130.22202.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8ylr9W9WlK4vAZcY" Content-Disposition: inline In-Reply-To: <201205041130.22202.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: jfv@freebsd.org, Jack Vogel , net@freebsd.org Subject: Re: 82574L hangs (with r233708 e1000 driver). X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 22:18:43 -0000 --8ylr9W9WlK4vAZcY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, May 04, 2012 at 11:30:22AM -0400, John Baldwin wrote: > On Tuesday, May 01, 2012 12:21:21 pm Konstantin Belousov wrote: > > On Thu, Apr 12, 2012 at 09:38:49PM +0300, Konstantin Belousov wrote: > > > On Mon, Apr 09, 2012 at 12:19:39PM -0400, John Baldwin wrote: > > > > On Sunday, April 08, 2012 1:11:25 am Konstantin Belousov wrote: > > > > > On Sat, Apr 07, 2012 at 04:22:07PM -0700, Jack Vogel wrote: > > > > > > Make sure you have any firmware up to the latest available, if = that=20 > doesn't > > > > > > help > > > > > > let me know and I'll check internally to see if there are any= =20 > outstanding > > > > > > issues > > > > > > in shared code, that will be after the weekend. > > > > >=20 > > > > > I had BIOS rev. 151, after you hint I found rev. 154 on the site. > > > > > Now BIOS reports itself as MTCDT10N.86A.0154.2012.0323.1601, > > > > > March 23. > > > > >=20 > > > > > Unfortunately, upgrade did not changed anything in regard of hang= ing > > > > > interface. > > > >=20 > > > > Does reverting 233708 make any difference? Have you tried futzing= =20 > around with > > > > kgdb when it is hung to see what state the device is in (software s= tate=20 > at > > > > least)? > > > It does, in a sense that without r233708 the interface becomes stuck > > > almost immediately. I just upgraded to the e1000@r234154, which does = not > > > change much. > > >=20 > > > I fiddled with the adapter state after the hang in kgdb more, and I > > > noted something interesting. Apparently, tx works. When I ping the re= mote > > > host from my suffering atom machine, remote host sees the packet. Also > > > remote machine sees some udp traffic originating from the tom, like > > > ntp queries. > > >=20 > > > And, on receive, the atom board does receive interrupts, em0:rx 0 cou= nter > > > in vmstat -i increases. Even more fun, the sysctl dev.em.0.debug > > > shows increasing hw rdh (as I understand, this is hardware 'last > > > received' packet pointer for rx ring). So I looked at the packet > > > descriptor at hw rdt index, and there I see > > > (kgdb) p/x ((struct adapter *)0xffffff80010e4000)->rx_rings->rx_base[= 78] > > > $11 =3D {buffer_addr =3D 0x12a128800, length =3D 0x5ea, csum =3D 0x3c= 2b, status =3D=20 > 0x0,=20 > > > errors =3D 0x0, special =3D 0x0} > > >=20 > > > Apparently, the Descriptor Done bit is clear, so the em_rxeof() funct= ion > > > breaks from the loop, not consuming the current packet. Also, it retu= rns > > > false due to DD bit clear. This prevents em_msix_rx() from scheduling > > > taskqueue for processing. So apparent cause for the hang is missing > > > DD bit in descriptor. > > >=20 > > > I am not sure isn't all this is obvious for anybody who knows em > > > internals, and were to go from there. > >=20 > > Ok, nobody cares. > >=20 > > Below is the workaround I use to prevent the interface wedging. > > It seems that the sole PCI register read (namely, the rx ring head read) > > and consequent recheck of the descriptor status greatly reduce the > > likelihood of the issue. Unfortunately, the read does not eliminate > > the hang completely. So it is not some PCIe coherency problem. > >=20 > > With the patch applied, I am able to copy around blu-ray images, while > > previously the interface hang in 20-30 seconds of 100Mbit/s traffic. > > Sometimes the messages are printed: > > em0: Workaround: head 1018 tail 1002 cur 1010 > > em0: Workaround: head 976 tail 973 cur 974 > > em0: Workaround: head 950 tail 939 cur 946 > > em0: Workaround: head 435 tail 419 cur 426 > >=20 > > Machine is still dead due to random memory corruption which I see, in > > particular, pmap sometimes read garbage from PTEs. I have no idea is > > it related to em0 rx descriptor missed writes, or is a different issue. >=20 > Humm, so if I'm reading this correctly, the card "skips" a receive > descriptor and stores a packet at the next descriptor? That's just > bizarre. Either this, or it does store the packet but 'forgots' to update the rx descriptor. I think that your interpretation is closer to reality, since I get sustained 20MB/s over ssh with the patch even when workaround activates. The lost packets probably should cause retransmit and speed drop. --8ylr9W9WlK4vAZcY Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk+kVasACgkQC3+MBN1Mb4hPbwCcDdHBGIRE0+uA2741UcfkB7bq 7GQAoMNWi9F2EfiEd2yoQ2ySz695yvAF =0K+1 -----END PGP SIGNATURE----- --8ylr9W9WlK4vAZcY-- From owner-freebsd-net@FreeBSD.ORG Sat May 5 07:52:25 2012 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 CE55D1065670; Sat, 5 May 2012 07:52:25 +0000 (UTC) (envelope-from sergey.dyatko@gmail.com) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id B319E8FC19; Sat, 5 May 2012 07:52:24 +0000 (UTC) Received: by lagv3 with SMTP id v3so3420193lag.13 for ; Sat, 05 May 2012 00:52:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type:content-transfer-encoding; bh=qxzOG88O09Rw0uIYmbe6GAC9o/g+baizR/erIdU0Dhg=; b=Ivz0Oy59KtB/6WhDowUHOB9hMzjBByf1/c0MHUaOLrwJkVXNnNI/mImjYsy0XBFySx VXaUVux+/SxU+j3Qkh9RzSXSxdKl6+4hcvLBpVrSo0hBsXnSs1BTR+7onDa4iErsxkQx 0CF7xv8Gf2vSHbK+N2KDIQz5opZ5UUXoVrwilLlO4wBbfDQ6vWD3MdHE6PCA0SUn3IkW iiTU6ZDYfAWUAsjgqGPqD0h6itmX+wpkTWpINbhv59ynHXBCNqK/T+gqK8iSnYDR24Jd E85B/9PPYFs2Zn73Hfot8E2rUsuaDfGoYbPgU8B98yjgWw0lHvl5EuOrW2SKCVhnv39U 4ZCw== Received: by 10.152.130.138 with SMTP id oe10mr1291853lab.5.1336204343379; Sat, 05 May 2012 00:52:23 -0700 (PDT) Received: from laptop (m-s.agava.net. [195.222.84.203]) by mx.google.com with ESMTPS id pv14sm11607341lab.2.2012.05.05.00.52.20 (version=SSLv3 cipher=OTHER); Sat, 05 May 2012 00:52:21 -0700 (PDT) Date: Sat, 5 May 2012 10:52:58 +0300 From: "Sergey V. Dyatko" To: Bernhard Schmidt Message-ID: <20120505105258.28e28803@laptop> In-Reply-To: <201205031853.53102.bschmidt@freebsd.org> References: <201205031853.53102.bschmidt@freebsd.org> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.6; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, freebsd-wireless@freebsd.org, freebsd-current@freebsd.org Subject: Re: [CFT] Ralink RT2860, RT2870, RT3060, RT3090 support 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, 05 May 2012 07:52:25 -0000 On Thu, 3 May 2012 18:53:52 +0200 Bernhard Schmidt wrote: > Hi folks, > > As some of you might know there has been some work going on porting > support for new Ralink chipsets from OpenBSD. Several different > drivers where floating around but nothing seemed to be decent enough > to be committed. ray@ and I had been working on cleaning up one of > those to get it into a good enough shape, but abandoned this approach > as it resulted in more work than starting from scratch. > > So, attached diff [1] is a from-scratch effort to port over support > for the new chipsets. It doesn't contain fancy stuff like 802.11n > support as of yet (this will be worked one once the legacy stuff is > in HEAD), nonetheless it showed pretty decent performance during the > basic sta/adhoc/hostap tests I've done. > > I'd appreciate testing and feedback ;) > at 1st I would say 'Thank You' for all people who working on this :) patch, make, make install, kldload: http://tiger.ipfw.ru/files/rt2860_3090.txt this is FreeBSD 10.0-CURRENT, r234992M: Fri May 4 11:25:53 FET 2012 from time to time on messages: May 5 10:32:47 laptop kernel: ral0: device timeout May 5 10:37:49 laptop kernel: ral0: device timeout May 5 10:42:50 laptop kernel: ral0: device timeout LED... is just glowing, rarely blinks. With patch from Alexander (ray@) it doesn't work [tiger@laptop]~%scp tiger:/storage/FreeBSD-8.2-RELEASE-amd64-dvd1.iso . FreeBSD-8.2-RELEASE-amd64-dvd1.iso 11% 271MB 1.9MB/s 18:19 ETA ^C Killed by signal 2. where 'tiger' is my desktop > The diff requires HEAD due to the firmware being available only there, > though, if there are enough requests, I might consider looking into > getting it merged to 9. (Simply pulling sys/modules/ralfw/ and > sys/contrib/dev/ral/ from HEAD might be enough I guess.) > > [1] http://techwires.net/~bschmidt/rt2860.diff > -- wbr, tiger From owner-freebsd-net@FreeBSD.ORG Sat May 5 08:24:23 2012 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 A99AC106566C for ; Sat, 5 May 2012 08:24:23 +0000 (UTC) (envelope-from bschmidt@techwires.net) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 305BB8FC17 for ; Sat, 5 May 2012 08:24:23 +0000 (UTC) Received: by weyt57 with SMTP id t57so2936682wey.13 for ; Sat, 05 May 2012 01:24:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id :x-gm-message-state; bh=7zI+MozWr2PwNC6S/D+rWBKo3+Vgtldt8Dyl8hUleGY=; b=aWtaC9BWTuriUsYS8SS35XBB6+E9A/DqqzLLRZqs7dDXP+uQW96PFpJqkViGdulyUa hv2qwz0QfmzlkEFbSkidUHZiEgeYV17v6bZ/ph1QHlJluSKgr7bPaQGxIl0nTmfSX0H+ p6uUgJF4t3iH8ZM1IRJmljDItXeJ+Ne2cxQbYwz5RqmEt/SyOD219bIYoGpHfEmYds4l QARJs1aezkm4hLQ9WC1jRvRFbB4sDPsn35f6vUTdtDFM64GKAbS9mGp1EjhywSlvaZQU HIOnE6ir8zgj1VED3UwO9GvLFxvUPOviJhl116eQfEneyTXyQUjE4NMhcmXHG2byYMcW 9n7w== Received: by 10.180.83.198 with SMTP id s6mr19630574wiy.8.1336206261373; Sat, 05 May 2012 01:24:21 -0700 (PDT) Received: from amy.lab.techwires.net (dslb-088-067-196-237.pools.arcor-ip.net. [88.67.196.237]) by mx.google.com with ESMTPS id ca3sm3711961wib.6.2012.05.05.01.24.17 (version=SSLv3 cipher=OTHER); Sat, 05 May 2012 01:24:20 -0700 (PDT) Sender: Bernhard Schmidt From: Bernhard Schmidt To: "Sergey V. Dyatko" Date: Sat, 5 May 2012 10:24:40 +0200 User-Agent: KMail/1.13.7 (FreeBSD/9.0-STABLE; KDE/4.7.4; amd64; ; ) References: <201205031853.53102.bschmidt@freebsd.org> <20120505105258.28e28803@laptop> In-Reply-To: <20120505105258.28e28803@laptop> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201205051024.40771.bschmidt@freebsd.org> X-Gm-Message-State: ALoCoQkKl4t6VLc8RcvsQQG4qRhQawbsi183eJAnHlRXGlfEGQKUJlkwF0NuNkrQLIxuibJULbTW Cc: freebsd-net@freebsd.org, freebsd-wireless@freebsd.org, freebsd-current@freebsd.org Subject: Re: [CFT] Ralink RT2860, RT2870, RT3060, RT3090 support 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, 05 May 2012 08:24:23 -0000 On Saturday 05 May 2012 09:52:58 Sergey V. Dyatko wrote: > On Thu, 3 May 2012 18:53:52 +0200 > Bernhard Schmidt wrote: > > > Hi folks, > > > > As some of you might know there has been some work going on porting > > support for new Ralink chipsets from OpenBSD. Several different > > drivers where floating around but nothing seemed to be decent enough > > to be committed. ray@ and I had been working on cleaning up one of > > those to get it into a good enough shape, but abandoned this approach > > as it resulted in more work than starting from scratch. > > > > So, attached diff [1] is a from-scratch effort to port over support > > for the new chipsets. It doesn't contain fancy stuff like 802.11n > > support as of yet (this will be worked one once the legacy stuff is > > in HEAD), nonetheless it showed pretty decent performance during the > > basic sta/adhoc/hostap tests I've done. > > > > I'd appreciate testing and feedback ;) > > > at 1st I would say 'Thank You' for all people who working on this :) > > patch, make, make install, kldload: > http://tiger.ipfw.ru/files/rt2860_3090.txt > > this is FreeBSD 10.0-CURRENT, r234992M: Fri May 4 11:25:53 FET 2012 > from time to time on messages: > May 5 10:32:47 laptop kernel: ral0: device timeout > May 5 10:37:49 laptop kernel: ral0: device timeout > May 5 10:42:50 laptop kernel: ral0: device timeout That interval is fishy.. can you try do disable bgscan? ifconfig wlan0 -bgscan > LED... is just glowing, rarely blinks. With patch from Alexander (ray@) > it doesn't work > > [tiger@laptop]~%scp tiger:/storage/FreeBSD-8.2-RELEASE-amd64-dvd1.iso . > FreeBSD-8.2-RELEASE-amd64-dvd1.iso 11% > 271MB 1.9MB/s 18:19 ETA > ^C > Killed by signal 2. > where 'tiger' is my desktop > > > > The diff requires HEAD due to the firmware being available only there, > > though, if there are enough requests, I might consider looking into > > getting it merged to 9. (Simply pulling sys/modules/ralfw/ and > > sys/contrib/dev/ral/ from HEAD might be enough I guess.) > > > > [1] http://techwires.net/~bschmidt/rt2860.diff > > > > > > -- Bernhard From owner-freebsd-net@FreeBSD.ORG Sat May 5 10:50:48 2012 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 742E41065675 for ; Sat, 5 May 2012 10:50:48 +0000 (UTC) (envelope-from bschmidt@techwires.net) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id EDFD28FC0A for ; Sat, 5 May 2012 10:50:47 +0000 (UTC) Received: by weyt57 with SMTP id t57so2999141wey.13 for ; Sat, 05 May 2012 03:50:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:message-id:x-gm-message-state; bh=DpIyN1EJkG2dgQNSdc+pgi7Tv2Y632zQs4UDIGose9o=; b=V85dQfBSajHlmJecWdW3G5vejgoDAlM+eo152ErUBrA1uYAd7TtUGWNG4cAq1MK7hK PhFQQtqrChgb2Gv9dByekZoa2wsRZScIw4PXu0Lc5IG9Sg1gBWqEneOWoLdTEvnJtU3M 7b/6/Nd8+kUbE4oU/nN1+BZXT2iawMVABETHnQT4Djdo8WhaMGUFGmToA+BA1HnRsvSN L+9KdlIvNI9kgbbQq6MDxKmdkWALFX2hQOZmm8az+Gg3b/OQY4Fkal5STCL/qrHAFOGt LQ3XCUZCI/qcmEowtcCJL2K+K6Zxe5+uxkjvHXvc+9VKeRZQadGz4tbKLF0jifcFHOsJ nUWQ== Received: by 10.180.88.169 with SMTP id bh9mr16806914wib.5.1336215046881; Sat, 05 May 2012 03:50:46 -0700 (PDT) Received: from amy.lab.techwires.net (dslb-088-067-196-237.pools.arcor-ip.net. [88.67.196.237]) by mx.google.com with ESMTPS id fo7sm3275178wib.9.2012.05.05.03.50.44 (version=SSLv3 cipher=OTHER); Sat, 05 May 2012 03:50:46 -0700 (PDT) Sender: Bernhard Schmidt From: Bernhard Schmidt To: freebsd-wireless@freebsd.org Date: Sat, 5 May 2012 12:51:10 +0200 User-Agent: KMail/1.13.7 (FreeBSD/9.0-STABLE; KDE/4.7.4; amd64; ; ) References: <201205031853.53102.bschmidt@freebsd.org> <20120505105258.28e28803@laptop> In-Reply-To: <20120505105258.28e28803@laptop> MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_eYQpPv8wqFkpfch" Message-Id: <201205051251.10431.bschmidt@freebsd.org> X-Gm-Message-State: ALoCoQnW0CfXiE0LLEe+lCjBBl3Ip85E39oTcVMkf1HVuSI1BVZJ+jmeIaUQYUNEegyr/Br4PlRk Cc: freebsd-net@freebsd.org, "Sergey V. Dyatko" , freebsd-current@freebsd.org Subject: Re: [CFT] Ralink RT2860, RT2870, RT3060, RT3090 support 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, 05 May 2012 10:50:48 -0000 --Boundary-00=_eYQpPv8wqFkpfch Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit On Saturday 05 May 2012 09:52:58 Sergey V. Dyatko wrote: > On Thu, 3 May 2012 18:53:52 +0200 > Bernhard Schmidt wrote: > > > Hi folks, > > > > As some of you might know there has been some work going on porting > > support for new Ralink chipsets from OpenBSD. Several different > > drivers where floating around but nothing seemed to be decent enough > > to be committed. ray@ and I had been working on cleaning up one of > > those to get it into a good enough shape, but abandoned this approach > > as it resulted in more work than starting from scratch. > > > > So, attached diff [1] is a from-scratch effort to port over support > > for the new chipsets. It doesn't contain fancy stuff like 802.11n > > support as of yet (this will be worked one once the legacy stuff is > > in HEAD), nonetheless it showed pretty decent performance during the > > basic sta/adhoc/hostap tests I've done. > > > > I'd appreciate testing and feedback ;) > > > at 1st I would say 'Thank You' for all people who working on this :) > > patch, make, make install, kldload: > http://tiger.ipfw.ru/files/rt2860_3090.txt > > this is FreeBSD 10.0-CURRENT, r234992M: Fri May 4 11:25:53 FET 2012 > from time to time on messages: > May 5 10:32:47 laptop kernel: ral0: device timeout > May 5 10:37:49 laptop kernel: ral0: device timeout > May 5 10:42:50 laptop kernel: ral0: device timeout > > LED... is just glowing, rarely blinks. With patch from Alexander (ray@) > it doesn't work > > [tiger@laptop]~%scp tiger:/storage/FreeBSD-8.2-RELEASE-amd64-dvd1.iso . > FreeBSD-8.2-RELEASE-amd64-dvd1.iso 11% > 271MB 1.9MB/s 18:19 ETA > ^C > Killed by signal 2. > where 'tiger' is my desktop Please apply attached patch (also here [1]) on top of the first one, it fixes channel switching for >= 3070 (called the wrong function, doh..) as well as a bgscan issue. [1] http://techwires.net/~bschmidt/rt2860_1.diff -- Bernhard --Boundary-00=_eYQpPv8wqFkpfch Content-Type: text/x-patch; charset="UTF-8"; name="rt2860_1.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="rt2860_1.diff" Index: sys/dev/ral/rt2860.c =================================================================== --- sys/dev/ral/rt2860.c (revision 234847) +++ sys/dev/ral/rt2860.c (working copy) @@ -1605,10 +1605,7 @@ rt2860_tx(struct rt2860_softc *sc, struct mbuf *m, struct ieee80211_node *ni) ieee80211_radiotap_tx(vap, m); } - if (hdrlen & 3) - pad = 4 - (hdrlen & 3); - else - pad = 0; + pad = (hdrlen + 3) & ~3; /* copy and trim 802.11 header */ memcpy(txwi + 1, wh, hdrlen); @@ -1667,7 +1664,7 @@ rt2860_tx(struct rt2860_softc *sc, struct mbuf *m, struct ieee80211_node *ni) /* first segment is TXWI + 802.11 header */ txd = &ring->txd[ring->cur]; txd->sdp0 = htole32(data->paddr); - txd->sdl0 = htole16(sizeof (struct rt2860_txwi) + hdrlen + pad); + txd->sdl0 = htole16(sizeof (struct rt2860_txwi) + pad); txd->flags = qsel; /* setup payload segments */ @@ -1776,7 +1773,7 @@ rt2860_tx_raw(struct rt2860_softc *sc, struct mbuf *m, u_int hdrlen; uint16_t dur; uint8_t type, qsel, mcs, pid, tid, qid; - int i, nsegs, ntxds, rate, ridx, error; + int i, nsegs, ntxds, pad, rate, ridx, error; /* the data pool contains at least one element, pick the first */ data = SLIST_FIRST(&sc->data_pool); @@ -1860,6 +1857,8 @@ rt2860_tx_raw(struct rt2860_softc *sc, struct mbuf *m, ieee80211_radiotap_tx(vap, m); } + pad = (hdrlen + 3) & ~3; + /* copy and trim 802.11 header */ memcpy(txwi + 1, wh, hdrlen); m_adj(m, hdrlen); @@ -1917,7 +1916,7 @@ rt2860_tx_raw(struct rt2860_softc *sc, struct mbuf *m, /* first segment is TXWI + 802.11 header */ txd = &ring->txd[ring->cur]; txd->sdp0 = htole32(data->paddr); - txd->sdl0 = htole16(sizeof (struct rt2860_txwi) + hdrlen); + txd->sdl0 = htole16(sizeof (struct rt2860_txwi) + pad); txd->flags = qsel; /* setup payload segments */ @@ -2336,7 +2335,6 @@ rt2860_scan_start(struct ieee80211com *ic) tmp & ~(RT2860_BCN_TX_EN | RT2860_TSF_TIMER_EN | RT2860_TBTT_TIMER_EN)); rt2860_set_gp_timer(sc, 0); - rt2860_set_bssid(sc, ifp->if_broadcastaddr); } static void @@ -2346,10 +2344,10 @@ rt2860_scan_end(struct ieee80211com *ic) struct rt2860_softc *sc = ifp->if_softc; struct ieee80211vap *vap = TAILQ_FIRST(&ic->ic_vaps); - rt2860_enable_tsf_sync(sc); - /* XXX keep local copy */ - rt2860_set_bssid(sc, vap->iv_bss->ni_bssid); - rt2860_set_gp_timer(sc, 500); + if (vap->iv_state == IEEE80211_S_RUN) { + rt2860_enable_tsf_sync(sc); + rt2860_set_gp_timer(sc, 500); + } } static void @@ -2359,7 +2357,7 @@ rt2860_set_channel(struct ieee80211com *ic) struct rt2860_softc *sc = ifp->if_softc; RAL_LOCK(sc); - rt2860_set_chan(sc, ieee80211_chan2ieee(ic, ic->ic_curchan)); + rt2860_switch_chan(sc, ic->ic_curchan); RAL_UNLOCK(sc); } --Boundary-00=_eYQpPv8wqFkpfch-- From owner-freebsd-net@FreeBSD.ORG Sat May 5 12:26:56 2012 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 CCE241065676; Sat, 5 May 2012 12:26:56 +0000 (UTC) (envelope-from sergey.dyatko@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id 761498FC0C; Sat, 5 May 2012 12:26:55 +0000 (UTC) Received: by lbon10 with SMTP id n10so3529121lbo.13 for ; Sat, 05 May 2012 05:26:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type:content-transfer-encoding; bh=0XIFRp8+T8dBFkkCqCZ9l0EJwcJQj1P9g9zEgWKOBx0=; b=acaeft1p4YHptBWdwtK2NhzwJ1uxccSkF+dgSvYgDyOFZ6XsXvpTNzWki9NeLctA/t P9F/fkrGRdcWVk+KXy3ii1zc5fVn+kjODaKLFVmMK/g8ZsBHm/zTIujhMXQsSCyIRgQm kK6VLaKK7sEj/6f+NxQBuzvyRjMfiLDafDoKKPczbs8IzGNjYytw8D8LUVPIvPUbh5Z9 SfnNDfnWJStd+DeollT480CY5vGYZUXsYTAup2Ai/DtLsUxfW1aYSYlrHHDPxeeNI/X5 JaZwyuVMz7Fb+DayCjCIEj79LFzUYGeHd60ksquFqCkPrJhg0gHb/ZhC4hs52nZU4cFN W16Q== Received: by 10.152.112.100 with SMTP id ip4mr8960103lab.1.1336220814122; Sat, 05 May 2012 05:26:54 -0700 (PDT) Received: from laptop (m-s.agava.net. [195.222.84.203]) by mx.google.com with ESMTPS id b5sm14946614lbg.15.2012.05.05.05.26.51 (version=SSLv3 cipher=OTHER); Sat, 05 May 2012 05:26:52 -0700 (PDT) Date: Sat, 5 May 2012 15:27:28 +0300 From: "Sergey V. Dyatko" To: Bernhard Schmidt Message-ID: <20120505152728.65d28e98@laptop> In-Reply-To: <201205051251.10431.bschmidt@freebsd.org> References: <201205031853.53102.bschmidt@freebsd.org> <20120505105258.28e28803@laptop> <201205051251.10431.bschmidt@freebsd.org> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.6; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, freebsd-wireless@freebsd.org, freebsd-current@freebsd.org Subject: Re: [CFT] Ralink RT2860, RT2870, RT3060, RT3090 support 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, 05 May 2012 12:26:57 -0000 On Sat, 5 May 2012 12:51:10 +0200 Bernhard Schmidt wrote: > On Saturday 05 May 2012 09:52:58 Sergey V. Dyatko wrote: > > On Thu, 3 May 2012 18:53:52 +0200 > > Bernhard Schmidt wrote: > > > > > Hi folks, > > > > > > As some of you might know there has been some work going on > > > porting support for new Ralink chipsets from OpenBSD. Several > > > different drivers where floating around but nothing seemed to be > > > decent enough to be committed. ray@ and I had been working on > > > cleaning up one of those to get it into a good enough shape, but > > > abandoned this approach as it resulted in more work than starting > > > from scratch. > > > > > > So, attached diff [1] is a from-scratch effort to port over > > > support for the new chipsets. It doesn't contain fancy stuff like > > > 802.11n support as of yet (this will be worked one once the > > > legacy stuff is in HEAD), nonetheless it showed pretty decent > > > performance during the basic sta/adhoc/hostap tests I've done. > > > > > > I'd appreciate testing and feedback ;) > > > > > at 1st I would say 'Thank You' for all people who working on this :) > > > > patch, make, make install, kldload: > > http://tiger.ipfw.ru/files/rt2860_3090.txt > > > > this is FreeBSD 10.0-CURRENT, r234992M: Fri May 4 11:25:53 FET > > 2012 from time to time on messages: > > May 5 10:32:47 laptop kernel: ral0: device timeout > > May 5 10:37:49 laptop kernel: ral0: device timeout > > May 5 10:42:50 laptop kernel: ral0: device timeout > > > > LED... is just glowing, rarely blinks. With patch from Alexander > > (ray@) it doesn't work > > > > [tiger@laptop]~%scp > > tiger:/storage/FreeBSD-8.2-RELEASE-amd64-dvd1.iso . > > FreeBSD-8.2-RELEASE-amd64-dvd1.iso > > 11% 271MB 1.9MB/s 18:19 ETA ^C > > Killed by signal 2. > > where 'tiger' is my desktop > > Please apply attached patch (also here [1]) on top of the first one, > it fixes channel switching for >= 3070 (called the wrong function, > doh..) as well as a bgscan issue. > > [1] http://techwires.net/~bschmidt/rt2860_1.diff > * patch applied without errors * build/install - ok kldload and after ~5 minutes: May 5 15:01:20 laptop kernel: ral0: device timeout May 5 15:06:12 laptop kernel: ral0: device timeout without bgscan I didn't see such messages ~30-40 min -- wbr, tiger From owner-freebsd-net@FreeBSD.ORG Sat May 5 12:50:54 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 535571065670 for ; Sat, 5 May 2012 12:50:54 +0000 (UTC) (envelope-from bschmidt@techwires.net) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id C294E8FC0C for ; Sat, 5 May 2012 12:50:53 +0000 (UTC) Received: by lagv3 with SMTP id v3so3538737lag.13 for ; Sat, 05 May 2012 05:50:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:x-originating-ip:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=9o0W7hfg/QvE+APkx2r2pbJdqHpyGLIl0YGPAMth5RA=; b=O0lFzRlSYH4jVhhpEEojXZ/juRdGvBseoGsX7/2pAfo7G3L55loHuEdYDWYDjfY1KX CBlOlRXTlenRueU8inMRMHg/diwFNvXs8g6a+EQLXgG9R6dPYdlgskRkcaQ092Eovz1a tZxZFsafO5JwRJlEOHyZsVmiIxoxUI2tUjAq/2UeNkXMtRD89dOFJK7rVb6v3464oJPJ BpTK2ZgoE/CltjlBPRZYYxxtbLqLb803vmhTyKVVXZEjXHyPV6fd6n9stPJrPAXg/SJY GNyU4rD484/Pe3tWS2NB6t2/jSHoboiDC475AsLmqyqtj+JbNR4h+wMpsOwLdaQbaxe+ dyzw== MIME-Version: 1.0 Received: by 10.152.128.137 with SMTP id no9mr8917830lab.2.1336222252169; Sat, 05 May 2012 05:50:52 -0700 (PDT) Sender: bschmidt@techwires.net Received: by 10.152.122.145 with HTTP; Sat, 5 May 2012 05:50:52 -0700 (PDT) X-Originating-IP: [88.67.196.237] In-Reply-To: <20120505152728.65d28e98@laptop> References: <201205031853.53102.bschmidt@freebsd.org> <20120505105258.28e28803@laptop> <201205051251.10431.bschmidt@freebsd.org> <20120505152728.65d28e98@laptop> Date: Sat, 5 May 2012 14:50:52 +0200 X-Google-Sender-Auth: iYjvtZsDIh3Z3lWjOrgBF9diUSw Message-ID: From: Bernhard Schmidt To: "Sergey V. Dyatko" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnvg/ppNsIEFR9L5OTG+sL2ROLJ1VVt3bgZEAzXA67sNLDMyheS/58s06xwWgWvjqsHUwQD Cc: freebsd-net@freebsd.org, freebsd-wireless@freebsd.org, freebsd-current@freebsd.org Subject: Re: [CFT] Ralink RT2860, RT2870, RT3060, RT3090 support 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, 05 May 2012 12:50:54 -0000 On Sat, May 5, 2012 at 2:27 PM, Sergey V. Dyatko wrote: > On Sat, 5 May 2012 12:51:10 +0200 > Bernhard Schmidt wrote: >> Please apply attached patch (also here [1]) on top of the first one, >> it fixes channel switching for >=3D 3070 (called the wrong function, >> doh..) as well as a bgscan issue. >> >> [1] http://techwires.net/~bschmidt/rt2860_1.diff >> > > * patch applied without errors > * build/install - ok > > kldload and after ~5 minutes: > > May =A05 15:01:20 laptop kernel: ral0: device timeout > May =A05 15:06:12 laptop kernel: ral0: device timeout > > without bgscan I didn't see such messages =A0~30-40 min Ok great, so except bgscan you haven't seen any other issue yet? --=20 Bernhard From owner-freebsd-net@FreeBSD.ORG Sat May 5 14:05:07 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 51E30106566B for ; Sat, 5 May 2012 14:05:07 +0000 (UTC) (envelope-from fastearning@gmail.com) Received: from p3smtphosting03-01.prod.phx3.secureserver.net (p3smtphosting03-01.prod.phx3.secureserver.net [208.109.80.73]) by mx1.freebsd.org (Postfix) with SMTP id 2AFAC8FC08 for ; Sat, 5 May 2012 14:05:07 +0000 (UTC) Received: (qmail 13799 invoked from network); 5 May 2012 13:58:27 -0000 Received: from p3swh195.shr.phx3.secureserver.net (HELO p3swh195.gdhosting.gdg) ([72.167.131.134]) (envelope-sender ) by p3smtphosting03-01.prod.phx3.secureserver.net (qmail-ldap-1.03) with SMTP for ; 5 May 2012 13:58:27 -0000 Received: from mail pickup service by p3swh195.gdhosting.gdg with Microsoft SMTPSVC; Sat, 5 May 2012 06:58:27 -0700 From: To: Date: Sat, 5 May 2012 06:58:26 -0700 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 Message-ID: X-OriginalArrivalTime: 05 May 2012 13:58:27.0124 (UTC) FILETIME=[25002F40:01CD2AC7] Subject: GetTicketsDirect-Tell a Friend 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, 05 May 2012 14:05:07 -0000 A Message for you from John Douglas: Congratulations! Friend, Get Your Waiting $630 Commissions Now!!!! Let me tell you my success story A Product A Day 100% instant Payment and the success it has given to the few individuals that I have shared it with so far. You just referred a Paying Members. $630 has been added to your Referral Earnings Section. As Referral Commission. We make 4 payments to our affiliate called weekly Earnings! Details of the members you Referred: This are paid referrals,placed DIRECTLY under you.If you are a Powerline member, If You Take Action today You"ll Also get the Following $630 Commissions sales automatic will be yours w/in 1 Week after you finish sign up . http://instantpaysites.com/websites/productad/index.html?refer=cashnow ACTIVE MEMBER COUNTRY No.# of Sales Robert Peterson-------------United States----$45 --3--sales David Hamilton-----------United States-------$30 --2--sales Mandene Jonhson-------------United States----$15 --1--sales Rebecca William-----------------Germany------$60 --4--sales Annalie Hanford----------United States-------$30 --2--sales Jericho Jackson-----------United States------$75 --5--sales Katherine Levies----------United States------$15 --1--sales Stephanie Dinver----------------Germany------$30 --2--sales Justine Claptons ----------------Canada------$45 --3--sales Jennefer Petters--------------Australia------$90 --7--sales Rebicca Jackjone----------------Hungary------$45 --3--sales Kietth Robensons------------------Italy------$30 --2--sales Yuhans Limtuacco--------------Singapore------$15 --1--sales Adrian Paulbergs---------United Kingdom------$45 --3--sales Rechelle Parkker ----------------Alaska------$60 --4--sales Total ------------ $630 All paid members will placed DIRECTLY under you.If you are a Powerline member, Any sales this persons make will be passed up DIRECTLY to you,$630 will be yours. and you will be notified by email. http://instantpaysites.com/websites/productad/index.html?refer=cashnow Remember: You will be a regular member recieved $630 every week as Affiliate Commission, as long as he/she stays with us. So, it's your responsibility to make sure they remain a member for a Long time. IMPORTANT: Order NOW or Before May-07-2012 Weekly Cycle is the Cut-Off date!To lock in your Position! For Only $15 (Lifetime Membership) to secure your $630 Commission. ATTENTION: This Position is Limited Only and we have 3 remaining Copies left Hurry Grab it Now!And If You are interested to join early.you become a regular member received $630 Partime Commissions every Month. You Get-Paid US $630 USD direct to your PAYPAL Account this May-12-2012. and you will be notified by email. http://instantpaysites.com/websites/productad/index.html?refer=cashnow Invited You, John Douglas U.K. Click on the link(s) above for more details. From owner-freebsd-net@FreeBSD.ORG Sat May 5 14:55:08 2012 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 E2A5B106566B for ; Sat, 5 May 2012 14:55:08 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from vps.hungerhost.com (vps.hungerhost.com [216.38.53.176]) by mx1.freebsd.org (Postfix) with ESMTP id 9B2D68FC0A for ; Sat, 5 May 2012 14:55:08 +0000 (UTC) Received: from pool-108-54-164-122.nycmny.fios.verizon.net ([108.54.164.122]:58905 helo=minion.home) by vps.hungerhost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1SQgO4-0007ml-83 for net@freebsd.org; Sat, 05 May 2012 10:55:08 -0400 From: George Neville-Neil Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Sat, 5 May 2012 10:55:07 -0400 References: <06E1CD64-9313-4569-B7D4-B8C24290C1B9@cl.cam.ac.uk> To: net@freebsd.org Message-Id: <6C5F7899-593B-4DEF-BB4F-F88DB35D560C@neville-neil.com> Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - vps.hungerhost.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - neville-neil.com Cc: Subject: Call for Papers Symposium on Architectures for Networking and Communications Systems 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, 05 May 2012 14:55:09 -0000 Howdy, I know that there are several people on this list who do interesting = work in the networking area. One of the things that can really help the FreeBSD project is for = people to submit papers and get them published on good work they're doing on FreeBSD. = While it's great that we all put stuff out there at the various BSD conferences, it's equally, = or possibly more, important to get the work we're doing on FreeBSD seen by the broader CS = community. If you have been doing interesting work in networking and think you = might be able to submit something you should definitely get cracking and submit to the following = conference. Also, if you know of anyone who would be interested in this conference = please forward this CFP to them as well. Best, George Begin forwarded message: > CALL FOR PAPERS >=20 > The 8th ACM/IEEE Symposium on Architectures > for Networking and Communications Systems >=20 > ANCS 2012 > http://www.ancsconf.org >=20 > October 29-30, 2012 > AT&T Conference Center > University of Texas > Austin, Texas, USA >=20 > IMPORTANT DATES: >=20 > Paper registration and abstract: May 18, 2012 > Submission deadline: May 25, 2012 > Author notification: August 18, 2012 >=20 > CONFERENCE OVERVIEW: >=20 > ANCS is a systems-oriented research conference, presenting original > work that explores the relationship between the architecture of modern > computer networks and the architecture of the individual hardware and > software elements from which these networks are built. This year's > conference will particularly emphasize insight into broader systems > issues in its paper selection, to recognize and foster the growth of > research that lies at the intersection of computer and network systems > architecture. >=20 > Topics of interest include, but are not limited to: >=20 > * System design for future network architectures > * Network architectures enabled by converged platforms > * Virtualized infrastructure architectures, rationale, and devices > * Converged router, server, and storage platforms > * Content-centric architectures, platforms, and mechanisms > * Scalable programming and application frameworks > * High performance / high function packet processing platforms > * Power- and size-optimized computer and communications platforms > * High-speed networking mechanisms and algorithms > * Network security architectures and security anchor/enhancement > devices > * Single-chip platform integration > * Network measurement techniques, architectures, and devices > * Techniques and systems for large-scale data analysis > * Host-network interface issues > * Architectures for data centers > * Router and switch architectures > * Software radios > * Wireless-networking hardware and related software >=20 > SUBMISSION PROCEDURES: >=20 > Papers must be registered, with a title and abstract, no later than=20 > May 18, 2011 at 11:59PM EST (US). The deadline for submissions of full=20= > papers is May 25, 2011 at 11:59PM EST (US). There will be no = extensions=20 > of this deadline. >=20 > Please see the conference web site for detailed submission guidelines > >=20 > Notification of Acceptance: August 18, 2012 >=20 > The Program Committee may choose to accept certain papers = conditionally, > based on a shepherding process. >=20 > SUBMISSION REQUIREMENTS: >=20 > ANCS 2010 will use single-blind reviewing, so submitted papers should > include the authors' names. >=20 > Submit papers using a 10pt font on 12pt leading formatted for printing = on > Letter-sized (8.5" by 11") paper. Paper text blocks must follow ACM > guidelines: double-column, with each column 9.25" by 3.33", 0.33" = space > between columns. Each column must contain no more than 55 lines of = text. > Latex and Word templates, and additional submission requirements, are > available via . ANCS submissions > must be no longer than 12 pages. The PC may choose to reject any = paper > that violates these format requirements, and no deadline extensions = will > be allowed for re-formatting. >=20 > We encourage submissions containing original ideas that are relevant > to the scope of ANCS. Like other conferences, ANCS requires that = papers > not be submitted simultaneously to any other conferences or = publications; > that submissions not be previously published in peer-reviewed = conferences; > and that accepted papers not be subsequently published elsewhere. = Papers > describing work that was previously published in a peer-reviewed = workshop > are allowed, if the authors clearly describe what significant new = content > has been included. >=20 > All submissions will be treated as confidential prior to publication=20= > in the proceedings; rejected submissions will be permanently treated = as > confidential. >=20 > POSTER SESSION: >=20 > ANCS 2012 will include a poster session. Submission deadlines and = guidelines=20 > will be announced at a later date on the conference web site=20 > . >=20 > GENERAL CHAIR: > Tilman Wolf, University of Massachusetts, USA >=20 > PROGRAM CHAIRS: > Andrew W. Moore, University of Cambridge, UK > Viktor Prasanna, University of Southern California, USA >=20 > TECHNICAL PROGRAM COMMITTEE: > Michela Becchi, University of Missouri > Gordon Brebner, Xilinx Labs > Greg Byrd, North Carolina State University > Qunfeng Dong, University of Science and Technology of China > Hans Eberle, Oracle Labs > Holger Fr=F6ning, University of Heidelberg > Euan Harris, Arista Networks > Hoang Le, ISC8 > Jun Li, Tsinghua University > Bill Lin, University of California, San Diego > Derek McAuley, Nottingham University > Kieran Mansley, Solarflare > David Meyer, Cisco Systems > Mario Nemirovsky, Barcelona Supercomputing Center > George Neville-Neil, FreeBSD Foundation > Luigi Rizzo, Universita` di Pisa > Tom Rodeheffer, Microsoft Research > Dimitrios Serpanos, ISI/RC ATHENA & University of Patras > Frederico Silla, Universitat Polit=E8cnica de Val=E8ncia > Satnam Singh, Google > Ripduman Sohan, University of Cambridge > Russ Tessier, University of Massachusetts Amherst > Ola Torudbakken, Oracle Systems > Fang Yu, Microsoft Research >=20 > STEERING COMMITTEE: > Laxmi Bhuyan, University of California, Riverside > H. Jonathan Chao, NYU-Poly > Patrick Crowley, Washington University > Mark Franklin, Washington University > Derek McAuley, University of Nottingham > Nick McKeown, Stanford University > Bill Lin, University of California, San Diego > Peter Z. Onufryk, Integrated Device Technology, Inc. > K. K. Ramakrishnan, AT&T Labs Research > Raj Yavatkar, Intel >=20 > FINANCE CHAIR: > Michela Becchi, University of Missouri, Columbia, USA >=20 > LOCAL ARRANGEMENTS CHAIR: > EJ Kim, Texas A&M University, USA >=20 > STUDENT TRAVEL GRANT CHAIR: > Michela Becchi, University of Missouri, Columbia, USA >=20 > WEB CHAIR: > Xinming Chen, University of Massachusetts, USA >=20 > CONTACT INFORMATION: >=20 > For updated details, please see >=20 >=20 >=20 >=20 >=20