Bug 37454 - Xircom CBEM56G flaky, while good in 7.0
Xircom CBEM56G flaky, while good in 7.0
Product: Red Hat Linux
Classification: Retired
Component: kernel-pcmcia-cs (Show other bugs)
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Dave Jones
Brock Organ
Depends On:
  Show dependency treegraph
Reported: 2001-04-24 13:21 EDT by Bertil Askelid
Modified: 2015-01-04 17:01 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-11-25 02:18:52 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Boot log from /var/log/messages showing PCMCIA setup (18.83 KB, text/plain)
2001-04-24 13:23 EDT, Bertil Askelid
no flags Details

  None (edit)
Description Bertil Askelid 2001-04-24 13:21:56 EDT
My "Xircom CardBus Ethernet 10/100 + Modem 56 CBEM56G 1.03" worked just fine
in 6.2 and 7.0 using PCIC=i82365 in /etc/sysconfig/pcmcia and the
automatically selected tulip_cs module.

In 7.1, the default "alias eth0 xircom_cb" in /etc/module.conf, recognize and
Xircom card and set it up. The modem works fine, but the ethernet card
doesn't. ifup sets up the regular ifconfig and routing tables correctly,
but the eth0 won't allow outgoing packets. It does receive incoming packets.

I switched over to use "alias eth0 xirc2ps_cs". Now things work a bit better.
Though, when I disconnect the eth0, the Xircom has to be ejected and then
inserted again (using cardctl) before another connection can be made.

I hope you ca fix this. It worked just fine in 7.0. I'm willing to help out
with testing, if you need that.
Comment 1 Bertil Askelid 2001-04-24 13:23:45 EDT
Created attachment 16247 [details]
Boot log from /var/log/messages showing PCMCIA setup
Comment 2 Arjan van de Ven 2001-04-24 13:25:57 EDT
Could you please try to get "ifconfig" output when you have the
xircom_cb driver running ?
and can you also try it without cardmgr running?

I assume you are using "yenta_socket" instead of "i82365", please check this
Comment 3 Bertil Askelid 2001-04-24 18:08:22 EDT


`ifconfig' w/ cardmgr running:

   eth0      Link encap:Ethernet  HWaddr 00:10:A4:ED:3D:64
             inet addr:  Bcast: 
             UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
             RX packets:82123 errors:0 dropped:0 overruns:0 frame:0
             TX packets:48327 errors:0 dropped:0 overruns:0 carrier:0
             collisions:0 txqueuelen:100
             Interrupt:11 Base address:0x1800

   lo        Link encap:Local Loopback
             inet addr:  Mask:
             UP LOOPBACK RUNNING  MTU:16436  Metric:1
             RX packets:6624 errors:0 dropped:0 overruns:0 frame:0
             TX packets:6624 errors:0 dropped:0 overruns:0 carrier:0
             collisions:0 txqueuelen:0

/var/log/messages w/ transcript from `killall cardmgr':

    cardmgr[499]: executing: './network stop xircom_cb'
   Apr 24 14:37:29 z cardmgr[499]: + usage: ifdown <device name>
   Apr 24 14:37:29 z cardmgr[499]: stop cmd exited with status 1
   Apr 24 14:37:29 z cardmgr[499]: executing: './serial stop xircom_cb'
   Apr 24 14:37:29 z cardmgr[499]: executing: 'modprobe -r xircom_cb'
   Apr 24 14:37:29 z kernel: tty01 unloaded
   Apr 24 14:37:29 z cardmgr[499]: + xircom_cb: Device or resource busy
   Apr 24 14:37:29 z cardmgr[499]: modprobe exited with status 1
   Apr 24 14:37:29 z cardmgr[499]: executing: 'modprobe -r serial_cb'
   Apr 24 14:37:29 z cardmgr[499]: executing: 'modprobe -r cb_enabler'
   Apr 24 14:37:29 z cardmgr[499]: exiting

w/o cardmgr running:

   It works!  Connection can be taken up and down repeatedly without any
Comment 4 Need Real Name 2001-05-19 08:46:56 EDT
I have similar experience to report: MII negotiation was upgraded from redhat's
linux kernel-2.2.16 to 2.2.19, with a xircom cbem cardbus

2.2.16: low troughput with a 100Mb/s partner (only 30-100kB/s)
2.2.19: full speed throughput (ie 10MB/s), but had to use an ifconfig eth0
allmulti hack

2.4.2: cannot go above 100kB/s again, whatever module I choose (xircom_cb,
xircom_tulip_cb or xirc2ps_cb). The only difference between those 3 modules is
that the xircom_cb seems to behave a little more gracefully (no ifconfig hack

I was wondering how to make this work at reasonable speeds again. The laptop if
a Dell Latitude CpxH500GT.

I will send you any further debugging info you will need.

Best regards.

Comment 5 Arjan van de Ven 2001-05-21 11:14:46 EDT
bernard@cmapx.polytechnique.fr: are you willing to test the newer version
of the driver? It's at


and I hope I fixed the "it's slow" bug; the problem is that I cannot reproduce
at all, it seems to happen with certain (brands of) switches only.
Comment 6 Bertil Askelid 2001-05-23 11:41:25 EDT
I've tried the fix from http://people.redhat.com/arjanv/xircom_cb. It certainly
solves my original problem with eth0 not getting connected at all times, now I
get connected without any problems.

However, occasionally, I notice a slowdown in throughput. A reset makes it work
again. Seems like this is happening when I switch from working at home (10 Mbps
LAN) and work (100 Mbps LAN), but I have only used the fix for a day, so I'm not 
sure if that is the cause. The slowdown is severe, a ping got down from 19 msec
to 2 sec.
Comment 7 Arjan van de Ven 2001-05-23 11:53:18 EDT
Do you suspend your laptop inbetween ? (I have one other report where suspending
the laptop causes troubles)
Comment 8 Need Real Name 2001-05-23 13:44:41 EDT
OK. I tested the new xircom_cb.c module by arjanv@redhat.com. The connection
remains very slow. 

My hardware setup is a xircom CBEM 10/100 NIC connected directly to another NIC
(DFE 530tx by Dlink), and not to a switch. I used the xircom_cb.c module with a
vanilla kernel-2.4.4 ac patchlevel 9. This is because I couldn't compile the
module alone (nor inside the kernel source tree from
kernel-source-2.4.2-2.i386.rpm: always got LOADS of unresolved symbols; even
usb-uhci could not load).

My currently best working setup is linux-2.4.4ac9 with the kernel side PCMCIA
support DISABLED and the latest pcmcia package from sourceforge compiled by
hand. With this (tulip_cb.o), I get close to 100Mb.

Connecting the laptop to a 10Mb hub however, is never a problem: I always get
maximal speed, as I did with the kernel shipped with rh7.1.

Comment 9 Bertil Askelid 2001-05-23 16:52:53 EDT
I have been looking around and tried various things. I have been unable to
figure out what it is that is causing the slow down. Suspend makes no
difference. Works just fine after a suspend. Runs just fine on battery only.
Not even time matters. Sometimes you get the slow down right away, sometimes
after a few hours.

While playing,  also noticed that I have to wait about 20 seconds after
"cardctl insert" until I can ping out. ifup can be done right away, but DNS
lookups will have to wait the 20 seconds. When I reconnect with the card
"inserted" in between, no wait is needed.

Finally, also I have noticed that I get full speed on a 10 Mbps LAN. On a 100
Mbps LAN I only get the same speeds as I did on the 10 Mbps LAN. I have a
Sparc/Solaris in my office connected to the same hub as my laptop. It gets
about 40 Mbps, while I only get about 2 Mpbs sending the same compressed file.
The xircom_cb driver does report that it sees a 100 Mbit link.

To summarize, I see:

	slowdown after a while, only an eject/insert cycle fixes that

	having to wait 20 seconds after insert

	Works fine on 10 Mbps, but no speed increase on 100 Mbps.
Comment 10 Arjan van de Ven 2001-05-24 04:30:44 EDT
"having to wait 20 seconds after insert" is because the card needs to negotiate
linkspeed and such and takes ages to do that.

The slowdown and slow behavior is still a mystory for me; I get 8Mbyte/sec
easily. /me keeps looking
Comment 11 Bertil Askelid 2001-05-24 11:35:35 EDT
I have spent more time trying to nail down what is happening and under what 

The 20 second wait is no longer needed. Must have been some temporary glitch
with the 100 Mbps LAN at work.

When things are working, i.e. no slowdown, I do consistently get about the same
speed on a 10 Mbps as a 100 Mbps LAN. OK speed on the 10 Mbps, but way to slow
on the 100 Mbps. There I get 2 Mbps while the Sparc in my room gets 20 Mbps.

I can force the slowdown to happen. An ifdown and then an ifup will in about 50%
of the cases cause the slowdown. A ping to my gateway then looks like this:

	64 bytes from icmp_seq=33 ttl=255 time=849 usec
	64 bytes from icmp_seq=32 ttl=255 time=1.002 sec
	64 bytes from icmp_seq=34 ttl=255 time=23.392 msec
	64 bytes from icmp_seq=35 ttl=255 time=1.022 msec
	64 bytes from icmp_seq=36 ttl=255 time=401.342 msec
	64 bytes from icmp_seq=38 ttl=255 time=705 usec
	64 bytes from icmp_seq=37 ttl=255 time=1.000 sec
	64 bytes from icmp_seq=40 ttl=255 time=841 usec
	64 bytes from icmp_seq=39 ttl=255 time=1.000 sec
	64 bytes from icmp_seq=42 ttl=255 time=728 usec
	64 bytes from icmp_seq=41 ttl=255 time=1.001 sec

with the regular sub msec response interspersed with above sec responses. And it
is not enough to reconnect using ifdown/ifup, a reset using
ifdown/eject/insert/ifup is needed. The slowdown happens with equal probability
on a 10 Mbps and a 100 Mbps LAN.
Comment 12 Arjan van de Ven 2001-06-05 08:41:56 EDT
I've put a new version of the driver up on


this driver should fix the initial 100mbit slowdown; however the "it's slow
after an hour" needs investigating still but I've an idea for that one.
Comment 13 Bertil Askelid 2001-06-05 21:03:44 EDT
Thanks! I now get full speed on a 100 Mbps LAN.

Note that the slowdown still happens. It happens in a bout 50% of the time
immediately after a ifdown/ifup cycle. When it happens, only a
ifdown/eject/insert/ifup helps. I notice the slowdown by looking at the ping
times to my gateway. When the slowdown happens I get 1-2 seconds interspersed
with the regular 600 usec. See above in the ping transcript in my comment from
2001-05-24 11:35:35.
Comment 14 Arjan van de Ven 2001-06-06 05:00:02 EDT
"I get 1-2 seconds" 
this confirms my suspicion about the second problem. What I think is happening
is this:

The card and driver communicate over a series of "descriptors", think of them as
drawers. Every time the kernel wants to send a packet, it places the payload in
the "next" drawer, and tells the card there is a new packet. The card knows what
the "next" drawer is, and goes to look there. There are 4 such drawers, and they
are used sequential (eg 1 2 3 4 1 2 3 4 etc)

Now, if there somehow is a miscommunication, the card will look at the "wrong"
drawer and see that it's empty... if you ping 4 times, all drawers are full and
the card will see all of them, and transmit them in a burst.
Comment 15 Bertil Askelid 2001-06-27 12:53:14 EDT
Since kernel-2.4.3-12 has been released things have gotten worse. After I have
done an ifdown on the Xircom Ethernet slot, an ifup only got a very shaky and
slow connection, to the point where communication programs time out, thus render
the connection useless. In kernel-2.4.2-2, a cardctl eject/insert cycle fixed
the problem. However, in kernel-2.4.3-12 at times that is not enough, a manual
eject/insert cycle has to be done, the card has to be physically removed and
inserted again.

Since the serial_cb module is missing from kernel-2.4.3-12 and my Xircom card
needs that for the modem slot to work, I can't use this latest kernel at all.
See bug 45906.

I hope that you can fix xircom_cb so that I can do ifup and ifdown without
having to do cardctl eject/insert, and the serial_cb problem so I can use my
Modem slot. My ISP don't like me to use the modem 24/7, so I need to be able
switch it off. My configuration is such that I'm connected to a LAN using the
Ethernet slot and disconnects from there to dial in to my ISP using the Modem
slot. All this is automated by a user level script.
Comment 16 Bertil Askelid 2001-08-06 13:41:36 EDT
   I'm now running into problems with the xircom_cb module that I no
   longer can get by with.

   When I'm connecting to a LAN using DHCP at my University Library,
   unfortunately `pump' doesn't manage to make the connection in one go,
   but has to do a card restart in between.  As we have found out
   previously in this bug report, that means that the xircom_cb module
   after the restart has a problem to handle the buffers causing packet
   delays on the seond level, which in turn causes applications to time
   out. It happens all the time, so there is no randomness in this.

   Thus, I can't connect at all using DHCP at that place, and I'm in bad
   need of being able to.

   I wonder what the status is at Red Hat of correcting this bug. Also,
   it worked just fine in redhat-7.0. Could I use the 7.0 modules there for
   the Xircom Cardbus in the current redhat-7.1 release? Or do have to
   go through the hassle of reinstalling 7.0?

   I sincerely hope that you will be able to fix the bug soon.

   Here's a transcript from what's happening during the DHCP connect,
   followed by a ping to the gateway showing the interspersed second
   level packet delays.

   Aug  6 09:09:59 z pumpd[23476]: starting at (uptime 15 days, 18:45:57) Mon
Aug  6 09:09:59 2001
   Aug  6 09:09:59 z kernel: Xircom cardbus adaptor found, registering as eth0,
using irq 11
   Aug  6 09:09:59 z kernel: xircom_cb: enabling promiscuous mode
   Aug  6 09:09:59 z kernel: xircom_cb: capabilities changed from 0xa1 to 0xa1
   Aug  6 09:09:59 z kernel: xircom_cb: Link is absent
   Aug  6 09:10:01 z kernel: xircom_cb: Link is 100 mbit
   Aug  6 09:10:23 z pumpd[23476]: configured interface eth0
   Aug  6 09:10:23 z kernel: Xircom cardbus adaptor found, registering as eth0,
using irq 11
   Aug  6 09:10:23 z kernel: xircom_cb: enabling promiscuous mode
   Aug  6 09:10:23 z kernel: xircom_cb: capabilities changed from 0xa1 to 0xa1
   Aug  6 09:10:23 z kernel: xircom_cb: Link is absent
   Aug  6 09:10:25 z kernel: xircom_cb: Link is 100 mbit
   Aug  6 09:10:26 z named[936]: loading configuration from '/etc/named.conf'
   Aug  6 09:10:26 z named[936]: no IPv6 interfaces found
   Aug  6 09:10:26 z named[936]: listening on IPv4 interface eth0,

   PING ( from : 56(84) bytes of data.
   Warning: time of day goes back, taking countermeasures.
   64 bytes from icmp_seq=0 ttl=255 time=12.486 msec
   64 bytes from icmp_seq=1 ttl=255 time=1.581 msec
   64 bytes from icmp_seq=4 ttl=255 time=257 usec
   64 bytes from icmp_seq=5 ttl=255 time=342 usec
   64 bytes from icmp_seq=2 ttl=255 time=3.000 sec
   64 bytes from icmp_seq=3 ttl=255 time=2.000 sec
   64 bytes from icmp_seq=8 ttl=255 time=302 usec
   64 bytes from icmp_seq=9 ttl=255 time=354 usec
   64 bytes from icmp_seq=6ttl=255 time=3.000 sec
   64 bytes from icmp_seq=7 ttl=255 time=2.000 sec
   64 bytes from icmp_seq=12 ttl=255 time=411 usec
   64 bytes from icmp_seq=13 ttl=255 time=361 usec
   64 bytes from icmp_seq=10 ttl=255 time=3.000 sec
   64 bytes from icmp_seq=11 ttl=255 time=2.000 sec
Comment 17 Bertil Askelid 2001-08-08 15:58:33 EDT
I increased the pump connection attempt timeout to get rid of the xircom_cb
refresh. Unfortunately, pump starts its connection attempt process by doing a
xircom_cb refresh, so I still can't connect to DHCP. So, I can't blame the slow
DHCP server at my library anymore.

DHCP connections cannot be made at all using the xircom_cb module for the Xircom

Please, do you have any ideas what I can do in 7.1 (and on) to get DHCP to work?
It did work in 7.0 using the tulip_cs module. I  hate to have reinstall that old
Comment 18 Bertil Askelid 2001-08-12 12:33:16 EDT
As a temporary solution, I installed the tulip_cb module from the standalone
pcmcia_cs pacakge from http://pcmcia-cs.sourceforge.net/. xircom_cb goes for the
eth0 interface, while tulip_cb selects the eth1. Just connect through eth1 and
the Xircom ethernet card works perfectly without any glitches.
Comment 19 Bertil Askelid 2001-08-14 11:16:27 EDT
   For reproducibility's sake, please, let me clarify exactly what I did
   to make it work:

      I did the following to pcmcia-cs-3.1.28:

         cd pcmcia-cs-3.1.28
         make config
         make all          # might not be needed, but just in case
         cd clients
         make all

      Then I copied pcmcia-cs-3.1.28/clients/tulip_cb.o to
   /lib/modules/2.4.3-12/pcmcia/. Note that I did *not* install anything
   else from the pcmcia-cs package. It might work, but I have no other
   problems with RedHat-7.1 kernel-pcmcia but the xircom_cb, so why
   change that?

   Then I added the following lines to /etc/pcmcia/config:

      device "tulip_cb"
        class "network" module "cb_enabler", "tulip_cb"

   and changed this

      card "Xircom CBEM56G-100 CardBus 10/100 Ethernet + 56K Modem"
        version "Xircom", "*", "CBEM56G"
        bind "xircom_cb" to 0, "serial_cb" to 1

      card "Xircom CBEM56G-100 CardBus 10/100 Ethernet + 56K Modem"
        version "Xircom", "*", "CBEM56G"
        bind "tulip_cb" to 0, "serial_cb" to 1
   Finally, to remove an warning from the boot sequence, I added

      alias eth1 xircom_cb

   to /etc/modules.conf

   With the command

      depmod -a

   the module facility was updated. And now tulip_cb is in charge of the
   Ethernet connections using eth1.
Comment 20 Need Real Name 2001-09-29 10:01:36 EDT
I experienced the same problems with my Xircom CBEM56G-100 CardBus 10/100
Ethernet + 56K Modem card.  I solved my network problems by changing the pcmcia
config to use the yenta_socket.

Now I still have a problem with the modem.  It does not work.
From messages:
Sep 29 15:35:19 localhost cardmgr[18650]: executing: 'modprobe cb_enabler'
Sep 29 15:35:19 localhost cardmgr[18650]: executing: 'modprobe xircom_cb'
Sep 29 15:35:19 localhost cardmgr[18650]: executing: 'modprobe serial_cb'
Sep 29 15:35:19 localhost /etc/hotplug/pci.agent: ... no drivers for PCI slot 
Sep 29 15:35:19 localhost kernel: serial_attach(bus 2, fn 1)
Sep 29 15:35:19 localhost cardmgr[18650]: executing: './network start xircom_cb'
Sep 29 15:35:19 localhost kernel: ttyS04 at port 0x1080 (irq = 11) is a 16550A
Sep 29 15:35:19 localhost cardmgr[18650]: executing: './serial start xircom_cb'
Sep 29 15:35:19 localhost cardmgr[18650]: + Default modem setup
Sep 29 15:35:19 localhost cardmgr[18650]: + ./MAKEDEV xircom_cb
Sep 29 15:35:19 localhost cardmgr[18650]: + don't know how to make device
Sep 29 15:35:19 localhost cardmgr[18650]: + /dev/xircom_cb: No such file or
Sep 29 15:35:19 localhost last message repeated 2 times
Sep 29 15:35:19 localhost cardmgr[18650]: exiting

How can I get my modem to work?

Comment 21 Bertil Askelid 2001-09-29 16:57:16 EDT
cd /dev
ln -sf xircom_cb modem
ln -sf ttyS4     xircom_cb
Comment 22 Need Real Name 2001-09-30 03:55:41 EDT
Now I have a fully operational Xircom card again!
I tried linking /dev/modem -> /dev/ttyS4 before and it did not work.  I never
thought of putting xircom_cb between the two.

Comment 23 Bertil Askelid 2001-11-16 21:42:56 EST
With RedHat-7.2 and the kernel-2.4.9-13, the xircom_tulip_cb module does the
job. Just do the following in your /etc/pcmcia/config file:


	device "xircom_tulip_cb"
	  class "network" module "cb_enabler", "xircom_tulip_cb"

and the change the card "Xircom CBEM56G-100 CardBus 10/100 Ethernet + 56K Modem"
entry to be

	card "Xircom CBEM56G-100 CardBus 10/100 Ethernet + 56K Modem"
  	  version "Xircom", "*", "CBEM56G"
  	  bind "xircom_tulip_cb" to 0

Thanks, pcmcia maintainer!!! You can close this bug now!

Comment 24 Bertil Askelid 2001-11-17 04:09:04 EST
Sorry!!! I was too fast to judge. It still doesn't work. After having used the
modem of the Xircom, the card has to be "cardctl eject/insert" cycled before the
Ethernet connection will work.

RedHat-7.2 kernel-2.4.9-13 i686

What's worse is that pcmcia-cs-3.1.29/tulip_cb won't load on kernel-2.4.9-13 due
to unresolved symbols (bug duly reported to sourceforge). So, again, I have a
non working Xircom PC card.
Comment 25 Arjan van de Ven 2001-11-17 04:12:08 EST
Does xircom_cb work in -13 ? (recent kernels have a different version of this)
Comment 26 Bertil Askelid 2001-11-18 17:22:22 EST
I does work after all! I forgot to add the following to /etc/modules.conf:

	alias eth0              xircom_tulip_cb
	alias eth1              xircom_tulip_cb

So this with the changes to /etc/pcmcia/config described above 
(2001-11-16 21:42:56) makes the Xircom fully functional in kernel-2.4.9-13.

Truly thanks! NOW the bug can be closed!
Comment 27 Need Real Name 2001-11-22 09:02:43 EST
About the "it's slow" bug: the problem remains with both modules xircom_cb and
xircom_tulip_cb: I reach maybe 1Mbit instead of 100 between two NIC's (the other
NIC is a DLINK DFE 530TX, with a driver 'via-rhine'). The PCMCIA card is a
CBEM56G-100 with a 56K modem.

With redhat-7.1, I had to take the module from pcmcia-cs to get normal rates.

This report is on redhat-7.2 with kernel 2.4.9-7.


Comment 28 Bertil Askelid 2001-11-22 09:22:57 EST
To bernard@cmapx.polytechnique.fr:

Have you tried 7.2 with kernel-2.4.9-13? It's only when I shifted to use this ck
latest kernel that I got the card back to work.
Comment 29 Need Real Name 2001-11-27 04:09:05 EST
Answer to Bertil@askelid.com about the '"it's slow" bug:

I have tried the very latest rh kernel on the pcmcia NIC side (2.4.9-13). The
peer NIC is on a desktop running rh7.1, dlink dfe 530tx+ with via-rhine. I also
updated this kernel to the very latest one (2.4.15) I had.

  xircom_cb (yenta_socket): slow (0.5Mbit instead of 100Mbit)
  xircom_tulip_cb (yenta_socket): slow ( " " )

  tulip_cb (from pcmcia-cs, yenta socket support removed): close to 100Mbit.

The only drawback is that I need to use the ifconfig allmulti hack, so I have
devised a tiny script to do this in /sbin/ifup-post, which waits until some
packets have been exchanged to set the interface back to '-allmulti'. It's ugly,
but still better than waiting hours for transfers that should take minutes.

Comment 30 Bertil Askelid 2001-11-27 21:34:35 EST
Hm, I measured the transfer speed and got 22 Mbps on a company LAN with quite a
few active users. kernel-2.4.9-13 in RedHat-7.2.

However, I occasionally after a modem session, the ethernet card wont work until
the Xircom has been cardctl eject/insert cycled. Sometimes I even have to
physically take the card out and insert it again. Now, it doesn't happen as
often as before, but it happens. So the problem is still there, but not as
severe as before.

bernard@cmapx.polytechnique.fr, how did you manage to get the tulip_cb.o loaded?
I get unresolved symbols when I do `depmod -a' with the tulip_cb.o in the
Comment 31 Need Real Name 2001-11-28 03:26:04 EST
I would love to have 22Mbps with xircom[_tulip]_cb. I think the problem is
specific to this very setup: a direct connection between a dlink NIC and the
xircom NIC, with no hub or switch whatsoever in between.

I had suspected the via-rhine driver, but the using the latest via-rhine.c of
kernel-2.4.15 did not help. The mii-tool indicates that on the dlink side a
100Mbit full-duplex connection has been negotiated.

As for the tulip_cb module, it comes from the pcmcia-cs package. Basically, I
recompile the RH kernel (from the sources in kernel-source, with a config file
from /usr/src/linux-2.4/configs/, without PCMCIA support, i.e. without the
yenta_socket module, and without a bunch of things I don't need and that would
take hours to recompile). 

Then I compile the latest pcmcia-cs package on the top of that. Works without
any symbol resolution problem if you follow the instructions in
pcmcia-cs-3.1.30. It works in replacement of the RH package kernel-pcmcia-cs,
with config files pointing to the tulip_cb package. I wrapped this pcmcia-cs
package into an RPM so that switching from the yenta-socket based setup to the
vanilla pcmcia-cs setup is not too piggy.

Comment 32 David Crim 2002-04-09 15:24:25 EDT
I have been playing around with a Xircom CBEM56G under RedHat 7.2. This laptop
used to work great under RedHat 6.2. It has always had problems with newer
releases unless I rebuilt the kernel with an old PCMCIA driver set from the 6.2

Recently I am having some success with a 2.4.9-21 kernel. Using netperf
perfomance went form < 20 Mbits/sec to > 75 Mbits/sec between machines 
attatched to the same switch, a Netgear FS108.

I did the following:

1) Moved /etc/rc.d/rc5.d/S45pcmcia to /etc/rc.d/rc5.d/S09pcmcia. Do the same for
run levels 2, 3, and 4 if you use them.

2) Add a line to /etc/modules.conf:

alias eth0 xircom_tulip_cb

3) Remove xircom_tulip_cb from /etc/hotplug/blacklist.

4) Add xircom_cb to /etc/hotplug/blacklist.

Comment 33 Bertil Askelid 2002-04-09 15:51:21 EDT
However, my original problem still remains unsolved in the latest
kernel (2.4.9-31). The ethernet part of the card is connected and
running OK, an intermittent modem connection will cause a following 
attempt to connect the ethernet part to fail, as described above.

Wonder when this problem will be solved?

Right now, I had recompile the kernel without any pcmcia support
and use the pcmcia-cs-3.1.33 package instead. Works perfectly!

I'm curious to know why it can be done right in the tulicp_cb module
from pcmcia-cs but not in xircom_tulip_cb from kernel-pcmcia?

Any news on what is going to happen with the further development of

Note You need to log in before you can comment on or make changes to this bug.