[ath9k-devel] RE : [AR9280] unable to get noise level
Hi Mohammed, Hi all,
We tried with the latest compat-wireless tree (as explained in
http://wireless.kernel.org/en/users/Download/hacking#Git_trees_you_will_need)
and we got same results with the command:
$ cat /proc/net/wireless
Inter-| sta-| Quality| Discarded packets | Missed | WE
face | tus | link level noise | nwid crypt frag retry misc | beacon | 22
wlan1: 30. -80. -2560 0 0 14 180
wlan2: 0 0 00 0 0 0 00
mon.wlan2: 0 0 00 0 0 0 00
Noise is always equal to -256.
We knew that API changed when iw tool was released (and consequently
wireless-tool was deprecated) but we thougth that read /proc/net/wireless
would still provide reliable information. It seems that we were wrong!
*) with old iwconfig tool, we can notice that Noise level is also missing:
# iwconfig wlan1
wlan1 IEEE 802.11abgn ESSID:...
Mode:Managed Frequency:2.422 GHz Access Point: XX:XX:XX:XX:XX:XX
Bit Rate=39 Mb/s Tx-Power=20 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Encryption key:off
Power Management:on
Link Quality=32/70 Signal level=-78 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:15 Invalid misc:18 Missed beacon:0
*) but with iw tool, we get noise information:
# iw dev wlan1 survey dump | grep -A 1 '2422 MHz'
frequency: 2422 MHz
noise: -109 dBm
Regards,
Mickael
De : Mohammed Shafi [shafi.at...@gmail.com]
Date d'envoi : jeudi 14 octobre 2010 09:28
À : MASSON Mickaël NRS
Cc : ath9k-devel-requ...@lists.ath9k.org
Objet : Re: [ath9k-devel] [AR9280] unable to get noise level
Hi Mickael ,
You can try with the latest wireless-testing tree or compat wireless ...
recently the following commit by Felix seems to update the noise parameter.
regards,
shafi
commit 3430098ae463e31ab16926ac3eb295368a3ca5d9
Author: Felix Fietkau n...@openwrt.orgmailto:n...@openwrt.org
Date: Sun Oct 10 18:21:52 2010 +0200
ath9k: implement channel utilization stats for survey
static void ath_update_survey_nf(struct ath_softc *sc, int channel)
+{
+ struct ath_hw *ah = sc-sc_ah;
+ struct ath9k_channel *chan = ah-channels[channel];
+ struct survey_info *survey = sc-survey[channel];
+
+ if (chan-noisefloor) {
+ survey-filled |= SURVEY_INFO_NOISE_DBM;
+ survey-noise = chan-noisefloor;
+ }
+}
On Wed, Oct 13, 2010 at 7:15 PM,
mickael.mas...@orange-ftgroup.commailto:mickael.mas...@orange-ftgroup.com
wrote:
We are working on Ubiquity SR71-E mini-PCIe card (based on Atheros AR9280
chipset) and we are unable to get noise level.
We use ath9k driver from compat-wireless-2010-10-05 tarball.
As we can see, noise is always equal to -256:
$ watch -n 0 -d cat /proc/net/wireless
Inter-| sta-| Quality| Discarded packets | Missed | WE
face | tus | link level noise | nwid crypt frag retry misc | beacon | 22
wlan1: 47. -63. -2560 0 0 0 00
wlan2: 0 0 00 0 0 0 00
mon.wlan2: 0 0 00 0 0 0 00
So we would like to know if there is a way to get this value or if it is not
implemented.
In the latter case, how can we estimate signal quality?
Thanks for your help,
Mickael
*
This message and any attachments (the message) are confidential and intended
solely for the addressees.
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration.
France Telecom Group shall not be liable for the message if altered, changed or
falsified.
If you are not the intended addressee of this message, please cancel it
immediately and inform the sender.
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.orgmailto:ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
*
This message and any attachments (the message) are confidential and intended
solely for the addressees.
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration.
France Telecom Group shall not be liable for the message if altered, changed or
falsified.
If you are not the intended addressee of this message, please cancel it
immediately and inform the sender.
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] RE : [AR9280] unable to get noise level
Hi Mickael ,
Yes thanks , it was already there in the old compat wireless
itself, I never saw it.
regards,
shafi
On Fri, Oct 15, 2010 at 6:05 PM, mickael.mas...@orange-ftgroup.com wrote:
Hi Mohammed, Hi all,
We tried with the latest compat-wireless tree (as explained in
http://wireless.kernel.org/en/users/Download/hacking#Git_trees_you_will_need)
and we got same results with the command:
$ cat /proc/net/wireless
Inter-| sta-| Quality| Discarded packets | Missed
| WE
face | tus | link level noise | nwid crypt frag retry misc | beacon
| 22
wlan1: 30. -80. -2560 0 0 14 18
0
wlan2: 0 0 00 0 0 0 00
mon.wlan2: 0 0 00 0 0 0 0
0
Noise is always equal to -256.
We knew that API changed when iw tool was released (and consequently
wireless-tool was deprecated) but we thougth that read /proc/net/wireless
would still provide reliable information. It seems that we were wrong!
*) with old iwconfig tool, we can notice that Noise level is also
missing:
# iwconfig wlan1
wlan1 IEEE 802.11abgn ESSID:...
Mode:Managed Frequency:2.422 GHz Access Point: XX:XX:XX:XX:XX:XX
Bit Rate=39 Mb/s Tx-Power=20 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Encryption key:off
Power Management:on
Link Quality=32/70 Signal level=-78 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:15 Invalid misc:18 Missed beacon:0
*) but with iw tool, we get noise information:
# iw dev wlan1 survey dump | grep -A 1 '2422 MHz'
frequency: 2422 MHz
noise: -109 dBm
Regards,
Mickael
De : Mohammed Shafi [shafi.at...@gmail.com]
Date d'envoi : jeudi 14 octobre 2010 09:28
À : MASSON Mickaël NRS
Cc : ath9k-devel-requ...@lists.ath9k.org
Objet : Re: [ath9k-devel] [AR9280] unable to get noise level
Hi Mickael ,
You can try with the latest wireless-testing tree or compat wireless
...
recently the following commit by Felix seems to update the noise parameter.
regards,
shafi
commit 3430098ae463e31ab16926ac3eb295368a3ca5d9
Author: Felix Fietkau n...@openwrt.orgmailto:n...@openwrt.org
Date: Sun Oct 10 18:21:52 2010 +0200
ath9k: implement channel utilization stats for survey
static void ath_update_survey_nf(struct ath_softc *sc, int channel)
+{
+ struct ath_hw *ah = sc-sc_ah;
+ struct ath9k_channel *chan = ah-channels[channel];
+ struct survey_info *survey = sc-survey[channel];
+
+ if (chan-noisefloor) {
+ survey-filled |= SURVEY_INFO_NOISE_DBM;
+ survey-noise = chan-noisefloor;
+ }
+}
On Wed, Oct 13, 2010 at 7:15 PM, mickael.mas...@orange-ftgroup.com
mailto:mickael.mas...@orange-ftgroup.com wrote:
We are working on Ubiquity SR71-E mini-PCIe card (based on Atheros AR9280
chipset) and we are unable to get noise level.
We use ath9k driver from compat-wireless-2010-10-05 tarball.
As we can see, noise is always equal to -256:
$ watch -n 0 -d cat /proc/net/wireless
Inter-| sta-| Quality| Discarded packets | Missed
| WE
face | tus | link level noise | nwid crypt frag retry misc | beacon
| 22
wlan1: 47. -63. -2560 0 0 0 0
0
wlan2: 0 0 00 0 0 0 00
mon.wlan2: 0 0 00 0 0 0 0
0
So we would like to know if there is a way to get this value or if it is
not implemented.
In the latter case, how can we estimate signal quality?
Thanks for your help,
Mickael
*
This message and any attachments (the message) are confidential and
intended solely for the addressees.
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration.
France Telecom Group shall not be liable for the message if altered,
changed or falsified.
If you are not the intended addressee of this message, please cancel it
immediately and inform the sender.
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.orgmailto:ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
*
This message and any attachments (the message) are confidential and
intended solely for the addressees.
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration.
France Telecom Group shall not be liable for the message if altered,
changed or falsified.
If you are not the intended addressee of this message, please cancel it
immediately and inform the sender.
Re: [ath9k-devel] RE : [AR9280] unable to get noise level
On 10/15/2010 05:35 AM, mickael.mas...@orange-ftgroup.com wrote:
Hi Mohammed, Hi all,
We tried with the latest compat-wireless tree (as explained in
http://wireless.kernel.org/en/users/Download/hacking#Git_trees_you_will_need)
and we got same results with the command:
$ cat /proc/net/wireless
Inter-| sta-| Quality| Discarded packets | Missed | WE
face | tus | link level noise | nwid crypt frag retry misc | beacon |
22
wlan1: 30. -80. -2560 0 0 14 180
wlan2: 0 0 00 0 0 0 00
mon.wlan2: 0 0 00 0 0 0 00
Noise is always equal to -256.
We knew that API changed wheniw tool was released (and
consequentlywireless-tool was deprecated) but we thougth that read
/proc/net/wireless would still provide reliable information. It seems that we were wrong!
I'm attaching patches to make this work, but the maintainers are not interested
in these
patches upstream last I checked, so you'll have to apply them yourself.
The status/flags part of the patch is a real hack (exposes internal flags field
with
no translation), but it can show you if the interfaces are scanning or not, etc.
This patch also shows current rate as a new field in /proc/net/wireless.
Please let me know if you have any questions.
Thanks,
Ben
--
Ben Greear gree...@candelatech.com
Candela Technologies Inc http://www.candelatech.com
From e622b8b63b0323057b5d72b1fb068c3c4b699427 Mon Sep 17 00:00:00 2001
From: Ben Greear gree...@candelatech.com
Date: Fri, 8 Oct 2010 08:05:27 -0700
Subject: [PATCH 1/3] wext: Add noise, flags, and rate to /proc/net/wireless
This seems unlikely to ever go upstream. The noise probing
code may not work for all drivers, the flags are a copy of
internal data, and rate is a new field in /proc/net/wireless
which might confuse something.
Signed-off-by: Ben Greear gree...@candelatech.com
---
:100644 100644 4395b28... e538c2d... M include/linux/wireless.h
:100644 100644 6187c2e... 6e48883... M include/net/cfg80211.h
:100644 100644 18bd0e5... 1c01f8f... M net/mac80211/cfg.c
:100644 100644 1ee... b78ddfc... M net/wireless/wext-compat.c
:100644 100644 8bafa31... 9ccc338... M net/wireless/wext-proc.c
include/linux/wireless.h |5 +++--
include/net/cfg80211.h |7 ++-
net/mac80211/cfg.c |8
net/wireless/wext-compat.c |3 +++
net/wireless/wext-proc.c |8 +---
5 files changed, 25 insertions(+), 6 deletions(-)
diff --git a/include/linux/wireless.h b/include/linux/wireless.h
index 4395b28..e538c2d 100644
--- a/include/linux/wireless.h
+++ b/include/linux/wireless.h
@@ -898,8 +898,9 @@ struct iw_pmkid_cand
*/
struct iw_statistics
{
- __u16 status; /* Status
-* - device dependent for now */
+ __u16 status; /* Status: ieee80211_sta_info_flags
+* plus: (115): Scanning */
+ __u16 txrate; /* Current rate, in 100Kbps units. */
struct iw_quality qual; /* Quality of the link
* (instant/mean/max) */
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 6187c2e..6e48883 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -485,6 +485,8 @@ struct rate_info {
* @plid: mesh peer link id
* @plink_state: mesh peer link state
* @signal: signal strength of last received packet in dBm
+ * @status: ieee80211_sta_info_flags plus: (115) Scanning.
+ * @noise: noise, as obtained from dump_survey of index 0.
* @txrate: current unicast bitrate to this station
* @rx_packets: packets received from this station
* @tx_packets: packets transmitted to this station
@@ -505,7 +507,10 @@ struct station_info {
u16 plid;
u8 plink_state;
s8 signal;
- struct rate_info txrate;
+ u16 status;
+ u8 noise;
+ /* 3 byte hole */
+struct rate_info txrate;
u32 rx_packets;
u32 tx_packets;
u32 tx_retries;
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index 18bd0e5..1c01f8f 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -319,6 +319,7 @@ static int ieee80211_config_default_mgmt_key(struct wiphy
*wiphy,
static void sta_set_sinfo(struct sta_info *sta, struct station_info *sinfo)
{
struct ieee80211_sub_if_data *sdata = sta-sdata;
+ struct survey_info survey;
sinfo-generation = sdata-local-sta_generation;
@@ -375,6 +376,13 @@ static void sta_set_sinfo(struct sta_info *sta, struct
station_info *sinfo)
sinfo-plink_state = sta-plink_state;
#endif
}
+
+ sinfo-status = sta-flags;
+ if (sdata-local-scanning)
+ sinfo-status |= (115);
+
+ if (drv_get_survey(sdata-local, 0, survey) == 0)
+
[ath9k-devel] cannot turn off RTS/CTS???
RTS/CTS is turned on (as evidenced by Wireshark) and nothing that I do will turn it off. In hostapd.conf I have RTS/CTS turned off. Here is the setting in hostapd.conf: # RTS/CTS threshold; 2347 = disabled (default); range 0..2347 # If this field is not included in hostapd.conf, hostapd will not control # RTS threshold and 'iwconfig wlan# rts val' can be used to set it. rts_threshold=2347 I have also tried on both stations the following 2 commands: 'sudo iwconfig wlan1 rts off' and 'sudo iw phy phy0 set rts off' but those commands did nothing. I have tried different versions of the ath9k driver (upgraded to the latest) and on both of them RTS/CTS is dynamic and once turned on it cannot be turned off??? Is there somewhere in the source code that I need to change? Thank you for any responses they are greatly appreciated! Brandon M. Combs brmco...@iusb.edu mypage.iusb.edu/~brmcombs (574)202-0972 ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] RE : [AR9280] unable to get noise level
On Fri, Oct 15, 2010 at 09:26:00AM -0700, Ben Greear wrote: On 10/15/2010 05:35 AM, mickael.mas...@orange-ftgroup.com wrote: Hi Mohammed, Hi all, We tried with the latest compat-wireless tree (as explained in http://wireless.kernel.org/en/users/Download/hacking#Git_trees_you_will_need) and we got same results with the command: $ cat /proc/net/wireless Inter-| sta-| Quality| Discarded packets | Missed | WE face | tus | link level noise | nwid crypt frag retry misc | beacon | 22 wlan1: 30. -80. -2560 0 0 14 18 0 wlan2: 0 0 00 0 0 0 00 mon.wlan2: 0 0 00 0 0 0 0 0 Noise is always equal to -256. We knew that API changed wheniw tool was released (and consequentlywireless-tool was deprecated) but we thougth that read /proc/net/wireless would still provide reliable information. It seems that we were wrong! I'm attaching patches to make this work, but the maintainers are not interested in these patches upstream last I checked, so you'll have to apply them yourself. The status/flags part of the patch is a real hack (exposes internal flags field with no translation), but it can show you if the interfaces are scanning or not, etc. This patch also shows current rate as a new field in /proc/net/wireless. Please let me know if you have any questions. there is no interest in furthering wireless extensions, the focus should developing new stuff only for nl80211, users and distributions should be using nl80211 now that wext is completely replacable. Luis ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] [PATCH] ath9k: Clear DMA addresses when buffers are freed.
From: Ben Greear gree...@candelatech.com
Previous patches cleared the pointer to the SKB, but did not
clear the DMA addresses. This patch moves the clear logic into
a method and makes sure that the DMA addresses are cleared as well.
This does not obviously fix any bug, but may make it harder to
cause bugs in the future.
Signed-off-by: Ben Greear gree...@candelatech.com
---
:100644 100644 0c917e5... 8fba13d... M drivers/net/wireless/ath/ath9k/ath9k.h
:100644 100644 97d471f... cc406f9... M drivers/net/wireless/ath/ath9k/beacon.c
:100644 100644 62294da... 1560280... M drivers/net/wireless/ath/ath9k/main.c
:100644 100644 fd778d2... 5afb46f... M drivers/net/wireless/ath/ath9k/recv.c
:100644 100644 a5e5f27... e86f59c... M drivers/net/wireless/ath/ath9k/xmit.c
drivers/net/wireless/ath/ath9k/ath9k.h |2 ++
drivers/net/wireless/ath/ath9k/beacon.c | 14 +-
drivers/net/wireless/ath/ath9k/main.c | 11 +++
drivers/net/wireless/ath/ath9k/recv.c | 12
drivers/net/wireless/ath/ath9k/xmit.c |6 ++
5 files changed, 24 insertions(+), 21 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ath9k.h
b/drivers/net/wireless/ath/ath9k/ath9k.h
index 0c917e5..8fba13d 100644
--- a/drivers/net/wireless/ath/ath9k/ath9k.h
+++ b/drivers/net/wireless/ath/ath9k/ath9k.h
@@ -737,4 +737,6 @@ bool ath_mac80211_start_queue(struct ath_softc *sc, u16
skb_queue);
void ath_start_rfkill_poll(struct ath_softc *sc);
extern void ath9k_rfkill_poll_state(struct ieee80211_hw *hw);
+void ath_clear_dma_ptrs(struct ath_buf *bf);
+
#endif /* ATH9K_H */
diff --git a/drivers/net/wireless/ath/ath9k/beacon.c
b/drivers/net/wireless/ath/ath9k/beacon.c
index 97d471f..cc406f9 100644
--- a/drivers/net/wireless/ath/ath9k/beacon.c
+++ b/drivers/net/wireless/ath/ath9k/beacon.c
@@ -139,7 +139,7 @@ static struct ath_buf *ath_beacon_generate(struct
ieee80211_hw *hw,
dma_unmap_single(sc-dev, bf-bf_buf_addr,
skb-len, DMA_TO_DEVICE);
dev_kfree_skb_any(skb);
- bf-bf_buf_addr = 0;
+ ath_clear_dma_ptrs(bf);
}
/* Get a new beacon from mac80211 */
@@ -167,8 +167,7 @@ static struct ath_buf *ath_beacon_generate(struct
ieee80211_hw *hw,
skb-len, DMA_TO_DEVICE);
if (unlikely(dma_mapping_error(sc-dev, bf-bf_buf_addr))) {
dev_kfree_skb_any(skb);
- bf-bf_mpdu = NULL;
- bf-bf_buf_addr = 0;
+ ath_clear_dma_ptrs(bf);
ath_print(common, ATH_DBG_FATAL,
dma_mapping_error on beaconing\n);
return NULL;
@@ -256,8 +255,7 @@ int ath_beacon_alloc(struct ath_wiphy *aphy, struct
ieee80211_vif *vif)
dma_unmap_single(sc-dev, bf-bf_buf_addr,
skb-len, DMA_TO_DEVICE);
dev_kfree_skb_any(skb);
- bf-bf_mpdu = NULL;
- bf-bf_buf_addr = 0;
+ ath_clear_dma_ptrs(bf);
}
/* NB: the beacon data buffer must be 32-bit aligned. */
@@ -302,8 +300,7 @@ int ath_beacon_alloc(struct ath_wiphy *aphy, struct
ieee80211_vif *vif)
skb-len, DMA_TO_DEVICE);
if (unlikely(dma_mapping_error(sc-dev, bf-bf_buf_addr))) {
dev_kfree_skb_any(skb);
- bf-bf_mpdu = NULL;
- bf-bf_buf_addr = 0;
+ ath_clear_dma_ptrs(bf);
ath_print(common, ATH_DBG_FATAL,
dma_mapping_error on beacon alloc\n);
return -ENOMEM;
@@ -329,8 +326,7 @@ void ath_beacon_return(struct ath_softc *sc, struct ath_vif
*avp)
dma_unmap_single(sc-dev, bf-bf_buf_addr,
skb-len, DMA_TO_DEVICE);
dev_kfree_skb_any(skb);
- bf-bf_mpdu = NULL;
- bf-bf_buf_addr = 0;
+ ath_clear_dma_ptrs(bf);
}
list_add_tail(bf-list, sc-beacon.bbuf);
diff --git a/drivers/net/wireless/ath/ath9k/main.c
b/drivers/net/wireless/ath/ath9k/main.c
index 62294da..1560280 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -213,6 +213,17 @@ static void ath_update_survey_stats(struct ath_softc *sc)
ath_update_survey_nf(sc, pos);
}
+void ath_clear_dma_ptrs(struct ath_buf *bf)
+{
+ struct ath_desc *ds = bf-bf_desc;
+ bf-bf_buf_addr = 0;
+ bf-bf_mpdu = NULL;
+ if (ds) {
+ ds-ds_data = 0;
+ ds-ds_vdata = NULL;
+ }
+}
+
/*
* Set/change channels. If the channel is really being changed, it's done
* by reseting the chip. To accomplish this we must first cleanup any pending
diff --git a/drivers/net/wireless/ath/ath9k/recv.c
b/drivers/net/wireless/ath/ath9k/recv.c
index
[ath9k-devel] [PATCH] ath9k: Properly initialize ath_common-cc_lock.
From: Ben Greear gree...@candelatech.com Otherwise, lockdep splats, at the least. Signed-off-by: Ben Greear gree...@candelatech.com --- :100644 100644 a4c5ed4... fdc25f9... M drivers/net/wireless/ath/ath9k/init.c drivers/net/wireless/ath/ath9k/init.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/net/wireless/ath/ath9k/init.c b/drivers/net/wireless/ath/ath9k/init.c index a4c5ed4..fdc25f9 100644 --- a/drivers/net/wireless/ath/ath9k/init.c +++ b/drivers/net/wireless/ath/ath9k/init.c @@ -577,6 +577,7 @@ static int ath9k_init_softc(u16 devid, struct ath_softc *sc, u16 subsysid, common-hw = sc-hw; common-priv = sc; common-debug_mask = ath9k_debug; + spin_lock_init(common-cc_lock); spin_lock_init(sc-wiphy_lock); spin_lock_init(sc-sc_resetlock); -- 1.7.2.2 ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH] ath9k: Properly initialize ath_common-cc_lock.
On Fri, Oct 15, 2010 at 2:56 PM, gree...@candelatech.com wrote: From: Ben Greear gree...@candelatech.com Otherwise, lockdep splats, at the least. Thanks for the fix, please include the lockdep rant here on the commit log. Luis ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] [PATCH v2] ath9k: Properly initialize ath_common-cc_lock.
From: Ben Greear gree...@candelatech.com Otherwise, lockdep splats, at the least: INFO: trying to register non-static key. the code is fine but needs lockdep annotation. turning off the locking correctness validator. Pid: 2240, comm: ip Not tainted 2.6.36-rc8-wl+ #32 Call Trace: [c075d940] ? printk+0xf/0x17 [c045507a] register_lock_class+0x5a/0x29e [c0455be2] ? mark_lock+0x1e/0x1de [c0456af5] __lock_acquire+0xa2/0xb8c [c0455be2] ? mark_lock+0x1e/0x1de [c0457639] lock_acquire+0x5a/0x78 [f8c5115b] ? ath9k_config+0x274/0x3d8 [ath9k] [c075f602] _raw_spin_lock_irqsave+0x2f/0x3f [f8c5115b] ? ath9k_config+0x274/0x3d8 [ath9k] [f8c5115b] ath9k_config+0x274/0x3d8 [ath9k] [f8c0ba2e] ieee80211_hw_config+0x11b/0x125 [mac80211] [f8c17edf] ieee80211_do_open+0x3c5/0x466 [mac80211] [f8c171d6] ? ieee80211_check_concurrent_iface+0x21/0x13a [mac80211] [f8c17fdb] ieee80211_open+0x5b/0x5e [mac80211] [c06ce76b] __dev_open+0x80/0xae [c06cc99b] __dev_change_flags+0xa0/0x115 [c06ce6bf] dev_change_flags+0x13/0x3f [c06d7e78] do_setlink+0x23a/0x51b [c0455037] ? register_lock_class+0x17/0x29e [c06d847c] rtnl_newlink+0x269/0x431 [c06d8291] ? rtnl_newlink+0x7e/0x431 [c0455be2] ? mark_lock+0x1e/0x1de [c0455de9] ? mark_held_locks+0x47/0x5f [c075ebcf] ? __mutex_lock_common+0x2bb/0x2d6 [c0456045] ? trace_hardirqs_on_caller+0x104/0x125 [c075ebe0] ? __mutex_lock_common+0x2cc/0x2d6 [c06d8213] ? rtnl_newlink+0x0/0x431 [c06d79e2] rtnetlink_rcv_msg+0x182/0x198 [c06d7860] ? rtnetlink_rcv_msg+0x0/0x198 [c06e503c] netlink_rcv_skb+0x30/0x77 [c06d7859] rtnetlink_rcv+0x1b/0x22 [c06e4e77] netlink_unicast+0xbe/0x119 [c06e5a15] netlink_sendmsg+0x234/0x24c [c06bf93a] __sock_sendmsg+0x51/0x5a [c06bfba4] sock_sendmsg+0x93/0xa7 [c04968cf] ? might_fault+0x47/0x81 [c0496904] ? might_fault+0x7c/0x81 [c06c7904] ? copy_from_user+0x8/0xa [c06c7c2d] ? verify_iovec+0x3e/0x6d [c06bfd8c] sys_sendmsg+0x149/0x193 [c0455037] ? register_lock_class+0x17/0x29e [c0455be2] ? mark_lock+0x1e/0x1de [c0498d7a] ? __do_fault+0x1fc/0x3a5 [c048690a] ? unlock_page+0x40/0x43 [c0498ef7] ? __do_fault+0x379/0x3a5 [c04576dd] ? lock_release_non_nested+0x86/0x1d8 [c04968cf] ? might_fault+0x47/0x81 [c04968cf] ? might_fault+0x47/0x81 [c06c148b] sys_socketcall+0x15e/0x1a5 [c0402f1c] sysenter_do_call+0x12/0x38 Signed-off-by: Ben Greear gree...@candelatech.com --- v1 - v2: Updated commit message to show lockdep splat. :100644 100644 a4c5ed4... fdc25f9... M drivers/net/wireless/ath/ath9k/init.c drivers/net/wireless/ath/ath9k/init.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/net/wireless/ath/ath9k/init.c b/drivers/net/wireless/ath/ath9k/init.c index a4c5ed4..fdc25f9 100644 --- a/drivers/net/wireless/ath/ath9k/init.c +++ b/drivers/net/wireless/ath/ath9k/init.c @@ -577,6 +577,7 @@ static int ath9k_init_softc(u16 devid, struct ath_softc *sc, u16 subsysid, common-hw = sc-hw; common-priv = sc; common-debug_mask = ath9k_debug; + spin_lock_init(common-cc_lock); spin_lock_init(sc-wiphy_lock); spin_lock_init(sc-sc_resetlock); -- 1.7.2.2 ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH v2] ath9k: Properly initialize ath_common-cc_lock.
On 2010-10-16 12:04 AM, gree...@candelatech.com wrote: From: Ben Greear gree...@candelatech.com Otherwise, lockdep splats, at the least: [...] diff --git a/drivers/net/wireless/ath/ath9k/init.c b/drivers/net/wireless/ath/ath9k/init.c index a4c5ed4..fdc25f9 100644 --- a/drivers/net/wireless/ath/ath9k/init.c +++ b/drivers/net/wireless/ath/ath9k/init.c @@ -577,6 +577,7 @@ static int ath9k_init_softc(u16 devid, struct ath_softc *sc, u16 subsysid, common-hw = sc-hw; common-priv = sc; common-debug_mask = ath9k_debug; + spin_lock_init(common-cc_lock); spin_lock_init(sc-wiphy_lock); spin_lock_init(sc-sc_resetlock); Makes sense. Please update ath5k as well, it also uses the lock. - Felix ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] [PATCH] ath9k: Convert to new PCI PM framework
From: Rafael J. Wysocki r...@sisk.pl
The ath9k driver uses the legacy PCI power management (suspend
and resume) callbacks that apparently cause intermittent problems
to happen (the adapter sometimes doesn't resume correctly on my
Acer Ferrari One). Make it use the new PCI PM and let the PCI core
code handle the PCI-specific details of power transitions.
Signed-off-by: Rafael J. Wysocki r...@sisk.pl
---
drivers/net/wireless/ath/ath9k/pci.c | 40 +++
1 file changed, 22 insertions(+), 18 deletions(-)
Index: linux-2.6/drivers/net/wireless/ath/ath9k/pci.c
===
--- linux-2.6.orig/drivers/net/wireless/ath/ath9k/pci.c
+++ linux-2.6/drivers/net/wireless/ath/ath9k/pci.c
@@ -247,34 +247,25 @@ static void ath_pci_remove(struct pci_de
#ifdef CONFIG_PM
-static int ath_pci_suspend(struct pci_dev *pdev, pm_message_t state)
+static int ath_pci_suspend(struct device *device)
{
+ struct pci_dev *pdev = to_pci_dev(device);
struct ieee80211_hw *hw = pci_get_drvdata(pdev);
struct ath_wiphy *aphy = hw-priv;
struct ath_softc *sc = aphy-sc;
ath9k_hw_set_gpio(sc-sc_ah, sc-sc_ah-led_pin, 1);
- pci_save_state(pdev);
- pci_disable_device(pdev);
- pci_set_power_state(pdev, PCI_D3hot);
-
return 0;
}
-static int ath_pci_resume(struct pci_dev *pdev)
+static int ath_pci_resume(struct device *device)
{
+ struct pci_dev *pdev = to_pci_dev(device);
struct ieee80211_hw *hw = pci_get_drvdata(pdev);
struct ath_wiphy *aphy = hw-priv;
struct ath_softc *sc = aphy-sc;
u32 val;
- int err;
-
- pci_restore_state(pdev);
-
- err = pci_enable_device(pdev);
- if (err)
- return err;
/*
* Suspend/Resume resets the PCI configuration space, so we have to
@@ -293,7 +284,23 @@ static int ath_pci_resume(struct pci_dev
return 0;
}
-#endif /* CONFIG_PM */
+static const struct dev_pm_ops ath9k_pm_ops = {
+ .suspend = ath_pci_suspend,
+ .resume = ath_pci_resume,
+ .freeze = ath_pci_suspend,
+ .thaw = ath_pci_resume,
+ .poweroff = ath_pci_suspend,
+ .restore = ath_pci_resume,
+};
+
+#define ATH9K_PM_OPS (ath9k_pm_ops)
+
+#else /* !CONFIG_PM */
+
+#define ATH9K_PM_OPS NULL
+
+#endif /* !CONFIG_PM */
+
MODULE_DEVICE_TABLE(pci, ath_pci_id_table);
@@ -302,10 +309,7 @@ static struct pci_driver ath_pci_driver
.id_table = ath_pci_id_table,
.probe = ath_pci_probe,
.remove = ath_pci_remove,
-#ifdef CONFIG_PM
- .suspend= ath_pci_suspend,
- .resume = ath_pci_resume,
-#endif /* CONFIG_PM */
+ .driver.pm = ATH9K_PM_OPS,
};
int ath_pci_init(void)
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH] ath9k: Convert to new PCI PM framework
On Fri, Oct 15, 2010 at 3:36 PM, Rafael J. Wysocki r...@sisk.pl wrote: From: Rafael J. Wysocki r...@sisk.pl The ath9k driver uses the legacy PCI power management (suspend and resume) callbacks that apparently cause intermittent problems to happen (the adapter sometimes doesn't resume correctly on my Acer Ferrari One). Make it use the new PCI PM and let the PCI core code handle the PCI-specific details of power transitions. Signed-off-by: Rafael J. Wysocki r...@sisk.pl Do you know when these hooks were added? If it fixes an issue should this go for stable? Luis ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH] ath9k: Convert to new PCI PM framework
On Fri, Oct 15, 2010 at 3:36 PM, Rafael J. Wysocki r...@sisk.pl wrote: From: Rafael J. Wysocki r...@sisk.pl The ath9k driver uses the legacy PCI power management (suspend and resume) callbacks that apparently cause intermittent problems to happen (the adapter sometimes doesn't resume correctly on my Acer Ferrari One). Make it use the new PCI PM and let the PCI core code handle the PCI-specific details of power transitions. I'm curious. What sort of behavior did you get when the device fails to resume correctly? Every now and then I've been getting bad accesses to 0x7000 every now and then -- after that any reads to PCI registers return all f's. -- Paul ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
