Date: Tue, 11 Jan 2011 16:27:51 -0800 From: Pyun YongHyeon <pyunyh@gmail.com> To: fbsdmail@dnswatch.com Cc: freebsd-amd64@freebsd.org Subject: Re: tx v2 error 0x6204<UNDERFLOW> - is this a new feature? Message-ID: <20110112002751.GE6278@michelle.cdnetworks.com> In-Reply-To: <1682d2c7ead29c3c80ad0676f61beb2c.dnswclient@www.dnswatch.com> References: <f765ac1cf5d77527d21ad2a83ee98d8c.dnswclient@www.dnswatch.com> <AANLkTi=CvNitBjG%2Br08NCTp_S=BwR7LZJ%2BeJuTkHAxVz@mail.gmail.com> <c91aeb7fe060c9d3548d120841d488fe.dnswclient@www.dnswatch.com> <AANLkTinZnkpPe2Xyh-tEJU0ZKJ%2BWjXprJFgVXj0XdPJs@mail.gmail.com> <30661ab452bce4de56f3e80f8682222a.dnswclient@www.dnswatch.com> <df34bd0d60eeff64cbb5c8a52147ede8.dnswclient@www.dnswatch.com> <20110111183315.GA6278@michelle.cdnetworks.com> <1682d2c7ead29c3c80ad0676f61beb2c.dnswclient@www.dnswatch.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110112002751.GE6278>