Re: alc(4) link autoselect problem

On Thu, Oct 08, 2009 at 12:38:45PM +0200, Ian FREISLICH wrote:
> Pyun YongHyeon wrote:
> > The atphy(4) recognizes PHY as F1 gigabit PHY because AR8132 uses
> > the same PHY id of F1 gigabit PHY. There is no way to know whether
> > it really has F1 gigabit PHY in driver's view.
> > 
> > > If I set the media to 100BaseTX full-duplex it works.
> > 
> > If link parter used auto-negotiation, this forced media selection
> > shall make your link partner select half-duplex mode instead of
> > full-duplex due to the nature of parallel detection.
> 
> When I do this:
> [mini] /usr/home/ianf # ifconfig alc0 media 100BaseTX mediaopt full-duplex
> 
> I get this on the switch:
> 
> 08-Oct-2009 12:26:42 %STP-W-PORTSTATUS: g14 of instance 0: STP status Forwarding
> 08-Oct-2009 12:26:42 %STP-W-PORTSTATUS: g14 of instance 1: STP status Forwarding
> 08-Oct-2009 12:26:42 %STP-W-PORTSTATUS: g14 of instance 2: STP status Forwarding
> 08-Oct-2009 12:26:42 %LINK-I-Up:  g14
> 
> wgsw-24010# sh interfaces status ethernet g14
>                                              Flow Link          Back   Mdix
> Port     Type         Duplex  Speed Neg      ctrl State       Pressure Mode
> -------- ------------ ------  ----- -------- ---- ----------- -------- -------
> g14      1G-Copper    Full    100   Enabled  Off  Up          Disabled Off    
> 

Hmm, does your switch have an option to enable/disable downshifting
feature? If so, how about toggling the option?

> So, it correctly detects full duplex.
> 
> The cable tester still reports the cable os open at 2m, probably
> because it expects all 4 pairs to be terminated.
> 


[...]

> > How about checking MIB statistics of controller?
> > (sysctl dev.alc.0.stats)
> 
> This is after a reboot, but the link was up for a short while to
> do the above testing.  rx.good_frames looks a bit high for "up 21
> mins".
> 
> dev.alc.0.stats.rx.good_frames: 3348588249
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> dev.alc.0.stats.rx.good_bcast_frames: 0
> dev.alc.0.stats.rx.good_mcast_frames: 0
> dev.alc.0.stats.rx.pause_frames: 0
> dev.alc.0.stats.rx.control_frames: 0
> dev.alc.0.stats.rx.crc_errs: 0
> dev.alc.0.stats.rx.len_errs: 0
> dev.alc.0.stats.rx.good_octets: 0
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Yeah, that looks odd, it seemed controller received a lot of good
frames but none were meaningful packets so I guess there are link
establishment issues. I still have no clue but if I manage to find
more test case I will let you know.

> dev.alc.0.stats.rx.good_bcast_octets: 0
> dev.alc.0.stats.rx.good_mcast_octets: 0

[...]