cvs commit: src/sys/dev/em if_em.c
pyunyh at gmail.com
Wed Aug 23 00:31:21 UTC 2006
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> FreeBSD src repository
> 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> This should fix occasional watchdog timeout errors seen on a few
> P> systems.
> 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).
More information about the cvs-all