From owner-freebsd-net@FreeBSD.ORG Sun Apr 8 01:17:19 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7B7AF106566B for ; Sun, 8 Apr 2012 01:17:19 +0000 (UTC) (envelope-from rsb@berentweb.com) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id D3A658FC12 for ; Sun, 8 Apr 2012 01:17:18 +0000 (UTC) Received: by lagv3 with SMTP id v3so4062281lag.13 for ; Sat, 07 Apr 2012 18:17:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=berentweb.com; s=google; h=mime-version:sender:x-originating-ip:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=6yz1sfCPGcONLlglJ1QYExqEuW8G29MRSKpcrrkn9RA=; b=EjLTB/02RusHtyuO9VcGDkJxkbQ3TGEVJVudFsO2UrttyBoo1q9UnsxZTXxShDia2G Qf7E0jW4mn1zdsk77zmXKEUZXXhdbHgFAYXjP5+YpVQGpQPZ/CEnafKBcSV7AO39GqZd tJNRrXmuN0Jy8oYCjd+LaG9/Pj1Ndft6q98D4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:x-originating-ip:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :x-gm-message-state; bh=6yz1sfCPGcONLlglJ1QYExqEuW8G29MRSKpcrrkn9RA=; b=AFrShDdgjakEUEkXJieSYWLTvEfzB7IHjFJZqYvzt9cD5RK3oMSeRvS11CyX5l/gsb c0nQvBoPLcgVVKAjSKJ16MhH+Ijh2BdXnWgDVg2kByEL/LzqPA9W1ki2jkufvwbLfZPT 3Wdz/Xx2cDmkljSFbniADUdyt62wjaqwhs/omww1sMTGQDve2OyTD0y9J7/DRE07hsIB Uidr7OWDLX4vZ5eTmGKwLauWalRCiztmUGEPNMBbGlbjRs4Ek4UGXj8MhZcTESZMe5+J TgKNpRXTmRbMj2q+0Rp6bKmvVhzDSlKRqNYE5XhvEU5dekuXDa7PdyjTZwGEi0rhF415 yjFw== MIME-Version: 1.0 Received: by 10.152.132.4 with SMTP id oq4mr4448504lab.40.1333847837632; Sat, 07 Apr 2012 18:17:17 -0700 (PDT) Sender: rsb@berentweb.com Received: by 10.112.100.225 with HTTP; Sat, 7 Apr 2012 18:17:17 -0700 (PDT) X-Originating-IP: [85.110.4.183] In-Reply-To: References: <20120329072054.GA45082@server.vk2pj.dyndns.org> <20120403074954.GA19241@server.vk2pj.dyndns.org> Date: Sun, 8 Apr 2012 04:17:17 +0300 X-Google-Sender-Auth: mHU6OPSBf2QKU_0E5ihC7ojnqkw Message-ID: From: Beeblebrox To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQm71K6u2g4mMJW0oiIJ1PJVJW1f9iWS2hUyS3mMjzzIBLQ9C5zZ13/NrAzlwzZFwDtvGwnz Subject: Re: lagg problems on diskless client X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Apr 2012 01:17:19 -0000 > Note to doing anything on wifi: in STA mode, you can't (standards > wise) send frames with a MAC that isn't yours. > > There's a conceptual fix for this - called "proxy-STA" - but noone's > coded it up in net80211 and/or any driver. @ Adrian: The DC's are not wireless. They have 2 NICs (NIC 10/100 and NIC GBit). After DC boots off 10/100 that NIC's job is finished and GBit should handle all traffic. At this point something as simple as NIC GBit up, NIC 10/100 down would be acceptable as well. I have tried to modify Peter's lagg script to jut bring up NIC GBit with NIC 10/100 info without using lagg, to no avail unfortunately. From owner-freebsd-net@FreeBSD.ORG Sun Apr 8 05:09:45 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 61FC6106564A; Sun, 8 Apr 2012 05:09:45 +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 CB0498FC14; Sun, 8 Apr 2012 05:09:44 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q3859cpO016001; Sun, 8 Apr 2012 08:09:38 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q3859c4X092375; Sun, 8 Apr 2012 08:09:38 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q3859c1q092374; Sun, 8 Apr 2012 08:09:38 +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: Sun, 8 Apr 2012 08:09:38 +0300 From: Konstantin Belousov To: Jason Wolfe Message-ID: <20120408050938.GZ2358@deviant.kiev.zoral.com.ua> References: <20120407133715.GU2358@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="f9wPAG0p55LdzBq3" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: jfv@freebsd.org, jhb@freebsd.org, net@freebsd.org Subject: Re: 82574L hangs (with r233708 e1000 driver). X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Apr 2012 05:09:45 -0000 --f9wPAG0p55LdzBq3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Apr 07, 2012 at 03:06:38PM -0700, Jason Wolfe wrote: > On Sat, Apr 7, 2012 at 6:37 AM, Konstantin Belousov = wrote: > > I bought Intel Atom motherboard DN2800MT, which has integrated if_em > > LOM, reported by pciconf as > > em0@pci0:1:0:0: class=3D0x020000 card=3D0x20128086 chip=3D0x10d38086 re= v=3D0x00 hdr=3D0x00 > > 82574L Gigabit Network Connection > > It seems that any non-trivial network activity on the interface causes > > reliable interface hang, which can be temporary cured by ifconfig down/= up. > > This happens both with outdated stable/9 sys/dev/e1000 and with driver > > from HEAD merged into stable/9. I currently use the copy of dev/e1000 > > at rev. r233708. Disabling MSI-X makes the hand to occur slightly less > > often. > > > > I can reproduce the hang in approximately a minute by scp'ing large > > file from other machine to /dev/null on the DN2800MT. This makes the > > board completely unusable for me. > > > > The driver reports itself as > > em0: port 0x2000-0x201f me= m 0xc0400000-0xc041ffff,0xc0000000-0xc03fffff,0xc0420000-0xc0423fff irq 16 = at device 0.0 on pci1 > > em0: attempting to allocate 3 MSI-X vectors (5 supported) > > msi: routing MSI-X IRQ 258 to local APIC 0 vector 60 > > msi: routing MSI-X IRQ 259 to local APIC 0 vector 61 > > msi: routing MSI-X IRQ 260 to local APIC 0 vector 62 > > em0: using IRQs 258-260 for MSI-X > > em0: Using MSIX interrupts with 3 vectors > > em0: bpf attached > > em0: Ethernet address: 00:22:4d:7a:47:f6 > > em0: Link is up 1000 Mbps Full Duplex > > > > The board is connected to ProCurve switch, there is no link flaps. > > > > When hang occur, dmesg output of # sysctl dev.em.0.debug=3D1 > > dev.em.0.debug: Interface is RUNNING and ACTIVE > > em0: hw tdh =3D 357, hw tdt =3D 357 > > em0: hw rdh =3D 323, hw rdt =3D 273 > > em0: Tx Queue Status =3D 0 > > em0: TX descriptors avail =3D 1024 > > em0: Tx Descriptors avail failure =3D 0 > > em0: RX discarded packets =3D 0 > > em0: RX Next to Check =3D 274 > > em0: RX Next to Refresh =3D 273 > > > > [..snip..] > > Any help ? >=20 > Konstantin, >=20 > It doesn't appear to be the exact issue I was seeing, but here is a > patch that did resolve issues with my 82574L buffers filling and > requiring a down/up to recover. It was the result of the 'Intel > 82574L interface wedging - em7.3.2/8.2-STABLE' if you'd like to peruse > that. Yes, I (re)read the thread when I first encountered the issue. The r233708 that I specifically mentioned above should be the commit of the patch you have attached. Anyway, thank you for help. --f9wPAG0p55LdzBq3 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk+BHZEACgkQC3+MBN1Mb4gUnwCgpy2G+VhstvuUutdqyat3FoIF 02gAoIILG75t4JqBQqZQuTDuoVI1kQFN =GJIm -----END PGP SIGNATURE----- --f9wPAG0p55LdzBq3-- From owner-freebsd-net@FreeBSD.ORG Sun Apr 8 05:11:32 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ABCD61065677; Sun, 8 Apr 2012 05:11:32 +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 18F3C8FC1F; Sun, 8 Apr 2012 05:11:31 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q385BPp3016568; Sun, 8 Apr 2012 08:11:25 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q385BPXP092401; Sun, 8 Apr 2012 08:11:25 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q385BPJ1092400; Sun, 8 Apr 2012 08:11:25 +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: Sun, 8 Apr 2012 08:11:25 +0300 From: Konstantin Belousov To: Jack Vogel Message-ID: <20120408051125.GA2358@deviant.kiev.zoral.com.ua> References: <20120407133715.GU2358@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="JbMKRSIIJiL0g+4u" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: jfv@freebsd.org, jhb@freebsd.org, net@freebsd.org Subject: Re: 82574L hangs (with r233708 e1000 driver). X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Apr 2012 05:11:32 -0000 --JbMKRSIIJiL0g+4u Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sat, Apr 07, 2012 at 04:22:07PM -0700, Jack Vogel wrote: > Make sure you have any firmware up to the latest available, if that doesn't > help > let me know and I'll check internally to see if there are any outstanding > issues > in shared code, that will be after the weekend. I had BIOS rev. 151, after you hint I found rev. 154 on the site. Now BIOS reports itself as MTCDT10N.86A.0154.2012.0323.1601, March 23. Unfortunately, upgrade did not changed anything in regard of hanging interface. --JbMKRSIIJiL0g+4u Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk+BHfwACgkQC3+MBN1Mb4h4VgCfcLNQtDCzuhiyGR/wom1+d3Gb VuAAn2fwDWa9ORI8wWNMCsJykAjKU9Ga =FmqJ -----END PGP SIGNATURE----- --JbMKRSIIJiL0g+4u-- From owner-freebsd-net@FreeBSD.ORG Sun Apr 8 08:48:12 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 377A4106566B for ; Sun, 8 Apr 2012 08:48:12 +0000 (UTC) (envelope-from farzin.falahati@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id ACEB28FC08 for ; Sun, 8 Apr 2012 08:48:11 +0000 (UTC) Received: by lbok6 with SMTP id k6so1860442lbo.13 for ; Sun, 08 Apr 2012 01:48:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=jJsP6rgIADbPtZyxtpd2lAS2fj3TfFQB4HTHvzHiJvM=; b=YOM+oh79ZJUZBI0J1yorQwaQ2MjYtzeCZB4oWRL83M+q+/dJRTOcir6s3AKCioS9Hg fO9+69jUkMfukjg0lHrB+39LLQCIlEfRiJJmt32NFDS99jG+JGHfj3+mzAGNp+sxRWmi cxTGkcOJRaum8+y0lPtDxq5NFqvPVahQVPleACaQBct7VKQFrDdFt7wByR+JX1LOO0dw ZX3qOxPKZkwk4L+BDCybHFihRdfqajIU5feZSdGJtW7XZJqvFtQsbaokVn9tZt8WgjMi 41UdFkvt1n5QH/YZ68T4AL+G0gNB9HRbdm6vMR0HiN4C9FcavTIHcX5iLkjP/aKk62D9 D4vA== MIME-Version: 1.0 Received: by 10.152.104.43 with SMTP id gb11mr5697643lab.8.1333874890430; Sun, 08 Apr 2012 01:48:10 -0700 (PDT) Received: by 10.112.45.101 with HTTP; Sun, 8 Apr 2012 01:48:10 -0700 (PDT) In-Reply-To: References: Date: Sun, 8 Apr 2012 13:18:10 +0430 Message-ID: From: Farzin Falahati To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: FreeVRRP 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, 08 Apr 2012 08:48:12 -0000 Hello How Are you My Friend ? in FreeBSD 8.2 I'm Changed The Interface Name On RC.Conf and Should Name Change ifconfig_em0_name="gbeth0" sorry(For Run VRRP , vrrp Create the NetGraph Bridge) For Create Netgraph Bridge FreeBsd Cannot Create The NetGraph Bridge With The Unrealistic Name And If Into the FreeVRRP config put the real name freeVRRP Cannot Find The InterFace And So This Is a Very Big Problem Thank You From owner-freebsd-net@FreeBSD.ORG Mon Apr 9 02:37:15 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9DA9D106566C for ; Mon, 9 Apr 2012 02:37:15 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by mx1.freebsd.org (Postfix) with ESMTP id 652CB8FC08 for ; Mon, 9 Apr 2012 02:37:15 +0000 (UTC) Received: by dadz14 with SMTP id z14so16353390dad.17 for ; Sun, 08 Apr 2012 19:37:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=ea1oxJ4phjDW+n/l1G/+N64HBj+ui/0gclG6o3waeSU=; b=dwtHQeR428coP3TUqjtlhNbE/AvnLSfZ3VAlqeDvSeKtR/z2rgidUFWKxs33FRr9Xe 8nDXO8s94cVuPGz2KzGgrINeFhysDc/HV4OWxhaJvQRskdZy1A/uMWskxxpcQzY0o3dz b87DZbZClXYlHrOD/shuqMz4fhQIARy1N+jXYMj4fnfCOalfCgWhmqyRy+DVobVXEVBj dfKow91m71GsvIUu9Sri5oXhwtHu/1UpYiNXE9kjnjFj1G0S4O/3h7TOKCuy0GI0vEku XQRUW9hyvSVhb4ljhxuNyLZXV+YqZpLv8gmHpdRN4vr27MJPco6ITJyRNmVxgMdoSq7/ pfpA== Received: by 10.68.136.1 with SMTP id pw1mr15066854pbb.105.1333939028962; Sun, 08 Apr 2012 19:37:08 -0700 (PDT) Received: from pyunyh@gmail.com ([114.111.62.249]) by mx.google.com with ESMTPS id i2sm13554500pbo.6.2012.04.08.19.37.04 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 08 Apr 2012 19:37:06 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Mon, 09 Apr 2012 11:37:04 -0700 From: YongHyeon PYUN Date: Mon, 9 Apr 2012 11:37:04 -0700 To: enoch Message-ID: <20120409183704.GA1668@michelle.cdnetworks.com> References: <20120403023225.GD3571@michelle.cdnetworks.com> <87ty11670b.fsf@hotmail.com> <20120403183521.GA7380@michelle.cdnetworks.com> <87obr95pxh.fsf@hotmail.com> <20120403225422.GB7380@michelle.cdnetworks.com> <87sjgk5czo.fsf@hotmail.com> <20120404210445.GB10911@michelle.cdnetworks.com> <87vclfwqp4.fsf@hotmail.com> <20120405161152.GA14289@michelle.cdnetworks.com> <87iphejaar.fsf@hotmail.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="opJtzjQTFsWo+cga" Content-Disposition: inline In-Reply-To: <87iphejaar.fsf@hotmail.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: [nfe] DHCP failure on 8-stable X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 02:37:15 -0000 --opJtzjQTFsWo+cga Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Apr 05, 2012 at 02:36:12PM -0400, enoch wrote: > YongHyeon PYUN writes: > > > On Wed, Apr 04, 2012 at 09:51:19AM -0400, enoch wrote: > >> YongHyeon PYUN writes: > >> > >> > On Wed, Apr 04, 2012 at 12:37:15AM -0400, enoch wrote: > >> >> YongHyeon PYUN writes: > >> >> > >> >> > On Tue, Apr 03, 2012 at 01:45:30AM -0400, enoch wrote: > >> >> >> YongHyeon PYUN writes: > >> >> >> > >> >> >> > On Mon, Apr 02, 2012 at 07:36:36PM -0400, enoch wrote: > >> >> >> >> YongHyeon PYUN writes: > >> >> >> >> > >> >> >> >> > On Mon, Apr 02, 2012 at 03:50:02AM -0400, enoch wrote: > >> >> >> >> >> On 04/02/2012 03:52 PM, YongHyeon PYUN wrote: > >> >> >> >> >> > On Fri, Mar 30, 2012 at 10:40:44AM -0400, enoch wrote: > >> >> >> >> >> >> On 03/30/2012 19:38, YongHyeon PYUN wrote: > >> >> >> >> >> >>> On Fri, Mar 30, 2012 at 03:01:52AM -0400, enoch wrote: > >> >> >> >> >> >>>> Recently it became extremely difficult to pass the DHCP discovery step > >> >> >> >> >> >>>> on boot. Now I am using the buggy [nve] instead. > >> >> >> >> >> >>>> > >> >> >> >> >> >>>> Can anyone help? > >> >> >> >> >> >>>> > >> >> >> >> >> >>> > >> >> >> >> >> >>> Did you set synchronous_dhclient option in rc.conf? > >> >> >> >> >> >>> > >> >> >> >> >> >> > >> >> >> >> >> >> Yes: ifconfig_nfe0="SYNCDHCP" > >> >> >> >> >> >> > >> >> >> >> >> >> I guess [nfe] is undergoing gradual devel changes of some sort as before > >> >> >> >> >> >> it had some chance of reporting "empty headers" on initial ifconfig and > >> >> >> >> >> >> refusing to work. Sorry, I should have reported when encountering the > >> >> >> >> >> >> first problems rather than solve by reboot. > >> >> >> >> >> > > >> >> >> >> >> > Would you show me the output of both dmesg(nfe(4) and its PHY only) > >> >> >> >> >> > and 'sysctl dev.nfe.0.stats'? > >> >> >> >> >> > It would be also helpful to know whether nfe(4) still sees > >> >> >> >> >> > incoming traffic. > >> >> >> >> >> > Does assigning static IP work? > >> >> >> >> >> > > >> >> >> >> >> > >> >> >> >> >> Static IP direct communication attempt from this desktop to another > >> >> >> >> >> laptop through a crossover cable fails as follows. Thanks. > >> >> >> >> >> > >> >> >> >> >> nfe0: flags=8843 metric 0 mtu 1500 > >> >> >> >> >> options=82008 > >> >> >> >> >> ether 00:1f:bc:00:19:dc > >> >> >> >> >> inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255 > >> >> >> >> >> media: Ethernet autoselect (1000baseT > >> >> >> >> >> ) > >> >> >> >> >> status: active > >> >> >> >> >> > >> >> >> >> >> nfe0: link state changed to UP > >> >> >> >> >> nfe0: port 0xf200-0xf207 > >> >> >> >> >> mem 0xefffb000-0xefffbfff irq 21 at device 20.0 on pci0 > >> >> >> >> >> miibus1: on nfe0 > >> >> >> >> > > >> >> >> >> > It seems you've omitted PHY driver here. What PHY driver was > >> >> >> >> > attached to nfe(4)? > >> >> >> >> > > >> >> >> >> > >> >> >> >> miibus1: on nfe0 > >> >> >> >> rgephy1: PHY 1 on miibus1 > >> >> >> >> > >> >> >> >> >> nfe0: Ethernet address: 00:1f:bc:00:19:dc > >> >> >> >> >> nfe0: [FILTER] > >> >> >> >> >> nfe0: discard frame w/o leading ethernet header (len 0 pkt len 0) > >> >> >> >> >> nfe0: discard frame w/o leading ethernet header (len 0 pkt len 0) > >> >> >> >> >> nfe0: link state changed to UP > >> >> >> >> >> nfe0: discard frame w/o leading ethernet header (len 0 pkt len 0) > >> >> >> >> >> nfe0: discard frame w/o leading ethernet header (len 0 pkt len 0) > >> >> >> >> >> nfe0: discard frame w/o leading ethernet header (len 0 pkt len 0) > >> >> >> >> >> > >> >> >> >> >> dev.nfe.0.stats.rx.frame_errors: 0 > >> >> >> >> >> dev.nfe.0.stats.rx.extra_bytes: 0 > >> >> >> >> >> dev.nfe.0.stats.rx.late_cols: 0 > >> >> >> >> >> dev.nfe.0.stats.rx.runts: 0 > >> >> >> >> >> dev.nfe.0.stats.rx.jumbos: 0 > >> >> >> >> >> dev.nfe.0.stats.rx.fifo_overuns: 0 > >> >> >> >> >> dev.nfe.0.stats.rx.crc_errors: 0 > >> >> >> >> >> dev.nfe.0.stats.rx.fae: 0 > >> >> >> >> >> dev.nfe.0.stats.rx.len_errors: 0 > >> >> >> >> >> dev.nfe.0.stats.rx.unicast: 56 > >> >> >> >> >> dev.nfe.0.stats.rx.multicast: 0 > >> >> >> >> >> dev.nfe.0.stats.rx.broadcast: 280 > >> >> >> >> >> dev.nfe.0.stats.tx.octets: 7517 > >> >> >> >> >> dev.nfe.0.stats.tx.zero_rexmits: 51 > >> >> >> >> >> dev.nfe.0.stats.tx.one_rexmits: 0 > >> >> >> >> >> dev.nfe.0.stats.tx.multi_rexmits: 0 > >> >> >> >> >> dev.nfe.0.stats.tx.late_cols: 0 > >> >> >> >> >> dev.nfe.0.stats.tx.fifo_underuns: 0 > >> >> >> >> >> dev.nfe.0.stats.tx.carrier_losts: 0 > >> >> >> >> >> dev.nfe.0.stats.tx.excess_deferrals: 0 > >> >> >> >> >> dev.nfe.0.stats.tx.retry_errors: 0 > >> >> >> >> >> > >> >> >> >> > > >> >> >> >> > Thanks. Would you show me the output of "pciconf -lcbv"? > >> >> >> >> > > >> >> >> >> > >> >> >> >> nfe0@pci0:0:20:0: class=0x068000 card=0x10003842 chip=0x026910de rev=0xa3 hdr=0x00 > >> >> >> >> vendor = 'NVIDIA Corporation' > >> >> >> >> device = 'MCP51 Network Bus Enumerator' > >> >> >> >> class = bridge > >> >> >> >> bar [10] = type Memory, range 32, base 0xefffb000, size 4096, enabled > >> >> >> >> bar [14] = type I/O Port, range 32, base 0xf200, size 8, enabled > >> >> >> >> cap 01[44] = powerspec 2 supports D0 D1 D2 D3 current D0 > >> >> >> >> > >> >> >> >> Interestingly, now that nfe0 is using a static IP it sometimes boots > >> >> >> >> up properly. Are you interested in its good working? > >> >> >> > > >> >> >> > Yes I am. Would you try attached patch and let me know whether the > >> >> >> > patch makes any difference on your box? > >> >> >> > >> >> >> Sorry to report: The patch was applied (to 8-stable latest code) but out > >> >> >> of 3 boots only one succeeded. Same stream of "nfe0: discard frame w/o > >> >> >> leading ethernet header (len 0 pkt len 0)" messages. > >> >> > > >> >> > Ok, back out previous patch and try attached one. > >> >> > >> >> With these two patch files applied to the 8-stable code, buildkernel > >> >> fails as follows. > >> >> > >> >> /usr/src/sys/modules/nfe/../../dev/nfe/if_nfe.c: In function 'nfe_attach': > >> >> /usr/src/sys/modules/nfe/../../dev/nfe/if_nfe.c:629: error: 'struct mii_softc' has no member named 'mii_mpd_oui' > >> >> /usr/src/sys/modules/nfe/../../dev/nfe/if_nfe.c:629: error: 'struct mii_softc' has no member named 'mii_mpd_oui' > >> >> /usr/src/sys/modules/nfe/../../dev/nfe/if_nfe.c:630: error: 'struct mii_softc' has no member named 'mii_mpd_model' > >> >> *** Error code 1 > >> >> > >> > > >> > Oops, sorry I forgot that this part of change was not merged to > >> > stable/8. I've attached a minimal patch which would be cleanly > >> > applied to stable/8. > >> > >> Wasn't the attached diff3 already included in diff2? Seems to me the > >> wrong file was attached this time. Please advise. > > > > diff2 is subset of diff3 but it can be merged to stable/8 and > > stable/7. Probably diff2 may have better chance to fully > > reinitialize PHY but let's see whether diff3 also makes difference > > on your box. > > So back out any changes and apply diff3. > > I'm sorry, this if_nfereg.h patch is not enough. Boot failure frequency > is just the same. I guess I should consider migrating to 9-stable. The > problem with 9-stable is that most of the time it does not build :-( > > Thanks for your efforts. Enoch. Here is updated patch for stable/8. Let me know whether it makes any difference. --opJtzjQTFsWo+cga Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="nfe.power.diff4" Index: sys/dev/nfe/if_nfe.c =================================================================== --- sys/dev/nfe/if_nfe.c (revision 233484) +++ sys/dev/nfe/if_nfe.c (working copy) @@ -338,7 +338,11 @@ { struct nfe_softc *sc; struct ifnet *ifp; + struct mii_softc *miisc; + struct mii_data *mii; bus_addr_t dma_addr_max; + uint32_t pwr; + uint16_t id1, id2; int error = 0, i, msic, reg, rid; sc = device_get_softc(dev); @@ -615,6 +619,30 @@ device_printf(dev, "attaching PHYs failed\n"); goto fail; } + mii = device_get_softc(sc->nfe_miibus); + miisc = LIST_FIRST(&mii->mii_phys); + /* + * XXX + * This kind of magic should live in PHY driver. + * Should have better to way to use MII_OUI_REALTEK, MII_OUI_xxREALTEK + * and MII_MODEL_REALTEK_RTL8169S/MII_MODEL_xxREALTEK_RTL8169S. + */ + id1 = nfe_miibus_readreg(dev, miisc->mii_phy, MII_PHYIDR1); + id2 = nfe_miibus_readreg(dev, miisc->mii_phy, MII_PHYIDR2); + if ((MII_OUI(id1, id2) == 0x000020 || MII_OUI(id1, id2) == 0x000732) && + MII_MODEL(id2) == 0x0011) { +#if 1 + device_printf(dev, "Forced PHY reset\n"); +#endif + pwr = NFE_READ(sc, NFE_PWR2_CTL); + NFE_WRITE(sc, NFE_PWR2_CTL, pwr | NFE_PWR2_PHY_RESET); + NFE_READ(sc, NFE_PWR2_CTL); + DELAY(1000 * 50); + NFE_WRITE(sc, NFE_PWR2_CTL, pwr); + NFE_READ(sc, NFE_PWR2_CTL); + DELAY(1000 * 50); + nfe_miibus_writereg(dev, miisc->mii_phy, 0x1F, 0); + } ether_ifattach(ifp, sc->eaddr); TASK_INIT(&sc->nfe_int_task, 0, nfe_int_task, sc); Index: sys/dev/nfe/if_nfereg.h =================================================================== --- sys/dev/nfe/if_nfereg.h (revision 233484) +++ sys/dev/nfe/if_nfereg.h (working copy) @@ -188,8 +188,9 @@ #define NFE_PWR_VALID (1 << 8) #define NFE_PWR_WAKEUP (1 << 15) -#define NFE_PWR2_WAKEUP_MASK 0x0f11 +#define NFE_PWR2_WAKEUP_MASK 0x0f15 #define NFE_PWR2_REVA3 (1 << 0) +#define NFE_PWR2_PHY_RESET 0x0004 #define NFE_PWR2_GATE_CLOCKS 0x0f00 #define NFE_MEDIA_SET 0x10000 --opJtzjQTFsWo+cga-- From owner-freebsd-net@FreeBSD.ORG Mon Apr 9 11:07:18 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 045B0106566B for ; Mon, 9 Apr 2012 11:07:18 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id E1E948FC1E for ; Mon, 9 Apr 2012 11:07:17 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q39B7H8J039682 for ; Mon, 9 Apr 2012 11:07:17 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q39B7HQc039680 for freebsd-net@FreeBSD.org; Mon, 9 Apr 2012 11:07:17 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 9 Apr 2012 11:07:17 GMT Message-Id: <201204091107.q39B7HQc039680@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, 09 Apr 2012 11:07:18 -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/166727 net [msk] msk driver keeps erroring o kern/166724 net [re] if_re watchdog timeout o kern/166550 net [netinet] [patch] Some log lines about arp do not incl o kern/166462 net [gre] gre(4) when using a tunnel source address from c o kern/166372 net [patch] ipfilter drops UDP packets with zero checksum o kern/166285 net [arp] FreeBSD v8.1 REL p8 arp: unknown hardware addres o kern/166255 net [net] [patch] It should be possible to disable "promis o kern/165963 net [panic] [ipf] ipfilter/nat NULL pointer deference o kern/165903 net mbuf leak o kern/165863 net [panic] [netinet] [patch] in_lltable_prefix_free() rac o kern/165643 net [net] [patch] Missing vnet restores in net/if_ethersub o kern/165622 net [ndis][panic][patch] Unregistered use of FPU in kernel s kern/165562 net [request] add support for Intel i350 in FreeBSD 7.4 o kern/165526 net [bxe] UDP packets checksum calculation whithin if_bxe o kern/165488 net [ppp] [panic] Fatal trap 12 jails and ppp , kernel wit o kern/165305 net [ip6] [request] Feature parity between IP_TOS and IPV6 o kern/165296 net [vlan] [patch] Fix EVL_APPLY_VLID, update EVL_APPLY_PR o kern/165181 net [igb] igb freezes after about 2 weeks of uptime o kern/165174 net [patch] [tap] allow tap(4) to keep its address on clos o kern/165152 net [ip6] Does not work through the issue of ipv6 addresse o kern/164569 net [msk] [hang] msk network driver cause freeze in FreeBS o kern/164495 net [igb] connect double head igb to switch cause system t o kern/164490 net [pfil] Incorrect IP checksum on pfil pass from ip_outp o kern/164475 net [gre] gre misses RUNNING flag after a reboot o kern/164400 net [ipsec] immediate crash after the start of ipsec proce o kern/164265 net [netinet] [patch] tcp_lro_rx computes wrong checksum i o kern/163903 net [igb] "igb0:tx(0)","bpf interface lock" v2.2.5 9-STABL o kern/163481 net freebsd do not add itself to ping route packet o kern/162927 net [tun] Modem-PPP error ppp[1538]: tun0: Phase: Clearing o kern/162926 net [ipfilter] Infinite loop in ipfilter with fragmented I o kern/162558 net [dummynet] [panic] seldom dummynet panics o kern/162509 net [re] [panic] Kernel panic may be related to if_re.c (r o kern/162153 net [em] intel em driver 7.2.4 don't compile o kern/162110 net [igb] [panic] RELENG_9 panics on boot in IGB driver - o kern/162028 net [ixgbe] [patch] misplaced #endif in ixgbe.c o kern/161381 net [re] RTL8169SC - re0: PHY write failed o kern/161277 net [em] [patch] BMC cannot receive IPMI traffic after loa o kern/160873 net [igb] igb(4) from HEAD fails to build on 7-STABLE o kern/160750 net Intel PRO/1000 connection breaks under load until rebo o kern/160693 net [gif] [em] Multicast packet are not passed from GIF0 t o kern/160420 net [msk] phy write timeout on HP 5310m o kern/160293 net [ieee80211] ppanic] kernel panic during network setup o kern/160206 net [gif] gifX stops working after a while (IPv6 tunnel) o kern/159817 net [udp] write UDPv4: No buffer space available (code=55) o kern/159629 net [ipsec] [panic] kernel panic with IPsec in transport m o kern/159621 net [tcp] [panic] panic: soabort: so_count o kern/159603 net [netinet] [patch] in_ifscrubprefix() - network route c o kern/159601 net [netinet] [patch] in_scrubprefix() - loopback route re o kern/159294 net [em] em watchdog timeouts o kern/159203 net [wpi] Intel 3945ABG Wireless LAN not support IBSS o kern/158930 net [bpf] BPF element leak in ifp->bpf_if->bif_dlist o kern/158726 net [ip6] [patch] ICMPv6 Router Announcement flooding limi o kern/158694 net [ix] [lagg] ix0 is not working within lagg(4) o kern/158665 net [ip6] [panic] kernel pagefault in in6_setscope() o kern/158635 net [em] TSO breaks BPF packet captures with em driver f kern/157802 net [dummynet] [panic] kernel panic in dummynet o kern/157785 net amd64 + jail + ipfw + natd = very slow outbound traffi o kern/157429 net [re] Realtek RTL8169 doesn't work with re(4) o kern/157418 net [em] em driver lockup during boot on Supermicro X9SCM- o kern/157410 net [ip6] IPv6 Router Advertisements Cause Excessive CPU U o kern/157287 net [re] [panic] INVARIANTS panic (Memory modified after f o kern/157209 net [ip6] [patch] locking error in rip6_input() (sys/netin o kern/157200 net [network.subr] [patch] stf(4) can not communicate betw o kern/157182 net [lagg] lagg interface not working together with epair o kern/156877 net [dummynet] [panic] dummynet move_pkt() null ptr derefe o kern/156667 net [em] em0 fails to init on CURRENT after March 17 o kern/156408 net [vlan] Routing failure when using VLANs vs. Physical e o kern/156328 net [icmp]: host can ping other subnet but no have IP from o kern/156317 net [ip6] Wrong order of IPv6 NS DAD/MLD Report o kern/156283 net [ip6] [patch] nd6_ns_input - rtalloc_mpath does not re o kern/156279 net [if_bridge][divert][ipfw] unable to correctly re-injec o kern/156226 net [lagg]: failover does not announce the failover to swi o kern/156030 net [ip6] [panic] Crash in nd6_dad_start() due to null ptr o kern/155772 net ifconfig(8): ioctl (SIOCAIFADDR): File exists on direc o kern/155680 net [multicast] problems with multicast s kern/155642 net [request] Add driver for Realtek RTL8191SE/RTL8192SE W o kern/155597 net [panic] Kernel panics with "sbdrop" message o kern/155420 net [vlan] adding vlan break existent vlan o kern/155177 net [route] [panic] Panic when inject routes in kernel o kern/155030 net [igb] igb(4) DEVICE_POLLING does not work with carp(4) o kern/155010 net [msk] ntfs-3g via iscsi using msk driver cause kernel o kern/154943 net [gif] ifconfig gifX create on existing gifX clears IP s kern/154851 net [request]: Port brcm80211 driver from Linux to FreeBSD o kern/154850 net [netgraph] [patch] ng_ether fails to name nodes when t o kern/154679 net [em] Fatal trap 12: "em1 taskq" only at startup (8.1-R o kern/154600 net [tcp] [panic] Random kernel panics on tcp_output o kern/154557 net [tcp] Freeze tcp-session of the clients, if in the gat o kern/154443 net [if_bridge] Kernel module bridgestp.ko missing after u o kern/154286 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/154255 net [nfs] NFS not responding o kern/154214 net [stf] [panic] Panic when creating stf interface o kern/154185 net race condition in mb_dupcl o kern/154169 net [multicast] [ip6] Node Information Query multicast add o kern/154134 net [ip6] stuck kernel state in LISTEN on ipv6 daemon whic o kern/154091 net [netgraph] [panic] netgraph, unaligned mbuf? o conf/154062 net [vlan] [patch] change to way of auto-generatation of v o kern/153937 net [ral] ralink panics the system (amd64 freeBSDD 8.X) wh o kern/153936 net [ixgbe] [patch] MPRC workaround incorrectly applied to o kern/153816 net [ixgbe] ixgbe doesn't work properly with the Intel 10g o kern/153772 net [ixgbe] [patch] sysctls reference wrong XON/XOFF varia o kern/153497 net [netgraph] netgraph panic due to race conditions o kern/153454 net [patch] [wlan] [urtw] Support ad-hoc and hostap modes o kern/153308 net [em] em interface use 100% cpu o kern/153244 net [em] em(4) fails to send UDP to port 0xffff o kern/152893 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/152853 net [em] tftpd (and likely other udp traffic) fails over e o kern/152828 net [em] poor performance on 8.1, 8.2-PRE o kern/152569 net [net]: Multiple ppp connections and routing table prob o kern/152235 net [arp] Permanent local ARP entries are not properly upd o kern/152141 net [vlan] [patch] encapsulate vlan in ng_ether before out o kern/152036 net [libc] getifaddrs(3) returns truncated sockaddrs for n o kern/151690 net [ep] network connectivity won't work until dhclient is o kern/151681 net [nfs] NFS mount via IPv6 leads to hang on client with o kern/151593 net [igb] [panic] Kernel panic when bringing up igb networ o kern/150920 net [ixgbe][igb] Panic when packets are dropped with heade o kern/150557 net [igb] igb0: Watchdog timeout -- resetting o kern/150251 net [patch] [ixgbe] Late cable insertion broken o kern/150249 net [ixgbe] Media type detection broken o bin/150224 net ppp(8) does not reassign static IP after kill -KILL co f kern/149969 net [wlan] [ral] ralink rt2661 fails to maintain connectio o kern/149937 net [ipfilter] [patch] kernel panic in ipfilter IP fragmen o kern/149643 net [rum] device not sending proper beacon frames in ap mo o kern/149609 net [panic] reboot after adding second default route o kern/149117 net [inet] [patch] in_pcbbind: redundant test o kern/149086 net [multicast] Generic multicast join failure in 8.1 o kern/148018 net [flowtable] flowtable crashes on ia64 o kern/147912 net [boot] FreeBSD 8 Beta won't boot on Thinkpad i1300 11 o kern/147894 net [ipsec] IPv6-in-IPv4 does not work inside an ESP-only o kern/147155 net [ip6] setfb not work with ipv6 o kern/146845 net [libc] close(2) returns error 54 (connection reset by f kern/146792 net [flowtable] flowcleaner 100% cpu's core load o kern/146719 net [pf] [panic] PF or dumynet kernel panic o kern/146534 net [icmp6] wrong source address in echo reply o kern/146427 net [mwl] Additional virtual access points don't work on m o kern/146426 net [mwl] 802.11n rates not possible on mwl o kern/146425 net [mwl] mwl dropping all packets during and after high u f kern/146394 net [vlan] IP source address for outgoing connections o bin/146377 net [ppp] [tun] Interface doesn't clear addresses when PPP o kern/146358 net [vlan] wrong destination MAC address o kern/146165 net [wlan] [panic] Setting bssid in adhoc mode causes pani o kern/146082 net [ng_l2tp] a false invaliant check was performed in ng_ o kern/146037 net [panic] mpd + CoA = kernel panic o kern/145825 net [panic] panic: soabort: so_count o kern/145728 net [lagg] Stops working lagg between two servers. p kern/145600 net TCP/ECN behaves different to CE/CWR than ns2 reference f kern/144917 net [flowtable] [panic] flowtable crashes system [regressi o kern/144882 net MacBookPro =>4.1 does not connect to BSD in hostap wit o kern/144874 net [if_bridge] [patch] if_bridge frees mbuf after pfil ho o conf/144700 net [rc.d] async dhclient breaks stuff for too many people o kern/144616 net [nat] [panic] ip_nat panic FreeBSD 7.2 f kern/144315 net [ipfw] [panic] freebsd 8-stable reboot after add ipfw o kern/144231 net bind/connect/sendto too strict about sockaddr length o kern/143846 net [gif] bringing gif3 tunnel down causes gif0 tunnel to s kern/143673 net [stf] [request] there should be a way to support multi s kern/143666 net [ip6] [request] PMTU black hole detection not implemen o kern/143622 net [pfil] [patch] unlock pfil lock while calling firewall o kern/143593 net [ipsec] When using IPSec, tcpdump doesn't show outgoin o kern/143591 net [ral] RT2561C-based DLink card (DWL-510) fails to work o kern/143208 net [ipsec] [gif] IPSec over gif interface not working o kern/143034 net [panic] system reboots itself in tcp code [regression] o kern/142877 net [hang] network-related repeatable 8.0-STABLE hard hang o kern/142774 net Problem with outgoing connections on interface with mu o kern/142772 net [libc] lla_lookup: new lle malloc failed o kern/142018 net [iwi] [patch] Possibly wrong interpretation of beacon- o kern/141861 net [wi] data garbled with WEP and wi(4) with Prism 2.5 f kern/141741 net Etherlink III NIC won't work after upgrade to FBSD 8, o kern/140742 net rum(4) Two asus-WL167G adapters cannot talk to each ot o kern/140682 net [netgraph] [panic] random panic in netgraph o kern/140634 net [vlan] destroying if_lagg interface with if_vlan membe o kern/140619 net [ifnet] [patch] refine obsolete if_var.h comments desc o kern/140346 net [wlan] High bandwidth use causes loss of wlan connecti o kern/140142 net [ip6] [panic] FreeBSD 7.2-amd64 panic w/IPv6 o kern/140066 net [bwi] install report for 8.0 RC 2 (multiple problems) o kern/139565 net [ipfilter] ipfilter ioctl SIOCDELST broken o kern/139387 net [ipsec] Wrong lenth of PF_KEY messages in promiscuous o bin/139346 net [patch] arp(8) add option to remove static entries lis o kern/139268 net [if_bridge] [patch] allow if_bridge to forward just VL p kern/139204 net [arp] DHCP server replies rejected, ARP entry lost bef o kern/139117 net [lagg] + wlan boot timing (EBUSY) o kern/139058 net [ipfilter] mbuf cluster leak on FreeBSD 7.2 o kern/138850 net [dummynet] dummynet doesn't work correctly on a bridge o kern/138782 net [panic] sbflush_internal: cc 0 || mb 0xffffff004127b00 o kern/138688 net [rum] possibly broken on 8 Beta 4 amd64: able to wpa a o kern/138678 net [lo] FreeBSD does not assign linklocal address to loop o kern/138620 net [lagg] [patch] lagg port bpf-writes blocked o kern/138407 net [gre] gre(4) interface does not come up after reboot o kern/138332 net [tun] [lor] ifconfig tun0 destroy causes LOR if_adata/ o kern/138266 net [panic] kernel panic when udp benchmark test used as r o kern/138177 net [ipfilter] FreeBSD crashing repeatedly in ip_nat.c:257 f kern/138029 net [bpf] [panic] periodically kernel panic and reboot o kern/137881 net [netgraph] [panic] ng_pppoe fatal trap 12 p bin/137841 net [patch] wpa_supplicant(8) cannot verify SHA256 signed p kern/137776 net [rum] panic in rum(4) driver on 8.0-BETA2 o bin/137641 net ifconfig(8): various problems with "vlan_device.vlan_i o kern/137392 net [ip] [panic] crash in ip_nat.c line 2577 o kern/137372 net [ral] FreeBSD doesn't support wireless interface from o kern/137089 net [lagg] lagg falsely triggers IPv6 duplicate address de o bin/136994 net [patch] ifconfig(8) print carp mac address o kern/136911 net [netgraph] [panic] system panic on kldload ng_bpf.ko t o kern/136618 net [pf][stf] panic on cloning interface without unit numb o kern/135502 net [periodic] Warning message raised by rtfree function i o kern/134583 net [hang] Machine with jail freezes after random amount o o kern/134531 net [route] [panic] kernel crash related to routes/zebra o kern/134157 net [dummynet] dummynet loads cpu for 100% and make a syst o kern/133969 net [dummynet] [panic] Fatal trap 12: page fault while in o kern/133968 net [dummynet] [panic] dummynet kernel panic o kern/133736 net [udp] ip_id not protected ... o kern/133595 net [panic] Kernel Panic at pcpu.h:195 o kern/133572 net [ppp] [hang] incoming PPTP connection hangs the system o kern/133490 net [bpf] [panic] 'kmem_map too small' panic on Dell r900 o kern/133235 net [netinet] [patch] Process SIOCDLIFADDR command incorre f kern/133213 net arp and sshd errors on 7.1-PRERELEASE o kern/133060 net [ipsec] [pfsync] [panic] Kernel panic with ipsec + pfs o kern/132889 net [ndis] [panic] NDIS kernel crash on load BCM4321 AGN d o conf/132851 net [patch] rc.conf(5): allow to setfib(1) for service run o kern/132734 net [ifmib] [panic] panic in net/if_mib.c o kern/132705 net [libwrap] [patch] libwrap - infinite loop if hosts.all o kern/132672 net [ndis] [panic] ndis with rt2860.sys causes kernel pani o kern/132554 net [ipl] There is no ippool start script/ipfilter magic t o kern/132354 net [nat] Getting some packages to ipnat(8) causes crash o kern/132277 net [crypto] [ipsec] poor performance using cryptodevice f o kern/131781 net [ndis] ndis keeps dropping the link o kern/131776 net [wi] driver fails to init o kern/131753 net [altq] [panic] kernel panic in hfsc_dequeue o kern/131601 net [ipfilter] [panic] 7-STABLE panic in nat_finalise (tcp o bin/131567 net [socket] [patch] Update for regression/sockets/unix_cm o bin/131365 net route(8): route add changes interpretation of network f kern/130820 net [ndis] wpa_supplicant(8) returns 'no space on device' o kern/130628 net [nfs] NFS / rpc.lockd deadlock on 7.1-R o conf/130555 net [rc.d] [patch] No good way to set ipfilter variables a o kern/130525 net [ndis] [panic] 64 bit ar5008 ndisgen-erated driver cau o kern/130311 net [wlan_xauth] [panic] hostapd restart causing kernel pa o kern/130109 net [ipfw] Can not set fib for packets originated from loc f kern/130059 net [panic] Leaking 50k mbufs/hour f kern/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129517 net [ipsec] [panic] double fault / stack overflow f kern/129508 net [carp] [panic] Kernel panic with EtherIP (may be relat o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129197 net [panic] 7.0 IP stack related panic o bin/128954 net ifconfig(8) deletes valid routes o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net [arp] arp: Segmentation fault (core dumped) f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by p kern/127360 net [socket] TOE socket options missing from sosetopt() o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126339 net [ipw] ipw driver drops the connection o kern/126075 net [inet] [patch] internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124225 net [ndis] [patch] ndis network driver sometimes loses net o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. o kern/123892 net [tap] [patch] No buffer space available o kern/123890 net [ppp] [panic] crash & reboot on work with PPP low-spee o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o kern/123758 net [panic] panic while restarting net/freenet6 o bin/123633 net ifconfig(8) doesn't set inet and ether address in one o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices f kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup ieee o bin/121895 net [patch] rtsol(8)/rtsold(8) doesn't handle managed netw s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121443 net [gif] [lor] icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o bin/121359 net [patch] [security] ppp(8): fix local stack overflow in o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/120966 net [rum] kernel panic with if_rum and WPA encryption o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [udp] [panic] gnugk causes kernel panic when closing U o bin/120060 net routed(8) deletes link-level routes in the presence of o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o kern/118727 net [netgraph] [patch] [request] add new ng_pf module o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/115019 net [netgraph] ng_ether upper hook packet flow stops on ad o kern/115002 net [wi] if_wi timeout. failed allocation (busy bit). ifco o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o kern/113432 net [ucom] WARNING: attempt to net_add_domain(netgraph) af o kern/112722 net [ipsec] [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/111537 net [inet6] [patch] ip6_input() treats mbuf cluster wrong o kern/111457 net [ral] ral(4) freeze o kern/110284 net [if_ethersubr] Invalid Assumption in SIOCSIFADDR in et o kern/110249 net [kernel] [regression] [patch] setsockopt() error regre o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o conf/107035 net [patch] bridge(8): bridge interface given in rc.conf n o kern/106444 net [netgraph] [panic] Kernel Panic on Binding to an ip to o kern/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/105945 net Address can disappear from network interface s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] o kern/104851 net [inet6] [patch] On link routes not configured when usi o kern/104751 net [netgraph] kernel panic, when getting info about my tr o kern/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac o kern/102540 net [netgraph] [patch] supporting vlan(4) by ng_fec(4) o conf/102502 net [netgraph] [patch] ifconfig name does't rename netgrap o kern/102035 net [plip] plip networking disables parallel port printing o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau o kern/100709 net [libc] getaddrinfo(3) should return TTL info o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/98597 net [inet6] Bug in FreeBSD 6.1 IPv6 link-local DAD procedu o bin/98218 net wpa_supplicant(8) blacklist not working o kern/97306 net [netgraph] NG_L2TP locks after connection with failed o conf/97014 net [gif] gifconfig_gif? in rc.conf does not recognize IPv f kern/96268 net [socket] TCP socket performance drops by 3000% if pack o kern/95519 net [ral] ral0 could not map mbuf o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear f kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/93019 net [ppp] ppp and tunX problems: no traffic after restarti o kern/92880 net [libc] [patch] almost rewritten inet_network(3) functi s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu o kern/91859 net [ndis] if_ndis does not work with Asus WL-138 s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging s kern/90086 net [hang] 5.4p8 on supermicro P8SCT hangs during boot if o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/87421 net [netgraph] [panic]: ng_ether + ng_eiface + if_bridge s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/86871 net [tcp] [patch] allocation logic for PCBs in TIME_WAIT s o kern/86427 net [lor] Deadlock with FASTIPSEC and nat o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter o kern/85780 net 'panic: bogus refcnt 0' in routing/ipv6 o bin/85445 net ifconfig(8): deprecated keyword to ifconfig inoperativ p kern/85320 net [gre] [patch] possible depletion of kernel stack in ip o bin/82975 net route change does not parse classfull network as given o kern/82881 net [netgraph] [panic] ng_fec(4) causes kernel panic after o kern/82468 net Using 64MB tcp send/recv buffers, trafficflow stops, i o bin/82185 net [patch] ndp(8) can delete the incorrect entry o kern/81095 net IPsec connection stops working if associated network i o kern/78968 net FreeBSD freezes on mbufs exhaustion (network interface o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if o kern/77341 net [ip6] problems with IPV6 implementation s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/75873 net Usability problem with non-RFC-compliant IP spoof prot s kern/75407 net [an] an(4): no carrier after short time a kern/71474 net [route] route lookup does not skip interfaces marked d o kern/71469 net default route to internet magically disappears with mu o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/68889 net [panic] m_copym, length > size of mbuf chain o kern/66225 net [netgraph] [patch] extend ng_eiface(4) control message o kern/65616 net IPSEC can't detunnel GRE packets after real ESP encryp s kern/60293 net [patch] FreeBSD arp poison patch a kern/56233 net IPsec tunnel (ESP) over IPv6: MTU computation is wrong s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr s kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". o kern/31940 net ip queue length too short for >500kpps o kern/31647 net [libc] socket calls can return undocumented EINVAL o kern/30186 net [libc] getaddrinfo(3) does not handle incorrect servna o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c f kern/24959 net [patch] proper TCP_NOPUSH/TCP_CORK compatibility o conf/23063 net [arp] [patch] for static ARP tables in rc.network o kern/21998 net [socket] [patch] ident only for outgoing connections o kern/5877 net [socket] sb_cc counts control data as well as data dat 402 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Apr 9 12:07:21 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4AF72106566C for ; Mon, 9 Apr 2012 12:07:21 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id 2F8478FC1D for ; Mon, 9 Apr 2012 12:07:21 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SHDNQ-000BY7-Jm for net@freebsd.org; Mon, 09 Apr 2012 12:07:21 +0000 Date: Mon, 09 Apr 2012 21:07:19 +0900 Message-ID: From: Randy Bush To: FreeBSD Net User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: Subject: dummynet dummy 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, 09 Apr 2012 12:07:21 -0000 new to dummynet FreeBSD dum0.sea.rg.net 9.0-STABLE FreeBSD 9.0-STABLE #0: Thu Apr 5 00:53:01 UTC 2012 root@dum0:/usr/obj/usr/src/sys/GENERIC amd64 dum0# ipfw show 00100 0 0 deny log ip from any to any ipoptions ssrr,lsrr,rr 00200 0 0 allow ip from any to any via lo0 00300 0 0 deny log ip from 127.0.0.0/8 to any 00400 0 0 deny log ip from any to 127.0.0.0/8 00500 0 0 allow tcp from me to any dst-port 25 00600 0 0 deny tcp from any to any dst-port 25 00700 6 7389 pipe 1 tcp from 147.28.2.129 to 147.28.2.133 00800 28 34816 pipe 2 tcp from 147.28.2.133 to 147.28.2.129 65530 590 64704 allow ip from any to any 65535 36 5331 deny ip from any to any dum0# ipfw 900 pipe 1 config queue 20 delay 10ms ipfw: bad command `1' i was following the cookbook as closely as i could. must be something simple, but i am not seeing it. randy From owner-freebsd-net@FreeBSD.ORG Mon Apr 9 12:40:13 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4E45D106566C for ; Mon, 9 Apr 2012 12:40:13 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id C40398FC16 for ; Mon, 9 Apr 2012 12:40:12 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 98ADA7300A; Mon, 9 Apr 2012 14:59:22 +0200 (CEST) Date: Mon, 9 Apr 2012 14:59:22 +0200 From: Luigi Rizzo To: Randy Bush Message-ID: <20120409125922.GA38663@onelab2.iet.unipi.it> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: FreeBSD Net Subject: Re: dummynet dummy 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, 09 Apr 2012 12:40:13 -0000 On Mon, Apr 09, 2012 at 09:07:19PM +0900, Randy Bush wrote: > new to dummynet > > FreeBSD dum0.sea.rg.net 9.0-STABLE FreeBSD 9.0-STABLE #0: Thu Apr 5 00:53:01 UTC 2012 root@dum0:/usr/obj/usr/src/sys/GENERIC amd64 > > dum0# ipfw show > 00100 0 0 deny log ip from any to any ipoptions ssrr,lsrr,rr > 00200 0 0 allow ip from any to any via lo0 > 00300 0 0 deny log ip from 127.0.0.0/8 to any > 00400 0 0 deny log ip from any to 127.0.0.0/8 > 00500 0 0 allow tcp from me to any dst-port 25 > 00600 0 0 deny tcp from any to any dst-port 25 > 00700 6 7389 pipe 1 tcp from 147.28.2.129 to 147.28.2.133 > 00800 28 34816 pipe 2 tcp from 147.28.2.133 to 147.28.2.129 > 65530 590 64704 allow ip from any to any > 65535 36 5331 deny ip from any to any > > dum0# ipfw 900 pipe 1 config queue 20 delay 10ms remove the '900' ipfw pipe 1 config queue 20 delay 10ms cheers luigi > ipfw: bad command `1' > > i was following the cookbook as closely as i could. must be something > simple, but i am not seeing it. > > randy > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Mon Apr 9 14:20:16 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 15CB2106564A for ; Mon, 9 Apr 2012 14:20:16 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id F36D98FC14 for ; Mon, 9 Apr 2012 14:20:15 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q39EKFwM022242 for ; Mon, 9 Apr 2012 14:20:15 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q39EKFIV022241; Mon, 9 Apr 2012 14:20:15 GMT (envelope-from gnats) Date: Mon, 9 Apr 2012 14:20:15 GMT Message-Id: <201204091420.q39EKFIV022241@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: st41ker Cc: Subject: Re: kern/154850: [netgraph] [patch] ng_ether fails to name nodes when the associated interface contains dots or colons X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: st41ker List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 14:20:16 -0000 The following reply was made to PR kern/154850; it has been noted by GNATS. From: st41ker To: bug-followup@FreeBSD.org, ndenev@gmail.com Cc: Subject: Re: kern/154850: [netgraph] [patch] ng_ether fails to name nodes when the associated interface contains dots or colons Date: Mon, 09 Apr 2012 17:07:39 +0300 Hello, Mentioned issue still exists in the FreeBSD-9-STABLE branch (it seems like every branch is affected). According to new rc subsystem (check the /etc/network.subr) where vlans are created - they're all using dots in ifnames. Also, function get_if_var() already has mentioned code for the replacing ". - / +" to "_". So mentioned patch will not break anything, even users ngctl scripts, since that users just can not use dots there by design. Thank you. From owner-freebsd-net@FreeBSD.ORG Mon Apr 9 16:34:50 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 719F01065675 for ; Mon, 9 Apr 2012 16:34:50 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 488798FC1A for ; Mon, 9 Apr 2012 16:34:50 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id A7EF8B9C4; Mon, 9 Apr 2012 12:34:49 -0400 (EDT) From: John Baldwin To: "Bjoern A. Zeeb" Date: Mon, 9 Apr 2012 12:15:13 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p10; KDE/4.5.5; amd64; ; ) References: <201204051447.52619.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201204091215.13312.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 09 Apr 2012 12:34:49 -0400 (EDT) Cc: net@freebsd.org Subject: Re: [PATCH] Add 40g media types 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, 09 Apr 2012 16:34:50 -0000 On Thursday, April 05, 2012 5:47:11 pm Bjoern A. Zeeb wrote: > On 5. Apr 2012, at 18:47 , John Baldwin wrote: > > Hi, > > > The patch below adds 40G media types for what I think are the "common" media > > types we would see on FreeBSD (could be wrong). One caveat though, we are > > running awfully low on bits now, and we don't have enough room for the 100G > > media types after this. Not sure what we want to do about that. :( > > Can't you also see a bright future for FDDI and Token Ring and the bling of > a Danish axe? Yeah, seems another experiment has proven to be going better > than expected a couple of decades ago. > > At this point I'd hope someone would get out the right MIB and tell us here's > the right thing to do... I was hoping someone else would suggest that. :) I pondered having an IFM_ETHER2, but that would be fugly. It is also convenient that the media word is stable across major versions. However, it seems to me if we want to reinvent this we should actually convert this to a struct instead of packing everything into a single word, and have the struct have various fields, and possibly split "speed" from "cable type". -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Mon Apr 9 16:34:51 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B0F461065689; Mon, 9 Apr 2012 16:34:51 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 80AE98FC1C; Mon, 9 Apr 2012 16:34:51 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id CD6C7B9C5; Mon, 9 Apr 2012 12:34:50 -0400 (EDT) From: John Baldwin To: Konstantin Belousov Date: Mon, 9 Apr 2012 12:19:39 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p10; KDE/4.5.5; amd64; ; ) References: <20120407133715.GU2358@deviant.kiev.zoral.com.ua> <20120408051125.GA2358@deviant.kiev.zoral.com.ua> In-Reply-To: <20120408051125.GA2358@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201204091219.39580.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 09 Apr 2012 12:34:50 -0400 (EDT) Cc: jfv@freebsd.org, Jack Vogel , net@freebsd.org Subject: Re: 82574L hangs (with r233708 e1000 driver). X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 16:34:51 -0000 On Sunday, April 08, 2012 1:11:25 am Konstantin Belousov wrote: > On Sat, Apr 07, 2012 at 04:22:07PM -0700, Jack Vogel wrote: > > Make sure you have any firmware up to the latest available, if that doesn't > > help > > let me know and I'll check internally to see if there are any outstanding > > issues > > in shared code, that will be after the weekend. > > I had BIOS rev. 151, after you hint I found rev. 154 on the site. > Now BIOS reports itself as MTCDT10N.86A.0154.2012.0323.1601, > March 23. > > Unfortunately, upgrade did not changed anything in regard of hanging > interface. Does reverting 233708 make any difference? Have you tried futzing around with kgdb when it is hung to see what state the device is in (software state at least)? -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Mon Apr 9 17:06:35 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 548421065674; Mon, 9 Apr 2012 17:06:35 +0000 (UTC) (envelope-from aboyer@averesystems.com) Received: from zimbra.averesystems.com (75-149-8-245-Pennsylvania.hfc.comcastbusiness.net [75.149.8.245]) by mx1.freebsd.org (Postfix) with ESMTP id 05AA68FC20; Mon, 9 Apr 2012 17:06:35 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zimbra.averesystems.com (Postfix) with ESMTP id B3EFB446006; Mon, 9 Apr 2012 13:05:54 -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 skriCG8kkTvX; Mon, 9 Apr 2012 13:05:52 -0400 (EDT) Received: from riven.arriad.com (fw.arriad.com [10.0.0.16]) by zimbra.averesystems.com (Postfix) with ESMTPSA id ABDC3446003; Mon, 9 Apr 2012 13:05:52 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Andrew Boyer In-Reply-To: Date: Mon, 9 Apr 2012 13:06:30 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8B0D75C6-5918-4EFE-9929-4344D877B320@averesystems.com> References: <201204020835.00357.jhb@freebsd.org> To: Andrew Thompson X-Mailer: Apple Mail (2.1084) Cc: freebsd-net@freebsd.org, John Baldwin Subject: Re: LACP kernel panics: /* unlocking is safe here */ 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, 09 Apr 2012 17:06:35 -0000 Makes sense to me. -Andrew On Apr 7, 2012, at 4:02 AM, Andrew Thompson wrote: > On 3 April 2012 00:35, John Baldwin wrote: >> On Friday, March 30, 2012 6:04:24 pm Andrew Boyer wrote: >>> While investigating a LACP issue, I turned on LACP_DEBUG on a debug = kernel. >> In this configuration it's easy to panic the kernel - just run = 'ifconfig lagg0 >> laggproto lacp' on a lagg that's already in LACP mode and receiving = LACP >> messages. >>>=20 >>> The problem is that lagg_lacp_detach() drops the lagg wlock (with = the >> comment in the title), which allows incoming LACP messages to get = through >> lagg_input() while the structure is being destroyed in lacp_detach(). >>>=20 >>> There's a very simple fix, but I don't know if it's the best way to = fix it. >> Resetting the protocol before calling sc_detach causes any further = incoming >> packets to be dropped until the lagg gets reconfigured. Thoughts? >>=20 >> This looks sensible. >=20 > Changing the order also needs an additional check as LAGG_PROTO_NONE > no longer means the detach is finished. If one ioctl sleeps then we > may nullify all the pointers upon wake that have already been set by > the other ioctl. >=20 > Does this look ok? >=20 > Index: if_lagg.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- if_lagg.c (revision 233252) > +++ if_lagg.c (working copy) > @@ -950,11 +950,11 @@ lagg_ioctl(struct ifnet *ifp, u_long cmd, = caddr_t > error =3D EPROTONOSUPPORT; > break; > } > + LAGG_WLOCK(sc); > if (sc->sc_proto !=3D LAGG_PROTO_NONE) { > - LAGG_WLOCK(sc); > + /* Reset protocol first in case detach unlocks = */ > + sc->sc_proto =3D LAGG_PROTO_NONE; > error =3D sc->sc_detach(sc); > - /* Reset protocol and pointers */ > - sc->sc_proto =3D LAGG_PROTO_NONE; > sc->sc_detach =3D NULL; > sc->sc_start =3D NULL; > sc->sc_input =3D NULL; > @@ -966,8 +966,11 @@ lagg_ioctl(struct ifnet *ifp, u_long cmd, caddr_t > sc->sc_lladdr =3D NULL; > sc->sc_req =3D NULL; > sc->sc_portreq =3D NULL; > - LAGG_WUNLOCK(sc); > + } else if (sc->sc_input !=3D NULL) { > + /* Still detaching */ > + error =3D EBUSY; > } > + LAGG_WUNLOCK(sc); > if (error !=3D 0) > break; > for (int i =3D 0; i < (sizeof(lagg_protos) / -------------------------------------------------- Andrew Boyer aboyer@averesystems.com From owner-freebsd-net@FreeBSD.ORG Mon Apr 9 17:30:08 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C08C1106564A for ; Mon, 9 Apr 2012 17:30:08 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by mx1.freebsd.org (Postfix) with ESMTP id 59F758FC12 for ; Mon, 9 Apr 2012 17:30:08 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1SHIPn-0002jW-D1 for freebsd-net@freebsd.org; Mon, 09 Apr 2012 19:30:07 +0200 Received: from pool-108-35-132-213.nwrknj.fios.verizon.net ([108.35.132.213]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 09 Apr 2012 19:30:07 +0200 Received: from ixew by pool-108-35-132-213.nwrknj.fios.verizon.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 09 Apr 2012 19:30:07 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: enoch Date: Mon, 09 Apr 2012 13:29:55 -0400 Lines: 165 Message-ID: <87fwccq0do.fsf@hotmail.com> References: <20120403023225.GD3571@michelle.cdnetworks.com> <87ty11670b.fsf@hotmail.com> <20120403183521.GA7380@michelle.cdnetworks.com> <87obr95pxh.fsf@hotmail.com> <20120403225422.GB7380@michelle.cdnetworks.com> <87sjgk5czo.fsf@hotmail.com> <20120404210445.GB10911@michelle.cdnetworks.com> <87vclfwqp4.fsf@hotmail.com> <20120405161152.GA14289@michelle.cdnetworks.com> <87iphejaar.fsf@hotmail.com> <20120409183704.GA1668@michelle.cdnetworks.com> Mime-Version: 1.0 Content-Type: text/plain X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: pool-108-35-132-213.nwrknj.fios.verizon.net User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.93 (berkeley-unix) Cancel-Lock: sha1:RFmijkcXZXW1EUTrbM9PYPjpMU0= Subject: Re: [nfe] DHCP failure on 8-stable X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 17:30:08 -0000 YongHyeon PYUN writes: > On Thu, Apr 05, 2012 at 02:36:12PM -0400, enoch wrote: >> YongHyeon PYUN writes: >> >> > On Wed, Apr 04, 2012 at 09:51:19AM -0400, enoch wrote: >> >> YongHyeon PYUN writes: >> >> >> >> > On Wed, Apr 04, 2012 at 12:37:15AM -0400, enoch wrote: >> >> >> YongHyeon PYUN writes: >> >> >> >> >> >> > On Tue, Apr 03, 2012 at 01:45:30AM -0400, enoch wrote: >> >> >> >> YongHyeon PYUN writes: >> >> >> >> >> >> >> >> > On Mon, Apr 02, 2012 at 07:36:36PM -0400, enoch wrote: >> >> >> >> >> YongHyeon PYUN writes: >> >> >> >> >> >> >> >> >> >> > On Mon, Apr 02, 2012 at 03:50:02AM -0400, enoch wrote: >> >> >> >> >> >> On 04/02/2012 03:52 PM, YongHyeon PYUN wrote: >> >> >> >> >> >> > On Fri, Mar 30, 2012 at 10:40:44AM -0400, enoch wrote: >> >> >> >> >> >> >> On 03/30/2012 19:38, YongHyeon PYUN wrote: >> >> >> >> >> >> >>> On Fri, Mar 30, 2012 at 03:01:52AM -0400, enoch wrote: >> >> >> >> >> >> >>>> Recently it became extremely difficult to pass the DHCP discovery step >> >> >> >> >> >> >>>> on boot. Now I am using the buggy [nve] instead. >> >> >> >> >> >> >>>> >> >> >> >> >> >> >>>> Can anyone help? >> >> >> >> >> >> >>>> >> >> >> >> >> >> >>> >> >> >> >> >> >> >>> Did you set synchronous_dhclient option in rc.conf? >> >> >> >> >> >> >>> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Yes: ifconfig_nfe0="SYNCDHCP" >> >> >> >> >> >> >> >> >> >> >> >> >> >> I guess [nfe] is undergoing gradual devel changes of some sort as before >> >> >> >> >> >> >> it had some chance of reporting "empty headers" on initial ifconfig and >> >> >> >> >> >> >> refusing to work. Sorry, I should have reported when encountering the >> >> >> >> >> >> >> first problems rather than solve by reboot. >> >> >> >> >> >> > >> >> >> >> >> >> > Would you show me the output of both dmesg(nfe(4) and its PHY only) >> >> >> >> >> >> > and 'sysctl dev.nfe.0.stats'? >> >> >> >> >> >> > It would be also helpful to know whether nfe(4) still sees >> >> >> >> >> >> > incoming traffic. >> >> >> >> >> >> > Does assigning static IP work? >> >> >> >> >> >> > >> >> >> >> >> >> >> >> >> >> >> >> Static IP direct communication attempt from this desktop to another >> >> >> >> >> >> laptop through a crossover cable fails as follows. Thanks. >> >> >> >> >> >> >> >> >> >> >> >> nfe0: flags=8843 metric 0 mtu 1500 >> >> >> >> >> >> options=82008 >> >> >> >> >> >> ether 00:1f:bc:00:19:dc >> >> >> >> >> >> inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255 >> >> >> >> >> >> media: Ethernet autoselect (1000baseT >> >> >> >> >> >> ) >> >> >> >> >> >> status: active >> >> >> >> >> >> >> >> >> >> >> >> nfe0: link state changed to UP >> >> >> >> >> >> nfe0: port 0xf200-0xf207 >> >> >> >> >> >> mem 0xefffb000-0xefffbfff irq 21 at device 20.0 on pci0 >> >> >> >> >> >> miibus1: on nfe0 >> >> >> >> >> > >> >> >> >> >> > It seems you've omitted PHY driver here. What PHY driver was >> >> >> >> >> > attached to nfe(4)? >> >> >> >> >> > >> >> >> >> >> >> >> >> >> >> miibus1: on nfe0 >> >> >> >> >> rgephy1: PHY 1 on miibus1 >> >> >> >> >> >> >> >> >> >> >> nfe0: Ethernet address: 00:1f:bc:00:19:dc >> >> >> >> >> >> nfe0: [FILTER] >> >> >> >> >> >> nfe0: discard frame w/o leading ethernet header (len 0 pkt len 0) >> >> >> >> >> >> nfe0: discard frame w/o leading ethernet header (len 0 pkt len 0) >> >> >> >> >> >> nfe0: link state changed to UP >> >> >> >> >> >> nfe0: discard frame w/o leading ethernet header (len 0 pkt len 0) >> >> >> >> >> >> nfe0: discard frame w/o leading ethernet header (len 0 pkt len 0) >> >> >> >> >> >> nfe0: discard frame w/o leading ethernet header (len 0 pkt len 0) >> >> >> >> >> >> >> >> >> >> >> >> dev.nfe.0.stats.rx.frame_errors: 0 >> >> >> >> >> >> dev.nfe.0.stats.rx.extra_bytes: 0 >> >> >> >> >> >> dev.nfe.0.stats.rx.late_cols: 0 >> >> >> >> >> >> dev.nfe.0.stats.rx.runts: 0 >> >> >> >> >> >> dev.nfe.0.stats.rx.jumbos: 0 >> >> >> >> >> >> dev.nfe.0.stats.rx.fifo_overuns: 0 >> >> >> >> >> >> dev.nfe.0.stats.rx.crc_errors: 0 >> >> >> >> >> >> dev.nfe.0.stats.rx.fae: 0 >> >> >> >> >> >> dev.nfe.0.stats.rx.len_errors: 0 >> >> >> >> >> >> dev.nfe.0.stats.rx.unicast: 56 >> >> >> >> >> >> dev.nfe.0.stats.rx.multicast: 0 >> >> >> >> >> >> dev.nfe.0.stats.rx.broadcast: 280 >> >> >> >> >> >> dev.nfe.0.stats.tx.octets: 7517 >> >> >> >> >> >> dev.nfe.0.stats.tx.zero_rexmits: 51 >> >> >> >> >> >> dev.nfe.0.stats.tx.one_rexmits: 0 >> >> >> >> >> >> dev.nfe.0.stats.tx.multi_rexmits: 0 >> >> >> >> >> >> dev.nfe.0.stats.tx.late_cols: 0 >> >> >> >> >> >> dev.nfe.0.stats.tx.fifo_underuns: 0 >> >> >> >> >> >> dev.nfe.0.stats.tx.carrier_losts: 0 >> >> >> >> >> >> dev.nfe.0.stats.tx.excess_deferrals: 0 >> >> >> >> >> >> dev.nfe.0.stats.tx.retry_errors: 0 >> >> >> >> >> >> >> >> >> >> >> > >> >> >> >> >> > Thanks. Would you show me the output of "pciconf -lcbv"? >> >> >> >> >> > >> >> >> >> >> >> >> >> >> >> nfe0@pci0:0:20:0: class=0x068000 card=0x10003842 chip=0x026910de rev=0xa3 hdr=0x00 >> >> >> >> >> vendor = 'NVIDIA Corporation' >> >> >> >> >> device = 'MCP51 Network Bus Enumerator' >> >> >> >> >> class = bridge >> >> >> >> >> bar [10] = type Memory, range 32, base 0xefffb000, size 4096, enabled >> >> >> >> >> bar [14] = type I/O Port, range 32, base 0xf200, size 8, enabled >> >> >> >> >> cap 01[44] = powerspec 2 supports D0 D1 D2 D3 current D0 >> >> >> >> >> >> >> >> >> >> Interestingly, now that nfe0 is using a static IP it sometimes boots >> >> >> >> >> up properly. Are you interested in its good working? >> >> >> >> > >> >> >> >> > Yes I am. Would you try attached patch and let me know whether the >> >> >> >> > patch makes any difference on your box? >> >> >> >> >> >> >> >> Sorry to report: The patch was applied (to 8-stable latest code) but out >> >> >> >> of 3 boots only one succeeded. Same stream of "nfe0: discard frame w/o >> >> >> >> leading ethernet header (len 0 pkt len 0)" messages. >> >> >> > >> >> >> > Ok, back out previous patch and try attached one. >> >> >> >> >> >> With these two patch files applied to the 8-stable code, buildkernel >> >> >> fails as follows. >> >> >> >> >> >> /usr/src/sys/modules/nfe/../../dev/nfe/if_nfe.c: In function 'nfe_attach': >> >> >> /usr/src/sys/modules/nfe/../../dev/nfe/if_nfe.c:629: error: 'struct mii_softc' has no member named 'mii_mpd_oui' >> >> >> /usr/src/sys/modules/nfe/../../dev/nfe/if_nfe.c:629: error: 'struct mii_softc' has no member named 'mii_mpd_oui' >> >> >> /usr/src/sys/modules/nfe/../../dev/nfe/if_nfe.c:630: error: 'struct mii_softc' has no member named 'mii_mpd_model' >> >> >> *** Error code 1 >> >> >> >> >> > >> >> > Oops, sorry I forgot that this part of change was not merged to >> >> > stable/8. I've attached a minimal patch which would be cleanly >> >> > applied to stable/8. >> >> >> >> Wasn't the attached diff3 already included in diff2? Seems to me the >> >> wrong file was attached this time. Please advise. >> > >> > diff2 is subset of diff3 but it can be merged to stable/8 and >> > stable/7. Probably diff2 may have better chance to fully >> > reinitialize PHY but let's see whether diff3 also makes difference >> > on your box. >> > So back out any changes and apply diff3. >> >> I'm sorry, this if_nfereg.h patch is not enough. Boot failure frequency >> is just the same. I guess I should consider migrating to 9-stable. The >> problem with 9-stable is that most of the time it does not build :-( >> >> Thanks for your efforts. Enoch. > > Here is updated patch for stable/8. Let me know whether it makes > any difference. Sorry, the diff4 patch compiled but made no difference (using static IP). On first boot the "w/o leading ethernet header" problem showed up. Can you generate diagnostic messages that I can collect for you from dmesg or messages? > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Mon Apr 9 18:37:02 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 91C9B106564A; Mon, 9 Apr 2012 18:37:02 +0000 (UTC) (envelope-from kes-kes@yandex.ru) Received: from forward16.mail.yandex.net (forward16.mail.yandex.net [IPv6:2a02:6b8:0:1402::1]) by mx1.freebsd.org (Postfix) with ESMTP id 047EE8FC15; Mon, 9 Apr 2012 18:37:02 +0000 (UTC) Received: from smtp16.mail.yandex.net (smtp16.mail.yandex.net [95.108.252.16]) by forward16.mail.yandex.net (Yandex) with ESMTP id 5ECF6D213C7; Mon, 9 Apr 2012 22:37:00 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1333996620; bh=+4rYyKhgm4de5DZgv44zkx576Wjgfyabaypv5JRtWi4=; h=Date:From:Reply-To:Message-ID:To:Subject:MIME-Version: Content-Type:Content-Transfer-Encoding; b=LzfXq0IDLBxWm2bsTd2bfdSXwxfi2xTatQsVOBGXUu4RxihJ6mHoPaz2rITZ65UaA sxlIXwygkbfymJrQD6I2JjYoFK+uihiJH91cPsjR/+95XuFbWR1tD4rQ4hZALSpq0k uY8oA5om55bxmzKa1F1C4/9oqBx5XQe1RL9WB0eM= Received: from smtp16.mail.yandex.net (localhost [127.0.0.1]) by smtp16.mail.yandex.net (Yandex) with ESMTP id 40A8F6A0020; Mon, 9 Apr 2012 22:37:00 +0400 (MSK) Received: from unknown (unknown [176.8.82.56]) by smtp16.mail.yandex.net (nwsmtp/Yandex) with ESMTP id au3mLaFr-ax3mxtI5; Mon, 9 Apr 2012 22:36:59 +0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1333996620; bh=+4rYyKhgm4de5DZgv44zkx576Wjgfyabaypv5JRtWi4=; h=Date:From:X-Mailer:Reply-To:Organization:X-Priority:Message-ID:To: Subject:MIME-Version:Content-Type:Content-Transfer-Encoding; b=QzWVQBVIhD9sBQXlGyDC3I9k+7Jb7eR4HzMLNbdFlRdaYvAhhBqlNhCL2S0XCyR2f EMwn6VPnQanh5I+ecSL+MdCC97Z7R6EyfEEJNU8pMpAtHpzleFuq5ruQMyYYX1etWc xer+IbyrCiRFUMFVmfUKL88Odd+6osCSCYqn3nd4= Date: Mon, 9 Apr 2012 21:36:54 +0300 From: =?windows-1251?B?yu7t/Oru4iDF4uPl7ejp?= X-Mailer: The Bat! (v4.0.24) Professional Organization: =?windows-1251?B?188gyu7t/Oru4iwgRnJlZUxpbmU=?= X-Priority: 3 (Normal) Message-ID: <61227818.20120409213654@yandex.ru> To: freebsd-questions@freebsd.org, freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: 8bit Cc: Subject: fsck problem FreeBSD 8.3 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: =?windows-1251?B?yu7t/Oru4iDF4uPl7ejp?= List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 18:37:02 -0000 Hi. Apr 9 19:51:58 fsck: /dev/ad8s1e: UNEXPECTED INCONSISTENCY, CANNOT RUN FAST FSCK Apr 9 19:51:58 fsck: Apr 9 19:51:58 fsck: Apr 9 19:51:58 fsck: /dev/ad8s1e: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY. Apr 9 19:51:58 fsck: /dev/ad8s1e: CANNOT SET FS_NEEDSFSCK FLAG Apr 9 20:09:22 kernel: running manually: # fsck -y /dev/ad8s1e ** /dev/ad8s1e (NO WRITE) ** Last Mounted on /tmp ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups 99 files, 10 used, 506477 free (45 frags, 63304 blocks, 0.0% fragmentation) Server reboot two or three time per day # uname -a FreeBSD flux 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #3 r231881: Fri Feb 24 17:07:48 UTC 2012 adm@flux:/usr/obj/usr/src/sys/KES_KERN_v8 amd64 before this it works about month without problems /var/crash - empty, in /var/log/messages there is no any messages before crash. Can any help to fix problem? From owner-freebsd-net@FreeBSD.ORG Mon Apr 9 18:43:58 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 09DCC106566B; Mon, 9 Apr 2012 18:43:58 +0000 (UTC) (envelope-from pprocacci@datapipe.com) Received: from EXFESMQ03.datapipe-corp.net (exfesmq03.datapipe.com [64.27.120.67]) by mx1.freebsd.org (Postfix) with ESMTP id B52148FC14; Mon, 9 Apr 2012 18:43:57 +0000 (UTC) Received: from nat.myhome (192.168.128.103) by EXFESMQ03.datapipe-corp.net (192.168.128.28) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 9 Apr 2012 14:42:48 -0400 Date: Mon, 9 Apr 2012 13:43:08 -0500 From: "Paul A. Procacci" To: ??????? ??????? Message-ID: <20120409184308.GX49374@nat.myhome> References: <61227818.20120409213654@yandex.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <61227818.20120409213654@yandex.ru> User-Agent: Mutt/1.5.21 (2010-09-15) X-Originating-IP: [192.168.128.103] Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, freebsd-questions@freebsd.org Subject: Re: fsck problem FreeBSD 8.3 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 18:43:58 -0000 Nothing logged in /var/log/* or crashes that exist in /var/crash would indi= cate to me some sort of hardware related problem. Have you tested your hardware lately and know that it is in operational ord= er? ~Paul On Mon, Apr 09, 2012 at 09:36:54PM +0300, ??????? ??????? wrote: > Hi. > > Apr 9 19:51:58 fsck: /dev/ad8s1e: UNEXPECTED INCONSISTENCY, CANNOT RUN F= AST FSCK > Apr 9 19:51:58 fsck: > Apr 9 19:51:58 fsck: > Apr 9 19:51:58 fsck: /dev/ad8s1e: UNEXPECTED INCONSISTENCY; RUN fsck MAN= UALLY. > Apr 9 19:51:58 fsck: /dev/ad8s1e: CANNOT SET FS_NEEDSFSCK FLAG > Apr 9 20:09:22 kernel: > > running manually: > # fsck -y /dev/ad8s1e > ** /dev/ad8s1e (NO WRITE) > ** Last Mounted on /tmp > ** Phase 1 - Check Blocks and Sizes > ** Phase 2 - Check Pathnames > ** Phase 3 - Check Connectivity > ** Phase 4 - Check Reference Counts > ** Phase 5 - Check Cyl groups > 99 files, 10 used, 506477 free (45 frags, 63304 blocks, 0.0% fragmentatio= n) > > > Server reboot two or three time per day > # uname -a > FreeBSD flux 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #3 r231881: Fri Feb 24= 17:07:48 UTC 2012 adm@flux:/usr/obj/usr/src/sys/KES_KERN_v8 amd64 > > before this it works about month without problems > > /var/crash - empty, in /var/log/messages there is no any messages before = crash. > Can any help to fix problem? > > _______________________________________________ > 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" ________________________________ This message may contain confidential or privileged information. If you are= not the intended recipient, please advise us immediately and delete this m= essage. See http://www.datapipe.com/legal/email_disclaimer/ for further inf= ormation on confidentiality and the risks of non-secure electronic communic= ation. If you cannot access these links, please notify us by reply message = and we will send the contents to you. From owner-freebsd-net@FreeBSD.ORG Mon Apr 9 19:02:44 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0FF00106564A; Mon, 9 Apr 2012 19:02:44 +0000 (UTC) (envelope-from kes-kes@yandex.ru) Received: from forward5.mail.yandex.net (forward5.mail.yandex.net [IPv6:2a02:6b8:0:602::5]) by mx1.freebsd.org (Postfix) with ESMTP id 2EF368FC1A; Mon, 9 Apr 2012 19:02:43 +0000 (UTC) Received: from smtp2.mail.yandex.net (smtp2.mail.yandex.net [77.88.46.102]) by forward5.mail.yandex.net (Yandex) with ESMTP id 9C6D71201B62; Mon, 9 Apr 2012 23:02:41 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1333998161; bh=rv/48MjBgWGt8ohUGK+T7JmKfrrmmpGjDercBumoJ+0=; h=Date:From:Reply-To:Message-ID:To:CC:Subject:In-Reply-To: References:MIME-Version:Content-Type:Content-Transfer-Encoding; b=s3Y1M5RBlGW86Zfy4zdLSKZCZgRmLxlqPeBfRys9e3TWvYzCPzZc7azlWoKWp1xrf RLkQlfI7hRo2zgGBHTHf+TYZ0vMVx9Y7PMc50VuDIZFuRZnoD4su93n9JUnYsx7D5M RtPFbdpG+6tSlvjicr+APFp5Y/FkWuxLM/Co65qo= Received: from smtp2.mail.yandex.net (localhost [127.0.0.1]) by smtp2.mail.yandex.net (Yandex) with ESMTP id 7A0AEE20364; Mon, 9 Apr 2012 23:02:41 +0400 (MSK) Received: from unknown (unknown [176.8.82.56]) by smtp2.mail.yandex.net (nwsmtp/Yandex) with ESMTP id 2baqWfUQ-2eaSI9kb; Mon, 9 Apr 2012 23:02:40 +0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1333998161; bh=rv/48MjBgWGt8ohUGK+T7JmKfrrmmpGjDercBumoJ+0=; h=Date:From:X-Mailer:Reply-To:Organization:X-Priority:Message-ID:To: CC:Subject:In-Reply-To:References:MIME-Version:Content-Type: Content-Transfer-Encoding; b=j7Lo7K9izRkaNhYmkbi7UgIJSol4JICoXx8qUlwJm/EDHcY6c9EX78rd+GCYkuHTR moHtqq6VzdSGdZ/ki6yrz4qLXo7ZDRYalhLurTaWvVlPTvcl7GaKcoctamymSrwIUG OMBvqo24UfKlgrVLr9gC+AL8mvoMagW9wS+jVdHc= Date: Mon, 9 Apr 2012 22:02:36 +0300 From: =?windows-1251?B?yu7t/Oru4iDF4uPl7ejp?= X-Mailer: The Bat! (v4.0.24) Professional Organization: =?windows-1251?B?188gyu7t/Oru4iwgRnJlZUxpbmU=?= X-Priority: 3 (Normal) Message-ID: <544633848.20120409220236@yandex.ru> To: "Paul A. Procacci" In-Reply-To: <20120409184308.GX49374@nat.myhome> References: <61227818.20120409213654@yandex.ru> <20120409184308.GX49374@nat.myhome> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org, freebsd-questions@freebsd.org Subject: Re[2]: fsck problem FreeBSD 8.3 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: =?windows-1251?B?yu7t/Oru4iDF4uPl7ejp?= List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 19:02:44 -0000 Yes, I have tested. and on this hardware on this OS it works from Fri Feb 24 17:07:48 UTC 2012 but last two days: reboot ~ Mon Apr 9 19:50 reboot ~ Mon Apr 9 18:30 reboot ~ Sun Apr 8 20:55 reboot ~ Sun Apr 8 20:00 reboot ~ Sun Apr 8 19:49 reboot ~ Sun Apr 8 17:43 reboot ~ Sun Apr 8 10:58 reboot ~ Sat Apr 7 21:13 reboot ~ Sat Apr 7 16:37 reboot ~ Sat Apr 7 16:07 I remembered. One thing changed. I add vlans to igb2, but no traffic flow on that devices yet. Before this I have use: igb0, igb1, igb3 igb0@pci0:1:0:0: class=0x020000 card=0x00018086 chip=0x15218086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' class = network subclass = ethernet igb1@pci0:1:0:1: class=0x020000 card=0x00018086 chip=0x15218086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' class = network subclass = ethernet igb2@pci0:1:0:2: class=0x020000 card=0x00018086 chip=0x15218086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' class = network subclass = ethernet igb3@pci0:1:0:3: class=0x020000 card=0x00018086 chip=0x15218086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' class = network subclass = ethernet ifconfig_vlan100="inet 192.168.0.1 netmask 255.255.255.0 vlan 100 vlandev igb2" #nALL ifconfig_vlan101="inet 192.168.1.1 netmask 255.255.255.0 vlan 101 vlandev igb2" #n2 p24 ifconfig_vlan102="inet 192.168.2.1 netmask 255.255.255.0 vlan 102 vlandev igb2" #n1 p23 ifconfig_vlan103="inet 192.168.3.1 netmask 255.255.255.0 vlan 103 vlandev igb2" #n3 p22 ifconfig_vlan104="inet 192.168.4.1 netmask 255.255.255.0 vlan 104 vlandev igb2" #n7,9 p21 ifconfig_vlan105="inet 192.168.5.1 netmask 255.255.255.0 vlan 105 vlandev igb2" #n11 p20 ifconfig_vlan106="inet 192.168.6.1 netmask 255.255.255.0 vlan 106 vlandev igb2" #n13 p19 ifconfig_vlan107="inet 192.168.7.1 netmask 255.255.255.0 vlan 107 vlandev igb2" #n223 p18 ifconfig_vlan108="inet 192.168.8.1 netmask 255.255.255.0 vlan 108 vlandev igb2" #n225 p17 ifconfig_vlan109="inet 192.168.9.1 netmask 255.255.255.0 vlan 109 vlandev igb2" #n221 p16 ifconfig_vlan110="inet 192.168.10.1 netmask 255.255.255.0 vlan 110 vlandev igb2" #n229 p15 ifconfig_vlan111="inet 192.168.11.1 netmask 255.255.255.0 vlan 111 vlandev igb2" #n233 p14 ifconfig_vlan112="inet 192.168.12.1 netmask 255.255.255.0 vlan 112 vlandev igb2" #n231 p13 ifconfig_vlan113="inet 192.168.13.1 netmask 255.255.255.0 vlan 113 vlandev igb2" #n237 p12 ifconfig_vlan114="inet 192.168.14.1 netmask 255.255.255.0 vlan 114 vlandev igb2" #n424 p11 ifconfig_vlan115="inet 192.168.15.1 netmask 255.255.255.0 vlan 115 vlandev igb2" # PAP> Nothing logged in /var/log/* or crashes that exist in /var/crash PAP> would indicate to me some sort of hardware related problem. PAP> Have you tested your hardware lately and know that it is in operational order? PAP> ~Paul PAP> On Mon, Apr 09, 2012 at 09:36:54PM +0300, ??????? ??????? wrote: >> Hi. >> >> Apr 9 19:51:58 fsck: /dev/ad8s1e: UNEXPECTED INCONSISTENCY, CANNOT RUN FAST FSCK >> Apr 9 19:51:58 fsck: >> Apr 9 19:51:58 fsck: >> Apr 9 19:51:58 fsck: /dev/ad8s1e: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY. >> Apr 9 19:51:58 fsck: /dev/ad8s1e: CANNOT SET FS_NEEDSFSCK FLAG >> Apr 9 20:09:22 kernel: >> >> running manually: >> # fsck -y /dev/ad8s1e >> ** /dev/ad8s1e (NO WRITE) >> ** Last Mounted on /tmp >> ** Phase 1 - Check Blocks and Sizes >> ** Phase 2 - Check Pathnames >> ** Phase 3 - Check Connectivity >> ** Phase 4 - Check Reference Counts >> ** Phase 5 - Check Cyl groups >> 99 files, 10 used, 506477 free (45 frags, 63304 blocks, 0.0% fragmentation) >> >> >> Server reboot two or three time per day >> # uname -a >> FreeBSD flux 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #3 r231881: Fri Feb 24 17:07:48 UTC 2012 adm@flux:/usr/obj/usr/src/sys/KES_KERN_v8 amd64 >> >> before this it works about month without problems >> >> /var/crash - empty, in /var/log/messages there is no any messages before crash. >> Can any help to fix problem? -- Ñ óâàæåíèåì, Êîíüêîâ mailto:kes-kes@yandex.ru From owner-freebsd-net@FreeBSD.ORG Mon Apr 9 19:34:00 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F3677106564A for ; Mon, 9 Apr 2012 19:34:00 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id D4AD78FC08 for ; Mon, 9 Apr 2012 19:34:00 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SHKLf-000Cgp-Kl; Mon, 09 Apr 2012 19:33:59 +0000 Date: Tue, 10 Apr 2012 04:33:58 +0900 Message-ID: From: Randy Bush To: Luigi Rizzo In-Reply-To: <20120409125922.GA38663@onelab2.iet.unipi.it> References: <20120409125922.GA38663@onelab2.iet.unipi.it> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: FreeBSD Net Subject: Re: dummynet dummy 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, 09 Apr 2012 19:34:01 -0000 >> dum0# ipfw 900 pipe 1 config queue 20 delay 10ms > remove the '900' > ipfw pipe 1 config queue 20 delay 10ms thanks! but ... sure, it's not really part of the programmitic sequence. but one can not see it's there! randy dum0# ipfw show 00100 0 0 deny log ip from any to any ipoptions ssrr,lsrr,rr 00200 0 0 allow ip from any to any via lo0 00300 0 0 deny log ip from 127.0.0.0/8 to any 00400 0 0 deny log ip from any to 127.0.0.0/8 00500 0 0 allow tcp from me to any dst-port 25 00600 0 0 deny tcp from any to any dst-port 25 00700 8 8494 pipe 1 tcp from 147.28.2.129 to 147.28.2.133 00800 12 6390 pipe 2 tcp from 147.28.2.133 to 147.28.2.129 65530 16 1392 allow ip from any to any 65535 5 376 deny ip from any to any From owner-freebsd-net@FreeBSD.ORG Mon Apr 9 19:40:19 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2F1AF106564A for ; Mon, 9 Apr 2012 19:40:19 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from nk11p00mm-asmtp007.mac.com (nk11p00mm-asmtp007.mac.com [17.158.161.6]) by mx1.freebsd.org (Postfix) with ESMTP id 1244F8FC0A for ; Mon, 9 Apr 2012 19:40:19 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from cswiger1.apple.com (unknown [17.209.4.71]) by nk11p00mm-asmtp007.mac.com (Oracle Communications Messaging Server 7u4-23.01(7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPSA id <0M28008Q29B0WD40@nk11p00mm-asmtp007.mac.com> for net@freebsd.org; Mon, 09 Apr 2012 19:40:13 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.6.7498,1.0.260,0.0.0000 definitions=2012-04-09_03:2012-04-09, 2012-04-09, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1204090225 From: Chuck Swiger In-reply-to: Date: Mon, 09 Apr 2012 12:40:12 -0700 Message-id: <3E121686-49C9-4F64-94B6-E628912BAFBA@mac.com> References: <20120409125922.GA38663@onelab2.iet.unipi.it> To: Randy Bush X-Mailer: Apple Mail (2.1084) Cc: Luigi Rizzo , FreeBSD Net Subject: Re: dummynet dummy 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, 09 Apr 2012 19:40:19 -0000 On Apr 9, 2012, at 12:33 PM, Randy Bush wrote: >> dum0# ipfw 900 pipe 1 config queue 20 delay 10ms >> remove the '900' >> ipfw pipe 1 config queue 20 delay 10ms > > thanks! but ... > > sure, it's not really part of the programmitic sequence. but one can > not see it's there! > > randy > > dum0# ipfw show > 00100 0 0 deny log ip from any to any ipoptions ssrr,lsrr,rr [ ... ] The configuration for a pipe isn't part of ruleset order #'s. Try "ipfw pipe show" instead.... Regards, -- -Chuck From owner-freebsd-net@FreeBSD.ORG Mon Apr 9 19:41:07 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CFA1D106567A for ; Mon, 9 Apr 2012 19:41:07 +0000 (UTC) (envelope-from kudzu@tenebras.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 88ACF8FC16 for ; Mon, 9 Apr 2012 19:41:07 +0000 (UTC) Received: by yhgm50 with SMTP id m50so2446922yhg.13 for ; Mon, 09 Apr 2012 12:41:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=M7QGHvP6DAy9fjtI1RQihnlTgziqrnhQc5oSAPt51Yc=; b=lTfmv3/XHyP3795r+H1QNTty8rkcX7p+ySRo+gUOSZ3LKSrMTRPOzBhCfxAT6aHWf/ Y53uun/Xb4j2RjsiJe7uMSp9/l0I8oX1tByXZSABO6yJvQ3PH0cEGG5oXePuwbwzZfPI BxQ5Q6NXBJNYaPIW1NsREWfGBpQWPESopQbfCxwEUjmXPCga8DZiInvl4txfhyvum29P mEGOXl5F+UFUF7izCM6MGF+/W3tZfsYBcifDOkma+xhLbfUeoms1OHK89dWCzsT36MBd dKgYeB9vaio6sSgPOV7C+h6UWevYgsqWLnbdF5QoFjT+djVuBaIH7UO5WOefTKYUrUfR KQZg== MIME-Version: 1.0 Received: by 10.236.72.133 with SMTP id t5mr6966903yhd.94.1334000467056; Mon, 09 Apr 2012 12:41:07 -0700 (PDT) Received: by 10.236.176.36 with HTTP; Mon, 9 Apr 2012 12:41:07 -0700 (PDT) In-Reply-To: References: <20120409125922.GA38663@onelab2.iet.unipi.it> Date: Mon, 9 Apr 2012 12:41:07 -0700 Message-ID: From: Michael Sierchio To: Randy Bush X-Gm-Message-State: ALoCoQlT4FJib89c+kBaRpxlYnFE9OVgCUoEg38NOEQPKOtHa1arMICq4D8350sqJnHJO3gFgypE Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Luigi Rizzo , FreeBSD Net Subject: Re: dummynet dummy 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, 09 Apr 2012 19:41:07 -0000 ipfw show (or list) shows rules and their state ipfw pipe show or ipfw queue show yields interesting results. - M From owner-freebsd-net@FreeBSD.ORG Mon Apr 9 21:39:56 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6CCF91065673; Mon, 9 Apr 2012 21:39:56 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13::5]) by mx1.freebsd.org (Postfix) with ESMTP id C843E8FC08; Mon, 9 Apr 2012 21:39:55 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.5/8.14.5) with ESMTP id q39LdqTE069396; Tue, 10 Apr 2012 04:39:52 +0700 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <4F835728.5030809@rdtc.ru> Date: Tue, 10 Apr 2012 04:39:52 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.2.13) Gecko/20110112 Thunderbird/3.1.7 MIME-Version: 1.0 To: =?KOI8-R?Q?=EB=CF=CE=D8=CB=CF=D7_=E5=D7=C7=C5=CE=C9=CA?= References: <61227818.20120409213654@yandex.ru> In-Reply-To: <61227818.20120409213654@yandex.ru> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org, freebsd-questions@freebsd.org Subject: Re: fsck problem FreeBSD 8.3 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 21:39:56 -0000 10.04.2012 01:36, ëÏÎØËÏ× å×ÇÅÎÉÊ ÐÉÛÅÔ: > Hi. > > Apr 9 19:51:58 fsck: /dev/ad8s1e: UNEXPECTED INCONSISTENCY, CANNOT RUN FAST FSCK > Apr 9 19:51:58 fsck: > Apr 9 19:51:58 fsck: > Apr 9 19:51:58 fsck: /dev/ad8s1e: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY. > Apr 9 19:51:58 fsck: /dev/ad8s1e: CANNOT SET FS_NEEDSFSCK FLAG > Apr 9 20:09:22 kernel: > > running manually: > # fsck -y /dev/ad8s1e > ** /dev/ad8s1e (NO WRITE) You cannot run fsck on mounted filesystem, unmount it first. From owner-freebsd-net@FreeBSD.ORG Mon Apr 9 21:46:19 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 986D21065670 for ; Mon, 9 Apr 2012 21:46:19 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from plsvl-mailgw-01.bluecoat.com (plsvl-mailgw-01.bluecoat.com [199.91.133.11]) by mx1.freebsd.org (Postfix) with ESMTP id 75EDB8FC12 for ; Mon, 9 Apr 2012 21:46:19 +0000 (UTC) Received: from PWSVL-EXCHTS-02.internal.cacheflow.com (unknown [10.2.2.126]) by plsvl-mailgw-01.bluecoat.com (Postfix) with ESMTP id 2F24A81A0D5; Mon, 9 Apr 2012 13:47:36 -0700 (PDT) Received: from pwsvl-excmbx-05.internal.cacheflow.com ([fe80::f848:d461:9aa9:59a8]) by PWSVL-EXCHTS-02.internal.cacheflow.com ([fe80::4910:317f:407:6ecc%14]) with mapi id 14.01.0289.001; Mon, 9 Apr 2012 14:46:18 -0700 From: "Li, Qing" To: Ryan Stone Thread-Topic: Removing an IPv6 address does not remove NDP entries on that subnet Thread-Index: AQHNDnkgJRkO9YzfY0abvrST7SLcoJaH0pmQgAtDFAA= Date: Mon, 9 Apr 2012 21:46:18 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [199.91.133.85] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: freebsd-net Subject: RE: Removing an IPv6 address does not remove NDP entries on that subnet 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, 09 Apr 2012 21:46:19 -0000 WRT the IF_AFDATA_LOCK() race condition you mentioned, I re-run the tests=20 that I used when I developed that code, but I haven't run into any issues,= =20 but that doesn't mean there isn't a bug. Could you please share with me a call path that you believe is=20 problematic, or a simple test case that uncovers the issue ? --Qing =20 > -----Original Message----- > From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd- > net@freebsd.org] On Behalf Of Li, Qing > Sent: Monday, April 02, 2012 10:54 AM > To: Ryan Stone > Cc: freebsd-net > Subject: RE: Removing an IPv6 address does not remove NDP entries on > that subnet >=20 > > > > On Fri, Mar 30, 2012 at 12:28 AM, Li, Qing > wrote: > > >> * In a way this is a good thing as in6_lltable_prefix_free() is > > >> guaranteed to crash your kernel in two different ways, and that's > > not > > >> counting the race conditions that it's subject to. > > >> > > > > > > =A0 =A0 =A0 =A0Could you please elaborate with some details on the tw= o > > different > > > =A0 =A0 =A0 =A0ways in6_lltable_prefix_free() crashes the kernel > > definitively ? > > > > First, it calls callout_drain on lle->le_timer, but that is never > > initialized for a v6 llentry. Second, it never stops the ln_timer_ch > > callout before it frees the llentry. Third, it modifies the lltable > > without holding IF_AFDATA_LOCK(in.c has the third problem: see the > > -net discussion about kern/165863). >=20 >=20 > 1. The reference to &lle->la_timer instead of ln_timer_ch is fine > because lle_timer is defined as a union. >=20 > 2. The manpage of "callout_drain()" reads >=20 > "The function callout_drain() is identical to callout_stop() except > that it will wait for the callout to be completed if it is already > in progress." >=20 > 3. wrt IF_AFDATA_LOCK() I will check again. >=20 > --Qing >=20 >=20 > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Mon Apr 9 22:28:01 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BCEF6106564A for ; Mon, 9 Apr 2012 22:28:01 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id A115C8FC0A for ; Mon, 9 Apr 2012 22:28:01 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SHN43-000D8n-Ab; Mon, 09 Apr 2012 22:27:59 +0000 Date: Tue, 10 Apr 2012 07:27:58 +0900 Message-ID: From: Randy Bush To: Chuck Swiger In-Reply-To: <3E121686-49C9-4F64-94B6-E628912BAFBA@mac.com> References: <20120409125922.GA38663@onelab2.iet.unipi.it> <3E121686-49C9-4F64-94B6-E628912BAFBA@mac.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: Luigi Rizzo , FreeBSD Net Subject: Re: dummynet dummy 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, 09 Apr 2012 22:28:01 -0000 > Try "ipfw pipe show" instead.... thanks! now to figure out what all that means. especially worried about the queue length, as will be using varying delays in an experiment. randy From owner-freebsd-net@FreeBSD.ORG Mon Apr 9 22:58:48 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DB1A1106566B for ; Mon, 9 Apr 2012 22:58:48 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id BE9128FC0A for ; Mon, 9 Apr 2012 22:58:48 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SHNXr-000DDN-PS; Mon, 09 Apr 2012 22:58:48 +0000 Date: Tue, 10 Apr 2012 07:58:46 +0900 Message-ID: From: Randy Bush To: Chuck Swiger In-Reply-To: <06F637C5-E9A5-402B-98FE-B87E7088A5FE@mac.com> References: <20120409125922.GA38663@onelab2.iet.unipi.it> <3E121686-49C9-4F64-94B6-E628912BAFBA@mac.com> <06F637C5-E9A5-402B-98FE-B87E7088A5FE@mac.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: FreeBSD Net Subject: Re: dummynet dummy 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, 09 Apr 2012 22:58:48 -0000 > Well, you should look at your bandwidth-delay product and adjust the > queue size appropriately.... is there a url for that product? :) do they take paypal? :) understand the math. want tool to do it for me. 'cause it ain't just me, it's lab tech(s). randy From owner-freebsd-net@FreeBSD.ORG Mon Apr 9 23:50:14 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 867761065674 for ; Mon, 9 Apr 2012 23:50:14 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 1562E8FC15 for ; Mon, 9 Apr 2012 23:50:13 +0000 (UTC) Received: by wgbds12 with SMTP id ds12so4755269wgb.31 for ; Mon, 09 Apr 2012 16:50:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=uVnF4sNdvD90Kny0Kvq77RBgY5zjGLPXsxQJewAWUWs=; b=0lWXmbkDG/08oB5EJO/ibENU+DGC3v7dgpUryh0F48JEcmMCp1ZevqXlj1LMZFX0IX 6BndsNy3RyV/Z8nEBFim3oOLyfkgo8AdB3hngB4tzYxh8Gj4T37D+JvhpC2f0pIhcS8c sbv7lQNI/xHAdoHeeLvxPr9tMeCDCWmbyoX5SK3hBldQMH0C8zQBhibPAK2ThbK13qOj 64YThQ2ii/W8DZtY0qntEkziaNpn8XKSJLJ+r5ug7RJHDuH39bC99QbVU5Qiso1bkssy Wr9NmNbBrHI03EH4WU2grl/cnBaP62wWRnwcJjpqVy6wOugdzviU9vhYI/LCpJl3/6j7 hV7w== MIME-Version: 1.0 Received: by 10.180.86.132 with SMTP id p4mr1899234wiz.15.1334015413273; Mon, 09 Apr 2012 16:50:13 -0700 (PDT) Received: by 10.180.104.98 with HTTP; Mon, 9 Apr 2012 16:50:13 -0700 (PDT) In-Reply-To: References: Date: Mon, 9 Apr 2012 19:50:13 -0400 Message-ID: From: Ryan Stone To: "Li, Qing" Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net Subject: Re: Removing an IPv6 address does not remove NDP entries on that subnet 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, 09 Apr 2012 23:50:14 -0000 On Mon, Apr 9, 2012 at 5:46 PM, Li, Qing wrote: > Could you please share with me a call path that you believe is > problematic, or a simple test case that uncovers the issue ? I cannot because it is literally impossible for in6_lltable_prefix_free() to ever be called. From owner-freebsd-net@FreeBSD.ORG Mon Apr 9 23:54:18 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 68EB5106564A for ; Mon, 9 Apr 2012 23:54:18 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from nk11p00mm-asmtp006.mac.com (nk11p00mm-asmtp006.mac.com [17.158.161.5]) by mx1.freebsd.org (Postfix) with ESMTP id 49A768FC08 for ; Mon, 9 Apr 2012 23:54:18 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from cswiger1.apple.com (unknown [17.209.4.71]) by nk11p00mm-asmtp006.mac.com (Oracle Communications Messaging Server 7u4-23.01(7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPSA id <0M2800ESCIA3GY40@nk11p00mm-asmtp006.mac.com> for net@freebsd.org; Mon, 09 Apr 2012 22:54:04 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.6.7498,1.0.260,0.0.0000 definitions=2012-04-09_03:2012-04-09, 2012-04-09, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1204090283 From: Chuck Swiger In-reply-to: Date: Mon, 09 Apr 2012 15:54:03 -0700 Message-id: <06F637C5-E9A5-402B-98FE-B87E7088A5FE@mac.com> References: <20120409125922.GA38663@onelab2.iet.unipi.it> <3E121686-49C9-4F64-94B6-E628912BAFBA@mac.com> To: Randy Bush X-Mailer: Apple Mail (2.1084) Cc: Luigi Rizzo , FreeBSD Net Subject: Re: dummynet dummy 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, 09 Apr 2012 23:54:18 -0000 On Apr 9, 2012, at 3:27 PM, Randy Bush wrote: >> Try "ipfw pipe show" instead.... > > thanks! You're most welcome. > now to figure out what all that means. especially worried about the > queue length, as will be using varying delays in an experiment. Well, you should look at your bandwidth-delay product and adjust the queue size appropriately.... Regards, -- -Chuck From owner-freebsd-net@FreeBSD.ORG Tue Apr 10 01:08:51 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AB195106564A for ; Tue, 10 Apr 2012 01:08:51 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from plsvl-mailgw-01.bluecoat.com (plsvl-mailgw-01.bluecoat.com [199.91.133.11]) by mx1.freebsd.org (Postfix) with ESMTP id 87E6D8FC16 for ; Tue, 10 Apr 2012 01:08:51 +0000 (UTC) Received: from PWSVL-EXCHTS-02.internal.cacheflow.com (unknown [10.2.2.126]) by plsvl-mailgw-01.bluecoat.com (Postfix) with ESMTP id 0EF0C81A0E7; Mon, 9 Apr 2012 17:10:08 -0700 (PDT) Received: from pwsvl-excmbx-05.internal.cacheflow.com ([fe80::f848:d461:9aa9:59a8]) by PWSVL-EXCHTS-02.internal.cacheflow.com ([fe80::4910:317f:407:6ecc%14]) with mapi id 14.01.0289.001; Mon, 9 Apr 2012 18:08:50 -0700 From: "Li, Qing" To: Ryan Stone Thread-Topic: Removing an IPv6 address does not remove NDP entries on that subnet Thread-Index: AQHNFquDKnm8fp7HXk2nAeZML12AZpaTPOVs Date: Tue, 10 Apr 2012 01:08:49 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [199.91.133.85] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: freebsd-net Subject: RE: Removing an IPv6 address does not remove NDP entries on that subnet 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, 10 Apr 2012 01:08:51 -0000 I have not followed this thread closely from the beginning, so let me confi= rm.=0A= =0A= Are you reporting multiple bugs: 1) ndp entries remain after the removal of= =0A= an address (according to the thread title), and 2) you believe there is a r= ace condition =0A= around in6_lltable_prefix_free() but if it can never be called, so where is= the race condition=0A= coming from ?=0A= =0A= wrt 1), I cannot reproduce the issue, if it's a problem for you, please pro= vide a description=0A= or just forward me the thread=0A= =0A= wrt 2), let me revisit what was the intention and looks like we use it diff= erently in our=0A= private branch=0A= =0A= --Qing=0A= =0A= ________________________________________=0A= From: Ryan Stone [rysto32@gmail.com]=0A= Sent: Monday, April 09, 2012 4:50 PM=0A= To: Li, Qing=0A= Cc: freebsd-net=0A= Subject: Re: Removing an IPv6 address does not remove NDP entries on that s= ubnet=0A= =0A= On Mon, Apr 9, 2012 at 5:46 PM, Li, Qing wrote:=0A= > Could you please share with me a call path that you believe is=0A= > problematic, or a simple test case that uncovers the issue ?=0A= =0A= I cannot because it is literally impossible for=0A= in6_lltable_prefix_free() to ever be called.=0A= From owner-freebsd-net@FreeBSD.ORG Tue Apr 10 02:02:04 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E2FC21065675 for ; Tue, 10 Apr 2012 02:02:03 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6FC2C8FC1E for ; Tue, 10 Apr 2012 02:02:03 +0000 (UTC) Received: by wern13 with SMTP id n13so3879205wer.13 for ; Mon, 09 Apr 2012 19:02:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=m2cEPrcY85B5lsqj62usVoQR1THSlWP5NhoxZQRXD5A=; b=mLCpvkYIhTMQJ+KDCUFOpKWu0W9NgcU2mRAJzd41jsJY/Y4eI3YfyZ+J9XCrAnfvMy pKqt1f23+ftlPRj1iTyDUa3jp0p9kSTNqbTSEbDaEME0G9L2DweUKERBH0BuJmX6L7T9 XqcR8upMXYFxcWjNJi8yIP8S0ClVc94iVRVdnPZIGlK7FIIfqheaxxnzwO+vThuUOxgP hO8iO+H97xuE/Rr+KXFahj7I2uti0zvg2BbwfjXTwcIoRL/Oj89urovq4V2kcBcEzjzQ qfuHU3bd4X/Hj7J4zKWq/cCKxJrlKt8Sic5xLHmNw2BF3Iw5EktcWLQ9z58SfqnhP2A/ lAxg== MIME-Version: 1.0 Received: by 10.180.78.40 with SMTP id y8mr2617243wiw.15.1334023322313; Mon, 09 Apr 2012 19:02:02 -0700 (PDT) Received: by 10.180.104.98 with HTTP; Mon, 9 Apr 2012 19:02:02 -0700 (PDT) In-Reply-To: References: Date: Mon, 9 Apr 2012 22:02:02 -0400 Message-ID: From: Ryan Stone To: "Li, Qing" Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net Subject: Re: Removing an IPv6 address does not remove NDP entries on that subnet 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, 10 Apr 2012 02:02:04 -0000 On Mon, Apr 9, 2012 at 9:08 PM, Li, Qing wrote: > I have not followed this thread closely from the beginning, so let me confirm. > > Are you reporting multiple bugs: 1) ndp entries remain after the removal of > an address (according to the thread title), and 2) you believe there is a race condition > around in6_lltable_prefix_free() but if it can never be called, so where is the race condition > coming from ? It's all well and good to say that the code can't crash now, but this is a landmine that somebody's going to step on the first time that they try to call this function. > wrt 1), I cannot reproduce the issue, if it's a problem for you, please provide a description > or just forward me the thread [rstone@vm-head ~]ping6 -c 1 1::2 PING6(56=40+8+8 bytes) 1::1 --> 1::2 16 bytes from 1::2, icmp_seq=0 hlim=64 time=0.477 ms --- 1::2 ping6 statistics --- 1 packets transmitted, 1 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 0.477/0.477/0.477/0.000 ms [rstone@vm-head ~]ndp -a Neighbor Linklayer Address Netif Expire S Flags 1::1 08:00:27:fa:87:32 em0 permanent R 1::2 08:00:27:1e:b8:16 em0 25s R fe80::a00:27ff:fefa:8732%em0 08:00:27:fa:87:32 em0 permanent R [rstone@vm-head ~]sudo ifconfig em0 inet6 1::1/64 -alias [rstone@vm-head ~]ndp -a Neighbor Linklayer Address Netif Expire S Flags 1::2 08:00:27:1e:b8:16 em0 7s R fe80::a00:27ff:fefa:8732%em0 08:00:27:fa:87:32 em0 permanent R [rstone@vm-head ~]uname -a FreeBSD vm-head 10.0-CURRENT FreeBSD 10.0-CURRENT #10 r233549:233552M: Wed Mar 28 10:27:20 EDT 2012 rstone@rstone-laptop:/home/rstone/freebsd/obj/usr/home/rstone/freebsd/head/sys/DTRACE amd64 From owner-freebsd-net@FreeBSD.ORG Tue Apr 10 03:51:41 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E755D1065670 for ; Tue, 10 Apr 2012 03:51:41 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id B29B98FC1F for ; Tue, 10 Apr 2012 03:51:41 +0000 (UTC) Received: by pbcwz17 with SMTP id wz17so5849692pbc.13 for ; Mon, 09 Apr 2012 20:51:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=ug4cEiBUJCx0K21l7OtqFp6KJoMD8WQxw4SxcGTfsgY=; b=ROMYoecOxKc8yVYDQXeV68824fEA4M3JHSOvTI1O/vLPzLgALJlV/N+lQ3f10hUPjO tShTmv05XlyQplJANToHgwJdXw8xyPZcH9p0JwuuLJtDB/cpF4E4TuphZBqB7Zlxqnu3 yfc2aw2T5E8rr5sNboVjvWOAYLwg3W8h1Vh8u3wQrffzjHLPfkm91+etK3r0+EYsv5ce baFI0e3OHUQYdsNdp/J+pNltaD4aYMsg4wUmRgRibNhlbCCL5PmFm/u2tG0GiAMj3qyH ndXOPEBb+bsGziQcutAFmzh3BwGJifvop4c8ewm5cXDfBKkevfMaXZReQOIew7I0qTPm XwFA== Received: by 10.68.238.67 with SMTP id vi3mr1111103pbc.30.1334029901168; Mon, 09 Apr 2012 20:51:41 -0700 (PDT) Received: from pyunyh@gmail.com ([114.111.62.249]) by mx.google.com with ESMTPS id ut9sm537502pbc.0.2012.04.09.20.51.37 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 09 Apr 2012 20:51:39 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Tue, 10 Apr 2012 12:51:35 -0700 From: YongHyeon PYUN Date: Tue, 10 Apr 2012 12:51:35 -0700 To: enoch Message-ID: <20120410195135.GA5349@michelle.cdnetworks.com> References: <20120403183521.GA7380@michelle.cdnetworks.com> <87obr95pxh.fsf@hotmail.com> <20120403225422.GB7380@michelle.cdnetworks.com> <87sjgk5czo.fsf@hotmail.com> <20120404210445.GB10911@michelle.cdnetworks.com> <87vclfwqp4.fsf@hotmail.com> <20120405161152.GA14289@michelle.cdnetworks.com> <87iphejaar.fsf@hotmail.com> <20120409183704.GA1668@michelle.cdnetworks.com> <87fwccq0do.fsf@hotmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87fwccq0do.fsf@hotmail.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: [nfe] DHCP failure on 8-stable X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 03:51:42 -0000 On Mon, Apr 09, 2012 at 01:29:55PM -0400, enoch wrote: > YongHyeon PYUN writes: > > > On Thu, Apr 05, 2012 at 02:36:12PM -0400, enoch wrote: > >> YongHyeon PYUN writes: > >> > >> > On Wed, Apr 04, 2012 at 09:51:19AM -0400, enoch wrote: > >> >> YongHyeon PYUN writes: > >> >> > >> >> > On Wed, Apr 04, 2012 at 12:37:15AM -0400, enoch wrote: > >> >> >> YongHyeon PYUN writes: > >> >> >> > >> >> >> > On Tue, Apr 03, 2012 at 01:45:30AM -0400, enoch wrote: > >> >> >> >> YongHyeon PYUN writes: > >> >> >> >> > >> >> >> >> > On Mon, Apr 02, 2012 at 07:36:36PM -0400, enoch wrote: > >> >> >> >> >> YongHyeon PYUN writes: > >> >> >> >> >> > >> >> >> >> >> > On Mon, Apr 02, 2012 at 03:50:02AM -0400, enoch wrote: > >> >> >> >> >> >> On 04/02/2012 03:52 PM, YongHyeon PYUN wrote: > >> >> >> >> >> >> > On Fri, Mar 30, 2012 at 10:40:44AM -0400, enoch wrote: > >> >> >> >> >> >> >> On 03/30/2012 19:38, YongHyeon PYUN wrote: > >> >> >> >> >> >> >>> On Fri, Mar 30, 2012 at 03:01:52AM -0400, enoch wrote: > >> >> >> >> >> >> >>>> Recently it became extremely difficult to pass the DHCP discovery step > >> >> >> >> >> >> >>>> on boot. Now I am using the buggy [nve] instead. > >> >> >> >> >> >> >>>> > >> >> >> >> >> >> >>>> Can anyone help? > >> >> >> >> >> >> >>>> > >> >> >> >> >> >> >>> > >> >> >> >> >> >> >>> Did you set synchronous_dhclient option in rc.conf? > >> >> >> >> >> >> >>> > >> >> >> >> >> >> >> > >> >> >> >> >> >> >> Yes: ifconfig_nfe0="SYNCDHCP" > >> >> >> >> >> >> >> > >> >> >> >> >> >> >> I guess [nfe] is undergoing gradual devel changes of some sort as before > >> >> >> >> >> >> >> it had some chance of reporting "empty headers" on initial ifconfig and > >> >> >> >> >> >> >> refusing to work. Sorry, I should have reported when encountering the > >> >> >> >> >> >> >> first problems rather than solve by reboot. > >> >> >> >> >> >> > > >> >> >> >> >> >> > Would you show me the output of both dmesg(nfe(4) and its PHY only) > >> >> >> >> >> >> > and 'sysctl dev.nfe.0.stats'? > >> >> >> >> >> >> > It would be also helpful to know whether nfe(4) still sees > >> >> >> >> >> >> > incoming traffic. > >> >> >> >> >> >> > Does assigning static IP work? > >> >> >> >> >> >> > > >> >> >> >> >> >> > >> >> >> >> >> >> Static IP direct communication attempt from this desktop to another > >> >> >> >> >> >> laptop through a crossover cable fails as follows. Thanks. > >> >> >> >> >> >> > >> >> >> >> >> >> nfe0: flags=8843 metric 0 mtu 1500 > >> >> >> >> >> >> options=82008 > >> >> >> >> >> >> ether 00:1f:bc:00:19:dc > >> >> >> >> >> >> inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255 > >> >> >> >> >> >> media: Ethernet autoselect (1000baseT > >> >> >> >> >> >> ) > >> >> >> >> >> >> status: active > >> >> >> >> >> >> > >> >> >> >> >> >> nfe0: link state changed to UP > >> >> >> >> >> >> nfe0: port 0xf200-0xf207 > >> >> >> >> >> >> mem 0xefffb000-0xefffbfff irq 21 at device 20.0 on pci0 > >> >> >> >> >> >> miibus1: on nfe0 > >> >> >> >> >> > > >> >> >> >> >> > It seems you've omitted PHY driver here. What PHY driver was > >> >> >> >> >> > attached to nfe(4)? > >> >> >> >> >> > > >> >> >> >> >> > >> >> >> >> >> miibus1: on nfe0 > >> >> >> >> >> rgephy1: PHY 1 on miibus1 > >> >> >> >> >> > >> >> >> >> >> >> nfe0: Ethernet address: 00:1f:bc:00:19:dc > >> >> >> >> >> >> nfe0: [FILTER] > >> >> >> >> >> >> nfe0: discard frame w/o leading ethernet header (len 0 pkt len 0) > >> >> >> >> >> >> nfe0: discard frame w/o leading ethernet header (len 0 pkt len 0) > >> >> >> >> >> >> nfe0: link state changed to UP > >> >> >> >> >> >> nfe0: discard frame w/o leading ethernet header (len 0 pkt len 0) > >> >> >> >> >> >> nfe0: discard frame w/o leading ethernet header (len 0 pkt len 0) > >> >> >> >> >> >> nfe0: discard frame w/o leading ethernet header (len 0 pkt len 0) > >> >> >> >> >> >> > >> >> >> >> >> >> dev.nfe.0.stats.rx.frame_errors: 0 > >> >> >> >> >> >> dev.nfe.0.stats.rx.extra_bytes: 0 > >> >> >> >> >> >> dev.nfe.0.stats.rx.late_cols: 0 > >> >> >> >> >> >> dev.nfe.0.stats.rx.runts: 0 > >> >> >> >> >> >> dev.nfe.0.stats.rx.jumbos: 0 > >> >> >> >> >> >> dev.nfe.0.stats.rx.fifo_overuns: 0 > >> >> >> >> >> >> dev.nfe.0.stats.rx.crc_errors: 0 > >> >> >> >> >> >> dev.nfe.0.stats.rx.fae: 0 > >> >> >> >> >> >> dev.nfe.0.stats.rx.len_errors: 0 > >> >> >> >> >> >> dev.nfe.0.stats.rx.unicast: 56 > >> >> >> >> >> >> dev.nfe.0.stats.rx.multicast: 0 > >> >> >> >> >> >> dev.nfe.0.stats.rx.broadcast: 280 > >> >> >> >> >> >> dev.nfe.0.stats.tx.octets: 7517 > >> >> >> >> >> >> dev.nfe.0.stats.tx.zero_rexmits: 51 > >> >> >> >> >> >> dev.nfe.0.stats.tx.one_rexmits: 0 > >> >> >> >> >> >> dev.nfe.0.stats.tx.multi_rexmits: 0 > >> >> >> >> >> >> dev.nfe.0.stats.tx.late_cols: 0 > >> >> >> >> >> >> dev.nfe.0.stats.tx.fifo_underuns: 0 > >> >> >> >> >> >> dev.nfe.0.stats.tx.carrier_losts: 0 > >> >> >> >> >> >> dev.nfe.0.stats.tx.excess_deferrals: 0 > >> >> >> >> >> >> dev.nfe.0.stats.tx.retry_errors: 0 > >> >> >> >> >> >> > >> >> >> >> >> > > >> >> >> >> >> > Thanks. Would you show me the output of "pciconf -lcbv"? > >> >> >> >> >> > > >> >> >> >> >> > >> >> >> >> >> nfe0@pci0:0:20:0: class=0x068000 card=0x10003842 chip=0x026910de rev=0xa3 hdr=0x00 > >> >> >> >> >> vendor = 'NVIDIA Corporation' > >> >> >> >> >> device = 'MCP51 Network Bus Enumerator' > >> >> >> >> >> class = bridge > >> >> >> >> >> bar [10] = type Memory, range 32, base 0xefffb000, size 4096, enabled > >> >> >> >> >> bar [14] = type I/O Port, range 32, base 0xf200, size 8, enabled > >> >> >> >> >> cap 01[44] = powerspec 2 supports D0 D1 D2 D3 current D0 > >> >> >> >> >> > >> >> >> >> >> Interestingly, now that nfe0 is using a static IP it sometimes boots > >> >> >> >> >> up properly. Are you interested in its good working? > >> >> >> >> > > >> >> >> >> > Yes I am. Would you try attached patch and let me know whether the > >> >> >> >> > patch makes any difference on your box? > >> >> >> >> > >> >> >> >> Sorry to report: The patch was applied (to 8-stable latest code) but out > >> >> >> >> of 3 boots only one succeeded. Same stream of "nfe0: discard frame w/o > >> >> >> >> leading ethernet header (len 0 pkt len 0)" messages. > >> >> >> > > >> >> >> > Ok, back out previous patch and try attached one. > >> >> >> > >> >> >> With these two patch files applied to the 8-stable code, buildkernel > >> >> >> fails as follows. > >> >> >> > >> >> >> /usr/src/sys/modules/nfe/../../dev/nfe/if_nfe.c: In function 'nfe_attach': > >> >> >> /usr/src/sys/modules/nfe/../../dev/nfe/if_nfe.c:629: error: 'struct mii_softc' has no member named 'mii_mpd_oui' > >> >> >> /usr/src/sys/modules/nfe/../../dev/nfe/if_nfe.c:629: error: 'struct mii_softc' has no member named 'mii_mpd_oui' > >> >> >> /usr/src/sys/modules/nfe/../../dev/nfe/if_nfe.c:630: error: 'struct mii_softc' has no member named 'mii_mpd_model' > >> >> >> *** Error code 1 > >> >> >> > >> >> > > >> >> > Oops, sorry I forgot that this part of change was not merged to > >> >> > stable/8. I've attached a minimal patch which would be cleanly > >> >> > applied to stable/8. > >> >> > >> >> Wasn't the attached diff3 already included in diff2? Seems to me the > >> >> wrong file was attached this time. Please advise. > >> > > >> > diff2 is subset of diff3 but it can be merged to stable/8 and > >> > stable/7. Probably diff2 may have better chance to fully > >> > reinitialize PHY but let's see whether diff3 also makes difference > >> > on your box. > >> > So back out any changes and apply diff3. > >> > >> I'm sorry, this if_nfereg.h patch is not enough. Boot failure frequency > >> is just the same. I guess I should consider migrating to 9-stable. The > >> problem with 9-stable is that most of the time it does not build :-( > >> > >> Thanks for your efforts. Enoch. > > > > Here is updated patch for stable/8. Let me know whether it makes > > any difference. > > Sorry, the diff4 patch compiled but made no difference (using static > IP). On first boot the "w/o leading ethernet header" problem showed > up. Can you generate diagnostic messages that I can collect for you from > dmesg or messages? > Due to lack of documentation, I also don't know which registers should I poke at this moment. This reminds me old experimental patch which tried to address reset/DMA issues. Would you try that? Note, I don't have access to nfe(4) so the patch was not tested at all. You can find the patch at the following URL. http://people.freebsd.org/~yongari/nfe/nfe.reset.diff From owner-freebsd-net@FreeBSD.ORG Tue Apr 10 06:54:39 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6FD971065670 for ; Tue, 10 Apr 2012 06:54:39 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id E9E818FC15 for ; Tue, 10 Apr 2012 06:54:38 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id q3A6sWt4034991; Tue, 10 Apr 2012 10:54:32 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id q3A6sWMR034990; Tue, 10 Apr 2012 10:54:32 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Tue, 10 Apr 2012 10:54:32 +0400 From: Gleb Smirnoff To: Ryan Stone Message-ID: <20120410065432.GJ9391@glebius.int.ru> References: <201203090930.q299UCPX057950@freefall.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-net@FreeBSD.org Subject: Re: kern/165863 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, 10 Apr 2012 06:54:39 -0000 Thanks, Ryan! On Thu, Mar 29, 2012 at 05:59:38PM -0400, Ryan Stone wrote: R> Ok, I think that I have an approach that will work. This is heavily R> based off of glebius' proposal. The big difference is that instead of R> initializing the arptimer callout with the ll_entry's lock, I R> initialize it with the if_afdata_lock. This eliminates the LOR R> problem in arptimer. It also nicely prevents any races between R> arptimer and in_lltable_prefix_free. Either arptimer will run and R> ensure that prefix_free can never see an entry that arptimer is in the R> process of destroying, or prefix_free will stop the callout before R> arptimer gets a chance to start. R> R> I'll admit that it feels a bit dirty to be doing anything if the ifp R> at this level, but I'd argue that is an artifact of using a lock in R> the ifp to protect the lltable. R> R> The patch below is not yet complete; it doesn't fix the IPv6 case. R> IPv6 is looking much trickier as when an NDP entry is timed out R> nd6_free() will drop the LLE_WLOCK, acquire the IF_AFDATA_LOCK and R> then re-acquire the LLE_WLOCK. It's not immediately clear to me what R> the best way to handle the race between in6_lltable_prefix_free and R> nd6_llinfo_timer is. Holding the afdata_lock across all of R> nd6_llinfo_timer feels like overkill. R> R> Any comments on this approach? Am I going in the wrong direction? Looks okay from my viewpoint. Have you stress tested it? My snap patch definitely had problems, AFAIR. If this patch fixes panics observed by kern/165863 and passes stress testing, then it should be committed ASAP, and shouldn't depend on IPv6 part. -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Tue Apr 10 20:26:02 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 947D9106566C; Tue, 10 Apr 2012 20:26:02 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 010E68FC1F; Tue, 10 Apr 2012 20:26:01 +0000 (UTC) Received: by wgbds12 with SMTP id ds12so191231wgb.31 for ; Tue, 10 Apr 2012 13:26:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=HchUOF2ktnwsVllqKKeHuNpaieOQVGJ2WyH7LT0kD8o=; b=KzJhEFZk+9MF22ewjaqFp8DZdGEGLl4nTyprh114I/PTvi19o2Zogroix01cllp2ph n5kFoW0m8rPvc01r+NRMbrJ+jU52S8zkKnrXgxItEJnEmOwYNS5Kpd+FNzhkFNWOfs98 PKCI1UDnyTmdjBRGLU1JSHQgmS1h7nPJz1NWhRnMR6ikD1oEWGfSl0lhovOukFr5PR0F /0w9TXTtsXLkZnq+f6PYNPt6qprLv/wlX8aDIGWGvJP0xjmFJzKpk177N1ndHGZOioZV 6KkPh8sPFISUakeONcms5U8lL+p+sCUUVF9BdLUzN+hNjQ7QAlufcnquKrgDtNBy0FaA UHLA== MIME-Version: 1.0 Received: by 10.180.101.8 with SMTP id fc8mr10149896wib.12.1334089561165; Tue, 10 Apr 2012 13:26:01 -0700 (PDT) Received: by 10.180.104.98 with HTTP; Tue, 10 Apr 2012 13:26:01 -0700 (PDT) In-Reply-To: <20120410065432.GJ9391@glebius.int.ru> References: <201203090930.q299UCPX057950@freefall.freebsd.org> <20120410065432.GJ9391@glebius.int.ru> Date: Tue, 10 Apr 2012 16:26:01 -0400 Message-ID: From: Ryan Stone To: Gleb Smirnoff Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: kern/165863 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, 10 Apr 2012 20:26:02 -0000 2012/4/10 Gleb Smirnoff : > =A0Thanks, Ryan! (snip) > Looks okay from my viewpoint. Have you stress tested it? My snap patch > definitely had problems, AFAIR. > > If this patch fixes panics observed by kern/165863 and passes stress > testing, then it should be committed ASAP, and shouldn't depend on > IPv6 part. > > -- > Totus tuus, Glebius. Hm, I was all ready to commit this, but I've realized that there is a problem. According to callout_reset(9), any caller to callout_reset must hold any mutex associated with the callout, but the two places that call callout_reset on the la_timer are not done with the if_afdata_lock held, and changing that looks to be non-trivial without making the if_afdata_lock a huge contention point. At this point I'm not sure what the best way to proceed is. From owner-freebsd-net@FreeBSD.ORG Tue Apr 10 22:33:47 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 15817106566C; Tue, 10 Apr 2012 22:33:47 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id C81E38FC08; Tue, 10 Apr 2012 22:33:45 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 9AF9B7300A; Wed, 11 Apr 2012 00:52:57 +0200 (CEST) Date: Wed, 11 Apr 2012 00:52:57 +0200 From: Luigi Rizzo To: current@freebsd.org, net@freebsd.org Message-ID: <20120410225257.GB53350@onelab2.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: Subject: strange ping response times... 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, 10 Apr 2012 22:33:47 -0000 I noticed this first on a 10G interface, but now there seems to be a similar issue on the loopback. Apparently a ping -f has a much lower RTT than one with non-zero delay between transmissions. Part of the story could be that the flood version invokes a non-blocking select. On the other hand, pinging on the loopback should make the response available right away, so what could be the reason for the additional 3..10us in the ping response time ? The following are numbers on an i7-2600k at 3400 MHz + turboboost, running stable/9 amd64. Note how the min ping time significantly increases moving from flood to 10ms to 1s. On an Intel 10G interface i am seeing a min of 14-16us with a ping flood, and up to 33-35us with the standard 1s interval (using -q probably trims another 2..5us) > sudo ping -c 1000 -q -f 127.0.0.1 round-trip min/avg/max/stddev = 0.002/0.003/0.012/0.001 ms > sudo ping -c 1000 -q -f 127.0.0.1 round-trip min/avg/max/stddev = 0.002/0.002/0.013/0.001 ms > sudo ping -c 1000 -q -f 127.0.0.1 round-trip min/avg/max/stddev = 0.002/0.002/0.013/0.001 ms > sudo ping -c 10000 -q -f 127.0.0.1 round-trip min/avg/max/stddev = 0.002/0.002/0.011/0.001 ms > sudo ping -c 1000 -q -i 0.01 127.0.0.1 round-trip min/avg/max/stddev = 0.005/0.012/0.017/0.001 ms > sudo ping -c 1000 -q -i 0.01 127.0.0.1 round-trip min/avg/max/stddev = 0.004/0.012/0.016/0.001 ms > sudo ping -c 200 -q -i 0.01 127.0.0.1 round-trip min/avg/max/stddev = 0.007/0.012/0.017/0.002 ms > sudo ping -c 200 -q -i 0.01 127.0.0.1 round-trip min/avg/max/stddev = 0.005/0.012/0.018/0.002 ms > sudo ping -c 200 -q -i 0.01 127.0.0.1 round-trip min/avg/max/stddev = 0.009/0.012/0.020/0.002 ms > sudo ping -c 200 -q -i 0.01 127.0.0.1 round-trip min/avg/max/stddev = 0.006/0.012/0.016/0.001 ms > sudo ping -c 200 -q -i 0.1 127.0.0.1 round-trip min/avg/max/stddev = 0.007/0.014/0.020/0.001 ms > sudo ping -c 200 -q -i 0.1 127.0.0.1 round-trip min/avg/max/stddev = 0.006/0.014/0.019/0.002 ms > sudo ping -c 200 -q -i 0.1 127.0.0.1 round-trip min/avg/max/stddev = 0.007/0.014/0.021/0.001 ms > sudo ping -c 200 -q -i 0.1 127.0.0.1 round-trip min/avg/max/stddev = 0.007/0.014/0.020/0.001 ms > sudo ping -c 200 -q -i 0.1 127.0.0.1 round-trip min/avg/max/stddev = 0.006/0.014/0.021/0.002 ms > sudo ping -c 200 -q -i 0.1 127.0.0.1 round-trip min/avg/max/stddev = 0.010/0.014/0.022/0.001 ms > sudo ping -c 20 -q -i 1 127.0.0.1 round-trip min/avg/max/stddev = 0.013/0.018/0.022/0.002 ms > sudo ping -c 20 -q -i 1 127.0.0.1 round-trip min/avg/max/stddev = 0.012/0.018/0.021/0.002 ms > sudo ping -c 20 -q -i 1 127.0.0.1 round-trip min/avg/max/stddev = 0.009/0.017/0.018/0.002 ms > sudo ping -c 20 -q -i 1 127.0.0.1 round-trip min/avg/max/stddev = 0.011/0.017/0.021/0.002 ms > sudo ping -c 20 -q -i 1 127.0.0.1 round-trip min/avg/max/stddev = 0.010/0.017/0.020/0.002 ms > sudo ping -c 20 -q -i 1 127.0.0.1 round-trip min/avg/max/stddev = 0.009/0.017/0.028/0.004 ms cheers luigi From owner-freebsd-net@FreeBSD.ORG Tue Apr 10 22:39:46 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 81B201065674; Tue, 10 Apr 2012 22:39:46 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 5C96C8FC0A; Tue, 10 Apr 2012 22:39:46 +0000 (UTC) Received: from julian-mac.elischer.org (c-67-180-24-15.hsd1.ca.comcast.net [67.180.24.15]) (authenticated bits=0) by vps1.elischer.org (8.14.5/8.14.5) with ESMTP id q3AMdcnO035453 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 10 Apr 2012 15:39:40 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <4F84B6DB.5040904@freebsd.org> Date: Tue, 10 Apr 2012 15:40:27 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.28) Gecko/20120306 Thunderbird/3.1.20 MIME-Version: 1.0 To: Luigi Rizzo References: <20120410225257.GB53350@onelab2.iet.unipi.it> In-Reply-To: <20120410225257.GB53350@onelab2.iet.unipi.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org, net@freebsd.org Subject: Re: strange ping response times... 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, 10 Apr 2012 22:39:46 -0000 On 4/10/12 3:52 PM, Luigi Rizzo wrote: > I noticed this first on a 10G interface, but now there seems > to be a similar issue on the loopback. > > Apparently a ping -f has a much lower RTT than one with non-zero > delay between transmissions. Part of the story could be that > the flood version invokes a non-blocking select. > On the other hand, pinging on the loopback should make > the response available right away, so what could be the reason > for the additional 3..10us in the ping response time ? > > The following are numbers on an i7-2600k at 3400 MHz + turboboost, > running stable/9 amd64. Note how the min ping time significantly > increases moving from flood to 10ms to 1s. > On an Intel 10G interface i am seeing a min of 14-16us with > a ping flood, and up to 33-35us with the standard 1s interval > (using -q probably trims another 2..5us) I'd suggest some ktr points around the loopback path.. > > sudo ping -c 1000 -q -f 127.0.0.1 > round-trip min/avg/max/stddev = 0.002/0.003/0.012/0.001 ms > > sudo ping -c 1000 -q -f 127.0.0.1 > round-trip min/avg/max/stddev = 0.002/0.002/0.013/0.001 ms > > sudo ping -c 1000 -q -f 127.0.0.1 > round-trip min/avg/max/stddev = 0.002/0.002/0.013/0.001 ms > > sudo ping -c 10000 -q -f 127.0.0.1 > round-trip min/avg/max/stddev = 0.002/0.002/0.011/0.001 ms > > > sudo ping -c 1000 -q -i 0.01 127.0.0.1 > round-trip min/avg/max/stddev = 0.005/0.012/0.017/0.001 ms > > sudo ping -c 1000 -q -i 0.01 127.0.0.1 > round-trip min/avg/max/stddev = 0.004/0.012/0.016/0.001 ms > > sudo ping -c 200 -q -i 0.01 127.0.0.1 > round-trip min/avg/max/stddev = 0.007/0.012/0.017/0.002 ms > > sudo ping -c 200 -q -i 0.01 127.0.0.1 > round-trip min/avg/max/stddev = 0.005/0.012/0.018/0.002 ms > > sudo ping -c 200 -q -i 0.01 127.0.0.1 > round-trip min/avg/max/stddev = 0.009/0.012/0.020/0.002 ms > > sudo ping -c 200 -q -i 0.01 127.0.0.1 > round-trip min/avg/max/stddev = 0.006/0.012/0.016/0.001 ms > > > sudo ping -c 200 -q -i 0.1 127.0.0.1 > round-trip min/avg/max/stddev = 0.007/0.014/0.020/0.001 ms > > sudo ping -c 200 -q -i 0.1 127.0.0.1 > round-trip min/avg/max/stddev = 0.006/0.014/0.019/0.002 ms > > sudo ping -c 200 -q -i 0.1 127.0.0.1 > round-trip min/avg/max/stddev = 0.007/0.014/0.021/0.001 ms > > sudo ping -c 200 -q -i 0.1 127.0.0.1 > round-trip min/avg/max/stddev = 0.007/0.014/0.020/0.001 ms > > sudo ping -c 200 -q -i 0.1 127.0.0.1 > round-trip min/avg/max/stddev = 0.006/0.014/0.021/0.002 ms > > sudo ping -c 200 -q -i 0.1 127.0.0.1 > round-trip min/avg/max/stddev = 0.010/0.014/0.022/0.001 ms > > > sudo ping -c 20 -q -i 1 127.0.0.1 > round-trip min/avg/max/stddev = 0.013/0.018/0.022/0.002 ms > > sudo ping -c 20 -q -i 1 127.0.0.1 > round-trip min/avg/max/stddev = 0.012/0.018/0.021/0.002 ms > > sudo ping -c 20 -q -i 1 127.0.0.1 > round-trip min/avg/max/stddev = 0.009/0.017/0.018/0.002 ms > > sudo ping -c 20 -q -i 1 127.0.0.1 > round-trip min/avg/max/stddev = 0.011/0.017/0.021/0.002 ms > > sudo ping -c 20 -q -i 1 127.0.0.1 > round-trip min/avg/max/stddev = 0.010/0.017/0.020/0.002 ms > > sudo ping -c 20 -q -i 1 127.0.0.1 > round-trip min/avg/max/stddev = 0.009/0.017/0.028/0.004 ms > > cheers > luigi > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Tue Apr 10 23:12:53 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B95E71065675; Tue, 10 Apr 2012 23:12:53 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 77EE78FC08; Tue, 10 Apr 2012 23:12:53 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 534117300A; Wed, 11 Apr 2012 01:32:11 +0200 (CEST) Date: Wed, 11 Apr 2012 01:32:11 +0200 From: Luigi Rizzo To: Barney Wolff Message-ID: <20120410233211.GA53829@onelab2.iet.unipi.it> References: <20120410225257.GB53350@onelab2.iet.unipi.it> <4F84B6DB.5040904@freebsd.org> <20120410230500.GA22829@pit.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120410230500.GA22829@pit.databus.com> User-Agent: Mutt/1.4.2.3i Cc: current@freebsd.org, net@freebsd.org Subject: Re: strange ping response times... 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, 10 Apr 2012 23:12:53 -0000 On Tue, Apr 10, 2012 at 07:05:00PM -0400, Barney Wolff wrote: > CPU cache? > Cx states? > powerd? powerd is disabled, and i am going down to C1 at most > sysctl -a | grep cx hw.acpi.cpu.cx_lowest: C1 dev.cpu.0.cx_supported: C1/1 C2/80 C3/104 which shouldn't take so much. Sure, cache matters, but the fact is, icmp processing on loopback should occur inline. unless there is a forced descheduling on a select with timeout > 0 which would explain the extra few microseconds (and makes me worry on how expensive is a scheduling decision...) cheers luigi > On Tue, Apr 10, 2012 at 03:40:27PM -0700, Julian Elischer wrote: > > On 4/10/12 3:52 PM, Luigi Rizzo wrote: > > > I noticed this first on a 10G interface, but now there seems > > > to be a similar issue on the loopback. > > > > > > Apparently a ping -f has a much lower RTT than one with non-zero > > > delay between transmissions. Part of the story could be that > > > the flood version invokes a non-blocking select. > > > On the other hand, pinging on the loopback should make > > > the response available right away, so what could be the reason > > > for the additional 3..10us in the ping response time ? > > > > > > The following are numbers on an i7-2600k at 3400 MHz + turboboost, > > > running stable/9 amd64. Note how the min ping time significantly > > > increases moving from flood to 10ms to 1s. > > > On an Intel 10G interface i am seeing a min of 14-16us with > > > a ping flood, and up to 33-35us with the standard 1s interval > > > (using -q probably trims another 2..5us) > > > > I'd suggest some ktr points around the loopback path.. From owner-freebsd-net@FreeBSD.ORG Tue Apr 10 23:14:27 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DC89B106566C; Tue, 10 Apr 2012 23:14:27 +0000 (UTC) (envelope-from barney@pit.databus.com) Received: from out.smtp-auth.no-ip.com (smtp-auth.no-ip.com [8.23.224.61]) by mx1.freebsd.org (Postfix) with ESMTP id B0DB18FC1A; Tue, 10 Apr 2012 23:14:27 +0000 (UTC) X-No-IP: databus.com@noip-smtp X-No-IP: databus.com@noip-smtp X-No-IP: databus.com@noip-smtp X-No-IP: databus.com@noip-smtp X-Report-Spam-To: abuse@no-ip.com Received: from smtp-auth.no-ip.com (unknown [172.20.20.61]) (Authenticated sender: databus.com@noip-smtp) by smtp-auth.no-ip.com (Postfix) with ESMTPA id D8BC1400AE5; Tue, 10 Apr 2012 16:05:03 -0700 (PDT) Received: from pit.databus.com (localhost [127.0.0.1]) by pit.databus.com (8.14.5/8.14.5) with ESMTP id q3AN50cV032034 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Apr 2012 19:05:01 -0400 (EDT) (envelope-from barney@pit.databus.com) X-DKIM: OpenDKIM Filter v2.4.3 pit.databus.com q3AN50cV032034 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=databus.com; s=20091218; t=1334099101; bh=EPhSfPa8ORbA+mlrPRKHrzJxWo4cwxc1v8Bnulkjs+k=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:In-Reply-To; b=m6O+edhSB2YaEA4sHQAUzjMBcuadBmVtc9gZM6Uo5kxhZ5h/U0UJGFONeEvmuvIhn nhAu/7UNKN5JgZOx2owgnis/WgBPT2REHRu/jGqSmBPhjTxhWthHn3WcSQVmNUkv20 hF5i0WzE3jaG3hmljBTn8MwZglyXtl05D6IilCcc= Received: (from barney@localhost) by pit.databus.com (8.14.5/8.14.5/Submit) id q3AN5028032033; Tue, 10 Apr 2012 19:05:00 -0400 (EDT) (envelope-from barney) Date: Tue, 10 Apr 2012 19:05:00 -0400 From: Barney Wolff To: Julian Elischer Message-ID: <20120410230500.GA22829@pit.databus.com> References: <20120410225257.GB53350@onelab2.iet.unipi.it> <4F84B6DB.5040904@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F84B6DB.5040904@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Luigi Rizzo , current@freebsd.org, net@freebsd.org Subject: Re: strange ping response times... 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, 10 Apr 2012 23:14:28 -0000 CPU cache? Cx states? powerd? On Tue, Apr 10, 2012 at 03:40:27PM -0700, Julian Elischer wrote: > On 4/10/12 3:52 PM, Luigi Rizzo wrote: > > I noticed this first on a 10G interface, but now there seems > > to be a similar issue on the loopback. > > > > Apparently a ping -f has a much lower RTT than one with non-zero > > delay between transmissions. Part of the story could be that > > the flood version invokes a non-blocking select. > > On the other hand, pinging on the loopback should make > > the response available right away, so what could be the reason > > for the additional 3..10us in the ping response time ? > > > > The following are numbers on an i7-2600k at 3400 MHz + turboboost, > > running stable/9 amd64. Note how the min ping time significantly > > increases moving from flood to 10ms to 1s. > > On an Intel 10G interface i am seeing a min of 14-16us with > > a ping flood, and up to 33-35us with the standard 1s interval > > (using -q probably trims another 2..5us) > > I'd suggest some ktr points around the loopback path.. From owner-freebsd-net@FreeBSD.ORG Wed Apr 11 00:42:56 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8879C106564A for ; Wed, 11 Apr 2012 00:42:56 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from plsvl-mailgw-02.bluecoat.com (plsvl-mailgw-02.bluecoat.com [199.91.133.12]) by mx1.freebsd.org (Postfix) with ESMTP id 60F378FC12 for ; Wed, 11 Apr 2012 00:42:56 +0000 (UTC) Received: from PWSVL-EXCHTS-02.internal.cacheflow.com (unknown [10.2.2.126]) by plsvl-mailgw-02.bluecoat.com (Postfix) with ESMTP id B79BB2013A; Tue, 10 Apr 2012 17:19:39 -0700 (PDT) Received: from pwsvl-excmbx-05.internal.cacheflow.com ([fe80::f848:d461:9aa9:59a8]) by PWSVL-EXCHTS-02.internal.cacheflow.com ([fe80::4910:317f:407:6ecc%14]) with mapi id 14.01.0289.001; Tue, 10 Apr 2012 17:42:55 -0700 From: "Li, Qing" To: Ryan Stone Thread-Topic: Removing an IPv6 address does not remove NDP entries on that subnet Thread-Index: AQHNFquDKnm8fp7HXk2nAeZML12AZpaTPOVsgACG8wCAAQVyFg== Date: Wed, 11 Apr 2012 00:42:54 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [199.91.133.85] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: freebsd-net Subject: RE: Removing an IPv6 address does not remove NDP entries on that subnet 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, 11 Apr 2012 00:42:56 -0000 >=0A= > [rstone@vm-head ~]ndp -a=0A= > Neighbor Linklayer Address Netif Expire S= Flags=0A= > 1::2 08:00:27:1e:b8:16 em0 7s R= =0A= > fe80::a00:27ff:fefa:8732%em0 08:00:27:fa:87:32 em0 permanent R= =0A= > rstone@vm-head ~]uname -a=0A= > FreeBSD vm-head 10.0-CURRENT FreeBSD 10.0-CURRENT #10 r233549:233552M:=0A= > Wed Mar 28 10:27:20 EDT 2012=0A= >=0A= =0A= I don't know when this basic functionality was broken. I cannot verify when= the breakage=0A= occurred on the 8.x systems I have because I am traveling at the moment.=0A= =0A= I can take ownership of this bug and get it fixed as soon as I return in 1.= 5 weeks.=0A= =0A= --Qing=0A= From owner-freebsd-net@FreeBSD.ORG Wed Apr 11 04:09:53 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DD27D1065670 for ; Wed, 11 Apr 2012 04:09:53 +0000 (UTC) (envelope-from jhellenthal@dataix.net) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 908008FC24 for ; Wed, 11 Apr 2012 04:09:53 +0000 (UTC) Received: by iahk25 with SMTP id k25so891087iah.13 for ; Tue, 10 Apr 2012 21:09:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to; bh=Zufs5q6xnWQp9SYx7MnO6ReeuRHBjoMxbFQgjJ3URGg=; b=R3+phvJKlWF8d5cDJD3ZyHuJitD942n/1KaY82ASoQLbyZpq13RXJT1uuyTy3MHWpM GpD8qrJzyFgAtCQcuXVGDdWM2WOXgyjar/iyNZzMfwlZxkR9GjUKQJkJ59UvQgeifHyJ 9SPkqUHbTNtPKhy6L8AHX+/RuLv817jTa9Ce8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:x-gm-message-state; bh=Zufs5q6xnWQp9SYx7MnO6ReeuRHBjoMxbFQgjJ3URGg=; b=guPDIld/If+5mBAEM5Qfr3dMapQbGDsFfXOm3pJCxkSdO3y90Oot+HDLsJ3zb7OQKx UvjrPpSppFIoaHVgfPWfA+T89iArTcEL/jjIzn1OPF+eW+Mr7onrfHo2ZwcptDbh488O A70GaqqoL+J7YWxJ9qSHn4uSgQS9d8f7XGVb1QpbwQaZW59KiuoCYLWotqyqEA0mY5gq BQwzzcUC3vJhkixfI4nYLSbtb8eaXMK3VT3sLHKzDa76st6X5iC6NKe8RpOdsdClShrc MJXma023KsK5da+eEClCmDnMM2SycQOylwMqFf4sV3RBHw8QU1x05b4Up+kd34mNlNn3 gtPg== Received: by 10.50.154.169 with SMTP id vp9mr784115igb.53.1334117392759; Tue, 10 Apr 2012 21:09:52 -0700 (PDT) Received: from DataIX.net (adsl-99-181-142-73.dsl.klmzmi.sbcglobal.net. [99.181.142.73]) by mx.google.com with ESMTPS id i6sm4067643igq.3.2012.04.10.21.09.51 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 10 Apr 2012 21:09:52 -0700 (PDT) Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.5/8.14.5) with ESMTP id q3B49oFa026333 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Apr 2012 00:09:50 -0400 (EDT) (envelope-from jhellenthal@DataIX.net) Received: (from jhellenthal@localhost) by DataIX.net (8.14.5/8.14.5/Submit) id q3B49mgM026332; Wed, 11 Apr 2012 00:09:48 -0400 (EDT) (envelope-from jhellenthal@DataIX.net) Date: Wed, 11 Apr 2012 00:09:48 -0400 From: Jason Hellenthal To: Luigi Rizzo Message-ID: <20120411040948.GA24775@DataIX.net> References: <20120410225257.GB53350@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120410225257.GB53350@onelab2.iet.unipi.it> X-Gm-Message-State: ALoCoQm7eiAuONaUpKAjZZdiOLGyewS4CccAz/b8z+VubuTsN0HzGVEaLGjegAS/KIWO1Zn62Smt Cc: current@freebsd.org, net@freebsd.org Subject: Re: strange ping response times... 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, 11 Apr 2012 04:09:53 -0000 On Wed, Apr 11, 2012 at 12:52:57AM +0200, Luigi Rizzo wrote: > I noticed this first on a 10G interface, but now there seems > to be a similar issue on the loopback. > > Apparently a ping -f has a much lower RTT than one with non-zero > delay between transmissions. Part of the story could be that > the flood version invokes a non-blocking select. > On the other hand, pinging on the loopback should make > the response available right away, so what could be the reason > for the additional 3..10us in the ping response time ? > > The following are numbers on an i7-2600k at 3400 MHz + turboboost, > running stable/9 amd64. Note how the min ping time significantly > increases moving from flood to 10ms to 1s. > On an Intel 10G interface i am seeing a min of 14-16us with Sorry but I am having trouble wrapping my head around this as the results below are only for the loopback address 127.0.0.1 that does not travel on the wire at all ? Did you assign this to the 10ge interface ? if so which result is which. ? In order to get any good results on my machine I had to tune the following. net.inet.icmp.reply_from_interface=1 net.inet.icmp.icmplim_output=0 net.inet.icmp.icmplim=0 net.inet.icmp.log_redirect=1 You may have other options if this is greater than stable/8 @ 234095 But yes the results seem skewed to some extent and being loopback I would think there should be a very near zero rx/tx time. > a ping flood, and up to 33-35us with the standard 1s interval > (using -q probably trims another 2..5us) > > > sudo ping -c 1000 -q -f 127.0.0.1 > round-trip min/avg/max/stddev = 0.002/0.003/0.012/0.001 ms > > sudo ping -c 1000 -q -f 127.0.0.1 > round-trip min/avg/max/stddev = 0.002/0.002/0.013/0.001 ms > > sudo ping -c 1000 -q -f 127.0.0.1 > round-trip min/avg/max/stddev = 0.002/0.002/0.013/0.001 ms > > sudo ping -c 10000 -q -f 127.0.0.1 > round-trip min/avg/max/stddev = 0.002/0.002/0.011/0.001 ms > > > sudo ping -c 1000 -q -i 0.01 127.0.0.1 > round-trip min/avg/max/stddev = 0.005/0.012/0.017/0.001 ms > > sudo ping -c 1000 -q -i 0.01 127.0.0.1 > round-trip min/avg/max/stddev = 0.004/0.012/0.016/0.001 ms > > sudo ping -c 200 -q -i 0.01 127.0.0.1 > round-trip min/avg/max/stddev = 0.007/0.012/0.017/0.002 ms > > sudo ping -c 200 -q -i 0.01 127.0.0.1 > round-trip min/avg/max/stddev = 0.005/0.012/0.018/0.002 ms > > sudo ping -c 200 -q -i 0.01 127.0.0.1 > round-trip min/avg/max/stddev = 0.009/0.012/0.020/0.002 ms > > sudo ping -c 200 -q -i 0.01 127.0.0.1 > round-trip min/avg/max/stddev = 0.006/0.012/0.016/0.001 ms > > > sudo ping -c 200 -q -i 0.1 127.0.0.1 > round-trip min/avg/max/stddev = 0.007/0.014/0.020/0.001 ms > > sudo ping -c 200 -q -i 0.1 127.0.0.1 > round-trip min/avg/max/stddev = 0.006/0.014/0.019/0.002 ms > > sudo ping -c 200 -q -i 0.1 127.0.0.1 > round-trip min/avg/max/stddev = 0.007/0.014/0.021/0.001 ms > > sudo ping -c 200 -q -i 0.1 127.0.0.1 > round-trip min/avg/max/stddev = 0.007/0.014/0.020/0.001 ms > > sudo ping -c 200 -q -i 0.1 127.0.0.1 > round-trip min/avg/max/stddev = 0.006/0.014/0.021/0.002 ms > > sudo ping -c 200 -q -i 0.1 127.0.0.1 > round-trip min/avg/max/stddev = 0.010/0.014/0.022/0.001 ms > > > sudo ping -c 20 -q -i 1 127.0.0.1 > round-trip min/avg/max/stddev = 0.013/0.018/0.022/0.002 ms > > sudo ping -c 20 -q -i 1 127.0.0.1 > round-trip min/avg/max/stddev = 0.012/0.018/0.021/0.002 ms > > sudo ping -c 20 -q -i 1 127.0.0.1 > round-trip min/avg/max/stddev = 0.009/0.017/0.018/0.002 ms > > sudo ping -c 20 -q -i 1 127.0.0.1 > round-trip min/avg/max/stddev = 0.011/0.017/0.021/0.002 ms > > sudo ping -c 20 -q -i 1 127.0.0.1 > round-trip min/avg/max/stddev = 0.010/0.017/0.020/0.002 ms > > sudo ping -c 20 -q -i 1 127.0.0.1 > round-trip min/avg/max/stddev = 0.009/0.017/0.028/0.004 ms > > cheers > luigi > _______________________________________________ > 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" -- ;s =; From owner-freebsd-net@FreeBSD.ORG Wed Apr 11 08:03:03 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C6FF91065679 for ; Wed, 11 Apr 2012 08:03:03 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by mx1.freebsd.org (Postfix) with ESMTP id 6D2248FC16 for ; Wed, 11 Apr 2012 08:03:03 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1SHsW3-00085O-O5 for freebsd-net@freebsd.org; Wed, 11 Apr 2012 10:02:59 +0200 Received: from pool-108-35-132-213.nwrknj.fios.verizon.net ([108.35.132.213]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 11 Apr 2012 10:02:59 +0200 Received: from ixew by pool-108-35-132-213.nwrknj.fios.verizon.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 11 Apr 2012 10:02:59 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: enoch Date: Wed, 11 Apr 2012 04:02:46 -0400 Lines: 184 Message-ID: <87obqyr909.fsf@hotmail.com> References: <20120403183521.GA7380@michelle.cdnetworks.com> <87obr95pxh.fsf@hotmail.com> <20120403225422.GB7380@michelle.cdnetworks.com> <87sjgk5czo.fsf@hotmail.com> <20120404210445.GB10911@michelle.cdnetworks.com> <87vclfwqp4.fsf@hotmail.com> <20120405161152.GA14289@michelle.cdnetworks.com> <87iphejaar.fsf@hotmail.com> <20120409183704.GA1668@michelle.cdnetworks.com> <87fwccq0do.fsf@hotmail.com> <20120410195135.GA5349@michelle.cdnetworks.com> Mime-Version: 1.0 Content-Type: text/plain X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: pool-108-35-132-213.nwrknj.fios.verizon.net User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.93 (berkeley-unix) Cancel-Lock: sha1:JF7xXkL92MUZieOUpa3RB349pvE= Subject: Re: [nfe] DHCP failure on 8-stable X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 08:03:04 -0000 YongHyeon PYUN writes: > On Mon, Apr 09, 2012 at 01:29:55PM -0400, enoch wrote: >> YongHyeon PYUN writes: >> >> > On Thu, Apr 05, 2012 at 02:36:12PM -0400, enoch wrote: >> >> YongHyeon PYUN writes: >> >> >> >> > On Wed, Apr 04, 2012 at 09:51:19AM -0400, enoch wrote: >> >> >> YongHyeon PYUN writes: >> >> >> >> >> >> > On Wed, Apr 04, 2012 at 12:37:15AM -0400, enoch wrote: >> >> >> >> YongHyeon PYUN writes: >> >> >> >> >> >> >> >> > On Tue, Apr 03, 2012 at 01:45:30AM -0400, enoch wrote: >> >> >> >> >> YongHyeon PYUN writes: >> >> >> >> >> >> >> >> >> >> > On Mon, Apr 02, 2012 at 07:36:36PM -0400, enoch wrote: >> >> >> >> >> >> YongHyeon PYUN writes: >> >> >> >> >> >> >> >> >> >> >> >> > On Mon, Apr 02, 2012 at 03:50:02AM -0400, enoch wrote: >> >> >> >> >> >> >> On 04/02/2012 03:52 PM, YongHyeon PYUN wrote: >> >> >> >> >> >> >> > On Fri, Mar 30, 2012 at 10:40:44AM -0400, enoch wrote: >> >> >> >> >> >> >> >> On 03/30/2012 19:38, YongHyeon PYUN wrote: >> >> >> >> >> >> >> >>> On Fri, Mar 30, 2012 at 03:01:52AM -0400, enoch wrote: >> >> >> >> >> >> >> >>>> Recently it became extremely difficult to pass the DHCP discovery step >> >> >> >> >> >> >> >>>> on boot. Now I am using the buggy [nve] instead. >> >> >> >> >> >> >> >>>> >> >> >> >> >> >> >> >>>> Can anyone help? >> >> >> >> >> >> >> >>>> >> >> >> >> >> >> >> >>> >> >> >> >> >> >> >> >>> Did you set synchronous_dhclient option in rc.conf? >> >> >> >> >> >> >> >>> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Yes: ifconfig_nfe0="SYNCDHCP" >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> I guess [nfe] is undergoing gradual devel changes of some sort as before >> >> >> >> >> >> >> >> it had some chance of reporting "empty headers" on initial ifconfig and >> >> >> >> >> >> >> >> refusing to work. Sorry, I should have reported when encountering the >> >> >> >> >> >> >> >> first problems rather than solve by reboot. >> >> >> >> >> >> >> > >> >> >> >> >> >> >> > Would you show me the output of both dmesg(nfe(4) and its PHY only) >> >> >> >> >> >> >> > and 'sysctl dev.nfe.0.stats'? >> >> >> >> >> >> >> > It would be also helpful to know whether nfe(4) still sees >> >> >> >> >> >> >> > incoming traffic. >> >> >> >> >> >> >> > Does assigning static IP work? >> >> >> >> >> >> >> > >> >> >> >> >> >> >> >> >> >> >> >> >> >> Static IP direct communication attempt from this desktop to another >> >> >> >> >> >> >> laptop through a crossover cable fails as follows. Thanks. >> >> >> >> >> >> >> >> >> >> >> >> >> >> nfe0: flags=8843 metric 0 mtu 1500 >> >> >> >> >> >> >> options=82008 >> >> >> >> >> >> >> ether 00:1f:bc:00:19:dc >> >> >> >> >> >> >> inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255 >> >> >> >> >> >> >> media: Ethernet autoselect (1000baseT >> >> >> >> >> >> >> ) >> >> >> >> >> >> >> status: active >> >> >> >> >> >> >> >> >> >> >> >> >> >> nfe0: link state changed to UP >> >> >> >> >> >> >> nfe0: port 0xf200-0xf207 >> >> >> >> >> >> >> mem 0xefffb000-0xefffbfff irq 21 at device 20.0 on pci0 >> >> >> >> >> >> >> miibus1: on nfe0 >> >> >> >> >> >> > >> >> >> >> >> >> > It seems you've omitted PHY driver here. What PHY driver was >> >> >> >> >> >> > attached to nfe(4)? >> >> >> >> >> >> > >> >> >> >> >> >> >> >> >> >> >> >> miibus1: on nfe0 >> >> >> >> >> >> rgephy1: PHY 1 on miibus1 >> >> >> >> >> >> >> >> >> >> >> >> >> nfe0: Ethernet address: 00:1f:bc:00:19:dc >> >> >> >> >> >> >> nfe0: [FILTER] >> >> >> >> >> >> >> nfe0: discard frame w/o leading ethernet header (len 0 pkt len 0) >> >> >> >> >> >> >> nfe0: discard frame w/o leading ethernet header (len 0 pkt len 0) >> >> >> >> >> >> >> nfe0: link state changed to UP >> >> >> >> >> >> >> nfe0: discard frame w/o leading ethernet header (len 0 pkt len 0) >> >> >> >> >> >> >> nfe0: discard frame w/o leading ethernet header (len 0 pkt len 0) >> >> >> >> >> >> >> nfe0: discard frame w/o leading ethernet header (len 0 pkt len 0) >> >> >> >> >> >> >> >> >> >> >> >> >> >> dev.nfe.0.stats.rx.frame_errors: 0 >> >> >> >> >> >> >> dev.nfe.0.stats.rx.extra_bytes: 0 >> >> >> >> >> >> >> dev.nfe.0.stats.rx.late_cols: 0 >> >> >> >> >> >> >> dev.nfe.0.stats.rx.runts: 0 >> >> >> >> >> >> >> dev.nfe.0.stats.rx.jumbos: 0 >> >> >> >> >> >> >> dev.nfe.0.stats.rx.fifo_overuns: 0 >> >> >> >> >> >> >> dev.nfe.0.stats.rx.crc_errors: 0 >> >> >> >> >> >> >> dev.nfe.0.stats.rx.fae: 0 >> >> >> >> >> >> >> dev.nfe.0.stats.rx.len_errors: 0 >> >> >> >> >> >> >> dev.nfe.0.stats.rx.unicast: 56 >> >> >> >> >> >> >> dev.nfe.0.stats.rx.multicast: 0 >> >> >> >> >> >> >> dev.nfe.0.stats.rx.broadcast: 280 >> >> >> >> >> >> >> dev.nfe.0.stats.tx.octets: 7517 >> >> >> >> >> >> >> dev.nfe.0.stats.tx.zero_rexmits: 51 >> >> >> >> >> >> >> dev.nfe.0.stats.tx.one_rexmits: 0 >> >> >> >> >> >> >> dev.nfe.0.stats.tx.multi_rexmits: 0 >> >> >> >> >> >> >> dev.nfe.0.stats.tx.late_cols: 0 >> >> >> >> >> >> >> dev.nfe.0.stats.tx.fifo_underuns: 0 >> >> >> >> >> >> >> dev.nfe.0.stats.tx.carrier_losts: 0 >> >> >> >> >> >> >> dev.nfe.0.stats.tx.excess_deferrals: 0 >> >> >> >> >> >> >> dev.nfe.0.stats.tx.retry_errors: 0 >> >> >> >> >> >> >> >> >> >> >> >> >> > >> >> >> >> >> >> > Thanks. Would you show me the output of "pciconf -lcbv"? >> >> >> >> >> >> > >> >> >> >> >> >> >> >> >> >> >> >> nfe0@pci0:0:20:0: class=0x068000 card=0x10003842 chip=0x026910de rev=0xa3 hdr=0x00 >> >> >> >> >> >> vendor = 'NVIDIA Corporation' >> >> >> >> >> >> device = 'MCP51 Network Bus Enumerator' >> >> >> >> >> >> class = bridge >> >> >> >> >> >> bar [10] = type Memory, range 32, base 0xefffb000, size 4096, enabled >> >> >> >> >> >> bar [14] = type I/O Port, range 32, base 0xf200, size 8, enabled >> >> >> >> >> >> cap 01[44] = powerspec 2 supports D0 D1 D2 D3 current D0 >> >> >> >> >> >> >> >> >> >> >> >> Interestingly, now that nfe0 is using a static IP it sometimes boots >> >> >> >> >> >> up properly. Are you interested in its good working? >> >> >> >> >> > >> >> >> >> >> > Yes I am. Would you try attached patch and let me know whether the >> >> >> >> >> > patch makes any difference on your box? >> >> >> >> >> >> >> >> >> >> Sorry to report: The patch was applied (to 8-stable latest code) but out >> >> >> >> >> of 3 boots only one succeeded. Same stream of "nfe0: discard frame w/o >> >> >> >> >> leading ethernet header (len 0 pkt len 0)" messages. >> >> >> >> > >> >> >> >> > Ok, back out previous patch and try attached one. >> >> >> >> >> >> >> >> With these two patch files applied to the 8-stable code, buildkernel >> >> >> >> fails as follows. >> >> >> >> >> >> >> >> /usr/src/sys/modules/nfe/../../dev/nfe/if_nfe.c: In function 'nfe_attach': >> >> >> >> /usr/src/sys/modules/nfe/../../dev/nfe/if_nfe.c:629: error: 'struct mii_softc' has no member named 'mii_mpd_oui' >> >> >> >> /usr/src/sys/modules/nfe/../../dev/nfe/if_nfe.c:629: error: 'struct mii_softc' has no member named 'mii_mpd_oui' >> >> >> >> /usr/src/sys/modules/nfe/../../dev/nfe/if_nfe.c:630: error: 'struct mii_softc' has no member named 'mii_mpd_model' >> >> >> >> *** Error code 1 >> >> >> >> >> >> >> > >> >> >> > Oops, sorry I forgot that this part of change was not merged to >> >> >> > stable/8. I've attached a minimal patch which would be cleanly >> >> >> > applied to stable/8. >> >> >> >> >> >> Wasn't the attached diff3 already included in diff2? Seems to me the >> >> >> wrong file was attached this time. Please advise. >> >> > >> >> > diff2 is subset of diff3 but it can be merged to stable/8 and >> >> > stable/7. Probably diff2 may have better chance to fully >> >> > reinitialize PHY but let's see whether diff3 also makes difference >> >> > on your box. >> >> > So back out any changes and apply diff3. >> >> >> >> I'm sorry, this if_nfereg.h patch is not enough. Boot failure frequency >> >> is just the same. I guess I should consider migrating to 9-stable. The >> >> problem with 9-stable is that most of the time it does not build :-( >> >> >> >> Thanks for your efforts. Enoch. >> > >> > Here is updated patch for stable/8. Let me know whether it makes >> > any difference. >> >> Sorry, the diff4 patch compiled but made no difference (using static >> IP). On first boot the "w/o leading ethernet header" problem showed >> up. Can you generate diagnostic messages that I can collect for you from >> dmesg or messages? >> > > Due to lack of documentation, I also don't know which registers > should I poke at this moment. This reminds me old experimental > patch which tried to address reset/DMA issues. > Would you try that? Note, I don't have access to nfe(4) so > the patch was not tested at all. > You can find the patch at the following URL. > http://people.freebsd.org/~yongari/nfe/nfe.reset.diff I will try it in the next few days. I saw that you are contributing to the [re] driver as well. This PCI card that I plugged (to replace [nfe]) in 8-stable is losing its Ethernet connection to the router every few hours. Recovery is only possible through a reboot. What info do you suggest to collect before opening a new thread. Thanks. > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Wed Apr 11 09:55:19 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3C9641065678 for ; Wed, 11 Apr 2012 09:55:19 +0000 (UTC) (envelope-from simond@irrelevant.org) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9BBFE8FC0C for ; Wed, 11 Apr 2012 09:55:17 +0000 (UTC) Received: by vbmv11 with SMTP id v11so673007vbm.13 for ; Wed, 11 Apr 2012 02:55:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=irrelevant.org; s=irrelevant; h=mime-version:x-originating-ip:date:message-id:subject:from:to :content-type; bh=7IlDX9Ml5R85QWHDpf5WDvMO1a+NA0bVIV3etRzFpX4=; b=hpNViwDVsgr4X4GzDezfVnW2fhVVq8m4WyBhAtmIyhrVlJjCmMwRrLc4BVlAc6yD36 397y5JKw9QYSrX1nMPIVPN+G7gmzOIHjBZQdV4RwiySxLkuzNO5fnHln5mxbdODKgIP/ McdgAn4i+1xDrlthznj5XmBiqzIl+EsdmJwPo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=7IlDX9Ml5R85QWHDpf5WDvMO1a+NA0bVIV3etRzFpX4=; b=kp48GM1cjvDxREvNqmF1YepgZ7GgMOlrrE6MUnessFc/3c8FdnxQ75wA23vh4VBLyi hGRTkczpM0OGjzmHcyL/Bre1HDNRxqns63y+rNoxQOkxLF2mVCxPvJ6lTjPU+iIdOr/R 8pMS25tX5CHgc3H8dI8ZFoid7Z2JsAVRVqps9dOjvGEyY2znzRQYvs7Vn25lIdiqeTSK MbYWFI373TXSJ/4NfHwD70mz9BQ+SBK3sFF87rPwkUBoiDH1pkmc0iXgBhgjnb/xkKFr LgDpuduoN6p0XExy1hEbuglXMOI3XowzuR5kbxz0nWFZXSj/OKBzuX04mxsSUwp6Yu/U +fwQ== MIME-Version: 1.0 Received: by 10.220.155.7 with SMTP id q7mr7357702vcw.71.1334138115979; Wed, 11 Apr 2012 02:55:15 -0700 (PDT) Received: by 10.52.173.68 with HTTP; Wed, 11 Apr 2012 02:55:15 -0700 (PDT) X-Originating-IP: [188.223.83.48] Date: Wed, 11 Apr 2012 10:55:15 +0100 Message-ID: From: Simon Dick To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlv2J3aNeV3QW6xfk7CUoKW5lcAWKNbDosFwGDbF6b0ddGa7YN//p1T6Y9TZkk7yOGXErZY Subject: Problems with lagg interfaces X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 09:55:19 -0000 Hi, I've just seen an odd problem when using the lagg interface (in FreeBSD 8.1, but I can't see any relevant commits post-8.1) where the underlying interfaces can see incoming traffic but that doesn't show up on lagg. Unfortunately it's not possible to upgrade the OS at this time as the server is remote and in production. Here's the rc.conf setup: ifconfig_igb0="up" ifconfig_igb1="up" ifconfig_em0="up" ifconfig_em1="up" cloned_interfaces="lagg0 lagg1" ifconfig_lagg0="laggproto failover laggport igb0 laggport em0 1.2.3.4/25" ifconfig_lagg1="laggproto failover laggport igb1 laggport em1 5.6.7.8/16" The strange part is that this happened on two separate machine (same hardware) at around the same time but not a third identical server. Some relevant parts of dmesg: igb0: port 0xcc00-0xcc1f mem 0xfa3e0000-0xfa3fffff,0xfa800000-0xfabfffff,0xfa3dc000-0xfa3dffff irq 16 at device 0.0 on pci5 igb0: Using MSIX interrupts with 10 vectors igb0: Ethernet address: 90:e2:ba:00:d5:ca igb1: port 0xc880-0xc89f mem 0xf97e0000-0xf97fffff,0xf9c00000-0xf9ffffff,0xf97dc000-0xf97dffff irq 17 at device 0.1 on pci5 igb1: Using MSIX interrupts with 10 vectors igb1: Ethernet address: 90:e2:ba:00:d5:cb em0: port 0xdc00-0xdc1f mem 0xfbce0000-0xfbcfffff,0xfbcdc000-0xfbcdffff irq 16 at device 0.0 on pci6 em0: Using MSIX interrupts with 5 vectors em0: Ethernet address: 00:25:90:62:bd:2a em1: port 0xec00-0xec1f mem 0xfbde0000-0xfbdfffff,0xfbddc000-0xfbddffff irq 17 at device 0.0 on pci7 em1: Using MSIX interrupts with 5 vectors em1: Ethernet address: 00:25:90:62:bd:2b If anyone needs any more information or has any ideas please let me know, all that fixed it last time was rebooting, destroying and recreateing the lagg1 interface and even removing totally and creating a lagg2 with the same details had no effect at all. Thanks! From owner-freebsd-net@FreeBSD.ORG Wed Apr 11 10:02:41 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C041E1065672; Wed, 11 Apr 2012 10:02:41 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 622F38FC08; Wed, 11 Apr 2012 10:02:41 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 3A5C57300A; Wed, 11 Apr 2012 12:21:58 +0200 (CEST) Date: Wed, 11 Apr 2012 12:21:58 +0200 From: Luigi Rizzo To: Jason Hellenthal Message-ID: <20120411102158.GA59821@onelab2.iet.unipi.it> References: <20120410225257.GB53350@onelab2.iet.unipi.it> <20120411040948.GA24775@DataIX.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120411040948.GA24775@DataIX.net> User-Agent: Mutt/1.4.2.3i Cc: current@freebsd.org, net@freebsd.org Subject: Re: strange ping response times... 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, 11 Apr 2012 10:02:41 -0000 On Wed, Apr 11, 2012 at 12:09:48AM -0400, Jason Hellenthal wrote: > ... > > Apparently a ping -f has a much lower RTT than one with non-zero > > delay between transmissions. Part of the story could be that > > the flood version invokes a non-blocking select. > > On the other hand, pinging on the loopback should make > > the response available right away, so what could be the reason > > for the additional 3..10us in the ping response time ? > > > > The following are numbers on an i7-2600k at 3400 MHz + turboboost, > > running stable/9 amd64. Note how the min ping time significantly > > increases moving from flood to 10ms to 1s. > > On an Intel 10G interface i am seeing a min of 14-16us with > > Sorry but I am having trouble wrapping my head around this as the > results below are only for the loopback address 127.0.0.1 that does not > travel on the wire at all ? Did you assign this to the 10ge interface ? > if so which result is which. ? yes i have set net.inet.icmp.icmplim=0 the 127.0.0.1 are purely through the software path. The 10ge numbers are between two freebsd machines connected back-to-back with an SFP+ twinax cable. In this case i get a min RTT of 12-13us with a ping -f, and 22-25us with ping -i 0.001 For the 10ge experiments, there is a clear dependency on the ixgbe interrupt mitigation delay (setting to 10Kintr/s gives ~120us RTT) but once you get down to 30-35us the mitigation has no more effect and you need other tricks (such as disabling AIM, ipfw, ipv6) to shave the extra 3-4us. In both cases there are several microseconds wasted between the -f and normal case. cheers luigi > In order to get any good results on my machine I had to tune the > following. > > net.inet.icmp.reply_from_interface=1 > net.inet.icmp.icmplim_output=0 > net.inet.icmp.icmplim=0 > net.inet.icmp.log_redirect=1 > > You may have other options if this is greater than stable/8 @ 234095 > > But yes the results seem skewed to some extent and being loopback I > would think there should be a very near zero rx/tx time. > > > > a ping flood, and up to 33-35us with the standard 1s interval > > (using -q probably trims another 2..5us) > > > > > sudo ping -c 1000 -q -f 127.0.0.1 > > round-trip min/avg/max/stddev = 0.002/0.003/0.012/0.001 ms > > > sudo ping -c 1000 -q -f 127.0.0.1 > > round-trip min/avg/max/stddev = 0.002/0.002/0.013/0.001 ms > > > sudo ping -c 1000 -q -f 127.0.0.1 > > round-trip min/avg/max/stddev = 0.002/0.002/0.013/0.001 ms > > > sudo ping -c 10000 -q -f 127.0.0.1 > > round-trip min/avg/max/stddev = 0.002/0.002/0.011/0.001 ms > > > > > sudo ping -c 1000 -q -i 0.01 127.0.0.1 > > round-trip min/avg/max/stddev = 0.005/0.012/0.017/0.001 ms > > > sudo ping -c 1000 -q -i 0.01 127.0.0.1 > > round-trip min/avg/max/stddev = 0.004/0.012/0.016/0.001 ms > > > sudo ping -c 200 -q -i 0.01 127.0.0.1 > > round-trip min/avg/max/stddev = 0.007/0.012/0.017/0.002 ms > > > sudo ping -c 200 -q -i 0.01 127.0.0.1 > > round-trip min/avg/max/stddev = 0.005/0.012/0.018/0.002 ms > > > sudo ping -c 200 -q -i 0.01 127.0.0.1 > > round-trip min/avg/max/stddev = 0.009/0.012/0.020/0.002 ms > > > sudo ping -c 200 -q -i 0.01 127.0.0.1 > > round-trip min/avg/max/stddev = 0.006/0.012/0.016/0.001 ms > > > > > sudo ping -c 200 -q -i 0.1 127.0.0.1 > > round-trip min/avg/max/stddev = 0.007/0.014/0.020/0.001 ms > > > sudo ping -c 200 -q -i 0.1 127.0.0.1 > > round-trip min/avg/max/stddev = 0.006/0.014/0.019/0.002 ms > > > sudo ping -c 200 -q -i 0.1 127.0.0.1 > > round-trip min/avg/max/stddev = 0.007/0.014/0.021/0.001 ms > > > sudo ping -c 200 -q -i 0.1 127.0.0.1 > > round-trip min/avg/max/stddev = 0.007/0.014/0.020/0.001 ms > > > sudo ping -c 200 -q -i 0.1 127.0.0.1 > > round-trip min/avg/max/stddev = 0.006/0.014/0.021/0.002 ms > > > sudo ping -c 200 -q -i 0.1 127.0.0.1 > > round-trip min/avg/max/stddev = 0.010/0.014/0.022/0.001 ms > > > > > sudo ping -c 20 -q -i 1 127.0.0.1 > > round-trip min/avg/max/stddev = 0.013/0.018/0.022/0.002 ms > > > sudo ping -c 20 -q -i 1 127.0.0.1 > > round-trip min/avg/max/stddev = 0.012/0.018/0.021/0.002 ms > > > sudo ping -c 20 -q -i 1 127.0.0.1 > > round-trip min/avg/max/stddev = 0.009/0.017/0.018/0.002 ms > > > sudo ping -c 20 -q -i 1 127.0.0.1 > > round-trip min/avg/max/stddev = 0.011/0.017/0.021/0.002 ms > > > sudo ping -c 20 -q -i 1 127.0.0.1 > > round-trip min/avg/max/stddev = 0.010/0.017/0.020/0.002 ms > > > sudo ping -c 20 -q -i 1 127.0.0.1 > > round-trip min/avg/max/stddev = 0.009/0.017/0.028/0.004 ms > > > > cheers > > luigi > > _______________________________________________ > > 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" > > -- > ;s =; From owner-freebsd-net@FreeBSD.ORG Wed Apr 11 10:34:37 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A9AAB106564A for ; Wed, 11 Apr 2012 10:34:37 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id B90FE8FC14 for ; Wed, 11 Apr 2012 10:34:36 +0000 (UTC) Received: (qmail 48813 invoked from network); 11 Apr 2012 10:31:18 -0000 Received: from unknown (HELO [62.48.0.94]) ([62.48.0.94]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 11 Apr 2012 10:31:18 -0000 Message-ID: <4F855E5E.5000107@freebsd.org> Date: Wed, 11 Apr 2012 12:35:10 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Luigi Rizzo References: <20120410225257.GB53350@onelab2.iet.unipi.it> <4F84B6DB.5040904@freebsd.org> <20120410230500.GA22829@pit.databus.com> <20120410233211.GA53829@onelab2.iet.unipi.it> In-Reply-To: <20120410233211.GA53829@onelab2.iet.unipi.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Barney Wolff , current@freebsd.org, net@freebsd.org Subject: Re: strange ping response times... 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, 11 Apr 2012 10:34:37 -0000 On 11.04.2012 01:32, Luigi Rizzo wrote: > On Tue, Apr 10, 2012 at 07:05:00PM -0400, Barney Wolff wrote: >> CPU cache? >> Cx states? >> powerd? > > powerd is disabled, and i am going down to C1 at most > > sysctl -a | grep cx > hw.acpi.cpu.cx_lowest: C1 > dev.cpu.0.cx_supported: C1/1 C2/80 C3/104 > > which shouldn't take so much. Sure, cache matters, but the > fact is, icmp processing on loopback should occur inline. > > unless there is a forced descheduling on a select with timeout> 0 > which would explain the extra few microseconds (and makes me worry > on how expensive is a scheduling decision...) Things going through loopback go through a NETISR and may end up queued to avoid LOR situations. In addition per-cpu queues with hash-distribution for affinity may cause your packet to be processed by a different core. Hence the additional delay. -- Andre From owner-freebsd-net@FreeBSD.ORG Wed Apr 11 10:41:18 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1E4AD1065672; Wed, 11 Apr 2012 10:41:18 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id D05758FC18; Wed, 11 Apr 2012 10:41:17 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 6E2777300A; Wed, 11 Apr 2012 13:00:36 +0200 (CEST) Date: Wed, 11 Apr 2012 13:00:36 +0200 From: Luigi Rizzo To: Andre Oppermann Message-ID: <20120411110036.GA60031@onelab2.iet.unipi.it> References: <20120410225257.GB53350@onelab2.iet.unipi.it> <4F84B6DB.5040904@freebsd.org> <20120410230500.GA22829@pit.databus.com> <20120410233211.GA53829@onelab2.iet.unipi.it> <4F855E5E.5000107@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F855E5E.5000107@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: Barney Wolff , current@freebsd.org, net@freebsd.org Subject: Re: strange ping response times... 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, 11 Apr 2012 10:41:18 -0000 On Wed, Apr 11, 2012 at 12:35:10PM +0200, Andre Oppermann wrote: > On 11.04.2012 01:32, Luigi Rizzo wrote: > >On Tue, Apr 10, 2012 at 07:05:00PM -0400, Barney Wolff wrote: > >>CPU cache? > >>Cx states? > >>powerd? > > > >powerd is disabled, and i am going down to C1 at most > > > sysctl -a | grep cx > > hw.acpi.cpu.cx_lowest: C1 > > dev.cpu.0.cx_supported: C1/1 C2/80 C3/104 > > > >which shouldn't take so much. Sure, cache matters, but the > >fact is, icmp processing on loopback should occur inline. > > > >unless there is a forced descheduling on a select with timeout> 0 > >which would explain the extra few microseconds (and makes me worry > >on how expensive is a scheduling decision...) > > Things going through loopback go through a NETISR and may > end up queued to avoid LOR situations. In addition per-cpu > queues with hash-distribution for affinity may cause your > packet to be processed by a different core. Hence the additional > delay. so you suggest that the (de)scheduling is costing several microseconds ? Do we have something like yield() to measure how expensive is the scheduler ? I ran some tests in a distant past and i remember numbers of a few microseconds, but that was almost two gigahertz ago... cheers luigi From owner-freebsd-net@FreeBSD.ORG Wed Apr 11 12:16:10 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 905E21065673 for ; Wed, 11 Apr 2012 12:16:10 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id E6B1B8FC12 for ; Wed, 11 Apr 2012 12:16:09 +0000 (UTC) Received: (qmail 49146 invoked from network); 11 Apr 2012 12:12:56 -0000 Received: from unknown (HELO [62.48.0.94]) ([62.48.0.94]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 11 Apr 2012 12:12:56 -0000 Message-ID: <4F857631.8040309@freebsd.org> Date: Wed, 11 Apr 2012 14:16:49 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Luigi Rizzo References: <20120410225257.GB53350@onelab2.iet.unipi.it> <4F84B6DB.5040904@freebsd.org> <20120410230500.GA22829@pit.databus.com> <20120410233211.GA53829@onelab2.iet.unipi.it> <4F855E5E.5000107@freebsd.org> <20120411110036.GA60031@onelab2.iet.unipi.it> In-Reply-To: <20120411110036.GA60031@onelab2.iet.unipi.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Barney Wolff , current@freebsd.org, net@freebsd.org Subject: Re: strange ping response times... 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, 11 Apr 2012 12:16:10 -0000 On 11.04.2012 13:00, Luigi Rizzo wrote: > On Wed, Apr 11, 2012 at 12:35:10PM +0200, Andre Oppermann wrote: >> On 11.04.2012 01:32, Luigi Rizzo wrote: >>> On Tue, Apr 10, 2012 at 07:05:00PM -0400, Barney Wolff wrote: >>>> CPU cache? >>>> Cx states? >>>> powerd? >>> >>> powerd is disabled, and i am going down to C1 at most >>> > sysctl -a | grep cx >>> hw.acpi.cpu.cx_lowest: C1 >>> dev.cpu.0.cx_supported: C1/1 C2/80 C3/104 >>> >>> which shouldn't take so much. Sure, cache matters, but the >>> fact is, icmp processing on loopback should occur inline. >>> >>> unless there is a forced descheduling on a select with timeout> 0 >>> which would explain the extra few microseconds (and makes me worry >>> on how expensive is a scheduling decision...) >> >> Things going through loopback go through a NETISR and may >> end up queued to avoid LOR situations. In addition per-cpu >> queues with hash-distribution for affinity may cause your >> packet to be processed by a different core. Hence the additional >> delay. > > so you suggest that the (de)scheduling is costing several microseconds ? Not directly. I'm just trying to explain what's going on to get a better idea where it may go wrong. There may be a poor ISR/scheduler interaction that prevents that causes the packet to be processed only on the next tick or something like that. I don't have a better explanation for this. > Do we have something like yield() to measure how expensive is the > scheduler ? I ran some tests in a distant past and i remember numbers > of a few microseconds, but that was almost two gigahertz ago... -- Andre From owner-freebsd-net@FreeBSD.ORG Wed Apr 11 13:00:03 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E8A311065670; Wed, 11 Apr 2012 13:00:02 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 981C98FC0C; Wed, 11 Apr 2012 13:00:02 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 5E1F17300A; Wed, 11 Apr 2012 15:19:20 +0200 (CEST) Date: Wed, 11 Apr 2012 15:19:20 +0200 From: Luigi Rizzo To: Andre Oppermann Message-ID: <20120411131920.GA61027@onelab2.iet.unipi.it> References: <20120410225257.GB53350@onelab2.iet.unipi.it> <4F84B6DB.5040904@freebsd.org> <20120410230500.GA22829@pit.databus.com> <20120410233211.GA53829@onelab2.iet.unipi.it> <4F855E5E.5000107@freebsd.org> <20120411110036.GA60031@onelab2.iet.unipi.it> <4F857631.8040309@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F857631.8040309@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: Barney Wolff , current@freebsd.org, net@freebsd.org Subject: Re: strange ping response times... 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, 11 Apr 2012 13:00:03 -0000 On Wed, Apr 11, 2012 at 02:16:49PM +0200, Andre Oppermann wrote: > On 11.04.2012 13:00, Luigi Rizzo wrote: > >On Wed, Apr 11, 2012 at 12:35:10PM +0200, Andre Oppermann wrote: > >>On 11.04.2012 01:32, Luigi Rizzo wrote: > >>>On Tue, Apr 10, 2012 at 07:05:00PM -0400, Barney Wolff wrote: > >>>>CPU cache? > >>>>Cx states? > >>>>powerd? > >>> > >>>powerd is disabled, and i am going down to C1 at most > >>> > sysctl -a | grep cx > >>> hw.acpi.cpu.cx_lowest: C1 > >>> dev.cpu.0.cx_supported: C1/1 C2/80 C3/104 > >>> > >>>which shouldn't take so much. Sure, cache matters, but the > >>>fact is, icmp processing on loopback should occur inline. > >>> > >>>unless there is a forced descheduling on a select with timeout> 0 > >>>which would explain the extra few microseconds (and makes me worry > >>>on how expensive is a scheduling decision...) > >> > >>Things going through loopback go through a NETISR and may > >>end up queued to avoid LOR situations. In addition per-cpu > >>queues with hash-distribution for affinity may cause your > >>packet to be processed by a different core. Hence the additional > >>delay. > > > >so you suggest that the (de)scheduling is costing several microseconds ? > > Not directly. I'm just trying to explain what's going on to > get a better idea where it may go wrong. > > There may be a poor ISR/scheduler interaction that prevents that > causes the packet to be processed only on the next tick or something > like that. I don't have a better explanation for this. ok, some final remarks just for archival purposes (still related to the loopback ping) ping takes a timestamp in userspace before trying to transmit the packet, and then the timestamp for the received packet is recorded in the kernel (in the interrupt or netisr thread i believe -- anyways, not in userspace). A thing that seems to make the difference is the choice of idle states: machdep.idle = {acpi, hlt, mwait, spin} hw.acpi.cpu.cx_lowest={C1, C2, C3} results in 10-15% of samples with significantly different values (see table below, all values in microseconds) config normal top 10-15% ----------------------------------------- acpi+c3 13 85 acpi+c2 10 40 acpi+c1 7 10 spin 7 8 hlt,mwait 6..10 (no clear distinction) ping -f 5-6 This suggests that sometimes the responding thread may be started on a sleeping core and so takes longer to wake up. The high values are not periodic but the ratio is close to the 128/1000 which relates profhz and tick, so that might be something to look at. cheers luigi From owner-freebsd-net@FreeBSD.ORG Wed Apr 11 17:05:18 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8AAE4106564A; Wed, 11 Apr 2012 17:05:18 +0000 (UTC) (envelope-from kes-kes@yandex.ru) Received: from forward4.mail.yandex.net (forward4.mail.yandex.net [IPv6:2a02:6b8:0:602::4]) by mx1.freebsd.org (Postfix) with ESMTP id ED5398FC17; Wed, 11 Apr 2012 17:05:17 +0000 (UTC) Received: from smtp1.mail.yandex.net (smtp1.mail.yandex.net [77.88.46.101]) by forward4.mail.yandex.net (Yandex) with ESMTP id 77AE21BC21F4; Wed, 11 Apr 2012 21:05:16 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1334163916; bh=MMdqYtyUK7M2jTb+C5FTArdZPn+rsztX9husSTOIp8I=; h=Date:From:Reply-To:Message-ID:To:CC:Subject:In-Reply-To: References:MIME-Version:Content-Type:Content-Transfer-Encoding; b=UXMnyNhie+XCG3yyqGGBiEqUCHZA3RXqtmPc+UpgmhJyvhcJS1sOyVsmnhI93mK3+ zEMbMq1OlmNQgsEJhQw6M9xL9GnEWfgty6VDPqvZIVeCAU7r9eTuGrQNeBk3W+0f16 fZWK45JBcY4E/eRzcUEBXUg6oZn70Mqavns+NhZk= Received: from smtp1.mail.yandex.net (localhost [127.0.0.1]) by smtp1.mail.yandex.net (Yandex) with ESMTP id 4AF57AA02EA; Wed, 11 Apr 2012 21:05:16 +0400 (MSK) Received: from unknown (unknown [176.8.82.56]) by smtp1.mail.yandex.net (nwsmtp/Yandex) with ESMTP id 5CqCUTjr-5Fq0qxWg; Wed, 11 Apr 2012 21:05:15 +0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1334163916; bh=MMdqYtyUK7M2jTb+C5FTArdZPn+rsztX9husSTOIp8I=; h=Date:From:X-Mailer:Reply-To:Organization:X-Priority:Message-ID:To: CC:Subject:In-Reply-To:References:MIME-Version:Content-Type: Content-Transfer-Encoding; b=isknHtZvc/95iJMi/6diLNmrMMTb+wA+KGs8bjxb2gu+/63JMdDItKn1zjzbj7bWo fzofPmEDsGND3Cc1lZ7lV3GyOF3yeY123aaArOTA6mNWvjoyjrYe5+ctXtsBGTd31G xWYI8otPuCPyu4HAfW/S4lm+XDBTXui/Yy7Uzg20= Date: Wed, 11 Apr 2012 20:05:10 +0300 From: =?koi8-r?B?68/O2MvP1yDl18fFzsnK?= X-Mailer: The Bat! (v4.0.24) Professional Organization: =?koi8-r?B?/vAg68/O2MvP1ywgRnJlZUxpbmU=?= X-Priority: 3 (Normal) Message-ID: <1003395682.20120411200510@yandex.ru> To: Eugene Grosbein In-Reply-To: <4F835728.5030809@rdtc.ru> References: <61227818.20120409213654@yandex.ru> <4F835728.5030809@rdtc.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org, freebsd-questions@freebsd.org Subject: Re[2]: fsck problem FreeBSD 8.3 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: =?koi8-r?B?68/O2MvP1yDl18fFzsnK?= List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 17:05:18 -0000 úÄÒÁ×ÓÔ×ÕÊÔÅ, Eugene. ÷Ù ÐÉÓÁÌÉ 10 ÁÐÒÅÌÑ 2012 Ç., 0:39:52: EG> 10.04.2012 01:36, ëÏÎØËÏ× å×ÇÅÎÉÊ ÐÉÛÅÔ: >> Hi. >> >> Apr 9 19:51:58 fsck: /dev/ad8s1e: UNEXPECTED INCONSISTENCY, CANNOT RUN FAST FSCK >> Apr 9 19:51:58 fsck: >> Apr 9 19:51:58 fsck: >> Apr 9 19:51:58 fsck: /dev/ad8s1e: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY. >> Apr 9 19:51:58 fsck: /dev/ad8s1e: CANNOT SET FS_NEEDSFSCK FLAG >> Apr 9 20:09:22 kernel: >> >> running manually: >> # fsck -y /dev/ad8s1e >> ** /dev/ad8s1e (NO WRITE) EG> You cannot run fsck on mounted filesystem, unmount it first. Why not? fsck can do its job at background, on mounted FS. So I also can run it on mounted FS. in this case (as I have showed) it do not find any errors. In any case I have run fsck on this FS when it was dismounted. There is no any errors. I think here is only one problem. problem to 'RUN FAST FSCK' -- ó Õ×ÁÖÅÎÉÅÍ, ëÏÎØËÏ× mailto:kes-kes@yandex.ru From owner-freebsd-net@FreeBSD.ORG Wed Apr 11 17:18:14 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AF061106566B; Wed, 11 Apr 2012 17:18:14 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13::5]) by mx1.freebsd.org (Postfix) with ESMTP id 14CF38FC08; Wed, 11 Apr 2012 17:18:13 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.5/8.14.5) with ESMTP id q3BHIBAM060260; Thu, 12 Apr 2012 00:18:11 +0700 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <4F85BCD3.3060900@rdtc.ru> Date: Thu, 12 Apr 2012 00:18:11 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.2.13) Gecko/20110112 Thunderbird/3.1.7 MIME-Version: 1.0 To: =?KOI8-R?Q?=EB=CF=CE=D8=CB=CF=D7_=E5=D7=C7=C5=CE=C9=CA?= References: <61227818.20120409213654@yandex.ru> <4F835728.5030809@rdtc.ru> <1003395682.20120411200510@yandex.ru> In-Reply-To: <1003395682.20120411200510@yandex.ru> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org, freebsd-questions@freebsd.org Subject: Re: fsck problem FreeBSD 8.3 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Apr 2012 17:18:14 -0000 12.04.2012 00:05, ëÏÎØËÏ× å×ÇÅÎÉÊ ÐÉÛÅÔ: > úÄÒÁ×ÓÔ×ÕÊÔÅ, Eugene. > > ÷Ù ÐÉÓÁÌÉ 10 ÁÐÒÅÌÑ 2012 Ç., 0:39:52: > > EG> 10.04.2012 01:36, ëÏÎØËÏ× å×ÇÅÎÉÊ ÐÉÛÅÔ: >>> Hi. >>> >>> Apr 9 19:51:58 fsck: /dev/ad8s1e: UNEXPECTED INCONSISTENCY, CANNOT RUN FAST FSCK >>> Apr 9 19:51:58 fsck: >>> Apr 9 19:51:58 fsck: >>> Apr 9 19:51:58 fsck: /dev/ad8s1e: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY. >>> Apr 9 19:51:58 fsck: /dev/ad8s1e: CANNOT SET FS_NEEDSFSCK FLAG >>> Apr 9 20:09:22 kernel: >>> >>> running manually: >>> # fsck -y /dev/ad8s1e >>> ** /dev/ad8s1e (NO WRITE) > > EG> You cannot run fsck on mounted filesystem, unmount it first. > Why not? fsck can do its job at background, on mounted FS. It is run in special mode then, you run fsck not that way. > So I also can run it on mounted FS. "NO WRITE" signals you that it will not be able to fix any problem it encounters. > in this case (as I have showed) it do not find any errors. And if it finds any error on mounted live file system, that would not mean the error really exists. Do NOT run fsck on mounted file system, period. > In any case I have run fsck on this FS when it was dismounted. > There is no any errors. So, you need not bother, your file system has been already fixed. > I think here is only one problem. problem to 'RUN FAST FSCK' No need to, already. Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Thu Apr 12 03:19:18 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6F7CD106566B; Thu, 12 Apr 2012 03:19:18 +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 E7B868FC0C; Thu, 12 Apr 2012 03:19:17 +0000 (UTC) Received: from c211-30-171-136.carlnfd1.nsw.optusnet.com.au (c211-30-171-136.carlnfd1.nsw.optusnet.com.au [211.30.171.136]) by mail01.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q3C3Ixxn028956 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Apr 2012 13:19:01 +1000 Date: Thu, 12 Apr 2012 13:18:59 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Luigi Rizzo In-Reply-To: <20120411131920.GA61027@onelab2.iet.unipi.it> Message-ID: <20120412112401.Q981@besplex.bde.org> References: <20120410225257.GB53350@onelab2.iet.unipi.it> <4F84B6DB.5040904@freebsd.org> <20120410230500.GA22829@pit.databus.com> <20120410233211.GA53829@onelab2.iet.unipi.it> <4F855E5E.5000107@freebsd.org> <20120411110036.GA60031@onelab2.iet.unipi.it> <4F857631.8040309@freebsd.org> <20120411131920.GA61027@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Barney Wolff , Andre Oppermann , current@freebsd.org, net@freebsd.org Subject: Re: strange ping response times... 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, 12 Apr 2012 03:19:18 -0000 On Wed, 11 Apr 2012, Luigi Rizzo wrote: > On Wed, Apr 11, 2012 at 02:16:49PM +0200, Andre Oppermann wrote: >> On 11.04.2012 13:00, Luigi Rizzo wrote: >>> On Wed, Apr 11, 2012 at 12:35:10PM +0200, Andre Oppermann wrote: >>>> On 11.04.2012 01:32, Luigi Rizzo wrote: >>>> >>>> Things going through loopback go through a NETISR and may >>>> end up queued to avoid LOR situations. In addition per-cpu >>>> queues with hash-distribution for affinity may cause your >>>> packet to be processed by a different core. Hence the additional >>>> delay. >>> >>> so you suggest that the (de)scheduling is costing several microseconds ? >> >> Not directly. I'm just trying to explain what's going on to >> get a better idea where it may go wrong. >> >> There may be a poor ISR/scheduler interaction that prevents that >> causes the packet to be processed only on the next tick or something >> like that. I don't have a better explanation for this. It's certainly abysmally slow. Just the extra context switching made in FreeBSD-5 made the RTT for pinging localhost 3-4 times slower than in FreeBSD-3 in old tests (I compared with FreeBSD-3 instead of FreeBSD-4 since general bloat had already made FreeBSD-4 significantly slower, although not 3-4 times). Direct dispatch of netisrs never did anything good in old tests, and the situation doesn't seem to have improved -- you now need an i7 2600 (SMP?) to get the same speed as my Athlon64 2000 (UP) in the best cases for both (2-3 usec RTT). SMP and multiple cores give more chances for scheduler pessimizations. > ok, some final remarks just for archival purposes > (still related to the loopback ping) > > ping takes a timestamp in userspace before trying to transmit > the packet, and then the timestamp for the received packet > is recorded in the kernel (in the interrupt or netisr thread > i believe -- anyways, not in userspace). No, all timestamps recorded used by ping are recorded in userland. IIRC, there is no kernel timestamping at all for ping packets, unless ping is invoked with "-M time" to make it use ICMP_TSTAMP, and ICMP_TSTAMP gives at best milliseconds resolution so it is useless for measuring RTTs in the 2-999 usec range. (ICMP_TSTAMP uses iptime(), and the protocol only supports milliseconds resolution, which was good enough for 1 Mbps ethernet. iptime() is more broken than that (except in my version), since it uses getmicrotime() instead of microtime(). getmicrotime() gives at best 1/HZ resolution, so it is not even good enough for 1 Mbps ethernet when HZ is small, and now it may give extra inaccuracies from stopping the 1/HZ clock while in sleep states.) This reminds me that slow timecounters make measuring small differences in times difficult. It can take longer to read the timecounter than the entire RTT. I tested this by pessimizing kern.timecounter.hardware from TSC to i8254. On my test system, clock_gettime() with CLOCK_MONOTONIC takes an average of 273 nsec with the TSC timecounter and 4695 nsec with the i8254 timecounter. ping uses gettimeofday() which is slightly slower and more broken (since it uses CLOCK_REALTIME). My normal ping -fq localhost RTT is 2-3 usec (closer to 3; another bug in this area is that the timestamps only have microseconds resolution so you can't see if 3 is actually more like 2.5. I was thinking of changing the resolution to nanoseconds 8-10 years ago, before the FreeBSD-5 pessimizations and CPU speeds hitting a wall made this not really necessary), but the kernel I'm testing with uses ipfw which bloats the RTT to 8-9 usec. Then kern.timecounter.hardware=i8254 bloates the RTT to 24-25! That's 16 usec extra, enough for the extra overhead of 4 gettimeofday() calls. Timecounter statistics confirm that there are many more than 2 timecounter calls per packet: - 7 binuptime calls per packet. That's the hardware part that is very slow with an i8254 timecounter. It apparently takes more like 3000 nsec than 4695 nsec (to fit 7 in 24-25 usec). - 3 bintime calls per packet. bintime calls binuptime, so this accounts for 3 of the above 7. The other 4 are apparently for context switching. There are 2 context switches per packet :-(. I can't explain why there are apparently 2 timestamps per context switch. (Note that -current uses the inferior cputicker mechanism instead of timecounters for timestamping context switches. It does this because some timecounters are very slow. But when the timecounter is the TSC, it binuptime() only takes a few cycles more than cpu_ticks(). (The above time of 273 nsec for reading the TSC timecounter is from userland. The kernel part takes only about 30 nsec, while cpu_ticks() might take 15 nsec.) So -current wouldn't be pessimized for this part by changing the timecounter to i8254, but without the pessimization it would be only a few nsec faster than old kernels provided the timecounter for old kernels is the TSC.) - 2 microtime calls per packet. These are for the 2 gettimeofday()s. microtime calls bintime, so this accounts for 2 of the above 3. The other 1 is unaccounted for. - 1 getmicrouptime call per packet. This doesn't involve the hardware. This is for the select() timeout. If we fixed the resolution bugs in select(), then we would have to be careful not to pessimize it too much by replacing this by microuptime. - 0 calls to iptime() per packet. Benchmarks like this show what a bad idea the get*time() timecounter APIs are. When you actually need to read the time a lot, you need high resolution and thus the full functions, and optimizing for when only low resolution is needed only optimizes the part that doesn't take very long anyway (except for broken programs). > A thing that seems to make > the difference is the choice of idle states: > machdep.idle = {acpi, hlt, mwait, spin} > hw.acpi.cpu.cx_lowest={C1, C2, C3} > results in 10-15% of samples with significantly different values > (see table below, all values in microseconds) > > config normal top 10-15% > ----------------------------------------- > acpi+c3 13 85 > acpi+c2 10 40 > acpi+c1 7 10 > > spin 7 8 > hlt,mwait 6..10 (no clear distinction) > ping -f 5-6 > > This suggests that sometimes the responding thread > may be started on a sleeping core and so takes > longer to wake up. > > The high values are not periodic but the ratio is close to > the 128/1000 which relates profhz and tick, so that might be > something to look at. I guess this is to be expected on a multi-core system. The scheduler should probably try to use a different core for netisrs, but this would cause both cores to block waiting for each other, so both might sleep. Any batching of netisrs would give bursts with longer sleeps in between. I didn't see any large differences between ping -f and ping -i 0.01 on a UP system. My HZ is 100, so -i 0.01 is not really possible and gives more like 0.015 (average) or perhaps 0.02 or even 0.03 after synchronization, as we discussed previously. -i 0.1 is closer to possible and gave a small increase in RTT (-i 1.0 gives the default and a much larger increase). The increases are absolute and not so large relatively starting with the slowness given by ipfw. Note that ping -f doesn't actually flood, since it waits for 1/100 seconds for something to come back, and 1/100 was only a short time with 1 Mbps ethernet. This can be worked around to some extent using ping -i to give a wait time of less than 1/100 seconds. It is still impossible to flood, since wait times of less than 1/HZ are impossible, and the resolution of ping -i is gratuitously limited to 1 msec. You could try setting the -i arg to 1/HZ to see the effects of this, or hack the hard-coded -f timeout to 1 usec. With hardware, there are many more ways for the RTT to vary. One way is that although ping -f doesn't flood, injecting an extra packet on some 1/100 second boundaries can cause queue lengths to build up. This might be only with my version of ping (it keeps track of the boundaries an might send an extra packet when it shouldn't). When the queue lengths increase for any reason (due to injecting packets or when there is a delay for other system activity), packets are sent and received in bursts; throughput goes up almost proporitionally to the queue lengths, and RTT goes up. Bruce From owner-freebsd-net@FreeBSD.ORG Thu Apr 12 07:35:17 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 15F88106564A; Thu, 12 Apr 2012 07:35:17 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id C5A068FC15; Thu, 12 Apr 2012 07:35:16 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 531F57300A; Thu, 12 Apr 2012 09:54:30 +0200 (CEST) Date: Thu, 12 Apr 2012 09:54:30 +0200 From: Luigi Rizzo To: Bruce Evans Message-ID: <20120412075430.GA71623@onelab2.iet.unipi.it> References: <20120410225257.GB53350@onelab2.iet.unipi.it> <4F84B6DB.5040904@freebsd.org> <20120410230500.GA22829@pit.databus.com> <20120410233211.GA53829@onelab2.iet.unipi.it> <4F855E5E.5000107@freebsd.org> <20120411110036.GA60031@onelab2.iet.unipi.it> <4F857631.8040309@freebsd.org> <20120411131920.GA61027@onelab2.iet.unipi.it> <20120412112401.Q981@besplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120412112401.Q981@besplex.bde.org> User-Agent: Mutt/1.4.2.3i Cc: Barney Wolff , Andre Oppermann , current@freebsd.org, net@freebsd.org Subject: Re: strange ping response times... 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, 12 Apr 2012 07:35:17 -0000 On Thu, Apr 12, 2012 at 01:18:59PM +1000, Bruce Evans wrote: > On Wed, 11 Apr 2012, Luigi Rizzo wrote: > > >On Wed, Apr 11, 2012 at 02:16:49PM +0200, Andre Oppermann wrote: ... > >ping takes a timestamp in userspace before trying to transmit > >the packet, and then the timestamp for the received packet > >is recorded in the kernel (in the interrupt or netisr thread > >i believe -- anyways, not in userspace). > > No, all timestamps recorded used by ping are recorded in userland. Bruce, look at the code in ping.c -- SO_TIMESTAMP is defined, so the program does (successfully) a setsockopt(s, SOL_SOCKET, SO_TIMESTAMP, &on, sizeof(on)); and then (verified that at runtime the code follows this path) struct cmsghdr *cmsg = (struct cmsghdr *)&ctrl; msg.msg_controllen = sizeof(ctrl); msg.msg_namelen = sizeof(from); if ((cc = recvmsg(s, &msg, 0)) < 0) { if (errno == EINTR) continue; warn("recvmsg"); continue; } if (cmsg->cmsg_level == SOL_SOCKET && cmsg->cmsg_type == SCM_TIMESTAMP && cmsg->cmsg_len == CMSG_LEN(sizeof *tv)) { /* Copy to avoid alignment problems: */ memcpy(&now, CMSG_DATA(cmsg), sizeof(now)); tv = &now; } ... > My normal ping -fq localhost RTT is 2-3 usec > (closer to 3; another bug in this area is that the timestamps only > have microseconds resolution so you can't see if 3 is actually > more like 2.5. I was thinking of changing the resolution to > nanoseconds 8-10 years ago, before the FreeBSD-5 pessimizations > and CPU speeds hitting a wall made this not really necessary), > but the kernel I'm testing with uses ipfw which bloats the RTT to 8-9 ipfw overhead obviously depends on your firewall configuration, i have tested without ipfw to remove that noise. cheers luigi From owner-freebsd-net@FreeBSD.ORG Thu Apr 12 10:25:13 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4E9051065673 for ; Thu, 12 Apr 2012 10:25:13 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 191C48FC0A for ; Thu, 12 Apr 2012 10:25:13 +0000 (UTC) Received: by pbcwz17 with SMTP id wz17so2402806pbc.13 for ; Thu, 12 Apr 2012 03:25:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=O7Sy0J52oblcBHAdjVygwpoM1bPTgVbnJ1fsG9TWmAE=; b=t4kIzZNjwW5Cbmr+h0t1c4X0JQOvYXl6mDkMMqWxmDv0a/57OI4QS0LczxvJ0P8YbV f9xuMbItkTRU787HAcGsMjKsNJ2c7JS2aktmyak3Fq6ltwaF/PJgW2BV7O7kuDulsnpC PfiAy6aTplk1xPnNSXkSmqDNN+Pj+l6kB/zPuVizyButp3k9taiHoX79kWR3L5kxyXPz 79VvecNqyzMddr1LU0sEdXC+IS+RoqfDzOLf5d85RD547LPvlOX72j3z5m5j8grfhrdR Rjc8KaaeyxzaHzmkzenzxz8tXv6ZMmAfZdhoGzUuaxAPL4yXzDpeEzqKojbYyszay64w pq4g== Received: by 10.68.138.232 with SMTP id qt8mr1221939pbb.114.1334226312613; Thu, 12 Apr 2012 03:25:12 -0700 (PDT) Received: from pyunyh@gmail.com ([114.111.62.249]) by mx.google.com with ESMTPS id d6sm5310872pbi.23.2012.04.12.03.25.08 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 12 Apr 2012 03:25:10 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Thu, 12 Apr 2012 19:25:07 -0700 From: YongHyeon PYUN Date: Thu, 12 Apr 2012 19:25:07 -0700 To: enoch Message-ID: <20120413022507.GA3270@michelle.cdnetworks.com> References: <20120403225422.GB7380@michelle.cdnetworks.com> <87sjgk5czo.fsf@hotmail.com> <20120404210445.GB10911@michelle.cdnetworks.com> <87vclfwqp4.fsf@hotmail.com> <20120405161152.GA14289@michelle.cdnetworks.com> <87iphejaar.fsf@hotmail.com> <20120409183704.GA1668@michelle.cdnetworks.com> <87fwccq0do.fsf@hotmail.com> <20120410195135.GA5349@michelle.cdnetworks.com> <87obqyr909.fsf@hotmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87obqyr909.fsf@hotmail.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: [nfe] DHCP failure on 8-stable X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 10:25:13 -0000 On Wed, Apr 11, 2012 at 04:02:46AM -0400, enoch wrote: > YongHyeon PYUN writes: > > > On Mon, Apr 09, 2012 at 01:29:55PM -0400, enoch wrote: > >> YongHyeon PYUN writes: > >> > >> > On Thu, Apr 05, 2012 at 02:36:12PM -0400, enoch wrote: > >> >> YongHyeon PYUN writes: > >> >> > >> >> > On Wed, Apr 04, 2012 at 09:51:19AM -0400, enoch wrote: > >> >> >> YongHyeon PYUN writes: > >> >> >> > >> >> >> > On Wed, Apr 04, 2012 at 12:37:15AM -0400, enoch wrote: > >> >> >> >> YongHyeon PYUN writes: > >> >> >> >> > >> >> >> >> > On Tue, Apr 03, 2012 at 01:45:30AM -0400, enoch wrote: > >> >> >> >> >> YongHyeon PYUN writes: > >> >> >> >> >> > >> >> >> >> >> > On Mon, Apr 02, 2012 at 07:36:36PM -0400, enoch wrote: > >> >> >> >> >> >> YongHyeon PYUN writes: > >> >> >> >> >> >> > >> >> >> >> >> >> > On Mon, Apr 02, 2012 at 03:50:02AM -0400, enoch wrote: > >> >> >> >> >> >> >> On 04/02/2012 03:52 PM, YongHyeon PYUN wrote: > >> >> >> >> >> >> >> > On Fri, Mar 30, 2012 at 10:40:44AM -0400, enoch wrote: > >> >> >> >> >> >> >> >> On 03/30/2012 19:38, YongHyeon PYUN wrote: > >> >> >> >> >> >> >> >>> On Fri, Mar 30, 2012 at 03:01:52AM -0400, enoch wrote: > >> >> >> >> >> >> >> >>>> Recently it became extremely difficult to pass the DHCP discovery step > >> >> >> >> >> >> >> >>>> on boot. Now I am using the buggy [nve] instead. > >> >> >> >> >> >> >> >>>> > >> >> >> >> >> >> >> >>>> Can anyone help? > >> >> >> >> >> >> >> >>>> > >> >> >> >> >> >> >> >>> > >> >> >> >> >> >> >> >>> Did you set synchronous_dhclient option in rc.conf? > >> >> >> >> >> >> >> >>> > >> >> >> >> >> >> >> >> > >> >> >> >> >> >> >> >> Yes: ifconfig_nfe0="SYNCDHCP" > >> >> >> >> >> >> >> >> > >> >> >> >> >> >> >> >> I guess [nfe] is undergoing gradual devel changes of some sort as before > >> >> >> >> >> >> >> >> it had some chance of reporting "empty headers" on initial ifconfig and > >> >> >> >> >> >> >> >> refusing to work. Sorry, I should have reported when encountering the > >> >> >> >> >> >> >> >> first problems rather than solve by reboot. > >> >> >> >> >> >> >> > > >> >> >> >> >> >> >> > Would you show me the output of both dmesg(nfe(4) and its PHY only) > >> >> >> >> >> >> >> > and 'sysctl dev.nfe.0.stats'? > >> >> >> >> >> >> >> > It would be also helpful to know whether nfe(4) still sees > >> >> >> >> >> >> >> > incoming traffic. > >> >> >> >> >> >> >> > Does assigning static IP work? > >> >> >> >> >> >> >> > > >> >> >> >> >> >> >> > >> >> >> >> >> >> >> Static IP direct communication attempt from this desktop to another > >> >> >> >> >> >> >> laptop through a crossover cable fails as follows. Thanks. > >> >> >> >> >> >> >> > >> >> >> >> >> >> >> nfe0: flags=8843 metric 0 mtu 1500 > >> >> >> >> >> >> >> options=82008 > >> >> >> >> >> >> >> ether 00:1f:bc:00:19:dc > >> >> >> >> >> >> >> inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255 > >> >> >> >> >> >> >> media: Ethernet autoselect (1000baseT > >> >> >> >> >> >> >> ) > >> >> >> >> >> >> >> status: active > >> >> >> >> >> >> >> > >> >> >> >> >> >> >> nfe0: link state changed to UP > >> >> >> >> >> >> >> nfe0: port 0xf200-0xf207 > >> >> >> >> >> >> >> mem 0xefffb000-0xefffbfff irq 21 at device 20.0 on pci0 > >> >> >> >> >> >> >> miibus1: on nfe0 > >> >> >> >> >> >> > > >> >> >> >> >> >> > It seems you've omitted PHY driver here. What PHY driver was > >> >> >> >> >> >> > attached to nfe(4)? > >> >> >> >> >> >> > > >> >> >> >> >> >> > >> >> >> >> >> >> miibus1: on nfe0 > >> >> >> >> >> >> rgephy1: PHY 1 on miibus1 > >> >> >> >> >> >> > >> >> >> >> >> >> >> nfe0: Ethernet address: 00:1f:bc:00:19:dc > >> >> >> >> >> >> >> nfe0: [FILTER] > >> >> >> >> >> >> >> nfe0: discard frame w/o leading ethernet header (len 0 pkt len 0) > >> >> >> >> >> >> >> nfe0: discard frame w/o leading ethernet header (len 0 pkt len 0) > >> >> >> >> >> >> >> nfe0: link state changed to UP > >> >> >> >> >> >> >> nfe0: discard frame w/o leading ethernet header (len 0 pkt len 0) > >> >> >> >> >> >> >> nfe0: discard frame w/o leading ethernet header (len 0 pkt len 0) > >> >> >> >> >> >> >> nfe0: discard frame w/o leading ethernet header (len 0 pkt len 0) > >> >> >> >> >> >> >> > >> >> >> >> >> >> >> dev.nfe.0.stats.rx.frame_errors: 0 > >> >> >> >> >> >> >> dev.nfe.0.stats.rx.extra_bytes: 0 > >> >> >> >> >> >> >> dev.nfe.0.stats.rx.late_cols: 0 > >> >> >> >> >> >> >> dev.nfe.0.stats.rx.runts: 0 > >> >> >> >> >> >> >> dev.nfe.0.stats.rx.jumbos: 0 > >> >> >> >> >> >> >> dev.nfe.0.stats.rx.fifo_overuns: 0 > >> >> >> >> >> >> >> dev.nfe.0.stats.rx.crc_errors: 0 > >> >> >> >> >> >> >> dev.nfe.0.stats.rx.fae: 0 > >> >> >> >> >> >> >> dev.nfe.0.stats.rx.len_errors: 0 > >> >> >> >> >> >> >> dev.nfe.0.stats.rx.unicast: 56 > >> >> >> >> >> >> >> dev.nfe.0.stats.rx.multicast: 0 > >> >> >> >> >> >> >> dev.nfe.0.stats.rx.broadcast: 280 > >> >> >> >> >> >> >> dev.nfe.0.stats.tx.octets: 7517 > >> >> >> >> >> >> >> dev.nfe.0.stats.tx.zero_rexmits: 51 > >> >> >> >> >> >> >> dev.nfe.0.stats.tx.one_rexmits: 0 > >> >> >> >> >> >> >> dev.nfe.0.stats.tx.multi_rexmits: 0 > >> >> >> >> >> >> >> dev.nfe.0.stats.tx.late_cols: 0 > >> >> >> >> >> >> >> dev.nfe.0.stats.tx.fifo_underuns: 0 > >> >> >> >> >> >> >> dev.nfe.0.stats.tx.carrier_losts: 0 > >> >> >> >> >> >> >> dev.nfe.0.stats.tx.excess_deferrals: 0 > >> >> >> >> >> >> >> dev.nfe.0.stats.tx.retry_errors: 0 > >> >> >> >> >> >> >> > >> >> >> >> >> >> > > >> >> >> >> >> >> > Thanks. Would you show me the output of "pciconf -lcbv"? > >> >> >> >> >> >> > > >> >> >> >> >> >> > >> >> >> >> >> >> nfe0@pci0:0:20:0: class=0x068000 card=0x10003842 chip=0x026910de rev=0xa3 hdr=0x00 > >> >> >> >> >> >> vendor = 'NVIDIA Corporation' > >> >> >> >> >> >> device = 'MCP51 Network Bus Enumerator' > >> >> >> >> >> >> class = bridge > >> >> >> >> >> >> bar [10] = type Memory, range 32, base 0xefffb000, size 4096, enabled > >> >> >> >> >> >> bar [14] = type I/O Port, range 32, base 0xf200, size 8, enabled > >> >> >> >> >> >> cap 01[44] = powerspec 2 supports D0 D1 D2 D3 current D0 > >> >> >> >> >> >> > >> >> >> >> >> >> Interestingly, now that nfe0 is using a static IP it sometimes boots > >> >> >> >> >> >> up properly. Are you interested in its good working? > >> >> >> >> >> > > >> >> >> >> >> > Yes I am. Would you try attached patch and let me know whether the > >> >> >> >> >> > patch makes any difference on your box? > >> >> >> >> >> > >> >> >> >> >> Sorry to report: The patch was applied (to 8-stable latest code) but out > >> >> >> >> >> of 3 boots only one succeeded. Same stream of "nfe0: discard frame w/o > >> >> >> >> >> leading ethernet header (len 0 pkt len 0)" messages. > >> >> >> >> > > >> >> >> >> > Ok, back out previous patch and try attached one. > >> >> >> >> > >> >> >> >> With these two patch files applied to the 8-stable code, buildkernel > >> >> >> >> fails as follows. > >> >> >> >> > >> >> >> >> /usr/src/sys/modules/nfe/../../dev/nfe/if_nfe.c: In function 'nfe_attach': > >> >> >> >> /usr/src/sys/modules/nfe/../../dev/nfe/if_nfe.c:629: error: 'struct mii_softc' has no member named 'mii_mpd_oui' > >> >> >> >> /usr/src/sys/modules/nfe/../../dev/nfe/if_nfe.c:629: error: 'struct mii_softc' has no member named 'mii_mpd_oui' > >> >> >> >> /usr/src/sys/modules/nfe/../../dev/nfe/if_nfe.c:630: error: 'struct mii_softc' has no member named 'mii_mpd_model' > >> >> >> >> *** Error code 1 > >> >> >> >> > >> >> >> > > >> >> >> > Oops, sorry I forgot that this part of change was not merged to > >> >> >> > stable/8. I've attached a minimal patch which would be cleanly > >> >> >> > applied to stable/8. > >> >> >> > >> >> >> Wasn't the attached diff3 already included in diff2? Seems to me the > >> >> >> wrong file was attached this time. Please advise. > >> >> > > >> >> > diff2 is subset of diff3 but it can be merged to stable/8 and > >> >> > stable/7. Probably diff2 may have better chance to fully > >> >> > reinitialize PHY but let's see whether diff3 also makes difference > >> >> > on your box. > >> >> > So back out any changes and apply diff3. > >> >> > >> >> I'm sorry, this if_nfereg.h patch is not enough. Boot failure frequency > >> >> is just the same. I guess I should consider migrating to 9-stable. The > >> >> problem with 9-stable is that most of the time it does not build :-( > >> >> > >> >> Thanks for your efforts. Enoch. > >> > > >> > Here is updated patch for stable/8. Let me know whether it makes > >> > any difference. > >> > >> Sorry, the diff4 patch compiled but made no difference (using static > >> IP). On first boot the "w/o leading ethernet header" problem showed > >> up. Can you generate diagnostic messages that I can collect for you from > >> dmesg or messages? > >> > > > > Due to lack of documentation, I also don't know which registers > > should I poke at this moment. This reminds me old experimental > > patch which tried to address reset/DMA issues. > > Would you try that? Note, I don't have access to nfe(4) so > > the patch was not tested at all. > > You can find the patch at the following URL. > > http://people.freebsd.org/~yongari/nfe/nfe.reset.diff > > I will try it in the next few days. Ok, thanks. > I saw that you are contributing to the [re] driver as well. This PCI > card > that I plugged (to replace [nfe]) in 8-stable is losing its Ethernet > connection to the router every few hours. Recovery is only possible > through a reboot. What info do you suggest to collect before opening a > new thread. Thanks. > It's the same as nfe(4). Include both dmesg output(re(4), rgephy(4) only) and any messages printed by re(4). If you know how to trigger the issue, share that information too. From owner-freebsd-net@FreeBSD.ORG Thu Apr 12 11:22:17 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 967C81065670; Thu, 12 Apr 2012 11:22:17 +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 1524F8FC16; Thu, 12 Apr 2012 11:22:16 +0000 (UTC) Received: from c211-30-171-136.carlnfd1.nsw.optusnet.com.au (c211-30-171-136.carlnfd1.nsw.optusnet.com.au [211.30.171.136]) by mail01.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q3CBM2Rl020290 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Apr 2012 21:22:04 +1000 Date: Thu, 12 Apr 2012 21:22:02 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Luigi Rizzo In-Reply-To: <20120412075430.GA71623@onelab2.iet.unipi.it> Message-ID: <20120412193745.O2350@besplex.bde.org> References: <20120410225257.GB53350@onelab2.iet.unipi.it> <4F84B6DB.5040904@freebsd.org> <20120410230500.GA22829@pit.databus.com> <20120410233211.GA53829@onelab2.iet.unipi.it> <4F855E5E.5000107@freebsd.org> <20120411110036.GA60031@onelab2.iet.unipi.it> <4F857631.8040309@freebsd.org> <20120411131920.GA61027@onelab2.iet.unipi.it> <20120412112401.Q981@besplex.bde.org> <20120412075430.GA71623@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Barney Wolff , Andre Oppermann , current@freebsd.org, net@freebsd.org Subject: Re: strange ping response times... 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, 12 Apr 2012 11:22:17 -0000 On Thu, 12 Apr 2012, Luigi Rizzo wrote: > On Thu, Apr 12, 2012 at 01:18:59PM +1000, Bruce Evans wrote: >> On Wed, 11 Apr 2012, Luigi Rizzo wrote: >> >>> On Wed, Apr 11, 2012 at 02:16:49PM +0200, Andre Oppermann wrote: > ... >>> ping takes a timestamp in userspace before trying to transmit >>> the packet, and then the timestamp for the received packet >>> is recorded in the kernel (in the interrupt or netisr thread >>> i believe -- anyways, not in userspace). >> >> No, all timestamps recorded used by ping are recorded in userland. > > Bruce, look at the code in ping.c -- SO_TIMESTAMP is defined, > so the program does (successfully) a > > setsockopt(s, SOL_SOCKET, SO_TIMESTAMP, &on, sizeof(on)); > > and then (verified that at runtime the code follows this path) > ... Indeed it does. This accounts for the previously unaccounted for binuptime call in the kernel. This is part of fenner's change (perhaps the most important part) to put the timestamping closer to the actual i/o, so that the RTT doesn't count setup overheads. Timestamping still works when SO_TIMESTAMP is undefed (after fixing the ifdefs on it). Not using it costs only 1 more gettimeofday() call in ping, but it increases my apparent RTT from 7-8 usec to 10-11 usec. 3 extra usec seems a lot for the overhead. I found that ping -f saves 1 gettimeofday() call per packet, and my version saves another 1. -current ping -q localhost: 4 my ping -q localhost: 3 -current ping -fq localhost: 3 my ping -fq localhost: 2 1 gettimeofday() call is needed for putting a timestamp in the output packet. Apparently, this is not well integrated with the bookkeeping for select(), and up to 3 more gettimeofday() calls are used. select() timeouts only have 1/HZ granulatrity, so the gettimeofday() calls to set them up could use clock_gettime() with CLOCK_REALTIME_FAST_N_BROKEN, but this would be a bogus optimization since most of the overhead is in the syscall provided the timecounter hardware is not slow (it takes 9-80 cycles to read TSC timecounter hardware and 600-800 cycles for clock_gettime() with a TSC timecounter). I just noticed Note that CLOCK_MONOTONIC cannot be used for the timestamp in the output packet if SO_TIMESTAMP is used for the timestamp in the input packet, since SO_TIMESTAMP uses CLOCK_REALTIME for historical reasons. There are 2 select()s per packet. Perhaps the number of gettimeofday()s can be reduced to 1 per packet in most cases (get one for the output packet and use it for both select()s). With my version the truss trace for ping localhost is: % 64 bytes from 127.0.0.1: icmp_seq=6 ttl=64 time=0.473 ms % write(1,0x80d4000,57) = 57 (0x39) % gettimeofday({1334226305 409249},0x0) = 0 (0x0) Need this for the next select(). There is a ~1 second pause here. % select(4,{3},0x0,0x0,{0 989607}) = 0 (0x0) Truss doesn't show this until select() returns ~1 second later. The gettimeofday() call was needed because we don't simply use a 1 second pause, but adjust for overheads. My version uses a fancier adjustment. % gettimeofday({1334226306 408632},0x0) = 0 (0x0) We need this accurately to put in the packet. But all the other timestamps can be derived from this for the non-flood case. We can just try to send every `interval' and adjust the timeouts a bit when we see that we get here a bit early or late, and when we get here more than a bit early or late we can either recalibrate or adjust by more. Note that this gettimeofday() returned 1.0 - 0.000617 seconds after the previous one, although we asked for a timeout of ~1/HZ = 0.0010000 seconds. Select timeouts have a large granularity and we expect errors of O(1/HZ) and mostly compensate for them. The drift without compensation would be 1% with HZ = 100 and -i 1.0, and much larger with -i . My version compensates more accurately than -current. % sendto(0x3,0x80b8d34,0,0x0,{ AF_INET 127.0.0.1:0 },0x10) = 64 (0x40) % gettimeofday({1334226306 408831},0x0) = 0 (0x0) % select(4,{3},0x0,0x0,{0 990025}) = 1 (0x1) % recvmsg(0x3,0xbfbfe8c0,0x0) = 84 (0x54) % gettimeofday({1334226306 409104},0x0) = 0 (0x0) I don't know what this is for. We got a timestamp in the returned packet, and use it. Since this timestamp has microsecond resolution and select() only has 1/Hz resolution. this timestamp should be more than good enough for sleeping for the interval. % 64 bytes from 127.0.0.1: icmp_seq=7 ttl=64 time=0.472 ms % write(1,0x80d4000,57) = 57 (0x39) Next packet: % gettimeofday({1334226306 409279},0x0) = 0 (0x0) % ... But select() timeouts are not needed at all. Versions before fenner's changes used a select() timeout for flood pings. alarm() was used to generate other timeouts. The alarm() code was not very good. It did a lot of work in the signal handler to set up the next alarm (1 call to signal() and 1 call to alarm()), and it did unsafe work in the signal handler. It was not careful about drift. These overheads and the drift can can be avoided using a periodic itimer. Ideally, expiry of each period would just cause select() to return, but AFAIK there is no way to make select() return without catching the signal, and even a null signal catcher has a lot of overhead. It is unclear if the overhead for a null signal catcher is larger than that for select timeouts. The current overhead for select timeouts is 2 or 3 gettimeofday() calls in ping and 1 or 2 getmicrouptime() calls in each select(). These take at least 1 usec on my Athlon64 2GHz UP, and signal handling also takes about 1 usec in old versions of FreeBSD, but now takes more like 1.5 usec. SO_TIMESTAMP seems to have been invented in 1996 by fenner to make ping work better. (The log messages seem to only mention fixing it but I can't find it in earlier code.) There seems to be no way to timestamp outgoing packets properly in the kernel. ICMP_TIMESTAMP might give milliseconds resolution for ping, but FreeBSD ping has given microseconds resulotion since 1993. Bruce From owner-freebsd-net@FreeBSD.ORG Thu Apr 12 18:38:54 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7564B106564A; Thu, 12 Apr 2012 18:38:54 +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 0D6798FC16; Thu, 12 Apr 2012 18:38:53 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q3CIcoOe059159; Thu, 12 Apr 2012 21:38:50 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q3CIcn26082486; Thu, 12 Apr 2012 21:38:49 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q3CIcnxS082485; Thu, 12 Apr 2012 21:38:49 +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: Thu, 12 Apr 2012 21:38:49 +0300 From: Konstantin Belousov To: John Baldwin Message-ID: <20120412183849.GA2358@deviant.kiev.zoral.com.ua> References: <20120407133715.GU2358@deviant.kiev.zoral.com.ua> <20120408051125.GA2358@deviant.kiev.zoral.com.ua> <201204091219.39580.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HcXGYAkJUr6H84bb" Content-Disposition: inline In-Reply-To: <201204091219.39580.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: jfv@freebsd.org, Jack Vogel , net@freebsd.org Subject: Re: 82574L hangs (with r233708 e1000 driver). X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 18:38:54 -0000 --HcXGYAkJUr6H84bb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 09, 2012 at 12:19:39PM -0400, John Baldwin wrote: > On Sunday, April 08, 2012 1:11:25 am Konstantin Belousov wrote: > > On Sat, Apr 07, 2012 at 04:22:07PM -0700, Jack Vogel wrote: > > > Make sure you have any firmware up to the latest available, if that d= oesn't > > > help > > > let me know and I'll check internally to see if there are any outstan= ding > > > issues > > > in shared code, that will be after the weekend. > >=20 > > I had BIOS rev. 151, after you hint I found rev. 154 on the site. > > Now BIOS reports itself as MTCDT10N.86A.0154.2012.0323.1601, > > March 23. > >=20 > > Unfortunately, upgrade did not changed anything in regard of hanging > > interface. >=20 > Does reverting 233708 make any difference? Have you tried futzing around= with > kgdb when it is hung to see what state the device is in (software state at > least)? It does, in a sense that without r233708 the interface becomes stuck almost immediately. I just upgraded to the e1000@r234154, which does not change much. I fiddled with the adapter state after the hang in kgdb more, and I noted something interesting. Apparently, tx works. When I ping the remote host from my suffering atom machine, remote host sees the packet. Also remote machine sees some udp traffic originating from the tom, like ntp queries. And, on receive, the atom board does receive interrupts, em0:rx 0 counter in vmstat -i increases. Even more fun, the sysctl dev.em.0.debug shows increasing hw rdh (as I understand, this is hardware 'last received' packet pointer for rx ring). So I looked at the packet descriptor at hw rdt index, and there I see (kgdb) p/x ((struct adapter *)0xffffff80010e4000)->rx_rings->rx_base[78] $11 =3D {buffer_addr =3D 0x12a128800, length =3D 0x5ea, csum =3D 0x3c2b, st= atus =3D 0x0,=20 errors =3D 0x0, special =3D 0x0} Apparently, the Descriptor Done bit is clear, so the em_rxeof() function breaks from the loop, not consuming the current packet. Also, it returns false due to DD bit clear. This prevents em_msix_rx() from scheduling taskqueue for processing. So apparent cause for the hang is missing DD bit in descriptor. I am not sure isn't all this is obvious for anybody who knows em internals, and were to go from there. --HcXGYAkJUr6H84bb Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk+HITkACgkQC3+MBN1Mb4h0XgCgrZCPC048gtwFEJIwmpwGFpvQ YxoAoNfy+YfHvHY4CDJOmOmmhI7Ifh7m =yI+Q -----END PGP SIGNATURE----- --HcXGYAkJUr6H84bb-- From owner-freebsd-net@FreeBSD.ORG Thu Apr 12 19:40:28 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9DEE5106566C; Thu, 12 Apr 2012 19:40:28 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id D36AA8FC08; Thu, 12 Apr 2012 19:40:27 +0000 (UTC) Received: by wgbds12 with SMTP id ds12so2354186wgb.31 for ; Thu, 12 Apr 2012 12:40:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=E0ezQBGYw/Ge+Gze0NxZE3LNKsqL1NGRNeiqJ+ztQC8=; b=KgRPu+TSl5gzQU+oOno5LEfqEboi7FPaDBZUiaRglEA9AWaMZ4EUkX3ODWzdabAtvD kFDgjpStT5mMxKTThJiQUr1NyCCQhuOKZU9qVJnSc+lwZHSxbm3vqWz2Stawz8U7Viy5 k2RbuMAl31S+QzKjaPOyG5csHerKbd6coKiHnrfaO7ujbpR0Uj5oNw07Q0zL6gJTJHey NCmEx0idcdTI94l96qM1gsFYPNznMC4PaA3VYa4+p2lMYqPv6sj0hcuYiIoUfN6ZrncJ oJDHVWl+IQVvP8cUM7JmgM/rYJNKubqs9lNyIiO4qcjPbSrb1ZjPRcJqkpE0WqpZ4oWg OolQ== MIME-Version: 1.0 Received: by 10.180.88.199 with SMTP id bi7mr8666639wib.12.1334259627043; Thu, 12 Apr 2012 12:40:27 -0700 (PDT) Received: by 10.180.104.98 with HTTP; Thu, 12 Apr 2012 12:40:27 -0700 (PDT) In-Reply-To: <20120412183849.GA2358@deviant.kiev.zoral.com.ua> References: <20120407133715.GU2358@deviant.kiev.zoral.com.ua> <20120408051125.GA2358@deviant.kiev.zoral.com.ua> <201204091219.39580.jhb@freebsd.org> <20120412183849.GA2358@deviant.kiev.zoral.com.ua> Date: Thu, 12 Apr 2012 15:40:27 -0400 Message-ID: From: Ryan Stone To: Konstantin Belousov Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: jfv@freebsd.org, Jack Vogel , John Baldwin , net@freebsd.org Subject: Re: 82574L hangs (with r233708 e1000 driver). X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 19:40:28 -0000 On Thu, Apr 12, 2012 at 2:38 PM, Konstantin Belousov wrote: > And, on receive, the atom board does receive interrupts, em0:rx 0 counter > in vmstat -i increases. Even more fun, the sysctl dev.em.0.debug > shows increasing hw rdh (as I understand, this is hardware 'last > received' packet pointer for rx ring). So I looked at the packet > descriptor at hw rdt index, and there I see > (kgdb) p/x ((struct adapter *)0xffffff80010e4000)->rx_rings->rx_base[78] > $11 =3D {buffer_addr =3D 0x12a128800, length =3D 0x5ea, csum =3D 0x3c2b, = status =3D 0x0, > =A0errors =3D 0x0, special =3D 0x0} This looks like a buffer address, not a written-back descriptor(0x12a128800 being aligned to a 2048 byte boundary is a big clue). Is it easy to check the mbuf in rx_rings->rx_buffers[78].m_head and see whether the buffer in the mbuf there has that physical address? If that is a buffer address then the driver must be updating descriptors in rx_base that are owned by hardware, or somehow forgetting to update rdt and rxr->next_to_check. From owner-freebsd-net@FreeBSD.ORG Thu Apr 12 23:54:06 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 537831065670 for ; Thu, 12 Apr 2012 23:54:06 +0000 (UTC) (envelope-from andy@fud.org.nz) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 279E68FC14 for ; Thu, 12 Apr 2012 23:54:06 +0000 (UTC) Received: by pbcwz17 with SMTP id wz17so3209618pbc.13 for ; Thu, 12 Apr 2012 16:53:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type:x-gm-message-state; bh=1MbdCzXGrfqFXK95taioyMWTWWXk9OSRXIljRWVW89M=; b=U/yyqav6CfsBsfWh6Wneg2i1JYKk42kD6l4LyjOeFsspPCvZwqTt3YDI4vH+tuwX9C O+wcaGrUSe67FMDM3kwHa1vJaHjTbNDTMJ2qh0M7055oTUzTJZPwkmT/5FRdzjlmBrAf pHdew5o4Bl+4sRg1DXvBawMgfXWIyCWQ1ri6/WGfv+ZTTwSjv68pVTbZH6il/9fH51aR CWa2lwnIk+k27DlOFkkVEz+Bvo6srM4o2yAAI36cPDwo1RbZirBSvSdIX6AY0YU7iqIq wmYIHMdQ7W0WNRc7NmZxMdmpxTdFc7oIsoTfNHtwb4NIB75hCAqfsmfIE0V/dapNIknB 6jRg== MIME-Version: 1.0 Received: by 10.68.195.103 with SMTP id id7mr973777pbc.98.1334274839867; Thu, 12 Apr 2012 16:53:59 -0700 (PDT) Sender: andy@fud.org.nz Received: by 10.68.33.230 with HTTP; Thu, 12 Apr 2012 16:53:59 -0700 (PDT) Date: Fri, 13 Apr 2012 11:53:59 +1200 X-Google-Sender-Auth: Oh9Q4EOxQru067ZgUR14G0GsfSs Message-ID: From: Andrew Thompson To: freebsd-net Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQl2ljFWUkwfu8m9Ivez0/p2LMNJWvdieYtQvog9MuLgGeyqC5HzcTsQxkLiypaivNS4pAga Subject: getifaddrs & ipv6 scope 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, 12 Apr 2012 23:54:06 -0000 Hi, I have noticed that getifaddrs() does not have sin6_scope_id set to the interface id for link local addresses on AF_INET6 types. Running the following program gives different results on Linux FreeBSD: dev: bge0 address: scope 0 dev: xl0 address: scope 0 dev: lo0 address: <::1> scope 0 dev: lo0 address: scope 0 Linux: dev: lo address: <::1> scope 0 dev: eth1 address: <2404:130:0:1000:204:75ff:febc:b8f0> scope 0 dev: eth1 address: scope 2 dev: eth0 address: scope 3 Should FreeBSD be setting sin6_scope_id? Andrew ---- #include #include #include #include #include #include #include #include #include #include int main(int argc, char *argv[]) { struct ifaddrs *ifaddr, *ifa; char host[NI_MAXHOST]; int rc; if (getifaddrs(&ifaddr) == -1) { perror("getifaddrs"); exit(EXIT_FAILURE); } for (ifa = ifaddr; ifa != NULL; ifa = ifa->ifa_next) { struct sockaddr_in6 *in6 = (struct sockaddr_in6 *)ifa->ifa_addr; if (ifa->ifa_addr == NULL) continue; if (ifa->ifa_addr->sa_family != AF_INET6) continue; rc = getnameinfo(ifa->ifa_addr, sizeof(struct sockaddr_in6), host, NI_MAXHOST, NULL, 0, NI_NUMERICHOST); if (rc != 0) { printf("getnameinfo() failed: %s\n", gai_strerror(rc)); exit(EXIT_FAILURE); } printf("dev: %-8s address: <%s> scope %d\n", ifa->ifa_name, host, in6->sin6_scope_id); } freeifaddrs(ifaddr); exit(EXIT_SUCCESS); } From owner-freebsd-net@FreeBSD.ORG Fri Apr 13 06:40:12 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 40FBF106566B for ; Fri, 13 Apr 2012 06:40:12 +0000 (UTC) (envelope-from chinaitvc@gmail.com) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) by mx1.freebsd.org (Postfix) with ESMTP id 19A7E8FC15 for ; Fri, 13 Apr 2012 06:40:12 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1SIaB1-00025y-PN for freebsd-net@freebsd.org; Thu, 12 Apr 2012 23:40:11 -0700 Date: Thu, 12 Apr 2012 23:40:11 -0700 (PDT) From: hahacc To: freebsd-net@freebsd.org Message-ID: <1334299211780-5637490.post@n5.nabble.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Intel 82574L interface wedging - em7.3.2/8.2-STABLE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 06:40:12 -0000 Just for guys who may arrive here after searching: 1.there's kernel bug in intel 82574L e1000e driver on centos 6(MSI/MSI-X interrupts issue), we can resolve this by install kmod-e1000e package from ELrepo.org and later add pcie_aspm=off e1000e.IntMode=1,1 e1000e.InterruptThrottleRate=10000,10000 acpi=off to kernel parameters. You can read more info [URL="http://www.doxer.org/learn-linux/resolved-intel-e1000e-driver-bug-on-82574l-ethernet-controller-causing-network-blipping/"]Intel e1000e driver bug on 82574L Ethernet controller causing network blipping[/URL]. 2.For the high Tx traffic, this was caused by port 53 dns flooding attack. I've resolved this by writing some iptable rules. More info here: [URL="http://www.doxer.org/learn-linux/resolved-port-53-dns-flooding-attack/"]port 53 dns flooding attack[/URL] -- View this message in context: http://freebsd.1045724.n5.nabble.com/Intel-82574L-interface-wedging-em7-3-2-8-2-STABLE-tp5529028p5637490.html Sent from the freebsd-net mailing list archive at Nabble.com. From owner-freebsd-net@FreeBSD.ORG Fri Apr 13 06:41:44 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7B3DE106566B for ; Fri, 13 Apr 2012 06:41:44 +0000 (UTC) (envelope-from Bredehorn@gmx.de) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by mx1.freebsd.org (Postfix) with SMTP id CC1018FC1C for ; Fri, 13 Apr 2012 06:41:43 +0000 (UTC) Received: (qmail 17743 invoked by uid 0); 13 Apr 2012 06:41:42 -0000 Received: from 93.159.253.120 by rms-de009.v300.gmx.net with HTTP Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" Date: Fri, 13 Apr 2012 08:41:41 +0200 From: "Rainer Bredehorn" Message-ID: <20120413064142.10640@gmx.net> MIME-Version: 1.0 To: freebsd-net@freebsd.org X-Authenticated: #168415 X-Flags: 0001 X-Mailer: GMX.net Web Mailer x-registered: 0 X-GMX-UID: 8a/1b0xleSEqVr7yaXQhtZZ+IGRvb4CS Subject: Re: getifaddrs & ipv6 scope 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, 13 Apr 2012 06:41:44 -0000 Hi! > I have noticed that getifaddrs() does not have sin6_scope_id set to > the interface id for link local addresses on AF_INET6 types. Running > the following program gives different results on Linux ifconfig shows the scopeid according to the interface: inet6 fe80::208:9bff:fe13:784e%fxp1 prefixlen 64 scopeid 0x2 Are you talking about the scope value of an multicast address or the scopeid for link local addresses? Best regards, Rainer. From owner-freebsd-net@FreeBSD.ORG Fri Apr 13 08:01:40 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2066A106566C for ; Fri, 13 Apr 2012 08:01:40 +0000 (UTC) (envelope-from andy@fud.org.nz) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by mx1.freebsd.org (Postfix) with ESMTP id E72598FC16 for ; Fri, 13 Apr 2012 08:01:39 +0000 (UTC) Received: by dadz14 with SMTP id z14so11777887dad.17 for ; Fri, 13 Apr 2012 01:01:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=3OAMiAOKN/pFIxCvzrH2oKS+9STqLUuuwxsRo4nyygM=; b=P6yheyIwwRtq3qDi8SnTuLlkj+LhBJEmD52FQJtFNtu5VRbycF2Y317m/n1iuB6Rr2 mx1+cuY/xbZQjQptOTYqFaVKyC29ty7GoQmMrVsoA9lmP1fz9gzxhCNsSn3/83IoItnP N3rqVV7twcss5mCgHtzCt/QxEitG7aPBd5rqJSpZYPh9MIzHxS3Q/+fWDGvmIssRH3iX a2qM3m2FM5WvathUmocoI8RtQaToyZidX+Qli723+7jom1nAKJuKYSR4pRGt4CfYCctN M7jItMiUgR6jtGxrNXrmn9ul7tK3npelAwymK6Fs9wKnzSlu3B3G+A5+wEl14XZgEpZe Re0Q== MIME-Version: 1.0 Received: by 10.68.201.73 with SMTP id jy9mr2824429pbc.35.1334304099239; Fri, 13 Apr 2012 01:01:39 -0700 (PDT) Sender: andy@fud.org.nz Received: by 10.68.33.230 with HTTP; Fri, 13 Apr 2012 01:01:39 -0700 (PDT) In-Reply-To: <20120413064142.10640@gmx.net> References: <20120413064142.10640@gmx.net> Date: Fri, 13 Apr 2012 20:01:39 +1200 X-Google-Sender-Auth: 4s2RnLsCbeQJesYmcLHmdGHzpH0 Message-ID: From: Andrew Thompson To: Rainer Bredehorn Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmlScgRX2oqx7EMpV/Eafj7n32QIvLvRKXpGWGNZdfuWzONNM/Eenkry8HlRes9tX3oZilm Cc: freebsd-net@freebsd.org Subject: Re: getifaddrs & ipv6 scope 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, 13 Apr 2012 08:01:40 -0000 On 13 April 2012 18:41, Rainer Bredehorn wrote: > Hi! > >> I have noticed that getifaddrs() does not have sin6_scope_id set to >> the interface id for link local addresses on AF_INET6 types. Running >> the following program gives different results on Linux > > ifconfig shows the scopeid according to the interface: > > inet6 fe80::208:9bff:fe13:784e%fxp1 prefixlen 64 scopeid 0x2 > > Are you talking about the scope value of an multicast address or > the scopeid for link local addresses? I am talking about the scopeid for link local addresses which (as far as I understand) is the interface index. Andrew From owner-freebsd-net@FreeBSD.ORG Fri Apr 13 08:17:21 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id ECE5F106564A; Fri, 13 Apr 2012 08:17:21 +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 6B3128FC08; Fri, 13 Apr 2012 08:17:21 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q3D8HGqU031596; Fri, 13 Apr 2012 11:17:16 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q3D8HFQw086873; Fri, 13 Apr 2012 11:17:15 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q3D8HFX0086872; Fri, 13 Apr 2012 11:17:15 +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: Fri, 13 Apr 2012 11:17:15 +0300 From: Konstantin Belousov To: Ryan Stone Message-ID: <20120413081715.GC2358@deviant.kiev.zoral.com.ua> References: <20120407133715.GU2358@deviant.kiev.zoral.com.ua> <20120408051125.GA2358@deviant.kiev.zoral.com.ua> <201204091219.39580.jhb@freebsd.org> <20120412183849.GA2358@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="P2QgR0JrZwTaWvmb" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: jfv@freebsd.org, Jack Vogel , John Baldwin , net@freebsd.org Subject: Re: 82574L hangs (with r233708 e1000 driver). X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 08:17:22 -0000 --P2QgR0JrZwTaWvmb Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Apr 12, 2012 at 03:40:27PM -0400, Ryan Stone wrote: > On Thu, Apr 12, 2012 at 2:38 PM, Konstantin Belousov > wrote: > > And, on receive, the atom board does receive interrupts, em0:rx 0 count= er > > in vmstat -i increases. Even more fun, the sysctl dev.em.0.debug > > shows increasing hw rdh (as I understand, this is hardware 'last > > received' packet pointer for rx ring). So I looked at the packet > > descriptor at hw rdt index, and there I see > > (kgdb) p/x ((struct adapter *)0xffffff80010e4000)->rx_rings->rx_base[78] > > $11 =3D {buffer_addr =3D 0x12a128800, length =3D 0x5ea, csum =3D 0x3c2b= , status =3D 0x0, > > =9Aerrors =3D 0x0, special =3D 0x0} >=20 > This looks like a buffer address, not a written-back What do you reference by 'This' ? 0x12a128800 is indeed buffer address, because it is the content of the first eight bytes of the descriptor. The next descriptor in the ring had the status 0x63, which is quite reasonable value for filled descriptor. > descriptor(0x12a128800 being aligned to a 2048 byte boundary is a big > clue). Is it easy to check the mbuf in > rx_rings->rx_buffers[78].m_head and see whether the buffer in the mbuf > there has that physical address? Probably so, I will recheck later today. >=20 > If that is a buffer address then the driver must be updating > descriptors in rx_base that are owned by hardware, or somehow > forgetting to update rdt and rxr->next_to_check. Yes, there is a bug somewhere. On the other hand, it is very specific to exactly this model and might be a revision, because I have tons of em interfaces working flawlessly with the same version of the driver. --P2QgR0JrZwTaWvmb Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk+H4QsACgkQC3+MBN1Mb4jlkwCfZpSndcS7LsiWMwAey9lV3z18 EP8An2Rb4Gm3cUL/fFqr7dDFrzI1cdPe =FeLU -----END PGP SIGNATURE----- --P2QgR0JrZwTaWvmb-- From owner-freebsd-net@FreeBSD.ORG Fri Apr 13 16:46:19 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E536D106564A; Fri, 13 Apr 2012 16:46:19 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id B8BD08FC17; Fri, 13 Apr 2012 16:46:19 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q3DGkJQ2096721; Fri, 13 Apr 2012 16:46:19 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q3DGkJIN096717; Fri, 13 Apr 2012 16:46:19 GMT (envelope-from linimon) Date: Fri, 13 Apr 2012 16:46:19 GMT Message-Id: <201204131646.q3DGkJIN096717@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/166909: [alc] NIC alc(4) does not support 1000baseTX 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, 13 Apr 2012 16:46:20 -0000 Old Synopsis: NIC alc (4) does not support 1000baseTX New Synopsis: [alc] NIC alc(4) does not support 1000baseTX Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Fri Apr 13 16:45:55 UTC 2012 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=166909 From owner-freebsd-net@FreeBSD.ORG Fri Apr 13 18:03:52 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4F6BF1065849; Fri, 13 Apr 2012 18:03:52 +0000 (UTC) (envelope-from ume@mahoroba.org) Received: from mail.mahoroba.org (ent.mahoroba.org [IPv6:2001:2f0:104:8010::1]) by mx1.freebsd.org (Postfix) with ESMTP id 21E778FC17; Fri, 13 Apr 2012 18:03:50 +0000 (UTC) Received: from yuga.mahoroba.org (ume@yuga.mahoroba.org [IPv6:2001:2f0:104:8010:7258:12ff:fe22:d94b]) (user=ume mech=DIGEST-MD5 bits=0) by mail.mahoroba.org (8.14.5/8.14.5) with ESMTP/inet6 id q3DI3ao6098811 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 14 Apr 2012 03:03:40 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Sat, 14 Apr 2012 03:03:36 +0900 Message-ID: From: Hajimu UMEMOTO To: Andrew Thompson In-Reply-To: References: <20120413064142.10640@gmx.net> User-Agent: xcite1.60> Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-2022-JP-2?B?R29qGyQoRCtXGyhC?=) APEL/10.8 Emacs/23.4 (i386-portbld-freebsd9.0) MULE/6.0 (HANACHIRUSATO) X-Operating-System: FreeBSD 9.0-STABLE X-PGP-Key: http://www.imasy.or.jp/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE Organization: Internet Mutual Aid Society, YOKOHAMA MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: multipart/mixed; boundary="Multipart_Sat_Apr_14_03:03:35_2012-1" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (mail.mahoroba.org [IPv6:2001:2f0:104:8010::1]); Sat, 14 Apr 2012 03:03:40 +0900 (JST) X-Virus-Scanned: clamav-milter 0.97.4 at asuka.mahoroba.org X-Virus-Status: Clean X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on asuka.mahoroba.org Cc: freebsd-net@FreeBSD.org, Rainer Bredehorn Subject: Re: getifaddrs & ipv6 scope 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, 13 Apr 2012 18:03:52 -0000 --Multipart_Sat_Apr_14_03:03:35_2012-1 Content-Type: text/plain; charset=US-ASCII Hi, >>>>> On Fri, 13 Apr 2012 20:01:39 +1200 >>>>> Andrew Thompson said: thompsa> On 13 April 2012 18:41, Rainer Bredehorn wrote: > Hi! > >> I have noticed that getifaddrs() does not have sin6_scope_id set to >> the interface id for link local addresses on AF_INET6 types. Running >> the following program gives different results on Linux > > ifconfig shows the scopeid according to the interface: > > inet6 fe80::208:9bff:fe13:784e%fxp1 prefixlen 64 scopeid 0x2 > > Are you talking about the scope value of an multicast address or > the scopeid for link local addresses? thompsa> I am talking about the scopeid for link local addresses which (as far thompsa> as I understand) is the interface index. The issue you mentioned comes from an implementation decision of the KAME IPv6 stack. The attached patch should address it. However, it may break the applications which expect that getifaddrs() returns a link-local address with KAME's embeded scopeid representation. I'm not sure there are such applications, for now. Sincerely, --Multipart_Sat_Apr_14_03:03:35_2012-1 Content-Type: text/x-patch; type=patch; charset=US-ASCII Content-Disposition: attachment; filename="getifaddrs.c-scopeid.diff" Content-Transfer-Encoding: 7bit Index: lib/libc/net/getifaddrs.c diff -u -p lib/libc/net/getifaddrs.c.orig lib/libc/net/getifaddrs.c --- lib/libc/net/getifaddrs.c.orig 2011-09-23 09:51:37.000000000 +0900 +++ lib/libc/net/getifaddrs.c 2012-04-14 02:49:11.000000000 +0900 @@ -43,6 +43,7 @@ __FBSDID("$FreeBSD: src/lib/libc/net/get #include #include #endif +#include #include #include @@ -87,6 +88,8 @@ __FBSDID("$FreeBSD: src/lib/libc/net/get #define MAX_SYSCTL_TRY 5 +static void in6_fillscopeid(struct sockaddr_in6 *); + int getifaddrs(struct ifaddrs **pif) { @@ -341,6 +344,8 @@ getifaddrs(struct ifaddrs **pif) (struct sockaddr *)(void *)data; memcpy(data, p, len); data += len; + if (ift->ifa_addr->sa_family == AF_INET6) + in6_fillscopeid((struct sockaddr_in6 *)ift->ifa_addr); break; case RTAX_NETMASK: @@ -416,3 +421,15 @@ freeifaddrs(struct ifaddrs *ifp) free(ifp); } + +static void +in6_fillscopeid(struct sockaddr_in6 *sin6) +{ +#if defined(__KAME__) + if (IN6_IS_ADDR_LINKLOCAL(&sin6->sin6_addr)) { + sin6->sin6_scope_id = + ntohs(*(u_int16_t *)&sin6->sin6_addr.s6_addr[2]); + sin6->sin6_addr.s6_addr[2] = sin6->sin6_addr.s6_addr[3] = 0; + } +#endif +} --Multipart_Sat_Apr_14_03:03:35_2012-1 Content-Type: text/plain; charset=US-ASCII -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ --Multipart_Sat_Apr_14_03:03:35_2012-1-- From owner-freebsd-net@FreeBSD.ORG Sat Apr 14 16:41:56 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 19499106564A; Sat, 14 Apr 2012 16:41:56 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) by mx1.freebsd.org (Postfix) with ESMTP id BE88B8FC08; Sat, 14 Apr 2012 16:41:55 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id D94E725D3860; Sat, 14 Apr 2012 16:41:54 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 1378DBE4D54; Sat, 14 Apr 2012 16:41:54 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id JV3VE4fufz1T; Sat, 14 Apr 2012 16:41:53 +0000 (UTC) Received: from orange-en1.sbone.de (orange-en1.sbone.de [IPv6:fde9:577b:c1a9:31:cabc:c8ff:fecf:e8e3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id F0E18BE4D53; Sat, 14 Apr 2012 16:41:52 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Bjoern A. Zeeb" In-Reply-To: Date: Sat, 14 Apr 2012 16:41:52 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <7153D609-0E71-435A-B076-27BD6C3AEA04@lists.zabbadoz.net> References: <20120413064142.10640@gmx.net> To: Hajimu UMEMOTO X-Mailer: Apple Mail (2.1084) Cc: freebsd-net@FreeBSD.org, Rainer Bredehorn , Andrew Thompson Subject: Re: getifaddrs & ipv6 scope 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, 14 Apr 2012 16:41:56 -0000 On 13. Apr 2012, at 18:03 , Hajimu UMEMOTO wrote: > Hi, >=20 >>>>>> On Fri, 13 Apr 2012 20:01:39 +1200 >>>>>> Andrew Thompson said: >=20 > thompsa> On 13 April 2012 18:41, Rainer Bredehorn = wrote: >> Hi! >>=20 >>> I have noticed that getifaddrs() does not have sin6_scope_id set to >>> the interface id for link local addresses on AF_INET6 types. Running >>> the following program gives different results on Linux >>=20 >> ifconfig shows the scopeid according to the interface: >>=20 >> inet6 fe80::208:9bff:fe13:784e%fxp1 prefixlen 64 scopeid 0x2 >>=20 >> Are you talking about the scope value of an multicast address or >> the scopeid for link local addresses? >=20 > thompsa> I am talking about the scopeid for link local addresses which = (as far > thompsa> as I understand) is the interface index. >=20 > The issue you mentioned comes from an implementation decision of the > KAME IPv6 stack. > The attached patch should address it. However, it may break the > applications which expect that getifaddrs() returns a link-local > address with KAME's embeded scopeid representation. I'm not sure > there are such applications, for now. There should be none. If we have some we should fix them. I wonder if = this should actually be done in the kernel to limit the scope of the = embedded scopeid to our kernel for now? Do we have other interfaces = (ignoring kvm) that export the embedded scopeid? /bz --=20 Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! From owner-freebsd-net@FreeBSD.ORG Sat Apr 14 18:20:54 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2DCFE1065672 for ; Sat, 14 Apr 2012 18:20:54 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell0.rawbw.com (shell0.rawbw.com [198.144.192.45]) by mx1.freebsd.org (Postfix) with ESMTP id 193E18FC08 for ; Sat, 14 Apr 2012 18:20:54 +0000 (UTC) Received: from eagle.yuri.org (stunnel@localhost [127.0.0.1]) (authenticated bits=0) by shell0.rawbw.com (8.14.4/8.14.4) with ESMTP id q3EIKrNr026687 for ; Sat, 14 Apr 2012 11:20:53 -0700 (PDT) (envelope-from yuri@rawbw.com) Message-ID: <4F89C005.2020304@rawbw.com> Date: Sat, 14 Apr 2012 11:20:53 -0700 From: Yuri User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.3) Gecko/20120316 Thunderbird/10.0.3 MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Why host transmit rate on 1Gb ethernet is only ~750Mbps ? 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, 14 Apr 2012 18:20:54 -0000 I am running some tests with gigabit switch between two 9.0 hosts using iperf. The best UDP transmit rate I am getting is 753 Mbits/sec with ~3-6% packet loss @1500 MTU @ 2.5GHz CPU, even though command 'iperf -c X.X.X.X -u -b 1000m' requests the full gigabit. I am trying to understand what exactly usually limits the speed with one way ethernet traffic and also what causes the packet loss. Is it the host's CPU or rather the need to make ~83K system calls in order to send 1Gb of UDP data at 1500 MTU? Is it the NIC or it's driver ('re' on source and 'em' on destination in my case)? Is it the router which is maybe too old? (Linksys EG008W, with tcpdump I made sure there is no ICMP traffic that is coming back from the router during the test). Why can't NIC send say 900 Mbps with MTU 1500 since the only overhead is ethernet+UDP headers which are ~120bytes out of 1500? Why packet loss occurs in such a simple network with just one switch and speeds of 75% of the maximum? How can I troubleshoot such situation and understand the reasons? Yuri From owner-freebsd-net@FreeBSD.ORG Sat Apr 14 19:11:25 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9B1F7106564A for ; Sat, 14 Apr 2012 19:11:25 +0000 (UTC) (envelope-from leschnik@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 57BBB8FC12 for ; Sat, 14 Apr 2012 19:11:25 +0000 (UTC) Received: by ggnk4 with SMTP id k4so2513438ggn.13 for ; Sat, 14 Apr 2012 12:11:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=xNSKk85jjpILTmPDdbL8/yReAcA1IPqIKTiIvv19zFY=; b=NIbV2dwGNPjcuK24fFBsFAHyyFyvKZUKL2v6uFUX08Vw3ECYSW6N5mIruA1EhlmMGQ BdlEiZ2g1lZ2LWC4vMZyRqGGPnxkN4iXcGZ4EbCC1L75pZ2FPwLvFJy9yhKszggT6TCE Ft18JDALnWvl2FSG4xTAVCl2xkOHRnY0fFa0kzc9/wALP3gWM+5x9qSqeTzjspaDoWAJ z51qsf9tlIbNHufn0PW/nLXjm/pXJmy9QyMtJPwcBvy5bRDQibUfkyXoWDyVgvAi+R2q KxkUU7rrnJK2VIMyffuNL64VzADn7kO+RjKvlxBgn+ytJvpKFzNVJ4w1drSPpnIxkxgx M95g== MIME-Version: 1.0 Received: by 10.101.8.37 with SMTP id l37mr1039661ani.49.1334430684676; Sat, 14 Apr 2012 12:11:24 -0700 (PDT) Received: by 10.100.210.4 with HTTP; Sat, 14 Apr 2012 12:11:24 -0700 (PDT) In-Reply-To: <4F89C005.2020304@rawbw.com> References: <4F89C005.2020304@rawbw.com> Date: Sun, 15 Apr 2012 05:11:24 +1000 Message-ID: From: Jason Leschnik To: Yuri Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: Why host transmit rate on 1Gb ethernet is only ~750Mbps ? 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, 14 Apr 2012 19:11:25 -0000 I would first start by doing a point-to-point link between your two end nodes to rule out your network gear as being the problem On Sun, Apr 15, 2012 at 4:20 AM, Yuri wrote: > I am running some tests with gigabit switch between two 9.0 hosts using > iperf. > The best UDP transmit rate I am getting is 753 Mbits/sec with ~3-6% packe= t > loss @1500 MTU @ 2.5GHz CPU, even though command 'iperf -c X.X.X.X -u -b > 1000m' requests the full gigabit. > > I am trying to understand what exactly usually limits the speed with one = way > ethernet traffic and also what causes the packet loss. > Is it the host's CPU or rather the need to make ~83K system calls in orde= r > to send 1Gb of UDP data at 1500 MTU? > Is it the NIC or it's driver ('re' on source and 'em' on destination in m= y > case)? > Is it the router which is maybe too old? (Linksys EG008W, with tcpdump I > made sure there is no ICMP traffic that is coming back from the router > during the test). > > Why can't NIC send say 900 Mbps with MTU 1500 since the only overhead is > ethernet+UDP headers which are ~120bytes out of 1500? > Why packet loss occurs in such a simple network with just one switch and > speeds of 75% of the maximum? > How can I troubleshoot such situation and understand the reasons? > > Yuri > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" --=20 Regards, Jason Leschnik. [m] 0432 35 4224 [w@] jason dot leschnik ansto dot gov dot au [U@]=A0jml974@uow.edu.au From owner-freebsd-net@FreeBSD.ORG Sat Apr 14 19:21:29 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2D170106566B for ; Sat, 14 Apr 2012 19:21:29 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell0.rawbw.com (shell0.rawbw.com [198.144.192.45]) by mx1.freebsd.org (Postfix) with ESMTP id F046E8FC12 for ; Sat, 14 Apr 2012 19:21:28 +0000 (UTC) Received: from eagle.yuri.org (stunnel@localhost [127.0.0.1]) (authenticated bits=0) by shell0.rawbw.com (8.14.4/8.14.4) with ESMTP id q3EJLS9i035686; Sat, 14 Apr 2012 12:21:28 -0700 (PDT) (envelope-from yuri@rawbw.com) Message-ID: <4F89CE37.1070706@rawbw.com> Date: Sat, 14 Apr 2012 12:21:27 -0700 From: Yuri User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.3) Gecko/20120316 Thunderbird/10.0.3 MIME-Version: 1.0 To: Jason Leschnik References: <4F89C005.2020304@rawbw.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Why host transmit rate on 1Gb ethernet is only ~750Mbps ? 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, 14 Apr 2012 19:21:29 -0000 On 04/14/2012 12:11, Jason Leschnik wrote: > I would first start by doing a point-to-point link between your two > end nodes to rule out your network gear as being the problem Now I did this, connected hosts directly with cat5 cable. Sending speed is still 753 Mbits/sec. Receiving speed reported even dropped from 729 to 695 Mbps for some reason. This rules out the router. Yuri From owner-freebsd-net@FreeBSD.ORG Sat Apr 14 19:27:12 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 89BA61065674 for ; Sat, 14 Apr 2012 19:27:12 +0000 (UTC) (envelope-from leschnik@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 45C978FC1A for ; Sat, 14 Apr 2012 19:27:12 +0000 (UTC) Received: by yenl9 with SMTP id l9so2513511yen.13 for ; Sat, 14 Apr 2012 12:27:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=GzsW1vULw1NFsR4vfc/X5VeYeyVIzMJX0tMySL62Sdk=; b=ZkFQLMPGkfHfSDQ0Y1PaZ5wpC+r0VDzkdnsWDUas4w451R8JTm0e8hLTvUeim/4Hz4 jVY3VHcvU+V/Ct82twDtKFnbmsqYgrZfAnOZrsEEt7OxNKf6B0w9mFFVvP6xwEmKyDni qXHt5WsI9qISm8N+V+fWlDuTOd6x+g9xPB2RzPoPWUC9DlCnnFHuCCyzaJ/rYpBeaT4m fWf56EvtNphcQ/rSTXUBBZoBftZTGrCG8Omt/6gpS5UWN22+k1DfFi0Uzw/RMwlupCIc 8l8A07mG7NQMkvsRhlTbHGirU5Gyjy6oymw+/3SrJAKQMF2KzA/im4RlLR2QUiPkkcCy bH0Q== MIME-Version: 1.0 Received: by 10.236.138.227 with SMTP id a63mr6049252yhj.80.1334431626057; Sat, 14 Apr 2012 12:27:06 -0700 (PDT) Received: by 10.100.210.4 with HTTP; Sat, 14 Apr 2012 12:27:06 -0700 (PDT) In-Reply-To: <4F89CE37.1070706@rawbw.com> References: <4F89C005.2020304@rawbw.com> <4F89CE37.1070706@rawbw.com> Date: Sun, 15 Apr 2012 05:27:06 +1000 Message-ID: From: Jason Leschnik To: Yuri Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: Why host transmit rate on 1Gb ethernet is only ~750Mbps ? 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, 14 Apr 2012 19:27:12 -0000 cat5e or just cat5? On Sun, Apr 15, 2012 at 5:21 AM, Yuri wrote: > On 04/14/2012 12:11, Jason Leschnik wrote: >> >> I would first start by doing a point-to-point link between your two >> end nodes to rule out your network gear as being the problem > > > Now I did this, connected hosts directly with cat5 cable. > Sending speed is still 753 Mbits/sec. Receiving speed reported even dropp= ed > from 729 to 695 Mbps for some reason. > > This rules out the router. > > Yuri --=20 Regards, Jason Leschnik. [m] 0432 35 4224 [w@] jason dot leschnik ansto dot gov dot au [U@]=A0jml974@uow.edu.au From owner-freebsd-net@FreeBSD.ORG Sat Apr 14 19:28:02 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 22A9F106568F for ; Sat, 14 Apr 2012 19:28:02 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell0.rawbw.com (shell0.rawbw.com [198.144.192.45]) by mx1.freebsd.org (Postfix) with ESMTP id E390A8FC19 for ; Sat, 14 Apr 2012 19:28:01 +0000 (UTC) Received: from eagle.yuri.org (stunnel@localhost [127.0.0.1]) (authenticated bits=0) by shell0.rawbw.com (8.14.4/8.14.4) with ESMTP id q3EJS18w036645; Sat, 14 Apr 2012 12:28:01 -0700 (PDT) (envelope-from yuri@rawbw.com) Message-ID: <4F89CFC1.80306@rawbw.com> Date: Sat, 14 Apr 2012 12:28:01 -0700 From: Yuri User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.3) Gecko/20120316 Thunderbird/10.0.3 MIME-Version: 1.0 To: Jason Leschnik References: <4F89C005.2020304@rawbw.com> <4F89CE37.1070706@rawbw.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Why host transmit rate on 1Gb ethernet is only ~750Mbps ? 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, 14 Apr 2012 19:28:02 -0000 On 04/14/2012 12:27, Jason Leschnik wrote: > cat5e or just cat5? sorry, CAT5e. Yuri From owner-freebsd-net@FreeBSD.ORG Sat Apr 14 19:32:32 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1091B106566C for ; Sat, 14 Apr 2012 19:32:32 +0000 (UTC) (envelope-from leschnik@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 BD40D8FC12 for ; Sat, 14 Apr 2012 19:32:31 +0000 (UTC) Received: by ghrr20 with SMTP id r20so2511925ghr.13 for ; Sat, 14 Apr 2012 12:32:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=IBHpVGR0lFSPJq2QjU9G4YDDY7sSFRrO1KSJBE5W04E=; b=mMIsvvLAjAGO9Nq22ds906KsKRNQhIgYdxYZOWV1pAG5VqT3T9dIr7qaL6g7CT5cJ/ 58IU/DFkBihnTvgtkT3Z10PI9Jku1E61cYs4RqLplRFxkmkdQJeMxWGzJnlZtFUR8soR z0hPR6c/X4qfXRMC66soUlgZXg8hVFBKd8tsgmIBV3tA7YUiHWQUdEkvInB0Avz4BJ8o Me4zlGrRwWXqe9zi3vp/gFHDKzFu831jaFReQtckCjCCKMHw0+ACpWUmiYaEYTVG/CIh OuHYzt6UsduFoK/g098pKD0+g2g4krq3HtXU1z2+sPpikv+Dj+bRyyT9I+DbE46tZdMR 9v2A== MIME-Version: 1.0 Received: by 10.236.155.226 with SMTP id j62mr6085560yhk.30.1334431951122; Sat, 14 Apr 2012 12:32:31 -0700 (PDT) Received: by 10.100.210.4 with HTTP; Sat, 14 Apr 2012 12:32:31 -0700 (PDT) In-Reply-To: <4F89CFC1.80306@rawbw.com> References: <4F89C005.2020304@rawbw.com> <4F89CE37.1070706@rawbw.com> <4F89CFC1.80306@rawbw.com> Date: Sun, 15 Apr 2012 05:32:31 +1000 Message-ID: From: Jason Leschnik To: Yuri Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: Why host transmit rate on 1Gb ethernet is only ~750Mbps ? 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, 14 Apr 2012 19:32:32 -0000 What kind of load are you looking at when running the test? maybe output `vmstat 1 15` during a test run On Sun, Apr 15, 2012 at 5:28 AM, Yuri wrote: > On 04/14/2012 12:27, Jason Leschnik wrote: >> >> cat5e or just cat5? > > > sorry, CAT5e. > > Yuri --=20 Regards, Jason Leschnik. [m] 0432 35 4224 [w@] jason dot leschnik ansto dot gov dot au [U@]=A0jml974@uow.edu.au From owner-freebsd-net@FreeBSD.ORG Sat Apr 14 19:37:23 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5DEBE106564A for ; Sat, 14 Apr 2012 19:37:23 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell0.rawbw.com (shell0.rawbw.com [198.144.192.45]) by mx1.freebsd.org (Postfix) with ESMTP id 41F0A8FC08 for ; Sat, 14 Apr 2012 19:37:23 +0000 (UTC) Received: from eagle.yuri.org (stunnel@localhost [127.0.0.1]) (authenticated bits=0) by shell0.rawbw.com (8.14.4/8.14.4) with ESMTP id q3EJbMaB037846; Sat, 14 Apr 2012 12:37:22 -0700 (PDT) (envelope-from yuri@rawbw.com) Message-ID: <4F89D1F2.3080009@rawbw.com> Date: Sat, 14 Apr 2012 12:37:22 -0700 From: Yuri User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0.3) Gecko/20120316 Thunderbird/10.0.3 MIME-Version: 1.0 To: Jason Leschnik References: <4F89C005.2020304@rawbw.com> <4F89CE37.1070706@rawbw.com> <4F89CFC1.80306@rawbw.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Why host transmit rate on 1Gb ethernet is only ~750Mbps ? 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, 14 Apr 2012 19:37:23 -0000 On 04/14/2012 12:32, Jason Leschnik wrote: > What kind of load are you looking at when running the test? > > maybe output `vmstat 1 15` during a test run Here is the log during the test run on the sending side: # vmstat 1 15 procs memory page disks faults cpu r b w avm fre flt re pi po fr sr md0 ad0 in sy cs us sy id 0 9 17 32481M 1312M 3155 1 6 0 3263 430 0 0 1163 11537 6958 4 1 95 1 9 17 32507M 1312M 283 0 0 0 55 0 0 0 2354 163960 8891 5 4 91 1 9 17 32507M 1312M 4 0 0 0 0 0 0 0 5427 156936 15139 5 3 92 0 9 17 32507M 1312M 3436 0 0 0 2380 0 0 0 5412 211755 16386 7 4 89 0 9 17 32507M 1312M 4 0 0 0 0 0 0 0 5418 151530 15159 5 3 92 1 9 17 32495M 1321M 5 0 0 0 2380 0 0 0 5411 145787 15047 4 3 93 1 9 17 32495M 1321M 4 0 0 0 0 0 0 0 5492 147687 15451 4 3 93 0 9 17 32495M 1321M 4 0 0 0 0 0 0 0 5441 145666 15155 4 3 92 0 9 17 32495M 1321M 600 0 0 0 0 0 0 0 5418 147173 15361 4 2 93 0 9 17 32495M 1321M 7 0 0 0 0 0 0 0 5428 145410 15122 4 3 93 0 9 17 32495M 1321M 4 0 0 0 0 0 0 0 5427 146896 15175 4 3 93 1 9 17 32481M 1312M 2402 0 0 0 399 0 0 51 2629 128751 9712 4 2 93 Yuri