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

[fbsdmail at dnswatch.com]

On Tue, January 11, 2011 10:33 am, Pyun YongHyeon wrote:
> 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".
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 at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-amd64
> To unsubscribe, send any mail to "freebsd-amd64-unsubscribe at freebsd.org"
>
>


-- 
kern:
FreeBSD 8.1-RELEASE amd64