From owner-freebsd-amd64@FreeBSD.ORG Wed Jan 12 00:28:28 2011 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BCE65106564A for ; Wed, 12 Jan 2011 00:28:28 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 40AB48FC0C for ; Wed, 12 Jan 2011 00:28:27 +0000 (UTC) Received: by iwn39 with SMTP id 39so15854iwn.13 for ; Tue, 11 Jan 2011 16:28:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:date:to:cc:subject:message-id:reply-to :references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=VhKxXWup0YH3TWSTxhXmXBIBvfBZoikTonbxsJRONm8=; b=aBiZBJNuzFBw+h1zl4fyBaI2gSgRpv+R7mvL6/pW+a8ZJMKuqAZAGMV9OoEmQPkuY9 KwRDbPxR3Z+fh+nzThh1XgM9OnGXrp+w0CbM5YGXxQANYrWMguYpvRYuJhFfjHwrv1Oc Sf4yE/mBSERj7O2XB0blUd3Du2cPZjgd5egvA= 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=XZH/H6kflcpABmOllNOLIk2oZDyKR1481Y5hTFXt37NUqmhOp0jO4fzvM5PChPsE5C sQn4D8Jj2he9LE+IlqScunXdD7avjhS57fjHWrd6F9foQ3IA4YJkUAmwXQJfBjipn2yd pG0y2mIbiCWNRqp+n0qDEPl/Jh7QG1LAFHWUs= Received: by 10.231.36.137 with SMTP id t9mr259438ibd.195.1294792107632; Tue, 11 Jan 2011 16:28:27 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id i16sm56613ibl.6.2011.01.11.16.28.25 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 11 Jan 2011 16:28:26 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Tue, 11 Jan 2011 16:27:51 -0800 From: Pyun YongHyeon Date: Tue, 11 Jan 2011 16:27:51 -0800 To: fbsdmail@dnswatch.com Message-ID: <20110112002751.GE6278@michelle.cdnetworks.com> References: <30661ab452bce4de56f3e80f8682222a.dnswclient@www.dnswatch.com> <20110111183315.GA6278@michelle.cdnetworks.com> <1682d2c7ead29c3c80ad0676f61beb2c.dnswclient@www.dnswatch.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1682d2c7ead29c3c80ad0676f61beb2c.dnswclient@www.dnswatch.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-amd64@freebsd.org Subject: Re: tx v2 error 0x6204 - is this a new feature? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2011 00:28:28 -0000 On Tue, Jan 11, 2011 at 04:16:45PM -0800, fbsdmail@dnswatch.com wrote: > > On Tue, January 11, 2011 10:33 am, Pyun YongHyeon wrote: [...] > >>>> Does the link partner also agree on the resolved > >>>> duplex(half-duplex)? It's not common to see half-duplex in these > >>>> days. Please make sure link partner is also using auto-negotiation. > >>>> > >>>> > >>>> > >>> > >>> I thought that odd, as well. Both kerns have as nearly the same > >>> options as is possible. Because the 8.1/amd64 is intended as a > >>> replacement for the 8.0/i386. They're both on the same switch. > >>> > >> > >> OK. Sorry, it just occurred to me that they /aren't/ both 10/100's > >> The 8.1/amd64 (nfe0) is 10/100/1000, which might account for the > >> half-dup. Just thought I'd mention it - but I'm sure you already > >> discovered that :P > >> > > > > I don't know any auto-negotiation issues of ciphy(4) so please > > verify whether the switch sees the same resolved speed/duplex. If you > > manually configured switch port to use 100Mbps/full-duplex it would create > > problems since resolved duplex for the parallel detection is normally > > half-duplex. This will cause duplex mismatch and you will see lots of > > unexpected problems. If both parties use the same forced media > > configuration in 10/100Mbps mode it would work but nfe(4) has one > > unresolved issue for that case(mainly due to lack of documentation). > > Without > > auto-negotiation, some nfe(4) controllers do not work correctly. > > > > nfe(4) also supports hardware MAC counters for supported controllers and I > > think your controller supports that. See what counters you have with > > "sysctl dev.nfe.0.stats". > I'm going to be away for a couple of hours. > Here's a dump of sysctl dev.nfe.0.stats, in the meantime: > > dev.nfe.0.stats.rx.frame_errors: 0 > dev.nfe.0.stats.rx.extra_bytes: 0 > dev.nfe.0.stats.rx.late_cols: 0 > dev.nfe.0.stats.rx.runts: 0 > dev.nfe.0.stats.rx.jumbos: 0 > dev.nfe.0.stats.rx.fifo_overuns: 0 > dev.nfe.0.stats.rx.crc_errors: 0 > dev.nfe.0.stats.rx.fae: 0 > dev.nfe.0.stats.rx.len_errors: 0 > dev.nfe.0.stats.rx.unicast: 711887 > dev.nfe.0.stats.rx.multicast: 0 > dev.nfe.0.stats.rx.broadcast: 36072 > dev.nfe.0.stats.tx.octets: 400617598 > dev.nfe.0.stats.tx.zero_rexmits: 420611 > dev.nfe.0.stats.tx.one_rexmits: 171560 > dev.nfe.0.stats.tx.multi_rexmits: 64390 Two counters above clearly indicates there are collisions in link. Check switch configuration and make it use auto-negotiation. > dev.nfe.0.stats.tx.late_cols: 0 > dev.nfe.0.stats.tx.fifo_underuns: 0 > dev.nfe.0.stats.tx.carrier_losts: 0 > dev.nfe.0.stats.tx.excess_deferrals: 0 > dev.nfe.0.stats.tx.retry_errors: 182 > > Thank you for all your time and consideration Pyun YongHyeon. > > --Chris