On 11 February 2014 20:05, Brad Smith <[email protected]> wrote: > On Tue, Feb 11, 2014 at 07:43:51PM +0100, Mark Kettenis wrote: >> > Date: Tue, 11 Feb 2014 13:30:47 -0500 >> > From: Brad Smith <[email protected]> >> > >> > > Index: arch/socppc/dev/if_tsec.c >> > > =================================================================== >> > > RCS file: /home/cvs/src/sys/arch/socppc/dev/if_tsec.c,v >> > > retrieving revision 1.29 >> > > diff -u -p -u -p -r1.29 if_tsec.c >> > > --- arch/socppc/dev/if_tsec.c 29 Nov 2012 21:10:31 -0000 1.29 >> > > +++ arch/socppc/dev/if_tsec.c 28 Jan 2014 05:16:24 -0000 >> > > @@ -779,7 +779,6 @@ tsec_errintr(void *arg) >> > > */ >> > > tsec_rx_proc(sc); >> > > tsec_write(sc, TSEC_RSTAT, TSEC_RSTAT_QHLT); >> > > - ifp->if_ierrors++; >> > > } >> > > >> > > return (1); >> >> >> This one doesn't seem right. This is the only place where the driver >> actually increases if_ierrors. > > Being the only place input errors are incremented is irrelevant. > Its being incremented because the particular "error" is a FIFO overrun. > >> I also still fundamentally disagree with the direction. I you guys >> really want to make a distinction between packets dropped because >> we're out of descriptors and packets that were not correctly received >> for other reasons, add a counter for that first and then change the >> drivers. > > I don't necessarily disagree with what you have said. I think we should > have some additional counters to deal with some of the counters we > are lumping into error counters. > > Since we can't seem to come to any consensus about how to deal with > this I'm going to revert the bge(4) commit in question. >
no way. counting drops caused by the mclgeti should not be accounted as input errors. it makes it hard to debug things. > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. >
