Date: Fri, 26 Sep 1997 21:34:01 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: dg@root.com Cc: mike@smith.net.au, 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: <199709262134.OAA14622@usr08.primenet.com> In-Reply-To: <199709261426.HAA25055@implode.root.com> from "David Greenman" at Sep 26, 97 07:26:27 am
next in thread | previous in thread | raw e-mail | index | archive | help
> One of these days I'll conjure up some sort of hack to fix the problem. > Intel recommends reprogramming the multicast filter (!) if no packets are > received for some number of seconds. This is difficult to implement in the > current design of the driver. Plus it leaves your butt hanging in the wind for several seconds on a *supposedly* 100Mbit card. Pretty frigging ugly. I guess the errata don't say what causes the bug (like a collision? That would explain the 100Mbit being more robust...), like the macrocell for the chip is actually mask programmed and the unused bit sets aren't specifically disallowed, or a header collision can't be dealt with because the header accumulation buffer isn't cleared, or something dumb like that? Do we know that the "cron ping soloution" actually works? If it does, can we set up a bogus gateway route to avoid getting a packet back for one sent to see if it's the packet out or the packet back that does it? I'm betting out at this point... If this works, then a timer set to bogusly send a packet to ourselves would not bother anyone else on the network who wasn't in promiscuous mode and running a network monitor, and it would be filterable there. 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?199709262134.OAA14622>