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!
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!
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!
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 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/