Date: Fri, 26 Sep 1997 18:10:48 -0700 From: David Greenman <dg@root.com> To: Terry Lambert <tlambert@primenet.com> Cc: 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: <199709270110.SAA01062@implode.root.com> In-Reply-To: Your message of "Fri, 26 Sep 1997 21:34:01 -0000." <199709262134.OAA14622@usr08.primenet.com>
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. Uh, well, as far as I can tell, for 100Mbps, the problem only occurs when the link transitions to 10Mbps first and then sees garbage. Since the link speed is autodetected, it's easy to see how this might happen when someone power cycles a hub or something. It's less clear how it could occur in normal use at 10Mbps. Perhaps the problem doesn't occur with some hubs due to the hub/switch regeneration of the synch bits (which many hubs apparantly will do). >I guess the errata don't say what causes the bug (like a collision? >That would explain the 100Mbit being more robust...), It has something to do with the synchronization bits that preceed the packet data, but I can't find the errata right now (I recall that is was quite vague in any case). >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... The problem is that the receiver circuitry in the chip locks up, so you stop getting the echo response; the card continues to transmit, however. For whatever reason, reprogramming the multicast filter or resetting the entire chip corrects the condition. (The multicast filter is part of the receiver circuit, and it is apparantly selectively reset when the multicast filter is reprogrammed). >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. You can't send a packet to yourself under normal circumstances (ethernet is a simplex device). -DG David Greenman Core-team/Principal Architect, The FreeBSD Project
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709270110.SAA01062>