Lots of input errors...

[Shawn Ramsey]

> > > I would say the physical wire is probably bad.  Seeing unidirectional
> > errors
> > > in this case wouldn't be uncommon; one of the pair of the receive
wires
> > may
> > > have issues.  Have you swapped the cable?  Most of the time you won't
see
> > > framing errors related to duplex mismatching.
> >
> > It turned out to be a NIC issue. It was a 3COM 3c980C-TXM or something
like
> > that... I switched it to the braindead rl0 onboard adapter and the
errors,
> > and problems went away... pretty sad that "The worst ethernet adapter
ever
> > made" (according to the person who wrote the driver) beats out a pricey
3com
> > adapter, although its probably just a driver issue.
>
> It doesn't really 'beat out' the 3Com. It just happens not to be
> flagging any RX errors in this one particular case. Sadly, it looks
> like we'll never know the real reason for the RX errors with the 3Com
> now that you've swapped it out.

It is not just a matter of flagging errors, we were having trouble pushing
greater than say 110-120Mb with the 3COM, the rl0 does 160 easily which is
our typical traffic.How much higher it will go im not sure, but it is
clearing "beating" the 3com from a performance standpoint. Another stange
thing about the 3com we replaced was, we made a replacement cable that would
not connect properly. It would fit and snap into every other nic including
another 3com. Perhaps there was something phsyically wrong with the card.


> There are a couple of reasons why the xl driver might be reporting
> input errors:
>
> 1) Unable to allocate a new mbuf in xl_rxeof()
> 2) XL_RXSTAT_UP_ERROR bit was set in an RX DMA descriptor in xl_rxeof()
> 3) RX overrun errors detected when reading the internal stats counter
>    registers on the NIC in xl_stats_update().
>
> I don't think you ran out of mbufs (you would have noticed) so that
> rules out case #1. Checking cases #2 and #3 requires adding a little
> instrumentation to the driver. If the XL_RXSTAT_UP_ERROR bit is being
> detected in xl_rxeof(), you can print out the status word and see
> if any of the following bits are also set:
>
> #define XL_RXSTAT_UP_OVERRUN    0x00010000
> #define XL_RXSTAT_RUNT          0x00020000
> #define XL_RXSTAT_ALIGN         0x00040000
> #define XL_RXSTAT_CRC           0x00080000
> #define XL_RXSTAT_OVERSIZE      0x00100000
> #define XL_RXSTAT_DRIBBLE       0x00800000
> #define XL_RXSTAT_UP_OFLOW      0x01000000
>
> You can also add some instrumentation to the xl_update_stats() routine.
> Something tells me the problem is RX overruns, which means some of
> the DMA parameters may need to be adjusted a little. However, after
> going back and trying to dig up the previous e-mails from this thread
> in the archives, I was unable to locate the following important info:
>
> - How fast is this machine? (What CPU, speed, etc...)
> - You say there's a gigE NIC in this machine too. What kind is it?
>   (Driver, chipset, etc...)

GigeE is an Intel fiber card, I don't know the exact model, but it uses the
em driver. The machine in question is an Athlon XP 2000, 256MB ram. We had
planned on upgrading it to 1GB RAM since we had some spare ram for the new
MB, but we never replaced the MB due to the fact the problem seems to be NIC
related.


> What I did see was a lot of people holding forth about duplex mismatches
> which, while they can be annoying, are not the only source of RX errors.
> A duplex mismatch typically yeilds very low overall throughput and very
> bursty traffic patterns.

I can assure you that errors we were getting were not the result of a duplex
mismatch...