lkml.org 
[lkml]   [1999]   [Jun]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: eepro100 storms, [was: Problems with 2.2.9, EEpro100 and IPv6 (was: Re: 2.2.0-pre9 and still "misbehaviour" with EEpro/100)]
Hi,

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/

\
 
 \ /
  Last update: 2005-03-22 13:52    [W:3.555 / U:0.004 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site