Date: Tue, 22 Aug 2006 19:23:33 +0400 From: Gleb Smirnoff <glebius@FreeBSD.org> To: Pyun YongHyeon <yongari@FreeBSD.org> Cc: "Patrick M. Hausen" <hausen@punkt.de>, cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/dev/em if_em.c Message-ID: <20060822152333.GV96644@FreeBSD.org> In-Reply-To: <200608220232.k7M2WmCr080275@repoman.freebsd.org> References: <200608220232.k7M2WmCr080275@repoman.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. So I think there is a problem in FreeBSD or driver, not in chip. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060822152333.GV96644>