From owner-cvs-all@FreeBSD.ORG Tue Aug 22 09:45:16 2006 Return-Path: X-Original-To: cvs-all@freebsd.org Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5A44616A4E8 for ; Tue, 22 Aug 2006 09:45:16 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6D9F643D58 for ; Tue, 22 Aug 2006 09:45:13 +0000 (GMT) (envelope-from pyunyh@gmail.com) Received: by py-out-1112.google.com with SMTP id o67so2795324pye for ; Tue, 22 Aug 2006 02:45:12 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=uJ0YQwg8cpVR1BDpSKgDiTSAB9t4C9VD2JMTMbe4n7xf7y5XXT+qxphBaCbMUHEaruojc6BnUDAKYiSXLJlhaWImWAdzX8xn3qcCJkCMrJIPYUdVYxp43S6zU9ZhViEr/MLukX7ydq0633pdKgZT5rBO9HYSSad0MCwszR11uEM= Received: by 10.35.29.6 with SMTP id g6mr15245683pyj; Tue, 22 Aug 2006 02:45:12 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.gmail.com with ESMTP id 20sm469462nzp.2006.08.22.02.45.09; Tue, 22 Aug 2006 02:45:11 -0700 (PDT) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id k7M9iq1P015234 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Aug 2006 18:44:52 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id k7M9iqav015233; Tue, 22 Aug 2006 18:44:52 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Tue, 22 Aug 2006 18:44:52 +0900 From: Pyun YongHyeon To: Ruslan Ermilov Message-ID: <20060822094452.GJ12848@cdnetworks.co.kr> References: <200608220232.k7M2WmCr080275@repoman.freebsd.org> <20060822082237.GC41304@rambler-co.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060822082237.GC41304@rambler-co.ru> User-Agent: Mutt/1.4.2.1i Cc: cvs-src@FreeBSD.org, Gleb Smirnoff , cvs-all@FreeBSD.org, src-committers@FreeBSD.org, Pyun YongHyeon Subject: Re: cvs commit: src/sys/dev/em if_em.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Aug 2006 09:45:16 -0000 On Tue, Aug 22, 2006 at 12:22:37PM +0400, Ruslan Ermilov wrote: > Hi Pyun, > > On Tue, Aug 22, 2006 at 02:32:48AM +0000, Pyun YongHyeon wrote: > > yongari 2006-08-22 02:32:48 UTC > > > > FreeBSD src repository > > > > Modified files: > > sys/dev/em if_em.c > > Log: > > It seems that em(4) misses Tx completion interrupts under certain > > conditions. The cause of missing Tx completion interrupts comes from > > Tx interrupt moderation mechanism(delayed interrupts) or chipset bug. > > If Tx interrupt moderation mechanism is the cause of false watchdog > > timeout error we should have to fix all device drivers that have Tx > > interrupt moderation capability. We may need more investigation > > for this issue. Anyway, the fix is the same for both cases. > > > > This should fix occasional watchdog timeout errors seen on a few > > systems. > > > > Reported by: -net, Patrick M. Hausen < hausen AT punkt DOT de > > > Tested by: Patrick M. Hausen < hausen AT punkt DOT de > > > > > Revision Changes Path > > 1.133 +12 -0 src/sys/dev/em/if_em.c > > > I agree this is a less painful way to recover, but it's still a > watchdog and it slows down the performance when it happens. After > this commit, if there's a moderate number of missing Tx completion > interrupts (for some reason), even a diagnostic message won't be > printed. This is bad -- users will "seem" to have working but > slow systems, without any indication of what causes this slowness. It just reinvokes txeof handler and check whether there are pending Tx descriptors in driver queue. If there are no pending Tx descriptors it's false watchdog timeout and just return without resetting hardware. So there is no performance drop. Of course, if we are out of Tx descriptors and missed Tx completion interrupts it would slow down Tx process. ATM I don't know what caused this missing Tx completion interrupt. (chipset bug/Tx interrupt moderation or other bug) > I think a diagnostic message should still be printed in this case, I have no objections on printing a diagnostic message. But if missing Tx completion interrupts is normal consequences for these hardwares it would give negative impresstion to users. > and adapter->watchdog_events should still be incrementd, we just > don't need to reinit the chip in this case. > adapter->watchdog_events is used to count output errors(if_oerrors). If we know the watchog timeout is false we should not increment the counter as we sucessfully transmitted it without errors. Because it's hard to reproduce it I guess it only happens under certain conditions. In addition we don't know how many Tx completion interrupts are lost. If you think it should recover fast from the above condition wihtout waiting for a watchdog timeout we could embebd an em_txeof() into em_local_timer() to sweep up Tx descriptors sucessfully transmitted. -- Regards, Pyun YongHyeon