Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 22 Aug 2006 12:22:37 +0400
From:      Ruslan Ermilov <ru@FreeBSD.org>
To:        Pyun YongHyeon <yongari@FreeBSD.org>
Cc:        cvs-src@FreeBSD.org, Gleb Smirnoff <glebius@FreeBSD.org>, cvs-all@FreeBSD.org, src-committers@FreeBSD.org
Subject:   Re: cvs commit: src/sys/dev/em if_em.c
Message-ID:  <20060822082237.GC41304@rambler-co.ru>
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

--61jdw2sOBCFtR2d/
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi Pyun,

On Tue, Aug 22, 2006 at 02:32:48AM +0000, Pyun YongHyeon wrote:
> yongari     2006-08-22 02:32:48 UTC
>=20
>   FreeBSD src repository
>=20
>   Modified files:
>     sys/dev/em           if_em.c=20
>   Log:
>   It seems that em(4) misses Tx completion interrupts under certain
>   conditions. The cause of missing Tx completion interrupts comes from
>   Tx interrupt moderation mechanism(delayed interrupts) or chipset bug.
>   If Tx interrupt moderation mechanism is the cause of false watchdog
>   timeout error we should have to fix all device drivers that have Tx
>   interrupt moderation capability. We may need more investigation
>   for this issue. Anyway, the fix is the same for both cases.
>  =20
>   This should fix occasional watchdog timeout errors seen on a few
>   systems.
>  =20
>   Reported by:    -net, Patrick M. Hausen < hausen AT punkt DOT de >
>   Tested by:      Patrick M. Hausen < hausen AT punkt DOT de >
>  =20
>   Revision  Changes    Path
>   1.133     +12 -0     src/sys/dev/em/if_em.c
>=20
I agree this is a less painful way to recover, but it's still a
watchdog and it slows down the performance when it happens.  After
this commit, if there's a moderate number of missing Tx completion
interrupts (for some reason), even a diagnostic message won't be
printed.  This is bad -- users will "seem" to have working but
slow systems, without any indication of what causes this slowness.
I think a diagnostic message should still be printed in this case,
and adapter->watchdog_events should still be incrementd, we just
don't need to reinit the chip in this case.


Cheers,
--=20
Ruslan Ermilov
ru@FreeBSD.org
FreeBSD committer

--61jdw2sOBCFtR2d/
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (FreeBSD)

iD8DBQFE6r7NqRfpzJluFF4RAqE2AJ9bagwyvLIIiYDYBRTGJTVmMJJxwACfU42J
FjyNVKdSO1yTMbg2gOzjrFM=
=iC2j
-----END PGP SIGNATURE-----

--61jdw2sOBCFtR2d/--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060822082237.GC41304>