From owner-freebsd-net@FreeBSD.ORG Tue Apr 22 15:27:52 2003 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 913D137B401 for ; Tue, 22 Apr 2003 15:27:52 -0700 (PDT) Received: from wall.polstra.com (wall-gw.polstra.com [206.213.73.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 89D7943F75 for ; Tue, 22 Apr 2003 15:27:51 -0700 (PDT) (envelope-from jdp@polstra.com) Received: from strings.polstra.com (strings.polstra.com [206.213.73.20]) by wall.polstra.com (8.12.3p2/8.12.3) with ESMTP id h3MMRndt059654 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 22 Apr 2003 15:27:49 -0700 (PDT) (envelope-from jdp@strings.polstra.com) Received: (from jdp@localhost) by strings.polstra.com (8.12.6/8.12.6/Submit) id h3MMRm5E009574; Tue, 22 Apr 2003 15:27:48 -0700 (PDT) (envelope-from jdp) Date: Tue, 22 Apr 2003 15:27:48 -0700 (PDT) Message-Id: <200304222227.h3MMRm5E009574@strings.polstra.com> To: net@freebsd.org From: John Polstra In-Reply-To: References: Organization: Polstra & Co., Seattle, WA Subject: Re: em net (optical GigE) driver hangs? 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: Tue, 22 Apr 2003 22:27:52 -0000 In article , Don Bowman wrote: > From: John Polstra [mailto:jdp@polstra.com] > > I think the RELENG_4 version is likely to eliminate the problem. See > > the comment near the define of EM_RDTR in if_em.h (in the RELENG_4 > > version of that file, of course). > > We saw that, but we are using DEVICE_POLLING, so assumed it was not > the issue. Assuming the RDTR-related hangs are caused by a chip bug, I think they would happen if the RDTR register was set to a nonzero value, whether or not you were using interrupts in the device driver. > We think instead its another problem, which is also solved in the > RELENG_4 driver, in that em_poll() calls em_start() if device is > running and there are pkts on the queue. em_start() re-arms the > timer, holding off the wdog forever. That may well be true. But the non-firing of the watchdog timer is a separate problem from the occurrence of the hangs in the first place. In other words, if everything were working perfectly you wouldn't need the watchdog timer at all. John -- John Polstra John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa