From owner-freebsd-amd64@FreeBSD.ORG Wed Jan 12 00:16:46 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 E990D1065670 for ; Wed, 12 Jan 2011 00:16:46 +0000 (UTC) (envelope-from fbsdmail@dnswatch.com) Received: from fast.dnswatch.com (fast.dnswatch.com [168.103.150.11]) by mx1.freebsd.org (Postfix) with ESMTP id AC5068FC15 for ; Wed, 12 Jan 2011 00:16:46 +0000 (UTC) Received: from www.dnswatch.com (localhost.dnswatch.com [127.0.0.1]) by fast.dnswatch.com (8.14.2/8.14.2) with ESMTP id p0C0GcqH013798; Tue, 11 Jan 2011 16:16:44 -0800 (PST) (envelope-from fbsdmail@dnswatch.com) Received: from udns0.ultimatedns.net ([168.103.150.26]) (DNSwatchWebMail authenticated user infos) by www.dnswatch.com with HTTP; Tue, 11 Jan 2011 16:16:45 -0800 (PST) Message-ID: <1682d2c7ead29c3c80ad0676f61beb2c.dnswclient@www.dnswatch.com> In-Reply-To: <20110111183315.GA6278@michelle.cdnetworks.com> References: <30661ab452bce4de56f3e80f8682222a.dnswclient@www.dnswatch.com> <20110111183315.GA6278@michelle.cdnetworks.com> Date: Tue, 11 Jan 2011 16:16:45 -0800 (PST) From: fbsdmail@dnswatch.com To: freebsd-amd64@freebsd.org User-Agent: DNSwatchWebMail/1.5.2 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: 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 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:16:47 -0000 On Tue, January 11, 2011 10:33 am, Pyun YongHyeon wrote: > 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". 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 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 > > > _______________________________________________ > freebsd-amd64@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 > To unsubscribe, send any mail to "freebsd-amd64-unsubscribe@freebsd.org" > > -- kern: FreeBSD 8.1-RELEASE amd64