Date: Wed, 6 Dec 2006 18:18:47 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: Marius Strobl <marius@FreeBSD.org> Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/pci if_xl.c if_xlreg.h Message-ID: <20061206181350.S32496@delplex.bde.org> In-Reply-To: <20061206164242.A32496@delplex.bde.org> References: <200612060218.kB62IfVn046324@repoman.freebsd.org> <20061206164242.A32496@delplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 6 Dec 2006, Bruce Evans wrote: > On Wed, 6 Dec 2006, Marius Strobl wrote: > ... >> While at it relax the watchdog a bit by reloading it in xl_txeof()/ >> xl_txeof_90xB() if there are still packets enqueued. > > Er, xl_txeof_90xB() was one of the 20-30% of txeof() routines that > handled this correctly. The timeout shouldn't be touched in xx_txeof() > except to clear it when all descriptors have been handled. > ... > xl_txeof_90xB() now reloads the timeout without checking anything > except that there are still some unhandled descriptors. ISTR that > this bug has been fixed in a few drivers, mainly ones that support > DEVICE_POLLING. Grepping for "0 : 5" shows the bug in the following > drivers: dc, pcn, sis, xl. All of these except pcn support Reference for a previous fix: if_rl.c 1.134. This actually reloads the timeout to 5 if it is 0 AND there is an unhandled tx descriptor. I think this case shouldn't happen (the watchdog should have handled it), and if it does it should be handled by resetting. Maybe it only happened due to the race decrementing if_timer. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061206181350.S32496>