From owner-freebsd-amd64@FreeBSD.ORG Tue Jan 11 18:33:54 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 91C84106564A for ; Tue, 11 Jan 2011 18:33:54 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5CA5A8FC13 for ; Tue, 11 Jan 2011 18:33:54 +0000 (UTC) Received: by pvc22 with SMTP id 22so4245164pvc.13 for ; Tue, 11 Jan 2011 10:33:53 -0800 (PST) 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=o2jw5giRQiHzlrogIqY/4ptwWGh0LTa4Y1XKXt1bIT8=; b=eugCOeaOUZKqvynR29kpsXbwU11zm/tuDIdlOCWCFffagWtVO5dVNLi6jYNOaoL7Lf ouQwiwJhlnTyWeJVSVFI4Hzu1rnvyeqNzQ1Hi5EgrVOst1b1OJM4ca567KM4/ODeQ7gM Y6rg2fW8Tdd1GIPjnV87jjiR5CVS58bHK1DpE= 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=PYJ15/5I4rRXzD1knTU0ykT3tt6S63yBZnXmSGAQ5n5uH02PtjvZIRNMcj95Meand5 Y94IVGZdMcWMJrkPn6qRyItyheXtjRWdRrLlp7IbcMggQlSwUsUctxxu6KgwxiKmXMtL IGrioNcLCjL6aCLGVdhja7VrEmgPw5DmOGUfU= Received: by 10.142.131.7 with SMTP id e7mr86512wfd.316.1294770833762; Tue, 11 Jan 2011 10:33:53 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id w14sm9537471wfd.18.2011.01.11.10.33.50 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 11 Jan 2011 10:33:50 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Tue, 11 Jan 2011 10:33:15 -0800 From: Pyun YongHyeon Date: Tue, 11 Jan 2011 10:33:15 -0800 To: fbsdmail@dnswatch.com Message-ID: <20110111183315.GA6278@michelle.cdnetworks.com> References: <30661ab452bce4de56f3e80f8682222a.dnswclient@www.dnswatch.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: 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: Tue, 11 Jan 2011 18:33:54 -0000 On Tue, Jan 11, 2011 at 01:14:49AM -0800, fbsdmail@dnswatch.com wrote: > > On Tue, January 11, 2011 1:01 am, fbsdmail@dnswatch.com wrote: > > > > > On Tue, January 11, 2011 12:42 am, Pyun YongHyeon wrote: > > > >> On Tue, Jan 11, 2011 at 12:28 AM, wrote: > >> > >> > >>> Greetings Pyun YongHyeon, and thank you for your reply. > >>> On Mon, January 10, 2011 11:40 pm, Pyun YongHyeon wrote: > >>> > >>> > >>>> On Mon, Jan 10, 2011 at 11:10 PM, ? wrote: > >>>> > >>>> > >>>> > >>>>> Greetings, > >>>>> I have been receiving these messages on a recent 8.1/AMD64 > >>>>> install. src/ports && world/kern about a week ago. Here is a block > >>>>> from the most recent output: nfe0: tx v2 error 0x6204 > >>>>> nfe0: tx v2 > >>>>> error 0x6204 > >> > >> [...] > >> > >> > >> > >>>>> nfe0: tx v2 error 0x6204 > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> It appears to only occur when transmitting largish amounts of > >>>>> data across an NFS mount. I'm not sure where the MIN-threshold > >>>>> lies. But appears to be >=1.5Mb. This fresh 8.1/AMD64 is part of a > >>>>> largish server farm comprised of 7+ - 8.0 i386 servers. This one > >>>>> is the only AMD64. It > >>>>> is also the only AMD64. I experience this when mounting an > >>>>> 8.0/i386 > >>>>> server from this 8.1/AMD64. The i386 also has mounts on this > >>>>> 8.1/AMD64. > >>>>> relevant info: ### 8.0/i386 8.0-STABLE FreeBSD 8.0-STABLE #0: > >>>>> /usr/obj/usr/src/sys/UDNS01 ?i386 > >>>>> Tyan 2-CPU MB > >>>>> 2 NIC's: fxp0 (only one in use) > >>>>> ### 8.1/AMD64 > >>>>> FreeBSD 8.1-RELEASE-p2 #0: /usr/obj/usr/src/sys/XII amd64 > >>>>> MSI K9N4 Ultra > >>>>> CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ (3511.34-MHz > >>>>> K8-class > >>>>> CPU) > >>>>> 1 NIC nfe0 > >>>>> ### common to both: > >>>>> rc.conf nfs_client_enable="YES" nfs_reserved_port_only="YES" > >>>>> nfs_server_enable="YES" > >>>>> > >>>>> NIC's on both boards are 10/100's @100mbps > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> Can anyone provide any insight as to why I should be receiving > >>>>> these messages on a fresh 8.1/amd64 install. Is 8.1 INcompatible > >>>>> with earlier versions? > >>>>> > >>>> > >>>> No, I guess you're seeing one of unresolved nfe(4) issues. > >>>> By chance, are you using forced media configuration instead of > >>>> auto-negotiation? Posting both dmesg and "ifconfig nfe0" output > >>>> would be useful. > >>> > >>> As dmesg(8) goes, I have no dmesg.boot on either box, and bouncing > >>> them is not an immediate option. > >>> > >>> ifconfig nfe0 (the 8.1/amd64) follows: # ifconfig nfe0 nfe0: > >>> flags=8843 metric 0 mtu 1500 > >>> options=8010b ether > >>> 00:19:db:22:74:87 > >>> inet XXX.XXX.XXX.26 netmask 0xffffffe0 broadcast XXX.XXX.XXX.31 inet6 > >>> fe80::219:dbff:fe22:7487%nfe0 prefixlen 64 scopeid 0x1 > >>> nd6 options=3 media: Ethernet autoselect > >>> (100baseTX ) > >>> > >>> > >> > >> 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".