em interface slow down on 8.0R

[Hiroki Sato]

Hi Jack,

Jack Vogel <jfvogel at gmail.com> wrote
  in <2a41acea0912021514r2d44dd33n4c364518d7fe1703 at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20091203/1c4102e9/attachment.pgp