From owner-freebsd-current@FreeBSD.ORG Thu Oct 8 17:06:14 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B895410656A6 for ; Thu, 8 Oct 2009 17:06:14 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.156]) by mx1.freebsd.org (Postfix) with ESMTP id 4231A8FC14 for ; Thu, 8 Oct 2009 17:06:13 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id 16so2028826fgg.13 for ; Thu, 08 Oct 2009 10:06:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=A7IfOnn76JrcPJ3kURguy2TYeRs/cqJb1PKKl8y8qLE=; b=pluCvqqZIk0tmYGIMmjZrULbP9bKIEZBJjatmUR8HxnVC6OYiY/GhIzUxdzpYBdhy7 P5RLrsav3y1Zxn/GvZlwPH4kj3GhpV/X1G33DphmYHZFFrClApbRpfgWxpNYSGdVdQh5 UCetYYolINKWpArS0MUSA97ySBJW+Zqx+MdsM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=cpTwQNbKFzF9g/vI8KHtpVmdSSFM2KAhMFPwdNS1vpEFOdsxqyhUgs3UqyRiTZR2VV uTyAAC+YcuWtMkBxhqMAOQU+P7S7n6u0mJOD1gqZRZaaL2H2u4AzOhqSHNo6h3B0FR7s 5C93KI9K+9420GQzyuhAVx0/QWyFRZZz2K3KI= Received: by 10.86.173.4 with SMTP id v4mr1375473fge.78.1255021573107; Thu, 08 Oct 2009 10:06:13 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 4sm104111fgg.28.2009.10.08.10.06.09 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 08 Oct 2009 10:06:10 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Thu, 8 Oct 2009 10:04:58 -0700 From: Pyun YongHyeon Date: Thu, 8 Oct 2009 10:04:58 -0700 To: Ian FREISLICH Message-ID: <20091008170458.GC3843@michelle.cdnetworks.com> References: <20091007180257.GA3843@michelle.cdnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: current@freebsd.org Subject: Re: alc(4) link autoselect problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2009 17:06:14 -0000 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 [...]