* 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).