Jason THorpe writes:
> Jonathan Stone <jonathan@DSG.Stanford.EDU> wrote:
> > Are you sure that just setting the ANAR is sufficient to
> > trigger re-negotiation?
>
>Uh, if the LEDs on the Intel end were still wrong, then the PHY didn't
>even get programmed into 10baseT mode correctly.

Okay.  I tried this with a -current that's a few days old.  The fxp
interface (fxp2) LEDs show that the NetBSD driver realy is doing the
right thing: no problem there, AFAICT.

There's a small annoyance going down to 10Mbit/sec. The 100Mbit LED on
fxp2 goes out, but the hub doesnt sense the change until fxp2 sends
traffic -- e.g., an outgoing ping.  The real problem is trying
to go from 10Mbit back up to 100Mbit. From 10Mbut Doing 

	ifconfig fxp2 media 100baseTX

does the right thing with the LED on fxp2, but the hub lights are
still out: my guess is, it still thinks the link has failed.  Pulling
the cable fixes it; when reconnected, the hub lights go to 100Mbit.
BUT, so does issuing

	ifconfig fxp2 media auto

I assume because that initiates an Nway cycle?

Looks like the driver is DTRT with the NIC speed, and the lights
suggest the NetGear hub is noticing link-fail, but the hub isnt
restarting NWay.  (Or maybe it is, but either times out or starts
too late?)

So, is it okay for the driver to force the NIC to start an NWAY cycle,
after the driver changes the advertized media (in the APAR or whatever
its called?)  The 802.3 text Matthias quoted seems like that'd be OK,
and to me it sounds more robust than what we do now. (Yes, better hubs
would be nice, but...)  Jason, does that sound okay to you?