Bug 86180
| Summary: | orinoco_cs periodically drops connection with linksys wpc11v3 | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | Justin Georgeson <jgeorgeson> |
| Component: | kernel | Assignee: | Arjan van de Ven <arjanv> |
| Status: | CLOSED ERRATA | QA Contact: | Brian Brock <bbrock> |
| Severity: | high | Docs Contact: | |
| Priority: | medium | ||
| Version: | 9 | CC: | bkoz, damon |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i686 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2003-05-14 18:09:43 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: | |||
Hm, don't know who updated this to say RH 9, but I do still see it in RH 9. I also see the occasional dropped connections. WPC11 Ver. 3.0. Most times this does not affect much, I just to a /etc/init.d/network restart and everything is fine again. Sometimes it gives me a hardlock up as well. The CPU pegges out at 100% ( ksoftirqd_CPU0). Syslog shows lots and lots of this: Apr 6 22:40:37 localhost last message repeated 1359 times Apr 6 22:40:37 localhost kernel: hermes @ IO 0x100: Error -16 issuing command. Apr 6 22:40:37 localhost kernel: hermes @ IO 0x100: Error -16 issuing command. Apr 6 22:40:37 localhost kernel: eth0: Error -110 writing Tx descriptor to BAP Apr 6 22:40:37 localhost kernel: hermes @ IO 0x100: Error -16 issuing command. Apr 6 22:40:37 localhost kernel: hermes @ IO 0x100: Error -16 issuing command. Apr 6 22:40:37 localhost kernel: eth0: Error -110 writing Tx descriptor to BAP This is with RedHat 9, installed on a clean disk on a Toshiba Satellite Pro model 4260. It seems to happen every couple of hours or so for me. I have the same problem with a Netgear MA311, and worked around it with newer beta orinoco drivers compiled against the stock redhat kernel from http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Orinoco.html#download The problem doesn't completely go away, but it shows up a lot less. I can confirm this is still an issue. I'm running RH9 on 1) IBM Thinkpad T30/D-Link 650 2) Dell 600 with Netgear MA401 The failure modes are identical, although for some reason I'm getting more, quicker failures when I'm using static routes versus dhcp. Both of these systems are up2date. After the connectivity drops, and the CPU usage pegs at 100%, dmesg looks like lines and lines of this: eth1: Error -110 writing Tx descriptor to BAP. Does anybody have any work arounds or suggestions? An errata has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2003-172.html I still am experiencing this same problem with RH9 and 2.4.20-20.9. |
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030206 Description of problem: I am Running Red Hat 8.0.94 with kernel 2.4.20-2.48. I have a Linksys WPC11 v3 (Prism 3) 802.11b card. Using an AP which broadcasts its SSID and no encryption, the orinoco_cs driver mostly works. The driver periodically drops the connection. When this happens pinging any hosts on my LAN (like the default gateway) yields "destination unreachable." This is not an issue with inactivity, I've seen this happen with several active connections. Version-Release number of selected component (if applicable): kernel-2.4.20-2.48 How reproducible: Sometimes Steps to Reproduce: 1. Configure a wireless interface with the orinoco_cs driver, default settings 2. Insert a Linksys WPC11 v3 PCMCIA card 3. Go on about your work like normal Actual Results: Association to AP should stay up Expected Results: Association is randomly dropped. Additional info: If caught in time, simply running 'ifup <interface>' can fix it without loosing any of my connections (ssh sessions, web sessions on secure sites, etc).