Date: Wed, 23 Aug 2006 18:55:04 +0900 From: Pyun YongHyeon <pyunyh@gmail.com> To: Gleb Smirnoff <glebius@FreeBSD.org> Cc: freebsd-current@FreeBSD.org Subject: Re: call for bge(4) testers Message-ID: <20060823095504.GI17902@cdnetworks.co.kr> In-Reply-To: <20060823093741.GF96644@FreeBSD.org> References: <20060822042023.GC12848@cdnetworks.co.kr> <20060823093741.GF96644@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Aug 23, 2006 at 01:37:41PM +0400, Gleb Smirnoff wrote: > On Tue, Aug 22, 2006 at 01:20:23PM +0900, Pyun YongHyeon wrote: > P> After fixing em(4) watchdog bug, I looked over bge(4) and I think > P> bge(4) may suffer from the same issue. So if you have seen occasional > P> watchdog timeout errors on bge(4) please give the attached patch a try. > P> The patch does fix false watchdog timeout error only. > P> Typical pheonoma for false watchdog timeout error are > P> o polling(4) fix the issue > P> o random watchdog error > P> > P> If my patch fix the issue you could see the following messages. > P> "missing Tx completion interrupt!" or "link lost -- resetting" > > I still think that this fix is incorrect. It is just a more gentle > recovery from a fake watchdog timeout. > Its sole purpose is to reinitialize hardware for real watchdog timeouts. It's not fix for general watchdog timeouts. As I said other mails, the fake watchdog timeout(losing Tx interrupts) for hardwares with Tx interrupt moderation capability could be normal thing. So I just want to know bge(4) also has the same feature(bug). > The more I think, the more I doubt that we really need the > watchdog infrastructure that comes from old days. > Would you give other way to recover from Tx stuck condition without using watchdog? -- Regards, Pyun YongHyeon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060823095504.GI17902>