From owner-freebsd-current@FreeBSD.ORG Sat Jan 3 22:51:06 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A4BD616A4CE; Sat, 3 Jan 2004 22:51:06 -0800 (PST) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 64DBA43D62; Sat, 3 Jan 2004 22:50:51 -0800 (PST) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.12.9p2/8.12.9) with ESMTP id i046oe7E008358; Sat, 3 Jan 2004 22:50:45 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <200401040650.i046oe7E008358@gw.catspoiler.org> Date: Sat, 3 Jan 2004 22:50:40 -0800 (PST) From: Don Lewis To: dejan.lesjak@ijs.si, wpaul@FreeBSD.org In-Reply-To: <200401040533.i045XU7E008256@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii cc: ryans@gamersimpact.com cc: silby@silby.com cc: freebsd-current@FreeBSD.org Subject: Re: 5.2-RC oerrs and collisions on dc0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jan 2004 06:51:06 -0000 On 3 Jan, Don Lewis wrote: > On 4 Jan, Dejan Lesjak wrote: > >> Hello again, >> With this line commented out, I still get both errors and collisions, twice as >> much collisions as errors. On another occasion, I also added two printf lines >> in here: >> if (txstat & DC_TXSTAT_EXCESSCOLL) >> ifp->if_collisions++; >> printf("EXCESSCOLL\n"); >> if (txstat & DC_TXSTAT_LATECOLL) >> ifp->if_collisions++; >> printf("LATECOLL\n"); >> and I constantly get both of those, so this would be where counters go up if >> this helps in any way. > > I'm not familiar with this hardware, but I suspect that these two flags > should probably not increment the collision counter. These are errors > that result in the packet being dropped, so they should count as output > errors. The hardware collision counter is probably incremented in these > cases, so incrementing if_collisions probably results in these types of > collisions being double counted. Hmn, it seems that I lied. I actually have studied this hardware in the past. I don't think the following code fragment in dc_txeof() is quite correct. if (txstat & DC_TXSTAT_ERRSUM) { ifp->if_oerrors++; if (txstat & DC_TXSTAT_EXCESSCOLL) ifp->if_collisions++; if (txstat & DC_TXSTAT_LATECOLL) ifp->if_collisions++; if (!(txstat & DC_TXSTAT_UNDERRUN)) { dc_init(sc); return; } } ifp->if_collisions += (txstat & DC_TXSTAT_COLLCNT) >> 3; I don't happen to have a copy of the 21143 documentation, but my crufty old 21140A documentation says that the collision count field is valid if the late collision bit is set, but not if the excess collision count bit is set. The documentation can't make up its mind as to whether the late collision bit is valid if the underrun bit is set. It looks like the code should be: if (txstat & DC_TXSTAT_ERRSUM) { ifp->if_oerrors++; if (!(txstat & DC_TXSTAT_UNDERRUN)) { dc_init(sc); return; } } ifp->if_collisions += (txstat & DC_TXSTAT_EXCESSCOLL) ? 16 : (txstat & DC_TXSTAT_COLLCNT) >> 3); This still doesn't explain why you are seeing output errors in full duplex mode. If the chip is really in full duplex mode, the circuitry that sets the collision counter and the late and excess collision bits should be disabled. It looks like the code to put the chip in full duplex mode is correct and I didn't see anything obvious in the busdma modifications to the driver.