Please post the output of dmesg from shortly after a reboot.

Created attachment 57392 [details]
relevant excerpt from dmesg

Looks right to me...your hardware is defining the available settings...

[    7.790913] ath: EEPROM regdomain: 0x65
[    7.790920] ath: EEPROM indicates we should expect a direct regpair map
[    7.790928] ath: Country alpha2 being used: 00
[    7.790932] ath: Regpair used: 0x65

From drivers/net/wireless/ath/regd.c:

        switch (reg->regpair->regDmnEnum) {
...
        case 0x63:
        case 0x65:
                return &ath_world_regdom_63_65;

static const struct ieee80211_regdomain ath_world_regdom_63_65 = {
        .n_reg_rules = 4,
        .alpha2 =  "99",
        .reg_rules = {
                ATH9K_2GHZ_CH01_11,
                ATH9K_2GHZ_CH12_13,
                ATH9K_5GHZ_NO_MIDBAND,
        }
};

You are talking about the frequency ranges, which are definitely correct, but this is not the topic!
I am talking about the transmission power limits, that are totally wrong. According to the regulatory domain for my country 20 dBm for each 2.4 GHz channel from 1 to 13 is allowed. But since 2.6.38 there are 17 dBm, 9 dBm, 13 dBm and 14 dBm limits assigned to the channels. This only happens with my Atheros and not with other wireless adapters.

Ah, OK...have you tried bisecting between 2.6.37 and 2.6.38?

commit de40f316c01b1ba9535e6dc99f6a67e7655b07da
Author: Felix Fietkau <nbd@openwrt.org>
Date:   Wed Oct 20 03:08:53 2010 +0200

    ath9k_hw: extend ath9k_hw_set_txpowerlimit to test channel txpower
    
    ath9k_hw_set_txpowerlimit gets an extra boolean parameter that - if set -
    causes the rate txpower table and the regulatory limit to be calculated
    and stored, without changing hardware registers.

That one looks very suspicious.

Oh, I missed that that were multiple patches. I think these commits are responsible for the problem:

babcbc295fee766ca710235e431686fef744d9a6
de40f316c01b1ba9535e6dc99f6a67e7655b07da
6b7b6cf553f881d45bb37a73f5db956afb290a08

They definitely seem related to the issue.  Unfortunately, reverting them is a bit ugly...

Could you verify that edb40a23c8dc5b5be219bf4561074b6233bba65f works and that babcbc295fee766ca710235e431686fef744d9a6 is broken?

edb40a23c8dc5b5be219bf4561074b6233bba65f can't be related, because it affects ath5k only.

Precisely -- it is the last commit before the three you identified. :-)

Why is the status still NEEDINFO? How is the progress on this?

The question was: Does the kernel edb40a23c8dc5b5be219bf4561074b6233bba65f work? 
In other words, did you test the corresponding kernel? (Comment #9 is not clear on that)

I used different versions of compat-wireless to find the faulty commits, because I always ran into compilation errors when I used Linus' tree. edb40a23c8dc5b5be219bf4561074b6233bba65f does not compile here either.

compat-wireless-2010-11-09 is good and compat-wireless-2010-11-13 is bad.

Same problem here
chipset: AR9285

iw list:
			* 2412 MHz [1] (17.0 dBm)
			* 2417 MHz [2] (17.0 dBm)
			* 2422 MHz [3] (9.0 dBm)
			* 2427 MHz [4] (13.0 dBm)
			* 2432 MHz [5] (13.0 dBm)
			* 2437 MHz [6] (13.0 dBm)
			* 2442 MHz [7] (13.0 dBm)
			* 2447 MHz [8] (13.0 dBm)
			* 2452 MHz [9] (9.0 dBm)
			* 2457 MHz [10] (14.0 dBm)
			* 2462 MHz [11] (14.0 dBm)
			* 2467 MHz [12] (17.0 dBm)
			* 2472 MHz [13] (17.0 dBm)
			* 2484 MHz [14] (disabled)

I using compat-wireless-2.6.39-1 + channel-negative-one-maxim.patch and 404-ath_regd_optional.patch

Still no progress on this annoying bug?

Created attachment 60832 [details]
ath9k_test.patch

This patch reverts small hunk of de40f316c01b1ba9535e6dc99f6a67e7655b07da that looks suspicious to me. Please test and report back, patch is for 2.6.38.

(In reply to comment #16)
> Created an attachment (id=60832) [details]
> ath9k_test.patch
> 
> This patch reverts small hunk of de40f316c01b1ba9535e6dc99f6a67e7655b07da
> that
> looks suspicious to me. Please test and report back, patch is for 2.6.38.

Unfortunately, no change. iw still lists the same wrong tw power values.

Created attachment 60852 [details]
ath9k_test2.patch

How about that one. This patch is effectively a revert of babcbc295fee766ca710235e431686fef744d9a6.

(In reply to comment #18)
> Created an attachment (id=60852) [details]
> ath9k_test2.patch
> 
> How about that one. This patch is effectively a revert of
> babcbc295fee766ca710235e431686fef744d9a6.

Yeah, that one brings back the correct values.

So, the bad commit is:

commit babcbc295fee766ca710235e431686fef744d9a6
Author: Felix Fietkau <nbd@openwrt.org>
Date:   Wed Oct 20 02:09:46 2010 +0200

    ath9k: initialize per-channel tx power limits instead of hardcoding them

Felix, do you know how to fix this bug?

First-Bad-Commit: babcbc295fee766ca710235e431686fef744d9a6

I think this commit only made the strange tx power limits visible, but did not cause them. Before this commit, hardware calibration data was not taken into account for the regulatory limit, instead it would not show what power limit the hardware was actually using.

Richard, do you experience actual problems with ath9k having less tx-power, or were you just startled from the different values in iwlist?

Because, having the actual values and not the theoretical limits in iwlist sounds like a good thing to me... (Depending on the actual intended behaviour of course. I don't know that.)

Regards,
Flo

Even if the commit only made the strange values visible they still look quite wrong to me. Is there a way to determine how powerful the hardware is really transmitting?

(In reply to comment #23)
> Richard, do you experience actual problems with ath9k having less tx-power,
> or
> were you just startled from the different values in iwlist?

Because I expected problems with the displayed lower values I never used "broken" kernels when I was on the move. So I can't say if there's really a difference at the moment.

PS: "iwlist" is not "iw list".

I'm no expert, but what I would do is to check how the throughput behaves with distance to the ap. If the tx/rx-power is less with one kernel, you should be able to see a throughput difference (if you are far away from the ap). At least I would imagine. You'd have to be careful that the conditions (other wireless traffic in the vincinity) are similar though.

Created attachment 65902 [details]
ath9k_print_ratesArray.patch

This patch prints ratesArray, i.e. per rate tx power setting we program device.

On my device there is no difference between programmed power setting with and without reverting "bad" commit. However ratesArray is calculated differently (and of course "iw list" output is different). I.e for 2.412 GHz I have:

Without comment 18 patch:
> ath9k_hw_def_set_txpower chan 2412 antRed 0 maxReg 40 limit 63 test 1
> 34, 34, 34, 34, 34, 34, 32, 30, 34, 34, 34, 34, 34, 34, 34, 34, 32, 32, 32,
> 32, 32, 28, 22, 20, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,  max_power_lever 34
[snip]
> ath9k_hw_def_set_txpower chan 2412 antRed 0 maxReg 34 limit 63 test 0
> 28, 28, 28, 28, 28, 28, 28, 28, 32, 32, 32, 32, 32, 32, 32, 28, 27, 27, 27,
> 27, 27, 27, 22, 20, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,  max_power_lever 32

With comment 18 patch:
> ath9k_hw_def_set_txpower chan 2412 antRed 0 maxReg 40 limit 63 test 0
> 28, 28, 28, 28, 28, 28, 28, 28, 32, 32, 32, 32, 32, 32, 32, 28, 27, 27, 27,
> 27, 27, 27, 22, 20, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,  max_power_lever 32

You can check if power settings are different on your device. If they are the same, the new kernels should work the same as older ones. If not we have a regression.

Of course, ideally if device could operate at full regulatory allowed tx power on each channel/rate, but this problem is not regression, and it's very hardware specific, probably only Atheros folks could fix it.

(In reply to comment #26)
> Created an attachment (id=65902) [details]
> ath9k_print_ratesArray.patch
> 
> This patch prints ratesArray, i.e. per rate tx power setting we program
> device.

I have applied your patch on 2.6.39.3 and I don't get any additional output.

Created attachment 65952 [details]
ath9k_print_ratesArray_v2.patch

I forgot add printk in ar9003_eeprom.c, now information should be printed.

(In reply to comment #28)
> Created an attachment (id=65952) [details]
> ath9k_print_ratesArray_v2.patch
> 
> I forgot add printk in ar9003_eeprom.c, now information should be printed.

Still nothing.

Patch looks fine. Are you looking at dmesg ? :-) If so, please double check if you correct apply the patch, use patched kernel, etc ...

Created attachment 66092 [details]
dmesg excerpt with debug information (without ath9k_test2.patch)

Created attachment 66102 [details]
dmesg excerpt with debug information (with ath9k_test2.patch)

Now the debug output was displayed. Probably I had to less coffee this morning as I tried the first time.

There's definitely a difference concerning the power levels when ath9k_test2.patch is applied.

Indeed, on some channels we transmit at half power. For example on 2.422 GHz channel: 

Wrong values:
> [    6.821219] ath9k_hw_4k_set_txpower chan 2422 antRed 0 maxReg 40 limit 63
> test 1
> [    6.821281] 19, 19, 19, 19, 19, 19, 19, 19, 19, 19, 19, 19, 19, 19, 19,
> 19, 19, 19, 19, 19, 19, 19, 19, 19, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 
> max_power_lever 19
[snip]
> [   17.337010] ath9k_hw_4k_set_txpower chan 2422 antRed 0 maxReg 18 limit 34
> test 0
> [   17.337077] 18, 18, 18, 18, 18, 18, 18, 18, 18, 18, 18, 18, 18, 18, 18,
> 18, 18, 18, 18, 18, 18, 18, 18, 18, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 
> max_power_lever 18

Correct values:
> [   17.053640] ath9k_hw_4k_set_txpower chan 2422 antRed 0 maxReg 40 limit 40
> test 0
> [   17.053707] 29, 29, 29, 29, 29, 29, 29, 29, 29, 29, 29, 29, 29, 29, 29,
> 29, 29, 29, 29, 29, 29, 29, 28, 26, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 
> max_power_lever 29

Looks like there is some flaw in ath9k_hw_4k_set_txpower(). For twiceMaxRegulatoryPower = 40 and powerLimit = 40 we get power value = 29, but for twiceMaxRegulatoryPower = 40 and powerLimit = 63 we get power value 19.

Flaw in ath9k_hw_4k_set_txpower should be probably fixed. But I wonder if calculating channel max power values we do currently, by th9k_hw_set_txpowerlimit test mode, is good solution. Perhaps better would be better to take these values from regulatory database via cfg80211/CRDA ? Felix & Atheros folks, would such change be ok for You?

cfg80211/crda is already used to restrict the tx power further. 
I think the test mode is useful, because otherwise the user has no way of knowing the transmit power limitation of the hardware, and without the test, such bugs that can limit the hardware tx power would simply go unnoticed.

Created attachment 66202 [details]
ath9k_remove_u8_cast.patch

This patch remove u8 (1 byte) cast, that possibly limit tx power values. Richard, does the patch make values similar like correct ones? If not, some more debugging patch(es) will be needed.

Created attachment 66232 [details]
dmesg excerpt with debug information (with ath9k_remove_u8_cast.patch)

Still the wrong values with ath9k_remove_u8_cast.patch applied.

Created attachment 66562 [details]
ath9k_print_ratesArray_v3.patch

This patch add printing variables from ath9k_hw_set_4k_power_per_rate_table.

Richard, please provide dmesg with this patch and as usual with and without ath9k_test2.patch for compare. Hopefully this would be enough to find problem, if not some more debug will be needed. Thanks.

Created attachment 66742 [details]
dmesg debug excerpt (ath9k_print_ratesArray_v3.patch)

Created attachment 66752 [details]
dmesg debug excerpt (ath9k_print_ratesArray_v3.patch + ath9k_test2.patch)

The difference is between twiceMaxEdgePower

Good:
[   17.176998] numCtlModes = 3
[   17.177002] twiceMaxEdgePower = 29

Bad:
[    6.773197] numCtlModes = 3
[    6.773201] twiceMaxEdgePower = 19

twiceMaxEdgePower calculation seems do not depend on powerLimit or twiceMaxRegulatoryPower. Seems to be depended on EEPROM data, which should be constant, and cfgCtl (input value, unfortunately it is not printed by debug patch).

I assume difference is caused by cfgCtl. It is provided by ath9k_regd_get_ctl(regulatory, chan), so cfgCtl seems to be depended on regulatory domain.

Created attachment 66812 [details]
ath9k_print_ratesArray_v4.patch

Add cfgCtl prints.

Created attachment 66822 [details]
ath9k_recalculate_txpower_limits_when_regd_change.patch

This patch recalculate max_power setting when regulatory domain is changed. It could be possible fix. Richard please check if it change max_power_lever to proper values.

Created attachment 66842 [details]
dmesg debug excerpt (ath9k_print_ratesArray_v4.patch)

Created attachment 66852 [details]
dmesg debug excerpt (ath9k_print_ratesArray_v4.patch + ath9k_test2.patch)

(In reply to comment #43)
> Created an attachment (id=66822) [details]
> ath9k_recalculate_txpower_limits_when_regd_change.patch
> 
> This patch recalculate max_power setting when regulatory domain is changed.
> It
> could be possible fix. Richard please check if it change max_power_lever to
> proper values.

No change.

Created attachment 66882 [details]
ath9k_print_ratesArray_v5.patch

So my assumptions was wrong, cfgCtl is exactly the same in bad and good case :-(

This patch prints more variables from ath9k_hw_set_4k_power_per_rate_table(), it should make us closer to solve the problem.

I tried Felix' patchset

[PATCH 1/4] ath9k: initialize tx chainmask before testing channel tx power values
[PATCH 2/4] ath9k_hw: remove the tx power index offset
[PATCH 3/4] ath9k_hw: fix calculated runtime tx power limit
[PATCH 4/4] ath9k_hw: do not limit initial tx power to 20 dbm

from linux-wireless, but that limits the tx power of every channel to 14 dBm (according to iw list).

Created attachment 66892 [details]
dmesg debug excerpt (ath9k_print_ratesArray_v5.patch)

Created attachment 66902 [details]
dmesg debug excerpt (ath9k_print_ratesArray_v5.patch + ath9k_test2.patch)

Can you try only first patch from Felix' set:
ath9k: initialize tx chainmask before testing channel tx power values ?

(In reply to comment #51)
> Can you try only first patch from Felix' set:
> ath9k: initialize tx chainmask before testing channel tx power values ?

Applying the first patch only is enough to get the same result (14 dBm limit for every channel).

Ahhh, I think this could be correct. Device should transmit with same tx power, you can check using ath9k_print_ratesArray_v2.patch and compare with results from comment #32 . iw list display is different because it not show hardcoded 20dB but true values with device is really working at.

Created attachment 66922 [details]
dmesg debug excerpt (ath9k: initialize tx chainmask before testing channel tx power values + ath9k_print_ratesArray_v2.patch)

Yeah, looks similar to #32. It's annoying that 'iw list' shows other values.

Patch: http://marc.info/?l=linux-wireless&m=131177168201216&w=2

(In reply to comment #54)
> Yeah, looks similar to #32. It's annoying that 'iw list' shows other values.
iw list show values which device transmit at (note max_power_lever showed in dmesg is 2*value, probably for make calculation easy). Currently we show true values, before babcbc295fee766ca710235e431686fef744d9a6 we showed hardcoded 20dB, no matter what was the real tx power device operate on. I'm considered regression caused by commit babcbc295fee766ca710235e431686fef744d9a6 (make device transmitting at low tx power on some channels) fixed by Felix' "initialize tx chainmask" patch. We currently transmit with the same tx power as before.

Perhaps these devices could operate at higher lever than 14dB. This is question for Atheros folks. But even if we have some other bug that limit tx power, it is not regression.

So I take it, the patch from comment #55 is the final word on it and close this as patch-available.  

If it hit's mainline, we can close this bug.