From owner-freebsd-net@FreeBSD.ORG Sat Apr 24 12:02:54 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 33DF716A4CE for ; Sat, 24 Apr 2004 12:02:54 -0700 (PDT) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id A9EF443D58 for ; Sat, 24 Apr 2004 12:02:53 -0700 (PDT) (envelope-from silby@silby.com) Received: (qmail 1263 invoked from network); 24 Apr 2004 19:02:52 -0000 Received: from niwun.pair.com (HELO localhost) (209.68.2.70) by relay.pair.com with SMTP; 24 Apr 2004 19:02:52 -0000 X-pair-Authenticated: 209.68.2.70 Date: Sat, 24 Apr 2004 14:04:14 -0500 (CDT) From: Mike Silbersack To: David Burns In-Reply-To: <408A160F.4090703@dugeem.net> Message-ID: <20040424140143.S5713@odysseus.silby.com> References: <408A160F.4090703@dugeem.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: net@freebsd.org Subject: Re: fast ethernet driver MII phy serial clock rates X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Apr 2004 19:02:54 -0000 On Sat, 24 Apr 2004, David Burns wrote: > Hello all, > > It appears that quite a few of the "el cheapo" hardware Fast Ethernet > drivers (at least rl, sis, ste, vr, wb - these are just the ones I found > in /usr/src/sys/pci) have added DELAY(1) statements around MII serial > clock ops which will result in a max Management Data Clock (MDC) > frequency of 500kHz for the serial management interface. Which means > that a mii_readreg (or writereg) operation will take a minimum of 128?s > (64?s for mii_sync + 64?s for data read/write). During which time the > driver is locked. This is an old problem, most of us leave it alone because hardware can break in strange ways. :) > NB this assumes that a DELAY(1) is really a delay of 1?s! Which I don't > think it is ... :-( Correct, DELAY takes far longer than it should. If you're really interested in fixing the problem and not inadvertantly breaking older cards, what you should do is implement a nanodelay function that actually delays for the time it's supposed to and then delay the rated amount. Removing all delays will probably break something somewhere. Mike "Silby" Silbersack