Re: em(4) duplex problems with 82541EI on RELENG_8, -CURRENT on PowerEdge 1850
On 7/26/2010 2:51 PM, Harald Schmalzbauer wrote: On 26.07.2010 18:19 Harald: Your patch looks clear. Now that the 8.1 mess is over, we should move quickly to bring up as many of the recent changes to -current as stable/8. George V. Neville-Neil already already got started on some of them. (1) We'll want to get them all patched now so that PowerEdge users have plenty of time to test in advance of 8.2-RELEASE 1. http://lists.freebsd.org/pipermail/svn-src-stable-8/2010-August/003081.html ~BAS ___ 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(4) duplex problems with 82541EI on RELENG_8, -CURRENT on PowerEdge 1850
On 26.07.2010 18:19, Brian A. Seklecki (CFI NOC) wrote: > On 7/19/2010 12:00 PM, Harald Schmalzbauer wrote: >> **/ >> -/*$FreeBSD: src/sys/dev/e1000/if_igb.h,v 1.4.2.2.2.1 2010/06/14 >> 02:09:06 kensmith Exp $*/ >> +/*$FreeBS > > > Haralad: > > It looks like your patch is identical to the patch RFP'd from HEAD > to branches/stable/8 on 06/18/2010 (aka, SVN r209309?) > > This includes the cumulative backport of changes in HEAD from > r208117 all the way to r209259 (but not 209959, which addresses > the TX checksum panic?) Looks like I really missed r209259 > Just to confirm: This fixes the duplex problems for you? No, I haven't done further tests regarding the duplex problem. > If so, odd -- I coped all of e1000/*.{c.h} from 8/stable/.../e1000/* > on 07/17/2010 into releng/8.1/sys/dev/e1000/* and am still seeing > the duplex problem after a full rebuild. > > I've been laboring under the assumption that SVN r209238 fixed > my problem, but it doesn't appear so from my backport testing. > > I'll try modifying your patch to include r209259 -> 209959 from > HEAD as well and go from there. Sorry for the hassle, I shouldn't have posted this patch without verification. -Harry ___ 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(4) duplex problems with 82541EI on RELENG_8, -CURRENT on PowerEdge 1850
On 7/19/2010 12:00 PM, Harald Schmalzbauer wrote: **/ -/*$FreeBSD: src/sys/dev/e1000/if_igb.h,v 1.4.2.2.2.1 2010/06/14 02:09:06 kensmith Exp $*/ +/*$FreeBS Haralad: It looks like your patch is identical to the patch RFP'd from HEAD to branches/stable/8 on 06/18/2010 (aka, SVN r209309?) This includes the cumulative backport of changes in HEAD from r208117 all the way to r209259 (but not 209959, which addresses the TX checksum panic?) Just to confirm: This fixes the duplex problems for you? If so, odd -- I coped all of e1000/*.{c.h} from 8/stable/.../e1000/* on 07/17/2010 into releng/8.1/sys/dev/e1000/* and am still seeing the duplex problem after a full rebuild. I've been laboring under the assumption that SVN r209238 fixed my problem, but it doesn't appear so from my backport testing. I'll try modifying your patch to include r209259 -> 209959 from HEAD as well and go from there. ~BAS PS. Maybe my lurid language has cursed me and I have to make peace with the universe first. Now, everyone reach under their chairs and take the 5 dried grams of shrooms I taped there. Then send in Vanilla Ice. ___ 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(4) duplex problems with 82541EI on RELENG_8, -CURRENT on PowerEdge 1850
On Mon, 19 Jul 2010, Brian A. Seklecki wrote: On Thu, 2010-07-15 at 10:53 -0700, Jack Vogel wrote: The fact that I WISH it to be MFC'd doesn't mean that I am actually given permission to do so. It seems 8.1 release was tagged on Saturday so we're proper-f* I can appreciate your frustration, but we don't use that kind of language on the freebsd lists. Doug -- Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso ___ 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(4) duplex problems with 82541EI on RELENG_8, -CURRENT on PowerEdge 1850
On Thu, 2010-07-15 at 10:53 -0700, Jack Vogel wrote: > The fact that I WISH it to be MFC'd doesn't mean that I am actually > given permission to do so. It seems 8.1 release was tagged on Saturday so we're proper-fucked (we will have to run local patches on all 1850s and 2850s for the duration of RELENG_8_1) http://svn.freebsd.org/viewvc/base?view=revision&revision=210187 Might want to prepare a patch file and instructions now for when the whining starts on freebsd-questi...@. ~BAS signature.asc Description: This is a digitally signed message part
Re: em(4) duplex problems with 82541EI on RELENG_8, -CURRENT on PowerEdge 1850
On Jul 15, 2010, at 7:48 PM, Steve Polyack wrote: > On 07/15/10 13:31, Michael Tuexen wrote: >> On Jul 15, 2010, at 6:50 PM, Brian A. Seklecki wrote: >> >> >>> It may have gone in before the RELENG_8_1 tag/branch occurred? SVN r209309 Jacks's change went into stable/8 on June 18: >>> Also, did anyone provide feedback on SVN r209959 to >>> head/sys/dev/e1000/if_em.c ? >>> >>> It's saying "8.1 MFC", so you might want to ask people to test that on >>> stable/8 then expedite the 8.1 MFC as well. >>> >> Maybe Jack can MFC it to stable/8. MFCing to releng/8.1 must come from >> stable/8 anyway. >> There is no need for re@ approval to MFC it into stable/8. >> > > As Brian stated, the change has already been MFC'd into stable/8 (June 18th) > with the following comment from Jack: > > "MFC to RELENG8.1 asap" Not sure if we talk about the same. r209959 was on July 12th and it was a commit to head and not stable/8. Best regards Michael > > > Steve >> Best regards >> Michael >> >>> ~BAS >>> >> ___ >> 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(4) duplex problems with 82541EI on RELENG_8, -CURRENT on PowerEdge 1850
> As Brian stated, the change has already been MFC'd into stable/8 (June > 18th) with the following comment from Jack: > > "MFC to RELENG8.1 asap" > I also dont see the issue listed on: http://wiki.freebsd.org/Releng/8.1TODO If someone can put it on there, even if the RELENG engineer doesn't handle it before the release, at least Dell users will be informed. ~BAS signature.asc Description: This is a digitally signed message part
Re: em(4) duplex problems with 82541EI on RELENG_8, -CURRENT on PowerEdge 1850
The fact that I WISH it to be MFC'd doesn't mean that I am actually given permission to do so. Jack On Thu, Jul 15, 2010 at 10:48 AM, Steve Polyack wrote: > On 07/15/10 13:31, Michael Tuexen wrote: > >> On Jul 15, 2010, at 6:50 PM, Brian A. Seklecki wrote: >> >> >> >>> >>> It may have gone in before the RELENG_8_1 tag/branch occurred? SVN r209309 Jacks's change went into stable/8 on June 18: >>> Also, did anyone provide feedback on SVN r209959 to >>> head/sys/dev/e1000/if_em.c ? >>> >>> It's saying "8.1 MFC", so you might want to ask people to test that on >>> stable/8 then expedite the 8.1 MFC as well. >>> >>> >> Maybe Jack can MFC it to stable/8. MFCing to releng/8.1 must come from >> stable/8 anyway. >> There is no need for re@ approval to MFC it into stable/8. >> >> > > As Brian stated, the change has already been MFC'd into stable/8 (June > 18th) with the following comment from Jack: > > "MFC to RELENG8.1 asap" > > > Steve > >> Best regards >> Michael >> >> >>> ~BAS >>> >>> >> ___ >> 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(4) duplex problems with 82541EI on RELENG_8, -CURRENT on PowerEdge 1850
On 07/15/10 13:31, Michael Tuexen wrote: On Jul 15, 2010, at 6:50 PM, Brian A. Seklecki wrote: It may have gone in before the RELENG_8_1 tag/branch occurred? SVN r209309 Jacks's change went into stable/8 on June 18: Also, did anyone provide feedback on SVN r209959 to head/sys/dev/e1000/if_em.c ? It's saying "8.1 MFC", so you might want to ask people to test that on stable/8 then expedite the 8.1 MFC as well. Maybe Jack can MFC it to stable/8. MFCing to releng/8.1 must come from stable/8 anyway. There is no need for re@ approval to MFC it into stable/8. As Brian stated, the change has already been MFC'd into stable/8 (June 18th) with the following comment from Jack: "MFC to RELENG8.1 asap" Steve Best regards Michael ~BAS ___ 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(4) duplex problems with 82541EI on RELENG_8, -CURRENT on PowerEdge 1850
On Jul 15, 2010, at 6:50 PM, Brian A. Seklecki wrote: > >> It may have gone in before the RELENG_8_1 tag/branch occurred? SVN >> r209309 >> >> Jacks's change went into stable/8 on June 18: >> > > Also, did anyone provide feedback on SVN r209959 to > head/sys/dev/e1000/if_em.c ? > > It's saying "8.1 MFC", so you might want to ask people to test that on > stable/8 then expedite the 8.1 MFC as well. Maybe Jack can MFC it to stable/8. MFCing to releng/8.1 must come from stable/8 anyway. There is no need for re@ approval to MFC it into stable/8. Best regards Michael > > ~BAS ___ 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(4) duplex problems with 82541EI on RELENG_8, -CURRENT on PowerEdge 1850
> It may have gone in before the RELENG_8_1 tag/branch occurred? SVN > r209309 > > Jacks's change went into stable/8 on June 18: > Also, did anyone provide feedback on SVN r209959 to head/sys/dev/e1000/if_em.c ? It's saying "8.1 MFC", so you might want to ask people to test that on stable/8 then expedite the 8.1 MFC as well. ~BAS signature.asc Description: This is a digitally signed message part
Re: em(4) duplex problems with 82541EI on RELENG_8, -CURRENT on PowerEdge 1850
On Tue, 2010-07-13 at 21:18 +0200, Harald Schmalzbauer wrote: > Jack Vogel schrieb am 18.06.2010 20:01 (localtime): > > Yes, the commits today are slated to get into 8.1, at least that's my > > understanding. > > > > Jack > > Hello, is this still on the to-merge-before-8.1-RELEASE list? Its hard to say; Not sure this issue was ever given a PR reference number? Jack's commit didn't mention one. It may have gone in before the RELENG_8_1 tag/branch occurred? SVN r209309 Jacks's change went into stable/8 on June 18: http://svn.freebsd.org/viewvc/base/stable/8/sys/dev/e1000/if_em.c?view=log 8.1 forked in SVN on June 14: http://svn.freebsd.org/viewvc/base/releng/8.1/sys/dev/e1000/if_em.c?view=log The change hasn't been MFC/RFP'd to releng/8.1/*, yet; Jack I'd get ahold of the releng officer ASAP at this point. ~BAS signature.asc Description: This is a digitally signed message part
Re: em(4) duplex problems with 82541EI on RELENG_8, -CURRENT on PowerEdge 1850
Jack Vogel schrieb am 18.06.2010 20:01 (localtime): Yes, the commits today are slated to get into 8.1, at least that's my understanding. Jack Hello, is this still on the to-merge-before-8.1-RELEASE list? Thanks, -Harry ... Adding Jack Vogel of Intel to the CC list, as he's been working on em(4) as of late. Brian, I have no idea if this will help or not, but... Jack just committed bits to the Intel drivers (em(4) ixgbe(4)), will you have a chance to test a new build? I'm trying to find an unused system ATM to test on myself, but it may take me a day or to. BTW, it appears Jack may be trying to get the fixes (and features) into 8.1-RELEASE, let's hope that it happens :) -Brandon signature.asc Description: OpenPGP digital signature
Re: em(4) duplex problems with 82541EI on RELENG_8, -CURRENT on PowerEdge 1850
On Fri, 18 Jun 2010, Jack Vogel wrote: Yes, the commits today are slated to get into 8.1, at least that's my understanding. Lets hope so; its looking very promising on the systems I'm able to test on. We should ask 82541EI and Dell 9th gen PowerEdge users to test them right away. ~BAS ___ 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(4) duplex problems with 82541EI on RELENG_8, -CURRENT on PowerEdge 1850
Yes, the commits today are slated to get into 8.1, at least that's my understanding. Jack On Fri, Jun 18, 2010 at 10:46 AM, Brandon Gooch wrote: > On Tue, Jun 1, 2010 at 2:37 PM, Jeremy Chadwick > wrote: > > On Tue, Jun 01, 2010 at 03:18:39PM -0400, Brian A. Seklecki wrote: > >> = Re-posted from freebsd-hardware@, since this is more of a bug > >> report than a hardware comparability inquiry / buying strategy > >> discussion. == > >> > >> All: > >> > >> Has anyone upgraded their PowerEdge 1850s to 8.0-PL or > >> RELENG_8 -stable? We're seeing problems where 7.2-PL and > >> 6.3-PL were not affected on the same hardware. > >> > >> The problem is that forcing the duplex 100/full on both > >> sides no longer functions. > >> > >> Configuration: > >> > >>- A variety of Cisco L2/L3 switches over the last decade: > >>-- 2848G-L3 > >>-- 2950 > >>-- 2960s > >>-- 3550-12Ts > >>-- 3550XLs > >>-- Duplex forced 100/full on Cisco side > >>- FreeBSD/amd64 RELENG_8 or 9-CURRENT with duplex > >> forced '100baseTX mediaopt full-duplex', > >>- This configuration has worked since FreeBSD 5.4 > >> > >> When connected to PowerEdge 1850r1/r2, with the onboard Intel > >> 82541EI, the parenthesis show an actual media speed/duplex of: > >> > >> media: Ethernet 100baseTX (100baseTX ) > >> > >> The same configuration using a Dell-sold Intel dual port > >> 82546EB, in the same system, on the same switch, works fine. > >> > >> > >> - > >> ifconfig(8): > >> - > >> em3: flags=8843 >> MULTICAST> metric 0 mtu 1500 > >> options=9b > >> ether 00:13:72:4f:70:81 > >> inet 192.168.97.20 netmask 0xff80 broadcast 192.168.97.127 > >> media: Ethernet 100baseTX (100baseTX ) > >> status: active > >> - > >> em0: flags=8843 >> MULTICAST> metric 0 mtu 1500> > >> options=9b > >> ether 00:04:23:c8:fe:ac > >> media: Ethernet 100baseTX > >> status: active > >> - > >> - > >> pciconf(8): > >> - > >> e...@pci0:7:8:0: class=0x02 card=0x016d1028 chip=0x10768086 > >> rev=0x05 hdr=0x00 > >> vendor = 'Intel Corporation' > >> device = 'Gigabit Ethernet Controller (82541EI)' > >> class = network > >> subclass = ethernet > >> e...@pci0:3:11:0: class=0x02 card=0x10128086 chip=0x10108086 > rev=0x01 > >> hdr=0x00 > >>vendor = 'Intel Corporation' > >>device = 'Dual Port Gigabit Ethernet Controller (Copper) (82546EB)' > >>class = network > >>subclass = ethernet > >> > >> - > >> > >> rc.conf(5) for shits & giggles: > >> > >> ifconfig_em0="inet X netmask Y media 100baseTX mediaopt full-duplex" > >> ifconfig_em3="inet Z netmask F media 100baseTX mediaopt full-duplex" > >> > >> > >> > >> Example IOS switch config: > >> interface FastEthernet0/39 > >> description I hate Dell > >> switchport access vlan 100 > >> switchport mode access > >> speed 100 > >> duplex full > >> spanning-tree portfast > >> end > >> > >> > >> I've been clearing interface counters on the switch side, but I'll send > >> 'netstat -i', 'show interface counters', and 'sudo sysctl -w > >> dev.em.3.stats=1' ASAP to illustrate connectivity errors soon. > >> > >> Are we being punished for patronizing Dell? > >> > >> Is it possible that ifconfig(8) output has simply changed? Are the > >> values in the parenthesis on the right the Ethernet auto-sense desired > >> values where as outside the parenthesis the current active values? > >> > >> In 6.3/7.2, once you forced a speed/duplex, the values in parenthesis > >> went away entirely. > >> > >> The only way I've been able to make that happen is to #define in > >> src/sys/dev/e1000/if_em.h: > >> > >> #define DO_AUTO_NEG 0 > >> /* > >>* This parameter control whether or not the driver will wait for > >>* autonegotiation to complete. > >>* 1 - Wait for autonegotiation to complete > >>* 0 - Don't wait for autonegotiation to complete > >> */ > >> > >> Also seems odd that some ICs are affected but not others. > >> > >> Its also possible that my problems are pf(4) + setfib(8) related and I > >> that this is a separate issue. > >> > >> Two new notes since the original post: > >> > >> - I have confirmed this problem on two revisions of the Dell > >>8th gen hardware in two different datacenters > >> - The problem persists on -CURRENT from 05/2010 > >> - RELENG_7 does not seem to be impacted > >> - More stats below. > >> > >> > >> Thanks, > >> ~BAS > >> > >> --- > >> > >> > >> > >> em1: link state changed to DOWN > >> em1: link state changed to UP > >> em1: link state changed to DOWN > >> em1: link state changed to UP > >> em1: link state changed to DOWN > >> em1: link state changed to UP > >> em1: link state changed to DOWN > >> em1: link state changed to UP > >> em1: link state changed t
Re: em(4) duplex problems with 82541EI on RELENG_8, -CURRENT on PowerEdge 1850
On Tue, Jun 1, 2010 at 2:37 PM, Jeremy Chadwick wrote: > On Tue, Jun 01, 2010 at 03:18:39PM -0400, Brian A. Seklecki wrote: >> = Re-posted from freebsd-hardware@, since this is more of a bug >> report than a hardware comparability inquiry / buying strategy >> discussion. == >> >> All: >> >> Has anyone upgraded their PowerEdge 1850s to 8.0-PL or >> RELENG_8 -stable? We're seeing problems where 7.2-PL and >> 6.3-PL were not affected on the same hardware. >> >> The problem is that forcing the duplex 100/full on both >> sides no longer functions. >> >> Configuration: >> >> - A variety of Cisco L2/L3 switches over the last decade: >> -- 2848G-L3 >> -- 2950 >> -- 2960s >> -- 3550-12Ts >> -- 3550XLs >> -- Duplex forced 100/full on Cisco side >> - FreeBSD/amd64 RELENG_8 or 9-CURRENT with duplex >> forced '100baseTX mediaopt full-duplex', >> - This configuration has worked since FreeBSD 5.4 >> >> When connected to PowerEdge 1850r1/r2, with the onboard Intel >> 82541EI, the parenthesis show an actual media speed/duplex of: >> >> media: Ethernet 100baseTX (100baseTX ) >> >> The same configuration using a Dell-sold Intel dual port >> 82546EB, in the same system, on the same switch, works fine. >> >> >> - >> ifconfig(8): >> - >> em3: flags=8843> MULTICAST> metric 0 mtu 1500 >> options=9b >> ether 00:13:72:4f:70:81 >> inet 192.168.97.20 netmask 0xff80 broadcast 192.168.97.127 >> media: Ethernet 100baseTX (100baseTX ) >> status: active >> - >> em0: flags=8843> MULTICAST> metric 0 mtu 1500> >> options=9b >> ether 00:04:23:c8:fe:ac >> media: Ethernet 100baseTX >> status: active >> - >> - >> pciconf(8): >> - >> e...@pci0:7:8:0: class=0x02 card=0x016d1028 chip=0x10768086 >> rev=0x05 hdr=0x00 >> vendor = 'Intel Corporation' >> device = 'Gigabit Ethernet Controller (82541EI)' >> class = network >> subclass = ethernet >> e...@pci0:3:11:0: class=0x02 card=0x10128086 chip=0x10108086 >> rev=0x01 >> hdr=0x00 >> vendor = 'Intel Corporation' >> device = 'Dual Port Gigabit Ethernet Controller (Copper) (82546EB)' >> class = network >> subclass = ethernet >> >> - >> >> rc.conf(5) for shits & giggles: >> >> ifconfig_em0="inet X netmask Y media 100baseTX mediaopt full-duplex" >> ifconfig_em3="inet Z netmask F media 100baseTX mediaopt full-duplex" >> >> >> >> Example IOS switch config: >> interface FastEthernet0/39 >> description I hate Dell >> switchport access vlan 100 >> switchport mode access >> speed 100 >> duplex full >> spanning-tree portfast >> end >> >> >> I've been clearing interface counters on the switch side, but I'll send >> 'netstat -i', 'show interface counters', and 'sudo sysctl -w >> dev.em.3.stats=1' ASAP to illustrate connectivity errors soon. >> >> Are we being punished for patronizing Dell? >> >> Is it possible that ifconfig(8) output has simply changed? Are the >> values in the parenthesis on the right the Ethernet auto-sense desired >> values where as outside the parenthesis the current active values? >> >> In 6.3/7.2, once you forced a speed/duplex, the values in parenthesis >> went away entirely. >> >> The only way I've been able to make that happen is to #define in >> src/sys/dev/e1000/if_em.h: >> >> #define DO_AUTO_NEG 0 >> /* >> * This parameter control whether or not the driver will wait for >> * autonegotiation to complete. >> * 1 - Wait for autonegotiation to complete >> * 0 - Don't wait for autonegotiation to complete >> */ >> >> Also seems odd that some ICs are affected but not others. >> >> Its also possible that my problems are pf(4) + setfib(8) related and I >> that this is a separate issue. >> >> Two new notes since the original post: >> >> - I have confirmed this problem on two revisions of the Dell >> 8th gen hardware in two different datacenters >> - The problem persists on -CURRENT from 05/2010 >> - RELENG_7 does not seem to be impacted >> - More stats below. >> >> >> Thanks, >> ~BAS >> >> --- >> >> >> >> em1: link state changed to DOWN >> em1: link state changed to UP >> em1: link state changed to DOWN >> em1: link state changed to UP >> em1: link state changed to DOWN >> em1: link state changed to UP >> em1: link state changed to DOWN >> em1: link state changed to UP >> em1: link state changed to DOWN >> em1: link state changed to UP >> em1: link state changed to DOWN >> >> em0: Excessive collisions = 0 >> em0: Sequence errors = 0 >> em0: Defer count = 0 >> em0: Missed Packets = 0 >> em0: Receive No Buffers = 0 >> em0: Receive Length Errors = 0 >> em0: Receive errors = 0 >> em0: Crc errors = 0 >> em0: Alignment errors = 0 >> em0: Collision/Carrier extension errors = 0 >> em0: RX overruns = 0 >> em0: watchdog timeouts = 0 >> em
Re: em(4) duplex problems with 82541EI on RELENG_8, -CURRENT on PowerEdge 1850
On Tue, Jun 01, 2010 at 03:18:39PM -0400, Brian A. Seklecki wrote: > = Re-posted from freebsd-hardware@, since this is more of a bug > report than a hardware comparability inquiry / buying strategy > discussion. == > > All: > > Has anyone upgraded their PowerEdge 1850s to 8.0-PL or > RELENG_8 -stable? We're seeing problems where 7.2-PL and > 6.3-PL were not affected on the same hardware. > > The problem is that forcing the duplex 100/full on both > sides no longer functions. > > Configuration: > >- A variety of Cisco L2/L3 switches over the last decade: >-- 2848G-L3 >-- 2950 >-- 2960s >-- 3550-12Ts >-- 3550XLs >-- Duplex forced 100/full on Cisco side >- FreeBSD/amd64 RELENG_8 or 9-CURRENT with duplex > forced '100baseTX mediaopt full-duplex', >- This configuration has worked since FreeBSD 5.4 > > When connected to PowerEdge 1850r1/r2, with the onboard Intel > 82541EI, the parenthesis show an actual media speed/duplex of: > > media: Ethernet 100baseTX (100baseTX ) > > The same configuration using a Dell-sold Intel dual port > 82546EB, in the same system, on the same switch, works fine. > > > - > ifconfig(8): > - > em3: flags=8843 MULTICAST> metric 0 mtu 1500 > options=9b > ether 00:13:72:4f:70:81 > inet 192.168.97.20 netmask 0xff80 broadcast 192.168.97.127 > media: Ethernet 100baseTX (100baseTX ) > status: active > - > em0: flags=8843 MULTICAST> metric 0 mtu 1500> > options=9b > ether 00:04:23:c8:fe:ac > media: Ethernet 100baseTX > status: active > - > - > pciconf(8): > - > e...@pci0:7:8:0: class=0x02 card=0x016d1028 chip=0x10768086 > rev=0x05 hdr=0x00 > vendor = 'Intel Corporation' > device = 'Gigabit Ethernet Controller (82541EI)' > class = network > subclass = ethernet > e...@pci0:3:11:0: class=0x02 card=0x10128086 chip=0x10108086 rev=0x01 > hdr=0x00 >vendor = 'Intel Corporation' >device = 'Dual Port Gigabit Ethernet Controller (Copper) (82546EB)' >class = network >subclass = ethernet > > - > > rc.conf(5) for shits & giggles: > > ifconfig_em0="inet X netmask Y media 100baseTX mediaopt full-duplex" > ifconfig_em3="inet Z netmask F media 100baseTX mediaopt full-duplex" > > > > Example IOS switch config: > interface FastEthernet0/39 > description I hate Dell > switchport access vlan 100 > switchport mode access > speed 100 > duplex full > spanning-tree portfast > end > > > I've been clearing interface counters on the switch side, but I'll send > 'netstat -i', 'show interface counters', and 'sudo sysctl -w > dev.em.3.stats=1' ASAP to illustrate connectivity errors soon. > > Are we being punished for patronizing Dell? > > Is it possible that ifconfig(8) output has simply changed? Are the > values in the parenthesis on the right the Ethernet auto-sense desired > values where as outside the parenthesis the current active values? > > In 6.3/7.2, once you forced a speed/duplex, the values in parenthesis > went away entirely. > > The only way I've been able to make that happen is to #define in > src/sys/dev/e1000/if_em.h: > > #define DO_AUTO_NEG 0 > /* >* This parameter control whether or not the driver will wait for >* autonegotiation to complete. >* 1 - Wait for autonegotiation to complete >* 0 - Don't wait for autonegotiation to complete > */ > > Also seems odd that some ICs are affected but not others. > > Its also possible that my problems are pf(4) + setfib(8) related and I > that this is a separate issue. > > Two new notes since the original post: > > - I have confirmed this problem on two revisions of the Dell >8th gen hardware in two different datacenters > - The problem persists on -CURRENT from 05/2010 > - RELENG_7 does not seem to be impacted > - More stats below. > > > Thanks, > ~BAS > > --- > > > > em1: link state changed to DOWN > em1: link state changed to UP > em1: link state changed to DOWN > em1: link state changed to UP > em1: link state changed to DOWN > em1: link state changed to UP > em1: link state changed to DOWN > em1: link state changed to UP > em1: link state changed to DOWN > em1: link state changed to UP > em1: link state changed to DOWN > > em0: Excessive collisions = 0 > em0: Sequence errors = 0 > em0: Defer count = 0 > em0: Missed Packets = 0 > em0: Receive No Buffers = 0 > em0: Receive Length Errors = 0 > em0: Receive errors = 0 > em0: Crc errors = 0 > em0: Alignment errors = 0 > em0: Collision/Carrier extension errors = 0 > em0: RX overruns = 0 > em0: watchdog timeouts = 0 > em0: RX MSIX IRQ = 0 TX MSIX IRQ = 0 LINK MSIX IRQ = 0 > em0: XON Rcvd = 0 > em0: XON Xmtd = 0 > em0: XOFF Rcvd = 0 > em0: XOFF Xmtd = 0 > em0: Good Packets Rcvd = 1319916 > em0: Good