Date: Thu, 8 Oct 2009 10:04:58 -0700 From: Pyun YongHyeon <pyunyh@gmail.com> To: Ian FREISLICH <ianf@clue.co.za> Cc: current@freebsd.org Subject: Re: alc(4) link autoselect problem Message-ID: <20091008170458.GC3843@michelle.cdnetworks.com> In-Reply-To: <E1MvqOT-0000Oo-7F@clue.co.za> References: <20091007180257.GA3843@michelle.cdnetworks.com> <E1MvPZq-000Fqu-Ti@clue.co.za> <E1MvqOT-0000Oo-7F@clue.co.za>
next in thread | previous in thread | raw e-mail | index | archive | help
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 [...]
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20091008170458.GC3843>