From owner-freebsd-net@FreeBSD.ORG Sun Jun 6 20:56:34 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 687DE10656C5 for ; Sun, 6 Jun 2010 20:56:34 +0000 (UTC) (envelope-from ncrogers@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 2E6998FC1E for ; Sun, 6 Jun 2010 20:56:33 +0000 (UTC) Received: by iwn5 with SMTP id 5so3386989iwn.13 for ; Sun, 06 Jun 2010 13:56:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=DqReQuVDfdWwkSHv/6ehCS348HFEtjqG8EXD+EE6F8w=; b=Baz2Z6Nofx0epIiqhWTtdtZ5tYXbOxOPiLBF8uTiojsuDDe4E5Cmj0K3nM3Goz3J20 7e1oZ5UwxSVBmDT+FJ3sqNFZX/Il68FTOR0EqnfcAGz6XywnHdBZuHQV4GKdHLtlXVy/ eaj6l5pkkpbV8H0JkQC0HIVvsQwdSgk+1iet4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=prSfG4NY8NrMz2lPKVi5gDh11quROgeUjOyIUPW9xNeBi8C+UAwG65n9L4e83cS7Xk bK03EeQr3aVf4lSe+0ldriW7RhBnZDP84+71P0fP+UJ0ZyIb4ZUBVfjY4gqWnysYK6Kq nP+ONwsLwgO6Z+AEhyI/bNtcMh09nAlMmtnV0= MIME-Version: 1.0 Received: by 10.231.158.132 with SMTP id f4mr16482721ibx.52.1275856435942; Sun, 06 Jun 2010 13:33:55 -0700 (PDT) Received: by 10.231.190.131 with HTTP; Sun, 6 Jun 2010 13:33:55 -0700 (PDT) Date: Sun, 6 Jun 2010 16:33:55 -0400 Message-ID: From: Nick Rogers To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: arp(8) performance w/ many aliases assigned to an interface 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, 06 Jun 2010 20:56:34 -0000 I have an 8.0-RELEASE system with 4000 "permanent" ARP entries due to having a network interface (em(4)) configured with 4000 aliases. The "arp -na" command takes what I consider to be an extremely long time to finish (up to 30s on an otherwise unloaded system). I am able to replicate this in a test environment by installing 8.0-RELEASE-amd64 on a VMWare VM w/ 1GB of RAM and a 2GHz CPU. The 4000 aliases/entries is arbitrary, but nicely illustrates the performance problem. The performance is much worse on a real/loaded system. I realize the 4k aliases on an interface is unusual but I have been effectively using this configuration in my network to try and keep my end-users's each on his/her own broadcast domain. The box is a router and I allocate addresses to each user and put each on his/her own subnet with a netmask of /30. If you would like more info on this I can provide it, but it has worked effectively in FreeBSD 6.0-7.2. The slow performance of "arp -na" is an issue for me because I have a web/CGI tool that runs various reports, many of them relying on acquiring the current "ARP table", and the performance of arp(8) makes the web interface extremely slow. I believe the problem was introduced between 7.2 and 8.0, when, as far as I understand, parts of the ARP subsystem were improved. In 7.2, the aliases configured on an interface were not considered ARP entries (at least according to arp(8)), but as of 8.0 they are marked as "permanent" ARP entries and displayed by arp(8), which seems to attribute to the performance problem. I ran the following perl script to setup my test system. This script was run after installing 8.0-RELEASE and adding the bash, perl, and p5-NetAddr-IP packages via pkg_add -r. #!/usr/bin/perl use strict; use diagnostics; use NetAddr::IP; my $interface = 'em1'; my $cidr = '10.0.0.1/18'; # configure the interface with 4000 or so aliases foreach my $na (@{NetAddr::IP->new($cidr)->splitref(30)}) { my $ip = $na->addr(); my $mask = $na->mask(); my $bcast = $na->broadcast()->addr(); my $cmd = "ifconfig $interface inet alias $ip netmask $mask broadcast $bcast"; print STDERR "$cmd\n"; system($cmd); } The results are as follows: [root@ ~]# uname -a FreeBSD .localdomain 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Sat Nov 21 15:02:08 UTC 2009 root@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 [root@ ~]# ifconfig -a | wc -l 4113 [root@ ~]# ifconfig -a | head -15 em0: flags=8843 metric 0 mtu 1500 options=9b ether 00:0c:29:65:4d:3e inet 172.16.16.244 netmask 0xffffff00 broadcast 172.16.16.255 media: Ethernet autoselect (1000baseT ) status: active em1: flags=8843 metric 0 mtu 1500 options=9b ether 00:0c:29:65:4d:48 inet 10.0.0.0 netmask 0xfffffffc broadcast 10.0.0.3 inet 10.0.0.4 netmask 0xfffffffc broadcast 10.0.0.7 inet 10.0.0.8 netmask 0xfffffffc broadcast 10.0.0.11 inet 10.0.0.12 netmask 0xfffffffc broadcast 10.0.0.15 inet 10.0.0.16 netmask 0xfffffffc broadcast 10.0.0.19 inet 10.0.0.20 netmask 0xfffffffc broadcast 10.0.0.23 [root@ ~]# time ifconfig -a > /dev/null real 0m0.032s user 0m0.023s sys 0m0.008s [root@ ~]# arp -na | wc -l 4100 [root@ ~]# arp -na | tail -15 ? (10.0.5.80) at 00:0c:29:65:4d:48 on em1 permanent [ethernet] ? (10.0.5.48) at 00:0c:29:65:4d:48 on em1 permanent [ethernet] ? (10.0.5.16) at 00:0c:29:65:4d:48 on em1 permanent [ethernet] ? (10.0.1.244) at 00:0c:29:65:4d:48 on em1 permanent [ethernet] ? (10.0.1.212) at 00:0c:29:65:4d:48 on em1 permanent [ethernet] ? (10.0.1.180) at 00:0c:29:65:4d:48 on em1 permanent [ethernet] ? (10.0.1.148) at 00:0c:29:65:4d:48 on em1 permanent [ethernet] ? (10.0.1.116) at 00:0c:29:65:4d:48 on em1 permanent [ethernet] ? (10.0.1.84) at 00:0c:29:65:4d:48 on em1 permanent [ethernet] ? (10.0.1.52) at 00:0c:29:65:4d:48 on em1 permanent [ethernet] ? (10.0.1.20) at 00:0c:29:65:4d:48 on em1 permanent [ethernet] ? (172.16.16.1) at 00:50:56:c0:00:08 on em0 [ethernet] ? (172.16.16.2) at 00:50:56:ea:ea:1a on em0 [ethernet] ? (172.16.16.254) at 00:50:56:f2:75:00 on em0 [ethernet] ? (172.16.16.244) at 00:0c:29:65:4d:3e on em0 permanent [ethernet] [root@ ~]# uptime 7:28PM up 42 mins, 2 users, load averages: 0.00, 0.00, 0.00 [root@ ~]# time arp -na > /dev/null real 0m12.761s user 0m2.959s sys 0m9.753s [root@ ~]# Notice that "arp -na" takes about 13s to execute even though there is no other load. This can get a lot worse by a few orders of magnitude on a loaded machine in a production environment, and seems to scale up linearly when more aliases are added to the interface (permanent ARP entries created). I tried the same scenario on 8.1-BETA1 and it still takes a very long time for arp(8) to complete. I was able to isolate the performance bottleneck to a small piece of the arp(8) code. It seems that looking up the interface for an ARP entry is a very heavy operation when that entry corresponds to an alias assigned to the interface. Permanent ARP entries that do not correspond with an interface alias do not seem to cause arp(8) to puke on the interface lookup. The following commands and code diff illustrates how arp(8) can be modified to run a lot faster in this scenario, but obviously the associated interface is no longer printed for each entry. [root@ /usr/src/usr.sbin/arp]# uname -a FreeBSD .localdomain 8.1-BETA1 FreeBSD 8.1-BETA1 #0: Thu May 27 15:03:30 UTC 2010 root@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 [root@ /usr/src/usr.sbin/arp]# time /usr/sbin/arp -na | wc -l 4100 real 0m14.903s user 0m3.133s sys 0m11.519s [root@ /usr/src/usr.sbin/arp]# pwd /usr/src/usr.sbin/arp [root@ /usr/src/usr.sbin/arp]# !diff diff -ruN arp.c.orig arp.c --- arp.c.orig 2010-06-05 18:25:24.000000000 +0000 +++ arp.c 2010-06-05 18:28:19.000000000 +0000 @@ -562,7 +562,7 @@ const char *host; struct hostent *hp; struct iso88025_sockaddr_dl_data *trld; - char ifname[IF_NAMESIZE]; + //char ifname[IF_NAMESIZE]; int seg; if (nflag == 0) @@ -591,8 +591,8 @@ } } else printf("(incomplete)"); - if (if_indextoname(sdl->sdl_index, ifname) != NULL) - printf(" on %s", ifname); + //if (if_indextoname(sdl->sdl_index, ifname) != NULL) + //printf(" on %s", ifname); if (rtm->rtm_rmx.rmx_expire == 0) printf(" permanent"); else { [root@ /usr/src/usr.sbin/arp]# make clean && make rm -f arp arp.o arp.4.gz arp.8.gz arp.4.cat.gz arp.8.cat.gz Warning: Object directory not changed from original /usr/src/usr.sbin/arp cc -O2 -pipe -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c arp.c cc -O2 -pipe -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -o arp arp.o gzip -cn arp.4 > arp.4.gz gzip -cn arp.8 > arp.8.gz [root@ /usr/src/usr.sbin/arp]# time ./arp -na | wc -l 4099 real 0m0.036s user 0m0.015s sys 0m0.021s [root@ /usr/src/usr.sbin/arp]# Notice that 0.036s without the interface lookup is a heck of a lot faster than 14.903s when doing the interface lookup. Is there something that can be done to speedup the call to if_indextoname(), or would it be worthwhile for me to submit a patch that adds the ability to skip the interface lookup as an arp(8) option? From owner-freebsd-net@FreeBSD.ORG Mon Jun 7 00:20:58 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 24219106568B for ; Mon, 7 Jun 2010 00:20:58 +0000 (UTC) (envelope-from jilingshu@gmail.com) Received: from mail-pz0-f175.google.com (mail-pz0-f175.google.com [209.85.222.175]) by mx1.freebsd.org (Postfix) with ESMTP id EBCDC8FC20 for ; Mon, 7 Jun 2010 00:20:57 +0000 (UTC) Received: by pzk5 with SMTP id 5so1379311pzk.14 for ; Sun, 06 Jun 2010 17:20:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:subject :message-id:organization:x-mailer:mime-version:content-type :content-transfer-encoding; bh=xNKYoJK8kPYXwkEy5lj//X2gu0CbTLFSN39GroQVDow=; b=upQgZfqsi3AlM0rzva3iNg9piHaWZfFlQeNrh+z0SUERuCiFRIIxhoQn0WLUDNJ0cP vctIz6y3xGAAiDpAhysAZyFhcUXlbwXKn8rLiItzcj+uU7fa5lPj6VxnqyCinXjhI/7Y Yc/w7ZPqwiOSN9pw75+folZpVFr27p9QgJU1M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:subject:message-id:organization:x-mailer:mime-version :content-type:content-transfer-encoding; b=etSw8PTFOVpdJeOxuGZo12jJRPzcyEcaA82Tn6DDu2wRH7rkdcefgua3yoD3zaSfBk 0IG1u/jKccZNCEsoXdYBXxZuDJUxnPd3B3h+ZrnlXGB0NSq9NXHxVRMdvWyCaiIaC/RG fsDrQOOtzqF8djTXupVfTmPLucUuf7+5plpvE= Received: by 10.140.57.9 with SMTP id f9mr11199890rva.149.1275868302605; Sun, 06 Jun 2010 16:51:42 -0700 (PDT) Received: from Bear-Win ([183.32.177.92]) by mx.google.com with ESMTPS id o38sm282802rvp.2.2010.06.06.16.51.40 (version=SSLv3 cipher=RC4-MD5); Sun, 06 Jun 2010 16:51:42 -0700 (PDT) Date: Mon, 7 Jun 2010 07:51:39 +0800 From: Bear To: "freebsd-net" Message-ID: <201006070751375365327@Gmail.com> Organization: Freebear Develop Group X-mailer: Foxmail 6, 15, 201, 22 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Problems on 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: Mon, 07 Jun 2010 00:20:58 -0000 hi, I am using a pure IPv6 network with NAT-PT. But I have massive of IPv4 applications like many online-games such as World of Warcraft. So is there any way for me to make them work? Can I build a tunnel? How? Thx! -------------- Bear 2010-06-07 From owner-freebsd-net@FreeBSD.ORG Mon Jun 7 05:02:46 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 334701065678; Mon, 7 Jun 2010 05:02:46 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (unknown [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 0B6688FC19; Mon, 7 Jun 2010 05:02:46 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o5752jOa052200; Mon, 7 Jun 2010 05:02:45 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o5752jsG052195; Mon, 7 Jun 2010 05:02:45 GMT (envelope-from linimon) Date: Mon, 7 Jun 2010 05:02:45 GMT Message-Id: <201006070502.o5752jsG052195@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-i386@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/147245: [dummynet] dummynet skip traffic over configured limit with net.inet.ip.dummynet.io_fast:1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2010 05:02:46 -0000 Old Synopsis: dummynet skip traffic over configured limit with net.inet.ip.dummynet.io_fast:1 New Synopsis: [dummynet] dummynet skip traffic over configured limit with net.inet.ip.dummynet.io_fast:1 Responsible-Changed-From-To: freebsd-i386->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Jun 7 05:02:14 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=147245 From owner-freebsd-net@FreeBSD.ORG Mon Jun 7 09:21:49 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3246F1065673 for ; Mon, 7 Jun 2010 09:21:49 +0000 (UTC) (envelope-from pieter@os3.nl) Received: from mail.thelostparadise.com (router.thelostparadise.com [IPv6:2a02:898:0:30::30:1]) by mx1.freebsd.org (Postfix) with ESMTP id C74738FC19 for ; Mon, 7 Jun 2010 09:21:48 +0000 (UTC) Received: by mail.thelostparadise.com (Postfix, from userid 127) id 8205273054; Mon, 7 Jun 2010 11:21:47 +0200 (CEST) Received: from localhost by mail.thelostparadise.com (Postfix) with ESMTP id C300E73008 for ; Mon, 7 Jun 2010 11:21:46 +0200 (CEST) Message-ID: <4C0CBA26.80209@os3.nl> Date: Mon, 07 Jun 2010 11:21:42 +0200 From: Pieter de Boer MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Connection rate limits with pf, blocks too soon? 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, 07 Jun 2010 09:21:49 -0000 Hi list, I have the following rule in my pf.conf: pass in quick on $ext_if inet proto tcp from any to $ext_addr port 80 modulate state (source-track rule max-src-conn 128 max-src-conn-rate 5000/600 overload flush global) I thought this meant that an IP address is added to the `weblamers' table as soon as either: - 128 simultaneous states are present for that IP in pf - 5000 new states have been made for that IP in a 10 minute time frame However, when I run a scanner against this web server, the source IP is blocked after a few seconds and only a few tens of requests. Using 'pfctl -s state' I confirmed that only 65 simultaneous states were present, much lower than the limit. The question is: is pf actually using a time frame of 10 minutes here? I guess it may be averaging over a much smaller amount of time instead. For instance, 5000/600 is averaged over 1 second as 8.3 states? Thanks, Pieter From owner-freebsd-net@FreeBSD.ORG Mon Jun 7 11:00:09 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 988091065672 for ; Mon, 7 Jun 2010 11:00:09 +0000 (UTC) (envelope-from pieter@thelostparadise.com) Received: from mail.thelostparadise.com (router.thelostparadise.com [IPv6:2a02:898:0:30::30:1]) by mx1.freebsd.org (Postfix) with ESMTP id 31F158FC08 for ; Mon, 7 Jun 2010 11:00:09 +0000 (UTC) Received: by mail.thelostparadise.com (Postfix, from userid 127) id 0991873054; Mon, 7 Jun 2010 13:00:08 +0200 (CEST) Received: from localhost by mail.thelostparadise.com (Postfix) with ESMTP id E2BBE73008 for ; Mon, 7 Jun 2010 13:00:07 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=thelostparadise.com; s=thelostparadise; t=1275908407; bh=tigJ2p0v8WFKvtdMOHvau3TeEiY=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=okOgmOntu3jt 9xx7oDCKVlYLZ1pdK5v7+hrIUC+penF0mL3UodPINYSieYGIQDzjYzoAa1vuvQioGXN sRIJUqyf/3wcoA0G3iKYiyVsdTemZkekuA/7GwmHHQ8WXa+niDaYo5MrCTkxQ6/cpHU RLReu4TkFJ1HLE6zDoM/Azo5Q= Message-ID: <4C0CD137.60804@thelostparadise.com> Date: Mon, 07 Jun 2010 13:00:07 +0200 From: Pieter de Boer MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <4C0CBA26.80209@os3.nl> In-Reply-To: <4C0CBA26.80209@os3.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Connection rate limits with pf, blocks too soon? 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, 07 Jun 2010 11:00:09 -0000 On 06/07/2010 11:21 AM, Pieter de Boer wrote: > However, when I run a scanner against this web server, the source IP is > blocked after a few seconds and only a few tens of requests. Using > 'pfctl -s state' I confirmed that only 65 simultaneous states were > present, much lower than the limit. Turns out I was looking at the wrong rule. Sorry for the noise, Pieter From owner-freebsd-net@FreeBSD.ORG Mon Jun 7 11:07:01 2010 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 28AC3106564A for ; Mon, 7 Jun 2010 11:07:01 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (unknown [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 1666F8FC2B for ; Mon, 7 Jun 2010 11:07:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o57B70Rb008726 for ; Mon, 7 Jun 2010 11:07:00 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o57B70jo008721 for freebsd-net@FreeBSD.org; Mon, 7 Jun 2010 11:07:00 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 7 Jun 2010 11:07:00 GMT Message-Id: <201006071107.o57B70jo008721@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, 07 Jun 2010 11:07:01 -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/147352 net [netinet] [patch] replace printf() with log() for "Lim o kern/147245 net [dummynet] dummynet skip traffic over configured limit o kern/147155 net [ip6] setfb not work with ipv6 o kern/146909 net [rue] rue(4) does not detect OQO model01 network contr o kern/146845 net [libc] close(2) returns error 54 (connection reset by o kern/146792 net [flowtable] flowcleaner 100% cpu's core load o kern/146759 net [cxgb] [patch] cxgb panic calling cxgb_set_lro() witho o kern/146719 net [pf] [panic] PF or dumynet kernel panic o kern/146628 net [tcp] [patch] TCP does not clear DF when MTU is below o kern/146539 net [arp] arp pub not working properly o kern/146534 net [icmp6] wrong source address in echo reply o kern/146517 net [ath] [wlan] device timeouts for ath wlan device on re o kern/146427 net [mwl] Additional virtual access points don't work on m o kern/146426 net [mwl] 802.11n rates not possible on mwl o kern/146425 net [mwl] mwl dropping all packets during and after high u f kern/146394 net [vlan] IP source address for outgoing connections o bin/146377 net [ppp] [tun] Interface doesn't clear addresses when PPP o kern/146358 net [vlan] wrong destination MAC address o kern/146263 net [em] [panic] Panic in em(4) SIOCADDMULTI/em_set_multi/ o kern/146250 net [netinet] [patch] Races on interface alias removal 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/145918 net [ae] After spontaneous ae0 "watchdog timeout", "stray o kern/145826 net [ath] Unable to configure adhoc mode on ath0/wlan0 o kern/145825 net [panic] panic: soabort: so_count o kern/145777 net [wpi] Intel 3945ABG driver breaks the connection after o kern/145728 net [lagg] Stops working lagg between two servers. o kern/145621 net [bge] [panic] bge watchdog timeout --resetting -> cras o kern/145462 net [netgraph] [patch] panic kernel when ng_ipfw send ip p o kern/144987 net [wpi] [panic] injecting packets with wlaninject using o kern/144898 net [wpi] [panic] wpi panics system 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 kern/144777 net [arp] proxyarp broken in 8.0 [regression] o kern/144755 net [iwi] [panic] iwi panic when issuing /etc/rc.d/netif r o kern/144724 net [bwn] if_bwn does not pass traffic when in PIO mode o conf/144700 net [rc.d] async dhclient breaks stuff for too many people o kern/144680 net [em] em(4) problem with dual-port adapter o kern/144642 net [rum] [panic] Enabling rum interface causes panic o kern/144616 net [nat] [panic] ip_nat panic FreeBSD 7.2 o kern/144572 net [carp] CARP preemption mode traffic partially goes to o kern/144561 net [ixgbe] [patch] ixgbe driver errors o kern/144529 net [sctp] sctp over ipv6 appears to not calculate checksu o kern/144505 net [bwn] [patch] Error in macro CALC_COEFF2. f kern/144315 net [ipfw] [panic] freebsd 8-stable reboot after add ipfw o kern/144206 net Marvell Yukon NIC not working under FreeBSD o kern/144000 net [tcp] setting TCP_MAXSEG by setsockopt() does not seem o kern/143939 net [ipfw] [em] ipfw nat and em interface rxcsum problem o kern/143874 net [wpi] Wireless 3945ABG error. wpi0 could not allocate o kern/143868 net [ath] [patch] allow Atheros watchdog timeout to be tun o kern/143846 net [gif] bringing gif3 tunnel down causes gif0 tunnel to s kern/143673 net [stf] [request] there should be a way to support multi s kern/143666 net [ip6] [request] PMTU black hole detection not implemen o kern/143622 net [pfil] [patch] unlock pfil lock while calling firewall o kern/143595 net [wpi] [panic] Creating virtual interface over wpi0 in o kern/143593 net [ipsec] When using IPSec, tcpdump doesn't show outgoin o kern/143591 net [ral] RT2561C-based DLink card (DWL-510) fails to work o kern/143573 net [em] em(4) NIC crashes intermittently o kern/143285 net [em] [regression] jumbo frames broken in 8.0 o kern/143208 net [ipsec] [gif] IPSec over gif interface not working o conf/143079 net hostapd(8) startup missing multi wlan functionality o kern/143074 net [wi]: wi driver triggers panic o kern/143034 net [panic] system reboots itself in tcp code [regression] o kern/142907 net [wpi] if_wpi unstable on ibm/lenovo x60 -- suspect fir o kern/142877 net [hang] network-related repeatable 8.0-STABLE hard hang o kern/142774 net Problem with outgoing connections on interface with mu o kern/142772 net [libc] lla_lookup: new lle malloc failed o kern/142766 net [ipw] [regression] ipw(4) with Intel PRO/wireless 2100 o kern/142518 net [em] [lagg] Problem on 8.0-STABLE with em and lagg o kern/142019 net [em] em needs "ifconfig em0 down up" when link was gon o kern/142018 net [iwi] [patch] Possibly wrong interpretation of beacon- o kern/141861 net [wi] data garbled with WEP and wi(4) with Prism 2.5 o kern/141843 net [em] [vlan] Intel txcsum and assigned vlan invoke wron o kern/141777 net [rum] [patch] Support usbdevs / rum(4) for Buffalo WLI f kern/141741 net Etherlink III NIC won't work after upgrade to FBSD 8, o kern/141720 net [sctp] [lor] [hang] sctp-create vs. sctp-it causes sys o kern/141698 net [sctp] [panic] Own lock on stcb at return from input o kern/141697 net [sctp] [panic] lock (sleep mutex) sctp-tcb not locked o kern/141696 net [rum] [panic] rum(4)+ vimage = kernel panic o kern/141695 net [sctp] [panic] kernel page fault with non-sleepable lo o kern/141314 net Network Performance has decreased by 30% [regression] o kern/141285 net [em] hangs down/up intel nic during creating vlan o kern/141023 net [carp] CARP arp replays with wrong src mac o kern/140796 net [ath] [panic] privileged instruction fault o kern/140778 net [em] randomly panic in vlan/em o kern/140742 net rum(4) Two asus-WL167G adapters cannot talk to each ot o kern/140728 net [em] [patch] Fast irq registration in em driver o kern/140682 net [netgraph] [panic] random panic in netgraph o kern/140647 net [em] [patch] e1000 driver does not correctly handle mu 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/140597 net [netinet] [patch] implement Lost Retransmission Detect o kern/140567 net [ath] [patch] ath is not worked on my notebook PC o kern/140564 net [wpi] Problem with Intel(R) PRO/Wireless 3945ABG o kern/140346 net [wlan] High bandwidth use causes loss of wlan connecti o kern/140326 net [em] em0: watchdog timeout when communicating to windo o kern/140245 net [ath] [panic] Kernel panic during network activity on o kern/140142 net [ip6] [panic] FreeBSD 7.2-amd64 panic w/IPv6 o kern/140066 net [bwi] install report for 8.0 RC 2 (multiple problems) o kern/140051 net [bce] [arp] ARP not sent through Bridge Firewall with o kern/139565 net [ipfilter] ipfilter ioctl SIOCDELST broken o kern/139387 net [ipsec] Wrong lenth of PF_KEY messages in promiscuous o bin/139346 net [patch] arp(8) add option to remove static entries lis o kern/139268 net [if_bridge] [patch] allow if_bridge to forward just VL o kern/139204 net [arp] DHCP server replies rejected, ARP entry lost bef o kern/139162 net [fwip] [panic] 8.0-RC1 panics if using IP over firewir o kern/139117 net [lagg] + wlan boot timing (EBUSY) o kern/139079 net [wpi] Failure to attach wpi(4) o kern/139058 net [ipfilter] mbuf cluster leak on FreeBSD 7.2 o kern/138850 net [dummynet] dummynet doesn't work correctly on a bridge o kern/138782 net [panic] sbflush_internal: cc 0 || mb 0xffffff004127b00 o kern/138739 net [wpi] wpi(4) does not work very well under 8.0-BETA4 o amd64/138688 net [rum] possibly broken on 8 Beta 4 amd64: able to wpa a o kern/138678 net [lo] FreeBSD does not assign linklocal address to loop o kern/138660 net [igb] igb driver troubles in 8.0-BETA4 o kern/138652 net [tcp] TCP window scaling value calculated incorrectly? o kern/138620 net [lagg] [patch] lagg port bpf-writes blocked o kern/138427 net [wpi] [panic] Kernel panic after trying set monitor wl o kern/138407 net [gre] gre(4) interface does not come up after reboot o kern/138332 net [tun] [lor] ifconfig tun0 destroy causes LOR if_adata/ o kern/138266 net [panic] kernel panic when udp benchmark test used as r o kern/138177 net [ipfilter] FreeBSD crashing repeatedly in ip_nat.c:257 o kern/138046 net [tcp] tcp sockets stay in SYN_SENT even after receivin o kern/137881 net [netgraph] [panic] ng_pppoe fatal trap 12 o bin/137841 net [patch] wpa_supplicant(8) cannot verify SHA256 signed p kern/137795 net [sctp] [panic] mtx_lock() of destroyed mutex o kern/137776 net [rum] panic in rum(4) driver on 8.0-BETA2 o kern/137775 net [netgraph] [patch] Add XMIT_FAILOVER to ng_one2many o bin/137641 net ifconfig(8): various problems with "vlan_device.vlan_i o kern/137592 net [ath] panic - 7-STABLE (Aug 7, 2009 UTC) crashes on ne o bin/137484 net [patch] Integer overflow in wpa_supplicant(8) base64 e o kern/137392 net [ip] [panic] crash in ip_nat.c line 2577 o kern/137372 net [ral] FreeBSD doesn't support wireless interface from o kern/137317 net [tcp] logs full of syncache problems o kern/137089 net [lagg] lagg falsely triggers IPv6 duplicate address de o bin/136994 net [patch] ifconfig(8) print carp mac address o kern/136943 net [wpi] [lor] wpi0_com_lock / wpi0 o kern/136911 net [netgraph] [panic] system panic on kldload ng_bpf.ko t o kern/136876 net [bge] bge will not resume properly after suspend o kern/136836 net [ath] atheros card stops functioning after about 12 ho o bin/136661 net [patch] ndp(8) ignores -f option o kern/136618 net [pf][stf] panic on cloning interface without unit numb o kern/136426 net [panic] spawning several dhclients in parallel panics o kern/136168 net [em] em driver initialization fails on Intel 5000PSL m o kern/135502 net [periodic] Warning message raised by rtfree function i o kern/135222 net [igb] low speed routing between two igb interfaces o kern/134956 net [em] FreeBSD 7.1 & 7.2, Intel PRO/1000 PT Quad Port Se o kern/134931 net [route] Route messages sent to all socket listeners re o kern/134583 net [hang] Machine with jail freezes after random amount o o kern/134531 net [route] [panic] kernel crash related to routes/zebra o kern/134401 net [msk] [panic] Kernel Fatal trap 12: page fault while i o kern/134168 net [ral] ral driver problem on RT2525 2.4GHz transceiver o kern/134157 net [dummynet] dummynet loads cpu for 100% and make a syst o kern/134079 net [em] "em0: Invalid MAC address" in FreeBSD-Current ( 8 o kern/133969 net [dummynet] [panic] Fatal trap 12: page fault while in o kern/133968 net [dummynet] [panic] dummynet kernel panic o kern/133902 net [tun] Killing tun0 iface ssh tunnel causes Panic Strin o kern/133786 net [netinet] [patch] ip_input might cause kernel panic o kern/133736 net [udp] ip_id not protected ... o kern/133613 net [wpi] [panic] kernel panic in wpi(4) o kern/133595 net [panic] Kernel Panic at pcpu.h:195 o kern/133572 net [ppp] [hang] incoming PPTP connection hangs the system o kern/133490 net [bpf] [panic] 'kmem_map too small' panic on Dell r900 o kern/133328 net [bge] [panic] Kernel panics with Windows7 client o kern/133235 net [netinet] [patch] Process SIOCDLIFADDR command incorre o kern/133218 net [carp] [hang] use of carp(4) causes system to freeze f kern/133213 net arp and sshd errors on 7.1-PRERELEASE o kern/133204 net [msk] msk driver timeouts o kern/133060 net [ipsec] [pfsync] [panic] Kernel panic with ipsec + pfs f bin/132911 net ip6fw(8): argument type of fill_icmptypes is wrong and o kern/132889 net [ndis] [panic] NDIS kernel crash on load BCM4321 AGN d o kern/132885 net [wlan] 802.1x broken after SVN rev 189592 o conf/132851 net [patch] rc.conf(5): allow to setfib(1) for service run o kern/132832 net [netinet] [patch] tcp_output() might generate invalid o bin/132798 net [patch] ggatec(8): ggated/ggatec connection slowdown p o kern/132734 net [ifmib] [panic] panic in net/if_mib.c o kern/132722 net [ath] Wifi ath0 associates fine with AP, but DHCP or I o kern/132705 net [libwrap] [patch] libwrap - infinite loop if hosts.all o kern/132672 net [ndis] [panic] ndis with rt2860.sys causes kernel pani o kern/132669 net [xl] 3c905-TX send DUP! in reply on ping (sometime) o kern/132554 net [ipl] There is no ippool start script/ipfilter magic t o kern/132354 net [nat] Getting some packages to ipnat(8) causes crash o kern/132285 net [carp] alias gives incorrect hash in dmesg o kern/132277 net [crypto] [ipsec] poor performance using cryptodevice f o kern/132107 net [carp] carp(4) advskew setting ignored when carp IP us o kern/131781 net [ndis] ndis keeps dropping the link o kern/131776 net [wi] driver fails to init o kern/131753 net [altq] [panic] kernel panic in hfsc_dequeue o bin/131567 net [socket] [patch] Update for regression/sockets/unix_cm o kern/131549 net ifconfig(8) can't clear 'monitor' mode on the wireless o kern/131536 net [netinet] [patch] kernel does allow manipulation of su o bin/131365 net route(8): route add changes interpretation of network o kern/131153 net [iwi] iwi doesn't see a wireless network f kern/131087 net [ipw] [panic] ipw / iwi - no sent/received packets; iw f kern/130820 net [ndis] wpa_supplicant(8) returns 'no space on device' o kern/130628 net [nfs] NFS / rpc.lockd deadlock on 7.1-R o conf/130555 net [rc.d] [patch] No good way to set ipfilter variables a o kern/130525 net [ndis] [panic] 64 bit ar5008 ndisgen-erated driver cau o kern/130311 net [wlan_xauth] [panic] hostapd restart causing kernel pa o kern/130109 net [ipfw] Can not set fib for packets originated from loc f kern/130059 net [panic] Leaking 50k mbufs/hour o kern/129750 net [ath] Atheros AR5006 exits on "cannot map register spa f kern/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129517 net [ipsec] [panic] double fault / stack overflow o kern/129508 net [carp] [panic] Kernel panic with EtherIP (may be relat o kern/129352 net [xl] [patch] xl0 watchdog timeout o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129197 net [panic] 7.0 IP stack related panic o bin/128954 net ifconfig(8) deletes valid routes o kern/128917 net [wpi] [panic] if_wpi and wpa+tkip causing kernel panic o kern/128840 net [igb] page fault under load with igb/LRO o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o conf/128334 net [request] use wpa_cli in the "WPA DHCP" situation o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127928 net [tcp] [patch] TCP bandwidth gets squeezed every time t o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net [arp] arp: Segmentation fault (core dumped) f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/127102 net [wpi] Intel 3945ABG low throughput o kern/127057 net [udp] Unable to send UDP packet via IPv6 socket to IPv o kern/127050 net [carp] ipv6 does not work on carp interfaces [regressi o kern/126945 net [carp] CARP interface destruction with ifconfig destro o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o kern/126714 net [carp] CARP interface renaming makes system no longer o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126688 net [ixgbe] [patch] 1.4.7 ixgbe driver panic with 4GB and o kern/126475 net [ath] [panic] ath pcmcia card inevitably panics under o kern/126339 net [ipw] ipw driver drops the connection o kern/126214 net [ath] txpower problem with Atheros wifi card o kern/126075 net [inet] [patch] internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125816 net [carp] [if_bridge] carp stuck in init when using bridg f kern/125502 net [ral] ifconfig ral0 scan produces no output unless in o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre o kern/124767 net [iwi] Wireless connection using iwi0 driver (Intel 220 o kern/124753 net [ieee80211] net80211 discards power-save queue packets o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124225 net [ndis] [patch] ndis network driver sometimes loses net o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. p kern/123961 net [vr] [patch] Allow vr interface to handle vlans 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 bin/123633 net ifconfig(8) doesn't set inet and ether address in one f kern/123617 net [tcp] breaking connection when client downloading file o kern/123603 net [tcp] tcp_do_segment and Received duplicate SYN o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o kern/123429 net [nfe] [hang] "ifconfig nfe up" causes a hard system lo o kern/123347 net [bge] bge1: watchdog timeout -- linkstate changed to D o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123256 net [wpi] panic: blockable sleep lock with wpi(4) f kern/123172 net [bce] Watchdog timeout problems with if_bce 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 o kern/122928 net [em] interface watchdog timeouts and stops receiving p f kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122772 net [em] em0 taskq panic, tcp reassembly bug causes radix o kern/122743 net [mbuf] [panic] vm_page_unwire: invalid wire count: 0 o kern/122697 net [ath] Atheros card is not well supported o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal o kern/122195 net [ed] Alignment problems in if_ed o kern/122058 net [em] [panic] Panic on em1: taskq o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup ieee o bin/121895 net [patch] rtsol(8)/rtsold(8) doesn't handle managed netw o kern/121872 net [wpi] driver fails to attach on a fujitsu-siemens s711 s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121706 net [netinet] [patch] "rtfree: 0xc4383870 has 1 refs" emit o kern/121624 net [em] [regression] Intel em WOL fails after upgrade to 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/121298 net [em] [panic] Fatal trap 12: page fault while in kernel 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/121080 net [bge] IPv6 NUD problem on multi address config on bge0 o kern/120966 net [rum] kernel panic with if_rum and WPA encryption p docs/120945 net [patch] ip6(4) man page lacks documentation for TCLASS o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [udp] [panic] gnugk causes kernel panic when closing U o kern/120232 net [nfe] [patch] Bring in nfe(4) to RELENG_6 o kern/120130 net [carp] [panic] carp causes kernel panics in any conste o bin/120060 net routed(8) deletes link-level routes in the presence of o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr a kern/118879 net [bge] [patch] bge has checksum problems on the 5703 ch o kern/118727 net [netgraph] [patch] [request] add new ng_pf module a kern/118238 net [bce] [patch] bce driver shows "no carrier" on Intel S s kern/117717 net [panic] Kernel panic with Bittorrent client. o kern/117448 net [carp] 6.2 kernel crash [regression] o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o kern/117043 net [em] Intel PWLA8492MT Dual-Port Network adapter EEPROM o kern/116747 net [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/115019 net [netgraph] ng_ether upper hook packet flow stops on ad o kern/115002 net [wi] if_wi timeout. failed allocation (busy bit). ifco o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o kern/113895 net [xl] xl0 fails on 6.2-RELEASE but worked fine on 5.5-R 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 kern/112570 net [bge] packet loss with bge driver on BCM5704 chipset o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/111457 net [ral] ral(4) freeze o kern/110140 net [ipw] ipw fails under load o kern/109733 net [bge] bge link state issues [regression] o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o kern/109308 net [pppd] [panic] Multiple panics kernel ppp suspected [r o kern/109251 net [re] [patch] if_re cardbus card won't attach o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/108542 net [bce] Huge network latencies with 6.2-RELEASE / STABLE o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o kern/107850 net [bce] bce driver link negotiation is faulty 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/106243 net [nve] double fault panic in if_nve.c on high loads 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/105348 net [ath] ath device stopps TX o kern/104851 net [inet6] [patch] On link routes not configured when usi o kern/104751 net [netgraph] kernel panic, when getting info about my tr o kern/104485 net [bge] Broadcom BCM5704C: Intermittent on newer chip ve o kern/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac o kern/102540 net [netgraph] [patch] supporting vlan(4) by ng_fec(4) o conf/102502 net [netgraph] [patch] ifconfig name does't rename netgrap o kern/102035 net [plip] plip networking disables parallel port printing o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau o kern/100709 net [libc] getaddrinfo(3) should return TTL info o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/98597 net [inet6] Bug in FreeBSD 6.1 IPv6 link-local DAD procedu o bin/98218 net wpa_supplicant(8) blacklist not working f bin/97392 net ppp(8) hangs instead terminating o kern/97306 net [netgraph] NG_L2TP locks after connection with failed f kern/96268 net [socket] TCP socket performance drops by 3000% if pack o kern/96030 net [bfe] [patch] Install hangs with Broadcomm 440x NIC in 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 s kern/94863 net [bge] [patch] hack to get bge(4) working on IBM e326m o kern/94162 net [bge] 6.x kenel stale with bge(4) o kern/93886 net [ath] Atheros/D-Link DWL-G650 long delay to associate f kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/93019 net [ppp] ppp and tunX problems: no traffic after restarti o kern/92880 net [libc] [patch] almost rewritten inet_network(3) functi f kern/92552 net A serious bug in most network drivers from 5.X to 6.X s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu o kern/92090 net [bge] bge0: watchdog timeout -- resetting 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/91594 net [em] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/10 o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging o kern/90890 net [vr] Problems with network: vr0: tx shutdown timeout s kern/90086 net [hang] 5.4p8 on supermicro P8SCT hangs during boot if f kern/88082 net [ath] [panic] cts protection for ath0 causes panic o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/87506 net [vr] [patch] Fix alias support on vr interfaces 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/86103 net [ipf] Illegal NAT Traversal in IPFilter o kern/85780 net 'panic: bogus refcnt 0' in routing/ipv6 o bin/85445 net ifconfig(8): deprecated keyword to ifconfig inoperativ o kern/84202 net [ed] [patch] Holtek HT80232 PCI NIC recognition on Fre o bin/82975 net route change does not parse classfull network as given o kern/82881 net [netgraph] [panic] ng_fec(4) causes kernel panic after o bin/82185 net [patch] ndp(8) can delete the incorrect entry s kern/81147 net [net] [patch] em0 reinitialization while adding aliase o kern/80853 net [ed] [patch] add support for Compex RL2000/ISA in PnP o kern/79895 net [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph f kern/79262 net [dc] Adaptec ANA-6922 not fully supported o bin/79228 net [patch] extend arp(8) to be able to create blackhole r o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if p kern/77913 net [wi] [patch] Add the APDL-325 WLAN pccard to wi(4) o kern/77341 net [ip6] problems with IPV6 implementation o kern/77273 net [ipf] ipfilter breaks ipv6 statefull filtering on 5.3 s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/75873 net Usability problem with non-RFC-compliant IP spoof prot s kern/75407 net [an] an(4): no carrier after short time f kern/73538 net [bge] problem with the Broadcom BCM5788 Gigabit Ethern o kern/71469 net default route to internet magically disappears with mu o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/66225 net [netgraph] [patch] extend ng_eiface(4) control message s kern/60293 net [patch] FreeBSD arp poison patch o kern/54383 net [nfs] [patch] NFS root configurations without dynamic f i386/45773 net [bge] Softboot causes autoconf failure on Broadcom 570 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/35442 net [sis] [patch] Problem transmitting runts in if_sis dri o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". o kern/31647 net [libc] socket calls can return undocumented EINVAL o kern/30186 net [libc] getaddrinfo(3) does not handle incorrect servna o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c o conf/23063 net [arp] [patch] for static ARP tables in rc.network 430 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Jun 7 17:57:10 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 52567106564A; Mon, 7 Jun 2010 17:57:10 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (unknown [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 28DA58FC15; Mon, 7 Jun 2010 17:57:10 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o57HvALL065976; Mon, 7 Jun 2010 17:57:10 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o57HvAQS065972; Mon, 7 Jun 2010 17:57:10 GMT (envelope-from linimon) Date: Mon, 7 Jun 2010 17:57:10 GMT Message-Id: <201006071757.o57HvAQS065972@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/71474: [route] route lookup does not skip interfaces marked down 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, 07 Jun 2010 17:57:10 -0000 Old Synopsis: route lookup does not skip interfaces marked down New Synopsis: [route] route lookup does not skip interfaces marked down Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Jun 7 17:55:37 UTC 2010 Responsible-Changed-Why: On second thought, it probably belongs to -net. http://www.freebsd.org/cgi/query-pr.cgi?pr=71474 From owner-freebsd-net@FreeBSD.ORG Mon Jun 7 18:04:48 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 658FF1065675; Mon, 7 Jun 2010 18:04:48 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (unknown [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 3C1948FC0C; Mon, 7 Jun 2010 18:04:48 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o57I4mPf074326; Mon, 7 Jun 2010 18:04:48 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o57I4mw6074321; Mon, 7 Jun 2010 18:04:48 GMT (envelope-from linimon) Date: Mon, 7 Jun 2010 18:04:48 GMT Message-Id: <201006071804.o57I4mw6074321@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/147638: [PATCH] [ath] Atheros R9280 has probrem at 8.1-PRERELEASE 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, 07 Jun 2010 18:04:48 -0000 Synopsis: [PATCH] [ath] Atheros R9280 has probrem at 8.1-PRERELEASE Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Jun 7 18:04:40 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=147638 From owner-freebsd-net@FreeBSD.ORG Mon Jun 7 18:59:54 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 284C0106564A for ; Mon, 7 Jun 2010 18:59:54 +0000 (UTC) (envelope-from davidch@broadcom.com) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by mx1.freebsd.org (Postfix) with ESMTP id 0607B8FC13 for ; Mon, 7 Jun 2010 18:59:53 +0000 (UTC) Received: from [10.9.200.131] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Mon, 07 Jun 2010 11:53:03 -0700 X-Server-Uuid: B55A25B1-5D7D-41F8-BC53-C57E7AD3C201 Received: from IRVEXCHCCR01.corp.ad.broadcom.com ([10.252.49.30]) by IRVEXCHHUB01.corp.ad.broadcom.com ([10.9.200.131]) with mapi; Mon, 7 Jun 2010 11:53:03 -0700 From: "David Christensen" To: "Mike Barnard" , "freebsd-net@freebsd.org" Date: Mon, 7 Jun 2010 11:53:01 -0700 Thread-Topic: bce+lagg Thread-Index: Acr+UZCRe3CoMFVPSDyP2sb86hie+wIIHFmQ Message-ID: <5D267A3F22FD854F8F48B3D2B52381933B3D633669@IRVEXCHCCR01.corp.ad.broadcom.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 60139F8531G149815652-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: Subject: RE: bce+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: Mon, 07 Jun 2010 18:59:54 -0000 > If I configure the cards individually, I can reach other devices on the > network. When I enable link aggregation, I can ping the hosts IP > address, > but I cannot ping its gateway. I haven't played with lagg on bce(4) so I definitely haven't tested this. Can you dump the hardware statistics before/after the test=20 ("sysctl -a | grep bce") and "diff" them to see which statistics have changed? Seems like it might be an RX filtering problem where the NIC drops frames unexpectedly. Does a trace on the GW show that if receives the ICMP echo requests and sends out the responses? Dave From owner-freebsd-net@FreeBSD.ORG Tue Jun 8 01:24:53 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 81F101065670 for ; Tue, 8 Jun 2010 01:24:53 +0000 (UTC) (envelope-from ozkan.kirik@gmail.com) Received: from mail-ww0-f54.google.com (mail-ww0-f54.google.com [74.125.82.54]) by mx1.freebsd.org (Postfix) with ESMTP id 1C9688FC2B for ; Tue, 8 Jun 2010 01:24:52 +0000 (UTC) Received: by wwb22 with SMTP id 22so4061779wwb.13 for ; Mon, 07 Jun 2010 18:24:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=DxdrQGfYcw0ohM9KFWXpKQH6P1R3p9rQLsuQxV5A+hc=; b=QWa1azYOxnP16bvsR9iPPbVLCgPfPycIVeA8iUEYwoROj00BwtfeEpDDNfEHsS82/k YgyWt62TB2PjubDKxMYI/M/UuycFIFNQ0gPhJb1+aA8Ter60pWBMvkC/L678mVdo2gpc HCzUS0CzMOD1pNviExGnL4ATxxOyRZi9u7//s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=EWE0CRSxUlqkU2+lSsUqPWIyB7rOTpcZ1bx5lLv5IohOLbK1lhrRKLeYNzquqRMDjM 2o8j6e5Q5A1SiLHoRfIch5UuYxDIH2gJR1YygJVlk1WeOb9jCQuLT6991+ug0G/IU/tJ QKoqViKqfnK6nPyTVADYsjr9j+tJwzrDA9kXo= MIME-Version: 1.0 Received: by 10.216.87.74 with SMTP id x52mr1167429wee.4.1275813743267; Sun, 06 Jun 2010 01:42:23 -0700 (PDT) Received: by 10.216.13.205 with HTTP; Sun, 6 Jun 2010 01:42:23 -0700 (PDT) Date: Sun, 6 Jun 2010 11:42:23 +0300 Message-ID: From: =?ISO-8859-1?Q?=D6zkan_KIRIK?= To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Default router changes unexpectedly 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, 08 Jun 2010 01:24:53 -0000 Hi, I am using FreeBSD 7.3 STABLE-201004. IPFW + In kernel NAT and if_vlan used mostly. System has 3 em interfaces. Scenario is classical, LAN DMZ WAN. Sometimes default router changes unexpectedly. I inspected logs if someone logged in or changed route. I found nothing. This problem repeats at least 1 times per day. I wrote a shell script which monitors the default router. I saw that sometimes netstat -rn shows that default router is changed as 10.3.1.64 or 10.5.3.189 etc. which are client IP addresses but routing still routes to right router 212.X.Y.Z . After a while, routing really fails. This problem occurs at multiple routing table supported freebsd versions. I dont use this feature. Regards, Ozkan KIRIK Mersin University @ Turkey From owner-freebsd-net@FreeBSD.ORG Wed Jun 9 00:21:33 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 42B051065674; Wed, 9 Jun 2010 00:21:33 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (unknown [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 1B0D38FC14; Wed, 9 Jun 2010 00:21:33 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o590LWHF079956; Wed, 9 Jun 2010 00:21:32 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o590LWIA079952; Wed, 9 Jun 2010 00:21:32 GMT (envelope-from linimon) Date: Wed, 9 Jun 2010 00:21:32 GMT Message-Id: <201006090021.o590LWIA079952@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/147684: [nfe] nVidia MCP55 driver blocks IPMI LAN on load X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2010 00:21:33 -0000 Old Synopsis: nVidia MCP55 driver blocks IPMI LAN on load New Synopsis: [nfe] nVidia MCP55 driver blocks IPMI LAN on load Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed Jun 9 00:19:24 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=147684 From owner-freebsd-net@FreeBSD.ORG Wed Jun 9 07:30:08 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 39277106566B for ; Wed, 9 Jun 2010 07:30:08 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (unknown [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 0EF768FC25 for ; Wed, 9 Jun 2010 07:30:08 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o597U7fO065694 for ; Wed, 9 Jun 2010 07:30:07 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o597U7QE065693; Wed, 9 Jun 2010 07:30:07 GMT (envelope-from gnats) Date: Wed, 9 Jun 2010 07:30:07 GMT Message-Id: <201006090730.o597U7QE065693@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Vincent Hoffman Cc: Subject: Re: kern/146517: [ath] [wlan] device timeouts for ath wlan device on recent stable. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Vincent Hoffman List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2010 07:30:08 -0000 The following reply was made to PR kern/146517; it has been noted by GNATS. From: Vincent Hoffman To: bug-followup@FreeBSD.org, vince@unsane.co.uk Cc: Subject: Re: kern/146517: [ath] [wlan] device timeouts for ath wlan device on recent stable. Date: Wed, 09 Jun 2010 08:24:18 +0100 I've applied and built the patch in PR kern/147638 and so far it seems to have fixed it for me. No more timeouts. I'll try some more testing if i get the chance but will be on holiday for a while from the end of the week for a week. -- regards, Vince From owner-freebsd-net@FreeBSD.ORG Wed Jun 9 12:44:40 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CAFFD1065676; Wed, 9 Jun 2010 12:44:40 +0000 (UTC) (envelope-from wxs@FreeBSD.org) Received: from freefall.freebsd.org (unknown [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id A40AA8FC2A; Wed, 9 Jun 2010 12:44:40 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o59CieHl059361; Wed, 9 Jun 2010 12:44:40 GMT (envelope-from wxs@freefall.freebsd.org) Received: (from wxs@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o59Cieo3059357; Wed, 9 Jun 2010 12:44:40 GMT (envelope-from wxs) Date: Wed, 9 Jun 2010 12:44:40 GMT Message-Id: <201006091244.o59Cieo3059357@freefall.freebsd.org> To: wxs@FreeBSD.org, freebsd-net@FreeBSD.org, wxs@FreeBSD.org From: wxs@FreeBSD.org Cc: Subject: Re: kern/147155: [ip6] setfb not work with 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, 09 Jun 2010 12:44:40 -0000 Synopsis: [ip6] setfb not work with ipv6 Responsible-Changed-From-To: freebsd-net->wxs Responsible-Changed-By: wxs Responsible-Changed-When: Wed Jun 9 12:44:40 UTC 2010 Responsible-Changed-Why: I'll take it. http://www.freebsd.org/cgi/query-pr.cgi?pr=147155 From owner-freebsd-net@FreeBSD.ORG Wed Jun 9 12:47:51 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 242A91065676; Wed, 9 Jun 2010 12:47:51 +0000 (UTC) (envelope-from wxs@FreeBSD.org) Received: from freefall.freebsd.org (unknown [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id F0EFB8FC26; Wed, 9 Jun 2010 12:47:50 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o59Clobh059919; Wed, 9 Jun 2010 12:47:50 GMT (envelope-from wxs@freefall.freebsd.org) Received: (from wxs@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o59CloHK059915; Wed, 9 Jun 2010 12:47:50 GMT (envelope-from wxs) Date: Wed, 9 Jun 2010 12:47:50 GMT Message-Id: <201006091247.o59CloHK059915@freefall.freebsd.org> To: wxs@FreeBSD.org, wxs@FreeBSD.org, freebsd-net@FreeBSD.org From: wxs@FreeBSD.org Cc: Subject: Re: kern/147155: [ip6] setfb not work with 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, 09 Jun 2010 12:47:51 -0000 Synopsis: [ip6] setfb not work with ipv6 Responsible-Changed-From-To: wxs->freebsd-net Responsible-Changed-By: wxs Responsible-Changed-When: Wed Jun 9 12:47:35 UTC 2010 Responsible-Changed-Why: Did not mean to grab this one. http://www.freebsd.org/cgi/query-pr.cgi?pr=147155 From owner-freebsd-net@FreeBSD.ORG Wed Jun 9 13:10:04 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6AF4A106566C for ; Wed, 9 Jun 2010 13:10:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (unknown [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 41CC88FC1F for ; Wed, 9 Jun 2010 13:10:04 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o59DA4u1076970 for ; Wed, 9 Jun 2010 13:10:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o59DA4gE076969; Wed, 9 Jun 2010 13:10:04 GMT (envelope-from gnats) Date: Wed, 9 Jun 2010 13:10:04 GMT Message-Id: <201006091310.o59DA4gE076969@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Vincent Hoffman Cc: Subject: Re: kern/147638: [PATCH] [ath] Atheros R9280 has probrem at 8.1-PRERELEASE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Vincent Hoffman List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jun 2010 13:10:04 -0000 The following reply was made to PR kern/147638; it has been noted by GNATS. From: Vincent Hoffman To: bug-followup@FreeBSD.org, amura@tomato.sakura.ne.jp Cc: Subject: Re: kern/147638: [PATCH] [ath] Atheros R9280 has probrem at 8.1-PRERELEASE Date: Wed, 09 Jun 2010 14:00:50 +0100 This is a multi-part message in MIME format. --------------000706050409030501050805 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I've tested this patch on my problematic ath (AR5B91) wireless card and no longer see the timeouts I was getting. I've also added this to my pr related to this (kern/146517) Thanks for the patch. -- regards, Vince --------------000706050409030501050805 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I've tested this patch on my problematic ath (AR5B91) wireless card and no longer see the timeouts I was getting.
I've also added this to my pr related to this (kern/146517)
Thanks for the patch.

--
regards,
Vince
--------------000706050409030501050805-- From owner-freebsd-net@FreeBSD.ORG Wed Jun 9 13:22:55 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 111C0106566C; Wed, 9 Jun 2010 13:22:55 +0000 (UTC) (envelope-from rpaulo@FreeBSD.org) Received: from freefall.freebsd.org (unknown [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id DD6C98FC15; Wed, 9 Jun 2010 13:22:54 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o59DMsS7094930; Wed, 9 Jun 2010 13:22:54 GMT (envelope-from rpaulo@freefall.freebsd.org) Received: (from rpaulo@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o59DMsog094926; Wed, 9 Jun 2010 13:22:54 GMT (envelope-from rpaulo) Date: Wed, 9 Jun 2010 13:22:54 GMT Message-Id: <201006091322.o59DMsog094926@freefall.freebsd.org> To: rpaulo@FreeBSD.org, freebsd-net@FreeBSD.org, rpaulo@FreeBSD.org From: rpaulo@FreeBSD.org Cc: Subject: Re: kern/147638: [PATCH] [ath] Atheros R9280 has probrem at 8.1-PRERELEASE 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, 09 Jun 2010 13:22:55 -0000 Synopsis: [PATCH] [ath] Atheros R9280 has probrem at 8.1-PRERELEASE Responsible-Changed-From-To: freebsd-net->rpaulo Responsible-Changed-By: rpaulo Responsible-Changed-When: Wed Jun 9 13:22:23 UTC 2010 Responsible-Changed-Why: Actually, I think the AR_SREV_MERLIN_20() check should just go away. http://www.freebsd.org/cgi/query-pr.cgi?pr=147638 From owner-freebsd-net@FreeBSD.ORG Wed Jun 9 18:45:01 2010 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from [127.0.0.1] (unknown [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 517691065673 for ; Wed, 9 Jun 2010 18:45:00 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-net@FreeBSD.org Date: Wed, 9 Jun 2010 14:44:47 -0400 User-Agent: KMail/1.6.2 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201006091444.50560.jkim@FreeBSD.org> Cc: Subject: [RFC] BPF timestamping 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, 09 Jun 2010 18:45:01 -0000 bpf(4) can only timestamp packets with microtime(9). I want to expand it to be able to use different format and resolution. The patch is here: http://people.freebsd.org/~jkim/bpf_tstamp.diff With this patch, we can select different format and resolution of the timestamps. It is done via ioctl(2) with BIOCSTSTAMP command. Similarly, you can get the current format and resolution with BIOCGTSTAMP command. Currently, the following functions are available: BPF_T_MICROTIME microtime(9) BPF_T_NANOTIME nanotime(9) BPF_T_BINTIME bintime(9) BPF_T_MICROTIME_FAST getmicrotime(9) BPF_T_NANOTIME_FAST getnanotime(9) BPF_T_BINTIME_FAST getbintime(9) BPF_T_NONE ignore time stamps (Note: Additionally, there is an experimental machanism to tag packets with timestamps in struct bintime format via mbuf_tags(9) from lower layer, e.g., device driver. However, I didn't test it because I wasn't sure whether this is the right thing to do.) While I was here, I moved the bogus SIZEOF_BPF_HDR macro into bpf.c and tried to make it little bit more correct. For example, the 32-bit shim should be able to handle alignment more properly for non-Ethernet DLTs. I tried my best not to break ABI/API (especially for 32-bit platforms) and relevant places are all marked with BURN_BRIDGES. What do you think? Is it worth committing? Thanks, Jung-uk Kim From owner-freebsd-net@FreeBSD.ORG Wed Jun 9 19:16:58 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 678201065678; Wed, 9 Jun 2010 19:16:58 +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 D7B0B8FC13; Wed, 9 Jun 2010 19:16:57 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o59JH4SO034069 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 Jun 2010 22:17:04 +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.4/8.14.4) with ESMTP id o59JGpjG037144; Wed, 9 Jun 2010 22:16:51 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o59JGpxW037143; Wed, 9 Jun 2010 22:16:51 +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: Wed, 9 Jun 2010 22:16:51 +0300 From: Kostik Belousov To: Jung-uk Kim Message-ID: <20100609191651.GR83316@deviant.kiev.zoral.com.ua> References: <201006091444.50560.jkim@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2TczCHLg+zehSNVj" Content-Disposition: inline In-Reply-To: <201006091444.50560.jkim@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=-2.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_50, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-net@freebsd.org Subject: Re: [RFC] BPF timestamping 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, 09 Jun 2010 19:16:58 -0000 --2TczCHLg+zehSNVj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jun 09, 2010 at 02:44:47PM -0400, Jung-uk Kim wrote: > bpf(4) can only timestamp packets with microtime(9). I want to expand=20 > it to be able to use different format and resolution. The patch is=20 > here: >=20 > http://people.freebsd.org/~jkim/bpf_tstamp.diff >=20 > With this patch, we can select different format and resolution of the=20 > timestamps. It is done via ioctl(2) with BIOCSTSTAMP command. =20 > Similarly, you can get the current format and resolution with=20 > BIOCGTSTAMP command. Currently, the following functions are=20 > available: >=20 > BPF_T_MICROTIME microtime(9) > BPF_T_NANOTIME nanotime(9) > BPF_T_BINTIME bintime(9) > BPF_T_MICROTIME_FAST getmicrotime(9) > BPF_T_NANOTIME_FAST getnanotime(9) > BPF_T_BINTIME_FAST getbintime(9) > BPF_T_NONE ignore time stamps >=20 > (Note: Additionally, there is an experimental machanism to tag packets=20 > with timestamps in struct bintime format via mbuf_tags(9) from lower=20 > layer, e.g., device driver. However, I didn't test it because I=20 > wasn't sure whether this is the right thing to do.) >=20 > While I was here, I moved the bogus SIZEOF_BPF_HDR macro into bpf.c=20 > and tried to make it little bit more correct. For example, the=20 > 32-bit shim should be able to handle alignment more properly for=20 > non-Ethernet DLTs. I tried my best not to break ABI/API (especially=20 > for 32-bit platforms) and relevant places are all marked with=20 > BURN_BRIDGES. Putting COMPAT_FREEBSD32 under BURN_BRIDGES feels somewhat strange. --2TczCHLg+zehSNVj Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkwP6KMACgkQC3+MBN1Mb4gMUgCggfGPETcl7pZMIGgEO2aQwiU1 vjEAoLBJwH1ZOgNDulSWZ1q1/umWXi71 =iYaM -----END PGP SIGNATURE----- --2TczCHLg+zehSNVj-- From owner-freebsd-net@FreeBSD.ORG Wed Jun 9 19:31:47 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1FE45106566B; Wed, 9 Jun 2010 19:31:47 +0000 (UTC) (envelope-from ghelmer@palisadesystems.com) Received: from smtp-saas2.palisadesystems.com (smtp-saas2.palisadesystems.com [216.81.161.162]) by mx1.freebsd.org (Postfix) with ESMTP id F13968FC08; Wed, 9 Jun 2010 19:31:46 +0000 (UTC) Received: from [172.16.2.94] (localhost.palisadesystems.com [127.0.0.1]) by smtp-saas2.palisadesystems.com (8.14.3/8.14.3) with ESMTP id o59J4fge039178; Wed, 9 Jun 2010 14:04:48 -0500 (CDT) (envelope-from ghelmer@palisadesystems.com) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Guy Helmer In-Reply-To: <201006091444.50560.jkim@FreeBSD.org> Date: Wed, 9 Jun 2010 14:04:41 -0500 Content-Transfer-Encoding: 7bit Message-Id: <95304DD4-3F41-4439-BD54-6E31D0445FEC@palisadesystems.com> References: <201006091444.50560.jkim@FreeBSD.org> To: Jung-uk Kim X-Mailer: Apple Mail (2.1078) X-PacketSure-Scanned: Yes Cc: freebsd-net@freebsd.org Subject: Re: [RFC] BPF timestamping 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, 09 Jun 2010 19:31:47 -0000 On Jun 9, 2010, at 1:44 PM, Jung-uk Kim wrote: > bpf(4) can only timestamp packets with microtime(9). I want to expand > it to be able to use different format and resolution. The patch is > here: > > http://people.freebsd.org/~jkim/bpf_tstamp.diff > > With this patch, we can select different format and resolution of the > timestamps. It is done via ioctl(2) with BIOCSTSTAMP command. > Similarly, you can get the current format and resolution with > BIOCGTSTAMP command. Currently, the following functions are > available: > > BPF_T_MICROTIME microtime(9) > BPF_T_NANOTIME nanotime(9) > BPF_T_BINTIME bintime(9) > BPF_T_MICROTIME_FAST getmicrotime(9) > BPF_T_NANOTIME_FAST getnanotime(9) > BPF_T_BINTIME_FAST getbintime(9) > BPF_T_NONE ignore time stamps > I like this idea. I've been using getmicrotime(9) myself. > (Note: Additionally, there is an experimental machanism to tag packets > with timestamps in struct bintime format via mbuf_tags(9) from lower > layer, e.g., device driver. However, I didn't test it because I > wasn't sure whether this is the right thing to do.) Not sure about this. > While I was here, I moved the bogus SIZEOF_BPF_HDR macro into bpf.c > and tried to make it little bit more correct. For example, the > 32-bit shim should be able to handle alignment more properly for > non-Ethernet DLTs. I tried my best not to break ABI/API (especially > for 32-bit platforms) and relevant places are all marked with > BURN_BRIDGES. Not sure about this either. Guy From owner-freebsd-net@FreeBSD.ORG Wed Jun 9 19:42:51 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from [127.0.0.1] (unknown [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 48CB61065674; Wed, 9 Jun 2010 19:42:48 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: Kostik Belousov Date: Wed, 9 Jun 2010 15:42:35 -0400 User-Agent: KMail/1.6.2 References: <201006091444.50560.jkim@FreeBSD.org> <20100609191651.GR83316@deviant.kiev.zoral.com.ua> In-Reply-To: <20100609191651.GR83316@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201006091542.37681.jkim@FreeBSD.org> Cc: freebsd-net@freebsd.org Subject: Re: [RFC] BPF timestamping 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, 09 Jun 2010 19:42:52 -0000 On Wednesday 09 June 2010 03:16 pm, Kostik Belousov wrote: > On Wed, Jun 09, 2010 at 02:44:47PM -0400, Jung-uk Kim wrote: > > bpf(4) can only timestamp packets with microtime(9). I want to > > expand it to be able to use different format and resolution. The > > patch is here: > > > > http://people.freebsd.org/~jkim/bpf_tstamp.diff > > > > With this patch, we can select different format and resolution of > > the timestamps. It is done via ioctl(2) with BIOCSTSTAMP > > command. Similarly, you can get the current format and resolution > > with BIOCGTSTAMP command. Currently, the following functions are > > available: > > > > BPF_T_MICROTIME microtime(9) > > BPF_T_NANOTIME nanotime(9) > > BPF_T_BINTIME bintime(9) > > BPF_T_MICROTIME_FAST getmicrotime(9) > > BPF_T_NANOTIME_FAST getnanotime(9) > > BPF_T_BINTIME_FAST getbintime(9) > > BPF_T_NONE ignore time stamps > > > > (Note: Additionally, there is an experimental machanism to tag > > packets with timestamps in struct bintime format via mbuf_tags(9) > > from lower layer, e.g., device driver. However, I didn't test it > > because I wasn't sure whether this is the right thing to do.) > > > > While I was here, I moved the bogus SIZEOF_BPF_HDR macro into > > bpf.c and tried to make it little bit more correct. For example, > > the 32-bit shim should be able to handle alignment more properly > > for non-Ethernet DLTs. I tried my best not to break ABI/API > > (especially for 32-bit platforms) and relevant places are all > > marked with BURN_BRIDGES. > > Putting COMPAT_FREEBSD32 under BURN_BRIDGES feels somewhat strange. If we burn bridges, we don't need to convert 64-bit bh_tstamp to 32-bit version because the sizeof(struct bpf_xhdr) is fixed for both 32-bit and 64-bit platforms. The only difference is alignment and padding because of the evil u_short bh_hdrlen. So, it was necessary evil if we don't want to break ABI between old 32-bit appliacations and bridge-burned 64-bit kernel. No, we are not going to burn bridges any time soon unless libpcap adopt the new structure. Shrug... Jung-uk Kim From owner-freebsd-net@FreeBSD.ORG Wed Jun 9 19:53:21 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from [127.0.0.1] (unknown [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id B461D1065670; Wed, 9 Jun 2010 19:53:19 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: Kostik Belousov Date: Wed, 9 Jun 2010 15:53:07 -0400 User-Agent: KMail/1.6.2 References: <201006091444.50560.jkim@FreeBSD.org> <20100609191651.GR83316@deviant.kiev.zoral.com.ua> <201006091542.37681.jkim@FreeBSD.org> In-Reply-To: <201006091542.37681.jkim@FreeBSD.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201006091553.09621.jkim@FreeBSD.org> Cc: freebsd-net@freebsd.org Subject: Re: [RFC] BPF timestamping 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, 09 Jun 2010 19:53:21 -0000 On Wednesday 09 June 2010 03:42 pm, Jung-uk Kim wrote: > On Wednesday 09 June 2010 03:16 pm, Kostik Belousov wrote: > > On Wed, Jun 09, 2010 at 02:44:47PM -0400, Jung-uk Kim wrote: > > > bpf(4) can only timestamp packets with microtime(9). I want to > > > expand it to be able to use different format and resolution. > > > The patch is here: > > > > > > http://people.freebsd.org/~jkim/bpf_tstamp.diff > > > > > > With this patch, we can select different format and resolution > > > of the timestamps. It is done via ioctl(2) with BIOCSTSTAMP > > > command. Similarly, you can get the current format and > > > resolution with BIOCGTSTAMP command. Currently, the following > > > functions are available: > > > > > > BPF_T_MICROTIME microtime(9) > > > BPF_T_NANOTIME nanotime(9) > > > BPF_T_BINTIME bintime(9) > > > BPF_T_MICROTIME_FAST getmicrotime(9) > > > BPF_T_NANOTIME_FAST getnanotime(9) > > > BPF_T_BINTIME_FAST getbintime(9) > > > BPF_T_NONE ignore time stamps > > > > > > (Note: Additionally, there is an experimental machanism to tag > > > packets with timestamps in struct bintime format via > > > mbuf_tags(9) from lower layer, e.g., device driver. However, I > > > didn't test it because I wasn't sure whether this is the right > > > thing to do.) > > > > > > While I was here, I moved the bogus SIZEOF_BPF_HDR macro into > > > bpf.c and tried to make it little bit more correct. For > > > example, the 32-bit shim should be able to handle alignment > > > more properly for non-Ethernet DLTs. I tried my best not to > > > break ABI/API (especially for 32-bit platforms) and relevant > > > places are all marked with BURN_BRIDGES. > > > > Putting COMPAT_FREEBSD32 under BURN_BRIDGES feels somewhat > > strange. > > If we burn bridges, we don't need to convert 64-bit bh_tstamp to > 32-bit version because the sizeof(struct bpf_xhdr) is fixed for ^^^^^^^^^^^^^^^^^^^^^^^ SIZEOF_BPF_HDR(struct bpf_xhdr) Argh... Jung-uk Kim > both 32-bit and 64-bit platforms. The only difference is alignment > and padding because of the evil u_short bh_hdrlen. So, it was > necessary evil if we don't want to break ABI between old 32-bit > appliacations and bridge-burned 64-bit kernel. > > No, we are not going to burn bridges any time soon unless libpcap > adopt the new structure. Shrug... From owner-freebsd-net@FreeBSD.ORG Wed Jun 9 20:35:48 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4E1DD1065675 for ; Wed, 9 Jun 2010 20:35:48 +0000 (UTC) (envelope-from kurt.buff@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 026FE8FC1D for ; Wed, 9 Jun 2010 20:35:46 +0000 (UTC) Received: by gyh20 with SMTP id 20so5558162gyh.13 for ; Wed, 09 Jun 2010 13:35:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=PZih6oljlOQiOIhYks7vJHUAdRSDEv2zvSZkJEhYuvk=; b=HgfcbcuwSgiv9f0vXDndt3PZ1imUxppJ/i/XmnqUtm6/KcpGBZv7P78bTctCfNmgi7 S7vA8X4Mvxt7SyLiBKClo6/IuZkhxKvyfo9MOP15sn0ehCngOAFUTd8cH6GKCye9BSut 8xqIoHmMH/7l5TJPicaS02UDgoSItDQv/fFQE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=uVCDEs4fBlOIbXFSrSXfLe4t+paBfV1KGvh8i/rK3LohAjMvO/owrHiueIRdApDCZ7 nHRzYToQC36hvlR9riEjyGmZKPzDY2V2JDg3/hfm7BVWO+ynIu7Xo0w6Q08gpIm6Xp9m cYvVWb8zUjkDwMMI6PyFGf+smpvgFNmG20Lx0= MIME-Version: 1.0 Received: by 10.150.237.1 with SMTP id k1mr336167ybh.309.1276115745962; Wed, 09 Jun 2010 13:35:45 -0700 (PDT) Received: by 10.231.11.76 with HTTP; Wed, 9 Jun 2010 13:35:45 -0700 (PDT) Date: Wed, 9 Jun 2010 13:35:45 -0700 Message-ID: From: Kurt Buff To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 Subject: VLANs, routing, multicast and HP switches, oh my... 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, 09 Jun 2010 20:35:48 -0000 All, I have in place a router that I built with FreeBSD (currently it's an i386 build - 7.0-STABLE FreeBSD 7.0-STABLE #1: Mon Jul 28 18:59:13 PDT 2008) on a whitebox with 3 dual-port NICs. the relevant data from /etc/rc.conf: defaultrouter="192.168.27.1" gateway_enable="YES" hostname="zrouter.example.com" ifconfig_fxp0="inet 192.168.27.2 netmask 255.255.255.0" ifconfig_fxp1="inet 10.0.0.1 netmask 255.255.255.0" ifconfig_fxp2="inet 10.0.1.1 netmask 255.255.255.0" ifconfig_fxp3="inet 10.0.2.1 netmask 255.255.255.0" ifconfig_fxp4="inet 10.0.3.1 netmask 255.255.255.0" ifconfig_fxp5="inet 10.0.4.1 netmask 255.255.255.0" static_routes="nistnet" route_nistnet="-net 10.0.5.0/24 10.0.4.60" It serves as a gateway between our production network (192.168.27.0/24) and a set of engineering test/dev subnets - no firewalling at the moment, just a simple router. The interfaces for the test/dev subnets have until now been plugged into dumb switches - no VLANs, and as you can see, just some simple static routing. Now, however, the subnet on fxp4 is going to have an HP 2610 switch attached to it, and they want to hang multiple subnets from that interface. The engineers are also asking for multicast routing between the subnets attached to this interface. So, it looks to me as if I need to set up this box with a VLAN configuration and some more routing intelligence than it has at the moment. I'm looking at, among other pages, this one http://www.cyberciti.biz/faq/howto-configure-freebsd-vlans-with-ifconfig-command/, though I don't see much addressing these two subjects in the handbook. Questions: 1) Do I still need to build a custom kernel for VLANs and multicast routing? 2) Where can I find a decent tutorial on multicast routing? 3) Any other things that I might need to know regarding this that I am obviously overlooking? Thanks muchly for any help. Kurt From owner-freebsd-net@FreeBSD.ORG Wed Jun 9 22:19:09 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B58971065687 for ; Wed, 9 Jun 2010 22:19:09 +0000 (UTC) (envelope-from ncrogers@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7B6C78FC2F for ; Wed, 9 Jun 2010 22:19:09 +0000 (UTC) Received: by iwn7 with SMTP id 7so3013118iwn.13 for ; Wed, 09 Jun 2010 15:19:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=ehpS+2bKW43e+SsLbVzwbRub2ZPvDjbrJsWpWJ03oaw=; b=eq4NHz/pFU2OembBddX4WJv3IfnalCIzAIZogi2gcA3QID8szjr+VXiOJBJDrczip7 NDTIVyYmpruJ+tcSuDGKlHRnBle50SNGt3oV6j3fVdC8V/+PrEECtNHR6vhQHj0S3TzT eh1vKZcpeLJR20NDrWZpVnVC9bQ/6af6tXIwc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=Q3qDZZZtzrtxBk0t2OGej1+QHMsZ0ivQ24BleyhENwHRZM1UfkRpyfpxK3bOacYfi7 1rUq242P/ipBCVsJ/rlZK2q8IVeUrYL6KbL//ON+vYsnO4kQlWmN+VCgTr9J+bRmCMAa aGvZ6Ujozx9Xm5E+vBxZZIQGn8nXAodmm0yVI= MIME-Version: 1.0 Received: by 10.231.119.102 with SMTP id y38mr4003382ibq.135.1276121948972; Wed, 09 Jun 2010 15:19:08 -0700 (PDT) Received: by 10.231.190.131 with HTTP; Wed, 9 Jun 2010 15:19:08 -0700 (PDT) In-Reply-To: References: Date: Wed, 9 Jun 2010 18:19:08 -0400 Message-ID: From: Nick Rogers To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: arp(8) performance w/ many aliases assigned to an interface 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, 09 Jun 2010 22:19:09 -0000 FYI there is a bugfix/patch for this issue being discussed in freebsd-hackers: http://www.mail-archive.com/freebsd-hackers@freebsd.org/msg157097.html From owner-freebsd-net@FreeBSD.ORG Thu Jun 10 02:56:22 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 285A21065672; Thu, 10 Jun 2010 02:56:22 +0000 (UTC) (envelope-from pisymbol@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id E89EA8FC19; Thu, 10 Jun 2010 02:56:21 +0000 (UTC) Received: by pwj1 with SMTP id 1so3678568pwj.13 for ; Wed, 09 Jun 2010 19:56:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=aXnfubl7vHblrAsaa1VE0QxsZYsIzxQCIy/utcvZQ0A=; b=XNtTuyxj62IpLEswquwx4O2xykUhoc6v8D1d8NOxMfJaJj9mg5P8D6cHnUZu715+lf rak9XkdRMyWwAQ2dnlDCJAFCzbC/VCCDD7clLJkkzaSKpbmAr/zbbHxdr+8sMQkN+Jlt 3WqBraJ/klT8HLoRIANckEkgi/SMHdEqtctt0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=opPbvGe/J5+4VbytqQK4pgF+n/7FpH1iIhKDqKGl0412onVTXfpT0THQ4x2boWs5yf idQb/PXSVq8Uj+9EyIgZopj+h9UeG/Csop0SxhGV6ykJiG5f3BG+gOT0u8DiVQMMmzP+ /3v5ykL/4mkMaIHoNPt0/ef5w31d2NAO/IxlY= MIME-Version: 1.0 Received: by 10.115.84.4 with SMTP id m4mr15023276wal.222.1276138581150; Wed, 09 Jun 2010 19:56:21 -0700 (PDT) Received: by 10.114.174.14 with HTTP; Wed, 9 Jun 2010 19:56:21 -0700 (PDT) In-Reply-To: References: Date: Wed, 9 Jun 2010 22:56:21 -0400 Message-ID: From: Alexander Sack To: Juli Mallett Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, Jack Vogel Subject: Re: Dual-rate transceivers with 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: Thu, 10 Jun 2010 02:56:22 -0000 On Fri, May 28, 2010 at 5:12 PM, Juli Mallett wrote: > On Wed, May 19, 2010 at 00:26, Jack Vogel wrote: >> Hmmm, this is odd, I'm sure that was tested by my validation engineer. >> Tell me what the hardware looks like, ie what the 1G link partner is >> and I'll have him check into it... it SHOULD work. > > It's plugged in to an Extreme Networks gigabit switch with Finisar SFP > transceivers. =A0The Intel NIC is populated with an Intel-branded > Finisar dual-rate SFP+ transceiver, model #FTLX8571D3BCV. > > Here's pciconf -lv: > ix0@pci0:8:0:0: class=3D0x020000 card=3D0x00038086 chip=3D0x10fb8086 rev= =3D0x01 hdr=3D0x00 > =A0 =A0vendor =A0 =A0 =3D 'Intel Corporation' > =A0 =A0class =A0 =A0 =A0=3D network > =A0 =A0subclass =A0 =3D ethernet > ix1@pci0:8:0:1: class=3D0x020000 card=3D0x00038086 chip=3D0x10fb8086 rev= =3D0x01 hdr=3D0x00 > =A0 =A0vendor =A0 =A0 =3D 'Intel Corporation' > =A0 =A0class =A0 =A0 =A0=3D network > =A0 =A0subclass =A0 =3D ethernet > > Is there anything it would help for me to instrument in the driver? > >> You could just ask me you know :) > > I think E-Mails from me are getting caught in your spam filter unless > they go through a list :( > > Thanks! > Juli. > _______________________________________________ > 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" > Jack: I am running into a slightly different issue after back porting ixgbe driver to 7.x (btw you are missing DEBUGOUT6 from your #ifdef and the build logic for the buf_ring's stuff is a little off I think). I am using a Finisar multi-mode transceiver connected to an IxIa 10G traffic generator (I don't know the model number, let me know if you absolutely need it) and everything seems to be working until I hit this block of code: ixgbe_phy.c: 1125 if (!(enforce_sfp & IXGBE_DEVICE_CAPS_ALLOW_ANY_SFP)) = { 1126 /* Make sure we're a supported PHY type */ 1127 if (hw->phy.type =3D=3D ixgbe_phy_sfp_intel) { 1128 status =3D IXGBE_SUCCESS; 1129 } else { 1130 DEBUGOUT("SFP+ module not supported\n"= ); 1131 hw->phy.type =3D ixgbe_phy_sfp_unsuppo= rted; 1132 status =3D IXGBE_ERR_SFP_NOT_SUPPORTED= ; 1133 } 1134 } else { 1135 status =3D IXGBE_SUCCESS; 1136 } Some more goodies: comp_codes_1g 0 comp_codes_10g 20 cable_tech 0 sfp_type: 6 vendor_oui: 906500 device caps: 0xfffc What's interesting is that according to the datasheet, 0x2C of the EEPROM is software reserved (Intel black magic!). Based on the logic, it seems if its an Intel SFP, its okay otherwise claim its not supported. If I #ifdef out this code, the driver comes up but does not autonegotiate on the first shot. If I then do ifconfig ix0 up/down everything comes up and I can use it. I noticed that there has been some churn in this area of recognizing SFPs between 7.x - CURRENT. (obviously Juli's issue might be related to this as well). $ ifconfig ix1 ix1: flags=3D8802 metric 0 mtu 1500 options=3D5bb ether 00:1b:21:40:4b:2d media: Ethernet autoselect status: no carrier # ifconfig ix1 down # ifconfig ix1 up # ifconfig ix1 ix1: flags=3D8843 metric 0 mtu 1500 options=3D5bb ether 00:1b:21:40:4b:2d media: Ethernet autoselect (10Gbase-SR ) status: active Jack, any idea on what's going on? (and what the heck is 0x2C in the EEPRO= M?) Thanks! -aps From owner-freebsd-net@FreeBSD.ORG Thu Jun 10 02:59:18 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9DE08106564A; Thu, 10 Jun 2010 02:59:18 +0000 (UTC) (envelope-from pisymbol@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id 68D398FC19; Thu, 10 Jun 2010 02:59:18 +0000 (UTC) Received: by pvb32 with SMTP id 32so884184pvb.13 for ; Wed, 09 Jun 2010 19:59:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=KuQm4v/YPj3In8/EaTkg0J5FgeXtA+UsFurotQeO1zs=; b=ScKHnNb2HZbPoUuolelSBA+RDQ9/5o/0/io7r1o858NQWoWK09aqH6nMkiwDZ76lzv y9oZmutmv7I03vrNBHatXQbbM9CFJxoojDpBtQ0LmIOI/Ih/warAQFIcOq53jdr0U2LF wDyBzHUV0AqUEqDIXkDrkvvgVdbpxWLrivHWY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=ft1bb3/IHQ+FyDV/YDgyIXGfMLflPEt0RzuI/COsT2SqLVxn/XU0g4/bRVAaixcy1z sejBfHAZS6xqJLpirarR5A+Cw7Xx3p5jMEAnS5tu3ZjofbWXNczXRFTP1Fo7A4N8yNp9 coKcargJ7YmzVee5USF0+9E5ZbWJSlhxJiC0g= MIME-Version: 1.0 Received: by 10.143.26.41 with SMTP id d41mr2663111wfj.316.1276138757780; Wed, 09 Jun 2010 19:59:17 -0700 (PDT) Received: by 10.114.174.14 with HTTP; Wed, 9 Jun 2010 19:59:17 -0700 (PDT) In-Reply-To: References: Date: Wed, 9 Jun 2010 22:59:17 -0400 Message-ID: From: Alexander Sack To: Juli Mallett Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, Jack Vogel Subject: Re: Dual-rate transceivers with 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: Thu, 10 Jun 2010 02:59:18 -0000 On Wed, Jun 9, 2010 at 10:56 PM, Alexander Sack wrote: > On Fri, May 28, 2010 at 5:12 PM, Juli Mallett wrot= e: >> On Wed, May 19, 2010 at 00:26, Jack Vogel wrote: >>> Hmmm, this is odd, I'm sure that was tested by my validation engineer. >>> Tell me what the hardware looks like, ie what the 1G link partner is >>> and I'll have him check into it... it SHOULD work. >> >> It's plugged in to an Extreme Networks gigabit switch with Finisar SFP >> transceivers. =A0The Intel NIC is populated with an Intel-branded >> Finisar dual-rate SFP+ transceiver, model #FTLX8571D3BCV. >> >> Here's pciconf -lv: >> ix0@pci0:8:0:0: class=3D0x020000 card=3D0x00038086 chip=3D0x10fb8086 rev= =3D0x01 hdr=3D0x00 >> =A0 =A0vendor =A0 =A0 =3D 'Intel Corporation' >> =A0 =A0class =A0 =A0 =A0=3D network >> =A0 =A0subclass =A0 =3D ethernet >> ix1@pci0:8:0:1: class=3D0x020000 card=3D0x00038086 chip=3D0x10fb8086 rev= =3D0x01 hdr=3D0x00 >> =A0 =A0vendor =A0 =A0 =3D 'Intel Corporation' >> =A0 =A0class =A0 =A0 =A0=3D network >> =A0 =A0subclass =A0 =3D ethernet >> >> Is there anything it would help for me to instrument in the driver? >> >>> You could just ask me you know :) >> >> I think E-Mails from me are getting caught in your spam filter unless >> they go through a list :( >> >> Thanks! >> Juli. >> _______________________________________________ >> 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" >> > > Jack: > > I am running into a slightly different issue after back porting ixgbe > driver to 7.x (btw you are missing DEBUGOUT6 from your #ifdef and the > build logic for the buf_ring's stuff is a little off I think). > > I am using a Finisar multi-mode transceiver connected to an IxIa 10G > traffic generator (I don't know the model number, let me know if you > absolutely need it) and everything seems to be working until =A0I hit > this block of code: > > ixgbe_phy.c: > 1125 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (!(enforce_sfp & IXGBE_DEVICE_CAP= S_ALLOW_ANY_SFP)) { > 1126 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 /* Make sure we're a= supported PHY type */ > 1127 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (hw->phy.type =3D= =3D ixgbe_phy_sfp_intel) { > 1128 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 stat= us =3D IXGBE_SUCCESS; > 1129 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 } else { > 1130 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 DEBU= GOUT("SFP+ module not supported\n"); > 1131 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 hw->= phy.type =3D ixgbe_phy_sfp_unsupported; > 1132 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 stat= us =3D IXGBE_ERR_SFP_NOT_SUPPORTED; > 1133 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 } > 1134 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 } else { > 1135 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 status =3D IXGBE_SUC= CESS; > 1136 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 } > > Some more goodies: > > comp_codes_1g 0 > comp_codes_10g 20 > cable_tech 0 > sfp_type: 6 > vendor_oui: 906500 > device caps: 0xfffc > > What's interesting is that according to the datasheet, 0x2C of the > EEPROM is software reserved (Intel black magic!). =A0Based on the logic, > it seems if its an Intel SFP, its okay otherwise claim its not > supported. > > If I #ifdef out this code, the driver comes up but does not > autonegotiate on the first shot. =A0If I then do ifconfig ix0 up/down > everything comes up and I can use it. =A0I noticed that there has been > some churn in this area of recognizing SFPs between 7.x - CURRENT. > (obviously Juli's issue might be related to this as well). > > $ ifconfig ix1 > ix1: flags=3D8802 metric 0 mtu 1500 > =A0 =A0 =A0 =A0options=3D5bb > =A0 =A0 =A0 =A0ether 00:1b:21:40:4b:2d > =A0 =A0 =A0 =A0media: Ethernet autoselect > =A0 =A0 =A0 =A0status: no carrier > # ifconfig ix1 down > # ifconfig ix1 up > # ifconfig ix1 > ix1: flags=3D8843 metric 0 mtu 15= 00 > =A0 =A0 =A0 =A0options=3D5bb > =A0 =A0 =A0 =A0ether 00:1b:21:40:4b:2d > =A0 =A0 =A0 =A0media: Ethernet autoselect (10Gbase-SR ) > =A0 =A0 =A0 =A0status: active > > Jack, any idea on what's going on? =A0(and what the heck is 0x2C in the E= EPROM?) I apologize: ix0@pci0:10:0:0: class=3D0x020000 card=3D0x000c8086 chip=3D0x10fb8086 rev=3D0x01 hdr=3D0x00 vendor =3D 'Intel Corporation' class =3D network subclass =3D ethernet ix1@pci0:10:0:1: class=3D0x020000 card=3D0x000c8086 chip=3D0x10fb8086 rev=3D0x01 hdr=3D0x00 vendor =3D 'Intel Corporation' class =3D network subclass =3D ethernet I am sure that would be helpful too. Its a 7.2-amd64 + CURRENT driver + my little fixes to make it compile (minor nits). -aps From owner-freebsd-net@FreeBSD.ORG Thu Jun 10 03:01:23 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DE488106566C for ; Thu, 10 Jun 2010 03:01:23 +0000 (UTC) (envelope-from juli@clockworksquid.com) Received: from mail-pz0-f175.google.com (mail-pz0-f175.google.com [209.85.222.175]) by mx1.freebsd.org (Postfix) with ESMTP id BBE708FC0C for ; Thu, 10 Jun 2010 03:01:23 +0000 (UTC) Received: by pzk5 with SMTP id 5so3484271pzk.14 for ; Wed, 09 Jun 2010 20:01:23 -0700 (PDT) Received: by 10.142.210.15 with SMTP id i15mr2005465wfg.256.1276138883168; Wed, 09 Jun 2010 20:01:23 -0700 (PDT) MIME-Version: 1.0 Sender: juli@clockworksquid.com Received: by 10.114.241.2 with HTTP; Wed, 9 Jun 2010 20:01:03 -0700 (PDT) In-Reply-To: References: From: Juli Mallett Date: Wed, 9 Jun 2010 20:01:03 -0700 X-Google-Sender-Auth: EzinLsS1ATAjTV3tpo4L1Z_NLiM Message-ID: To: Alexander Sack Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org, Jack Vogel Subject: Re: Dual-rate transceivers with 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: Thu, 10 Jun 2010 03:01:23 -0000 On Wed, Jun 9, 2010 at 19:56, Alexander Sack wrote: > $ ifconfig ix1 > ix1: flags=8802 metric 0 mtu 1500 You need to bring the interface up in order for the SFP configuration to occur. > # ifconfig ix1 down > # ifconfig ix1 up > # ifconfig ix1 > ix1: flags=8843 metric 0 mtu 1500 From owner-freebsd-net@FreeBSD.ORG Thu Jun 10 09:00:35 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 938A2106566B; Thu, 10 Jun 2010 09:00:35 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) by mx1.freebsd.org (Postfix) with ESMTP id 12CE78FC23; Thu, 10 Jun 2010 09:00:34 +0000 (UTC) Received: from lstewart.caia.swin.edu.au (lstewart.caia.swin.edu.au [136.186.229.95]) by lauren.room52.net (Postfix) with ESMTPSA id 78CDE7E871; Thu, 10 Jun 2010 19:00:30 +1000 (EST) Message-ID: <4C10A9AD.9020308@freebsd.org> Date: Thu, 10 Jun 2010 19:00:29 +1000 From: Lawrence Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.9) Gecko/20100409 Thunderbird/3.0.4 MIME-Version: 1.0 To: Jung-uk Kim References: <201006091444.50560.jkim@FreeBSD.org> In-Reply-To: <201006091444.50560.jkim@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: [RFC] BPF timestamping 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, 10 Jun 2010 09:00:35 -0000 On 06/10/10 04:44, Jung-uk Kim wrote: > bpf(4) can only timestamp packets with microtime(9). I want to expand > it to be able to use different format and resolution. The patch is > here: > > http://people.freebsd.org/~jkim/bpf_tstamp.diff > > With this patch, we can select different format and resolution of the > timestamps. It is done via ioctl(2) with BIOCSTSTAMP command. > Similarly, you can get the current format and resolution with > BIOCGTSTAMP command. Currently, the following functions are > available: > > BPF_T_MICROTIME microtime(9) > BPF_T_NANOTIME nanotime(9) > BPF_T_BINTIME bintime(9) > BPF_T_MICROTIME_FAST getmicrotime(9) > BPF_T_NANOTIME_FAST getnanotime(9) > BPF_T_BINTIME_FAST getbintime(9) > BPF_T_NONE ignore time stamps This sounds great, assuming it is extensible such that it's easy to add new methods in the future. > (Note: Additionally, there is an experimental machanism to tag packets > with timestamps in struct bintime format via mbuf_tags(9) from lower > layer, e.g., device driver. However, I didn't test it because I > wasn't sure whether this is the right thing to do.) This is also an important feature for newer NICs, but I'm also not sure if tags are the right way to do it. It certainly wouldn't be a bad way to start though. > While I was here, I moved the bogus SIZEOF_BPF_HDR macro into bpf.c > and tried to make it little bit more correct. For example, the > 32-bit shim should be able to handle alignment more properly for > non-Ethernet DLTs. I tried my best not to break ABI/API (especially > for 32-bit platforms) and relevant places are all marked with > BURN_BRIDGES. > > What do you think? Is it worth committing? I won't comment on the actual patch, but the ideas described above get the thumbs up from me. Cheers, Lawrence From owner-freebsd-net@FreeBSD.ORG Thu Jun 10 09:45:37 2010 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6304A106564A; Thu, 10 Jun 2010 09:45:37 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail08.syd.optusnet.com.au (mail08.syd.optusnet.com.au [211.29.132.189]) by mx1.freebsd.org (Postfix) with ESMTP id F3EC58FC16; Thu, 10 Jun 2010 09:45:36 +0000 (UTC) Received: from c122-106-175-69.carlnfd1.nsw.optusnet.com.au (c122-106-175-69.carlnfd1.nsw.optusnet.com.au [122.106.175.69]) by mail08.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o5A9jXPe003494 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Jun 2010 19:45:34 +1000 Date: Thu, 10 Jun 2010 19:45:32 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Jung-uk Kim In-Reply-To: <201006091444.50560.jkim@FreeBSD.org> Message-ID: <20100610173950.T33647@delplex.bde.org> References: <201006091444.50560.jkim@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@FreeBSD.org Subject: Re: [RFC] BPF timestamping 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, 10 Jun 2010 09:45:37 -0000 On Wed, 9 Jun 2010, Jung-uk Kim wrote: > bpf(4) can only timestamp packets with microtime(9). I want to expand > it to be able to use different format and resolution. The patch is > here: > > http://people.freebsd.org/~jkim/bpf_tstamp.diff > > With this patch, we can select different format and resolution of the > timestamps. It is done via ioctl(2) with BIOCSTSTAMP command. > Similarly, you can get the current format and resolution with > BIOCGTSTAMP command. Currently, the following functions are > available: > > BPF_T_MICROTIME microtime(9) > BPF_T_NANOTIME nanotime(9) > BPF_T_BINTIME bintime(9) > BPF_T_MICROTIME_FAST getmicrotime(9) > BPF_T_NANOTIME_FAST getnanotime(9) > BPF_T_BINTIME_FAST getbintime(9) > BPF_T_NONE ignore time stamps This has too many timestamp types, yet not one timestamp type which is any good except possibly BPF_T_NONE, and not one monotonic timestamp type. Only external uses and compatibility require use of CLOCK_REALTIME. I recently tried looking at timeout resolution on FreeBSD cluster machines using ktrace, and found ktrace unusable for this. At first I blamed the slowness of the default misconfiguered timecounter ACPI-fast, but the main problem was that I forgot my home directory was on nfs, and nfs makes writing ktrace records take hundreds of times longer than on local file systems. ACPI-fast seemed to be taking nearly 1000 uS, but it was nfs taking that long. Anyway, ACPI-fast takes nearly 1000 nS, which is many times too long to be good for timestamping individual syscalls or packets, and makes sub-microseconds resolution useless. The above non-get *time() interfaces still use the primary timecounter, and this might be slow even if it is not misconfigured. The above get*time() interfaces are fast only at the cost of being broken. Among other bugs, their times only change at relatively large intervals which should become infinity with tickless kernels. (BTW, icmp timestamps are still broken on systems with hz < 100. Someone changed microtime() to getmicrotime(), but getmicrotime() cannot deliver the resolution of 1 mS supported by icmp timestamps unless these intervals are <= 1 mS.) Bruce From owner-freebsd-net@FreeBSD.ORG Thu Jun 10 14:02:16 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A0B231065673 for ; Thu, 10 Jun 2010 14:02:16 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 2AED18FC1A for ; Thu, 10 Jun 2010 14:02:15 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1OMiKk-0004O3-Ac for freebsd-net@freebsd.org; Thu, 10 Jun 2010 16:02:14 +0200 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 10 Jun 2010 16:02:14 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 10 Jun 2010 16:02:14 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org connect(): No such file or directory From: Ivan Voras Date: Thu, 10 Jun 2010 16:02:06 +0200 Lines: 64 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.9) Gecko/20100518 Thunderbird/3.0.4 In-Reply-To: X-Enigmail-Version: 1.0.1 Subject: Re: VLANs, routing, multicast and HP switches, oh my... 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, 10 Jun 2010 14:02:16 -0000 On 06/09/10 22:35, Kurt Buff wrote: > All, > > I have in place a router that I built with FreeBSD (currently it's an > i386 build - 7.0-STABLE FreeBSD 7.0-STABLE #1: Mon Jul 28 18:59:13 PDT > 2008) on a whitebox with 3 dual-port NICs. > > the relevant data from /etc/rc.conf: > > defaultrouter="192.168.27.1" > gateway_enable="YES" > hostname="zrouter.example.com" > ifconfig_fxp0="inet 192.168.27.2 netmask 255.255.255.0" > ifconfig_fxp1="inet 10.0.0.1 netmask 255.255.255.0" > ifconfig_fxp2="inet 10.0.1.1 netmask 255.255.255.0" > ifconfig_fxp3="inet 10.0.2.1 netmask 255.255.255.0" > ifconfig_fxp4="inet 10.0.3.1 netmask 255.255.255.0" > ifconfig_fxp5="inet 10.0.4.1 netmask 255.255.255.0" > static_routes="nistnet" > route_nistnet="-net 10.0.5.0/24 10.0.4.60" > > It serves as a gateway between our production network > (192.168.27.0/24) and a set of engineering test/dev subnets - no > firewalling at the moment, just a simple router. Straightforward enough. > Now, however, the subnet on fxp4 is going to have an HP 2610 switch > attached to it, and they want to hang multiple subnets from that > interface. ... which doesn't necessarily translate to VLANs. You can assign an arbitrary number IP addresses to a single NIC without problems. > So, it looks to me as if I need to set up this box with a VLAN > configuration and some more routing intelligence than it has at the > moment. > > I'm looking at, among other pages, this one > http://www.cyberciti.biz/faq/howto-configure-freebsd-vlans-with-ifconfig-command/, > though I don't see much addressing these two subjects in the handbook. There's not much to say on the topic. The section which describes VLAN setup in the link you have given is correct. Each new virtual vlan device will behave as another NIC. The story behind VLANs is that they are an Ethernet-level routing kludge. Instead of having a flat topology, they divide it into chunks which may be routed separately on L2. On the FreeBSD side, the representation of this will be additional NICs which operate only on these "chunks" - virtual Ethernets which don't see packets from other VLANs even if they travel on the same wire(s). The physical NIC will need to "see" all packets indiscriminately (which is sometimes called a "trunk"), and the OS logic will then "divide" those packets into individual virtual vlan devices. Note that if you use VLANs, all active equipment involved will probably need to be able to understand and work with VLANs, and you will need to configure them all. To be able to use generic Ethernet clients (like Windows with low-end NICs), some kind of end-point equipment will need to strip VLAN tags before the packets reach them. But as I've said, maybe you don't need VLANs. Simply hang multiple IP subnets on normal Ethernet NICs. From owner-freebsd-net@FreeBSD.ORG Thu Jun 10 14:16:01 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 220AC106567E; Thu, 10 Jun 2010 14:16:01 +0000 (UTC) (envelope-from pisymbol@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id E1A2D8FC08; Thu, 10 Jun 2010 14:16:00 +0000 (UTC) Received: by pwj1 with SMTP id 1so3909751pwj.13 for ; Thu, 10 Jun 2010 07:16:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=36+xaolJZHoJ0VrPYB04VJjnB4AdqPHdeX6jePrTND0=; b=wzBr9f4gWhKkNdXwqrcn8ZkR0bgO0kr/0yuws8Fd5rLoMk65UJpDyfNNfYu+H7C8oI DWoiP6pDzBVaMCkqCC+USqKKSGRRIo9wO91EuX74xuWqA0ehYXGgKHPVI3t0m9DZm5Kn 8xorZu6fXnoqc9HgJGYrzEkNiWuzRZ9g032kA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=KSHI2gXfmHdF5KQFIQHRkA+yK+qrHlOWD45Haqq+566ewTMGCEjxy5BOn9+8M0rG6T lerNZ0ZOBsEor+MlT3N+DTYPaTMqmFB07t7RsCtQDWS++A6To4JLWyUtwMJOgVo82QMb UgdGD532oPLIQERcu2Y3eCiUQyziP7mKFcTDg= MIME-Version: 1.0 Received: by 10.114.251.32 with SMTP id y32mr190602wah.149.1276179360306; Thu, 10 Jun 2010 07:16:00 -0700 (PDT) Received: by 10.114.174.14 with HTTP; Thu, 10 Jun 2010 07:16:00 -0700 (PDT) In-Reply-To: <20100610173950.T33647@delplex.bde.org> References: <201006091444.50560.jkim@FreeBSD.org> <20100610173950.T33647@delplex.bde.org> Date: Thu, 10 Jun 2010 10:16:00 -0400 Message-ID: From: Alexander Sack To: Bruce Evans Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, Jung-uk Kim Subject: Re: [RFC] BPF timestamping 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, 10 Jun 2010 14:16:01 -0000 On Thu, Jun 10, 2010 at 5:45 AM, Bruce Evans wrote: > On Wed, 9 Jun 2010, Jung-uk Kim wrote: > >> bpf(4) can only timestamp packets with microtime(9). =A0I want to expand >> it to be able to use different format and resolution. =A0The patch is >> here: >> >> http://people.freebsd.org/~jkim/bpf_tstamp.diff >> >> With this patch, we can select different format and resolution of the >> timestamps. =A0It is done via ioctl(2) with BIOCSTSTAMP command. >> Similarly, you can get the current format and resolution with >> BIOCGTSTAMP command. =A0Currently, the following functions are >> available: >> >> =A0 =A0 =A0 =A0BPF_T_MICROTIME =A0 =A0 =A0 =A0 microtime(9) >> =A0 =A0 =A0 =A0BPF_T_NANOTIME =A0 =A0 =A0 =A0 =A0nanotime(9) >> =A0 =A0 =A0 =A0BPF_T_BINTIME =A0 =A0 =A0 =A0 =A0 bintime(9) >> =A0 =A0 =A0 =A0BPF_T_MICROTIME_FAST =A0 =A0getmicrotime(9) >> =A0 =A0 =A0 =A0BPF_T_NANOTIME_FAST =A0 =A0 getnanotime(9) >> =A0 =A0 =A0 =A0BPF_T_BINTIME_FAST =A0 =A0 =A0getbintime(9) >> =A0 =A0 =A0 =A0BPF_T_NONE =A0 =A0 =A0 =A0 =A0 =A0 =A0ignore time stamps > > This has too many timestamp types, yet not one timestamp type which > is any good except possibly BPF_T_NONE, and not one monotonic timestamp > type. =A0Only external uses and compatibility require use of CLOCK_REALTI= ME. None of these issues are bpf(4)) related though...you are blaming the clock source (rightly so). bpf(4) is just a consumer, its not its job to validate clocks. The kernel offers it so bpf(4) uses it. > I recently tried looking at timeout resolution on FreeBSD cluster > machines using ktrace, and found ktrace unusable for this. =A0At > first I blamed the slowness of the default misconfiguered timecounter > ACPI-fast, but the main problem was that I forgot my home directory > was on nfs, and nfs makes writing ktrace records take hundreds of > times longer than on local file systems. =A0ACPI-fast seemed to be > taking nearly 1000 uS, but it was nfs taking that long. > > Anyway, ACPI-fast takes nearly 1000 nS, which is many times too long > to be good for timestamping individual syscalls or packets, and makes > sub-microseconds resolution useless. =A0The above non-get *time() > interfaces still use the primary timecounter, and this might be slow > even if it is not misconfigured. =A0The above get*time() interfaces are > fast only at the cost of being broken. =A0Among other bugs, their times > only change at relatively large intervals which should become infinity > with tickless kernels. =A0(BTW, icmp timestamps are still broken on > systems with hz < 100. =A0Someone changed microtime() to getmicrotime(), > but getmicrotime() cannot deliver the resolution of 1 mS supported by > icmp timestamps unless these intervals are <=3D 1 mS.) Again, I agree that bpf(4) has really no way to validate whether the clock its using has the precision to generate a valid timestamp. I ran into this exact problem trying to ACPI-fast timecounter in the bge(4) driver as an experiment to timestamp packets directly (despite the many many issues with this idea), one of the main problems was EXACTLY what you describe, ACPI-fast takes too long to access and the get* variants just don't update quick enough HOWEVER, JK's changes STILL make sense in my opinion: - Many new NIC chipsets will timestamp packets directly in the driver. (Intel has one already that timestamps all packets, not just PTP/IEEE1588 ones). So using bpf_gettime() vs just blindly calling microtime() no matter what IS the right idea (including the mbuf tagging mechanism to tell bpf(4) you got a time, use it). - I don't see the use of the get* variants for anything above 100Mbps (as you say, they don't update fast enough), however there may be uses I am not thinking of (I think Guy mentioned he uses it). - I am told by Intel that going forward the TSC will now not only be P-state invariant BUT ALSO synced across packages on Nehalem based platforms and higher. I was going to start a new thread about this and sort of socialize this fact (they claim that all packages of ALL cores on the same motherboard will be clocked to the same oscillator and all drift equally provided you don't write TSC MSR directly - software resets have no effect on the TSC, once the BIOS performs a hard reset, the TSCs are all synchronized). *** That is what I am told by Intel. *** I realize this is much different than what everybody is used too. I am in the process of setting up a box to play with the TSC a bit (how does one test this, I was going to just read the tsc constantly across randomized cores and verify its at least monotonic?). Apparently Intel submitted some patches for Linux that skips its warp/sync test on boot up due to these new changes (i.e. I think by default on Nehalem based processors where the TSC is marked reliable (via CPUID bits), gettimeofday() calls use the TSC because its now reliable again - can somebody else confirm this?). Provided one COULD use the TSC which is much much faster than ACPI-fast, I believe the above changes make even more sense! I still like the changes! :) -aps From owner-freebsd-net@FreeBSD.ORG Thu Jun 10 14:24:52 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2C026106564A; Thu, 10 Jun 2010 14:24:52 +0000 (UTC) (envelope-from pisymbol@gmail.com) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id ECCE98FC17; Thu, 10 Jun 2010 14:24:51 +0000 (UTC) Received: by pxi7 with SMTP id 7so3487643pxi.13 for ; Thu, 10 Jun 2010 07:24:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=zt0CeQjsSrsqiSUjA247MbhV2HeuqtL0ngw1pVAsu+s=; b=vu//QYl0oW+02sefvRSGRwxGRarojRmFMXQMpTpmUNoIqTE4DcJ1mHMC04wx+lCzq5 LF/YPXmLYqhwN/XTaBkoBNyey1N9qC+vv7EhGmwlXNIoaYJugZdLMMVw+NvBmPcJ0h+w 9tRN+sIY8zVKhMG7B3+YgWZJDmpFp/ycwixp0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=XtEHoqUX3nNxFPkhJAj+hfSDt2tOpVFuilaY0wpHVLL+PAy7TUtQh81xVzVStPwoxU raABdZFnLEh+nkSOlqfnKxD13pehJDcN2LhrTKC6sV5RlpiEz5vznQjHqirjMYOz6iV+ 84AsQ7CH/1cuVXCga+ow2uSZyGqReqp8DC82Q= MIME-Version: 1.0 Received: by 10.114.187.18 with SMTP id k18mr211719waf.101.1276179890997; Thu, 10 Jun 2010 07:24:50 -0700 (PDT) Received: by 10.114.174.14 with HTTP; Thu, 10 Jun 2010 07:24:50 -0700 (PDT) In-Reply-To: References: Date: Thu, 10 Jun 2010 10:24:50 -0400 Message-ID: From: Alexander Sack To: Juli Mallett Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org, Jack Vogel Subject: Re: Dual-rate transceivers with 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: Thu, 10 Jun 2010 14:24:52 -0000 On Wed, Jun 9, 2010 at 11:01 PM, Juli Mallett wrote: > On Wed, Jun 9, 2010 at 19:56, Alexander Sack wrote: >> $ ifconfig ix1 >> ix1: flags=8802 metric 0 mtu 1500 > > You need to bring the interface up in order for the SFP configuration to occur. I am little bit confused: What's different with the ixgbe(4) than em(4)? i.e. My second em(4) interface auto-negotiates properly on boot up, why shouldn't ixgbe without having to do an additional ifconfig down/up cycle? (my ifconfig output above might be a little off since I was debugging my SFP issues). -aps From owner-freebsd-net@FreeBSD.ORG Thu Jun 10 17:03:09 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1507D1065675; Thu, 10 Jun 2010 17:03:09 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail02.syd.optusnet.com.au (mail02.syd.optusnet.com.au [211.29.132.183]) by mx1.freebsd.org (Postfix) with ESMTP id 880A08FC2A; Thu, 10 Jun 2010 17:03:07 +0000 (UTC) Received: from c122-106-175-69.carlnfd1.nsw.optusnet.com.au (c122-106-175-69.carlnfd1.nsw.optusnet.com.au [122.106.175.69]) by mail02.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o5AH35Oq002323 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Jun 2010 03:03:06 +1000 Date: Fri, 11 Jun 2010 03:03:04 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Alexander Sack In-Reply-To: Message-ID: <20100611014615.S34102@delplex.bde.org> References: <201006091444.50560.jkim@FreeBSD.org> <20100610173950.T33647@delplex.bde.org> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1966940048-1276189384=:34102" Cc: freebsd-net@freebsd.org, Jung-uk Kim Subject: Re: [RFC] BPF timestamping 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, 10 Jun 2010 17:03:09 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1966940048-1276189384=:34102 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Thu, 10 Jun 2010, Alexander Sack wrote: > On Thu, Jun 10, 2010 at 5:45 AM, Bruce Evans wrote= : >> On Wed, 9 Jun 2010, Jung-uk Kim wrote: >> >>> bpf(4) can only timestamp packets with microtime(9). =A0I want to expan= d >>> it to be able to use different format and resolution. =A0The patch is >>> here: >>> >>> http://people.freebsd.org/~jkim/bpf_tstamp.diff >>> >>> With this patch, we can select different format and resolution of the >>> timestamps. =A0It is done via ioctl(2) with BIOCSTSTAMP command. >>> Similarly, you can get the current format and resolution with >>> BIOCGTSTAMP command. =A0Currently, the following functions are >>> available: >>> >>> =A0 =A0 =A0 =A0BPF_T_MICROTIME =A0 =A0 =A0 =A0 microtime(9) [more \xa0 deleted] >> This has too many timestamp types, yet not one timestamp type which >> is any good except possibly BPF_T_NONE, and not one monotonic timestamp >> type. =A0Only external uses and compatibility require use of CLOCK_REALT= IME. > > None of these issues are bpf(4)) related though...you are blaming the > clock source (rightly so). > > bpf(4) is just a consumer, its not its job to validate clocks. The > kernel offers it so bpf(4) uses it. My main point is that no one knows how to choose the best clock, partly because there isn't one, so bpf and its consumers won't know either, or shouldn't, because such knowledge should be in the kernel. > Again, I agree that bpf(4) has really no way to validate whether the > clock its using has the precision to generate a valid timestamp. Not quite. bpf or userland in conjunction with bpf could call clock_getres(CLOCK_XXX), where XXX is REALTIME[_PRECISE] corresponding to BPF_T_NANOTIME and REALTIME_FAST corresponding to BPF_T_NANOTIME_FAST, and unavailable for the other bpf ioctl values, and if clock_getres() worked as well as possible, then bpf could tell if the clock has enough precision. clock_getres() works reasonably well for CLOCK_REALTIME_PRECISE (it gives the same "resolution" as the hardware clock, although the time delivered is not usually a multiple of that), but for CLOCK_REALTIME_FAST it returns the same as for CLOCK_REALTIME_PRECISE and is thus useless (it should return the get* update interval tc_tick * hz). POSIX is as confused as anyone about the difference between precision, resolution and accuracy so its clock_getres() is misnamed and/or underspecified, but to be useful it has to return a value related to the clock's update interval and not one related to the number of trailing zeros (or multiple of a non power of 10) in the nanoseconds field of interface. > I ran into this exact problem trying to ACPI-fast timecounter in the > bge(4) driver as an experiment to timestamp packets directly (despite > the many many issues with this idea), one of the main problems was > EXACTLY what you describe, ACPI-fast takes too long to access and the > get* variants just don't update quick enough I still mostly run UP systems where the TSC works. Then microtime() works very well for timestamping groups of packets at interrupt time. Raw TSC reads would have worked a bit faster, but using microtime() gave correctness (except I should have used microuptime()) and a convenient conversion at little cost. > HOWEVER, JK's changes STILL make sense in my opinion: > > - Many new NIC chipsets will timestamp packets directly in the driver. > (Intel has one already that timestamps all packets, not just > PTP/IEEE1588 ones). So using bpf_gettime() vs just blindly calling > microtime() no matter what IS the right idea (including the mbuf > tagging mechanism to tell bpf(4) you got a time, use it). I agree with that. vfs_timestamp() does the same things for file systems, but has the bugs that it is system-wide (should be per file system) and not all file systems use it. > - I don't see the use of the get* variants for anything above 100Mbps > (as you say, they don't update fast enough), however there may be uses > I am not thinking of (I think Guy mentioned he uses it). Above 1Mbps for me :-). Its still surely not useful to have nanosecond and weeniesecond precisions, and would be more useful to have a bpf-specifi= c version that combines a timestamp (maybe in seconds resolution) with a generation count. phk wouldn't want a generation count on the get*time() functions for the same reasons that he didn't want to fix them to be coherent with the non-get* ones -- this would require locking on every *time() read. A bpf-specific version might be able to avoid additional locking for the generation count or at least localize it better. > - I am told by Intel that going forward the TSC will now not only be > P-state invariant BUT ALSO synced across packages on Nehalem based > platforms and higher. I was going to start a new thread about this > and sort of socialize this fact (they claim that all packages of ALL > cores on the same motherboard will be clocked to the same oscillator > and all drift equally provided you don't write TSC MSR directly - > software resets have no effect on the TSC, once the BIOS performs a > hard reset, the TSCs are all synchronized). Is it already synced across cores within a package on pre-Nehalem? I was going to mention in my original reply that it seems to be synced on FreeBSD cluster machines which are Xeon 0x6f7 whatever that is. > *** That is what I am told by Intel. *** > > I realize this is much different than what everybody is used too. I > am in the process of setting up a box to play with the TSC a bit (how > does one test this, I was going to just read the tsc constantly across > randomized cores and verify its at least monotonic?). Apparently My tests don't do the randomization properly and SCHED_ULE does too good a kob of keeping threads on the same CPU. However, with 64 threads on 8 CPUs, threads migrate occasionally and this doesn't cause any noticeable glitches in a TSC calibration program. > Intel submitted some patches for Linux that skips its warp/sync test > on boot up due to these new changes (i.e. I think by default on > Nehalem based processors where the TSC is marked reliable (via CPUID Shouldn't it still do the test? At least it has one. > bits), gettimeofday() calls use the TSC because its now reliable again > - can somebody else confirm this?). Provided one COULD use the TSC > which is much much faster than ACPI-fast, I believe the above changes > make even more sense! Nah, with a working TSC timecounter almost everything can just use microtime() :-). There is still the problem that rdtsc() is not serializing and you don't want it to be. I have never noticed this causing time warps though there must have been many for timestamping of function calls in high resolution kernel profiling. The extra code in microtime() may prevent time warps for timestamping at an even lower level, and packet timestamping is at a higher level and is associated with i/o which may imply sufficient serialization. Bruce --0-1966940048-1276189384=:34102-- From owner-freebsd-net@FreeBSD.ORG Thu Jun 10 17:03:26 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F20171065707; Thu, 10 Jun 2010 17:03:25 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 831298FC16; Thu, 10 Jun 2010 17:03:25 +0000 (UTC) Received: by vws1 with SMTP id 1so176892vws.13 for ; Thu, 10 Jun 2010 10:03:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=spmK17GZC+lkMF6DKflPFdHTD3Vq39Vr6+eRHwCLOp8=; b=a40HyKsuTx1osKpA7YRgstzUKkvW0zeDX3dc2qYv7mjmGtYXkMcvGrlpK1LaPmzp8n mo849sVUDcyFABLNV1LIKo1HqjBHjNS90UJppdtuLHteGgaMPq9/gZmjm1QGM4lhV9eO XLbaen/KLbf1eB58UfKUGWCA7wbr12keBDKbQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=wn1A93oK6YC2CM98kAiIupwHtP24MyKXN66Z2Bqk5btYUfizRlZFyOrtyh05tIgljk RRPiUX78BapedXuyLyiXk9FpgSrnJeuRnZxi1K01tuGZ+T1BUtfangcky2OS6dp/kan8 yhqPB5jGK0f3a0N5VWaOaoZA0bhXeOD2TYHwA= MIME-Version: 1.0 Received: by 10.224.19.100 with SMTP id z36mr473785qaa.84.1276189404356; Thu, 10 Jun 2010 10:03:24 -0700 (PDT) Received: by 10.229.238.199 with HTTP; Thu, 10 Jun 2010 10:03:24 -0700 (PDT) In-Reply-To: References: Date: Thu, 10 Jun 2010 10:03:24 -0700 Message-ID: From: Jack Vogel To: Alexander Sack Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Juli Mallett , freebsd-net@freebsd.org Subject: Re: Dual-rate transceivers with 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: Thu, 10 Jun 2010 17:03:26 -0000 Well, em doesn't have a pluggable phy :) Hardware is different, that's why there's a different driver.... Jack On Thu, Jun 10, 2010 at 7:24 AM, Alexander Sack wrote: > On Wed, Jun 9, 2010 at 11:01 PM, Juli Mallett > wrote: > > On Wed, Jun 9, 2010 at 19:56, Alexander Sack wrote: > >> $ ifconfig ix1 > >> ix1: flags=8802 metric 0 mtu 1500 > > > > You need to bring the interface up in order for the SFP configuration to > occur. > > I am little bit confused: > > What's different with the ixgbe(4) than em(4)? i.e. My second em(4) > interface auto-negotiates properly on boot up, why shouldn't ixgbe > without having to do an additional ifconfig down/up cycle? > > (my ifconfig output above might be a little off since I was debugging > my SFP issues). > > -aps > From owner-freebsd-net@FreeBSD.ORG Thu Jun 10 17:14:09 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 93FA1106564A; Thu, 10 Jun 2010 17:14:09 +0000 (UTC) (envelope-from pisymbol@gmail.com) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5FF358FC15; Thu, 10 Jun 2010 17:14:09 +0000 (UTC) Received: by pxi7 with SMTP id 7so78418pxi.13 for ; Thu, 10 Jun 2010 10:14:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=KR/LZ50hgWXMilUVBbRMsJBaZenEW31+K11kJ1r+Kw0=; b=k0xX1dgzFtULP9xAk7v9fQdRzAd9Bqo/qYKK7Z+bhLSm0aGhCLLi3Dr4Hawq6P9bXG LlaV658ECRRsocKIJNudsUtWihZ/NfGCeqcxMUrhqJdncKqbUV08uY3RvzJnlK7FbeR4 BQPy0CQ7rvmvJGTBwrGFVRI5tfEtszVVRoCug= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ZpGW9QWYodO94UuRAiJifqJ7rLP8NHH5wSwvhsW5zrYPtXbHb9L0OLDwIywo+MkZBY liTgm+nJtgZRqlQQXp6q26zgKZq8JSR+L9hA29mYmXc4Y9in67EMoycG7LeOAzJGDRPO 1XcWZwrqG+a0xIp8br5fqx9SHI0Ivb2JSK2Ag= MIME-Version: 1.0 Received: by 10.115.101.14 with SMTP id d14mr374658wam.176.1276190048645; Thu, 10 Jun 2010 10:14:08 -0700 (PDT) Received: by 10.115.73.20 with HTTP; Thu, 10 Jun 2010 10:14:08 -0700 (PDT) In-Reply-To: References: Date: Thu, 10 Jun 2010 13:14:08 -0400 Message-ID: From: Alexander Sack To: Jack Vogel Content-Type: text/plain; charset=ISO-8859-1 Cc: Juli Mallett , freebsd-net@freebsd.org Subject: Re: Dual-rate transceivers with 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: Thu, 10 Jun 2010 17:14:09 -0000 On Thu, Jun 10, 2010 at 1:03 PM, Jack Vogel wrote: > Well, em doesn't have a pluggable phy :) Hardware is different, that's why > there's > a different driver.... Thanks Juli/Jack. I didn't know that! And knowing is half the battle... So, not to completely hijack Juli's thread (sorry), but what about these SFP issues. What was the point of the code I mentioned? Am I living that dangerously commenting it out? What's the real fix here? -aps From owner-freebsd-net@FreeBSD.ORG Thu Jun 10 17:58:42 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D64C910656BF; Thu, 10 Jun 2010 17:58:42 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 632938FC16; Thu, 10 Jun 2010 17:58:41 +0000 (UTC) Received: by vws1 with SMTP id 1so235536vws.13 for ; Thu, 10 Jun 2010 10:58:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=M7h9svc9klY9eJO++7Zff0m0ZCNmiRMhMotcTDRa73Y=; b=GSkeoKl4dF7OiuQpXpnRqwmFahXFoHe0NFZ+/+W11rWRr5X1lY/TQ99WBpmX8UUS0c dpKZ2n/fMZfrEM3JvY+pcR8sud8A1u0K8ZON8bbi6kCSN2J7cPCitERO7GnB0z4QQ7yk SWTsylRBjXu++8T9JXrXiLCqe6faJAS8KFkTE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=YkE+kEFci/nbhJYvKwkOSVmg6ZAzbI8t/Ab3T7tobvniwzQwGjEvoH1ZIoto6Ldup6 aux2ze5CE8BDOeJT1TUun1S//29zT22qXAr3Lv5lT0MP4LhGprgLU7s4sSXLUhDr9GmU wQyJz0jMXvtu4LsRgEiUdUX6mrb/vbjNlAvTw= MIME-Version: 1.0 Received: by 10.224.124.212 with SMTP id v20mr505083qar.278.1276192721137; Thu, 10 Jun 2010 10:58:41 -0700 (PDT) Received: by 10.229.238.199 with HTTP; Thu, 10 Jun 2010 10:58:41 -0700 (PDT) In-Reply-To: References: Date: Thu, 10 Jun 2010 10:58:41 -0700 Message-ID: From: Jack Vogel To: Alexander Sack Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Juli Mallett , freebsd-net@freebsd.org Subject: Re: Dual-rate transceivers with 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: Thu, 10 Jun 2010 17:58:42 -0000 I believe I've explained this once before. The limitation code is put in explicitly because its what we support and all we support, we know that some hardware out there will not work, some may. If you buy the hardware you would be wise to make sure you get what's supported, but please don't ask me how to hack around it or what it means when you have problems when you do. In the first place I dont have the time, second, I do not have the hardware or means to test that, and finally I need to abide by what my management tells me... you do all want me to keep my job yes? :) Cheers, Jack On Thu, Jun 10, 2010 at 10:14 AM, Alexander Sack wrote: > On Thu, Jun 10, 2010 at 1:03 PM, Jack Vogel wrote: > > Well, em doesn't have a pluggable phy :) Hardware is different, that's > why > > there's > > a different driver.... > > Thanks Juli/Jack. I didn't know that! And knowing is half the battle... > > So, not to completely hijack Juli's thread (sorry), but what about > these SFP issues. What was the point of the code I mentioned? Am I > living that dangerously commenting it out? What's the real fix here? > > -aps > From owner-freebsd-net@FreeBSD.ORG Thu Jun 10 19:04:37 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DA198106567A; Thu, 10 Jun 2010 19:04:37 +0000 (UTC) (envelope-from pisymbol@gmail.com) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id 9E9A58FC1D; Thu, 10 Jun 2010 19:04:37 +0000 (UTC) Received: by pxi7 with SMTP id 7so129239pxi.13 for ; Thu, 10 Jun 2010 12:04:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=RF8awiigShfvWOPOGUKSc8b4p2Sm5TCRpJ+KEd59mrE=; b=E5zVi51j7GLZbyJvTZ0ER4iht3HCfTWFpuqg6IPZBLLBcHft8qRU7XgcukXTwYZdbv NVXgb66y/0hx73J7Kjx8F5AIcwMylb90nov/GTu00o+yQbeNVGVpm/PPPQB73CZ6yHoI zWSCfyMD8map0bj4uKct2Q1nd0lw2tsoI1sPI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=QCEmS6TsinpSorI7YTLjzde+1UrNNd/cAq9KIoELEgcxkoDKHn00RfDBlHFsNycKFW zG48wj9CCjw/tO0nC7MwKZe8IuOVEL1nw3XNygEmyp1D5pX9ZugzYm6oU8JEYA+3zEJX 5CETqixAlgNwbrcN9q6PjcruEB53s/kpUDBGU= MIME-Version: 1.0 Received: by 10.115.103.40 with SMTP id f40mr523031wam.38.1276196677255; Thu, 10 Jun 2010 12:04:37 -0700 (PDT) Received: by 10.115.73.20 with HTTP; Thu, 10 Jun 2010 12:04:37 -0700 (PDT) In-Reply-To: References: Date: Thu, 10 Jun 2010 15:04:37 -0400 Message-ID: From: Alexander Sack To: Jack Vogel Content-Type: multipart/mixed; boundary=0016e64ccb969c81bb0488b1b1e4 Cc: Juli Mallett , freebsd-net@freebsd.org Subject: Re: Dual-rate transceivers with 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: Thu, 10 Jun 2010 19:04:37 -0000 --0016e64ccb969c81bb0488b1b1e4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Jun 10, 2010 at 1:58 PM, Jack Vogel wrote: > I believe I've explained this once before. The limitation code is put in > explicitly > because its what we support and all we support, we know that some hardwar= e > out there will not work, some may. > > If you buy the hardware you would be wise to make sure you get what's > supported, > but please don't ask me how to hack around it or what it means when you h= ave > problems when you do.=A0=A0 In the first place I dont have the time, seco= nd, I > do not > have the hardware or means to test that, and finally I need to abide by w= hat > my > management tells me...=A0 you do all want me to keep my job yes? :) I certainly do Jack! LOL. However, would it be possible to please make this a kenv tunable in the driver? Its kinda stupid I have to recompile to add a SFP. It can certainly be an unsupported feature by you. Patch attached. Tested with CURRENT driver on a 7.2-amd64-release machine. If you set the tunable to 1, ixgbe loads without issue. If you leave it to zero (default), it will not attach to unsupported SFPs. I also added DEBUGOUT6 since it was missing and caused a compilation failure when I turned on in-driver debugging. What do you think? -aps --0016e64ccb969c81bb0488b1b1e4 Content-Type: application/octet-stream; name="ixgbe-sfp.patch" Content-Disposition: attachment; filename="ixgbe-sfp.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_ga9yj5ox1 SW5kZXg6IGl4Z2JlLmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gaXhnYmUuYwkocmV2aXNpb24gMjA4OTUwKQor KysgaXhnYmUuYwkod29ya2luZyBjb3B5KQpAQCAtMjg0LDYgKzI4NCwxMyBAQAogc3RhdGljIGlu dCBpeGdiZV9yeGQgPSBQRVJGT1JNX1JYRDsKIFRVTkFCTEVfSU5UKCJody5peGdiZS5yeGQiLCAm aXhnYmVfcnhkKTsKIAorLyogCisgKiBBbGxvdyBjb25maWd1cmF0aW9uIG9mIHVuc3VwcG9ydGVk IFNGUHMuICAKKyAqIFVzZSBhdCB5b3VyIG93biByaXNrLiAKKyAqLworaW50IGl4Z2JlX2FsbG93 X3Vuc3VwcG9ydGVkX3NmcCA9IDA7CitUVU5BQkxFX0lOVCgiaHcuaXhnYmUuYWxsb3dfdW5zdXBw b3J0ZWRfc2ZwIiwgJml4Z2JlX2FsbG93X3Vuc3VwcG9ydGVkX3NmcCk7CisKIC8qIEtlZXAgcnVu bmluZyB0YWIgb24gdGhlbSBmb3Igc2FuaXR5IGNoZWNrICovCiBzdGF0aWMgaW50IGl4Z2JlX3Rv dGFsX3BvcnRzOwogCkluZGV4OiBpeGdiZV9waHkuYwo9PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBpeGdiZV9waHku YwkocmV2aXNpb24gMjA4OTUwKQorKysgaXhnYmVfcGh5LmMJKHdvcmtpbmcgY29weSkKQEAgLTQ5 LDYgKzQ5LDggQEAKIHN0YXRpYyBib29sIGl4Z2JlX2dldF9pMmNfZGF0YSh1MzIgKmkyY2N0bCk7 CiB2b2lkIGl4Z2JlX2kyY19idXNfY2xlYXIoc3RydWN0IGl4Z2JlX2h3ICpodyk7CiAKK2V4dGVy biBpbnQgaXhnYmVfYWxsb3dfdW5zdXBwb3J0ZWRfc2ZwOworCiAvKioKICAqICBpeGdiZV9pbml0 X3BoeV9vcHNfZ2VuZXJpYyAtIEluaXRzIFBIWSBmdW5jdGlvbiBwdHJzCiAgKiAgQGh3OiBwb2lu dGVyIHRvIHRoZSBoYXJkd2FyZSBzdHJ1Y3R1cmUKQEAgLTExMDYsNyArMTEwOCw4IEBACiAJCX0K IAogCQlpeGdiZV9nZXRfZGV2aWNlX2NhcHMoaHcsICZlbmZvcmNlX3NmcCk7Ci0JCWlmICghKGVu Zm9yY2Vfc2ZwICYgSVhHQkVfREVWSUNFX0NBUFNfQUxMT1dfQU5ZX1NGUCkpIHsKKwkJaWYgKCEo ZW5mb3JjZV9zZnAgJiBJWEdCRV9ERVZJQ0VfQ0FQU19BTExPV19BTllfU0ZQKSAmJiAKKwkJICAg IChpeGdiZV9hbGxvd191bnN1cHBvcnRlZF9zZnAgPT0gMCkpIHsKIAkJCS8qIE1ha2Ugc3VyZSB3 ZSdyZSBhIHN1cHBvcnRlZCBQSFkgdHlwZSAqLwogCQkJaWYgKGh3LT5waHkudHlwZSA9PSBpeGdi ZV9waHlfc2ZwX2ludGVsKSB7CiAJCQkJc3RhdHVzID0gSVhHQkVfU1VDQ0VTUzsKSW5kZXg6IGl4 Z2JlX29zZGVwLmgKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PQotLS0gaXhnYmVfb3NkZXAuaAkocmV2aXNpb24gMjA4OTUw KQorKysgaXhnYmVfb3NkZXAuaAkod29ya2luZyBjb3B5KQpAQCAtNjcsNiArNjcsNyBAQAogCSNk ZWZpbmUgREVCVUdPVVQxKFMsQSkgICAgICBwcmludGYoUyAiXG4iLEEpCiAJI2RlZmluZSBERUJV R09VVDIoUyxBLEIpICAgIHByaW50ZihTICJcbiIsQSxCKQogCSNkZWZpbmUgREVCVUdPVVQzKFMs QSxCLEMpICBwcmludGYoUyAiXG4iLEEsQixDKQorCSNkZWZpbmUgREVCVUdPVVQ2KFMsQSxCLEMs RCxFLEYpICAgIHByaW50ZihTICJcbiIsQSxCLEMsRCxFLEYpCiAJI2RlZmluZSBERUJVR09VVDco UyxBLEIsQyxELEUsRixHKSAgcHJpbnRmKFMgIlxuIixBLEIsQyxELEUsRixHKQogI2Vsc2UKIAkj ZGVmaW5lIERFQlVHT1VUKFMpCg== --0016e64ccb969c81bb0488b1b1e4-- From owner-freebsd-net@FreeBSD.ORG Thu Jun 10 19:20:38 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7E5C91065672 for ; Thu, 10 Jun 2010 19:20:38 +0000 (UTC) (envelope-from juli@clockworksquid.com) Received: from mail-pz0-f175.google.com (mail-pz0-f175.google.com [209.85.222.175]) by mx1.freebsd.org (Postfix) with ESMTP id 56FFC8FC14 for ; Thu, 10 Jun 2010 19:20:38 +0000 (UTC) Received: by pzk5 with SMTP id 5so152341pzk.14 for ; Thu, 10 Jun 2010 12:20:38 -0700 (PDT) Received: by 10.114.10.14 with SMTP id 14mr530021waj.72.1276197637912; Thu, 10 Jun 2010 12:20:37 -0700 (PDT) MIME-Version: 1.0 Sender: juli@clockworksquid.com Received: by 10.114.241.2 with HTTP; Thu, 10 Jun 2010 12:20:17 -0700 (PDT) In-Reply-To: References: From: Juli Mallett Date: Thu, 10 Jun 2010 12:20:17 -0700 X-Google-Sender-Auth: pKs71sLnpR7Z9tpoSi4V0HhZNLQ Message-ID: To: Alexander Sack Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, Jack Vogel Subject: Re: Dual-rate transceivers with 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: Thu, 10 Jun 2010 19:20:38 -0000 On Thu, Jun 10, 2010 at 12:04, Alexander Sack wrote: > However, would it be possible to please make this a kenv tunable in > the driver? =A0Its kinda stupid I have to recompile to add a SFP. =A0It > can certainly be an unsupported feature by you. This is a good idea, but asking Jack to commit something that goes against Intel's wishes and which he's not going to support is probably a losing strategy. Whether he minds someone else committing might be another story :) One thing that the base driver probably ought to do is not fail in attach if there's an unrecognized SFP+ module. Since we get interrupts on module change (although this doesn't seem to always work *entirely* right in the stock sources, mostly wrt stored values of AUTOC and the like) it should be possible to bring the interface up with the unsupported (and disabled) SFP+ module and do the SFP+ module probing we already do on hot-swap. > Patch attached. =A0Tested with CURRENT driver on a 7.2-amd64-release > machine. =A0If you set the tunable to 1, ixgbe loads without issue. =A0If > you leave it to zero (default), it will not attach to unsupported > SFPs. If you're going to do this, you ought to support SFP as well as SFP+ modules which requires a few more changes. But not very many :) Although some SFP modules seem to return something for the comp_codes_10g read, which makes deciding which SFI mode to configure non-trivial, short of providing an actual vendor/model switch. Thanks, Juli. From owner-freebsd-net@FreeBSD.ORG Thu Jun 10 19:59:04 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 69CB4106574E; Thu, 10 Jun 2010 19:59:04 +0000 (UTC) (envelope-from pisymbol@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id D3B5C8FC19; Thu, 10 Jun 2010 19:59:02 +0000 (UTC) Received: by gwj20 with SMTP id 20so336913gwj.13 for ; Thu, 10 Jun 2010 12:59:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=wqvzOTUYwOE+Zfs34Ov/AH2Al0+uzcN1pHDlj4qtvls=; b=jBJ073a67MVWUuFImRvnM/xvGW4kyJro6DT0Xg0vbbWH+xT8rBVdJ9Y2HHu4vAiIim WdhuPB9MvhawEceGzn/NZ++s8IYqRLWqGPwcVHrDJnMfN5OGpb14cjR05as+FNlcj1P0 Ngzabvf7rN0gTxBC1OvOCbFWF+DNplo4dVlcw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=oNw2oGN6RuTwMKaMeGaFsWJhKjx8BljvVtzioxwQBrQVjNv9b50yKU886cCDRJM3LV lpSmN+GTZ+poE3pnPagSwh4TAO4r4JWj4Uj/ViOFTRx866MfBsxXkIMP/43Ew0QWDyjQ JBoUTPvG896jq8F2ZJqup9vci2/oVdXBDoUuU= MIME-Version: 1.0 Received: by 10.101.3.38 with SMTP id f38mr658455ani.90.1276199941542; Thu, 10 Jun 2010 12:59:01 -0700 (PDT) Received: by 10.100.137.4 with HTTP; Thu, 10 Jun 2010 12:59:01 -0700 (PDT) In-Reply-To: References: Date: Thu, 10 Jun 2010 15:59:01 -0400 Message-ID: From: Alexander Sack To: Juli Mallett Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, Jack Vogel Subject: Re: Dual-rate transceivers with 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: Thu, 10 Jun 2010 19:59:04 -0000 On Thu, Jun 10, 2010 at 3:20 PM, Juli Mallett wrote: > On Thu, Jun 10, 2010 at 12:04, Alexander Sack wrote: >> However, would it be possible to please make this a kenv tunable in >> the driver? =A0Its kinda stupid I have to recompile to add a SFP. =A0It >> can certainly be an unsupported feature by you. > > This is a good idea, but asking Jack to commit something that goes > against Intel's wishes and which he's not going to support is probably > a losing strategy. =A0Whether he minds someone else committing might be > another story :) Sorry Jack! :) I am not trying to cause you grief but.... It would SEEM BENEFICIAL to the community to allow unsupported SFPs (again use at your own risk, don't ask Jack why doesn't it work and expect a lot of attention). That's all I am saying. I don't know the history here, so if this topic has been heavily debated on the lists, please forgive. I am also not trying to upset Jack or Intel or anyone here. Good intentions an all that!? > One thing that the base driver probably ought to do is not fail in > attach if there's an unrecognized SFP+ module. =A0Since we get > interrupts on module change (although this doesn't seem to always work > *entirely* right in the stock sources, mostly wrt stored values of > AUTOC and the like) it should be possible to bring the interface up > with the unsupported (and disabled) SFP+ module and do the SFP+ module > probing we already do on hot-swap. Alright, let me see if I can test that. Let me rephrase so I validate what you are saying: The driver can come up with an unsupported module but disable the interface (ifconfig shows the interface, etc.). If you then hot-swap a supported SFP, it should come up then with a ifconfig down/up cycle. Right? As it stand now, if you load the driver with an unsupported module, it will not attach at all causing you to reload the entire driver OR reboot the box to have it reattach to the other SFP. Do I understand you correctly? >> Patch attached. =A0Tested with CURRENT driver on a 7.2-amd64-release >> machine. =A0If you set the tunable to 1, ixgbe loads without issue. =A0I= f >> you leave it to zero (default), it will not attach to unsupported >> SFPs. > > If you're going to do this, you ought to support SFP as well as SFP+ > modules which requires a few more changes. =A0But not very many :) LOL....right....let me adjust...let me look at the SFP path. > Although some SFP modules seem to return something for the > comp_codes_10g read, which makes deciding which SFI mode to configure > non-trivial, short of providing an actual vendor/model switch. I want to avoid this completely. There is already a vendor_oui switch which I now understand are the specific SFPs Intel tests and certifies with! (right?) I think the policy should be (ideally): - Attach to all supported tested Intel stamp-of-approval SFPs (normal driver path) - Disable any unsupported SFPs but still complete driver attachment - Tunable to control attaching to an unsupported SFP (YOU AT YOUR OWN RISK) Is that right? -aps From owner-freebsd-net@FreeBSD.ORG Thu Jun 10 20:02:25 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D5238106566B; Thu, 10 Jun 2010 20:02:25 +0000 (UTC) (envelope-from pisymbol@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 655528FC19; Thu, 10 Jun 2010 20:02:25 +0000 (UTC) Received: by gyh20 with SMTP id 20so338498gyh.13 for ; Thu, 10 Jun 2010 13:02:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=FqQWD4gxEajH+/FaBQFeY93Bw3lL2A/i9EUhpXDgAE0=; b=tTo6LGktomN7clE6wgUw1g0k+He7ZPDbk/x/8eY9BGjKkPMrXJeC7yVIGtGsuXZNXh Vu5tmraUHk8FqnAUZ4UKUMPx5P4ptrd/2KMjxUUyWfG1pE+p3POLuooSR0gQPUneCf4V CKhKXlHdhxILmWlRFzqLWVsh9+cyaRQp9ujeg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=CU6pOMpsZNceXSiegC2ff3HWEOuChoa4S4ybQJpAxFG+H/p/c/QgY3zP8+LhLklsE3 DNBRe87loNOPLqYdB4xcpbz+tEtEo1qiXhNsfJdCbnrXD2Nz5bZYyYoI0gxyBgg9YZ3q ee5VNiJnijrlx1IWoE1IrF0nFAaseWzq9rzN4= MIME-Version: 1.0 Received: by 10.101.145.9 with SMTP id x9mr700693ann.13.1276200143614; Thu, 10 Jun 2010 13:02:23 -0700 (PDT) Received: by 10.100.137.4 with HTTP; Thu, 10 Jun 2010 13:02:23 -0700 (PDT) In-Reply-To: References: Date: Thu, 10 Jun 2010 16:02:23 -0400 Message-ID: From: Alexander Sack To: Juli Mallett Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, Jack Vogel Subject: Re: Dual-rate transceivers with 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: Thu, 10 Jun 2010 20:02:25 -0000 On Thu, Jun 10, 2010 at 3:59 PM, Alexander Sack wrote: > On Thu, Jun 10, 2010 at 3:20 PM, Juli Mallett wrot= e: >> On Thu, Jun 10, 2010 at 12:04, Alexander Sack wrote= : >>> However, would it be possible to please make this a kenv tunable in >>> the driver? =A0Its kinda stupid I have to recompile to add a SFP. =A0It >>> can certainly be an unsupported feature by you. >> >> This is a good idea, but asking Jack to commit something that goes >> against Intel's wishes and which he's not going to support is probably >> a losing strategy. =A0Whether he minds someone else committing might be >> another story :) > > Sorry Jack! =A0:) =A0I am not trying to cause you grief but.... > > It would SEEM BENEFICIAL to the community to allow unsupported SFPs > (again use at your own risk, don't ask Jack why doesn't it work and > expect a lot of attention). =A0That's all I am saying. =A0I don't know th= e > history here, so if this topic has been heavily debated on the lists, > please forgive. > > I am also not trying to upset Jack or Intel or anyone here. =A0Good > intentions an all that!? > >> One thing that the base driver probably ought to do is not fail in >> attach if there's an unrecognized SFP+ module. =A0Since we get >> interrupts on module change (although this doesn't seem to always work >> *entirely* right in the stock sources, mostly wrt stored values of >> AUTOC and the like) it should be possible to bring the interface up >> with the unsupported (and disabled) SFP+ module and do the SFP+ module >> probing we already do on hot-swap. > > Alright, let me see if I can test that. =A0Let me rephrase so I validate > what you are saying: > > The driver can come up with an unsupported module but disable the > interface (ifconfig shows the interface, etc.). > > If you then hot-swap a supported SFP, it should come up then with a > ifconfig down/up cycle. =A0Right? > > As it stand now, if you load the driver with an unsupported module, it > will not attach at all causing you to reload the entire driver OR > reboot the box to have it reattach to the other SFP. > > Do I understand you correctly? > >>> Patch attached. =A0Tested with CURRENT driver on a 7.2-amd64-release >>> machine. =A0If you set the tunable to 1, ixgbe loads without issue. =A0= If >>> you leave it to zero (default), it will not attach to unsupported >>> SFPs. >> >> If you're going to do this, you ought to support SFP as well as SFP+ >> modules which requires a few more changes. =A0But not very many :) > > LOL....right....let me adjust...let me look at the SFP path. > >> Although some SFP modules seem to return something for the >> comp_codes_10g read, which makes deciding which SFI mode to configure >> non-trivial, short of providing an actual vendor/model switch. > > I want to avoid this completely. =A0There is already a vendor_oui switch > which I now understand are the specific SFPs Intel tests and certifies > with! =A0(right?) > > I think the policy should be (ideally): > > - Attach to all supported tested Intel stamp-of-approval SFPs (normal > driver path) > - Disable any unsupported SFPs but still complete driver attachment > - Tunable to control attaching to an unsupported SFP (YOU AT YOUR OWN RIS= K) > > Is that right? > Sorry for the mixed conversation in that last email....I think you guys can figure out who is who! :-)! -aps From owner-freebsd-net@FreeBSD.ORG Thu Jun 10 21:12:35 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4DF021065674; Thu, 10 Jun 2010 21:12:35 +0000 (UTC) (envelope-from aboyer@averesystems.com) Received: from zimbra.averesystems.com (75-149-8-243-Pennsylvania.hfc.comcastbusiness.net [75.149.8.243]) by mx1.freebsd.org (Postfix) with ESMTP id 01A7B8FC17; Thu, 10 Jun 2010 21:12:34 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zimbra.averesystems.com (Postfix) with ESMTP id 7F3408BC915; Thu, 10 Jun 2010 17:12:59 -0400 (EDT) X-Virus-Scanned: amavisd-new at averesystems.com Received: from zimbra.averesystems.com ([127.0.0.1]) by localhost (zimbra.averesystems.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A5erruFjJnzX; Thu, 10 Jun 2010 17:12:58 -0400 (EDT) Received: from riven.arriad.com (fw.arriad.com [10.0.0.16]) by zimbra.averesystems.com (Postfix) with ESMTPSA id 87BDE8BC048; Thu, 10 Jun 2010 17:12:58 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Andrew Boyer In-Reply-To: Date: Thu, 10 Jun 2010 17:12:32 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <82D310BD-48DE-4F79-84C6-356AB4F04C42@averesystems.com> References: To: Alexander Sack X-Mailer: Apple Mail (2.1078) Cc: Juli Mallett , freebsd-net@freebsd.org, Jack Vogel Subject: Re: Dual-rate transceivers with 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: Thu, 10 Jun 2010 21:12:35 -0000 On Jun 10, 2010, at 3:59 PM, Alexander Sack wrote: >=20 >> One thing that the base driver probably ought to do is not fail in >> attach if there's an unrecognized SFP+ module. Since we get >> interrupts on module change (although this doesn't seem to always = work >> *entirely* right in the stock sources, mostly wrt stored values of >> AUTOC and the like) it should be possible to bring the interface up >> with the unsupported (and disabled) SFP+ module and do the SFP+ = module >> probing we already do on hot-swap. >=20 > Alright, let me see if I can test that. Let me rephrase so I validate > what you are saying: >=20 > The driver can come up with an unsupported module but disable the > interface (ifconfig shows the interface, etc.). >=20 > If you then hot-swap a supported SFP, it should come up then with a > ifconfig down/up cycle. Right? >=20 > As it stand now, if you load the driver with an unsupported module, it > will not attach at all causing you to reload the entire driver OR > reboot the box to have it reattach to the other SFP. >=20 We use this patch to allow the driver to attach when no module is = installed. This might be a starting point for you. I haven't tested it = without all of our other changes in place so my apologies if it doesn't = quite work. We only have Intel modules around for testing. -Andrew --- ixgbe.c 2010-06-10 16:53:08.000000000 -0400 +++ ixgbe.c 2010-06-10 16:55:26.000000000 -0400 @@ -566,7 +566,7 @@ } else if (error =3D=3D IXGBE_ERR_SFP_NOT_SUPPORTED) device_printf(dev,"Unsupported SFP+ Module\n"); =20 - if (error) { + if (error && error !=3D IXGBE_ERR_SFP_NOT_PRESENT) { error =3D EIO; device_printf(dev,"Hardware Initialization Failure\n"); goto err_late; --- ixgbe_82598.c 2010-06-10 16:53:24.000000000 -0400 +++ ixgbe_82598.c 2010-06-10 16:56:31.000000000 -0400 @@ -257,10 +257,6 @@ ret_val =3D ixgbe_get_sfp_init_sequence_offsets(hw, = &list_offset, = &data_offset); - if (ret_val !=3D IXGBE_SUCCESS) { - ret_val =3D IXGBE_ERR_SFP_NOT_SUPPORTED; - goto out; - } break; default: break; -------------------------------------------------- Andrew Boyer aboyer@averesystems.com From owner-freebsd-net@FreeBSD.ORG Thu Jun 10 21:25:13 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C6EA91065672; Thu, 10 Jun 2010 21:25:13 +0000 (UTC) (envelope-from pisymbol@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 555FD8FC12; Thu, 10 Jun 2010 21:25:13 +0000 (UTC) Received: by gwj20 with SMTP id 20so415228gwj.13 for ; Thu, 10 Jun 2010 14:25:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=LRMzhV9XAheF0WwvsCO6HGeX/Skq4y0evTrrrNBWQAc=; b=h3THDjYbqNsjCl755bPy09B83e93gWV5RaJSf4IvlmXGOVVBpG01Nr2RzyaNFNZCyE 58ThOtuQkD/Ftz8+Ukj0PzFP0GjyU0o0wc+elZpvN0D74kQlrJsNs24X2o2C3rLf36Q9 RwRsO6045FSk7GyV1m+i/lqOQfSmi2IPGBNAg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=WfuwWwhhKDAVRF8MtWFAcrlrX9rzHl1nEgB8etBR06WAsmAkVKoRx0f1w3oT1aUhM9 n1WA0ARs9CwTcJcd4kCqhpgdsWmU3J0K3rGfksyJb/TS4j8tYGZ6sEXQ2jXxZUJGYQKW PSF/jkYBUsUg/sFRGyupUn1bJlD6mPpfqPbjE= MIME-Version: 1.0 Received: by 10.101.4.26 with SMTP id g26mr802239ani.157.1276205112324; Thu, 10 Jun 2010 14:25:12 -0700 (PDT) Received: by 10.100.137.4 with HTTP; Thu, 10 Jun 2010 14:25:10 -0700 (PDT) In-Reply-To: <82D310BD-48DE-4F79-84C6-356AB4F04C42@averesystems.com> References: <82D310BD-48DE-4F79-84C6-356AB4F04C42@averesystems.com> Date: Thu, 10 Jun 2010 17:25:10 -0400 Message-ID: From: Alexander Sack To: Andrew Boyer Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Juli Mallett , freebsd-net@freebsd.org, Jack Vogel Subject: Re: Dual-rate transceivers with 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: Thu, 10 Jun 2010 21:25:13 -0000 On Thu, Jun 10, 2010 at 5:12 PM, Andrew Boyer wro= te: > > On Jun 10, 2010, at 3:59 PM, Alexander Sack wrote: >> >>> One thing that the base driver probably ought to do is not fail in >>> attach if there's an unrecognized SFP+ module. =A0Since we get >>> interrupts on module change (although this doesn't seem to always work >>> *entirely* right in the stock sources, mostly wrt stored values of >>> AUTOC and the like) it should be possible to bring the interface up >>> with the unsupported (and disabled) SFP+ module and do the SFP+ module >>> probing we already do on hot-swap. >> >> Alright, let me see if I can test that. =A0Let me rephrase so I validate >> what you are saying: >> >> The driver can come up with an unsupported module but disable the >> interface (ifconfig shows the interface, etc.). >> >> If you then hot-swap a supported SFP, it should come up then with a >> ifconfig down/up cycle. =A0Right? >> >> As it stand now, if you load the driver with an unsupported module, it >> will not attach at all causing you to reload the entire driver OR >> reboot the box to have it reattach to the other SFP. >> > > We use this patch to allow the driver to attach when no module is install= ed. =A0This might be a starting point for you. =A0I haven't tested it witho= ut all of our other changes in place so my apologies if it doesn't quite wo= rk. =A0We only have Intel modules around for testing. > > -Andrew > > --- ixgbe.c =A0 =A0 2010-06-10 16:53:08.000000000 -0400 > +++ ixgbe.c =A0 =A0 2010-06-10 16:55:26.000000000 -0400 > @@ -566,7 +566,7 @@ > =A0 =A0 =A0 =A0} else if (error =3D=3D IXGBE_ERR_SFP_NOT_SUPPORTED) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0device_printf(dev,"Unsupported SFP+ Module= \n"); > > - =A0 =A0 =A0 if (error) { > + =A0 =A0 =A0 if (error && error !=3D IXGBE_ERR_SFP_NOT_PRESENT) { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0error =3D EIO; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0device_printf(dev,"Hardware Initialization= Failure\n"); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0goto err_late; > > --- ixgbe_82598.c =A0 =A0 =A0 2010-06-10 16:53:24.000000000 -0400 > +++ ixgbe_82598.c =A0 =A0 =A0 2010-06-10 16:56:31.000000000 -0400 > @@ -257,10 +257,6 @@ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ret_val =3D ixgbe_get_sfp_init_sequence_of= fsets(hw, > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0&list_offset, > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0&data_offset); > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (ret_val !=3D IXGBE_SUCCESS) { > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ret_val =3D IXGBE_ERR_SFP_N= OT_SUPPORTED; > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto out; > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 } > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0break; > =A0 =A0 =A0 =A0default: > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0break; Thank you Andrew! I am on the same path as above! (though I also had 82599 changes which may not be meaningful to your application). I will have access to numerous SFP/SFP+ very soon (all Finisar based - though I think the Intel supplied ones are Finisar too anyway). I will test the dual-rate as well with both 10G and 1G traffic. Stay tuned, I want to test all of this in the lab. -aps From owner-freebsd-net@FreeBSD.ORG Fri Jun 11 01:24:17 2010 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from [127.0.0.1] (unknown [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 3EC461065672; Fri, 11 Jun 2010 01:24:15 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: Bruce Evans Date: Thu, 10 Jun 2010 21:23:59 -0400 User-Agent: KMail/1.6.2 References: <201006091444.50560.jkim@FreeBSD.org> <20100610173950.T33647@delplex.bde.org> In-Reply-To: <20100610173950.T33647@delplex.bde.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201006102124.02005.jkim@FreeBSD.org> Cc: freebsd-net@FreeBSD.org Subject: Re: [RFC] BPF timestamping 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, 11 Jun 2010 01:24:17 -0000 On Thursday 10 June 2010 05:45 am, Bruce Evans wrote: > On Wed, 9 Jun 2010, Jung-uk Kim wrote: > > bpf(4) can only timestamp packets with microtime(9). I want to > > expand it to be able to use different format and resolution. The > > patch is here: > > > > http://people.freebsd.org/~jkim/bpf_tstamp.diff > > > > With this patch, we can select different format and resolution of > > the timestamps. It is done via ioctl(2) with BIOCSTSTAMP > > command. Similarly, you can get the current format and resolution > > with BIOCGTSTAMP command. Currently, the following functions are > > available: > > > > BPF_T_MICROTIME microtime(9) > > BPF_T_NANOTIME nanotime(9) > > BPF_T_BINTIME bintime(9) > > BPF_T_MICROTIME_FAST getmicrotime(9) > > BPF_T_NANOTIME_FAST getnanotime(9) > > BPF_T_BINTIME_FAST getbintime(9) > > BPF_T_NONE ignore time stamps > > This has too many timestamp types, yet not one timestamp type which > is any good except possibly BPF_T_NONE, and not one monotonic > timestamp type. Only external uses and compatibility require use > of CLOCK_REALTIME. > > I recently tried looking at timeout resolution on FreeBSD cluster > machines using ktrace, and found ktrace unusable for this. At > first I blamed the slowness of the default misconfiguered > timecounter ACPI-fast, but the main problem was that I forgot my > home directory was on nfs, and nfs makes writing ktrace records > take hundreds of times longer than on local file systems. > ACPI-fast seemed to be taking nearly 1000 uS, but it was nfs taking > that long. > > Anyway, ACPI-fast takes nearly 1000 nS, which is many times too > long to be good for timestamping individual syscalls or packets, > and makes sub-microseconds resolution useless. The above non-get > *time() interfaces still use the primary timecounter, and this > might be slow even if it is not misconfigured. The above > get*time() interfaces are fast only at the cost of being broken. > Among other bugs, their times only change at relatively large > intervals which should become infinity with tickless kernels. > (BTW, icmp timestamps are still broken on systems with hz < 100. > Someone changed microtime() to getmicrotime(), but getmicrotime() > cannot deliver the resolution of 1 mS supported by icmp timestamps > unless these intervals are <= 1 mS.) Please note that I am not trying to solve timecounter issues here. The current BPF timestamping is not too good because of two main reasons; 1) it is too slow with some timecounter hardware as you have noted and 2) we have no API to change timestamp resolution, accuracy, format, offset, or whatever *at all*. The most common trick for the first problem is using getmicrotime(9) instead of microtime() if the users don't care much about its accuracy. For those people who want to collect as many packets as possible without spending fortunes, it works pretty well. However, suppose you have multiple interfaces. You want good timestamps from a slower controller (LAN side) and less accurate timestamps from a super fast controller (WAN side), but you can't. My patch solves this problem by assigning time stamping function per descriptor. So, you can use the same resolution but different accuracies, for example. The second problem is little bit harder for us without breaking libpcap and its consumers as it expects struct timeval and nothing else. That's why I had to introduce new header format with compat shims. In fact, struct bpf_hdr (and struct pcap_sf_pkthdr) is really obsolete and people have been talking about pcap NG for many years, which can store timestamps in variable resolutions and offsets. However, we can only use the default resolution even if libpcap gets the new format because we are stuck with struct bpf_hdr[1]. BTW, I updated my patch, which includes monotonic clocks now. BPF_T_MICROTIME_MONOTONIC microuptime(9) BPF_T_NANOTIME_MONOTONIC nanouptime(9) BPF_T_BINTIME_MONOTONIC binuptime(9) BPF_T_MICROTIME_MONOTONIC_FAST getmicrouptime(9) BPF_T_NANOTIME_MONOTONIC_FAST getnanouptime(9) BPF_T_BINTIME_MONOTONIC_FAST getbinuptime(9) http://people.freebsd.org/~jkim/bpf_tstamp2.diff Thanks for the hint, Bruce, although you may say there are more bogus clock types now. ;-) Enjoy, Jung-uk Kim [1] libpcap added limited support for the pcap NG format since 1.1.0 and my patch was written with the format in mind. If my patch gets committed, I am going to submit a libpcap patch upstream to introduce new struct bpf_xhdr. From owner-freebsd-net@FreeBSD.ORG Fri Jun 11 12:14:32 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 928C6106564A for ; Fri, 11 Jun 2010 12:14:32 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 186AA8FC17 for ; Fri, 11 Jun 2010 12:14:31 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1ON382-000692-Tn for freebsd-net@freebsd.org; Fri, 11 Jun 2010 14:14:30 +0200 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 11 Jun 2010 14:14:30 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 11 Jun 2010 14:14:30 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org connect(): No such file or directory From: Ivan Voras Date: Fri, 11 Jun 2010 14:14:23 +0200 Lines: 88 Message-ID: References: <4BD885C6.10600@FreeBSD.org> <20100429204544.GC1286@arthur.nitro.dk> <1272998683.2406.38.camel@localhost.localdomain> <20100504190328.GC31196@valentine.liquidneon.com> <4BE80F07.8090309@cs.duke.edu> <4BE82011.6050009@cs.duke.edu> <20100511092000.GA12735@walton.maths.tcd.ie> <4BE961EA.2060806@cs.duke.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.9) Gecko/20100518 Thunderbird/3.0.4 In-Reply-To: <4BE961EA.2060806@cs.duke.edu> X-Enigmail-Version: 1.0.1 Subject: Re: FreeBSD.org IPv6 issue - AAAA records disabled 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, 11 Jun 2010 12:14:32 -0000 On 05/11/10 15:55, Andrew Gallatin wrote: > David Malone wrote: >> On Mon, May 10, 2010 at 11:02:41AM -0400, Andrew Gallatin wrote: >>> I think something may be holding onto an mbuf after free, >>> then re-freeing it. But only after somebody else allocated >>> it. I was hoping that the mbuf double free referenced >>> above was the smoking gun, but it turns out that there isn't >>> even a bge interface in my pr (just bce and mxge). >> >> Weren't there some bugs fixed recently that alowed the arp/ndp code >> to free packets that weren't previously being freed? They'd be good >> candidates for something that holds onto an mbuf for a while and >> then frees it. > > Unfortunately, I think at least the PR I'm looking into pre-dates > those fixes -- these problems started in r202120 (early Jan). > I need to ask what he upgraded from. > > When did IPv6 become unstable for others? For what it's worth, it looks like using IPv6 really is causing my crashes, but in a really wide-spread ways, possibly a deep memory corruption. I've disabled it on the machine I have here that would crash or hang once or twice a week and so far there are no problems with uptime of nearly 10 days. When IPv6 is enabled here, it is used for "everything" - from interactive ssh sessions, http, to NFS. I have 9 core files here with text crashdumps, if anyone's interested. Here's a sample: # grep -i panic core* core.txt.0:panic: sbsndptr: sockbuf 0xffffff007cca8c20 and mbuf 0xffffff00490a6400 clashing core.txt.0:panic: sbsndptr: sockbuf 0xffffff007cca8c20 and mbuf 0xffffff00490a6400 clashing core.txt.0:#2 0xffffffff80585e4c in panic ( core.txt.0:panic: sbsndptr: sockbuf 0xffffff007cca8c20 and mbuf 0xffffff00490a6400 clashing core.txt.1:panic: page fault core.txt.1:panic: page fault core.txt.1:#2 0xffffffff8058afdc in panic (fmt=0xffffffff809364ac "%s") core.txt.1:panic: page fault core.txt.2:panic: general protection fault core.txt.2:panic: general protection fault core.txt.2:#2 0xffffffff8058afdc in panic (fmt=0xffffffff809364ac "%s") core.txt.2:panic: page fault core.txt.2:savecore: reboot after panic: page fault core.txt.2:Feb 17 20:43:07 geri savecore: reboot after panic: page fault core.txt.2:panic: general protection fault core.txt.3:panic: sbdrop core.txt.3:panic: sbdrop core.txt.3:#2 0xffffffff8058afdc in panic (fmt=0xffffffff80963dff "sbdrop") core.txt.3:panic: sbdrop core.txt.4:panic: general protection fault core.txt.4:panic: general protection fault core.txt.4:#2 0xffffffff8058d26c in panic (fmt=0xffffffff80938c44 "%s") core.txt.4:panic: general protection fault core.txt.5:panic: general protection fault core.txt.5:panic: general protection fault core.txt.5:#2 0xffffffff8058d5ac in panic (fmt=0xffffffff80944404 "%s") core.txt.5:panic: general protection fault core.txt.6:panic: sbflush_internal: cc 0 || mb 0xffffff003a7a9600 || mbcnt 4608 core.txt.6:panic: sbflush_internal: cc 0 || mb 0xffffff003a7a9600 || mbcnt 4608 core.txt.6:Dumping 1573 MB:panic: bufwrite: buffer is not busy??? core.txt.6:#2 0xffffffff8058d5ac in panic ( core.txt.6:panic: sbflush_internal: cc 0 || mb 0xffffff003a7a9600 || mbcnt 4608 core.txt.6:Dumping 1573 MB:panic: bufwrite: buffer is not busy??? core.txt.7:panic: sbsndptr: sockbuf 0xffffff0001f7eec8 and mbuf 0xffffff0001909c00 clashing core.txt.7:#2 0xffffffff8058d5ac in panic ( core.txt.7:panic: sbsndptr: sockbuf 0xffffff0001f7eec8 and mbuf 0xffffff0001909c00 clashing core.txt.7:Dumping 1715 MB:panic: bufwrite: buffer is not busy??? core.txt.8:panic: sbdrop core.txt.8:panic: sbdrop core.txt.8:#2 0xffffffff805a2e9c in panic (fmt=0xffffffff8098f15f "sbdrop") core.txt.8:panic: sbdrop All of the dumps have several messages like "em0: discard frame w/o packet header" immediately before crashing. From owner-freebsd-net@FreeBSD.ORG Fri Jun 11 13:08:29 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D73891065677; Fri, 11 Jun 2010 13:08:29 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail01.syd.optusnet.com.au (mail01.syd.optusnet.com.au [211.29.132.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6D4C58FC22; Fri, 11 Jun 2010 13:08:28 +0000 (UTC) Received: from c122-106-175-69.carlnfd1.nsw.optusnet.com.au (c122-106-175-69.carlnfd1.nsw.optusnet.com.au [122.106.175.69]) by mail01.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o5BD8PMW028256 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Jun 2010 23:08:26 +1000 Date: Fri, 11 Jun 2010 23:08:24 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Jung-uk Kim In-Reply-To: <201006102124.02005.jkim@FreeBSD.org> Message-ID: <20100611215032.U35046@delplex.bde.org> References: <201006091444.50560.jkim@FreeBSD.org> <20100610173950.T33647@delplex.bde.org> <201006102124.02005.jkim@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: [RFC] BPF timestamping 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, 11 Jun 2010 13:08:29 -0000 On Thu, 10 Jun 2010, Jung-uk Kim wrote: > On Thursday 10 June 2010 05:45 am, Bruce Evans wrote: >> On Wed, 9 Jun 2010, Jung-uk Kim wrote: >>> bpf(4) can only timestamp packets with microtime(9). I want to >>> expand it to be able to use different format and resolution. The >>> ... >> This has too many timestamp types, yet not one timestamp type which >> is any good except possibly BPF_T_NONE, and not one monotonic >> timestamp type. Only external uses and compatibility require use >> of CLOCK_REALTIME. >> ... > Please note that I am not trying to solve timecounter issues here. > The current BPF timestamping is not too good because of two main > reasons; 1) it is too slow with some timecounter hardware as you have > noted and 2) we have no API to change timestamp resolution, accuracy, > format, offset, or whatever *at all*. > > The most common trick for the first problem is using getmicrotime(9) > instead of microtime() if the users don't care much about its > accuracy. For those people who want to collect as many packets as > possible without spending fortunes, it works pretty well. However, > suppose you have multiple interfaces. You want good timestamps from > a slower controller (LAN side) and less accurate timestamps from a > super fast controller (WAN side), but you can't. My patch solves > this problem by assigning time stamping function per descriptor. So, > you can use the same resolution but different accuracies, for > example. I now think you should provide exactly the same timestamping features as provided to useland by clock_gettime(2), clock_getres(2) and clock_getaccprecres(2missing), using essentially the same interface and code. The userland interface involves clock ids of type clockid_t with names like CLOCK_REALTIME instead of bpf-specific names and types. Unfortunately it only supports the timespec format. > The second problem is little bit harder for us without breaking > libpcap and its consumers as it expects struct timeval and nothing > else. That's why I had to introduce new header format with compat > shims. In fact, struct bpf_hdr (and struct pcap_sf_pkthdr) is really > obsolete and people have been talking about pcap NG for many years, > which can store timestamps in variable resolutions and offsets. Does it prefer or support bintimes? > However, we can only use the default resolution even if libpcap gets > the new format because we are stuck with struct bpf_hdr[1]. > > BTW, I updated my patch, which includes monotonic clocks now. > > BPF_T_MICROTIME_MONOTONIC microuptime(9) > BPF_T_NANOTIME_MONOTONIC nanouptime(9) > BPF_T_BINTIME_MONOTONIC binuptime(9) > BPF_T_MICROTIME_MONOTONIC_FAST getmicrouptime(9) > BPF_T_NANOTIME_MONOTONIC_FAST getnanouptime(9) > BPF_T_BINTIME_MONOTONIC_FAST getbinuptime(9) > > http://people.freebsd.org/~jkim/bpf_tstamp2.diff > > Thanks for the hint, Bruce, although you may say there are more bogus > clock types now. ;-) Yes, there are far too many, but many are still missing: - aliases BPF_T_*TIME_PRECISE for BPF_T_*TIME correpsonding to the corresponding aliases for clockid_t's. This gives 18 clock ids per timecounter instead of only 12. clock_gettime() only supports 6 of these (it doesn't support the micro or bin time formats). - aliases BPF_T_UPTIME* for BPF_*TIME_MONOTONIC. This gives 27 clock ids per timecounter instead of only 18. clock_gettime() only supports 9 of these. - BPF_T_SECOND corresponding to CLOCK_SECOND. clock_gettime() supports this. - BPF_T_THREAD_CPUTIME corresponding to CLOCK_THREAD_CPUTIME_ID, but without the bogus _ID suffix. The latter gives the runtime of the current thread in nanoseconds. This might be almost useful for bpf if all the packets are stamped by the same kernel or user thread. Then it would function as a packet id with extra info about the time spent processing packets. - BPF_T_VIRTUAL and BPF_T_PROF corresponding to CLOCK_VIRTUAL and CLOCK_PROF. The latter give user and user+sys times for processes. They would be about as useful as BPF_T_THREAD_CPUTIME for bpf. - the total is now 31 for bpf (19 missing) and 13 for clock_gettime(). - multiply this by the number of timecounters. Non-primary timecounters should be available iff something has a use for them. - raw cputicker timestamps. CLOCK_THREAD_CPUTIME_ID's timer uses these. These are not available in userland. They are easily available in the kernel, by calling cpu_tick(). Scaling them is nontrivial. - raw timecounter reads. These are already available in userland via sysctlbyname("kern.timecounter.tc..counter", ...). Strangely, they are hard to call from the kernel. By using normal clock ids and calling kern_clock_gettime(), you can avoid lots of duplication (including documentation of the bpf clock ids) and automatically support new normal clock ids. However, I can't see how to implement the following features as efficiently: - direct scaling to the final precision (kern_clock_gettime() only returns timspecs -- see abov) - delayed scaling to the final precision (bpf seems to make timestamps as binuptimes and scale them later) - avoiding going through layers and switches. bpf goes through several layers and switches now, but perhaps it can go directly to the *time() function in kern_tc.c via a single function pointer, where kern_clock_gettime() and delayed scaling have to use a switch or an indexed function pointer since their clock id is highly variable. Bruce From owner-freebsd-net@FreeBSD.ORG Fri Jun 11 16:38:42 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from [127.0.0.1] (unknown [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 4BB701065672; Fri, 11 Jun 2010 16:38:41 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: Bruce Evans Date: Fri, 11 Jun 2010 12:38:19 -0400 User-Agent: KMail/1.6.2 References: <201006091444.50560.jkim@FreeBSD.org> <201006102124.02005.jkim@FreeBSD.org> <20100611215032.U35046@delplex.bde.org> In-Reply-To: <20100611215032.U35046@delplex.bde.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201006111238.24726.jkim@FreeBSD.org> Cc: freebsd-net@freebsd.org Subject: Re: [RFC] BPF timestamping 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, 11 Jun 2010 16:38:42 -0000 On Friday 11 June 2010 09:08 am, Bruce Evans wrote: > On Thu, 10 Jun 2010, Jung-uk Kim wrote: > > On Thursday 10 June 2010 05:45 am, Bruce Evans wrote: > >> On Wed, 9 Jun 2010, Jung-uk Kim wrote: > >>> bpf(4) can only timestamp packets with microtime(9). I want to > >>> expand it to be able to use different format and resolution. > >>> The ... > >> > >> This has too many timestamp types, yet not one timestamp type > >> which is any good except possibly BPF_T_NONE, and not one > >> monotonic timestamp type. Only external uses and compatibility > >> require use of CLOCK_REALTIME. > >> ... > > > > Please note that I am not trying to solve timecounter issues > > here. The current BPF timestamping is not too good because of two > > main reasons; 1) it is too slow with some timecounter hardware as > > you have noted and 2) we have no API to change timestamp > > resolution, accuracy, format, offset, or whatever *at all*. > > > > The most common trick for the first problem is using > > getmicrotime(9) instead of microtime() if the users don't care > > much about its accuracy. For those people who want to collect as > > many packets as possible without spending fortunes, it works > > pretty well. However, suppose you have multiple interfaces. You > > want good timestamps from a slower controller (LAN side) and less > > accurate timestamps from a super fast controller (WAN side), but > > you can't. My patch solves this problem by assigning time > > stamping function per descriptor. So, you can use the same > > resolution but different accuracies, for example. > > I now think you should provide exactly the same timestamping > features as provided to useland by clock_gettime(2), > clock_getres(2) and clock_getaccprecres(2missing), using > essentially the same interface and code. The userland interface > involves clock ids of type clockid_t with names like CLOCK_REALTIME > instead of bpf-specific names and types. Unfortunately it only > supports the timespec format. I thought about using them but struct timespec isn't good enough. It has exactly the same problem as struct timeval does, i.e., sizeof(time_t) and sizeof(long) are variable depending on arch. Note struct bpf_xhdr uses int64_t and uint64_t to work around the problem. At least in theory, it should be good enough until we have to support a 16-byte aligned arch. :-) > > The second problem is little bit harder for us without breaking > > libpcap and its consumers as it expects struct timeval and > > nothing else. That's why I had to introduce new header format > > with compat shims. In fact, struct bpf_hdr (and struct > > pcap_sf_pkthdr) is really obsolete and people have been talking > > about pcap NG for many years, which can store timestamps in > > variable resolutions and offsets. > > Does it prefer or support bintimes? It supports bintime. It does not prefer anything although the default resolution is 1 usec for backward compatibility with old pcap format. > > However, we can only use the default resolution even if libpcap > > gets the new format because we are stuck with struct bpf_hdr[1]. > > > > BTW, I updated my patch, which includes monotonic clocks now. > > > > BPF_T_MICROTIME_MONOTONIC microuptime(9) > > BPF_T_NANOTIME_MONOTONIC nanouptime(9) > > BPF_T_BINTIME_MONOTONIC binuptime(9) > > BPF_T_MICROTIME_MONOTONIC_FAST getmicrouptime(9) > > BPF_T_NANOTIME_MONOTONIC_FAST getnanouptime(9) > > BPF_T_BINTIME_MONOTONIC_FAST getbinuptime(9) > > > > http://people.freebsd.org/~jkim/bpf_tstamp2.diff > > > > Thanks for the hint, Bruce, although you may say there are more > > bogus clock types now. ;-) > > Yes, there are far too many, but many are still missing: > - aliases BPF_T_*TIME_PRECISE for BPF_T_*TIME correpsonding to the > corresponding aliases for clockid_t's. This gives 18 clock ids > per timecounter instead of only 12. clock_gettime() only > supports 6 of these (it doesn't support the micro or bin time > formats). - aliases BPF_T_UPTIME* for BPF_*TIME_MONOTONIC. This > gives 27 clock ids per timecounter instead of only 18. > clock_gettime() only supports 9 of these. > - BPF_T_SECOND corresponding to CLOCK_SECOND. clock_gettime() > supports this. > - BPF_T_THREAD_CPUTIME corresponding to CLOCK_THREAD_CPUTIME_ID, > but without the bogus _ID suffix. The latter gives the runtime of > the current thread in nanoseconds. This might be almost useful for > bpf if all the packets are stamped by the same kernel or user > thread. Then it would function as a packet id with extra info > about the time spent processing packets. > - BPF_T_VIRTUAL and BPF_T_PROF corresponding to CLOCK_VIRTUAL and > CLOCK_PROF. The latter give user and user+sys times for > processes. They would be about as useful as BPF_T_THREAD_CPUTIME > for bpf. - the total is now 31 for bpf (19 missing) and 13 for > clock_gettime(). - multiply this by the number of timecounters. > Non-primary timecounters should be available iff something has a > use for them. > - raw cputicker timestamps. CLOCK_THREAD_CPUTIME_ID's timer uses > these. These are not available in userland. They are easily > available in the kernel, by calling cpu_tick(). Scaling them is > nontrivial. - raw timecounter reads. These are already available > in userland via sysctlbyname("kern.timecounter.tc..counter", > ...). Strangely, they are hard to call from the kernel. That's really far too many for my taste. :-( It'll significantly increase number of special cases for switch statement but I cannot avoid it (please see below). I added _MONOTONIC because it was relatively cheap to implement and important. I may add some aliases for _REALTIME, _PRECISE, and _UPTIME if you insist, though. > By using normal clock ids and calling kern_clock_gettime(), you can > avoid lots of duplication (including documentation of the bpf clock > ids) and automatically support new normal clock ids. However, I > can't see how to implement the following features as efficiently: > - direct scaling to the final precision (kern_clock_gettime() only > returns timspecs -- see abov) > - delayed scaling to the final precision (bpf seems to make > timestamps as binuptimes and scale them later) > - avoiding going through layers and switches. bpf goes through > several layers and switches now, but perhaps it can go directly to > the *time() function in kern_tc.c via a single function pointer, > where kern_clock_gettime() and delayed scaling have to use a switch > or an indexed function pointer since their clock id is highly > variable. As I said, we cannot use kern_clock_gettime() and clockid_t. The code duplication is also necessary evil because multiple descriptors may be attached to a single interface, unless you are effectively asking me to revert the following commit: http://docs.freebsd.org/cgi/mid.cgi?200607241542.k6OFg5ck098374 Cheers, Jung-uk Kim From owner-freebsd-net@FreeBSD.ORG Fri Jun 11 18:09:20 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C92381065678 for ; Fri, 11 Jun 2010 18:09:20 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [204.109.60.94]) by mx1.freebsd.org (Postfix) with ESMTP id AEE038FC0A for ; Fri, 11 Jun 2010 18:09:20 +0000 (UTC) Received: from unknown (87-194-158-129.bethere.co.uk [87.194.158.129]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA id 70EAA5CCC for ; Fri, 11 Jun 2010 17:51:45 +0000 (UTC) Date: Fri, 11 Jun 2010 18:51:03 +0100 From: Bruce Cran To: freebsd-net@freebsd.org Message-ID: <20100611185103.000026a3@unknown> X-Mailer: Claws Mail 3.7.4cvs1 (GTK+ 2.16.0; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Testing recent sis(4) changes on SiS controllers 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, 11 Jun 2010 18:09:20 -0000 I recently committed to 9-CURRENT a fix for the sis(4) driver to improve performance when the host can't keep up with the processing requirements of the network. Previously, when an overflow occurred the chip was reset and a sleep of 100ms was introduced while programming a short cable fix for the NatSemi FA311 chip. Now, the reset is only done once when a media change occurs and the delay was reduced to 100us. However there's some doubt as to whether the change may cause problems on SiS based controllers as found on some motherboards - they may require the chip to be reset when an overflow occurs. If anyone has a machine with a SiS based controller I'd welcome any testing that could be done to check that I've not broken overflow handling. Overflows are indicated by the Ierrs column in the output of "netstat -s". -- Bruce Cran From owner-freebsd-net@FreeBSD.ORG Sat Jun 12 21:22:53 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 42AF11065670 for ; Sat, 12 Jun 2010 21:22:53 +0000 (UTC) (envelope-from kurt.buff@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 0B0E08FC14 for ; Sat, 12 Jun 2010 21:22:52 +0000 (UTC) Received: by iwn7 with SMTP id 7so3211327iwn.13 for ; Sat, 12 Jun 2010 14:22:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=IguAlHlC82KW4d7Ls/t7jWZbSYGms4BzSEwSmPidCnc=; b=FIvgNCHOgEu55CppnFKeh/2JktbzxKLZiQP6Q/46eVKDN2K97X+TAedPwRFpR3BJdB vWUvf4RKvhdyN8Ie3ExXWqPl1sLbYCKmPOitVdMQklEEnaDRUTQodAwkpIP9o7iPdQTY YJaF3fU0iJ6chIKHAAYFiNqHM87DzeVYe7UtA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=GvIu1KAWx2PKwJ0gOIaz2VovIWkuaUuLh5wgmYQs34swI3I0OZvhIFHms7LSPYCLfd XGiAdVktkMto4XNbpH0wHKFi5/BYRTd7fYa33gGZHNBExDnQubU6VKRHx6/2rT+MLaw2 U8/r68I98a8XkCEztH2t3HwZXXaj8RcHiNVqY= MIME-Version: 1.0 Received: by 10.231.124.229 with SMTP id v37mr3344028ibr.184.1276377772269; Sat, 12 Jun 2010 14:22:52 -0700 (PDT) Received: by 10.231.38.8 with HTTP; Sat, 12 Jun 2010 14:22:52 -0700 (PDT) In-Reply-To: References: Date: Sat, 12 Jun 2010 14:22:52 -0700 Message-ID: From: Kurt Buff To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 Subject: Re: VLANs, routing, multicast and HP switches, oh my... 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, 12 Jun 2010 21:22:53 -0000 On Thu, Jun 10, 2010 at 07:02, Ivan Voras wrote: > On 06/09/10 22:35, Kurt Buff wrote: >> All, >> Now, however, the subnet on fxp4 is going to have an HP 2610 switch >> attached to it, and they want to hang multiple subnets from that >> interface. > > ... which doesn't necessarily translate to VLANs. You can assign an > arbitrary number IP addresses to a single NIC without problems. True - but they are apparently going to be simulating hundreds of machines on two subnets, as I found out a day later. Sorry for the late reply - been slammed at work. >> So, it looks to me as if I need to set up this box with a VLAN >> configuration and some more routing intelligence than it has at the >> moment. >> >> I'm looking at, among other pages, this one >> http://www.cyberciti.biz/faq/howto-configure-freebsd-vlans-with-ifconfig-command/, >> though I don't see much addressing these two subjects in the handbook. > > There's not much to say on the topic. The section which describes VLAN > setup in the link you have given is correct. Each new virtual vlan > device will behave as another NIC. Good to know. Thanks for that. > The story behind VLANs is that they are an Ethernet-level routing > kludge. Instead of having a flat topology, they divide it into chunks > which may be routed separately on L2. Yep - do that with my HP switches in the rest of the environment. > On the FreeBSD side, the > representation of this will be additional NICs which operate only on > these "chunks" - virtual Ethernets which don't see packets from other > VLANs even if they travel on the same wire(s). The physical NIC will > need to "see" all packets indiscriminately (which is sometimes called a > "trunk"), and the OS logic will then "divide" those packets into > individual virtual vlan devices. Note that if you use VLANs, all active > equipment involved will probably need to be able to understand and work > with VLANs, and you will need to configure them all. To be able to use > generic Ethernet clients (like Windows with low-end NICs), some kind of > end-point equipment will need to strip VLAN tags before the packets > reach them. > > But as I've said, maybe you don't need VLANs. Simply hang multiple IP > subnets on normal Ethernet NICs. Again - they'll be putting up to 200 busy machines on each subnet. It seems reasonable to limit the broadcast domains with VLANs. Thanks for the feedback. Kurt