tx v2 error 0x6204<UNDERFLOW> - is this a new feature?

[Pyun YongHyeon]

On Tue, Jan 11, 2011 at 01:14:49AM -0800, fbsdmail at dnswatch.com wrote:
> 
> On Tue, January 11, 2011 1:01 am, fbsdmail at dnswatch.com wrote:
> >
> 
> > On Tue, January 11, 2011 12:42 am, Pyun YongHyeon wrote:
> >
> >> On Tue, Jan 11, 2011 at 12:28 AM,  <fbsdmail at dnswatch.com> 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, ?<fbsdmail at dnswatch.com> 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<UNDERFLOW>
> >>>>> nfe0: tx v2
> >>>>> error 0x6204<UNDERFLOW>
> >>
> >> [...]
> >>
> >>
> >>
> >>>>> nfe0: tx v2 error 0x6204<UNDERFLOW>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> 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<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
> >>> options=8010b<RXCSUM,TXCSUM,VLAN_MTU,TSO4,LINKSTATE> 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<PERFORMNUD,ACCEPT_RTADV> media: Ethernet autoselect
> >>> (100baseTX <half-duplex>)
> >>>
> >>>
> >>
> >> 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".