Date: Fri, 26 Sep 1997 21:07:31 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: dg@root.com Cc: tlambert@primenet.com, tarkhil@mgt.msk.ru, hackers@FreeBSD.ORG, stable@FreeBSD.ORG Subject: Re: 'fxp' driver/hardware lossage (was Re: Alexander B. Povol's mail) Message-ID: <199709262107.OAA13493@usr08.primenet.com> In-Reply-To: <199709261431.HAA25105@implode.root.com> from "David Greenman" at Sep 26, 97 07:31:43 am
next in thread | previous in thread | raw e-mail | index | archive | help
> >This is an interesting problem... I'm going to provide some possible > >hacks. Normally I don't hack drivers for cards that I don't have > > Wrong on all accounts. Let's not cloud the issue with irrelevant > information and wrong patches. It's difficult enough for me to provide > accurate information without having to battle misinformation. Thanks. This seemed like an issue that simply hadn't been addresssed, but which was well known, according to early postings. Subsequent traffic (which occurred *after* my posting makes it clear that up/downing the interface will fix it as well. Clearly, the very last suggestion, coupled with the suggested receive idle timer, will work, though it is not pretty. Playing with the control bits, as well, may very well "resolve" the deadlock. As far as mbuf denial, it's clearly not the problem, but it could be *a* problem. I should have suggested "vmstat -m | grep mbuf" first, though. 8-). I'm not sure why that status bit is not checked in all cases, though if ether_input() isn't puked, all it should do is result in bogus packets coming further up the stack than they should. 8-(. Anyway, it's still an interesting problem: how to deal with broken hardware. Sounds like a job for a high resoloution timer... ;-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709262107.OAA13493>