Bug 13537

Summary: ath9k: the signal power is about at 80% when under M$ Vista is at 100%
Product: Drivers Reporter: andrea ferraris (andrea.ferraris)
Component: network-wirelessAssignee: drivers_network-wireless (drivers_network-wireless)
Status: CLOSED CODE_FIX    
Severity: normal CC: andrea.ferraris, drago01, linville, mcgrof, senthilkumar, sujith, vkthiagu
Priority: P1    
Hardware: i386   
OS: Linux   
Kernel Version: 2.6.30 vanilla Subsystem:
Regression: No Bisected commit-id:
Attachments: kernel.log (dmesg)
# lspci -v
patch to solve ath9k signal issue
kern.log after modprobe ath9k debug=0xa404
pktlog patch for ath9k
Traffic log (some ping) from debugfs with CONFIG_ATH9K_DEBUGFS_PKTLOG enabled and the module loaded with debug=0xa404
ath9k: differentiate quality reporting between legacy and HT configurations

Description andrea ferraris 2009-06-14 15:31:50 UTC
First, let me know which logs and info you need and I'll attach them to the next message. I'm not a wlan expert at all. At first I'll attach kernel.log and lspci -v.

The machine is a Dell Studio XPS 1340 with a AR928X PCI Express controller.

I'm one meter far from the AP (Zyxel 600 P series) and between the notebook and the AP there are only air. 
With the pre-installed Windows Vista Home the connection to the network (WAP) is almost immediately established after giving the key and the signal power is at 100%.

With the Ubuntu 8.04 kernel, 2.6.27-7 and 2.6.27-14, the signal power was about between 60 amd 80%, then after the upgrade to Ubuntu 9.04 and kernel 2.6.28-11 the wireless network doesn't worked any more. Then I compiled a shiny vanilla 2.6.30 and the situation is that I have the signal power at 80% and the access to the network is quite slow (about 20 seconds). I recompiled enabling the debug for 
ath9k. In the system log I don't see anomalies or errors.
Comment 1 andrea ferraris 2009-06-14 15:33:30 UTC
Created attachment 21912 [details]
kernel.log (dmesg)
Comment 2 andrea ferraris 2009-06-14 15:37:12 UTC
Created attachment 21913 [details]
# lspci -v
Comment 3 andrea ferraris 2009-06-14 18:18:59 UTC
The signal power sometimes is lowering to 60% and twice in the last 2 hours I've got spontaneous disconnections and reconnections with the following messages in kernel.log: 

[ 7212.325924] wlan0: disassociating by local choice (reason=3)
[ 7214.012032] wlan0: deauthenticating by local choice (reason=3)
[ 7220.645862] ADDRCONF(NETDEV_UP): wlan0: link is not ready
[ 7227.814301] wlan0: authenticate with AP 00:13:49:f0:ec:8f
[ 7227.816345] wlan0: authenticated
[ 7227.816349] wlan0: associate with AP 00:13:49:f0:ec:8f
[ 7227.819019] wlan0: RX AssocResp from 00:13:49:f0:ec:8f (capab=0x471 status=0 aid=2)
[ 7227.819023] wlan0: associated
[ 7227.819681] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[ 7237.992022] wlan0: no IPv6 routers present
Comment 4 Senthil Balasubramanian 2009-06-16 09:54:01 UTC
Created attachment 21932 [details]
patch to solve ath9k signal issue
Comment 5 Senthil Balasubramanian 2009-06-16 09:56:14 UTC
Please apply the above patch and see if it solves your signal issue. This patch can be applied on top of 2.6.30 itself. if you are using the latest wireless-testing, then you can pull my patches from the mailing list.
Comment 6 andrea ferraris 2009-06-16 18:27:26 UTC
I applied the patch on top of 2.6.30.
I can't see differencies. After applying the kernel log is like this, and the signal power doesn't change (about 80% or less). 

ath9k 0000:06:00.0: PCI INT A -> Link[Z016] -> GSI 21 (level, low) -> IRQ 21
[  947.810872] ath9k 0000:06:00.0: setting latency timer to 64
[  948.246669] phy1: Selected rate control algorithm 'ath9k_rate_control'
[  948.247269] Registered led device: ath9k-phy1::radio
[  948.247283] Registered led device: ath9k-phy1::assoc
[  948.247302] Registered led device: ath9k-phy1::tx
[  948.247314] Registered led device: ath9k-phy1::rx
[  948.247320] phy1: Atheros AR9280 MAC/BB Rev:2 AR5133 RF Rev:d0: mem=0xf8160000, irq=21
[  952.814039] ADDRCONF(NETDEV_UP): wlan0: link is not ready
[  967.883471] wlan0: authenticate with AP 00:13:49:f0:ec:8f
[  967.885757] wlan0: authenticated
[  967.885761] wlan0: associate with AP 00:13:49:f0:ec:8f
[  967.888547] wlan0: RX AssocResp from 00:13:49:f0:ec:8f (capab=0x471 status=0 aid=1)
[  967.888551] wlan0: associated
[  967.888783] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[  978.604045] wlan0: no IPv6 routers present

If that could be useful the output of iwconfig on the device is

wlan0     IEEE 802.11abgn  ESSID:"ZyXEL"  
          Mode:Managed  Frequency:2.437 GHz  Access Point: 00:13:49:F0:EC:8F   
          Bit Rate=54 Mb/s   Tx-Power=20 dBm   
          Retry min limit:7   RTS thr:off   Fragment thr:off
          Encryption key:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX [2]   Security mode:open
          Power Management:off
          Link Quality=57/70  Signal level=-53 dBm  
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

Please, let me know if I can give more info.
Comment 7 Senthil Balasubramanian 2009-06-17 04:17:33 UTC
please run ath9k with 0xa404 debug mask and paste the dmesg log here. 

modprobe ath9k debug=0xa404
Comment 8 andrea ferraris 2009-06-17 06:33:31 UTC
Here you are the log in attachment.
Comment 9 andrea ferraris 2009-06-17 06:35:25 UTC
Created attachment 21956 [details]
kern.log after modprobe ath9k debug=0xa404
Comment 10 Senthil Balasubramanian 2009-06-17 07:09:11 UTC
Thanks for your log files. Can you please apply the patch and send us the pktlog dump. Please refer to the following steps to take the dump

Enable Kconfig CONFIG_ATH9K_DEBUGFS_PKTLOG
compile ath9k
mount -t debugfs debugfs /tmp_mnt/
echo 1 > /tmp_mnt/ieee80211/<phyX>/ath9k/pktlog/pktlog_enable
assoicate and send few ping packets.
cp /tmp_mnt/ieee80211/<phyX>/ath9k/pktlog/pktlog ath9k_pktlog.log

attach ath9k_pktlog.log
Comment 11 Senthil Balasubramanian 2009-06-17 07:10:41 UTC
Created attachment 21958 [details]
pktlog patch for ath9k

run git am 0001-ath9k-Add-pktlog-support-for-ATH9K.patch to apply this patch.
Comment 12 andrea ferraris 2009-06-17 08:50:27 UTC
(In reply to comment #10)
> Thanks for your log files. Can you please apply the patch and send us the
> pktlog dump. Please refer to the following steps to take the dump
> 
> Enable Kconfig CONFIG_ATH9K_DEBUGFS_PKTLOG
> compile ath9k
> mount -t debugfs debugfs /tmp_mnt/
> echo 1 > /tmp_mnt/ieee80211/<phyX>/ath9k/pktlog/pktlog_enable
> assoicate and send few ping packets.

Sorry, but I don't know how associate what to what, could you, please, explain a bit more?

> cp /tmp_mnt/ieee80211/<phyX>/ath9k/pktlog/pktlog ath9k_pktlog.log
> 
> attach ath9k_pktlog.log
Comment 13 Senthil Balasubramanian 2009-06-17 11:53:08 UTC
sorry! I meant to connect the Station to the AP. Connect to the AP is what i meant by saying "associate"

Please connect to the AP after enabling the pktlog (echo 1 > ...pktlog_enable)
and run few pings. and copy the pktlog from debugfs as mentioned before.
Comment 14 andrea ferraris 2009-06-17 14:19:21 UTC
(In reply to comment #13)
> sorry! I meant to connect the Station to the AP. Connect to the AP is what i
> meant by saying "associate"
> 
> Please connect to the AP after enabling the pktlog (echo 1 >
> ...pktlog_enable)
> and run few pings. and copy the pktlog from debugfs as mentioned before.

Thank you. I already did all except the ping, but there was traffic because I was browsing and the file stayed at 0 bytes; maybe I made something wrong. Now I don't have the machine with me; I'll try again late, this night. 
At the end we'll find that the gnome applet that display the wifi signal power and network status is buggy :-) 
There are some more cli and reliable command to see such wifi network things?
Comment 15 andrea ferraris 2009-06-17 21:58:26 UTC
Created attachment 21976 [details]
Traffic log (some ping) from debugfs with CONFIG_ATH9K_DEBUGFS_PKTLOG enabled and the module loaded with debug=0xa404

Sorry. It was already working this morning but I'm ignorant about debugfs, so I didn't know that also if a file show 0 bytes listing with ls, it can be full of wonderful worlds. How you do to see what's in? Strings doesn't show marvelous things.
Comment 16 Senthil Balasubramanian 2009-06-18 06:41:13 UTC
We use a proprietary debugging tools to parse the bytes in the ktlog. 

The RSSIs reported by the hardware seems to be fine with the pktlog. Can you please report the signal level in dBm with the same card and with the same AP on Windows XP 

You need to simply connect to the AP and use Atheros Wireless Configuration Uitilty to know the signal level in dBm. You can click on STATUS button once connected to know the signal strength in Vista.

I have tested with the same card and Windows vista and Ubuntu and noticed that the Signal Levels are same in both cases. thanks for your prompt followup.
Comment 17 andrea ferraris 2009-06-18 16:44:58 UTC
(In reply to comment #16)

> The RSSIs reported by the hardware seems to be fine with the pktlog. Can you
> please report the signal level in dBm with the same card and with the same AP
> on Windows XP 

Sorry, I can't because I don't have Windows XP, only Vista Home installed.

> You need to simply connect to the AP and use Atheros Wireless Configuration
> Uitilty to know the signal level in dBm. You can click on STATUS button once
> connected to know the signal strength in Vista.

Where can I find the AWCU or a similar Vista utility? I don't have it. In my Vista the signal is "Excellent" and has five bars on five where on Linux I have 4 bars on five.
Comment 18 Senthil Balasubramanian 2009-06-19 12:07:41 UTC
I think it is AWIC from what i heard from people though i haven't used Vista personally.The tool is delivered part of driver CD from your vendor. Otherwise, you can use netsh/wlan (show networks mode=bssid)commands in Vista to see the signal strength in %. But not sure if there is an option to see the Signal Level in dBm. Anyway, you can see whta % it shows instead of looking at the no.of bars...
Comment 19 andrea ferraris 2009-06-19 17:37:03 UTC
AWIC not found. netsh and wlan and show all doesn't show Signal Level in dBm, but  says loudly that the signal strength is 100%, QED. Now it's easy enough to understand why in Linux instead is about 80% or less; it is, it should be something wrong on the Linux side. Good luck!
Comment 20 andrea ferraris 2009-06-19 17:50:56 UTC
I'm yet actively looking for a tool for getting the dBm under Vista and thinking about trying under Linux with the same kernel but a different distribution (this one is Ubuntu 9.04.
Comment 21 John W. Linville 2009-06-19 17:52:23 UTC
100% of what?  No, I'm serious.  If the Windows report is a meaningless number
than what difference does it make?  How do you know that the Windows number is correct?  What defines "100%" signal strength, anyway?
Comment 22 Luis Chamberlain 2009-06-19 18:12:08 UTC
To supplement John's comment about this, I can tell you exactly what we mean by the percentage of quality as per Wireless Extensions in Linux.

        /* at 45 you will be able to use MCS 15 reliably. A more elaborate
         * scheme can be used here but it requires tables of SNR/throughput for
         * each possible mode used. */
        rx_status->qual =  ds->ds_rxstat.rs_rssi * 100 / 45;

So we know internally in our hardware that an rssi of of 45 means we should be able to use MCS rate 15
reliably. That's how we define and judge the the % you see.

For 802.11abg networks this can probably be reduced, so for example for ath5k we have:

                /* An rssi of 35 indicates you should be able use
                 * 54 Mbps reliably. A more elaborate scheme can be used
                 * here but it requires a map of SNR/throughput for each
                 * possible mode used */
                rxs.qual = rs.rs_rssi * 100 / 35;

So technically we can add a check here if conf_is_ht() for ath9k and when not using HT configurations you'll see a higher bar. So if connecting to an 802.11abg AP only you'll see a higher bar when using ath9k. Is your AP non-802.11n ?
Comment 23 andrea ferraris 2009-06-19 18:52:23 UTC
Now I have 150% under Vista and -50% under Linux of stinking socks :-) 
Sorry, now I've found a shareware software (Wireless Mon) to make a conceptually sensible measurement under Vista and the dBm is about -40. My AP is not n.
So as I was saying ;-) there was not a Linux driver problem, but only a different way to display signal strength in Vista and Linux. Am I right? Let me know.
Comment 24 Luis Chamberlain 2009-06-19 19:00:02 UTC
Created attachment 22013 [details]
ath9k: differentiate quality reporting between legacy and HT configurations

Did you read anything from the last few comments? I am under the impression you are ignoring what we tell you.

Anyway please try this patch and please report back.
Comment 25 andrea ferraris 2009-06-19 19:23:56 UTC
I'll try with immense pleasure (I'm going to reboot).
For the past you're kind, it is, I don't have problems to read what you wrote, but maybe I have problems to understand it because as I wrote at beginning I'm not at all a wireless network expert. But maybe you too could have some problem to understand what I was writing, it is, I was also joking.
Comment 26 andrea ferraris 2009-06-19 20:02:27 UTC
Patch applied and tried. The PC doesn't feeze, neither reboot spontaneously and the displayed signal strength is the same as before (about 80% or less) while a iwconfig report:

wlan0     IEEE 802.11abgn  ESSID:"ZyXEL"  
          Mode:Managed  Frequency:2.437 GHz  Access Point: 00:13:49:F0:EC:8F   
          Bit Rate=54 Mb/s   Tx-Power=20 dBm   
          Retry min limit:7   RTS thr:off   Fragment thr:off
          Encryption key:XXXX-XXXX-XXXX-XXXX-XXXX-XXXX-XXXX-XXXX-XXXX-XXXX-XXXX-XXXX-XXXX-XXXX-XXXX-XXXX [2]   Security mode:open
          Power Management:off
          Link Quality=55/70  Signal level=-55 dBm  
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

May I do yet something for you?
Comment 27 Luis Chamberlain 2009-06-20 01:11:16 UTC
Provided that Vista is showing you 150% I take it we are doing better in giving you something rather useful and valid.

You should see a difference with the patch you applied, can you provide the output of this command before the patch AND then after the patch:

while true ; do iwconfig wlan0 | grep "Link Quality" ; sleep 1; done

For example here is what I see with ath9k:

mcgrof@tesla ~ $ while true ; do iwconfig wlan0 | grep "Link Quality" ; sleep 1; done
          Link Quality=50/70  Signal level=-60 dBm  
          Link Quality=48/70  Signal level=-62 dBm  
          Link Quality=49/70  Signal level=-61 dBm  
          Link Quality=48/70  Signal level=-62 dBm  
          Link Quality=47/70  Signal level=-63 dBm  
          Link Quality=47/70  Signal level=-63 dBm  
          Link Quality=42/70  Signal level=-68 dBm  
          Link Quality=51/70  Signal level=-59 dBm  
          Link Quality=47/70  Signal level=-63 dBm  
          Link Quality=48/70  Signal level=-62 dBm  
          Link Quality=50/70  Signal level=-60 dBm  
          Link Quality=42/70  Signal level=-68 dBm  
          Link Quality=52/70  Signal level=-58 dBm  
          Link Quality=50/70  Signal level=-60 dBm


Also please please try upgrading to something newer, 2.6.30 is actually old for ath9k's and "Link quality" reporting is something that will not get fixed in 2.6.30.x series.

See:

http://wireless.kernel.org/en/users/Download
Comment 28 andrea ferraris 2009-06-20 08:25:40 UTC
Vista is showing 150% of stinking socks so it doesn't smell good at all.
Warning that it was not so true, it is, Vista continues to show 5 bars
and to say Excellent signal. I suspect that if it catches a whatever signal
it say Excellent and display a small nice bmp with 5 bars.

After patch:

          Link Quality=61/70  Signal level=-49 dBm
          Link Quality=61/70  Signal level=-49 dBm
          Link Quality=59/70  Signal level=-51 dBm
          Link Quality=57/70  Signal level=-53 dBm
          Link Quality=58/70  Signal level=-52 dBm
          Link Quality=58/70  Signal level=-52 dBm
          Link Quality=57/70  Signal level=-53 dBm
          Link Quality=57/70  Signal level=-53 dBm
          Link Quality=57/70  Signal level=-53 dBm
          Link Quality=56/70  Signal level=-54 dBm
          Link Quality=57/70  Signal level=-53 dBm
          Link Quality=57/70  Signal level=-53 dBm
          Link Quality=57/70  Signal level=-53 dBm
          Link Quality=57/70  Signal level=-53 dBm
          Link Quality=57/70  Signal level=-53 dBm
          Link Quality=57/70  Signal level=-53 dBm
          Link Quality=57/70  Signal level=-53 dBm
          Link Quality=57/70  Signal level=-53 dBm
          Link Quality=56/70  Signal level=-54 dBm
          Link Quality=55/70  Signal level=-55 dBm
          Link Quality=56/70  Signal level=-54 dBm
          Link Quality=58/70  Signal level=-52 dBm
          Link Quality=58/70  Signal level=-52 dBm
          Link Quality=58/70  Signal level=-52 dBm

Before patch:

          Link Quality=61/70  Signal level=-49 dBm
          Link Quality=62/70  Signal level=-48 dBm
          Link Quality=60/70  Signal level=-50 dBm
          Link Quality=60/70  Signal level=-50 dBm
          Link Quality=61/70  Signal level=-49 dBm
          Link Quality=62/70  Signal level=-48 dBm
          Link Quality=62/70  Signal level=-48 dBm
          Link Quality=61/70  Signal level=-49 dBm
          Link Quality=61/70  Signal level=-49 dBm
          Link Quality=61/70  Signal level=-49 dBm
          Link Quality=61/70  Signal level=-49 dBm
          Link Quality=61/70  Signal level=-49 dBm
          Link Quality=61/70  Signal level=-49 dBm
          Link Quality=62/70  Signal level=-48 dBm
          Link Quality=61/70  Signal level=-49 dBm
          Link Quality=61/70  Signal level=-49 dBm
          Link Quality=62/70  Signal level=-48 dBm
          Link Quality=61/70  Signal level=-49 dBm
          Link Quality=61/70  Signal level=-49 dBm
          Link Quality=62/70  Signal level=-48 dBm
          Link Quality=62/70  Signal level=-48 dBm
          Link Quality=61/70  Signal level=-49 dBm
          Link Quality=60/70  Signal level=-50 dBm
          Link Quality=59/70  Signal level=-51 dBm

So it seems that the patch does something.
Then, thank you very much for your help and sorry for my silly report,
because I think that the important thing is not the details showed,
but the work of the system and of the driver.

Now I'll do the last try, it is a pure ftp transfer of a big file on my
LAN with Linux 2.6.30 and Vista.

Under Linux:
22766189 bytes received in 10.96 secs (2028.5 kB/s)

Under Vista:
ftp: 22766189 bytes received in 11,45Seconds 1988,31Kbytes/sec.

So it seems at least that Linux is good as Vista in respect to this hardware.
I know I'd have to repeat the measurement some times and with bigger files
and mybe with different ftp server, but the life is short and I can stop here.

If you need more help, let me know.
Comment 29 Luis Chamberlain 2009-06-20 09:36:27 UTC
Looks like you are getting good results with Senthil's patch and my small patch. I believe this bug can be closed now.
Comment 30 Luis Chamberlain 2009-06-22 15:40:32 UTC
Can this bug be closed now?
Comment 31 andrea ferraris 2009-06-22 16:20:44 UTC
Sorry I didn't understood that was up to me.

For me yes, you can close the bug, also if yesterday evening I suffered some minutes (at least 5) of disconnection and I couldn't connected again also if I have unload and reload many times the module and the network was working because the the PC saw the signal and another device could connect and browse. 
But it's another story, different from this bug. If it will arrive again I'll open another and different bug.
Comment 32 John W. Linville 2009-07-01 16:00:13 UTC
*** Bug 12930 has been marked as a duplicate of this bug. ***