Red Hat Bugzilla – Bug 75237
orinoco_pci flaky on UP, very flaky on SMP kernel
Last modified: 2013-07-02 22:07:31 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020830
Description of problem:
I have an Actiontec wireless PCI card, lspci output:
02:06.0 Network controller: Harris Semiconductor Prism 2.5 Wavelan chipset (rev 01)
Using the SMP kernel, after just a few pings the driver fails with Tx error,
status 1 error messages. The first time I loaded the driver it lasted a bit
longer (on kernel 2.4.18-14smp for Athlon). If I use the UP kernel the driver is
more stable but if I stress the card by downloading large files it crashes the
Version-Release number of selected component (if applicable):
kernel: 2.4.18-14smp, 2.4.18-14
Steps to Reproduce:
1.Configure card using neat (you have to select another network card then
replace it with orinoco_pci in /etc/modules.conf)
2.Activate the wireless connection
3.Do a few pings (SMP) or download large files (UP)
Actual Results: (date) (host name) kernel: eth1: Tx error, status 1 (FID=....)
repeated multiple times
Expected Results: No such error message
Similar to bug 65097 for Red Hat 7.3, and errors I get with the Kawasaki 19250
USB network device last year - flaky driver!
Correction: error message was:
eth1: Error -110 writing Tx descriptor to BAP
I also have problems with this driver on my IBM ThinkPad T30, which has a
built-in wireless card. The wireless capability will work for some period of
time, then dies unexpectedly. In addition, the error message is written out
frequently enough that it affects the performance of the rest of the system.
In order to restart the wireless networking it is necessary to ifdown the
device, then remove the orinoco_pci module, reload the module, then ifup the
Here is the relevant output of lspci -vvv for this device:
02:02.0 Network controller: Harris Semiconductor Prism 2.5 Wavelan chipset (rev
Subsystem: Intel Corp.: Unknown device 2513
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr-
Stepping- SERR+ FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 64, cache line size 08
Interrupt: pin A routed to IRQ 11
Region 0: Memory at f8000000 (32-bit, prefetchable) [size=4K]
Capabilities: [dc] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
IBM ThinkPad A30P, orinoco_pci, RHL 8.0, all kernel versions :
Usually (but not always), when the wireless connection dies, 'iwconfig eth1'
reveals the Encryption Key has been reset.
In that particular case, 'iwconfig eth1 key xyz123...' usually restores my
No new info, just more of the same. RedHat 8.0 IBM T30 orinoco_pci module. Lots
of "eth1: Error -110 writing Tx descriptor to BAP" kmessages, and 100% CPU
utilization on kernel logger. Only work-around found so far is to 'ifdown eth1;
rmmod orinoco_pci orinoco; ifup eth1'.
Same here: Netgear MA401 card, stock Redhat 8.0 kernel. The lockups usually
occur during heavy file transfers and the only solution is ejecting and
reinserting the card.
Dec 9 20:05:28 localhost kernel: eth1: error -110 reading Rx descriptor. Frame
Dec 9 20:05:28 localhost kernel: eth1: Error -110 writing packet header to BAP
Dec 9 20:05:28 localhost kernel: eth1: Error -110 writing Tx descriptor to BAP
Dec 9 20:05:56 localhost last message repeated 18823 times
I also have the problem with an IBM ThinkPad A31, RH8.0 and the orinoco_pci
driver. Under heavy network loads the card hangs and gives the following error:
eth1:Error -110 writing Tx descriptor to BAP
It appears to be a kernel driver issue since I recieve the same errors using
different kernels and different distros.
It is easy for me to replicate this: send a lot of outbound data, receving data
doesn't trigger it as frequently. When it does it is probably ACKs doing anyway.
I've got an IBM T30 laptop, and am seeing this problem, just like Greg Kurtzner.
It seems to happen when I RECEIVE a lot of data, for example if I'm updating a
lot of RPM's. At MIT I expect people will be doing updates of Linux in this way,
so this will be a pretty important bug to users that I take care of.
Bug still present in kernel 2.4.20-2.2 (RawHide / Phoebe 8.0.92).
Comment #9 : Sorry, I forgot to mention that kernel was compiled on stock RHL
8.0 (and thus not tested under Phoebe).
I have a prism2/intersil built-in pci wireless card on a fujitsu lifebook
notebook computer. The orinoco_pci driver has very similar problems: works OK
for simple websurfing, but as soon as a do a large upload it chokes and
connection can't be restarted properly. This is a UP kernel for i686 in redhat
7.3 (kernel 2.4.18-19.7.x).Jan 14 13:56:55 . Here are some of the error msgs:
cholla kernel: eth1: Error -110 writing packet to BAP
Jan 14 13:56:55 cholla kernel: eth1: Error -110 writing Tx descriptor to BAP
Jan 14 13:57:26 cholla last message repeated 33726 times
Jan 14 13:58:27 cholla last message repeated 68372 times
Jan 14 13:58:36 cholla last message repeated 10143 times
Jan 14 13:58:36 cholla kernel: eth1: Error -110 setting multicast list.
Jan 14 13:58:36 cholla kernel: eth1: Error -110 writing Tx descriptor to BAP
Jan 14 13:58:36 cholla kernel: hermes @ MEM 0xe0145000: Timeout waiting for card
to reset (reg=0x0000)!
Jan 14 13:58:36 cholla kernel: eth1: Error -110 shutting down Hermes chipset
Jan 14 13:58:40 cholla kernel: hermes @ MEM 0xe0145000: Error -16 issuing command.
Jan 14 13:58:40 cholla last message repeated 8 times
However, this wireless card works flawlessly using the prism2_pci driver from
wlan-ng . I obtained the rpms for this driver from this URL:
The source code configured for generating redhat rpms is available there too.
Perhaps redhat should consider packaging these drivers with their distribution...
I have just switched over to the wlan-ng drivers too, I have not been able to
crash them in my stress testing.
Unfortunately, they don't integrate too well with redhat-config-network et al,
and their configuration tools are pretty horrid (mib style commands in a UI, gah!).
*** Bug 85529 has been marked as a duplicate of this bug. ***
Same problem with RH9, Netgear MA401, Dell Latitude C600. It's a showstopper
for real work.
I too have the same problem with RH9 and Netgear MA401 card.
Same problem: a lot of "eth1: Error -110 writing Tx descriptor to BAP"
kernel errors that make klogd use the CPU at 100%. This always
reproducible when I upload a large file at maximum throughput, on a
local LAN. It usually happens in the first 30 seconds of upload.
Oh, forgot to add: this is on Fedora Core 2, with kernel 2.6.5.
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/