Bug 11176

Summary:	rtl8180: disconnects randomly after some minutes of use. (and other things)
Product:	Drivers	Reporter:	Diego Escalante Urrelo (diegoe)
Component:	network-wireless	Assignee:	John W. Linville (linville)
Status:	CLOSED CODE_FIX
Severity:	normal	CC:	diegoe, guido.iodice, hvengel, linux
Priority:	P1
Hardware:	All
OS:	Linux
Kernel Version:	2.6.26	Subsystem:
Regression:	No	Bisected commit-id:
Attachments:	rtl8180: fix tx status reporting

Description Diego Escalante Urrelo 2008-07-30 02:14:05 UTC

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.

Comment 1 John W. Linville 2008-08-14 10:46:25 UTC

Could you attach the contents of /var/log/messages just after a disconnection?

Comment 2 John W. Linville 2008-09-30 07:11:24 UTC

Closed based on lack of response...please reopen with the requested information when/if it becomes available...

Comment 3 Diego Escalante Urrelo 2008-11-12 00:03:40 UTC

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.

Comment 4 Diego Escalante Urrelo 2009-04-11 01:20:49 UTC

Hey guys, would you reconsider giving some love to this bug?

Comment 5 Guido 2010-02-23 12:56:42 UTC

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.

Comment 6 John W. Linville 2010-04-29 15:27:44 UTC

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?

Comment 7 Hal V. Engel 2010-07-09 06:07:52 UTC

(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?

Comment 8 Guido 2010-07-09 07:48:44 UTC

Is the patch already included in 2.6.35-rc4?

Comment 9 John W. Linville 2010-07-19 20:54:25 UTC

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