Re: [E1000-devel] Having link-up problems between pairs of e1000s...

[Brandeburg, J. <jes...@in...>]

Brandon Black wrote:
> -- modprobe e1000 AutoNeg=3D0x20,0x20:
> Intel(R) PRO/1000 Network Driver - version 7.6.5-NAPI
> Copyright (c) 1999-2007 Intel Corporation.
> PCI: Enabling device 0000:0c:00.0 (0140 -> 0143)
> ACPI: PCI Interrupt 0000:0c:00.0[A] -> GSI 18 (level, low) -> IRQ 185
> PCI: Setting latency timer of device 0000:0c:00.0 to 64
> e1000: 0000:0c:00.0: e1000_probe: (PCI Express:2.5Gb/s:Width x4)
> 00:15:17:35:c5:22
> e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection
> PCI: Enabling device 0000:0c:00.1 (0140 -> 0143)
> ACPI: PCI Interrupt 0000:0c:00.1[B] -> GSI 19 (level, low) -> IRQ 193
> PCI: Setting latency timer of device 0000:0c:00.1 to 64
> e1000: 0000:0c:00.1: e1000_probe: (PCI Express:2.5Gb/s:Width x4)
> 00:15:17:35:c5:23
> e1000: eth1: e1000_probe: Intel(R) PRO/1000 Network Connection
>=20
> -- ifconfig interfaces up...
> ADDRCONF(NETDEV_UP): eth0: link is not ready
> e1000: eth0: e1000_change_mtu: changing MTU from 1500 to 9000
> ADDRCONF(NETDEV_UP): eth1: link is not ready
> e1000: eth1: e1000_change_mtu: changing MTU from 1500 to 9000
>=20
> -- phy reg debug during ethtool -d eth0
> e1000: eth0: e1000_get_regs: phy 0: 0x1140
> Ane, FD, 1GB
> e1000: eth0: e1000_get_regs: phy 1: 0x7909
> Legacy adv
> e1000: eth0: e1000_get_regs: phy 2: 0x2A8
> e1000: eth0: e1000_get_regs: phy 3: 0x380
> Id reg
> e1000: eth0: e1000_get_regs: phy 4: 0xDE1
>=20
> e1000: eth0: e1000_get_regs: phy 5: 0x0
> n/a
> e1000: eth0: e1000_get_regs: phy 6: 0x4
> No fault, next page able
> e1000: eth0: e1000_get_regs: phy 7: 0x2801
>=20
> e1000: eth0: e1000_get_regs: phy 8: 0x0
> e1000: eth0: e1000_get_regs: phy 9: 0x200
> 1000T FD cap
> e1000: eth0: e1000_get_regs: phy 10: 0x0
> e1000: eth0: e1000_get_regs: phy 11: 0x0
> e1000: eth0: e1000_get_regs: phy 12: 0x0
> e1000: eth0: e1000_get_regs: phy 13: 0x0
> e1000: eth0: e1000_get_regs: phy 14: 0x0
> n/a
> e1000: eth0: e1000_get_regs: phy 15: 0x3000
> Adv 1000 fd
> e1000: eth0: e1000_get_regs: phy 16: 0x1A0
> Dis TP loopback, SMARTSPEED ENA!, preamble ena
> e1000: eth0: e1000_get_regs: phy 17: 0x4870
> 100BaseTX, crossed over, link down, rsvd bits set
> e1000: eth0: e1000_get_regs: phy 18: 0x1600
> Automdix, defaults
> e1000: eth0: e1000_get_regs: phy 19: 0x300
> Local receiver not okay, gig idle error
> e1000: eth0: e1000_get_regs: phy 20: 0x5
> ok
> e1000: eth0: e1000_get_regs: phy 21: 0xFFFF
> ?
> e1000: eth0: e1000_get_regs: phy 22: 0x0
> e1000: eth0: e1000_get_regs: phy 23: 0x850
> e1000: eth0: e1000_get_regs: phy 24: 0x514
> Not documented
> e1000: eth0: e1000_get_regs: phy 25: 0x11C
> Internal reset cleared, Link energy detect(only valid if ane and
> spd), low power in nonD0 enabled. e1000: eth0: e1000_get_regs: phy
> 26: 0x0=20
> e1000: eth0: e1000_get_regs: phy 27: 0x80
> Ss_cfg_ctr =3D 2
> e1000: eth0: e1000_get_regs: phy 28: 0x2F44
> Adv 1GFD,
> e1000: eth0: e1000_get_regs: phy 29: 0x0
> e1000: eth0: e1000_get_regs: phy 30: 0x0

brandon, I discovered looking through your results that smartspeed is
enabled in phy 16:

however, it appears that the adapter is not trying to use smartspeed
because the smartspeed counters are not incrementing.  That is the only
thing I see that could have anything to do with this problem.

Forgive me if you mentioned this before, but can you try with crossover
cables?  There are also some test modes where you can simply force 1G/FD
(will require driver hacks) to see if everything links up.  In this test
mode auto-mdix is not functional so you would have to have crossover
cables anyway.  The theory I have is that you are having trouble because
both sides are trying to figure out MDI-X or not, as well as negotiate
link training.

The registers report energy detect, so the phy knows a link partner is
there.  I'm asking around here if something else might be going on.

Jesse

PS I don't know where you got your adapters, but the eeprom version is
quite old (5.6-2) and there were quite a few changes made to the gigabit
link negotiation settings in later eeproms for 82571.  However, I'm not
sure if we can update the eeprom in an easy manner.

Jesse