Bug 228852 - e1000 back-to-back unable to negotiate link...
Summary: e1000 back-to-back unable to negotiate link...
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: CURRENT
Hardware: amd64 Any
: --- Affects Some People
Assignee: Stephen Hurd
URL:
Keywords: iflib
Depends on:
Blocks:
 
Reported: 2018-06-09 19:26 UTC by Sean Chittenden
Modified: 2018-06-19 13:50 UTC (History)
5 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Sean Chittenden freebsd_committer freebsd_triage 2018-06-09 19:26:13 UTC 
Using two back-to-back e1000 Ethernet adapters, neither NIC negotiates to up.  The max link speed is 100baseTX but setting auto-negotiate refuses to establish link.  This may be an MDI-X problem.

CC shurd@

% doas ifconfig em0 media 1000baseT mediaopt full-duplex
% ifconfig em0
em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
	options=85259b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,LRO,WOL_MAGIC,VLAN_HWFILTER,VLAN_HWTSO>
	ether 50:7b:9d:a3:d9:d0
	inet6 fe80::527b:9dff:fea3:d9d0%em0 prefixlen 64 scopeid 0x1 
	inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255 
	nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
	media: Ethernet 1000baseT <full-duplex> (autoselect)
	status: no carrier
Comment 1 Eugene Grosbein freebsd_committer freebsd_triage 2018-06-10 23:50:05 UTC 
What is a cable are you using to test?
Number of twisted pairs, category and lenght?

Make sure the cable is not too short, at least 1.5 meters, better 2 meters. It is common mistake to use too short cable for gigabit link, it won't work reliably.
Comment 2 Sean Bruno freebsd_committer freebsd_triage 2018-06-12 14:13:58 UTC 
(In reply to Eugene Grosbein from comment #1)
We discussed this at BSDCan.

I know this does *not* happen with Intel 82574 chips as I test with this all the time.

I'm assuming this will be the case on newer chipsets.
Comment 3 Rodney W. Grimes freebsd_committer freebsd_triage 2018-06-12 14:36:14 UTC 
(In reply to Sean Bruno from comment #2)
Last time I seen this type of problem it was more to do with the MII chip used and less to do with the controller chip.
So could everyone please report which MII they have, or does the Intel 82574 have an embedded MII?
Comment 4 Eric Joyner freebsd_committer freebsd_triage 2018-06-13 23:50:30 UTC 
We're going to need the specific device that's being used, either by name or PCI ID.
Comment 5 Sean Chittenden freebsd_committer freebsd_triage 2018-06-15 05:41:25 UTC 
(In reply to Eric Joyner from comment #4)

```
em0@pci0:0:31:6:        class=0x020000 card=0x223317aa chip=0x156f8086 rev=0x21 hdr=0x00
    vendor     = 'Intel Corporation'
    device     = 'Ethernet Connection I219-LM'
    class      = network

em0: <Intel(R) PRO/1000 Network Connection> mem 0xe1200000-0xe121ffff at device 31.6 on pci0
em0: attach_pre capping queues at 1
em0: using 1024 tx descriptors and 1024 rx descriptors
em0: msix_init qsets capped at 1
em0: PCIY_MSIX capability not found; or rid 0 == 0.
em0: Using an MSI interrupt
em0: allocated for 1 tx_queues
em0: allocated for 1 rx_queues
em0: Ethernet address: 50:7b:9d:a3:d9:d0
em0: netmap queues/slots: TX 1/1024, RX 1/1024
```
Comment 6 Sean Bruno freebsd_committer freebsd_triage 2018-06-19 13:50:52 UTC 
(In reply to Sean Chittenden from comment #5)
If this is in a back-to-back configuration, don't we need to know the PCI IDs of both sides?