On Mon, May 31, 1999 at 04:08:16PM -0700, David wrote:
> Gert Doering wrote:
>
> > > I talked to Don about this at the Expo. Don's theory is that its the SMbus
> > > management stuff (the onboard eepro and firmwar eof their own accord
> > > support stuff like 'machine tampered with' and 'reboot' packets). Intel
> > > apparently havent provided enough documentation to handle this right now.
>
> > > > So there's definitely something fishy going on with the combination of
> > > > eepro100 and IPv6. Bad, since I really want to start deploying IPv6
> > > > in our local test bed here (as soon as RIPE hands out some v6 addresses).
> > > Ok. The Ipv6 may be cause or a symptom Im not sure which.
>
> I don't think it is ipv6.
It is, indirectly. Alexey is right, it's the multicast filters - when I
set the limit to "3", the problems disappeared.
Maybe you're doing other stuff that requires multicasting? Mbone, OSPF
routing, RIPv2, ...?
> I have two machines w/ eepro100 cards, one onboard.
> Every 10-30 seconds, the cards storm the network, totally disabling it for
> anywhere between 5 and 30 seconds -unless- the card is in promiscuous mode. If
> the card is left in promisc, it'll function perfectly.
Yep. I never saw it when a "tcpdump" was running (unless I put tcpdump to
non-promiscuous mode).
> While this storm is going on, the machine originating it appears completely
> unaware of the activity. tcpdump on that machine shows nothing however any other
> machine shows the packet flood. The packet flood is entirely comprised of one
> specific packet for that particular flood.
Yes, that's about the way it looked here as well.
> This has been happening since early 2.2.x.
Since 2.2.0-pre<something>.
For me, it went away as soon as I added "multicast_filter_limit=3" to
the insmod options ("insmod eepro100 multicast_filter_limit=3"), no
problems since then anymore.
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany gert@greenie.muc.de
fax: +49-89-35655025 gert.doering@physik.tu-muenchen.de
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/