From owner-cvs-all@FreeBSD.ORG Wed Aug 23 00:31:21 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 D32F616A4DD for ; Wed, 23 Aug 2006 00:31:21 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.180]) by mx1.FreeBSD.org (Postfix) with ESMTP id C879F43D55 for ; Wed, 23 Aug 2006 00:31:17 +0000 (GMT) (envelope-from pyunyh@gmail.com) Received: by py-out-1112.google.com with SMTP id o67so3089396pye for ; Tue, 22 Aug 2006 17:31:17 -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=kyNzqweII6OtMOqEOakaXBa2n7HiiCt6V2uE1ztkK1NQF9sWuEfdIa3je7U8lg9/Z1eHqDUCF7vbDn87+EMaNmDC2FnGdw7rWWwZyRq1HyaqgNgh6GmUKXFt/zibqOI7jqLWiB15HXh9tF3LJoOLa96vrYqMainzT3Yrzgfafdk= Received: by 10.35.127.7 with SMTP id e7mr16612363pyn; Tue, 22 Aug 2006 17:31:16 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.gmail.com with ESMTP id 8sm3282527nzn.2006.08.22.17.31.14; Tue, 22 Aug 2006 17:31:16 -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 k7N0VAP8018148 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Aug 2006 09:31:10 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id k7N0V9re018147; Wed, 23 Aug 2006 09:31:09 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Wed, 23 Aug 2006 09:31:09 +0900 From: Pyun YongHyeon To: Gleb Smirnoff Message-ID: <20060823003109.GB17902@cdnetworks.co.kr> References: <200608220232.k7M2WmCr080275@repoman.freebsd.org> <20060822152333.GV96644@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060822152333.GV96644@FreeBSD.org> User-Agent: Mutt/1.4.2.1i Cc: "Patrick M. Hausen" , cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@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: Wed, 23 Aug 2006 00:31:21 -0000 On Tue, Aug 22, 2006 at 07:23:33PM +0400, Gleb Smirnoff wrote: > On Tue, Aug 22, 2006 at 02:32:48AM +0000, Pyun YongHyeon wrote: > P> yongari 2006-08-22 02:32:48 UTC > P> > P> FreeBSD src repository > P> > P> Modified files: > P> sys/dev/em if_em.c > P> Log: > P> It seems that em(4) misses Tx completion interrupts under certain > P> conditions. The cause of missing Tx completion interrupts comes from > P> Tx interrupt moderation mechanism(delayed interrupts) or chipset bug. > P> If Tx interrupt moderation mechanism is the cause of false watchdog > P> timeout error we should have to fix all device drivers that have Tx > P> interrupt moderation capability. We may need more investigation > P> for this issue. Anyway, the fix is the same for both cases. > P> > P> This should fix occasional watchdog timeout errors seen on a few > P> systems. > P> > P> Reported by: -net, Patrick M. Hausen < hausen AT punkt DOT de > > P> Tested by: Patrick M. Hausen < hausen AT punkt DOT de > > > This look like a workaround, not a fix the root of the problem. Several > people on net said that this problem disappears if debug.mpsafenet=0. I think that problem is different one. That problem happens when interrupt is shared with other devices. In these configuration em(4) misses lots of Tx completion interrupts and devices that use the shared interrupt stop working in the long run. It seems that debug.mpsafenet=0 mitigate the issue. > So I think there is a problem in FreeBSD or driver, not in chip. > Agreed. If my memory serve me right it introduced right after switching to taskqueue(9) in interrupt handling(rev, 1.98). -- Regards, Pyun YongHyeon