Red Hat Bugzilla – Bug 85836
100% CPU after large transfer on orinoco_cs card - transfer stalls
Last modified: 2008-01-17 12:49:42 EST
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):
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
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
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
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!
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
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!
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.
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
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)
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/