linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Eugene Surovegin <ebs@ebshome.net>
To: Jeff Mock <jeff@mock.com>
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: PPC440GX ethernet oddities
Date: Mon, 27 Nov 2006 14:44:30 -0800	[thread overview]
Message-ID: <20061127224430.GA20171@gate.ebshome.net> (raw)
In-Reply-To: <456B6475.4010109@mock.com>

On Mon, Nov 27, 2006 at 02:19:33PM -0800, Jeff Mock wrote:
> 
> 
> Eugene Surovegin wrote:
> > On Mon, Nov 27, 2006 at 09:34:59AM -0800, Jeff Mock wrote:
> >> # ./ethtool -S eth0
> >> NIC statistics:
> >>      rx_packets: 683430611
> >>      rx_bytes: 45405076316
> >>      tx_packets: 1331225622
> >>      tx_bytes: 2005276384145
> >>      rx_packets_csum: 683428670
> >>      tx_packets_csum: 1331224150
> >>      tx_undo: 0
> >>      rx_dropped_stack: 80
> >>      rx_dropped_oom: 0
> >>      rx_dropped_error: 0
> >>      [lots more 0's...]
> >>
> >> The number of checksum errors seems okay and doesn't really change when
> >> I plug in the second network connection, but the ring buffer usage still
> >> increases dramatically.
> > 
> > Stats look OK.  BTW, tx/rx_packets_csum is not a number of checksum 
> > errors, that's a number of packets where driver used hw checksum 
> > acceleration :).
> > 
> 
> Ah, silly me.  Can you tell me where I can find the number of received
> packets with bad ethernet checksums?  I'm still thinking that I might
> have a little hardware problem that is increasing the bit error rate
> when I use both ports, ultimately increasing my buffer utilization.

Packets with bad ethernet checksums are dropped by the MAC before 
being handed off to MAL. You can disable this behavior by setting 
RFP bit in EMACx_RMR register. In this case I think IP stack will drop 
these packets because IP and/or TCP checksum will fail. Use netstat -s 
to check network stack statistics.

Here is untested patch which enables RFP bit. It's against recent-ish 
kernel.org git tree:

diff --git a/drivers/net/ibm_emac/ibm_emac_core.c b/drivers/net/ibm_emac/ibm_emac_core.c
index ffeafb2..56ad988 100644
--- a/drivers/net/ibm_emac/ibm_emac_core.c
+++ b/drivers/net/ibm_emac/ibm_emac_core.c
@@ -372,7 +372,7 @@ static void emac_hash_mc(struct ocp_enet
 static inline u32 emac_iff2rmr(struct net_device *ndev)
 {
        u32 r = EMAC_RMR_SP | EMAC_RMR_SFCS | EMAC_RMR_IAE | EMAC_RMR_BAE |
-           EMAC_RMR_BASE;
+           EMAC_RMR_BASE | EMAC_RMR_RFP;

        if (ndev->flags & IFF_PROMISC)
                r |= EMAC_RMR_PME;



-- 
Eugene

  reply	other threads:[~2006-11-27 22:44 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-11-27  4:05 PPC440GX ethernet oddities Jeff Mock
2006-11-27  4:25 ` Eugene Surovegin
2006-11-27 17:34   ` Jeff Mock
2006-11-27 20:18     ` Eugene Surovegin
2006-11-27 22:19       ` Jeff Mock
2006-11-27 22:44         ` Eugene Surovegin [this message]
2006-11-27  7:14 ` Wolfgang Denk
2006-11-27 17:39   ` Jeff Mock

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20061127224430.GA20171@gate.ebshome.net \
    --to=ebs@ebshome.net \
    --cc=jeff@mock.com \
    --cc=linuxppc-embedded@ozlabs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).