* net driver error accounting
@ 2007-08-02 20:17 Andrew Morton
2007-08-02 20:38 ` Jeff Garzik
0 siblings, 1 reply; 3+ messages in thread
From: Andrew Morton @ 2007-08-02 20:17 UTC (permalink / raw)
To: netdev, Jeff Garzik; +Cc: Natalie Protasevich
Looking at http://bugzilla.kernel.org/show_bug.cgi?id=8106
Guys, could we please have a ruling here?
When a net driver encounters a tx_fifo_error, should this also contribute
to the tx_error count, or should it not?
More generally, should netdev drivers accumulate all the detailed
rx_errors into net_device_stats.rx_errors in real time, or should they not?
Thanks.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: net driver error accounting
2007-08-02 20:17 net driver error accounting Andrew Morton
@ 2007-08-02 20:38 ` Jeff Garzik
2007-08-02 20:45 ` Andrew Morton
0 siblings, 1 reply; 3+ messages in thread
From: Jeff Garzik @ 2007-08-02 20:38 UTC (permalink / raw)
To: Andrew Morton; +Cc: netdev, Natalie Protasevich
Andrew Morton wrote:
> Looking at http://bugzilla.kernel.org/show_bug.cgi?id=8106
>
> Guys, could we please have a ruling here?
>
> When a net driver encounters a tx_fifo_error, should this also contribute
> to the tx_error count, or should it not?
For each TX error, (a) tx_error is incremented and (b) a more-specific
TX error stat is also potentially incremented. So, yes, tx_error
accumulates.
See cp_tx() in 8139cp.
> More generally, should netdev drivers accumulate all the detailed
> rx_errors into net_device_stats.rx_errors in real time, or should they not?
For each RX error, (a) rx_error is incremented and (b) a more-specific
RX error stat is also potentially incremented. So, yes, rx_error
accumulates.
See cp_rx_err_acct() in 8139cp.
Jeff
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: net driver error accounting
2007-08-02 20:38 ` Jeff Garzik
@ 2007-08-02 20:45 ` Andrew Morton
0 siblings, 0 replies; 3+ messages in thread
From: Andrew Morton @ 2007-08-02 20:45 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev, Natalie Protasevich, Tim Hockin
On Thu, 02 Aug 2007 16:38:09 -0400
Jeff Garzik <jeff@garzik.org> wrote:
> Andrew Morton wrote:
> > Looking at http://bugzilla.kernel.org/show_bug.cgi?id=8106
> >
> > Guys, could we please have a ruling here?
> >
> > When a net driver encounters a tx_fifo_error, should this also contribute
> > to the tx_error count, or should it not?
>
> For each TX error, (a) tx_error is incremented and (b) a more-specific
> TX error stat is also potentially incremented. So, yes, tx_error
> accumulates.
>
> See cp_tx() in 8139cp.
>
>
> > More generally, should netdev drivers accumulate all the detailed
> > rx_errors into net_device_stats.rx_errors in real time, or should they not?
>
> For each RX error, (a) rx_error is incremented and (b) a more-specific
> RX error stat is also potentially incremented. So, yes, rx_error
> accumulates.
>
> See cp_rx_err_acct() in 8139cp.
>
OK, thanks.
One does wonder why the overall rx_error exists all all, but whatever. The
main thing is to get all the net drivers doing the same thing.
So I guess bug 8106 wants something like this?
diff -puN drivers/net/natsemi.c~a drivers/net/natsemi.c
--- a/drivers/net/natsemi.c~a
+++ a/drivers/net/natsemi.c
@@ -2438,13 +2438,16 @@ static void netdev_error(struct net_devi
dev->name);
}
np->stats.rx_fifo_errors++;
+ np->stats.rx_errors++;
}
/* Hmmmmm, it's not clear how to recover from PCI faults. */
if (intr_status & IntrPCIErr) {
printk(KERN_NOTICE "%s: PCI error %#08x\n", dev->name,
intr_status & IntrPCIErr);
np->stats.tx_fifo_errors++;
+ np->stats.tx_errors++;
np->stats.rx_fifo_errors++;
+ np->stats.rx_errors++;
}
spin_unlock(&np->lock);
}
_
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2007-08-02 20:45 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-08-02 20:17 net driver error accounting Andrew Morton
2007-08-02 20:38 ` Jeff Garzik
2007-08-02 20:45 ` Andrew Morton
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).