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

[fbsdmail at dnswatch.com]

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.

>
>> status: active
>>
>>
>> FWIW ifconfig fxp0 on the 8.0/i386 follows:
>> # ifconfig fxp0
>> fxp0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu
>> 1500
>> options=2009<RXCSUM,VLAN_MTU,WOL_MAGIC> ether 00:e0:81:20:9d:66 inet
>> XXX.XXX.XXX.20 netmask 0xffffffe0 broadcast XXX.XXX.XXX.31
>> inet XXX.XXX.XXX.21 netmask 0xffffffff broadcast XXX.XXX.XXX.21 inet
>> XXX.XXX.XXX.22 netmask 0xffffffff broadcast XXX.XXX.XXX.22
>> inet XXX.XXX.XXX.23 netmask 0xffffffff broadcast XXX.XXX.XXX.23 inet
>> XXX.XXX.XXX.24 netmask 0xffffffff broadcast XXX.XXX.XXX.24
>> inet XXX.XXX.XXX.25 netmask 0xffffffff broadcast XXX.XXX.XXX.25 media:
>> Ethernet autoselect (100baseTX)
>> status: active
>>
>>
>> They're all on the same /24, and as you can see, there is no
>> forced media configuration.
>>
>> I /do/ have an old (pre-kern-build) dmesg.boot for the 8.1/amd64, if
>> you (or anyone else) thinks it would help. If the dmesg.boot is
>> absolutely required, I'll schedule an opportunity to bounce both of them
>> - I'll need to know, tho.
>>
>>
>
> Then show me the output of  "devinfo -rv" and "pciconf -lcbv".

Sorry, my bad. I forgot that there would be a copy of dmesg.boot in
/var/run/.

dmesg.boot.udns0 = 8.1/amd64
dmesg.boot.udns = 8.0/i386

My mailer is acting up, or I would simply attach them. So in the meantime
they can be found here:

https://dnswatch.com/_tmp/dmesg.boot.udns0
and here:
https://dnswatch.com/_tmp/dmesg.boot.udns

Thanks again.

--Chris

>
>
>> Thank you again for your thoughtful reply.
>>
>>
>> --Chris
>>
>>
>>
>>>
>>>> Thank you for all your time and consideration.
>>>>
>>>>
>>>>
>>>> --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
>>
>>
>>
>>
> _______________________________________________
> 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