Red Hat Bugzilla – Bug 438438
rtl8180 keeps timing out
Last modified: 2009-03-17 13:23:32 EDT
Description of problem:
At (seemingly) random intervals, the rtl8180 driver causes a disconnection
because of a timeout. I have tried to use NDISwrapper with the Windows XP
driver, but this occasionally causes a kernel panic because of Fedora's 4K
stacks. When that program is not causing a panic, it works perfectly, so I
assume that there is a problem with the native rtl8180
Version-Release number of selected component (if applicable):
rtl8180 shipping with kernel-2.6.23-1.fc8.i686 through kernel-126.96.36.199-34.fc8.i686
I don't know exactly how to reproduce it, but if you connect to a wireless
network, it is bound to happen within fifteen minutes.
Steps to Reproduce:
1. Boot up in the latest kernel (188.8.131.52-34.fc8 at this time)
2. Connect to a wireless with a card using the rtl8180 driver (mine happens to
be a TEW-421PC with an RTL8185 chipset)
3. Wait. (Usually about 5-15 minutes)
Disconnection due to timeout (at least, that's what NetworkManager reports)
A steady connection
Sometimes, it will reconnect on it's own, but usually I have to replug the card
to restore the connection. That means on certain segments of my school's
wireless network, I have to reauthenticate, which can take a while. Sometimes
the network disconnects without alerting NetworkManager
Let me know what logs I should post, as I have no idea where to look (other than
/var/log/messages, and I saw nothing out of the ordinary there)
Please attach the contents of /var/log/messages anyway, just in case we can
see something interesting. If possible, perhaps you can attach a wireshark
capture taken from another station that shows the time when you disconnect?
Created attachment 298914 [details]
Also, when I type ifup wlan0, it gives me this:
Error for wireless request "Set Encode" (8B2A) :
SET failed on device wlan0 ; No such file or directory.
Determining IP information for wlan0... Done
How would I get a wireshark capture?
The "Set Encode" message is (sadly) normal -- please ignore it.
Please attach the output of running "iwconfig wlan0 scan". Also, would you
mind attaching the output of runnign "ps aux"?
Let's hold-off on the wireshark capture for the moment.
Created attachment 298921 [details]
First output is while it was disconnected, Second is while connected
Just to keep you posted, kernel-184.108.40.206-50.fc8 still has this problem.
There is a patch in the builds here which may address this issue:
When the build completes, could you give that a try? Does it help? Thanks!
should I install the debug version, or just the regular?
The non-debug version is fine.
nope, same problem. Although I have noticed something odd:
No matter how physically close I get to the router, NM always reports the signal
strength in the range of 22%-27%, and the network speed is usually reported as 1
MB/s. I have rarely seen values outside that range. I don't know if that helps,
but... there it is.
This problem still exists in as of 220.127.116.11-18 in Fedora 9. Should I refile the
bug under Fedora 9
I'm not sure of any specific fix, but it might be wortwhile for you to try a
Can you recreate this issue with those kernels?
Same problem with 18.104.22.168-39.fc9.i686. Although, before, the NM applet would
always register two bars, no matter what. Now, it seems to randomly switch
between one, two, and three bars. I don't know if that means anything, but there
Is this still an issue in -108 or later?
Still an issue in -108. I just downloaded the new 2.6.26 kernel, so I will keep you posted.
Created attachment 319687 [details]
Normalize quality values to 100-point scale.
I don't have a good theory on why this would help, but without this patch the driver can report quality levels like "133/100" -- that might be confusing NM and/or wpa_supplicant?
Well, I think it is worth a try -- want to build a kernel w/ this patch applied and give it a shot?
I have never compiled a kernel before, but I'd like to give it a try. What do I need?
FWIW, the patch from comment 16 never really worked... :-(
I've been using this device with the equivalent of a rawhide kernel lately, and it seems to work alright for me. Are you still seeing problems with recent kernels? If so, what is the latest kernel you have tried?
Closed due to lack of response. Please reopen if/when the requested information becomes available...thanks!