Date: Wed, 23 Aug 2006 09:31:09 +0900 From: Pyun YongHyeon <pyunyh@gmail.com> To: Gleb Smirnoff <glebius@FreeBSD.org> Cc: "Patrick M. Hausen" <hausen@punkt.de>, cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org, Pyun YongHyeon <yongari@FreeBSD.org> Subject: Re: cvs commit: src/sys/dev/em if_em.c Message-ID: <20060823003109.GB17902@cdnetworks.co.kr> In-Reply-To: <20060822152333.GV96644@FreeBSD.org> References: <200608220232.k7M2WmCr080275@repoman.freebsd.org> <20060822152333.GV96644@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060823003109.GB17902>