Re: em interface slow down on 8.0R
Hiroki Sato h...@freebsd.org wrote in 20091220.053757.230970486@allbsd.org: hr Jack Vogel jfvo...@gmail.com wrote hr in 2a41acea0912052327t7830f85aw5b4b581ab3f09...@mail.gmail.com: hr hr jf The 82573, when onboard (LOM) is usually special, it is used by system hr jf management hr jf firmware. Go to the system BIOS and turn off management, see if that hr jf eliminates the hr jf periodic hang. hr hr Well, I am using them without enabling such a BIOS feature on the two hr boxes. hr hr I was monitoring for 1 week after replacing the kernel of 8.0-STABLE hr with 8.0R. Frequency of the symptom was reduced, but occurred once hr in 2-3 days. So it is reproducible on 8.0R, too. JFYI, when I tried 8-STABLE as of May 15 the periodic hang-ups disappeared. The chip ids are 0x109a8086 and 0x108c8086 (pciconf reported them as 82573L and 82573E, added to PCI slots on the box). The hang-ups were able to be reproduced on 8.0-RELEASE. I didn't tried other boxes which had another symptom (abnormal long interval between each packet), but I will give it a try and report it, too I have no idea of what was the cause because there were a lot of changes since the release, though. -- Hiroki pgpgHrrrlXSG7.pgp Description: PGP signature
Re: em interface slow down on 8.0R
On Thu, Jan 28, 2010 at 11:16:02AM -0800, Jack Vogel wrote: I am investigating it, and have a suspicion about what's going on, you can assist in verifying my suspicion. In if_em.c search for em_setup_vlan_hw, you will find a compile time option that uses that only if FreeBSD_version is 700029, hack the code however you wish so that it uses the OLD way (ie that it never calls em_setup_vlan_hw_support()) and see if that makes the issue disappear. Oh good, I will try that and let you know about the result first chance I get. Should be days rather then hours, but I'll make it asap. If you have any problems or questions email me directly. Will do, thanks! Marco On Thu, Jan 28, 2010 at 4:17 AM, Marco van Tol ma...@tols.org wrote: On Tue, Jan 26, 2010 at 09:00:35AM -0800, Nick Rogers wrote: Is it advisable to patch 8.0-RELEASE kernel sources with the latest (CURRENT) em driver (i.e., src/sys/dev/e1000)? It looks like there are some updates to the driver since 8.0-RELEASE that may fix some problems? While on the em subject, forgive me if I mail this to the inappropriate place, but is there any ETA on progress for bug kern/141646? I'm currently suffering from it and would be willing to provide needed assistance for fixing it. Thank you very much in advance, Marco van Tol -- Better to remain silent and be thought a fool than to speak out and remove all doubt. - Abraham Lincoln ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: em interface slow down on 8.0R
No need, I set it up and tried it, and I was right, it does not fail if that routine is not used. The interesting thing is that the igb driver, which has the same code, works fine. In any case, I'm hot on the track of this and hope I can figure it out today. Jack On Fri, Jan 29, 2010 at 5:38 AM, Marco van Tol ma...@tols.org wrote: On Thu, Jan 28, 2010 at 11:16:02AM -0800, Jack Vogel wrote: I am investigating it, and have a suspicion about what's going on, you can assist in verifying my suspicion. In if_em.c search for em_setup_vlan_hw, you will find a compile time option that uses that only if FreeBSD_version is 700029, hack the code however you wish so that it uses the OLD way (ie that it never calls em_setup_vlan_hw_support()) and see if that makes the issue disappear. Oh good, I will try that and let you know about the result first chance I get. Should be days rather then hours, but I'll make it asap. If you have any problems or questions email me directly. Will do, thanks! Marco On Thu, Jan 28, 2010 at 4:17 AM, Marco van Tol ma...@tols.org wrote: On Tue, Jan 26, 2010 at 09:00:35AM -0800, Nick Rogers wrote: Is it advisable to patch 8.0-RELEASE kernel sources with the latest (CURRENT) em driver (i.e., src/sys/dev/e1000)? It looks like there are some updates to the driver since 8.0-RELEASE that may fix some problems? While on the em subject, forgive me if I mail this to the inappropriate place, but is there any ETA on progress for bug kern/141646? I'm currently suffering from it and would be willing to provide needed assistance for fixing it. Thank you very much in advance, Marco van Tol -- Better to remain silent and be thought a fool than to speak out and remove all doubt. - Abraham Lincoln ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: em interface slow down on 8.0R
On Fri, Jan 29, 2010 at 09:45:42AM -0800, Jack Vogel wrote:
No need, I set it up and tried it, and I was right, it does not fail if that
routine is not used. The interesting thing is that the igb driver, which
has the same code, works fine.
In any case, I'm hot on the track of this and hope I can figure it out
today.
Ah nice, I found a hole in time to try it as well. I just rebuild a kernel
and rebooted. During the reboot I found what you write above. :)
Anyways, the attached patch makes it work indeed as you found yourself as
well in the mean time. :-)
I tried just deleting the call itself at first, but the module is compiled
with warnings treated as errors and barfs about a defined but unused
function. So in the patch you'll find the entire function removed.
Let me know about anything else I can do. I don't have the necessary test
equipment at home, so normally I'll need to find a time window to test
things. But I'm more then willing to.
The version I patch is the following by the way, from 8.0-RELEASE-p2:
/*$FreeBSD: src/sys/dev/e1000/if_em.c,v 1.21.2.3.2.1 2009/10/25 01:10:29
kensmith Exp $*/
Thanks so far!
Marco
--
Van Duitsers heb je pas gewonnen als ze met de bus de stad uit zijn.
- Youp van 't Hek
--- sys/dev/e1000/if_em.c.orig 2010-01-29 18:20:46.0 +0100
+++ sys/dev/e1000/if_em.c 2010-01-29 18:26:59.0 +0100
@@ -289,7 +289,6 @@
#if __FreeBSD_version = 700029
static void em_register_vlan(void *, struct ifnet *, u16);
static void em_unregister_vlan(void *, struct ifnet *, u16);
-static void em_setup_vlan_hw_support(struct adapter *);
#endif
static int em_xmit(struct adapter *, struct mbuf **);
static void em_smartspeed(struct adapter *);
@@ -1535,17 +1534,12 @@
/* Setup VLAN support, basic and offload if available */
E1000_WRITE_REG(adapter-hw, E1000_VET, ETHERTYPE_VLAN);
-#if __FreeBSD_version 700029
if (ifp-if_capenable IFCAP_VLAN_HWTAGGING) {
u32 ctrl;
ctrl = E1000_READ_REG(adapter-hw, E1000_CTRL);
ctrl |= E1000_CTRL_VME;
E1000_WRITE_REG(adapter-hw, E1000_CTRL, ctrl);
}
-#else
- /* Use real VLAN Filter support */
- em_setup_vlan_hw_support(adapter);
-#endif
/* Set hardware offload abilities */
ifp-if_hwassist = 0;
@@ -4762,44 +4756,6 @@
em_init(adapter);
}
-static void
-em_setup_vlan_hw_support(struct adapter *adapter)
-{
- struct e1000_hw *hw = adapter-hw;
- u32 reg;
-
- /*
- ** We get here thru init_locked, meaning
- ** a soft reset, this has already cleared
- ** the VFTA and other state, so if there
- ** have been no vlan's registered do nothing.
- */
- if (adapter-num_vlans == 0)
-return;
-
- /*
- ** A soft reset zero's out the VFTA, so
- ** we need to repopulate it now.
- */
- for (int i = 0; i EM_VFTA_SIZE; i++)
-if (em_shadow_vfta[i] != 0)
- E1000_WRITE_REG_ARRAY(hw, E1000_VFTA,
-i, em_shadow_vfta[i]);
-
- reg = E1000_READ_REG(hw, E1000_CTRL);
- reg |= E1000_CTRL_VME;
- E1000_WRITE_REG(hw, E1000_CTRL, reg);
-
- /* Enable the Filter Table */
- reg = E1000_READ_REG(hw, E1000_RCTL);
- reg = ~E1000_RCTL_CFIEN;
- reg |= E1000_RCTL_VFE;
- E1000_WRITE_REG(hw, E1000_RCTL, reg);
-
- /* Update the frame size */
- E1000_WRITE_REG(adapter-hw, E1000_RLPML,
- adapter-max_frame_size + VLAN_TAG_SIZE);
-}
#endif
static void
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: em interface slow down on 8.0R
You know, i know absolutely nothing about ALTQ :) This is the first I've heard about this problem, you should make sure the maintainer of the driver gets informed sooner :) Would be happy to look into it as I have time. Jack On Fri, Jan 29, 2010 at 5:28 PM, Nick Rogers ncrog...@gmail.com wrote: Does any of this have anything to do with the fact that ALTQ seems to be broken for em(4) under 8.0-RELEASE? I just ran into this similar problem today where my PF/ALTQ hfsc rules no longer seem to do anything on em interfaces. http://forums.freebsd.org/showthread.php?t=6656 Any information regarding this would be appreciated. Thanks. On Fri, Jan 29, 2010 at 9:45 AM, Jack Vogel jfvo...@gmail.com wrote: No need, I set it up and tried it, and I was right, it does not fail if that routine is not used. The interesting thing is that the igb driver, which has the same code, works fine. In any case, I'm hot on the track of this and hope I can figure it out today. Jack On Fri, Jan 29, 2010 at 5:38 AM, Marco van Tol ma...@tols.org wrote: On Thu, Jan 28, 2010 at 11:16:02AM -0800, Jack Vogel wrote: I am investigating it, and have a suspicion about what's going on, you can assist in verifying my suspicion. In if_em.c search for em_setup_vlan_hw, you will find a compile time option that uses that only if FreeBSD_version is 700029, hack the code however you wish so that it uses the OLD way (ie that it never calls em_setup_vlan_hw_support()) and see if that makes the issue disappear. Oh good, I will try that and let you know about the result first chance I get. Should be days rather then hours, but I'll make it asap. If you have any problems or questions email me directly. Will do, thanks! Marco On Thu, Jan 28, 2010 at 4:17 AM, Marco van Tol ma...@tols.org wrote: On Tue, Jan 26, 2010 at 09:00:35AM -0800, Nick Rogers wrote: Is it advisable to patch 8.0-RELEASE kernel sources with the latest (CURRENT) em driver (i.e., src/sys/dev/e1000)? It looks like there are some updates to the driver since 8.0-RELEASE that may fix some problems? While on the em subject, forgive me if I mail this to the inappropriate place, but is there any ETA on progress for bug kern/141646? I'm currently suffering from it and would be willing to provide needed assistance for fixing it. Thank you very much in advance, Marco van Tol -- Better to remain silent and be thought a fool than to speak out and remove all doubt. - Abraham Lincoln ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: em interface slow down on 8.0R
Does any of this have anything to do with the fact that ALTQ seems to be broken for em(4) under 8.0-RELEASE? I just ran into this similar problem today where my PF/ALTQ hfsc rules no longer seem to do anything on em interfaces. http://forums.freebsd.org/showthread.php?t=6656 Any information regarding this would be appreciated. Thanks. On Fri, Jan 29, 2010 at 9:45 AM, Jack Vogel jfvo...@gmail.com wrote: No need, I set it up and tried it, and I was right, it does not fail if that routine is not used. The interesting thing is that the igb driver, which has the same code, works fine. In any case, I'm hot on the track of this and hope I can figure it out today. Jack On Fri, Jan 29, 2010 at 5:38 AM, Marco van Tol ma...@tols.org wrote: On Thu, Jan 28, 2010 at 11:16:02AM -0800, Jack Vogel wrote: I am investigating it, and have a suspicion about what's going on, you can assist in verifying my suspicion. In if_em.c search for em_setup_vlan_hw, you will find a compile time option that uses that only if FreeBSD_version is 700029, hack the code however you wish so that it uses the OLD way (ie that it never calls em_setup_vlan_hw_support()) and see if that makes the issue disappear. Oh good, I will try that and let you know about the result first chance I get. Should be days rather then hours, but I'll make it asap. If you have any problems or questions email me directly. Will do, thanks! Marco On Thu, Jan 28, 2010 at 4:17 AM, Marco van Tol ma...@tols.org wrote: On Tue, Jan 26, 2010 at 09:00:35AM -0800, Nick Rogers wrote: Is it advisable to patch 8.0-RELEASE kernel sources with the latest (CURRENT) em driver (i.e., src/sys/dev/e1000)? It looks like there are some updates to the driver since 8.0-RELEASE that may fix some problems? While on the em subject, forgive me if I mail this to the inappropriate place, but is there any ETA on progress for bug kern/141646? I'm currently suffering from it and would be willing to provide needed assistance for fixing it. Thank you very much in advance, Marco van Tol -- Better to remain silent and be thought a fool than to speak out and remove all doubt. - Abraham Lincoln ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: em interface slow down on 8.0R
I just discovered it myself today. I'll try and post more info in another thread. On Fri, Jan 29, 2010 at 5:43 PM, Jack Vogel jfvo...@gmail.com wrote: You know, i know absolutely nothing about ALTQ :) This is the first I've heard about this problem, you should make sure the maintainer of the driver gets informed sooner :) Would be happy to look into it as I have time. Jack On Fri, Jan 29, 2010 at 5:28 PM, Nick Rogers ncrog...@gmail.com wrote: Does any of this have anything to do with the fact that ALTQ seems to be broken for em(4) under 8.0-RELEASE? I just ran into this similar problem today where my PF/ALTQ hfsc rules no longer seem to do anything on em interfaces. http://forums.freebsd.org/showthread.php?t=6656 Any information regarding this would be appreciated. Thanks. On Fri, Jan 29, 2010 at 9:45 AM, Jack Vogel jfvo...@gmail.com wrote: No need, I set it up and tried it, and I was right, it does not fail if that routine is not used. The interesting thing is that the igb driver, which has the same code, works fine. In any case, I'm hot on the track of this and hope I can figure it out today. Jack On Fri, Jan 29, 2010 at 5:38 AM, Marco van Tol ma...@tols.org wrote: On Thu, Jan 28, 2010 at 11:16:02AM -0800, Jack Vogel wrote: I am investigating it, and have a suspicion about what's going on, you can assist in verifying my suspicion. In if_em.c search for em_setup_vlan_hw, you will find a compile time option that uses that only if FreeBSD_version is 700029, hack the code however you wish so that it uses the OLD way (ie that it never calls em_setup_vlan_hw_support()) and see if that makes the issue disappear. Oh good, I will try that and let you know about the result first chance I get. Should be days rather then hours, but I'll make it asap. If you have any problems or questions email me directly. Will do, thanks! Marco On Thu, Jan 28, 2010 at 4:17 AM, Marco van Tol ma...@tols.org wrote: On Tue, Jan 26, 2010 at 09:00:35AM -0800, Nick Rogers wrote: Is it advisable to patch 8.0-RELEASE kernel sources with the latest (CURRENT) em driver (i.e., src/sys/dev/e1000)? It looks like there are some updates to the driver since 8.0-RELEASE that may fix some problems? While on the em subject, forgive me if I mail this to the inappropriate place, but is there any ETA on progress for bug kern/141646? I'm currently suffering from it and would be willing to provide needed assistance for fixing it. Thank you very much in advance, Marco van Tol -- Better to remain silent and be thought a fool than to speak out and remove all doubt. - Abraham Lincoln ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: em interface slow down on 8.0R
On Fri, Jan 29, 2010 at 5:43 PM, Jack Vogel jfvo...@gmail.com wrote: You know, i know absolutely nothing about ALTQ :) This is the first I've heard about this problem, you should make sure the maintainer of the driver gets informed sooner :) Look like there is an old PR for it. See kern/138392. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: em interface slow down on 8.0R
On Tue, Jan 26, 2010 at 09:00:35AM -0800, Nick Rogers wrote: Is it advisable to patch 8.0-RELEASE kernel sources with the latest (CURRENT) em driver (i.e., src/sys/dev/e1000)? It looks like there are some updates to the driver since 8.0-RELEASE that may fix some problems? While on the em subject, forgive me if I mail this to the inappropriate place, but is there any ETA on progress for bug kern/141646? I'm currently suffering from it and would be willing to provide needed assistance for fixing it. Thank you very much in advance, Marco van Tol -- Most general statements are false, including this one. - Alexander Dumas ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: em interface slow down on 8.0R
I am investigating it, and have a suspicion about what's going on, you can assist in verifying my suspicion. In if_em.c search for em_setup_vlan_hw, you will find a compile time option that uses that only if FreeBSD_version is 700029, hack the code however you wish so that it uses the OLD way (ie that it never calls em_setup_vlan_hw_support()) and see if that makes the issue disappear. If you have any problems or questions email me directly. Jack On Thu, Jan 28, 2010 at 4:17 AM, Marco van Tol ma...@tols.org wrote: On Tue, Jan 26, 2010 at 09:00:35AM -0800, Nick Rogers wrote: Is it advisable to patch 8.0-RELEASE kernel sources with the latest (CURRENT) em driver (i.e., src/sys/dev/e1000)? It looks like there are some updates to the driver since 8.0-RELEASE that may fix some problems? While on the em subject, forgive me if I mail this to the inappropriate place, but is there any ETA on progress for bug kern/141646? I'm currently suffering from it and would be willing to provide needed assistance for fixing it. Thank you very much in advance, Marco van Tol -- Most general statements are false, including this one. - Alexander Dumas ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: em interface slow down on 8.0R
Is it advisable to patch 8.0-RELEASE kernel sources with the latest (CURRENT) em driver (i.e., src/sys/dev/e1000)? It looks like there are some updates to the driver since 8.0-RELEASE that may fix some problems? On Mon, Jan 25, 2010 at 8:31 PM, Joshua Boyd boy...@jbip.net wrote: I've been having a similar problem with my network dropping completely on my 8-STABLE gateway/firewall/fileserver. My setup is a little different, as I have re0 and ral0 bridged for LAN, and em0 for WAN. I've just turned off TX checksum offloading to see if that makes any difference. \\ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: em interface slow down on 8.0R
looks like the patch mentioned in kern/141843 has not been applied to the tree? On Tue, Jan 26, 2010 at 9:00 AM, Nick Rogers ncrog...@gmail.com wrote: Is it advisable to patch 8.0-RELEASE kernel sources with the latest (CURRENT) em driver (i.e., src/sys/dev/e1000)? It looks like there are some updates to the driver since 8.0-RELEASE that may fix some problems? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: em interface slow down on 8.0R
No, it hasn't, I need time to look it over and be convinced of what he was doing. Jack On Tue, Jan 26, 2010 at 9:14 AM, Nick Rogers ncrog...@gmail.com wrote: looks like the patch mentioned in kern/141843 has not been applied to the tree? On Tue, Jan 26, 2010 at 9:00 AM, Nick Rogers ncrog...@gmail.com wrote: Is it advisable to patch 8.0-RELEASE kernel sources with the latest (CURRENT) em driver (i.e., src/sys/dev/e1000)? It looks like there are some updates to the driver since 8.0-RELEASE that may fix some problems? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: em interface slow down on 8.0R
I've tried this patch, and it completely breaks IPv6 offloads, which DO work btw, our testers have a netperf stress test that does both ipv4 and ipv6, and that test fails 100% after this change. I could go hacking at it myself but as its your code Pyun would you like to resolve this issue? Regards, Jack On Tue, Jan 26, 2010 at 9:40 AM, Jack Vogel jfvo...@gmail.com wrote: No, it hasn't, I need time to look it over and be convinced of what he was doing. Jack On Tue, Jan 26, 2010 at 9:14 AM, Nick Rogers ncrog...@gmail.com wrote: looks like the patch mentioned in kern/141843 has not been applied to the tree? On Tue, Jan 26, 2010 at 9:00 AM, Nick Rogers ncrog...@gmail.com wrote: Is it advisable to patch 8.0-RELEASE kernel sources with the latest (CURRENT) em driver (i.e., src/sys/dev/e1000)? It looks like there are some updates to the driver since 8.0-RELEASE that may fix some problems? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: em interface slow down on 8.0R
On Tue, Jan 26, 2010 at 11:55:00AM -0800, Jack Vogel wrote: I've tried this patch, and it completely breaks IPv6 offloads, which DO work btw, our testers have a netperf stress test that does both ipv4 and ipv6, and that test fails 100% after this change. I could go hacking at it myself but as its your code Pyun would you like to resolve this issue? I wonder how you could test IPv6 checksum offloading/TSO as FreeBSD does not have that capability yet. Do we already have that capability? I vaguely remember there was an effort to bring the support in but I don't know current status. If we have the capability I would have to update all other drivers that can do IPv6 checksum offloading/TSO for IPv6. Regards, Jack On Tue, Jan 26, 2010 at 9:40 AM, Jack Vogel jfvo...@gmail.com wrote: No, it hasn't, I need time to look it over and be convinced of what he was doing. Jack On Tue, Jan 26, 2010 at 9:14 AM, Nick Rogers ncrog...@gmail.com wrote: looks like the patch mentioned in kern/141843 has not been applied to the tree? On Tue, Jan 26, 2010 at 9:00 AM, Nick Rogers ncrog...@gmail.com wrote: Is it advisable to patch 8.0-RELEASE kernel sources with the latest (CURRENT) em driver (i.e., src/sys/dev/e1000)? It looks like there are some updates to the driver since 8.0-RELEASE that may fix some problems? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: em interface slow down on 8.0R
Well, what our testers do is assign BOTH an ipv4 and ipv6 address to an interface, then netperf runs over both, I don't know the internal details but I assume both TCP and UDP are going over ipv6. Prior to your change there is IPv6 handling code in the tx checksum routine, so I assume the hardware offload for that works. With your patch if I disable TXCSUM on the interface then it will work... but before your change it works with that on. So, am I missing something? Cheers, Jack On Tue, Jan 26, 2010 at 12:12 PM, Pyun YongHyeon pyu...@gmail.com wrote: On Tue, Jan 26, 2010 at 11:55:00AM -0800, Jack Vogel wrote: I've tried this patch, and it completely breaks IPv6 offloads, which DO work btw, our testers have a netperf stress test that does both ipv4 and ipv6, and that test fails 100% after this change. I could go hacking at it myself but as its your code Pyun would you like to resolve this issue? I wonder how you could test IPv6 checksum offloading/TSO as FreeBSD does not have that capability yet. Do we already have that capability? I vaguely remember there was an effort to bring the support in but I don't know current status. If we have the capability I would have to update all other drivers that can do IPv6 checksum offloading/TSO for IPv6. Regards, Jack On Tue, Jan 26, 2010 at 9:40 AM, Jack Vogel jfvo...@gmail.com wrote: No, it hasn't, I need time to look it over and be convinced of what he was doing. Jack On Tue, Jan 26, 2010 at 9:14 AM, Nick Rogers ncrog...@gmail.com wrote: looks like the patch mentioned in kern/141843 has not been applied to the tree? On Tue, Jan 26, 2010 at 9:00 AM, Nick Rogers ncrog...@gmail.com wrote: Is it advisable to patch 8.0-RELEASE kernel sources with the latest (CURRENT) em driver (i.e., src/sys/dev/e1000)? It looks like there are some updates to the driver since 8.0-RELEASE that may fix some problems? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: em interface slow down on 8.0R
On Tue, Jan 26, 2010 at 12:22:01PM -0800, Jack Vogel wrote: Well, what our testers do is assign BOTH an ipv4 and ipv6 address to an interface, then netperf runs over both, I don't know the internal details but I assume both TCP and UDP are going over ipv6. Prior to your change there is IPv6 handling code in the tx checksum routine, so I assume the hardware offload for that works. With your patch if I disable TXCSUM on the interface then it will work... but before your change it works with that on. So, am I missing something? Hmm, then I guess there is bug in the patch. Apparently upper stack already computed checksum for IPv6 so the patch should not try to offload IPv6 traffic again. I'll see the patch again. Thanks for valuable input. :-) Cheers, Jack On Tue, Jan 26, 2010 at 12:12 PM, Pyun YongHyeon pyu...@gmail.com wrote: On Tue, Jan 26, 2010 at 11:55:00AM -0800, Jack Vogel wrote: I've tried this patch, and it completely breaks IPv6 offloads, which DO work btw, our testers have a netperf stress test that does both ipv4 and ipv6, and that test fails 100% after this change. I could go hacking at it myself but as its your code Pyun would you like to resolve this issue? I wonder how you could test IPv6 checksum offloading/TSO as FreeBSD does not have that capability yet. Do we already have that capability? I vaguely remember there was an effort to bring the support in but I don't know current status. If we have the capability I would have to update all other drivers that can do IPv6 checksum offloading/TSO for IPv6. Regards, Jack On Tue, Jan 26, 2010 at 9:40 AM, Jack Vogel jfvo...@gmail.com wrote: No, it hasn't, I need time to look it over and be convinced of what he was doing. Jack On Tue, Jan 26, 2010 at 9:14 AM, Nick Rogers ncrog...@gmail.com wrote: looks like the patch mentioned in kern/141843 has not been applied to the tree? On Tue, Jan 26, 2010 at 9:00 AM, Nick Rogers ncrog...@gmail.com wrote: Is it advisable to patch 8.0-RELEASE kernel sources with the latest (CURRENT) em driver (i.e., src/sys/dev/e1000)? It looks like there are some updates to the driver since 8.0-RELEASE that may fix some problems? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: em interface slow down on 8.0R
Great, if you can get the changes to me quickly I'd like to incorporate them. BTW, I have merged your igb changes into my code and its very stable, should see that checked in for 7.3 shortly. Thanks for your hard work Pyun! Jack On Tue, Jan 26, 2010 at 12:33 PM, Pyun YongHyeon pyu...@gmail.com wrote: On Tue, Jan 26, 2010 at 12:22:01PM -0800, Jack Vogel wrote: Well, what our testers do is assign BOTH an ipv4 and ipv6 address to an interface, then netperf runs over both, I don't know the internal details but I assume both TCP and UDP are going over ipv6. Prior to your change there is IPv6 handling code in the tx checksum routine, so I assume the hardware offload for that works. With your patch if I disable TXCSUM on the interface then it will work... but before your change it works with that on. So, am I missing something? Hmm, then I guess there is bug in the patch. Apparently upper stack already computed checksum for IPv6 so the patch should not try to offload IPv6 traffic again. I'll see the patch again. Thanks for valuable input. :-) Cheers, Jack On Tue, Jan 26, 2010 at 12:12 PM, Pyun YongHyeon pyu...@gmail.com wrote: On Tue, Jan 26, 2010 at 11:55:00AM -0800, Jack Vogel wrote: I've tried this patch, and it completely breaks IPv6 offloads, which DO work btw, our testers have a netperf stress test that does both ipv4 and ipv6, and that test fails 100% after this change. I could go hacking at it myself but as its your code Pyun would you like to resolve this issue? I wonder how you could test IPv6 checksum offloading/TSO as FreeBSD does not have that capability yet. Do we already have that capability? I vaguely remember there was an effort to bring the support in but I don't know current status. If we have the capability I would have to update all other drivers that can do IPv6 checksum offloading/TSO for IPv6. Regards, Jack On Tue, Jan 26, 2010 at 9:40 AM, Jack Vogel jfvo...@gmail.com wrote: No, it hasn't, I need time to look it over and be convinced of what he was doing. Jack On Tue, Jan 26, 2010 at 9:14 AM, Nick Rogers ncrog...@gmail.com wrote: looks like the patch mentioned in kern/141843 has not been applied to the tree? On Tue, Jan 26, 2010 at 9:00 AM, Nick Rogers ncrog...@gmail.com wrote: Is it advisable to patch 8.0-RELEASE kernel sources with the latest (CURRENT) em driver (i.e., src/sys/dev/e1000)? It looks like there are some updates to the driver since 8.0-RELEASE that may fix some problems? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: em interface slow down on 8.0R
On Tue, Jan 26, 2010 at 12:36:22PM -0800, Jack Vogel wrote: Great, if you can get the changes to me quickly I'd like to incorporate them. Unfortunately I couldn't reproduce it on my box. I've tested both IPv4 and IPv6 at the same time with netperf and it worked as expected. Reading the code also indicates the patch wouldn't break IPv6 traffic as CSUM_OFFLOAD is not set by upper stack. Are you using any special configurations for testing? BTW, I have merged your igb changes into my code and its very stable, should see that checked in for 7.3 shortly. That's great! Thank you. Thanks for your hard work Pyun! No problem. Jack On Tue, Jan 26, 2010 at 12:33 PM, Pyun YongHyeon pyu...@gmail.com wrote: On Tue, Jan 26, 2010 at 12:22:01PM -0800, Jack Vogel wrote: Well, what our testers do is assign BOTH an ipv4 and ipv6 address to an interface, then netperf runs over both, I don't know the internal details but I assume both TCP and UDP are going over ipv6. Prior to your change there is IPv6 handling code in the tx checksum routine, so I assume the hardware offload for that works. With your patch if I disable TXCSUM on the interface then it will work... but before your change it works with that on. So, am I missing something? Hmm, then I guess there is bug in the patch. Apparently upper stack already computed checksum for IPv6 so the patch should not try to offload IPv6 traffic again. I'll see the patch again. Thanks for valuable input. :-) Cheers, Jack On Tue, Jan 26, 2010 at 12:12 PM, Pyun YongHyeon pyu...@gmail.com wrote: On Tue, Jan 26, 2010 at 11:55:00AM -0800, Jack Vogel wrote: I've tried this patch, and it completely breaks IPv6 offloads, which DO work btw, our testers have a netperf stress test that does both ipv4 and ipv6, and that test fails 100% after this change. I could go hacking at it myself but as its your code Pyun would you like to resolve this issue? I wonder how you could test IPv6 checksum offloading/TSO as FreeBSD does not have that capability yet. Do we already have that capability? I vaguely remember there was an effort to bring the support in but I don't know current status. If we have the capability I would have to update all other drivers that can do IPv6 checksum offloading/TSO for IPv6. Regards, Jack On Tue, Jan 26, 2010 at 9:40 AM, Jack Vogel jfvo...@gmail.com wrote: No, it hasn't, I need time to look it over and be convinced of what he was doing. Jack On Tue, Jan 26, 2010 at 9:14 AM, Nick Rogers ncrog...@gmail.com wrote: looks like the patch mentioned in kern/141843 has not been applied to the tree? On Tue, Jan 26, 2010 at 9:00 AM, Nick Rogers ncrog...@gmail.com wrote: Is it advisable to patch 8.0-RELEASE kernel sources with the latest (CURRENT) em driver (i.e., src/sys/dev/e1000)? It looks like there are some updates to the driver since 8.0-RELEASE that may fix some problems? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: em interface slow down on 8.0R
Can anyone clarify if I should be looking to disable TSO or TXCSUM, or both, or does disabling either one somehow work around the problem? Thanks a lot. On Mon, Jan 25, 2010 at 8:31 PM, Joshua Boyd boy...@jbip.net wrote: I've been having a similar problem with my network dropping completely on my 8-STABLE gateway/firewall/fileserver. My setup is a little different, as I have re0 and ral0 bridged for LAN, and em0 for WAN. I've just turned off TX checksum offloading to see if that makes any difference. On Mon, Jan 25, 2010 at 1:49 PM, Lars Eggert lars.egg...@nokia.com wrote: Hi, On 2010-1-25, at 19:38, Nick Rogers wrote: On Mon, Jan 25, 2010 at 10:22 AM, Pyun YongHyeon pyu...@gmail.com wrote: I'm not sure you're seeing a checksum offload bug of em(4) but the bug is easily reproducible in VLAN environments. If the issue is gone when you disable TX checksum offloading, see kern/141843 for for more detailed information as well as fix. Good to know, but I am having a similar problem on another em(4) interface that has no VLAN interfaces. FYI, I also have these issues without using VLANs, and turning off TSO fixed them. Lars ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: em interface slow down on 8.0R
On Tue, Jan 26, 2010 at 11:09:45PM -0800, Nick Rogers wrote: Can anyone clarify if I should be looking to disable TSO or TXCSUM, or both, or does disabling either one somehow work around the problem? Thanks a lot. On Mon, Jan 25, 2010 at 8:31 PM, Joshua Boyd boy...@jbip.net wrote: I've been having a similar problem with my network dropping completely on my 8-STABLE gateway/firewall/fileserver. My setup is a little different, as I have re0 and ral0 bridged for LAN, and em0 for WAN. I've just turned off TX checksum offloading to see if that makes any difference. On Mon, Jan 25, 2010 at 1:49 PM, Lars Eggert lars.egg...@nokia.com wrote: Hi, On 2010-1-25, at 19:38, Nick Rogers wrote: On Mon, Jan 25, 2010 at 10:22 AM, Pyun YongHyeon pyu...@gmail.com wrote: I'm not sure you're seeing a checksum offload bug of em(4) but the bug is easily reproducible in VLAN environments. If the issue is gone when you disable TX checksum offloading, see kern/141843 for for more detailed information as well as fix. Good to know, but I am having a similar problem on another em(4) interface that has no VLAN interfaces. FYI, I also have these issues without using VLANs, and turning off TSO fixed them. The recommendation is to disable TSO (TCP Segmentation Offloading) as well as TXCSUM (TCP Checksum Offloading). -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: em interface slow down on 8.0R
Hi, have you tried turning off TCP Segmentation Offloading (net.inet.tcp.tso sysctl)? That fixed performance issues with some em cards for me. Lars On 2010-1-25, at 5:47, Nick Rogers wrote: I am having similar em interface problems with some of my production machines running older intel 2-port cards, since upgrading from 7.2-RELEASE to 8.0-RELEASE. The problem is basically, everything works fine, but periodically the interface hangs (tcpdump shows no frames). A reboot or an ifconfig down followed by an ifconfig up fixes the problem for some time. Traffic peaks at maybe 20mbit per day and its all 802.1Q VLAN tagged traffic (about 10 vlan interfaces). When this happens netstat reports only errors and no packets on the affected interface. Media is set to autoselect. This is happening about 5-10x per day. Heres relevant sysctl and ifconfig info. dev.em.6.%desc: Intel(R) PRO/1000 Network Connection 6.9.14 dev.em.6.%driver: em dev.em.6.%location: slot=3 function=0 dev.em.6.%pnpinfo: vendor=0x8086 device=0x1079 subvendor=0x8086 subdevice=0x1179 class=0x02 dev.em.6.%parent: pci3 dev.em.6.debug: -1 dev.em.6.stats: -1 dev.em.6.rx_int_delay: 0 dev.em.6.tx_int_delay: 66 dev.em.6.rx_abs_int_delay: 66 dev.em.6.tx_abs_int_delay: 66 dev.em.6.rx_processing_limit: 100 em6: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=9bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM ether 00:04:23:cd:47:82 media: Ethernet autoselect (1000baseT full-duplex) status: active On Tue, Jan 5, 2010 at 6:35 PM, Jason Chambers jchamb...@ucla.edu wrote: Hiroki Sato wrote: 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) OKOKtoo slow[1] 82541PI (chip=0x107c8086, rev=0x05) OK? OK Running 8.0R I've noticed the same problem with this card (0x107c8086). Duplex and speed are manually set at full/1000. e...@pci0:3:3:0: class=0x02 card=0x13768086 chip=0x107c8086 rev=0x05 hdr=0x00 vendor = 'Intel Corporation' device = 'Gigabit Ethernet Controller (Copper) rev 5 (82541PI)' class = network subclass = ethernet Regards, --Jason ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: em interface slow down on 8.0R
Hi, have you tried turning off TCP Segmentation Offloading (net.inet.tcp.tso sysctl)? That fixed performance issues with some em cards for me. Lars On 2010-1-25, at 5:47, Nick Rogers wrote: I am having similar em interface problems with some of my production machines running older intel 2-port cards, since upgrading from 7.2-RELEASE to 8.0-RELEASE. The problem is basically, everything works fine, but periodically the interface hangs (tcpdump shows no frames). A reboot or an ifconfig down followed by an ifconfig up fixes the problem for some time. Traffic peaks at maybe 20mbit per day and its all 802.1Q VLAN tagged traffic (about 10 vlan interfaces). When this happens netstat reports only errors and no packets on the affected interface. Media is set to autoselect. This is happening about 5-10x per day. Heres relevant sysctl and ifconfig info. dev.em.6.%desc: Intel(R) PRO/1000 Network Connection 6.9.14 dev.em.6.%driver: em dev.em.6.%location: slot=3 function=0 dev.em.6.%pnpinfo: vendor=0x8086 device=0x1079 subvendor=0x8086 subdevice=0x1179 class=0x02 dev.em.6.%parent: pci3 dev.em.6.debug: -1 dev.em.6.stats: -1 dev.em.6.rx_int_delay: 0 dev.em.6.tx_int_delay: 66 dev.em.6.rx_abs_int_delay: 66 dev.em.6.tx_abs_int_delay: 66 dev.em.6.rx_processing_limit: 100 em6: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=9bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM ether 00:04:23:cd:47:82 media: Ethernet autoselect (1000baseT full-duplex) status: active On Tue, Jan 5, 2010 at 6:35 PM, Jason Chambers jchamb...@ucla.edu wrote: Hiroki Sato wrote: 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) OKOKtoo slow[1] 82541PI (chip=0x107c8086, rev=0x05) OK? OK Running 8.0R I've noticed the same problem with this card (0x107c8086). Duplex and speed are manually set at full/1000. e...@pci0:3:3:0: class=0x02 card=0x13768086 chip=0x107c8086 rev=0x05 hdr=0x00 vendor = 'Intel Corporation' device = 'Gigabit Ethernet Controller (Copper) rev 5 (82541PI)' class = network subclass = ethernet Regards, --Jason ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: em interface slow down on 8.0R
I have not tried toying with any tcp sysctl. I'm not having performance problems so much as the interface just stops working entirely, which I would think has nothing to do with the TCP stack when layer 2 is not functioning? I'll give it a shot if I can. For the moment I have had to switch to a different (lower performance) network card to get things stable and I would like to be aware of a more concrete driver fix in STABLE before switching back my production machines. On Mon, Jan 25, 2010 at 6:25 AM, Lars Eggert lars.egg...@nokia.com wrote: Hi, have you tried turning off TCP Segmentation Offloading (net.inet.tcp.tso sysctl)? That fixed performance issues with some em cards for me. Lars ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: em interface slow down on 8.0R
On Mon, Jan 25, 2010 at 08:25:43AM -0800, Nick Rogers wrote: I have not tried toying with any tcp sysctl. I'm not having performance problems so much as the interface just stops working entirely, which I would think has nothing to do with the TCP stack when layer 2 is not functioning? I'm not sure you're seeing a checksum offload bug of em(4) but the bug is easily reproducible in VLAN environments. If the issue is gone when you disable TX checksum offloading, see kern/141843 for for more detailed information as well as fix. I'll give it a shot if I can. For the moment I have had to switch to a different (lower performance) network card to get things stable and I would like to be aware of a more concrete driver fix in STABLE before switching back my production machines. On Mon, Jan 25, 2010 at 6:25 AM, Lars Eggert lars.egg...@nokia.com wrote: Hi, have you tried turning off TCP Segmentation Offloading (net.inet.tcp.tso sysctl)? That fixed performance issues with some em cards for me. Lars ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: em interface slow down on 8.0R
On Mon, Jan 25, 2010 at 10:22 AM, Pyun YongHyeon pyu...@gmail.com wrote: On Mon, Jan 25, 2010 at 08:25:43AM -0800, Nick Rogers wrote: I have not tried toying with any tcp sysctl. I'm not having performance problems so much as the interface just stops working entirely, which I would think has nothing to do with the TCP stack when layer 2 is not functioning? I'm not sure you're seeing a checksum offload bug of em(4) but the bug is easily reproducible in VLAN environments. If the issue is gone when you disable TX checksum offloading, see kern/141843 for for more detailed information as well as fix. Good to know, but I am having a similar problem on another em(4) interface that has no VLAN interfaces. I'll give it a shot if I can. For the moment I have had to switch to a different (lower performance) network card to get things stable and I would like to be aware of a more concrete driver fix in STABLE before switching back my production machines. On Mon, Jan 25, 2010 at 6:25 AM, Lars Eggert lars.egg...@nokia.com wrote: Hi, have you tried turning off TCP Segmentation Offloading (net.inet.tcp.tso sysctl)? That fixed performance issues with some em cards for me. Lars ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: em interface slow down on 8.0R
Hi, On 2010-1-25, at 19:38, Nick Rogers wrote: On Mon, Jan 25, 2010 at 10:22 AM, Pyun YongHyeon pyu...@gmail.com wrote: I'm not sure you're seeing a checksum offload bug of em(4) but the bug is easily reproducible in VLAN environments. If the issue is gone when you disable TX checksum offloading, see kern/141843 for for more detailed information as well as fix. Good to know, but I am having a similar problem on another em(4) interface that has no VLAN interfaces. FYI, I also have these issues without using VLANs, and turning off TSO fixed them. Lars
Re: em interface slow down on 8.0R
I've been having a similar problem with my network dropping completely on my 8-STABLE gateway/firewall/fileserver. My setup is a little different, as I have re0 and ral0 bridged for LAN, and em0 for WAN. I've just turned off TX checksum offloading to see if that makes any difference. On Mon, Jan 25, 2010 at 1:49 PM, Lars Eggert lars.egg...@nokia.com wrote: Hi, On 2010-1-25, at 19:38, Nick Rogers wrote: On Mon, Jan 25, 2010 at 10:22 AM, Pyun YongHyeon pyu...@gmail.com wrote: I'm not sure you're seeing a checksum offload bug of em(4) but the bug is easily reproducible in VLAN environments. If the issue is gone when you disable TX checksum offloading, see kern/141843 for for more detailed information as well as fix. Good to know, but I am having a similar problem on another em(4) interface that has no VLAN interfaces. FYI, I also have these issues without using VLANs, and turning off TSO fixed them. Lars -- Joshua Boyd JBipNet E-mail: boy...@jbip.net http://www.jbip.net ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: em interface slow down on 8.0R
I am having similar em interface problems with some of my production machines running older intel 2-port cards, since upgrading from 7.2-RELEASE to 8.0-RELEASE. The problem is basically, everything works fine, but periodically the interface hangs (tcpdump shows no frames). A reboot or an ifconfig down followed by an ifconfig up fixes the problem for some time. Traffic peaks at maybe 20mbit per day and its all 802.1Q VLAN tagged traffic (about 10 vlan interfaces). When this happens netstat reports only errors and no packets on the affected interface. Media is set to autoselect. This is happening about 5-10x per day. Heres relevant sysctl and ifconfig info. dev.em.6.%desc: Intel(R) PRO/1000 Network Connection 6.9.14 dev.em.6.%driver: em dev.em.6.%location: slot=3 function=0 dev.em.6.%pnpinfo: vendor=0x8086 device=0x1079 subvendor=0x8086 subdevice=0x1179 class=0x02 dev.em.6.%parent: pci3 dev.em.6.debug: -1 dev.em.6.stats: -1 dev.em.6.rx_int_delay: 0 dev.em.6.tx_int_delay: 66 dev.em.6.rx_abs_int_delay: 66 dev.em.6.tx_abs_int_delay: 66 dev.em.6.rx_processing_limit: 100 em6: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=9bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM ether 00:04:23:cd:47:82 media: Ethernet autoselect (1000baseT full-duplex) status: active On Tue, Jan 5, 2010 at 6:35 PM, Jason Chambers jchamb...@ucla.edu wrote: Hiroki Sato wrote: 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) OKOKtoo slow[1] 82541PI (chip=0x107c8086, rev=0x05) OK? OK Running 8.0R I've noticed the same problem with this card (0x107c8086). Duplex and speed are manually set at full/1000. e...@pci0:3:3:0: class=0x02 card=0x13768086 chip=0x107c8086 rev=0x05 hdr=0x00 vendor = 'Intel Corporation' device = 'Gigabit Ethernet Controller (Copper) rev 5 (82541PI)' class = network subclass = ethernet Regards, --Jason ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: em interface slow down on 8.0R
Hiroki Sato wrote: 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) OKOKtoo slow[1] 82541PI (chip=0x107c8086, rev=0x05) OK? OK Running 8.0R I've noticed the same problem with this card (0x107c8086). Duplex and speed are manually set at full/1000. e...@pci0:3:3:0:class=0x02 card=0x13768086 chip=0x107c8086 rev=0x05 hdr=0x00 vendor = 'Intel Corporation' device = 'Gigabit Ethernet Controller (Copper) rev 5 (82541PI)' class = network subclass = ethernet Regards, --Jason ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: em interface slow down on 8.0R
Jack Vogel jfvo...@gmail.com wrote in 2a41acea0912052327t7830f85aw5b4b581ab3f09...@mail.gmail.com: jf The 82573, when onboard (LOM) is usually special, it is used by system jf management jf firmware. Go to the system BIOS and turn off management, see if that jf eliminates the jf periodic hang. Well, I am using them without enabling such a BIOS feature on the two boxes. I was monitoring for 1 week after replacing the kernel of 8.0-STABLE with 8.0R. Frequency of the symptom was reduced, but occurred once in 2-3 days. So it is reproducible on 8.0R, too. Just after the symptom occurred, dev.em.[01].debug showed the following: Dec 17 16:50:03 pool kernel: em0: Std mbuf failed = 0 Dec 17 16:50:03 pool kernel: em0: Std mbuf cluster failed = 9612 Dec 17 16:50:12 pool kernel: em1: Std mbuf failed = 0 Dec 17 16:50:12 pool kernel: em1: Std mbuf cluster failed = 15183 The other numbers look normal to me. dev.em.[01].stats reported almost all of the counters other than Good Packets are zero. Doing ifconfig down/up could make it work again, sending/receiving 10 packets or so it stopped. -- Hiroki pgpqr0AvqiEGc.pgp Description: PGP signature
Re: em interface slow down on 8.0R
Hiroki Sato h...@freebsd.org wrote in 20091203.182931.129751456@allbsd.org: hr And another thing, I noticed a box with 82573E and 82573L sometimes hr got stuck after upgrading to 8.0-STABLE. It has moderate network hr load (average 5-10Mbps) on both NICs. It worked for a day or two and hr then got stuck suddenly. Rebooting the box solved the situation, but hr it got stuck again after a day or so. After it happens, the hr interface does not respond. The other functionalities of FreeBSD hr seemed working. Doing an up/down cycle for the NICs seemed to send hr some packets, but it did not recover completely; rebooting was needed hr for recovery. This box does not have the RTT problem. I am still hr not sure what is the trigger, there seems something wrong. Things turned out for this symptom so far are: - This occurs around once per 1-2 days. - Once it occurs, all of communications including ARP and IPv4 stop. - ifconfig em0 down/up can recover the interface. However, on doing up after down the following message was displayed: # ifconfig em0 up em0: Could not setup receive structures After trying it several times it worked. Then, the interface seemed back to normal for a couple of minutes, but it stopped again. I guess there is a kind of deadlock somewhere but not sure it is really related to the em(4) driver. I will continue to investigate anyway. -- Hiroki pgpLUYiLUHZZ7.pgp Description: PGP signature
Re: em interface slow down on 8.0R
On Dec 5, 2009, at 4:40 AM, Hiroki Sato h...@freebsd.org wrote: Hiroki Sato h...@freebsd.org wrote in 20091203.182931.129751456@allbsd.org: hr And another thing, I noticed a box with 82573E and 82573L sometimes hr got stuck after upgrading to 8.0-STABLE. It has moderate network hr load (average 5-10Mbps) on both NICs. It worked for a day or two and hr then got stuck suddenly. Rebooting the box solved the situation, but hr it got stuck again after a day or so. After it happens, the hr interface does not respond. The other functionalities of FreeBSD hr seemed working. Doing an up/down cycle for the NICs seemed to send hr some packets, but it did not recover completely; rebooting was needed hr for recovery. This box does not have the RTT problem. I am still hr not sure what is the trigger, there seems something wrong. Things turned out for this symptom so far are: - This occurs around once per 1-2 days. - Once it occurs, all of communications including ARP and IPv4 stop. - ifconfig em0 down/up can recover the interface. However, on doing up after down the following message was displayed: # ifconfig em0 up em0: Could not setup receive structures After trying it several times it worked. Then, the interface seemed back to normal for a couple of minutes, but it stopped again. I guess there is a kind of deadlock somewhere but not sure it is really related to the em(4) driver. I will continue to investigate anyway. I'm curious, what speed/duplex is your interface using and is it statically set or using autoselect? JN ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: em interface slow down on 8.0R
John Nielsen j...@jnielsen.net wrote in 1e3c66ea-a6d3-44d7-b28e-bf068fff1...@jnielsen.net: jo On Dec 5, 2009, at 4:40 AM, Hiroki Sato h...@freebsd.org wrote: jo jo Hiroki Sato h...@freebsd.org wrote jo in 20091203.182931.129751456@allbsd.org: jo jo hr And another thing, I noticed a box with 82573E and 82573L jo sometimes jo hr got stuck after upgrading to 8.0-STABLE. It has moderate network jo hr load (average 5-10Mbps) on both NICs. It worked for a day or two jo and jo hr then got stuck suddenly. Rebooting the box solved the situation, jo but jo hr it got stuck again after a day or so. After it happens, the jo hr interface does not respond. The other functionalities of FreeBSD jo hr seemed working. Doing an up/down cycle for the NICs seemed to jo send jo hr some packets, but it did not recover completely; rebooting was jo needed jo hr for recovery. This box does not have the RTT problem. I am still jo hr not sure what is the trigger, there seems something wrong. jo jo Things turned out for this symptom so far are: jo jo - This occurs around once per 1-2 days. jo jo - Once it occurs, all of communications including ARP and IPv4 stop. jo jo - ifconfig em0 down/up can recover the interface. However, on doing joup after down the following message was displayed: jo jo# ifconfig em0 up joem0: Could not setup receive structures jo joAfter trying it several times it worked. jo joThen, the interface seemed back to normal for a couple of minutes, jobut it stopped again. jo jo I guess there is a kind of deadlock somewhere but not sure it is jo really related to the em(4) driver. I will continue to investigate jo anyway. jo jo I'm curious, what speed/duplex is your interface using and is it jo statically set or using autoselect? No manual configuration. Two em's are set as the following: | media: Ethernet autoselect (1000baseT full-duplex) It is mainly used for NFS server. The actual communication speed was around 700Mbps at peak. -- Hiroki pgpvYDKEkwgAk.pgp Description: PGP signature
Re: em interface slow down on 8.0R
The 82573, when onboard (LOM) is usually special, it is used by system management firmware. Go to the system BIOS and turn off management, see if that eliminates the periodic hang. Jack On Sat, Dec 5, 2009 at 9:27 PM, Hiroki Sato h...@freebsd.org wrote: John Nielsen j...@jnielsen.net wrote in 1e3c66ea-a6d3-44d7-b28e-bf068fff1...@jnielsen.net: jo On Dec 5, 2009, at 4:40 AM, Hiroki Sato h...@freebsd.org wrote: jo jo Hiroki Sato h...@freebsd.org wrote jo in 20091203.182931.129751456@allbsd.org: jo jo hr And another thing, I noticed a box with 82573E and 82573L jo sometimes jo hr got stuck after upgrading to 8.0-STABLE. It has moderate network jo hr load (average 5-10Mbps) on both NICs. It worked for a day or two jo and jo hr then got stuck suddenly. Rebooting the box solved the situation, jo but jo hr it got stuck again after a day or so. After it happens, the jo hr interface does not respond. The other functionalities of FreeBSD jo hr seemed working. Doing an up/down cycle for the NICs seemed to jo send jo hr some packets, but it did not recover completely; rebooting was jo needed jo hr for recovery. This box does not have the RTT problem. I am still jo hr not sure what is the trigger, there seems something wrong. jo jo Things turned out for this symptom so far are: jo jo - This occurs around once per 1-2 days. jo jo - Once it occurs, all of communications including ARP and IPv4 stop. jo jo - ifconfig em0 down/up can recover the interface. However, on doing joup after down the following message was displayed: jo jo# ifconfig em0 up joem0: Could not setup receive structures jo joAfter trying it several times it worked. jo joThen, the interface seemed back to normal for a couple of minutes, jobut it stopped again. jo jo I guess there is a kind of deadlock somewhere but not sure it is jo really related to the em(4) driver. I will continue to investigate jo anyway. jo jo I'm curious, what speed/duplex is your interface using and is it jo statically set or using autoselect? No manual configuration. Two em's are set as the following: | media: Ethernet autoselect (1000baseT full-duplex) It is mainly used for NFS server. The actual communication speed was around 700Mbps at peak. -- Hiroki ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: em interface slow down on 8.0R
Hi Jack, Jack Vogel jfvo...@gmail.com wrote in 2a41acea0912021514r2d44dd33n4c364518d7fe1...@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) OKOKtoo slow[1] 82541PI (chip=0x107c8086, rev=0x05) OK? OK 82545ep (chip=0x10268086, rev=0x04) OK? OK 82547EI (chip=0x10198086, rev=0x00) OKOKtoo 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 pgpJ7YFZl6Z8M.pgp Description: PGP signature
Re: em interface slow down on 8.0R
We've run into a snag on this problem. The 82547 is a LOM only interface and my validation engineer has only found two old systems that have it, and neither of them will even install FreeBSD 8 they are so old :( I might suggest that you continue using the 7.2 driver with that hardware if it was working. To me this is further data on the need to have a frozen legacy version of em but the problem is which code to use and how to approach it. Can you give me more specifics on the box you have this installed on?? Regards, Jack On Mon, Nov 30, 2009 at 5:29 PM, Hiroki Sato h...@freebsd.org wrote: Jack Vogel jfvo...@gmail.com wrote in 2a41acea0911301119j1449be58y183f2fe1d1112...@mail.gmail.com: jf I will look into this Hiroki, as time goes the older hardware does not jf always jf get test cycles like one might wish. Thanks! Please let me know if you need more information. -- Hiroki ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: em interface slow down on 8.0R
Update: the claim to be unable to install was hasty, I went in and looked into myself and was able to get an install. Here's what I've found so far: First, the 82547EI will fail due to Invalid Mac Address, so I guess you hacked around this problem yourself? I had someone here test all legacy adapters for this problem and I was told nothing else was exhibiting it besides the 82542, obviously this is false :) In any case I will be making an official patch to fix that problem soon. Second, once I had the device working I do indeed see substandard performance, I am continuing to debug, but wanted you to know that I have reproduced this. Jack On Wed, Dec 2, 2009 at 12:49 PM, Jack Vogel jfvo...@gmail.com wrote: We've run into a snag on this problem. The 82547 is a LOM only interface and my validation engineer has only found two old systems that have it, and neither of them will even install FreeBSD 8 they are so old :( I might suggest that you continue using the 7.2 driver with that hardware if it was working. To me this is further data on the need to have a frozen legacy version of em but the problem is which code to use and how to approach it. Can you give me more specifics on the box you have this installed on?? Regards, Jack On Mon, Nov 30, 2009 at 5:29 PM, Hiroki Sato h...@freebsd.org wrote: Jack Vogel jfvo...@gmail.com wrote in 2a41acea0911301119j1449be58y183f2fe1d1112...@mail.gmail.com: jf I will look into this Hiroki, as time goes the older hardware does not jf always jf get test cycles like one might wish. Thanks! Please let me know if you need more information. -- Hiroki ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: em interface slow down on 8.0R
On 1 Dec 2009, at 12:05, Elliot Finley wrote: On Mon, Nov 30, 2009 at 6:29 PM, Hiroki Sato h...@freebsd.org wrote: Jack Vogel jfvo...@gmail.com wrote in 2a41acea0911301119j1449be58y183f2fe1d1112...@mail.gmail.com: jf I will look into this Hiroki, as time goes the older hardware does not jf always jf get test cycles like one might wish. Here's some more info to throw into the mix. I have several new boxes running 8-Stable (a few hours after release). Leaving all sysctl at default, I get around 400mbps testing with netperf or iperf. If I set the following on the box running 'netserver' or 'iperf -s': kern.ipc.maxsockbuf=16777216 net.inet.tcp.recvspace=1048576 then I can get around 926mbps. But then if I make those same changes on the box running the client side of netperf or iperf the performance drops back down to around 400mbps. All boxes have the same hardware. they have two 4-port Intel NICS in them. e...@pci0:5:0:1: class=0x02 card=0x10a48086 chip=0x10a48086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' device = '82571EB Gigabit Ethernet Controller' class = network subclass = ethernet any pointers on further network tuning to get bidirectional link saturation would be much appreciated. These boxes are not in production yet, so anyone that would like to have access to troubleshoot, just ask. I've CC'd Lawrence Stewart in on this thread, as he's been doing work on the TCP stack lately and might have insight into what you might be running into. Lawrence -- there's a bit of a back thread with configuration and problem details in the stable@ archives. Robert___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: em interface slow down on 8.0R
On Mon, Nov 30, 2009 at 6:29 PM, Hiroki Sato h...@freebsd.org wrote: Jack Vogel jfvo...@gmail.com wrote in 2a41acea0911301119j1449be58y183f2fe1d1112...@mail.gmail.com: jf I will look into this Hiroki, as time goes the older hardware does not jf always jf get test cycles like one might wish. Here's some more info to throw into the mix. I have several new boxes running 8-Stable (a few hours after release). Leaving all sysctl at default, I get around 400mbps testing with netperf or iperf. If I set the following on the box running 'netserver' or 'iperf -s': kern.ipc.maxsockbuf=16777216 net.inet.tcp.recvspace=1048576 then I can get around 926mbps. But then if I make those same changes on the box running the client side of netperf or iperf the performance drops back down to around 400mbps. All boxes have the same hardware. they have two 4-port Intel NICS in them. e...@pci0:5:0:1: class=0x02 card=0x10a48086 chip=0x10a48086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' device = '82571EB Gigabit Ethernet Controller' class = network subclass = ethernet any pointers on further network tuning to get bidirectional link saturation would be much appreciated. These boxes are not in production yet, so anyone that would like to have access to troubleshoot, just ask. TIA Elliot ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: em interface slow down on 8.0R
I will look into this Hiroki, as time goes the older hardware does not always get test cycles like one might wish. Jack On Mon, Nov 30, 2009 at 12:04 AM, Hiroki Sato h...@freebsd.org wrote: Hi, I noticed that network connection of one of my boxes got significantly slow just after upgrading it to 8.0R. The box has an em0 (82547EI) and worked fine with 7.2R. The symptoms are: - A ping to a host on the same LAN takes 990ms RTT, it reduces gradually to around 1ms, and then it returns to around 1s. The rate was about 2ms/ping. - The response is quite slow, but no packet loss and network services on the box seem to work fine as far as I can check. There does not seem interrupt storm according to vmstat -i. No error message such as watchdog timeout appears. Any ideas to narrow down the cause? It maybe a linkup problem with a specific model of hub like full-duplex/half-duplex mismatch, but the link is 1000baseT full-duplex and setting it manually did not solve it. I think it is certain that upgrading to 8.0R triggered it, at least. Another box with an em interface works fine after upgrading to 8.0R. It has a different chip (82573E). Details of the em interface and vmstat -i are the following: e...@pci0:1:1:0: class=0x02 card=0x302c8086 chip=0x10198086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = 'Gigabit Ethernet Controller (LOM) (82547EI)' class = network subclass = ethernet Adapter hardware address = 0xc42e1424 em0: CTRL = 0x183c0241 RCTL = 0x8002 em0: Packet buffer = Tx=10k Rx=30k em0: Flow control watermarks high = 28672 low = 27172 em0: tx_int_delay = 66, tx_abs_int_delay = 66 em0: rx_int_delay = 0, rx_abs_int_delay = 66 em0: fifo workaround = 0, fifo_reset_count = 0 em0: hw tdh = 49, hw tdt = 49 em0: hw rdh = 238, hw rdt = 187 em0: Num Tx descriptors avail = 250 em0: Tx Descriptors not avail1 = 0 em0: Tx Descriptors not avail2 = 0 em0: Std mbuf failed = 0 em0: Std mbuf cluster failed = 0 em0: Driver dropped packets = 0 em0: Driver tx dma failure in encap = 0 dev.em.0.%desc: Intel(R) PRO/1000 Network Connection 6.9.14 dev.em.0.%driver: em dev.em.0.%location: slot=1 function=0 handle=\_SB_.PCI0.P0P2.TANA dev.em.0.%pnpinfo: vendor=0x8086 device=0x1019 subvendor=0x8086 subdevice=0x302c class=0x02 dev.em.0.%parent: pci1 dev.em.0.debug: -1 dev.em.0.stats: -1 dev.em.0.rx_int_delay: 0 dev.em.0.tx_int_delay: 66 dev.em.0.rx_abs_int_delay: 66 dev.em.0.tx_abs_int_delay: 66 dev.em.0.rx_processing_limit: 100 dev.em.0.wake: 0 % vmstat -i interrupt total rate irq4: uart0 3585 3 irq14: ata0 1811 1 irq15: ata1 112 0 irq16: uhci0 uhci315 0 irq18: em0 uhci2+ 92457 99 irq19: uhci1 1 0 irq23: ehci0 2 0 cpu0: timer 1849981 1997 cpu1: timer 1849961 1997 Total3797925 4101 -- Hiroki ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: em interface slow down on 8.0R
Jack Vogel jfvo...@gmail.com wrote in 2a41acea0911301119j1449be58y183f2fe1d1112...@mail.gmail.com: jf I will look into this Hiroki, as time goes the older hardware does not jf always jf get test cycles like one might wish. Thanks! Please let me know if you need more information. -- Hiroki pgp3TYQPpOkMO.pgp Description: PGP signature
