Date: Tue, 22 Aug 2006 14:10:12 +0400 From: Ruslan Ermilov <ru@freebsd.org> To: Pyun YongHyeon <pyunyh@gmail.com> Cc: cvs-src@freebsd.org, Gleb Smirnoff <glebius@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: <20060822101012.GC43494@rambler-co.ru> In-Reply-To: <20060822094452.GJ12848@cdnetworks.co.kr> References: <200608220232.k7M2WmCr080275@repoman.freebsd.org> <20060822082237.GC41304@rambler-co.ru> <20060822094452.GJ12848@cdnetworks.co.kr>
next in thread | previous in thread | raw e-mail | index | archive | help
--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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060822101012.GC43494>