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 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 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 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=revisionrevision=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 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 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
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 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
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
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 kor...@comcast.net 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
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
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
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
On Tue, Jun 1, 2010 at 2:37 PM, Jeremy Chadwick free...@jdc.parodius.com 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 full-duplex (100baseTX half-duplex) 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=8843UP,BROADCAST,RUNNING,SIMPLEX, \r MULTICAST metric 0 mtu 1500 options=9bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM ether 00:13:72:4f:70:81 inet 192.168.97.20 netmask 0xff80 broadcast 192.168.97.127 media: Ethernet 100baseTX full-duplex (100baseTX half-duplex) status: active - em0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,\ MULTICAST metric 0 mtu 1500 options=9bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM ether 00:04:23:c8:fe:ac media: Ethernet 100baseTX full-duplex 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
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 jamesbrandongo...@gmail.com wrote: On Tue, Jun 1, 2010 at 2:37 PM, Jeremy Chadwick free...@jdc.parodius.com 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 full-duplex (100baseTX half-duplex) 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=8843UP,BROADCAST,RUNNING,SIMPLEX, \r MULTICAST metric 0 mtu 1500 options=9bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM ether 00:13:72:4f:70:81 inet 192.168.97.20 netmask 0xff80 broadcast 192.168.97.127 media: Ethernet 100baseTX full-duplex (100baseTX half-duplex) status: active - em0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,\ MULTICAST metric 0 mtu 1500 options=9bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM ether 00:04:23:c8:fe:ac media: Ethernet 100baseTX full-duplex 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
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 full-duplex (100baseTX half-duplex) 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=8843UP,BROADCAST,RUNNING,SIMPLEX, \r MULTICAST metric 0 mtu 1500 options=9bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM ether 00:13:72:4f:70:81 inet 192.168.97.20 netmask 0xff80 broadcast 192.168.97.127 media: Ethernet 100baseTX full-duplex (100baseTX half-duplex) status: active - em0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,\ MULTICAST metric 0 mtu 1500 options=9bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM ether 00:04:23:c8:fe:ac media: Ethernet 100baseTX full-duplex 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 =
