Date: Thu, 03 Dec 2009 18:29:31 +0900 (JST) From: Hiroki Sato <hrs@FreeBSD.org> To: jfvogel@gmail.com Cc: stable@FreeBSD.org Subject: Re: em interface slow down on 8.0R Message-ID: <20091203.182931.129751456.hrs@allbsd.org> In-Reply-To: <2a41acea0912021514r2d44dd33n4c364518d7fe1703@mail.gmail.com> References: <20091201.102925.218343479.hrs@allbsd.org> <2a41acea0912021249w1aed8e83kf89ceb1e6041edaf@mail.gmail.com> <2a41acea0912021514r2d44dd33n4c364518d7fe1703@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
----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 <jfvogel@gmail.com> 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)----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20091203.182931.129751456.hrs>