From owner-freebsd-hackers Fri Sep 26 14:08:37 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA27846 for hackers-outgoing; Fri, 26 Sep 1997 14:08:37 -0700 (PDT) Received: from usr08.primenet.com (tlambert@usr08.primenet.com [206.165.6.208]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA27811; Fri, 26 Sep 1997 14:08:21 -0700 (PDT) Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id OAA13493; Fri, 26 Sep 1997 14:07:32 -0700 (MST) From: Terry Lambert Message-Id: <199709262107.OAA13493@usr08.primenet.com> Subject: Re: 'fxp' driver/hardware lossage (was Re: Alexander B. Povol's mail) To: dg@root.com Date: Fri, 26 Sep 1997 21:07:31 +0000 (GMT) Cc: tlambert@primenet.com, tarkhil@mgt.msk.ru, hackers@FreeBSD.ORG, stable@FreeBSD.ORG In-Reply-To: <199709261431.HAA25105@implode.root.com> from "David Greenman" at Sep 26, 97 07:31:43 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > >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.