Latest working kernel version: none Earliest failing kernel version: 2.6.25 (it was included since then) Distribution: Ubuntu Intrepid (but also fails in -say- Fedora that includes .25) Hardware Environment: IBM Thinkpad r50e laptop, card is pcmcia a cheap wifi card using the realtek chip. 02:00.0 CardBus bridge: Texas Instruments PCI1510 PC card Cardbus Controller 03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8180L 802.11b MAC (rev 20) Software Environment: Problem Description: When using the rtl8180 driver, the card drops the connection frequently by no reason, nothing is printed to dmesg. This is not a problem with the AP, the disconnections occur at the same exact place where it works with the alternative driver(see below) or ndiswrapper. If I recall correctly, this was present in an old version of the driver that ubuntu used to ship up to 2.6.16~18. Basically, when NetworkManager pinged the card for its status, it disconnected sometimes. Of course, we can't say it's a NM bug, given that so many other cards out there don't drop connections :). Alternative driver Thanks to the interwebs, I still can use the card with the driver found in http://rtl-wifi.sf.net, they have an improved (well, for me it's better) version of the driver that (as I can see) was merged into the kernel. I have been able to use WEP keys (my card doesn't support WPA) without a problem and had no sudden disconnects, the only missing feature for me is multicast support that looks like a placeholder in the source iirc. I'm using their latest svn right now: https://rtl-wifi.svn.sourceforge.net/svnroot/rtl-wifi So this report can be summarized in: 1. there's a problem with the card disconnecting randomly, apparently when someone ask it for it's state too much 2. the card doesn't work with WEP keys for me, only when I use the alternative driver WEP keys work. 3. if you can please check rtl-wifi and see if they have any modification you could use, it would be great to not have to build my own module for 2.6.27 too :). 4. please hack multicast support to the driver Thanks for your patience and hard work, let me know if I can help you with more info.
Could you attach the contents of /var/log/messages just after a disconnection?
Closed based on lack of response...please reopen with the requested information when/if it becomes available...
Sorry for the late response, this is the extract of what was printed on the disconnect: [281046.560826] ADDRCONF(NETDEV_UP): wlan0: link is not ready [281046.605228] wlan0: authenticate with AP 00:11:f5:50:49:b7 [281046.644182] wlan0: authenticate with AP 00:11:f5:50:49:b7 [281046.844095] wlan0: authenticate with AP 00:11:f5:50:49:b7 [281047.044393] wlan0: authenticate with AP 00:11:f5:50:49:b7 [281047.244079] wlan0: authentication with AP 00:11:f5:50:49:b7 timed out [281195.112424] ADDRCONF(NETDEV_UP): wlan0: link is not ready [281195.156067] wlan0: authenticate with AP 00:11:f5:50:49:b7 [281195.356071] wlan0: authenticate with AP 00:11:f5:50:49:b7 [281195.556049] wlan0: authenticate with AP 00:11:f5:50:49:b7 [281195.756070] wlan0: authentication with AP 00:11:f5:50:49:b7 timed out [281230.360061] wlan0: authenticate with AP 00:11:f5:50:49:b7 [281230.560107] wlan0: authenticate with AP 00:11:f5:50:49:b7 [281230.760085] wlan0: authenticate with AP 00:11:f5:50:49:b7 [281230.961869] wlan0: authentication with AP 00:11:f5:50:49:b7 timed out [281246.697665] wlan0: authenticate with AP 00:11:f5:50:49:b7 [281246.896270] wlan0: authenticate with AP 00:11:f5:50:49:b7 [281247.096099] wlan0: authenticate with AP 00:11:f5:50:49:b7 [281247.296304] wlan0: authentication with AP 00:11:f5:50:49:b7 timed out Here I tried a pccard eject/insert: [281272.417781] pccard: card ejected from slot 0 [281272.524334] rtl8180 0000:03:00.0: PCI INT A disabled [281275.717001] pccard: CardBus card inserted into slot 0 [281275.717054] PCI: 0000:03:00.0 reg 10 io port: [0, ff] [281275.717064] PCI: 0000:03:00.0 reg 14 32bit mmio: [0, 1ff] [281275.717116] pci 0000:03:00.0: supports D1 [281275.717120] pci 0000:03:00.0: supports D2 [281275.717124] pci 0000:03:00.0: PME# supported from D1 D2 D3hot D3cold [281275.717131] pci 0000:03:00.0: PME# disabled [281275.743067] rtl8180 0000:03:00.0: enabling device (0000 -> 0003) [281275.743088] rtl8180 0000:03:00.0: PCI INT A -> Link[LNKA] -> GSI 11 (level, low) -> IRQ 11 [281275.743109] rtl8180 0000:03:00.0: setting latency timer to 64 [281275.829337] phy2: Selected rate control algorithm 'pid' [281275.831001] phy2: hwaddr 00:0b:9d:00:46:a8, RTL8180 + Philips [281277.020408] ADDRCONF(NETDEV_UP): wlan0: link is not ready [281278.208049] wlan0: authenticate with AP 00:11:f5:50:49:b7 [281278.408052] wlan0: authenticate with AP 00:11:f5:50:49:b7 [281278.608052] wlan0: authenticate with AP 00:11:f5:50:49:b7 [281278.808061] wlan0: authentication with AP 00:11:f5:50:49:b7 timed out Still no use! This is from my last problem with this, just some minutes ago. If you want the FULL dmesg of one session, let me know, but it's not really different. AP times out and it stops working. This is the log for my successful connection just after this break down: Removed and modprobe the module again: [282589.180960] rtl8180 0000:03:00.0: PCI INT A -> Link[LNKA] -> GSI 11 (level, low) -> IRQ 11 [282589.229890] phy3: Selected rate control algorithm 'pid' [282589.231437] phy3: hwaddr 00:0b:9d:00:46:a8, RTL8180 + Philips [282622.680362] ADDRCONF(NETDEV_UP): wlan0: link is not ready [282623.876069] wlan0: authenticate with AP 00:11:f5:50:49:b7 [282623.877694] wlan0: authenticated [282623.877702] wlan0: associate with AP 00:11:f5:50:49:b7 [282623.880068] wlan0: RX AssocResp from 00:11:f5:50:49:b7 (capab=0x401 status=0 aid=1) [282623.880076] wlan0: associated [282623.880705] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready [282634.444041] wlan0: no IPv6 routers present [282652.984793] ADDRCONF(NETDEV_UP): wlan0: link is not ready [282653.030195] wlan0: authenticate with AP 00:11:f5:50:49:b7 [282653.083949] wlan0: authenticate with AP 00:11:f5:50:49:b7 [282653.084070] wlan0: authenticated [282653.084080] wlan0: associate with AP 00:11:f5:50:49:b7 [282653.088153] wlan0: RX AssocResp from 00:11:f5:50:49:b7 (capab=0x401 status=0 aid=1) [282653.088174] wlan0: associated [282653.089138] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready Working! I suspect this could be related to http://bugzilla.kernel.org/show_bug.cgi?id=11392 , perhaps the driver is thinking that the really low signal means we are disconnected... or something like a line like: ap_works = (signal_level > 0), which could possibly give false despite reality would say true due to the mentioned bug.
Hey guys, would you reconsider giving some love to this bug?
I confirm the bug on linux 2.6.31 and 2.6.32: lspci: 03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8185 IEEE 802.11a/b/g Wireless LAN Controller (rev 20) uname -r: 2.6.32-10-generic (Ubuntu kernel based on linux 2.6.32.2 iwconfig wlan0: wlan0 IEEE 802.11bg ESSID:"Conceptronic" Mode:Managed Frequency:2.452 GHz Access Point: 00:80:5A:37:6C:A9 Bit Rate=1 Mb/s Tx-Power=20 dBm Retry long limit:7 RTS thr:off Fragment thr:off Power Management:off Link Quality=34/100 Signal level=34/100 Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0 (the router is very near with PC, about 50 cm) I installet 2.6.33 modules with linux-backports-modules in Ubuntu. The problem is still here.
Created attachment 26182 [details] rtl8180: fix tx status reporting This allows the rate control algorithm to do its job. Does it help with this issue?
(In reply to comment #6) > Created an attachment (id=26182) [details] > rtl8180: fix tx status reporting > > This allows the rate control algorithm to do its job. Does it help with this > issue? I applied this change to the 2.6.34 kernel and it did seem to fix the rate control issue. Before the fix I was getting: # iwlist wlan0 rate wlan0 unknown bit-rate information. Current Bit Rate:1 Mb/s Now I get: # iwlist wlan0 rate wlan0 unknown bit-rate information. Current Bit Rate:54 Mb/s I am also seeing higher download and ping speeds after this change. Download speeds are about 3 times as fast and probably are bottle necked on the Internet connection now. Pings of the local router/ap are about twice as fast. Big improvement. Now perhaps we can get a fix for the bad signal strength reports coming from this driver?
Is the patch already included in 2.6.35-rc4?
Yes it is. commit d989ff7cf8d14f1b523f63ba0bf2ec1a9b7c25bc Author: John W. Linville <linville@tuxdriver.com> Date: Wed Apr 28 19:14:42 2010 -0400 rtl8180: fix tx status reporting When reporting Tx status, indicate that only one rate was used. Otherwise, the rate is frozen at rate index 0 (i.e. 1Mb/s). Signed-off-by: John W. Linville <linville@tuxdriver.com> Cc: stable@kernel.org