I have been having some problems with the xircom_cb driver here at
columbia for the past few weeks. It finally dawned on me that the problem
might be because dmesg kept on telling me that driver was going into
promiscious mode (and ifconfig show me a high RX value (after only a few
moments of the card being up)). I did't have any problems on my small
network at home, but I'm guessing a problem b/w the switch here at school
and the card being in promiscious mode basically made the card useless in
linux (worked fine in win2k)
in looking through the source for the driver, it seems from the comments
that when the card is in interrupt handler mode, it has to turn
promiscious mode on. I don't know why, but I do know that it never seems
to turn it off. I basically stuck a return in the enable_promisc function
before it does anything, and that cleared up all my problems.
I'm guessing this is not the correct solution (based on the comment), so
if someone who has a better idea of how network card drivers work, I'd
appreciate some insight.
thanks,
shaya potter
--
spotter@{cs.columbia.edu,yucs.org}
In article <[email protected]> you wrote:
> in looking through the source for the driver, it seems from the comments
> that when the card is in interrupt handler mode, it has to turn
> promiscious mode on. I don't know why, but I do know that it never seems
> to turn it off. I basically stuck a return in the enable_promisc function
> before it does anything, and that cleared up all my problems.
It actually doesn't need the promisc for most revisions of the card, but for
some it seems to be really needed.
The xircom_tulip_cb driver is more advanced, and probably works well for
your system. (It doesn't work for all cards, but I suspect that correlates
highly with the revision that needs the promisc)
On Thu, 18 Oct 2001 22:36:38 +0100, [email protected] wrote:
> The xircom_tulip_cb driver is more advanced, and probably works well for
> your system. (It doesn't work for all cards, but I suspect that correlates
> highly with the revision that needs the promisc)
In particular the xircom_tulip_cb driver from 2.4.13-pre4 should work well
at Columbia (since that's one place where I tested it :-). You can simply
copy the xircom_tulip_cb.c from 2.4.13-pre4 into pretty much any 2.4
kernel and recompile, and it should work -- except maybe for the
MODULE_LICENSE line which can be safely commented out.
Arjan, are there still cards that don't work without promisc mode enabled?
I got two different versions myself and both work very nicely with the
latest xircom_tulip_cb.
Thanks,
Ion
--
It is better to keep your mouth shut and be thought a fool,
than to open it and remove all doubt.
actually, it seems on my system, if my system goes to sleep (haven't
played around with it enough to figure out how to prevent that from
happening), it seems to crash on "wakeup" if I use the xircom_tulip_cb,
while the xircom_cb doesn't have that problem.
other thing is, xircom_tulip_cb used to work on my system (2.4.10) (xircom
realport card, rebranded for IBM), but with 2.4.12-ac3, it can't seem to
drive the card. it loads fine, detects the card, but no blinky lights.
<shrug/>
if it doesn't need promiscious mode always, shouldn't this be a module
param?
thanks,
shaya
On Thu, 18 Oct 2001 [email protected] wrote:
> In article <[email protected]> you wrote:
>
> > in looking through the source for the driver, it seems from the comments
> > that when the card is in interrupt handler mode, it has to turn
> > promiscious mode on. I don't know why, but I do know that it never seems
> > to turn it off. I basically stuck a return in the enable_promisc function
> > before it does anything, and that cleared up all my problems.
>
> It actually doesn't need the promisc for most revisions of the card, but for
> some it seems to be really needed.
>
> The xircom_tulip_cb driver is more advanced, and probably works well for
> your system. (It doesn't work for all cards, but I suspect that correlates
> highly with the revision that needs the promisc)
>
Shaya Potter wrote:
> other thing is, xircom_tulip_cb used to work on my system (2.4.10) (xircom
> realport card, rebranded for IBM), but with 2.4.12-ac3, it can't seem to
> drive the card. it loads fine, detects the card, but no blinky lights.
It's critical that you get xircom_tulip_cb.c from 2.4.13-pre3.
2.4.12-ac3 does not the long-needing-to-be-applied fixes that are now in
2.4.13-pre3's copy of the driver.
Ion ([email protected]) did the changes, so he is pretty close to
you if you need debugging, too <g>
Jeff
--
Jeff Garzik | Only so many songs can be sung
Building 1024 | with two lips, two lungs, and one tongue.
MandrakeSoft | - nomeansno
Shaya Potter wrote:
> if it doesn't need promiscious mode always, shouldn't this be a module
> param?
There is a significant enough portion of Xircom cards that have that
particular quirk, that relegating the option to a not-enabled-by-default
setting would mean some people's cards flat out don't work by default
with the driver. Ugly user support issue, even if it is easily solved.
I am hoping that Ion's changes make unconditional promisc mode
unnecessary..
--
Jeff Garzik | Only so many songs can be sung
Building 1024 | with two lips, two lungs, and one tongue.
MandrakeSoft | - nomeansno
On Thu, Oct 18, 2001 at 08:09:18PM -0400, Jeff Garzik wrote:
> Shaya Potter wrote:
> > other thing is, xircom_tulip_cb used to work on my system (2.4.10) (xircom
> > realport card, rebranded for IBM), but with 2.4.12-ac3, it can't seem to
> > drive the card. it loads fine, detects the card, but no blinky lights.
>
> It's critical that you get xircom_tulip_cb.c from 2.4.13-pre3.
> 2.4.12-ac3 does not the long-needing-to-be-applied fixes that are now in
> 2.4.13-pre3's copy of the driver.
>
> Ion ([email protected]) did the changes, so he is pretty close to
> you if you need debugging, too <g>
I am quite interested in the problems that arise with the xircom
cardbus ethernet cards, since I have difficulties with them as well.
However, my problems are not solved by setting promisc mode.
When I try to transmit larger amounts of data (such as scp'ing a 30 MB
file over from a different machine on the LAN), network transfer
stalls. I can abort the user space program, but the network link is
gone. This can be reproduced with:
- kernel 2.4.13, using pcmcia-cs drivers 3.1.25
- kernel 2.4.13, using pcmcia-cs drivers 3.1.29
- kernel 2.4.13, using kernel driver xircom_tulip_cb
- kernel 2.4.13-ac5, using kernel driver xircom_tulip_cb
- kernel 2.4.13-ac5, using kernel driver xircom_cb
I am using Debian/GNU Linux unstable/sid.
I tried this with two different RealPort 2 CardBus Ethernet R2BE100,
and an older RealPort CardBus Ethernet RBE100. I am currently in no
position of trying a different notebook, since the machine in question
(a Maxdata Artist Eton Pro from 1999, most probably a chicony OEM
product) is the only CardBus-able Linux notebook around. All three
Xircom Cards work fine with Windows 98 on that box, and an even older
16 bit Xircom RealPort card works fine with Linux.
Is it possible that I am doing something wrong?
2.4.13-ac5 has the patched xircom_tulip_cb from 2.4.13-pre3?
Any hints will be appreciated.
Greetings
Marc
--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Karlsruhe, Germany | lose things." Winona Ryder | Fon: *49 721 966 32 15
Nordisch by Nature | How to make an American Quilt | Fax: *49 721 966 31 29
On Thu, 1 Nov 2001 11:26:28 +0100, Marc Haber <[email protected]> wrote:
> I am quite interested in the problems that arise with the xircom
> cardbus ethernet cards, since I have difficulties with them as well.
> However, my problems are not solved by setting promisc mode.
Indeed, this sounds like a very different problem.
> When I try to transmit larger amounts of data (such as scp'ing a 30 MB
> file over from a different machine on the LAN), network transfer
> stalls. I can abort the user space program, but the network link is
> gone.
Ok, so let's take a closer look at this. I am mostly interested in the
behavior of the xircom_tulip_cb from 2.4.13+ and 2.4.12-ac4+ kernels.
When you say the network link is gone, does it mean the network link light
on the card is gone? What does mii-tool report?
Do you get any kernel messages when the networking dies? Any netdev
transmit timeouts or anything else?
What are the messages you get from xircom_tulip_cb when it gets
initialized? [make sure you look at dmesg's output, some syslog
configurations don't log all kernel messages.]
Can you run tcpdump on the other side of the scp connection to see what
exactly is going on?
> Is it possible that I am doing something wrong?
It's very unlikely... but possible. :-)
> 2.4.13-ac5 has the patched xircom_tulip_cb from 2.4.13-pre3?
It does.
Thanks,
Ion
--
It is better to keep your mouth shut and be thought a fool,
than to open it and remove all doubt.
On Thu, Nov 01, 2001 at 10:47:03AM -0500, Ion Badulescu wrote:
> On Thu, 1 Nov 2001 11:26:28 +0100, Marc Haber <[email protected]> wrote:
> > I am quite interested in the problems that arise with the xircom
> > cardbus ethernet cards, since I have difficulties with them as well.
> > However, my problems are not solved by setting promisc mode.
>
> Indeed, this sounds like a very different problem.
:-(
> > When I try to transmit larger amounts of data (such as scp'ing a 30 MB
> > file over from a different machine on the LAN), network transfer
> > stalls. I can abort the user space program, but the network link is
> > gone.
>
> Ok, so let's take a closer look at this. I am mostly interested in the
> behavior of the xircom_tulip_cb from 2.4.13+ and 2.4.12-ac4+ kernels.
OK. All tests have been done on 2.4.13-ac5.
> When you say the network link is gone, does it mean the network link light
> on the card is gone?
No. The light (that is somewhere _inside_ the card for the R2BE-100)
stays on.
> What does mii-tool report?
This is what mii-tool reports while the link is still up:
|Basic registers of MII PHY #0: 1000 782d 0040 6331 00a1 45e1 0005 2001.
| The autonegotiated capability is 00a0.
|The autonegotiated media type is 100baseTx.
| Basic mode control register 0x1000: Auto-negotiation enabled.
| You have link beat, and everything is working OK.
| Your link partner advertised 45e1: Flow-control 100baseTx-FD 100baseTx 10baseT-FD 10baseT, w/ 802.3X flow control.
| End of basic transceiver informaion.
Invoking mii-diag after provoking the network freeze freezes the
entire machine. Not even magic sqsrq works in that situation.
> Do you get any kernel messages when the networking dies? Any netdev
> transmit timeouts or anything else?
neither on syslog, nor on the console.
Sometimes, I get a "spurious 8259A interrupt: IRQ7" or " spurious
8259A interrupt: IRQ15" message on console and syslog, though.
> What are the messages you get from xircom_tulip_cb when it gets
> initialized? [make sure you look at dmesg's output, some syslog
> configurations don't log all kernel messages.]
I stopped pcmcia, unloaded all modules, and reloaded them again. This
is the relevant dmesg output:
|Linux Kernel Card Services 3.1.22
| options: [pci] [cardbus] [pm]
|PCI: Found IRQ 10 for device 00:09.0
|PCI: Sharing IRQ 10 with 00:09.1
|PCI: Found IRQ 10 for device 00:09.1
|PCI: Sharing IRQ 10 with 00:09.0
|Yenta IRQ list 0898, PCI irq10
|Socket status: 30000007
|Yenta IRQ list 0898, PCI irq10
|Socket status: 30000821
|cs: cb_alloc(bus 6): vendor 0x115d, device 0x0003
|PCI: Enabling device 06:00.0 (0000 -> 0003)
|cs: IO port probe 0x0c00-0x0cff: clean.
|cs: IO port probe 0x0800-0x08ff: clean.
|cs: IO port probe 0x0100-0x04ff: excluding 0x170-0x177 0x370-0x37f 0x398-0x39f 0cs: IO port probe 0x0a00-0x0aff: clean.
|xircom_tulip_cb.c derived from tulip.c:v0.91 4/14/99 [email protected]
| unofficial 2.4.x kernel port, version 0.91+LK1.1, October 11, 2001
| PCI: Setting latency timer of device 06:00.0 to 64
| eth0: Xircom Cardbus Adapter rev 3 at 0x4c00, 00:10:A4:98:CD:5C, IRQ 10.
|eth0: MII transceiver #0 config 3000 status 7809 advertising 01e1.
> Can you run tcpdump on the other side of the scp connection to see what
> exactly is going on?
Sure.
|19:10:31.258464 172.20.206.6.22 > 192.168.130.42.32781: tcp 1448 (DF) [tos 0x8]
|19:10:31.258610 172.20.206.6.22 > 192.168.130.42.32781: tcp 1448 (DF) [tos 0x8]
|19:10:31.258793 172.20.206.6.22 > 192.168.130.42.32781: tcp 1448 (DF) [tos 0x8]
|19:10:31.258978 172.20.206.6.22 > 192.168.130.42.32781: tcp 1448 (DF) [tos 0x8]
|19:10:31.258958 192.168.130.42.32781 > 172.20.206.6.22: tcp 0 (DF) [tos 0x8]
|19:10:31.259275 172.20.206.6.22 > 192.168.130.42.32781: tcp 1448 (DF) [tos 0x8]
|19:10:31.259464 172.20.206.6.22 > 192.168.130.42.32781: tcp 1448 (DF) [tos 0x8]
|19:10:31.259322 192.168.130.42.32781 > 172.20.206.6.22: tcp 0 (DF) [tos 0x8]
|19:10:31.259798 172.20.206.6.22 > 192.168.130.42.32781: tcp 476 (DF) [tos 0x8]
|19:10:31.276840 172.20.206.6.22 > 192.168.130.42.32781: tcp 1448 (DF) [tos 0x8]
|19:10:31.469788 172.20.206.6.22 > 192.168.130.42.32781: tcp 1448 (DF) [tos 0x8]
|19:10:31.889876 172.20.206.6.22 > 192.168.130.42.32781: tcp 1448 (DF) [tos 0x8]
|19:10:32.729853 172.20.206.6.22 > 192.168.130.42.32781: tcp 1448 (DF) [tos 0x8]
|19:10:34.409733 172.20.206.6.22 > 192.168.130.42.32781: tcp 1448 (DF) [tos 0x8]
|19:10:37.769731 172.20.206.6.22 > 192.168.130.42.32781: tcp 1448 (DF) [tos 0x8]
|19:10:44.489736 172.20.206.6.22 > 192.168.130.42.32781: tcp 1448 (DF) [tos 0x8]
|19:10:57.929585 172.20.206.6.22 > 192.168.130.42.32781: tcp 1448 (DF) [tos 0x8]
|19:11:24.809292 172.20.206.6.22 > 192.168.130.42.32781: tcp 1448 (DF) [tos 0x8]
|19:12:18.568665 172.20.206.6.22 > 192.168.130.42.32781: tcp 1448 (DF) [tos 0x8]
|19:12:23.568365 arp who-has 192.168.130.42 tell 192.168.130.1
|19:12:24.568352 arp who-has 192.168.130.42 tell 192.168.130.1
|19:12:25.568350 arp who-has 192.168.130.42 tell 192.168.130.1
|19:12:26.568327 arp who-has 192.168.130.42 tell 192.168.130.1
|19:12:27.568298 arp who-has 192.168.130.42 tell 192.168.130.1
|19:12:28.568296 arp who-has 192.168.130.42 tell 192.168.130.1
172.20.206.6 and 192.168.130.1 are the remote side (external and
internal IP of my border router), and 192.168.130.42 is the notebook
in question. tcpdump done on the border router. This looks like the
notebook simply stops answering, after which the remote side fills up
the window and then waits, arping for the notebook after running into
a time out.
> > 2.4.13-ac5 has the patched xircom_tulip_cb from 2.4.13-pre3?
>
> It does.
Then there is still a bug. Or something's wrong here.
I cannot rule out that my notebook is broken, Chicony has a history of
making abysmally bad hardware, and the machine is about two years old.
I don't have a reference notebook that has Linux installed and can do
Cardbus to cross-check, sorry.
Greetings
Marc
--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Karlsruhe, Germany | lose things." Winona Ryder | Fon: *49 721 966 32 15
Nordisch by Nature | How to make an American Quilt | Fax: *49 721 966 31 29
Hi Marc,
Sorry for the late reply, I've been on vacation for the last week..
On Thu, 1 Nov 2001 19:34:37 +0100, Marc Haber <[email protected]> wrote:
> On Thu, Nov 01, 2001 at 10:47:03AM -0500, Ion Badulescu wrote:
>> What does mii-tool report?
>
> This is what mii-tool reports while the link is still up:
> |Basic registers of MII PHY #0: 1000 782d 0040 6331 00a1 45e1 0005 2001.
> | The autonegotiated capability is 00a0.
> |The autonegotiated media type is 100baseTx.
> | Basic mode control register 0x1000: Auto-negotiation enabled.
> | You have link beat, and everything is working OK.
> | Your link partner advertised 45e1: Flow-control 100baseTx-FD 100baseTx 10baseT-FD 10baseT, w/ 802.3X flow control.
> | End of basic transceiver informaion.
All right, so far so good.
> Invoking mii-diag after provoking the network freeze freezes the
> entire machine. Not even magic sqsrq works in that situation.
This, however, is not good. Not good at all. If sysrq is not working, that
means the interrupts are disabled or the bus is completely wedged. The
driver never disables interrupts, and the ioctl() function is not called
with the interrupts disabled, so that's not a possible cause. Furthermore,
the ioctl() function does something very mundane (reading a few
registers), which definitely shouldn't cause lock ups.
I'm sorry, I don't have any good news for you... I really don't think the
problem is in the driver.
Just for the kicks, can you strace mii-diag when it locks up, to see on
which ioctl() call it locks up? I don't think that will help much, but...
> Sometimes, I get a "spurious 8259A interrupt: IRQ7" or " spurious
> 8259A interrupt: IRQ15" message on console and syslog, though.
I get the IRQ7 one as well, it's not something to be overly concerned
with.
> I cannot rule out that my notebook is broken, Chicony has a history of
> making abysmally bad hardware, and the machine is about two years old.
Could very well be broken, unfortunately.
> I don't have a reference notebook that has Linux installed and can do
> Cardbus to cross-check, sorry.
Do you have any other cardbus cards to test if they work with this laptop?
Thanks,
Ion
--
It is better to keep your mouth shut and be thought a fool,
than to open it and remove all doubt.
On Thu, Nov 01, 2001 at 07:34:37PM +0100, Marc Haber wrote:
> On Thu, Nov 01, 2001 at 10:47:03AM -0500, Ion Badulescu wrote:
> > On Thu, 1 Nov 2001 11:26:28 +0100, Marc Haber <[email protected]> wrote:
> > > I am quite interested in the problems that arise with the xircom
> > > cardbus ethernet cards, since I have difficulties with them as well.
> > > However, my problems are not solved by setting promisc mode.
> >
> > Indeed, this sounds like a very different problem.
>
> :-(
> I cannot rule out that my notebook is broken, Chicony has a history of
> making abysmally bad hardware, and the machine is about two years old.
> I don't have a reference notebook that has Linux installed and can do
> Cardbus to cross-check, sorry.
I now have to confitm that my notebook is broken. The card works fine
even with the stock kernel driver in an HP OmniBook, so it must be the
notebook at fault :-(
Thanks for your assistance and the good work regarding the Linux
kernel, I really appreciate that.
Greetings
Marc
--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Karlsruhe, Germany | lose things." Winona Ryder | Fon: *49 721 966 32 15
Nordisch by Nature | How to make an American Quilt | Fax: *49 721 966 31 29