From owner-freebsd-stable@FreeBSD.ORG Thu Dec 3 09:30:34 2009 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A17941065695 for ; Thu, 3 Dec 2009 09:30:34 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper-int.allbsd.org [IPv6:2001:2f0:104:e002::2]) by mx1.freebsd.org (Postfix) with ESMTP id AC47C8FC15 for ; Thu, 3 Dec 2009 09:30:33 +0000 (UTC) Received: from delta.allbsd.org (p3177-ipbf416funabasi.chiba.ocn.ne.jp [123.225.92.177]) (authenticated bits=128) by mail.allbsd.org (8.14.3/8.14.3) with ESMTP id nB39U8xP063912; Thu, 3 Dec 2009 18:30:19 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (alph.allbsd.org [192.168.0.10]) (authenticated bits=0) by delta.allbsd.org (8.13.4/8.13.4) with ESMTP id nB39U2eD055861; Thu, 3 Dec 2009 18:30:07 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Thu, 03 Dec 2009 18:29:31 +0900 (JST) Message-Id: <20091203.182931.129751456.hrs@allbsd.org> To: jfvogel@gmail.com From: Hiroki Sato In-Reply-To: <2a41acea0912021514r2d44dd33n4c364518d7fe1703@mail.gmail.com> References: <20091201.102925.218343479.hrs@allbsd.org> <2a41acea0912021249w1aed8e83kf89ceb1e6041edaf@mail.gmail.com> <2a41acea0912021514r2d44dd33n4c364518d7fe1703@mail.gmail.com> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.3rc1 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Thu_Dec__3_18_29_31_2009_240)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.95.3 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.allbsd.org [133.31.130.32]); Thu, 03 Dec 2009 18:30:26 +0900 (JST) X-Spam-Status: No, score=-5.4 required=13.0 tests=AWL,BAYES_00, CONTENT_TYPE_PRESENT, SPF_SOFTFAIL, X_MAILER_PRESENT autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gatekeeper.allbsd.org Cc: stable@FreeBSD.org Subject: Re: em interface slow down on 8.0R X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 09:30:34 -0000 ----Security_Multipart(Thu_Dec__3_18_29_31_2009_240)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Jack, Jack Vogel wrote in <2a41acea0912021514r2d44dd33n4c364518d7fe1703@mail.gmail.com>: jf> Update: the claim to be unable to install was hasty, I went in and looked jf> into myself and was able to get an install. Here's what I've found so far: jf> jf> First, the 82547EI will fail due to Invalid Mac Address, so I guess you jf> hacked around this problem yourself? I had someone here test all jf> legacy adapters for this problem and I was told nothing else was exhibiting jf> it besides the 82542, obviously this is false :) In any case I will be jf> making jf> an official patch to fix that problem soon. jf> jf> Second, once I had the device working I do indeed see substandard jf> performance, I am continuing to debug, but wanted you to know that I jf> have reproduced this. Thank you! I have investigated some more details. First, I got something wrong with the affected FreeBSD versions; one I tried was 8.0-STABLE, not 8.0-RELEASE. So I started to try 8.0R. A summary of chips and releases I tried so far is now the following: 7.2R 8.0R 8.0-STABLE 82540EM (chip=0x100e8086, rev=0x02) OK OK too slow[1] 82541PI (chip=0x107c8086, rev=0x05) OK ? OK 82545ep (chip=0x10268086, rev=0x04) OK ? OK 82547EI (chip=0x10198086, rev=0x00) OK OK too slow[1] 82562V-2(chip=0x10c08086, rev=0x02) OK ? OK 82573E (chip=0x108c8086, rev=0x03) OK ? work but sometimes freeze[2] 82573L (chip=0x109a8086, rev=0x00) OK ? work but sometimes freeze[2] 8.0-STABLE is as of Dec 1. The [1] means the odd RTT I described in the previous email. The [2] means it worked fine but sometimes it stopped working, as described later. The long RTT symptom is reproducible on Intel D865BGP motherboard. When I inserted another PCI card with an 82545ep onto it, it worked fine as em1. The em0 still had the problem after adding the em1 card. I did not manually set MAC address on it, and there was no error related to it. The above box is used for some network services, so I prepared another box based on D865BGP motherboard. This box has two NICs, 82547EI and 82540EM. The former is on-board and the latter is a PCI card. The 8.0R worked fine with the two. On the 8.0-STABLE both NICs have the RTT problem. The following difference was found by comparing the outputs dev.em.[01].debug with each other: -em0: Adapter hardware address = 0xc42e1424 +em0: Adapter hardware address = 0xc42e0424 -em1: Adapter hardware address = 0xc4364424 +em1: Adapter hardware address = 0xc435e424 The "-" lines are on 8.0-STABLE, and the "+" ones are on 8.0-RELEASE. Although I did not yet tried 8.0R on the other boxes which work fine on 8.0-STABLE, it is certain that the RTT problem did not occur on that box + 8.0R, at least. Difference of em(4) between 8.0-RELEASE and 8.0-STABLE is quite small, so perhaps it is due to some other changes... If there is something else I should try, please let me know. And another thing, I noticed a box with 82573E and 82573L sometimes got stuck after upgrading to 8.0-STABLE. It has moderate network load (average 5-10Mbps) on both NICs. It worked for a day or two and then got stuck suddenly. Rebooting the box solved the situation, but it got stuck again after a day or so. After it happens, the interface does not respond. The other functionalities of FreeBSD seemed working. Doing an up/down cycle for the NICs seemed to send some packets, but it did not recover completely; rebooting was needed for recovery. This box does not have the RTT problem. I am still not sure what is the trigger, there seems something wrong. -- Hiroki ----Security_Multipart(Thu_Dec__3_18_29_31_2009_240)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAksXhPsACgkQTyzT2CeTzy0E+ACgh4PjBtE+RyzvIfZGzu6UVWAh q0oAnjD0BNWRG4XF6ejNeeAYIl6l34wd =qnsA -----END PGP SIGNATURE----- ----Security_Multipart(Thu_Dec__3_18_29_31_2009_240)----