Bug 66745

Summary: [xirc2ps_cs] Network problems with Xircom PCMCIA NIC/modem
Product: [Retired] Red Hat Linux Reporter: Mike Gahagan <mgahagan>
Component: kernelAssignee: Jeff Garzik <jgarzik>
Status: CLOSED CURRENTRELEASE QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.3CC: diego.santacruz, peterm
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-09-30 15:39:40 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
lsmod output, should be about the same for -4
none
lspci output
none
relevant bits of /var/log/messages with several vfree() messages from both kernels none

Description Mike Gahagan 2002-06-14 19:43:33 UTC 
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:

always

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)
3. 

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 19:54:35 UTC 
Created attachment 61024 [details]
lsmod output, should be about the same for -4
Comment 2 Mike Gahagan 2002-06-14 19:55:29 UTC 
Created attachment 61025 [details]
lspci output
Comment 3 Mike Gahagan 2002-06-14 19:56:48 UTC 
Created attachment 61026 [details]
relevant bits of /var/log/messages with several vfree() messages from both kernels
Comment 4 diego.santacruz 2002-10-01 09:46:46 UTC 
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 15:39:40 UTC 
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
persists.

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/