Bug 85836 - 100% CPU after large transfer on orinoco_cs card - transfer stalls
Summary: 100% CPU after large transfer on orinoco_cs card - transfer stalls
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel
Version: 9
Hardware: i686
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Arjan van de Ven
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-03-08 22:04 UTC by Thomas M Steenholdt
Modified: 2008-01-17 17:49 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2004-09-30 15:40:37 UTC
Embargoed:


Attachments (Terms of Use)

Description Thomas M Steenholdt 2003-03-08 22:04:34 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030206

Description of problem:
I recently purchased a wlan card, and it works just fine, using the orinoco_cs
driver - But when i tried to do a mirror of my local ftp server, only a couple
of secs into the transfer the transfer stalled and the machine went into 100%
CPU usage, and stayed there, even after i killed the downloading process...
Taking out the card make the CPU usage drop again. Inserting the card after this
shows no remains of the problem. Retrying shows the same problem!

The process using all the resources is ksoftirqd_CPU0.

The WLAN card is a ZyXel B-100 in infrastructure mode using 64-bit WEP encryption.

I used the card for browsing the internet all night with no problems, but these
large transfers makes it stall!

Just to make sure wget was not the troubled one i reproduced the error using ncftp.

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


How reproducible:
Always

Steps to Reproduce:
1. From a system with a ZyXel B-100(or i guess other similar card) do an ftp
transfer from a fast ftp server.
2. Watch as the system cpu usage hits the roof

    

Actual Results:  CPU usage increases to 100% and transfer stalls!

Expected Results:  CPU usage should be moderate and transfer should finish
successfully

Additional info:

Please ask for further info - I'm afraid the wireless LAN business is still new
to me, so i might have missed some important piece of information to provide you
with!

Comment 1 Thomas M Steenholdt 2003-03-10 21:19:02 UTC
The problem depicted above is with the Phoebe kernel 2.4.20-2.5 for i686.

However the problem goes back to RH 8.0 as well... The exact same problem
happens on Psyche kernel 2.4.18-26.8.0 for i686.

It seems that my problem has been discussed on the linux kernel mailing list, so
i can't possibly be the only one experiencing this problem.

problem number 2 mentioned in this mail
http://www.cs.helsinki.fi/linux/linux-kernel/2002-20/0553.html
looks very much like what i have seen at least on the RH 8.0 kernel.

The thread mentions that this might actually be a pcmcia problem rather that a
driver problem... Please advice on this one!

Comment 2 Thomas M Steenholdt 2003-03-10 22:27:58 UTC
Okay - I made a bold test on my RH8.0 installation (i would have mad it on
Phoebe only i'd have to install it so i thought i'd see if it would actually
make a difference) I took drivers/net/wireless/hermes* and
/drivers/net/wireless/orinoco*  from 2.4.21-pre5 and simply copied the files
into the 2.4.18-26.8.0 source tree, then rebuilt!
The transfer stall and the 100% CPU issues disappeared! I saw some "Lost
information frame" messages. but these seems a lot less severe than my previous
errors.

What's the chance of having a driver update like this incorporated in the Phoebe
kernel before the final version is released?

Is there anything else that you'd like me to try? I could try doing the same
thing on Phoebe-3!

Comment 3 Thomas M Steenholdt 2003-03-12 22:01:56 UTC
Did the same test in another way on Phoebe-3.

Downloaded orinoco-0.13b.tar.gz from
http://ozlabs.org/people/dgibson/dldwd/orinoco-0.13.tar.gz untarred, built and
installed - Everything seems to work fine - or at least better. It doesn't hang
although i get debug messages on-screen :
eth1: Information frame lost (lots of these when downloading at full speed)
eth1: Tx timeout! ALLOCFID=0128, TXCOMPLFID=03c9, EVSTAT=a08b (no so many of
these, yet some)

I also tried with 0.13c and that seems to put out more of the Tx errors than
0.13b. Doesn't hang though!

The problem that I have descriped in this bug-report seems to be well-known by
the driver maintainer... Its listed in the README.orinoco file included in the
tar-files... He has some things to try that i haven't tried yet, but i will. 

Comment 4 Arjan van de Ven 2003-03-12 22:04:05 UTC
we've tried the .13 driver in rawhide for a bit, and unfortionatly for several
people it solidly hug the machine sometimes....
I'd love to get it fixed, my own card suffers from this too.
2 things I did to help it a bit:
1) ping some host constnatly
2) switch to wvlan_cs

Comment 5 Thomas M Steenholdt 2003-03-12 22:45:35 UTC
wvlan_cs will not even initialize on my card - probably because this is a fairly
new prism based card?!?
The interesting thing is that it is only a problem when transferring data at
max-speed(max 802.11b nic speed)

Comment 6 Bugzilla owner 2004-09-30 15:40:37 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/



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