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

[fbsdmail at dnswatch.com]

Greetings Pyun YongHyeon, and thank you for your reply.
On Tue, January 11, 2011 4:27 pm, Pyun YongHyeon wrote:
> On Tue, Jan 11, 2011 at 04:16:45PM -0800, fbsdmail at 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.

Closer examination of the switch seems to indicate one of the ports
is flaky (the nfe0 port). Well, that's good enough for me - this
switch is going to go to the recycling depot, and I'm going to
purchase a new one tomorrow. I'll report back as to whether the
<UNDERFLOW> errors stop with the use of the new switch.

Thank you very much Pyun YongHyeon for all your time and consideration.

--Chris

>
>
>> 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