[PATCH 3/3] ep93xx_eth: don't report RX FIFO overrun errors

[PATCH 3/3] ep93xx_eth: don't report RX FIFO overrun errors

[Lennert Buytenhek]

Flooding the console with an RX FIFO overrun error for every single
dropped packet isn't very sensible.  The hardware is very underpowered
according to today's standards, and RX FIFO overrun errors can be
triggered quite easily, so don't report them at all.

Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org>

Index: linux-2.6.19-rc3/drivers/net/arm/ep93xx_eth.c
===================================================================
--- linux-2.6.19-rc3.orig/drivers/net/arm/ep93xx_eth.c
+++ linux-2.6.19-rc3/drivers/net/arm/ep93xx_eth.c
@@ -230,8 +230,9 @@ static int ep93xx_rx(struct net_device *
 					 " %.8x %.8x\n", rstat0, rstat1);
 
 		if (!(rstat0 & RSTAT0_RWE)) {
-			printk(KERN_NOTICE "ep93xx_rx: receive error "
-					 " %.8x %.8x\n", rstat0, rstat1);
+			if (!(rstat0 & RSTAT_OE))
+				printk(KERN_NOTICE "ep93xx_rx: receive error "
+				       " %.8x %.8x\n", rstat0, rstat1);
 
 			ep->stats.rx_errors++;
 			if (rstat0 & RSTAT0_OE)

Re: [PATCH 3/3] ep93xx_eth: don't report RX FIFO overrun errors

[Ray Lehtiniemi]

On Sunday 29 October 2006 06:06, Lennert Buytenhek wrote:
> Flooding the console with an RX FIFO overrun error for every single
> dropped packet isn't very sensible.  The hardware is very underpowered
> according to today's standards, and RX FIFO overrun errors can be
> triggered quite easily, so don't report them at all.
>
> Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org>
>
> Index: linux-2.6.19-rc3/drivers/net/arm/ep93xx_eth.c
> ===================================================================
> --- linux-2.6.19-rc3.orig/drivers/net/arm/ep93xx_eth.c
> +++ linux-2.6.19-rc3/drivers/net/arm/ep93xx_eth.c
> @@ -230,8 +230,9 @@ static int ep93xx_rx(struct net_device *
>  					 " %.8x %.8x\n", rstat0, rstat1);
>
>  		if (!(rstat0 & RSTAT0_RWE)) {
> -			printk(KERN_NOTICE "ep93xx_rx: receive error "
> -					 " %.8x %.8x\n", rstat0, rstat1);
> +			if (!(rstat0 & RSTAT_OE))
> +				printk(KERN_NOTICE "ep93xx_rx: receive error "
> +				       " %.8x %.8x\n", rstat0, rstat1);
>
>  			ep->stats.rx_errors++;
>  			if (rstat0 & RSTAT0_OE)


i got a compile error: please s/RSTAT_OE/RSTAT0_OE/ in this patch.  Also, is 
it possible for any other error bits to be set at the same time as OE?  such 
bits would not be printed to the log in this case.

ray

Re: [PATCH 3/3] ep93xx_eth: don't report RX FIFO overrun errors

[Lennert Buytenhek]

On Sun, Oct 29, 2006 at 11:15:28AM -0700, Ray Lehtiniemi wrote:

> > Index: linux-2.6.19-rc3/drivers/net/arm/ep93xx_eth.c
> > ===================================================================
> > --- linux-2.6.19-rc3.orig/drivers/net/arm/ep93xx_eth.c
> > +++ linux-2.6.19-rc3/drivers/net/arm/ep93xx_eth.c
> > @@ -230,8 +230,9 @@ static int ep93xx_rx(struct net_device *
> >  					 " %.8x %.8x\n", rstat0, rstat1);
> >
> >  		if (!(rstat0 & RSTAT0_RWE)) {
> > -			printk(KERN_NOTICE "ep93xx_rx: receive error "
> > -					 " %.8x %.8x\n", rstat0, rstat1);
> > +			if (!(rstat0 & RSTAT_OE))
> > +				printk(KERN_NOTICE "ep93xx_rx: receive error "
> > +				       " %.8x %.8x\n", rstat0, rstat1);
> >
> >  			ep->stats.rx_errors++;
> >  			if (rstat0 & RSTAT0_OE)
> 
> i got a compile error: please s/RSTAT_OE/RSTAT0_OE/ in this patch.

Whoops, I thought I sent the right one.  :(


> Also, is it possible for any other error bits to be set at the same
> time as OE?  such bits would not be printed to the log in this case.

Not sure, but arguably, this wouldn't be very interesting.  Actually,
now I'm wondering whether we should just remove the printk altogether.


cheers,
Lennert

Re: [PATCH 3/3] ep93xx_eth: don't report RX FIFO overrun errors

[Ray Lehtiniemi]

On Sunday 29 October 2006 11:22, Lennert Buytenhek wrote:

> > Also, is it possible for any other error bits to be set at the same
> > time as OE?  such bits would not be printed to the log in this case.
>
> Not sure, but arguably, this wouldn't be very interesting.  Actually,
> now I'm wondering whether we should just remove the printk altogether.

i don't see why we need a printk... the error counters _should_ be sufficient.

ray