Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 80213 - xircom CBEM56G very slow
Summary: xircom CBEM56G very slow
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel-pcmcia-cs
Version: 8.0
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Dave Jones
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2002-12-22 14:23 UTC by Sebastien Stormacq
Modified: 2015-01-04 22:02 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2004-11-25 08:27:56 UTC

Attachments (Terms of Use)

Description Sebastien Stormacq 2002-12-22 14:23:53 UTC
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.