From owner-cvs-all@FreeBSD.ORG Tue Aug 22 10:13:23 2006 Return-Path: X-Original-To: cvs-all@freebsd.org Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3288416A4FA; Tue, 22 Aug 2006 10:13:23 +0000 (UTC) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (relay0.rambler.ru [81.19.66.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id 29A3643DFC; Tue, 22 Aug 2006 10:10:09 +0000 (GMT) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (localhost [127.0.0.1]) by relay0.rambler.ru (Postfix) with ESMTP id F075A5F5B; Tue, 22 Aug 2006 14:10:04 +0400 (MSD) Received: from edoofus.park.rambler.ru (unknown [81.19.65.108]) by relay0.rambler.ru (Postfix) with ESMTP id CCD625F45; Tue, 22 Aug 2006 14:10:04 +0400 (MSD) Received: (from ru@localhost) by edoofus.park.rambler.ru (8.13.6/8.13.6) id k7MAACCv043644; Tue, 22 Aug 2006 14:10:12 +0400 (MSD) (envelope-from ru) Date: Tue, 22 Aug 2006 14:10:12 +0400 From: Ruslan Ermilov To: Pyun YongHyeon Message-ID: <20060822101012.GC43494@rambler-co.ru> References: <200608220232.k7M2WmCr080275@repoman.freebsd.org> <20060822082237.GC41304@rambler-co.ru> <20060822094452.GJ12848@cdnetworks.co.kr> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="MfFXiAuoTsnnDAfZ" Content-Disposition: inline In-Reply-To: <20060822094452.GJ12848@cdnetworks.co.kr> User-Agent: Mutt/1.5.12-2006-07-14 X-Virus-Scanned: No virus found Cc: cvs-src@freebsd.org, Gleb Smirnoff , src-committers@freebsd.org, cvs-all@freebsd.org, Pyun YongHyeon Subject: Re: cvs commit: src/sys/dev/em if_em.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Aug 2006 10:13:23 -0000 --MfFXiAuoTsnnDAfZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 22, 2006 at 06:44:52PM +0900, Pyun YongHyeon wrote: > On Tue, Aug 22, 2006 at 12:22:37PM +0400, Ruslan Ermilov wrote: > > 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. >=20 > It just reinvokes txeof handler and check whether there are pending Tx > descriptors in driver queue. If there are no pending Tx descriptors > it's false watchdog timeout and just return without resetting=20 > hardware. >=20 This is all clear. > So there is no performance drop. Of course, if we are out of > Tx descriptors and missed Tx completion interrupts it would slow down > Tx process. >=20 Yes, that's what I was talking about. > ATM I don't know what caused this missing Tx completion interrupt. > (chipset bug/Tx interrupt moderation or other bug) >=20 > > I think a diagnostic message should still be printed in this case, > I have no objections on printing a diagnostic message. But if missing > Tx completion interrupts is normal consequences for these hardwares > it would give negative impresstion to users. >=20 It would tell the true, like em0: watchdog timeout (missed Tx interrupt) -- recovering (Maybe under bootverbose only.) > > and adapter->watchdog_events should still be incrementd, we just > > don't need to reinit the chip in this case. > >=20 > adapter->watchdog_events is used to count output errors(if_oerrors). > If we know the watchog timeout is false we should not increment the > counter as we sucessfully transmitted it without errors. >=20 It's still a watchdog event. We can make it a separate counter, like watchdog_tx_event, and not add it to oerrors, but still show it in em_print_hw_stats(). It'd be useful to have this statistics available. > Because it's hard to reproduce it I guess it only happens under > certain conditions. In addition we don't know how many Tx completion > interrupts are lost. If you think it should recover fast from the > above condition wihtout waiting for a watchdog timeout we could > embebd an em_txeof() into em_local_timer() to sweep up Tx > descriptors sucessfully transmitted. >=20 That would make it look more like polling. :-) I'm pretty sure this problem is not unique to em(4). Adding these quirks to all known to be subject to this issue drivers and gathering the statistics would be a good thing IMO. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --MfFXiAuoTsnnDAfZ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFE6tgEqRfpzJluFF4RArASAJ9nDT8TyfNIQWW767mW954iyqGmfwCffJPl 8SqNXmfT8yE6wDOaSeqVb8c= =uU82 -----END PGP SIGNATURE----- --MfFXiAuoTsnnDAfZ--