Re: wm(4) won't negotiate 1000-base-T with Cisco switches and won't operate with manual media settings

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

On Thu, Nov 24, 2011 at 04:34:32AM -0800, Brian Buhrow wrote:
>       hello.  I've been running the following chips under NetBSD 4.x for a
> number of years at 100mbits/sec without any problems at all.  However,
> recently, when I tried to link one of these up to a gige port on a Cisco
> ME3400 switch, it failed to establish link.  If left to autonegotiate, it
> establishes a link with the Cisco at 100mbits/sec, but forcing either side,
> or both sides to 1000-base-t causes the network status to be set to no
> carrier.  Worse, it appears that seting the media to anything other than
> auto or 100baseTX or 100baseTX mediaopt full-duplex doesn't work.
>       notes from the FreeBSD Intel E1000 driver hint that this might be one 
> of the
> problematic chips which fails to establish link with certain link partners,
> a sentiment echoed by their notes for the Windows drivers as well.
>       To make sure I've covered my bases, I booted a monolithic kernel from
> the snapshot at nyftp.netbsd.org dated: 201111220010Z with the same
> results.  All works fine if all I need is 100mbits/sec, but if I want to
> set the media to anything else, no dice, including 10baseT.
>       Does anyone know what the specific bug is in this hardware to cause
> the dire notes in Intel's README files?  I spent a good deal of time
> looking at and playing with the if_wm(4) driver in an effort to understand
> what it's doing, since I did almost this same thing for 1000-base-SX if_wm
> cards about 5 years ago, but I'm having a lot of trouble understanding the
> relationship between the mii layer, the phy driver and the if_wm driver
> itself.  After pouring over the e1000 driver in FreeBSD-8, I'm not
> convinced we're doing the right things with the phy, but I'm not sure
> enough of the hardware to know if it's a driver bug or a hardware bug.  As
> an extra data point, the 1000-base-T mode isn't completely broken in that I
> have one site using this chip negotiating 1000-base-T full-duplex with a
> Force10 switch.  Again, if we try to nail it, it doesn't work, but autoneg
> does the right thing in this instance.
> 
>       Does anyone have any ideas, documents i should read, or patches
> floating around that I should try?  I can file a pr, and I will, but I
> thought I'd ask here first.
>       Oh, yes, this is under I386, both NetBSD-4 as of early 2008, and the
> NetBSD-current snapshot noted above.
> 
> -thanks
> -Brian
> 
> 
> wm0 at pci0 dev 5 function 0: Intel i82541GI 1000BASE-T Ethernet, rev. 5
> wm0: interrupting at ioapic0 pin 16 (irq 5)
> wm0: 32-bit 66MHz PCI bus
> wm0: 64 word (6 address bits) MicroWire EEPROM
> wm0: Ethernet address 00:30:18:xx:xx:xx
> igphy0 at wm0 phy 1: Intel IGP01E1000 Gigabit PHY, rev. 0
> igphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT,
> 1000baseT-FDX


I have:
wm0 at pci6 dev 7 function 0: Intel i82541GI 1000BASE-T Ethernet, rev. 5
wm0: interrupting at ioapic2 pin 0
wm0: 32-bit 66MHz PCI bus
wm0: 65536 word (16 address bits) SPI EEPROM
wm0: Ethernet address 00:14:22:19:17:73
igphy0 at wm0 phy 1: Intel IGP01E1000 Gigabit PHY, rev. 0
igphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 
1000baseT-FDX, auto

running netbsd-5. It has no problems negociating gigabit speed with
a cisco 6000 of some sort, and a cisco 3750G.

-- 
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--