Bug 66745 - [xirc2ps_cs] Network problems with Xircom PCMCIA NIC/modem
[xirc2ps_cs] Network problems with Xircom PCMCIA NIC/modem
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jeff Garzik
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2002-06-14 15:43 EDT by Mike Gahagan
Modified: 2013-07-02 22:06 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-09-30 11:39:40 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
lsmod output, should be about the same for -4 (700 bytes, text/plain)
2002-06-14 15:54 EDT, Mike Gahagan
no flags Details
lspci output (5.40 KB, text/plain)
2002-06-14 15:55 EDT, Mike Gahagan
no flags Details
relevant bits of /var/log/messages with several vfree() messages from both kernels (74.24 KB, text/plain)
2002-06-14 15:56 EDT, Mike Gahagan
no flags Details

  None (edit)
Description Mike Gahagan 2002-06-14 15:43:33 EDT
Description of Problem:

kernel vfree() messages anytime card is removed (2.4.18-3 and -4) Machine
remains responsive.

Network performance problems with 2.4.18-4:
   Network transfer rates are either very slow all the time (50k/sec on a 100 MB
switched LAN) or will work reasonably well for a short period of time then
network becomes unresponsive until machine is rebooted. This behavior is not
seen on 2.4.18-3. I have recieved approx. 1.5MB/sec over NFS using 2.4.18-3 on
the same network.

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

7.3 w/ all errata installed, using both 2.4.18-3 and 2.4.18-4.

How Reproducible:


Steps to Reproduce:
1. remove NIC at any time to get vfree()
2. slow or stalled network performance under 2.4.18-4 observable under all
network protocols/apps I have tried (FTP, Samba, NFS, pings, DNS queries)

Actual Results:

2.4.18-3 - can always reproduce oops seen when removing card, network
performance acceptable.

2.4.18-4 - oops always reproduceable, network performance as described above.

Expected Results:

no oopses when removing cards, decent network performance :)

Additional Information:
Please see attached files.
Comment 1 Mike Gahagan 2002-06-14 15:54:35 EDT
Created attachment 61024 [details]
lsmod output, should be about the same for -4
Comment 2 Mike Gahagan 2002-06-14 15:55:29 EDT
Created attachment 61025 [details]
lspci output
Comment 3 Mike Gahagan 2002-06-14 15:56:48 EDT
Created attachment 61026 [details]
relevant bits of /var/log/messages with several vfree() messages from both kernels
Comment 4 diego.santacruz 2002-10-01 05:46:46 EDT
I also reported a similar oops under bug #74735 for the same NIC/modem card.

Additionally, on my laptop I also experience problems when I insert the card.
The network is totally unreliable with many transmission errors. If I put the
interface down and up again (ip link eth0 down; ip link eth0 up) then it works
OK. In the kernel logs one can see that the first time the interface is put up
the kernel reports "silicon revision 0", while the second one reports "silicon
revision 5". This problem can also be seen in the logs in the previous
attachement of this bug report. Something is probably going wrong when the
interface is brought up the first time. This never occured back when I was
running under kernel 2.2.x (long time ago), but has always happened when running
under 2.4.x. The workaround I use is to issue an "ip link eth0 up; ip link eth0
down" in /sbin/ifup-pre-local before the interface is brought up by the network
initialization scripts.
Comment 5 Bugzilla owner 2004-09-30 11:39:40 EDT
Thanks for the bug report. However, Red Hat no longer maintains this version of
the product. Please upgrade to the latest version and open a new bug if the problem

The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases, 
and if you believe this bug is interesting to them, please report the problem in
the bug tracker at: http://bugzilla.fedora.us/

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