Re: Fix for kern/20700

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

On Wed, Dec 07, 2011 at 10:45:30AM -0800, Brian Buhrow wrote:
>       Hello.  After working on this problem for a while, I propose
> committing the diff below as a fix for this bug.  The problem of
> negotiating link at a speed other than the 1000-base-T remains, but see
> below for my reasoning on this topic.
> 
>       the current state of affairs is that Nway autonegotiation works for
> twisted pair copper connections.  Nailed up speed requests work with 10 and
> 100mbit connections, but will never work with 1000-base-T connections,
> unless the chip has initialized, and hence negotiated, a connection before
> ifconfig is called in the boot sequence.
> 
>       What this patch does is turn on Nway autonegotiation when the user
> requests 1000baset with ifconfig and turn off advertisements for speeds
> other than 1000baset in the Nway autonegotiation process.  This makes 
> 1000baset nailed links work, which, in my view, is the behavior of least
> astonishment.
> 
>       Because of the race between Nway negotiation and parallel detection,
> which Thor alluded to earlier in this thread, I've found it very difficult
> to prevent the chip from establishing link with its partners at speeds
> other than the requested speed without totally disabling the ability for
> the link to come up again on its own once the proper speeds and duplexes
> were configured on both ends of the link.  I experimented with disallowing
> the interface from passing traffic if the link speed didn't match the
> requested speed, but that seemed even less intuitive, since ifconfig would
> show the interface as being active, but wouldn't actually work.  Finally,
> I figured out that I could probably implement the requested behavior to fix
> this bug completely, but to do so would require that I touch every phy
> driver in the system, creating a huge patch and a larger testing problem.
> 
>       In summary, in my view, this patch improves the state of the world,
> permitting more configuration cases to work than do today, as well as
> causing the system to behave in less astonishing ways than it does today.
> Right now, if you get a link at 1000baset when the system boots, and you
> don't have autonegotiation configured, if you pull the plug or otherwise
> bounce the port, you have to reboot or turn autonegotiation on to
> re-establish link.  this patch insures that you'll get a restoration of
> service, regardless of how you set ifconfig, without user intervention.
> 
>       If folks don't strongly object, I'll commit this patch in the next
> week or so and request a pullup for the 5.x branch.  If someone has an idea
> for fully implementing the requested behavior without having to touch all
> the phy drivers, I'm very interested and will be happy to implement and
> test.


I've tested with a:
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:13:72:54:ee:13
igphy0 at wm0 phy 1: Intel IGP01E1000 Gigabit PHY, rev. 0

connected to a cisco 3750 gigabit switch.
This works as expected: with ifconfig wm0 media 1000baseT,
I get a link up when the cisco is set up with speed auto, speed auto 1000
and speed 1000, and no link with anything else on the cisco side.

I also get a working link if I do
ifconfig wm0 media 100baseTX mediaopt full-duplex on the NetBSD side and
speed 100
duplex full
on the cisco side.

So everything works as I'd expect.

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