Date: Tue, 22 Aug 2006 20:54:44 -0700 (PDT) From: John Polstra <jdp@polstra.com> To: Pyun YongHyeon <pyunyh@gmail.com> Cc: src-committers@FreeBSD.org, "Patrick M. Hausen" <hausen@punkt.de>, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org, Gleb Smirnoff <glebius@FreeBSD.org>, Pyun YongHyeon <yongari@FreeBSD.org> Subject: Re: cvs commit: src/sys/dev/em if_em.c Message-ID: <XFMail.20060822205444.jdp@polstra.com> In-Reply-To: <20060823003109.GB17902@cdnetworks.co.kr>
next in thread | previous in thread | raw e-mail | index | archive | help
On 23-Aug-2006 Pyun YongHyeon wrote: > On Tue, Aug 22, 2006 at 07:23:33PM +0400, Gleb Smirnoff wrote: > 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). I was wondering about something in connection with this. The em interrupt handler is now a "fast" handler, but the interrupt is still allocated with bus_alloc_resource_any(..., RF_SHAREABLE). If I remember correctly, fast interrupts cannot be shared. So, isn't it wrong to allocate the interrupt with RF_SHAREABLE? John
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.20060822205444.jdp>