Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 80213 - xircom CBEM56G very slow
xircom CBEM56G very slow
Product: Red Hat Linux
Classification: Retired
Component: kernel-pcmcia-cs (Show other bugs)
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Dave Jones
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2002-12-22 09:23 EST by Sebastien Stormacq
Modified: 2015-01-04 17:02 EST (History)
2 users (show)

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

Attachments (Terms of Use)

  None (edit)
Description Sebastien Stormacq 2002-12-22 09:23:53 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003

Description of problem:
This is a similar problem to those reported for RedHat 7.1 (bug #37454) and and
for RedHat 7.2 (bug #63071)

I am using a Xircom CBEM56G on a Dell Latitude C800 under RedHat 8.0 and
experiencing a very slow network connection since the RH 8.0 installation.

The network worked great with my previous linux distro (kernel 2.4.18 without
pcmcia support and pcmcia-cs 3.1.?)
 The default installation correctly recognizes the net card but I have a 
maximum throughput of 10 Mb/sec (being connected to a 100 Mb switch)

The workaround detailed in bug #63071 worked for me.
After modifying the config as explained and rebooted, I have a full 100 Mb/s
throughput again !


Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.Install redhat 8.0 - default options - using a Xircom CBE56G pcmcia card
2.test the network performance (netperf)

Actual Results:  networking is very slow (throughput < 10 Mb/s)

Expected Results:  Actual throughput must be around 100 Mb/s

Additional info:

workaround described in bug #63071 worked for me and restored my expected throughput

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