public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: David Hinds <dhinds@valinux.com>
To: linux-kernel@vger.kernel.org
Cc: jgarzik@mandrakesoft.com
Subject: Re: PATCH: Pcmcia/Cardbus/xircom_tulip in 2.4.0-test10.
Date: Mon, 13 Nov 2000 12:18:33 -0800	[thread overview]
Message-ID: <20001113121833.A1725@valinux.com> (raw)

> Can you try the test11-pre2 patch? It includes a bugfix to
> xircom_tulip from Andrea. 

Andrea's fix doesn't actually solve the problem; it merely changes the
set of working configurations to a set that includes Andrea's setup.
I don't know whether the size of the working set gets larger or
smaller.

There is something fundamentally broken/weird about how the receive
filter works on the Xircom cards.  It is at least deterministic, but
different network configurations behave very differently and I haven't
been able to figure out the logic.  One version of the driver will
work perfectly for everyone that uses DHCP... another version will
work fine for people who specify a static IP address... another
version will work for people who use Red Hat's network configuration
script but not the default PCMCIA script.  The best I've been able to
figure out, is that whether a call to set_rx_mode() will work or lock
up the card depends on the history of what has gone on before (whether
the card has had traffic through it), where the rx filter setup frame
goes in the transmit ring, the alignment of the frame, and how many
times set_rx_mode() has been called.  Certain combinations work, other
combinations don't.

The effect of "ifconfig eth0 -multicast" (which should be a no-op) is
that it calls set_rx_mode() with the same set of parameters it was
called with before.  Doing this one or more times may kick the card so
that it starts working.  The number of times is constant for a given
network configuration, and varies between 0 and 3.

I wasted a lot of time trying to figure out the rules for when
set_rx_mode() would work and eventually gave up; I'm waiting for
Xircom to give me an explanation.

-- Dave

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

             reply	other threads:[~2000-11-13 21:36 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-11-13 20:18 David Hinds [this message]
2000-11-14  1:18 ` PATCH: Pcmcia/Cardbus/xircom_tulip in 2.4.0-test10 Ion Badulescu
2000-11-14  1:44   ` anyone compiled 2.2.17 on RH7 successfully? Corisen
2000-11-14  1:58   ` David Relson
2000-11-14  2:14     ` Corisen
2000-11-14  3:49       ` Michael Rothwell
2000-11-14  3:37         ` Dan Browning
2000-11-14  7:08       ` anyone compiled 2.2.17 on RH7 successfully? [SOLVED] Corisen
  -- strict thread matches above, loose matches on Subject: below --
2000-11-10 17:10 PATCH: Pcmcia/Cardbus/xircom_tulip in 2.4.0-test10 Ballabio_Dario
2000-11-10 12:36 Ballabio_Dario
2000-11-10 15:46 ` Jeff Garzik

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=20001113121833.A1725@valinux.com \
    --to=dhinds@valinux.com \
    --cc=jgarzik@mandrakesoft.com \
    --cc=linux-kernel@vger.kernel.org \
    /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