Bug 13958 - ath5k Atheros AR5001 low signal
ath5k Atheros AR5001 low signal
Status: CLOSED INVALID
Product: Drivers
Classification: Unclassified
Component: network-wireless
All Linux
: P1 normal
Assigned To: drivers_network-wireless@kernel-bugs.osdl.org
:
Depends on:
Blocks: 13070
  Show dependency treegraph
 
Reported: 2009-08-10 15:03 UTC by Marco Siviero
Modified: 2010-06-22 18:41 UTC (History)
6 users (show)

See Also:
Kernel Version: 2.6.30-rc1+
Tree: Mainline
Regression: Yes


Attachments
lspci -vv from 2.6.31-rc6 kernel (10.07 KB, text/plain)
2009-08-14 11:52 UTC, Marco Siviero
Details
config for 2.6.29 kernel (54.54 KB, text/plain)
2009-10-26 08:44 UTC, Marco Siviero
Details
iwconfig from 2.6.29 kernel (484 bytes, text/plain)
2009-10-26 08:44 UTC, Marco Siviero
Details
lsmod from 2.6.29 kernel (260 bytes, text/plain)
2009-10-26 08:45 UTC, Marco Siviero
Details
lspci from 2.6.29 kernel (10.08 KB, text/plain)
2009-10-26 08:45 UTC, Marco Siviero
Details
iwconfig from 2.6.31-ARCH kernel (480 bytes, text/plain)
2009-10-26 08:47 UTC, Marco Siviero
Details
iperf test results for 2.6.31* kernel (1.28 KB, text/plain)
2009-10-30 09:23 UTC, Marco Siviero
Details
iperf test results for 2.6.29 kernel (1.38 KB, text/plain)
2009-10-30 09:23 UTC, Marco Siviero
Details

Description Marco Siviero 2009-08-10 15:03:38 UTC
Hello!
With 2.6.30-rc1 and above kernels my wireless card is no more recognized as AR242x and signal is lower: where it was near 100% now is only 60%.

For example:
2.6.29 kernel iwconfig:
wlan0     IEEE 802.11bg  ESSID:"Alice-04493438"  
          Mode:Managed  Frequency:2.412 GHz  Access Point: 00:1D:8B:43:29:15   
          Bit Rate=11 Mb/s   Tx-Power=5 dBm   
          Retry min limit:7   RTS thr:off   Fragment thr=2352 B   
          Power Management:on
          Link Quality=100/100  Signal level:-65 dBm  Noise level=-105 dBm
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

2.6.31-rc5 kernel iwconfig:
wlan0     IEEE 802.11bg  ESSID:"Alice-04493438"  
          Mode:Managed  Frequency:2.412 GHz  Access Point: 00:1D:8B:43:29:15   
          Bit Rate=11 Mb/s   Tx-Power=20 dBm   
          Retry  long limit:7   RTS thr:off   Fragment thr:off
          Power Management:off
          Link Quality=42/70  Signal level=-68 dBm  Noise level=-104 dBm
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

Also, where before there was a stable signal of about 40% now there is no signal at all.

Last fully working kernel was 2.6.29* series.

Bye

Marco
Comment 1 Marco Siviero 2009-08-14 11:52:05 UTC
Created attachment 22717 [details]
lspci -vv from 2.6.31-rc6 kernel
Comment 2 Rafael J. Wysocki 2009-08-20 14:37:23 UTC
On Thursday 20 August 2009, Marco Siviero wrote:
> Rafael J. Wysocki ha scritto:
> >
> > The following bug entry is on the current list of known regressions
> > introduced between 2.6.29 and 2.6.30.  Please verify if it still should
> > be listed and let me know (either way).
> Hello!
> In 2.6.30.5 the regression is still alive. I'm waiting for the 
> 2.6.31-rc6 to test if this regression is gone away.
Comment 3 Marco Siviero 2009-09-07 07:42:22 UTC
this bug is still a problem with 2.6.31-rc9 and previous release candidates kernels. the last working kernel is the 2.6.29.* series.

Bye

Marco
Comment 4 Rafał Miłecki 2009-09-14 16:18:10 UTC
As this is regression, very helpful would be finding commit that broke that.

Could you bisect this, please?

I also found similar report on ath5k-devel:
https://lists.ath5k.org/pipermail/ath5k-devel/2009-August/002590.html
however it doesn't have to be the same problem of course. Just some track I wanted to mention.
Comment 5 Bob Copeland 2009-10-25 19:57:39 UTC
Ok wait, are you using madwifi in 2.6.29 or ath5k?

And when you say "no signal at all" -- are you by chance using IBSS (ad-hoc) mode?  Because this shows a 50% signal level:
 
> Link Quality=42/70  Signal level=-68 dBm  Noise level=-104 dBm
Comment 6 Marco Siviero 2009-10-26 08:42:15 UTC
Hello Bob!


When i say "no signal at all" i mean "no signal at all".

Where with 2.6.29 kernel i have a strong signal, near 40%, with newer kernels i have no signal at all.

Where with newer kernels i have for example 60% signal, with 2.6.29 kernels i have 90-100% signal, like this:

Same place:

2.6.29 IWCONFIG
wlan0     IEEE 802.11bg  ESSID:"Alice-04493438"  
          Mode:Managed  Frequency:2.412 GHz  Access Point: 00:1D:8B:43:29:15   
          Bit Rate=11 Mb/s   Tx-Power=5 dBm   
          Retry min limit:7   RTS thr:off   Fragment thr=2352 B   
          Power Management:on
          Link Quality=100/100  Signal level:-66 dBm  Noise level=-104 dBm
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

2.6.31 IWCONFIG
wlan0     IEEE 802.11bg  ESSID:"Alice-04493438"  
          Mode:Managed  Frequency:2.412 GHz  Access Point: 00:1D:8B:43:29:15   
          Bit Rate=18 Mb/s   Tx-Power=20 dBm   
          Retry  long limit:7   RTS thr:off   Fragment thr:off
          Power Management:off
          Link Quality=44/70  Signal level=-66 dBm  Noise level=-105 dBm
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

As you can see my network mode is managed, as i connect to my router.

I attach some files thath could help debugging.


Thanks for the support

Marco
Comment 7 Marco Siviero 2009-10-26 08:43:05 UTC
Uh, i use in both 2.6.29 and in newer kernels ath5k driver! NO madwifi!
Comment 8 Marco Siviero 2009-10-26 08:44:11 UTC
Created attachment 23526 [details]
config for 2.6.29 kernel
Comment 9 Marco Siviero 2009-10-26 08:44:43 UTC
Created attachment 23527 [details]
iwconfig from 2.6.29 kernel
Comment 10 Marco Siviero 2009-10-26 08:45:18 UTC
Created attachment 23528 [details]
lsmod from 2.6.29 kernel
Comment 11 Marco Siviero 2009-10-26 08:45:57 UTC
Created attachment 23529 [details]
lspci from 2.6.29 kernel
Comment 12 Marco Siviero 2009-10-26 08:47:05 UTC
Created attachment 23530 [details]
iwconfig from 2.6.31-ARCH kernel
Comment 13 Bob Copeland 2009-10-26 09:30:18 UTC
Ok, can you run some tests with iperf to see what actual throughput is?  We may have changed the link quality calculation at some point to be more accurate.  

e.g. in 2.6.31 it shows you using 18 mbps instantaneous rate whereas in 2.6.29 you are using 11.  The actual signal values reported by the card are about the same despite the 'link quality' discrepancy.
Comment 14 Marco Siviero 2009-10-30 09:22:06 UTC
Hello Bob!
I attach the results of iperf tests; note that my iperf server machine is linked to a router that doesn't support speed above 10mbps for wired connections.
Comment 15 Marco Siviero 2009-10-30 09:23:10 UTC
Created attachment 23593 [details]
iperf test results for 2.6.31* kernel
Comment 16 Marco Siviero 2009-10-30 09:23:54 UTC
Created attachment 23594 [details]
iperf test results for 2.6.29 kernel
Comment 17 John W. Linville 2010-03-04 19:09:30 UTC
Bob, is Marco's information useful?  Nick, could we be incorrectly calculating the signal strength?
Comment 18 Bob Copeland 2010-03-04 19:19:32 UTC
Yes -- the posted information shows very little difference in actual throughput between 2.6.29 and 2.6.31.  What it does show is:

- in 29 it always reported 100/100 (despite only getting nominal 18 mbps)
- in 31 it shows 43/70, for -67 dBm signal.

.31 seems more correct to me.  Also some user space programs didn't deal well with the change to /70 fractions, maybe that is at play here?
Comment 19 Nick Kossifidis 2010-03-05 13:11:55 UTC
.31 seems O.K. to mee too, you can't have 100/100 with -66dBm. We calculate rssi corectly, i've verified it with a spectrum analyzer some time ago (and we haven't changed the way we read it from the card since). -105 noise floor seems weird though and -66 is usually good enough to have >= 36Mb rate, maybe Bruno's patches for I/Q calibration can fix that (or maybe it's just the card's sensitivity).
Comment 20 John W. Linville 2010-06-22 18:38:08 UTC
Rafael, comment 18 and comment 19 seem to indicate that this isn't actually a bug (and therefor not a regression).  Can we close this on that basis?
Comment 21 Rafael J. Wysocki 2010-06-22 18:41:02 UTC
Yes, we can.  Closing.

Note You need to log in before you can comment on or make changes to this bug.