issues with Intel Pro/1000 and 1000baseTX
pyunyh at gmail.com
Fri May 15 04:15:19 UTC 2009
On Thu, May 14, 2009 at 11:54:00AM -0400, Bill Moran wrote:
> In response to James Tanis <jtanis at mdchs.org>:
> > I have a FreeBSD v7.0 box it has two Intel Pro/1000 NICs, the one in
> > question is:
> > em1: <Intel(R) PRO/1000 Network Connection Version - 6.7.3> port
> > 0x2020-0x203f mem 0xd8060000-0xd807ffff,0xd8040000-0xd805ffff irq 19 at
> > device 0.1 on pci4
> > what we get after boot is:
> > em1: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0
> > mtu 1500
> > options=19b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4>
> > ether 00:30:48:xx:xx:xx
> > inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255
> > media: Ethernet autoselect (100baseTX <full-duplex>)
> > status: active
> > The problem is that the NIC refuses to connect at 1000baseTX.
> > It's connected to a HP Procurve 1700-24 switch which supports 1000baseTX
> > on ports 23 and 24. This particular computer is connected on port 24. I
> > have a much older end user system which uses the same card (but earlier
> > revision), runs Windows XP and is plugged in to port 23. The end user
> > system has no problem connecting at 1000baseTX. I have of course tried
> > switching ports.
> > Attempting to force 1000baseTX via:
> > ifconfig em1 media 1000baseTX mediaopt full-duplex
> > gets me:
> > status: no carrier
> > After forcing the NIC to go 1000baseTX the LEDs on the backpane are both
> > off. I can only come to the conclusion that this is a driver issue based
> > on previous experience and the simple fact that the end user system is
> > capable of connecting at 1000baseTX. Anybody have any suggestions? I'm
> > hoping I'm wrong. I'd rather not do an in-place upgrade, this is a
> > production system and the main gateway for an entire school, when I do
> > not even know for sure whether this will fix the problem. It's worth it
> > to me though, having a 1000baseTX uplink from the switch would remove a
> > major bottleneck for me.
> While it's _possible_ that this is a driver issue, it's much more likely
> (in my experience) that it's a mismatch between the two network devices
> (the HP and the NIC).
> Try forcing on both ends (I assume the Procurve will allow you to do that).
> One thing I've seen consistently is that if you force the speed/duplex on
> one end, the other end will still try to autoneg, and will end up with
> something stupid like 100baseT/half-duplex, or will give up and disable
No, this is not a stupid thing, it's result of parallel detection.
See IEEE 802.3 Std 188.8.131.52 for more details. This is one of reason
why users should always use 'auto-negotiation' on 1000baseT media.
> the port.
> Also, try autoneg on both ends. Make absolutely sure the Procurve is set
> to autoneg.
> Replace the cable. If the cable is marginal, autoneg will downgrade the
> speed to ensure reliability. Use a cable that you know will produce
> 1000baseTX because you've tested it on other systems.
> Try switching out the NIC. Manufacturing QA isn't 100% reliable, sometimes
> you get a card that's just flaky.
> Hope this helps.
> Bill Moran
More information about the freebsd-questions