netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Pekka Pietikainen <pp@ee.oulu.fi>
To: James Hubbard <jameshubbard@gmail.com>
Cc: netdev@oss.sgi.com
Subject: Re: Multicast on b44
Date: Sun, 16 Jan 2005 01:38:36 +0200	[thread overview]
Message-ID: <20050115233836.GA5334@ee.oulu.fi> (raw)
In-Reply-To: <f3ddc6d305011320416635914@mail.gmail.com>

On Thu, Jan 13, 2005 at 11:41:12PM -0500, James Hubbard wrote:
> I spoke to one of the developers of the communication software.  He
> checked things in a limited way.  This was his take on things.
> 
> "Okay, so I went and looked at the source to the b44 driver that comes
> with Fedora 1, and downloaded the 7.3.5 and 3.0.8 versions of the
> drivers from the broadcom web site."
> 
> "I'm not sure which chip you've got or which driver you're running, but
> the b44 driver looks like it's completely broken as soon as you go over
> about 30 multicast groups.  It just sort of randomly stops accepting new
> joins and so forth.  The ones from broadcom seem a little bit better,
> but are still a little bogus looking."
> 
> Do you have any suggestions that might help us to fix the problem?
Hiya

It looks like the b44 driver is limited to 32 entries (B44_MCAST_TABLE_SIZE)
whereas bcm4400 goes up to 63. It's just a #define so you should be able to
up it to that and be safe, might be worth upping it to that in b44 by
default. 

If you need more than that you're stuck with allmulti, which if I remember
correctly didn't work. Yup, from a previous mail of mine I did test it at
one point:

"Ok, after some digging around ALLMULTI breaking is not a bug, the
vendor-provided driver seems to break in similar ways, at least on 2.6,
so that's a feature unless they fix it in theirs so I can copy the fix :-)"

(well, it receive all multicasts after that, just not any unicasts :-) ).
Might be worth checking if the latest one of theirs still does that.
Wouldn't be surprised if it was a hardware bug...

Another option is promiscuous, which definately does work since I've used
tcpdump quite a bit :-). If it's a hardware bug with allmulti I suppose
just making allmulti == promiscuous.

Debugging this kind of things is very difficult though, since the only
source of documentation I have is the bcm4400 driver. And now that I
upgraded my system to a nice Athlon 64 with dual GigE I don't have the
hardware to test with either, so there's not much I can do to the driver
anyway other than point people to stuff, make "it compiles" patches and hope
someone tests and fixes them :-/

       reply	other threads:[~2005-01-15 23:38 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <f3ddc6d305011320416635914@mail.gmail.com>
2005-01-15 23:38 ` Pekka Pietikainen [this message]
2005-01-16  0:08   ` Multicast on b44 Pekka Pietikainen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20050115233836.GA5334@ee.oulu.fi \
    --to=pp@ee.oulu.fi \
    --cc=jameshubbard@gmail.com \
    --cc=netdev@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).