Date: Fri, 28 Jun 2002 02:35:20 -0500 (CDT) From: Mike Silbersack <silby@silby.com> To: Luigi Rizzo <rizzo@icir.org> Cc: net@freebsd.org Subject: Re: interface stalling on tx ? Message-ID: <20020628022611.K70821-100000@patrocles.silby.com> In-Reply-To: <20020627230348.A54937@iguana.icir.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 27 Jun 2002, Luigi Rizzo wrote: > I thought that upon transmission the driver somehow registered a > timeout to take care of these events, but maybe I am wrong ? > > Have other people seen this problem too ? > > cheers > luigi 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. 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? Of course, in an ideal world all drivers would recover in a graceful fashion. However, taking advantage of the watchdog timer to reset stuck cards seems like an adequate workaround. So far, I can't see any downside to this approach. If the card never locks up, then the change is superfluous. When it does, the change is a lifesaver. Apologies if parts of this message sound like babbling; I should be sleeping at this moment in time. :) Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020628022611.K70821-100000>