Hi,
I've just recognised the following failure with an ar5211 card (GIGABYTE
GN-WLMA101) while calling "ifconfig wlan0 up" (both in 2.6.27 and
wireless-testing):
ath5k phy9: unsupported channel mode: 3
ath5k phy9: can't reset hardware (-22)
channel mode 3 is AR5K_MODE_11G and the error is printed in initvals.c:
1779 } else if (ah->ah_version == AR5K_AR5211) {
1780
1781 /* AR5K_MODE_11B */
1782 if (mode > 2) {
1783 ATH5K_ERR(ah->ah_sc,
1784 "unsupported channel mode: %d\n", mode);
1785 return -EINVAL;
Alright, ath5k tries to set channel mode to AR5K_MODE_11G but AR5211 only
allows AR5K_MODE_11B. After some further investigations I was able to find
out why the mode gets set to AR5K_MODE_11G: _All_ bg-channels have the mode
flag set to AR5K_MODE_11G.
Digging even deeper revealed that the mode flags are set depending on the
device capabilities queried from the eeprom in caps.c:
93 if (AR5K_EEPROM_HDR_11B(ee_header))
94 __set_bit(AR5K_MODE_11B,
95 ah->ah_capabilities.cap_mode);
96
97 if (AR5K_EEPROM_HDR_11G(ee_header))
98 __set_bit(AR5K_MODE_11G,
99 ah->ah_capabilities.cap_mode);
I was wondering why the card (which btw is labeled to only be an 802.11ab
card) should have the AR5K_MODE_11G flag set in its eeprom. Next step was to
have a closer look at the eeprom contents using ath_info:
| 802.11a Support: yes | Turbo-A disabled: no |
| 802.11b Support: yes | Turbo-G disabled: no |
| 802.11g Support: yes | 2GHz XR disabled: no |
Huh, the eeprom tells me that the card has 11g support. Therefore I tried
the following small patch:
diff --git a/drivers/net/wireless/ath5k/initvals.c
b/drivers/net/wireless/ath5k/initvals.c
index 450bd6e..8b011fb 100644
--- a/drivers/net/wireless/ath5k/initvals.c
+++ b/drivers/net/wireless/ath5k/initvals.c
@@ -1779,7 +1779,7 @@ int ath5k_hw_write_initvals(struct ath5k_hw *ah, u8 mode,
bool change_channel)
} else if (ah->ah_version == AR5K_AR5211) {
/* AR5K_MODE_11B */
- if (mode > 2) {
+ if (mode > 3) {
ATH5K_ERR(ah->ah_sc,
"unsupported channel mode: %d\n", mode);
return -EINVAL;
The result is: I can take the interface up and a scan also return some APs,
but only on a-channels not on bg-channels. I've used another card to sniff
the wireless traffic and the card indeed does not send any frames (probe
requests) on bg-channels. dmesg shows the following error for every
bg-channel:
ath5k phy10: noise floor calibration failed (2412MHz)
I'm not completely sure what this means in regard to the problem I've
described above but I would say the card does _not_ support 11g.
Ok, next try:
diff --git a/drivers/net/wireless/ath5k/caps.c
b/drivers/net/wireless/ath5k/caps.c
index 150f5ed..af2a14d 100644
--- a/drivers/net/wireless/ath5k/caps.c
+++ b/drivers/net/wireless/ath5k/caps.c
@@ -94,9 +94,11 @@ int ath5k_hw_set_capabilities(struct ath5k_hw *ah)
__set_bit(AR5K_MODE_11B,
ah->ah_capabilities.cap_mode);
- if (AR5K_EEPROM_HDR_11G(ee_header))
- __set_bit(AR5K_MODE_11G,
+ if (ah->ah_version != AR5K_AR5211) {
+ if (AR5K_EEPROM_HDR_11G(ee_header))
+ __set_bit(AR5K_MODE_11G,
ah->ah_capabilities.cap_mode);
+ }
}
}
Using this patch allows me to take the interface up and to scan all channels,
including bg. And I'm able to associate with an AP in 11b mode.
My question is:
Do ar5211 devices exist that are 11g capable? Is the device I have here
also capable of 11g or does the eeprom contain wrong information?
Is the above patch acceptable or should we check the pciids instad of
ah_version?
Helmut
_______________________________________________
ath5k-devel mailing list
ath5k-devel@lists.ath5k.org
https://lists.ath5k.org/mailman/listinfo/ath5k-devel
