Bug 12588
| Summary: | "weak signal" with rtl8180 and Belking 701f | ||
|---|---|---|---|
| Product: | Drivers | Reporter: | drkludge |
| Component: | network-wireless | Assignee: | John W. Linville (linville) |
| Status: | CLOSED CODE_FIX | ||
| Severity: | high | CC: | guido.iodice, lean-kernelbug, linville, mexsalem, wolkenschieber |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | 2.6.28.2 | Subsystem: | |
| Regression: | No | Bisected commit-id: | |
| Attachments: |
rtl8180: fix tx status reporting
0001-rtl8180-improve-signal-reporting-for-rtl8185-hardwar.patch 0001-rtl8180-improve-signal-reporting-for-rtl8185-hardwar.patch |
||
|
Description
drkludge
2009-01-31 12:29:10 UTC
*** This bug has been marked as a duplicate of bug 11392 *** i'm not sure this is actually the same bug as 11392... it seems from my reading that bug has the driver reporting the wrong values, but not interfering with connections. in other words, if i understand correctly, the driver works but lies.
in my case, the driver may be wrong about the signal quality, but it sure acts like it's telling the truth. i can only "see" the one network, and i'm unable to connect to it; as if it actually were out of range:
dmesg <snip> with ndiswrapper:
Feb 4 10:11:32 laura ndiswrapper version 1.53 loaded (smp=yes, preempt=yes)
Feb 4 10:11:32 laura ndiswrapper: driver net8185 (Realtek,02/01/2007,5.1097.0201.2007) loaded
Feb 4 10:11:32 laura ndiswrapper 0000:06:00.0: PCI INT A -> Link[LNKB] -> GSI 11 (level, low) -> IRQ 11
Feb 4 10:11:33 laura ndiswrapper: using IRQ 11
Feb 4 10:11:38 laura wlan0: ethernet device 00:17:3f:d6:bc:9c using NDIS driver: net8185, version: 0x50449, NDIS version: 0x500, vendor: 'Realtek RTL8185 Wireless LAN (Mini-)PCI NIC ', 1799:701F.5.conf
Feb 4 10:11:38 laura wlan0: encryption modes supported: WEP; TKIP with WPA, WPA2, WPA2PSK; AES/CCMP with WPA, WPA2, WPA2PSK
Feb 4 10:11:38 laura usbcore: registered new interface driver ndiswrapper
Feb 4 10:11:55 laura dhcpcd[415]: wlan0: dhcpcd not running
Feb 4 10:11:55 laura dhcpcd[416]: eth0: dhcpcd not running
Feb 4 10:11:55 laura dhcpcd[426]: wlan0: dhcpcd 4.0.7 starting
Feb 4 10:11:55 laura dhcpcd[426]: wlan0: broadcasting for a lease
Feb 4 10:11:59 laura dhcpcd[426]: wlan0: offered 192.168.1.100 from 192.168.1.1
Feb 4 10:11:59 laura dhcpcd[426]: wlan0: checking 192.168.1.100 is available on attached networks
Feb 4 10:12:04 laura dhcpcd[426]: wlan0: acknowledged 192.168.1.100 from 192.168.1.1
Feb 4 10:12:04 laura dhcpcd[426]: wlan0: leased 192.168.1.100 for 86400 seconds
# \/ modprobe -r ndiswrapper \/
Feb 4 15:28:54 laura ndiswrapper: device wlan0 removed
Feb 4 15:28:54 laura ndiswrapper 0000:06:00.0: PCI INT A disabled
# \/ modprobe rtl8180 \/
Feb 4 15:30:23 laura cfg80211: Using static regulatory domain info
Feb 4 15:30:23 laura cfg80211: Regulatory domain: US
Feb 4 15:30:23 laura (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
Feb 4 15:30:23 laura (2402000 KHz - 2472000 KHz @ 40000 KHz), (600 mBi, 2700 mBm)
Feb 4 15:30:23 laura (5170000 KHz - 5190000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
Feb 4 15:30:23 laura (5190000 KHz - 5210000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
Feb 4 15:30:23 laura (5210000 KHz - 5230000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
Feb 4 15:30:23 laura (5230000 KHz - 5330000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
Feb 4 15:30:23 laura (5735000 KHz - 5835000 KHz @ 40000 KHz), (600 mBi, 3000 mBm)
Feb 4 15:30:23 laura cfg80211: Calling CRDA for country: US
Feb 4 15:30:23 laura rtl8180 0000:06:00.0: PCI INT A -> Link[LNKB] -> GSI 11 (level, low) -> IRQ 11
Feb 4 15:30:23 laura phy0: Selected rate control algorithm 'pid'
Feb 4 15:30:24 laura phy0: hwaddr 00:17:3f:d6:bc:9c, RTL8185vD + rtl8225z2
Feb 4 15:30:24 laura load-modules.sh: 'platform:regulatory' is not a valid module or alias name
since i'm using wicd, it will see interface when it comes up and try to connect. i can't provide the output of dhcpcd's attempts to connect because right now iwlist doesn't see the network at all, but on those rare occassions when it does, it times out trying to probe the access point.
here are two runs of iwlist with the two drivers, for comparison's sake:
with ndiswrapper:
wlan0 Scan completed :
Cell 01 - Address: 00:1F:F3:C1:99:5E
ESSID:"Manuel Arellano"
Protocol:IEEE 802.11g
Mode:Managed
Frequency:2.437 GHz (Channel 6)
Quality:32/100 Signal level:-75 dBm Noise level:-96 dBm
Encryption key:on
Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 6 Mb/s
9 Mb/s; 12 Mb/s; 18 Mb/s
Extra:bcn_int=100
Extra:atim=0
IE: IEEE 802.11i/WPA2 Version 1
Group Cipher : TKIP
Pairwise Ciphers (2) : CCMP TKIP
Authentication Suites (1) : PSK
IE: WPA Version 1
Group Cipher : TKIP
Pairwise Ciphers (1) : TKIP
Authentication Suites (1) : PSK
Cell 02 - Address: 00:1D:7E:41:7E:98
ESSID:"admin"
Protocol:IEEE 802.11g
Mode:Managed
Frequency:2.422 GHz (Channel 3)
Quality:48/100 Signal level:-65 dBm Noise level:-96 dBm
Encryption key:off
Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 18 Mb/s
24 Mb/s; 36 Mb/s; 54 Mb/s
Extra:bcn_int=100
Extra:atim=0
Cell 03 - Address: 00:14:95:1E:AB:B9
ESSID:"2WIRE359"
Protocol:IEEE 802.11g
Mode:Managed
Frequency:2.437 GHz (Channel 6)
Quality:39/100 Signal level:-71 dBm Noise level:-96 dBm
Encryption key:on
Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 6 Mb/s
9 Mb/s; 12 Mb/s; 18 Mb/s
Extra:bcn_int=100
Extra:atim=0
with rtl8180:
lan0 Scan completed :
Cell 01 - Address: 00:1D:7E:41:7E:98
ESSID:"admin"
Protocol:IEEE 802.11g
Mode:Managed
Frequency:2.422 GHz (Channel 3)
Quality:9/100 Signal level:-65 dBm Noise level:-96
dBm
Encryption key:off
Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 18 Mb/s
24 Mb/s; 36 Mb/s; 54 Mb/s
Extra:bcn_int=100
Extra:atim=0
(sorry if re-opening is obnoxious. if i'm really just pissing in the wind, please do close again.)
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 confirm this bug on Linux 2.6.32.3.
Bit rate and signal is very weak.
lspci:
04:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8185 IEEE 802.11a/b/g Wireless LAN Controller (rev 20) [LevelOne WNC-0301 rev 6]
uname:
Linux 2.6.32.3-atom #1 SMP Sat Jan 9 13:56:42 CET 2010 x86_64 GNU/Linux
iwconfig:
wlan0 IEEE 802.11bg ESSID:"Name"
Mode:Managed Frequency:2.437 GHz Access Point: MAC
Bit Rate=1 Mb/s Tx-Power=20 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Power Management:off
Link Quality=20/100 Signal level=20/100
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
distance to router:
approx. 5m
Ndiswrapper doesn't work since there are no working 64-bit drivers from LevelOne or Realtek. Realtek's linux drivers won't compile since Kernel 2.6.31.
Today I use uname -r 2.6.32-13-generic (ubuntu kernel based on latest upstream stable kernel) I installed newest compat wireless by linux-backports-modules in Ubuntu. The issue is still here. lsmod | grep rtl rtl8180 26419 0 mac80211 210453 1 rtl8180 eeprom_93cx6 1333 1 rtl8180 cfg80211 130948 2 rtl8180,mac80211 filename: /lib/modules/2.6.32-13-generic/updates/cw/rtl8180.ko license: GPL description: RTL8180 / RTL8185 PCI wireless driver author: Andrea Merello <andreamrl@tiscali.it> author: Michael Wu <flamingice@sourmilk.net> srcversion: 2FF25434BD6684F625C53BB alias: pci:v00001186d00003300sv*sd*bc*sc*i* alias: pci:v00001799d00006020sv*sd*bc*sc*i* alias: pci:v00001799d00006001sv*sd*bc*sc*i* alias: pci:v000010ECd00008180sv*sd*bc*sc*i* alias: pci:v00001799d0000701Fsv*sd*bc*sc*i* alias: pci:v00001799d0000700Fsv*sd*bc*sc*i* alias: pci:v000010ECd00008185sv*sd*bc*sc*i* depends: mac80211,eeprom_93cx6,cfg80211 vermagic: 2.6.32-13-generic SMP mod_unload modversions 586 Created attachment 26183 [details]
rtl8180: fix tx status reporting
This allows the rate control algorithm to do its job. Does it help with this issue?
@ #6 I tried the patch, and it didn't seem to work. I guess it is too much to ask for a one-liner ;) 07:01.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8185 IEEE 802.11a/b/g Wireless LAN Controller (rev 20) Created attachment 27160 [details]
0001-rtl8180-improve-signal-reporting-for-rtl8185-hardwar.patch
Can you give this a try?
Created attachment 27171 [details]
0001-rtl8180-improve-signal-reporting-for-rtl8185-hardwar.patch
I use an updated subsystem based on compat-wireless-2.6.35-1. It improved my Bit Rate up to 54 Mbit/s instead of fixed 1 MBit/s, but the signal is still weak (Link Quality=16/100 Signal level=16/100 ). I tried this patch but it didn't work for me. mexsalem@GERICOM:~$ lspci -nnk | grep -i realtek -A2 02:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL-8185 IEEE 802.11a/b/g Wireless LAN Controller [10ec:8185] (rev 20) Kernel driver in use: rtl8180 Kernel modules: rtl8180, r8185b mexsalem@GERICOM:~$ modinfo rtl8180 filename: /lib/modules/2.6.32-24-generic/updates/drivers/net/wireless/rtl818x/rtl8180.ko license: GPL description: RTL8180 / RTL8185 PCI wireless driver author: Andrea Merello <andreamrl@tiscali.it> author: Michael Wu <flamingice@sourmilk.net> srcversion: 01F194141F159398B338207 alias: pci:v00001186d00003300sv*sd*bc*sc*i* alias: pci:v00001799d00006020sv*sd*bc*sc*i* alias: pci:v00001799d00006001sv*sd*bc*sc*i* alias: pci:v000010ECd00008180sv*sd*bc*sc*i* alias: pci:v00001799d0000701Fsv*sd*bc*sc*i* alias: pci:v00001799d0000700Fsv*sd*bc*sc*i* alias: pci:v000010ECd00008185sv*sd*bc*sc*i* depends: mac80211,eeprom_93cx6,cfg80211 vermagic: 2.6.32-24-generic SMP mod_unload modversions 586 mexsalem@GERICOM:~/Downloads$ sudo patch -b -p0 < PATCH_v2_rtl8180_improve_signal_reporting_for_rtl81852_hardware.patch patching file b/drivers/net/wireless/rtl818x/rtl8180_dev.c Hunk #1 FAILED at 103. Hunk #2 FAILED at 130. 2 out of 2 hunks FAILED -- saving rejects to file b/drivers/net/wireless/rtl818x/rtl8180_dev.c.rej It looks like the patch failed to apply for you... FWIW, you need to use "-p1" as an argument to patch. Because the patch failed to apply for my version of the rtl8180_dev.c, I added the patch manually. Here is the extract of the modified rtl8180_dev.c :
mexsalem@GERICOM:~/Downloads/compat-wireless-2.6.35-1/drivers/net/wireless/rtl818x$ cat -n rtl8180_dev.c | head -n 109 | tail -n 7
103 {
104 struct rtl8180_priv *priv = dev->priv;
105 unsigned int count = 32;
106 u8 signal;
107 while (count--) {
108 struct rtl8180_rx_desc *entry = &priv->rx_ring[priv->rx_idx];
109 struct sk_buff *skb = priv->rx_buf[priv->rx_idx];
mexsalem@GERICOM:~/Downloads/compat-wireless-2.6.35-1/drivers/net/wireless/rtl818x$ cat -n rtl8180_dev.c | head -n 141 | tail -n 12
130 skb_put(skb, flags & 0xFFF);
131
132 rx_status.antenna = (flags2 >> 15) & 1;
133
134 rx_status.rate_idx = (flags >> 20) & 0xF;
135 /* TODO: improve signal/rssi reporting for !rtl8185 */
136 signal = (flags2 >> 17) & 0x7F;
137 if (rx_status.rate_idx > 3)
138 signal = 90 - clamp_t(u8, signal, 25, 90);
139 else
140 signal = 95 - clamp_t(u8, signal, 30, 95);
141 rx_status.signal = signal;
Then i compiled and installed it, now the signal varies from 16% to 33% max. - but this is still to weak compared to the expected signal. The Network-Manager-Applet shows 1-2 lines for the signal.
modinfo rtl8180 | grep version
srcversion: 3BDDA4655443D3A170CCAE9
vermagic: 2.6.32-24-generic SMP mod_unload modversions 586
Well, I'm sorry you are not happy. But as this is an improvement, it is based on the vendor-provided driver, and I have no better (or other) reference then this is about as good as you can expect it to get. commit 8b74964c73ca9eed7078388d871cc7fae973cb63 Author: John W. Linville <linville@tuxdriver.com> Date: Mon Jul 19 16:35:20 2010 -0400 rtl8180: improve signal reporting for rtl8185 hardware The existing code seemed to be somewhat based on the datasheet, but varied substantially from the vendor-provided driver. This mirrors the handling of the rtl8185 case from that driver, but still neglects the specifics for the rtl8180 hardware. Those details are a bit muddled... Signed-off-by: John W. Linville <linville@tuxdriver.com> Also, this: commit 8b73fb8e29e9ae0458d36cc0dc25e2717587dfd4 Author: John W. Linville <linville@tuxdriver.com> Date: Wed Jul 21 16:26:40 2010 -0400 rtl8180: improve signal reporting for actual rtl8180 hardware Adapted from Realtek-provided driver... Signed-off-by: John W. Linville <linville@tuxdriver.com> Tested-by: Pauli Nieminen <suokkos@gmail.com> |