From owner-freebsd-net Fri Jun 28 0:53:58 2002 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 8D03E37B401 for ; Fri, 28 Jun 2002 00:53:47 -0700 (PDT) Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id C0EF943E12 for ; Fri, 28 Jun 2002 00:53:25 -0700 (PDT) (envelope-from rizzo@iguana.icir.org) Received: (from rizzo@localhost) by iguana.icir.org (8.11.6/8.11.3) id g5S7qrL55684; Fri, 28 Jun 2002 00:52:53 -0700 (PDT) (envelope-from rizzo) Date: Fri, 28 Jun 2002 00:52:53 -0700 From: Luigi Rizzo To: Mike Silbersack Cc: net@FreeBSD.ORG Subject: Re: interface stalling on tx ? Message-ID: <20020628005253.B55603@iguana.icir.org> References: <20020627230348.A54937@iguana.icir.org> <20020628022611.K70821-100000@patrocles.silby.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020628022611.K70821-100000@patrocles.silby.com>; from silby@silby.com on Fri, Jun 28, 2002 at 02:35:20AM -0500 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, Jun 28, 2002 at 02:35:20AM -0500, Mike Silbersack wrote: ... > The watchdog timer code in most of the drivers is rather conservative, and > may not detect mid-transfer stalls. I'll use the dc driver as an example: > > In dc_start, if_timer = 5 is set. Then, in dc_txeof, if_timer = 0, > disabling the watchdog timer. This means that after a _single_ frame is > sent, any subsequent stall will not be recovered from by the watchdog. ok, i think this is exactly the problem, and "conservative" is an understatement, I would call that plain broken :) Your fix seems the correct way to handle the problem, I wonder if there is an easy way to put something like this in a generic procedure (such as ether_output_frame) that is called by all drivers instead of relying on the individual drivers to do the right thing each one in its own way... > In the vr driver, we were having problems where such stalls could be > caused by high load, and the ifconfig up / down process was getting > annoying to users. I worked around this by setting if_timer = 5 every > time vr_txeof was entered, only setting if_timer = 0 at the point when the > _entire_ transmit buffer list was emptied. > > (See if_vr.c rev 1.49 to see how I did it in that driver.) > > You should be able to do something similar in all of the drivers, and I > have indeed thought of doing so. Could you code up and test such a patch > for whatever card you are using in your test environment to see if it > is a successful workaround? yes i will try it tonight. thanks luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message