Re: [ath9k-devel] [AR9160] ath9k and Ubiquiti SR-71a - not getting anywhere near full TX power
So it turns out that the SR-71A card TX power rates are quoted based on the sum of all three chain TX'ing, rather than per-chain TX power. Given that legacy frames are transmitted through all chains anyway (there's no special handling in the TX path that limits the TX chainmask to 1 for non-11n frames), is there any reason why all the radio chains aren't enabled for legacy mode? Adrian ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [AR9160] ath9k and Ubiquiti SR-71a - not getting anywhere near full TX power
On Mon, Nov 29, 2010 at 1:49 PM, Adrian Chadd wrote:
> So it turns out that the SR-71A card TX power rates are quoted based
> on the sum of all three chain TX'ing, rather than per-chain TX power.
>
> Given that legacy frames are transmitted through all chains anyway
> (there's no special handling in the TX path that limits the TX
> chainmask to 1 for non-11n frames), is there any reason why all the
> radio chains aren't enabled for legacy mode?
Experienced people had said that one chain is sufficient for legacy
rates(except for PAPRD frames where all 3 chain is needed).The
chainmask of 1 is updated through the following thing in main.c and I
remember this goes into the tx descriptors,but for 11n mode the
default chainmask is used.
*
* Update tx/rx chainmask. For legacy association,
* hard code chainmask to 1x1, for 11n association, use
* the chainmask configuration, for bt coexistence, use
* the chainmask configuration even in legacy mode.
*/
void ath_update_chainmask(struct ath_softc *sc, int is_ht)
{
struct ath_hw *ah = sc->sc_ah;
struct ath_common *common = ath9k_hw_common(ah);
if ((sc->sc_flags & SC_OP_OFFCHANNEL) || is_ht ||
(ah->btcoex_hw.scheme != ATH_BTCOEX_CFG_NONE)) {
common->tx_chainmask = ah->caps.tx_chainmask;
common->rx_chainmask = ah->caps.rx_chainmask;
} else {
common->tx_chainmask = 1;
common->rx_chainmask = 1;
}
ath_print(common, ATH_DBG_CONFIG,
"tx chmask: %d, rx chmask: %d\n",
common->tx_chainmask,
common->rx_chainmask);
}
>
>
> Adrian
> ___
> ath9k-devel mailing list
> ath9k-devel@lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] [PATCH] fix endianity on ath9k_htc
It seems struct eep_header lacks proper #ifdef BIG_ENDIAN_BITFIELD
markup. eep_4k_header has proper markup, but two fields were swapped.
Signed-off-by: Pavel Machek
diff --git a/drivers/net/wireless/ath/ath9k/eeprom.h
b/drivers/net/wireless/ath/ath9k/eeprom.h
index 3c99830..022589d 100644
--- a/drivers/net/wireless/ath/ath9k/eeprom.h
+++ b/drivers/net/wireless/ath/ath9k/eeprom.h
@@ -378,10 +374,14 @@ struct modal_eep_header {
u8 xatten2Margin[AR5416_MAX_CHAINS];
u8 ob_ch1;
u8 db_ch1;
- u8 useAnt1:1,
- force_xpaon:1,
- local_bias:1,
+#ifndef __BIG_ENDIAN_BITFIELD
+ u8 useAnt1:1, force_xpaon:1, local_bias:1,
femBandSelectUsed:1, xlnabufin:1, xlnaisel:2, xlnabufmode:1;
+#else
+ u8 xlnabufmode:1, xlnaisel:2, xlnabufin:1,
+ femBandSelectUsed:1, local_bias:1, force_xpaon:1, useAnt1:1;
+#endif
+
u8 miscBits;
u16 xpaBiasLvlFreq[3];
u8 futureModal[6];
@@ -443,7 +444,7 @@ struct modal_eep_4k_header {
u8 antdiv_ctl1:4, ob_4:4;
u8 db1_3:4, db1_2:4;
u8 antdiv_ctl2:4, db1_4:4;
- u8 db2_2:4, db2_3:4;
+ u8 db2_3:4, db2_2:4;
u8 reserved:4, db2_4:4;
#else
u8 ob_2:4, ob_3:4;
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] [PATCH] ath9k_htc cleanups
This fixes whitespace and reduces ammount of ifdefed lines.
Signed-off-by: Pavel Machek
diff --git a/drivers/net/wireless/ath/ath9k/eeprom.h
b/drivers/net/wireless/ath/ath9k/eeprom.h
index 3c99830..022589d 100644
--- a/drivers/net/wireless/ath/ath9k/eeprom.h
+++ b/drivers/net/wireless/ath/ath9k/eeprom.h
@@ -23,11 +23,7 @@
#define AH_USE_EEPROM 0x1
-#ifdef __BIG_ENDIAN
-#define AR5416_EEPROM_MAGIC 0x5aa5
-#else
-#define AR5416_EEPROM_MAGIC 0xa55a
-#endif
+#define AR5416_EEPROM_MAGIC cpu_to_be16(0x5aa5)
#define CTRY_DEBUG 0x1ff
#defineCTRY_DEFAULT 0
@@ -536,17 +537,14 @@ struct cal_target_power_ht {
} __packed;
-#ifdef __BIG_ENDIAN_BITFIELD
struct cal_ctl_edges {
u8 bChannel;
+#ifdef __BIG_ENDIAN_BITFIELD
u8 flag:2, tPower:6;
-} __packed;
#else
-struct cal_ctl_edges {
- u8 bChannel;
u8 tPower:6, flag:2;
-} __packed;
#endif
+} __packed;
struct cal_data_op_loop_ar9287 {
u8 pwrPdg[2][5];
diff --git a/drivers/net/wireless/ath/ath9k/htc_hst.c
b/drivers/net/wireless/ath/ath9k/htc_hst.c
index c41ab8c..4d34446 100644
--- a/drivers/net/wireless/ath/ath9k/htc_hst.c
+++ b/drivers/net/wireless/ath/ath9k/htc_hst.c
@@ -16,7 +16,7 @@
#include "htc.h"
-static int htc_issue_send(struct htc_target *target, struct sk_buff* skb,
+static int htc_issue_send(struct htc_target *target, struct sk_buff *skb,
u16 len, u8 flags, u8 epid,
struct ath9k_htc_tx_ctl *tx_ctl)
{
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k_htc vs. powerpc (was Re: working usb wifi card, that is still possible to buy)
Hi! > > > Sujith, I see you fought with endianness issues on ath9k_htc > > > driver. Was you able to test it on actual hardware? Should I try the > > > version just after your commit? > > > > No, I never had a chance to test the driver on a big-endian system. > > I assume you are referring to this commit: "ath9k_htc: Fix sparse endian > > warnings" ? > > Yes. > > > Does using latest wireless-testing help ? > > I updated to wireless-testing from today, and still same results. > > > Or you can try compat-wireless to get the latest code. > > wireless-testing is actually easier to be. ...so I indentified two endianness problems in eeprom, but even with both fixed, it still will not associate. Is there some way to dump USB packets, then compare them between PC and PowerPC versions? Should I expect them to match? Pavel ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [AR9160] ath9k and Ubiquiti SR-71a - not getting anywhere near full TX power
Oh, I know about where the chainmask is set to 1x1 for legacy mode. It
just means the effective TX power is in no way related to what the
specification sheet is. That's why I've enabled it for non-n mode in
my local FreeBSD HAL to evaluate its effects.
I'll do some RF testing over the next few days to see if it indeed
does (mostly) add up together and improve effective TX range, but I'm
dubious (and I'm not an RF or communications engineer by trade, so
this is going to be a bit of a steep learning curve.)
Thanks,
Adrian
On 29 November 2010 16:39, Mohammed Shafi wrote:
> On Mon, Nov 29, 2010 at 1:49 PM, Adrian Chadd wrote:
>> So it turns out that the SR-71A card TX power rates are quoted based
>> on the sum of all three chain TX'ing, rather than per-chain TX power.
>>
>> Given that legacy frames are transmitted through all chains anyway
>> (there's no special handling in the TX path that limits the TX
>> chainmask to 1 for non-11n frames), is there any reason why all the
>> radio chains aren't enabled for legacy mode?
>
> Experienced people had said that one chain is sufficient for legacy
> rates(except for PAPRD frames where all 3 chain is needed).The
> chainmask of 1 is updated through the following thing in main.c and I
> remember this goes into the tx descriptors,but for 11n mode the
> default chainmask is used.
> *
> * Update tx/rx chainmask. For legacy association,
> * hard code chainmask to 1x1, for 11n association, use
> * the chainmask configuration, for bt coexistence, use
> * the chainmask configuration even in legacy mode.
> */
> void ath_update_chainmask(struct ath_softc *sc, int is_ht)
> {
> struct ath_hw *ah = sc->sc_ah;
> struct ath_common *common = ath9k_hw_common(ah);
>
> if ((sc->sc_flags & SC_OP_OFFCHANNEL) || is_ht ||
> (ah->btcoex_hw.scheme != ATH_BTCOEX_CFG_NONE)) {
> common->tx_chainmask = ah->caps.tx_chainmask;
> common->rx_chainmask = ah->caps.rx_chainmask;
> } else {
> common->tx_chainmask = 1;
> common->rx_chainmask = 1;
> }
>
> ath_print(common, ATH_DBG_CONFIG,
> "tx chmask: %d, rx chmask: %d\n",
> common->tx_chainmask,
> common->rx_chainmask);
> }
>
>
>
>>
>>
>> Adrian
>> ___
>> ath9k-devel mailing list
>> ath9k-devel@lists.ath9k.org
>> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>>
>
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] [PATCH] ath9k_htc more cleanups
This fixes whitespace and fixes strings.
Signed-off-by: Pavel Machek
diff --git a/drivers/net/wireless/ath/ath9k/htc_hst.c
b/drivers/net/wireless/ath/ath9k/htc_hst.c
index c41ab8c..ac4aed7 100644
--- a/drivers/net/wireless/ath/ath9k/htc_hst.c
+++ b/drivers/net/wireless/ath/ath9k/htc_hst.c
@@ -16,7 +16,7 @@
#include "htc.h"
-static int htc_issue_send(struct htc_target *target, struct sk_buff* skb,
+static int htc_issue_send(struct htc_target *target, struct sk_buff *skb,
u16 len, u8 flags, u8 epid,
struct ath9k_htc_tx_ctl *tx_ctl)
{
@@ -239,7 +239,7 @@ int htc_connect_service(struct htc_target *target,
/* Find an available endpoint */
endpoint = get_next_avail_ep(target->endpoint);
if (!endpoint) {
- dev_err(target->dev, "Endpoint is not available for"
+ dev_err(target->dev, "Endpoint is not available for "
"service %d\n", service_connreq->service_id);
return -EINVAL;
}
@@ -253,7 +253,7 @@ int htc_connect_service(struct htc_target *target,
skb = alloc_skb(sizeof(struct htc_conn_svc_msg) +
sizeof(struct htc_frame_hdr), GFP_ATOMIC);
if (!skb) {
- dev_err(target->dev, "Failed to allocate buf to send"
+ dev_err(target->dev, "Failed to allocate buf to send "
"service connect req\n");
return -ENOMEM;
}
@@ -274,6 +274,7 @@ int htc_connect_service(struct htc_target *target,
time_left = wait_for_completion_timeout(&target->cmd_wait, HZ);
if (!time_left) {
+ /* who frees skb */
dev_err(target->dev, "Service connection timeout for: %d\n",
service_connreq->service_id);
return -ETIMEDOUT;
@@ -434,7 +435,7 @@ struct htc_target *ath9k_htc_hw_alloc(void *hif_handle,
target = kzalloc(sizeof(struct htc_target), GFP_KERNEL);
if (!target) {
- printk(KERN_ERR "Unable to allocate memory for"
+ printk(KERN_ERR "Unable to allocate memory for "
"target device\n");
return NULL;
}
diff --git a/drivers/net/wireless/ath/ath9k/htc_hst.h
b/drivers/net/wireless/ath/ath9k/htc_hst.h
index 6fc1b21..02f4074 100644
--- a/drivers/net/wireless/ath/ath9k/htc_hst.h
+++ b/drivers/net/wireless/ath/ath9k/htc_hst.h
@@ -165,7 +165,7 @@ struct htc_service_connreq {
/* Current service IDs */
-enum htc_service_group_ids{
+enum htc_service_group_ids {
RSVD_SERVICE_GROUP = 0,
WMI_SERVICE_GROUP = 1,
diff --git a/drivers/net/wireless/ath/ath9k/xmit.c
b/drivers/net/wireless/ath/ath9k/xmit.c
index 495432e..b309b68 100644
--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -287,7 +287,7 @@ static void ath_tx_return_buffer(struct ath_softc *sc,
struct ath_buf *bf)
spin_unlock_bh(&sc->tx.txbuflock);
}
-static struct ath_buf* ath_clone_txbuf(struct ath_softc *sc, struct ath_buf
*bf)
+static struct ath_buf *ath_clone_txbuf(struct ath_softc *sc, struct ath_buf
*bf)
{
struct ath_buf *tbf;
@@ -666,7 +666,7 @@ static int ath_compute_num_delims(struct ath_softc *sc,
struct ath_atx_tid *tid,
ndelim += ATH_AGGR_ENCRYPTDELIM;
/*
-* Convert desired mpdu density from microeconds to bytes based
+* Convert desired mpdu density from microseconds to bytes based
* on highest rate in rate series (i.e. first rate) to determine
* required minimum length for subframe. Take into account
* whether high rate is 20 or 40Mhz and half or full GI.
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH] fix endianity on ath9k_htc
On 2010-11-29 10:58 AM, Pavel Machek wrote:
>
> It seems struct eep_header lacks proper #ifdef BIG_ENDIAN_BITFIELD
> markup. eep_4k_header has proper markup, but two fields were swapped.
>
> Signed-off-by: Pavel Machek
>
> diff --git a/drivers/net/wireless/ath/ath9k/eeprom.h
> b/drivers/net/wireless/ath/ath9k/eeprom.h
> index 3c99830..022589d 100644
> --- a/drivers/net/wireless/ath/ath9k/eeprom.h
> +++ b/drivers/net/wireless/ath/ath9k/eeprom.h
> @@ -378,10 +374,14 @@ struct modal_eep_header {
> u8 xatten2Margin[AR5416_MAX_CHAINS];
> u8 ob_ch1;
> u8 db_ch1;
> - u8 useAnt1:1,
> - force_xpaon:1,
> - local_bias:1,
> +#ifndef __BIG_ENDIAN_BITFIELD
> + u8 useAnt1:1, force_xpaon:1, local_bias:1,
> femBandSelectUsed:1, xlnabufin:1, xlnaisel:2, xlnabufmode:1;
> +#else
> + u8 xlnabufmode:1, xlnaisel:2, xlnabufin:1,
> + femBandSelectUsed:1, local_bias:1, force_xpaon:1, useAnt1:1;
> +#endif
> +
> u8 miscBits;
> u16 xpaBiasLvlFreq[3];
> u8 futureModal[6];
I already sent a different fix for this part. See
'[PATCH] ath9k_hw: fix more bitfield related endian issues'
> @@ -443,7 +444,7 @@ struct modal_eep_4k_header {
> u8 antdiv_ctl1:4, ob_4:4;
> u8 db1_3:4, db1_2:4;
> u8 antdiv_ctl2:4, db1_4:4;
> - u8 db2_2:4, db2_3:4;
> + u8 db2_3:4, db2_2:4;
> u8 reserved:4, db2_4:4;
> #else
> u8 ob_2:4, ob_3:4;
Looks good.
- Felix
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH] fix endianity on ath9k_htc
Hi!
> > It seems struct eep_header lacks proper #ifdef BIG_ENDIAN_BITFIELD
> > markup. eep_4k_header has proper markup, but two fields were swapped.
> >
> > Signed-off-by: Pavel Machek
> >
> > diff --git a/drivers/net/wireless/ath/ath9k/eeprom.h
> > b/drivers/net/wireless/ath/ath9k/eeprom.h
> > index 3c99830..022589d 100644
> > --- a/drivers/net/wireless/ath/ath9k/eeprom.h
> > +++ b/drivers/net/wireless/ath/ath9k/eeprom.h
> > @@ -378,10 +374,14 @@ struct modal_eep_header {
> > u8 xatten2Margin[AR5416_MAX_CHAINS];
> > u8 ob_ch1;
> > u8 db_ch1;
> > - u8 useAnt1:1,
> > - force_xpaon:1,
> > - local_bias:1,
> > +#ifndef __BIG_ENDIAN_BITFIELD
> > + u8 useAnt1:1, force_xpaon:1, local_bias:1,
> > femBandSelectUsed:1, xlnabufin:1, xlnaisel:2, xlnabufmode:1;
> > +#else
> > + u8 xlnabufmode:1, xlnaisel:2, xlnabufin:1,
> > + femBandSelectUsed:1, local_bias:1, force_xpaon:1, useAnt1:1;
> > +#endif
> > +
> > u8 miscBits;
> > u16 xpaBiasLvlFreq[3];
> > u8 futureModal[6];
> I already sent a different fix for this part. See
> '[PATCH] ath9k_hw: fix more bitfield related endian issues'
Thanks, your patch is obviously better.
> > @@ -443,7 +444,7 @@ struct modal_eep_4k_header {
> > u8 antdiv_ctl1:4, ob_4:4;
> > u8 db1_3:4, db1_2:4;
> > u8 antdiv_ctl2:4, db1_4:4;
> > - u8 db2_2:4, db2_3:4;
> > + u8 db2_3:4, db2_2:4;
> > u8 reserved:4, db2_4:4;
> > #else
> > u8 ob_2:4, ob_3:4;
> Looks good.
Yep, but it does not help :-(. Were you able to get the driver to work
on big-endian machine?
Pavel
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] [patch] remove unneeded prototype on ath9k_htc
The prototype does not seem to have corresponding function. Signed-off-by: Pavel Machek diff --git a/drivers/net/wireless/ath/ath9k/hw.h b/drivers/net/wireless/ath/ath9k/hw.h index cc8f3b9..ed5d199 100644 --- a/drivers/net/wireless/ath/ath9k/hw.h +++ b/drivers/net/wireless/ath/ath9k/hw.h @@ -906,7 +906,6 @@ bool ath9k_hw_disable(struct ath_hw *ah); void ath9k_hw_set_txpowerlimit(struct ath_hw *ah, u32 limit, bool test); void ath9k_hw_setopmode(struct ath_hw *ah); void ath9k_hw_setmcastfilter(struct ath_hw *ah, u32 filter0, u32 filter1); -void ath9k_hw_setbssidmask(struct ath_hw *ah); void ath9k_hw_write_associd(struct ath_hw *ah); u64 ath9k_hw_gettsf64(struct ath_hw *ah); void ath9k_hw_settsf64(struct ath_hw *ah, u64 tsf64); ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] How do I check if channel diversity is working?
Hi, I have a DNMA92 mini-pci wireless card (http://pcengines.ch/dnma92.htm) and I'm using it with two antennas on the 2.4Ghz band (802.11b/g). This is the output of lspci -vv 00:0e.0 Network controller: Atheros Communications Inc. AR922X Wireless Network Adapter (rev 01) Subsystem: Atheros Communications Inc. Device 2096 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- http://utenti.lycos.it/giannicostanzi/ | | My Fotoblog: | http://giannicostanzi.fotoblog.it -- ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k_htc vs. powerpc (was Re: working usb wifi card, that is still possible to buy)
Pavel Machek wrote:
> ...so I indentified two endianness problems in eeprom, but even with
> both fixed, it still will not associate. Is there some way to dump USB
> packets, then compare them between PC and PowerPC versions? Should I
> expect them to match?
Does this patch help ?
diff --git a/drivers/net/wireless/ath/ath9k/htc.h
b/drivers/net/wireless/ath/ath9k/htc.h
index afe39a9..b04a25a 100644
--- a/drivers/net/wireless/ath/ath9k/htc.h
+++ b/drivers/net/wireless/ath/ath9k/htc.h
@@ -78,7 +78,7 @@ struct tx_frame_hdr {
u8 node_idx;
u8 vif_idx;
u8 tidno;
- u32 flags; /* ATH9K_HTC_TX_* */
+ __be32 flags; /* ATH9K_HTC_TX_* */
u8 key_type;
u8 keyix;
u8 reserved[26];
@@ -91,30 +91,19 @@ struct tx_mgmt_hdr {
u8 flags;
u8 key_type;
u8 keyix;
- u16 reserved;
+ __be16 reserved;
} __packed;
struct tx_beacon_header {
u8 len_changed;
u8 vif_index;
- u16 rev;
-} __packed;
-
-struct ath9k_htc_target_hw {
- u32 flags;
- u32 flags_ext;
- u32 ampdu_limit;
- u8 ampdu_subframes;
- u8 tx_chainmask;
- u8 tx_chainmask_legacy;
- u8 rtscts_ratecode;
- u8 protmode;
+ __be16 rev;
} __packed;
struct ath9k_htc_cap_target {
- u32 flags;
- u32 flags_ext;
- u32 ampdu_limit;
+ __be32 flags;
+ __be32 flags_ext;
+ __be32 ampdu_limit;
u8 ampdu_subframes;
u8 tx_chainmask;
u8 tx_chainmask_legacy;
@@ -128,9 +117,9 @@ struct ath9k_htc_target_vif {
__be32 opmode;
u8 myaddr[ETH_ALEN];
u8 bssid[ETH_ALEN];
- u32 flags;
- u32 flags_ext;
- u16 ps_sta;
+ __be32 flags;
+ __be32 flags_ext;
+ __be16 ps_sta;
__be16 rtsthreshold;
u8 ath_cap;
u8 node;
@@ -144,25 +133,25 @@ struct ath9k_htc_target_vif {
/* FIXME: UAPSD variables */
struct ath9k_htc_target_sta {
- u16 associd;
- u16 txpower;
- u32 ucastkey;
+ __be16 associd;
+ __be16 txpower;
+ __be32 ucastkey;
u8 macaddr[ETH_ALEN];
u8 bssid[ETH_ALEN];
u8 sta_index;
u8 vif_index;
u8 vif_sta;
__be16 flags; /* ATH_HTC_STA_* */
- u16 htcap;
+ __be16 htcap;
u8 valid;
- u16 capinfo;
- struct ath9k_htc_target_hw *hw;
+ __be16 capinfo;
+ struct ath9k_htc_cap_target *hw;
struct ath9k_htc_target_vif *vif;
- u16 txseqmgmt;
+ __be16 txseqmgmt;
u8 is_vif_sta;
- u16 maxampdu;
- u16 iv16;
- u32 iv32;
+ __be16 maxampdu;
+ __be16 iv16;
+ __be32 iv32;
} __packed;
struct ath9k_htc_target_aggr {
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_main.c
b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
index e9761c2..1b435d4 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_main.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
@@ -204,7 +204,7 @@ static int ath9k_htc_add_station(struct ath9k_htc_priv
*priv,
ista = (struct ath9k_htc_sta *) sta->drv_priv;
memcpy(&tsta.macaddr, sta->addr, ETH_ALEN);
memcpy(&tsta.bssid, common->curbssid, ETH_ALEN);
- tsta.associd = common->curaid;
+ tsta.associd = cpu_to_be16(common->curaid);
tsta.is_vif_sta = 0;
tsta.valid = true;
ista->index = priv->nstations;
@@ -215,7 +215,7 @@ static int ath9k_htc_add_station(struct ath9k_htc_priv
*priv,
tsta.sta_index = priv->nstations;
tsta.vif_index = avp->index;
- tsta.maxampdu = 0x;
+ tsta.maxampdu = cpu_to_be16(0x);
if (sta && sta->ht_cap.ht_supported)
tsta.flags = cpu_to_be16(ATH_HTC_STA_HT);
@@ -279,9 +279,9 @@ static int ath9k_htc_update_cap_target(struct
ath9k_htc_priv *priv)
memset(&tcap, 0, sizeof(struct ath9k_htc_cap_target));
/* FIXME: Values are hardcoded */
- tcap.flags = 0x240c40;
- tcap.flags_ext = 0x80601000;
- tcap.ampdu_limit = 0x;
+ tcap.flags = cpu_to_be32(0x240c40);
+ tcap.flags_ext = cpu_to_be32(0x80601000);
+ tcap.ampdu_limit = cpu_to_be32(0x);
tcap.ampdu_subframes = 20;
tcap.tx_chainmask_legacy = priv->ah->caps.tx_chainmask;
tcap.protmode = 1;
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_txrx.c
b/drivers/net/wireless/ath/ath9k/htc_drv_txrx.c
index 7795867..9902ec7 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_txrx.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_txrx.c
@@ -136,12 +136,12 @@ int ath9k_htc_tx_start(struct ath9k_htc_priv *priv,
struct sk_buff *skb)
/* Check for RTS protection */
if (priv->hw->wiphy->rts_threshold != (u32) -1)
if (skb->len > priv->hw->wiphy->rts_threshold)
- tx_hdr.flags |= ATH9K_HTC_TX_RTSCTS;
+
Re: [ath9k-devel] ath9k_htc vs. powerpc (was Re: working usb wifi card, that is still possible to buy)
Pavel Machek wrote: > Hi! > > > > Sujith, I see you fought with endianness issues on ath9k_htc > > > driver. Was you able to test it on actual hardware? Should I try the > > > version just after your commit? > > > > No, I never had a chance to test the driver on a big-endian system. > > I assume you are referring to this commit: "ath9k_htc: Fix sparse endian > > warnings" ? > > Yes. > > > Does using latest wireless-testing help ? > > I updated to wireless-testing from today, and still same results. A lot of structures in htc.h are not handled in an endian-safe manner. I'll send a patch fixing them and maybe things will improve. Sujith ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k_htc vs. powerpc (was Re: working usb wifi card, that is still possible to buy)
Hi! > > ...so I indentified two endianness problems in eeprom, but even with > > both fixed, it still will not associate. Is there some way to dump USB > > packets, then compare them between PC and PowerPC versions? Should I > > expect them to match? > > Does this patch help ? No, it does not seem to. (I did apply it on top of other fixes, but they should not interfere.) Pavel ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k_htc vs. powerpc (was Re: working usb wifi card, that is still possible to buy)
Hi! > > ...so I indentified two endianness problems in eeprom, but even with > > both fixed, it still will not associate. Is there some way to dump USB > > packets, then compare them between PC and PowerPC versions? Should I > > expect them to match? > > Does this patch help ? Actually I wonder... > diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_main.c > b/drivers/net/wireless/ath/ath9k/htc_drv_main.c > index e9761c2..1b435d4 100644 > --- a/drivers/net/wireless/ath/ath9k/htc_drv_main.c > +++ b/drivers/net/wireless/ath/ath9k/htc_drv_main.c > @@ -204,7 +204,7 @@ static int ath9k_htc_add_station(struct ath9k_htc_priv > *priv, > ista = (struct ath9k_htc_sta *) sta->drv_priv; > memcpy(&tsta.macaddr, sta->addr, ETH_ALEN); > memcpy(&tsta.bssid, common->curbssid, ETH_ALEN); > - tsta.associd = common->curaid; > + tsta.associd = cpu_to_be16(common->curaid); > tsta.is_vif_sta = 0; > tsta.valid = true; > ista->index = priv->nstations; We know the code currently works on PC; but this adds conversions that are nop on PowerPC and do something on PC... so they should have no effect on PowerPC and could break PC...? Pavel ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] ath9k_htc vs. powerpc (was Re: working usb wifi card, that is still possible to buy)
Pavel Machek wrote: > We know the code currently works on PC; but this adds conversions that > are nop on PowerPC and do something on PC... so they should have no > effect on PowerPC and could break PC...? Well, I tested the patch on x86 and it seemed to work okay. But yeah, it needs to be tested well. Sujith ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [AR9160] ath9k and Ubiquiti SR-71a - not getting anywhere near full TX power
On Mon, Nov 29, 2010 at 4:41 PM, Adrian Chadd wrote:
> Oh, I know about where the chainmask is set to 1x1 for legacy mode. It
> just means the effective TX power is in no way related to what the
> specification sheet is. That's why I've enabled it for non-n mode in
> my local FreeBSD HAL to evaluate its effects.
>
Oh Ok.
> I'll do some RF testing over the next few days to see if it indeed
> does (mostly) add up together and improve effective TX range, but I'm
> dubious (and I'm not an RF or communications engineer by trade, so
> this is going to be a bit of a steep learning curve.)
>
> Thanks,
>
>
> Adrian
>
> On 29 November 2010 16:39, Mohammed Shafi wrote:
>> On Mon, Nov 29, 2010 at 1:49 PM, Adrian Chadd wrote:
>>> So it turns out that the SR-71A card TX power rates are quoted based
>>> on the sum of all three chain TX'ing, rather than per-chain TX power.
>>>
>>> Given that legacy frames are transmitted through all chains anyway
>>> (there's no special handling in the TX path that limits the TX
>>> chainmask to 1 for non-11n frames), is there any reason why all the
>>> radio chains aren't enabled for legacy mode?
>>
>> Experienced people had said that one chain is sufficient for legacy
>> rates(except for PAPRD frames where all 3 chain is needed).The
>> chainmask of 1 is updated through the following thing in main.c and I
>> remember this goes into the tx descriptors,but for 11n mode the
>> default chainmask is used.
>> *
>> * Update tx/rx chainmask. For legacy association,
>> * hard code chainmask to 1x1, for 11n association, use
>> * the chainmask configuration, for bt coexistence, use
>> * the chainmask configuration even in legacy mode.
>> */
>> void ath_update_chainmask(struct ath_softc *sc, int is_ht)
>> {
>> struct ath_hw *ah = sc->sc_ah;
>> struct ath_common *common = ath9k_hw_common(ah);
>>
>> if ((sc->sc_flags & SC_OP_OFFCHANNEL) || is_ht ||
>> (ah->btcoex_hw.scheme != ATH_BTCOEX_CFG_NONE)) {
>> common->tx_chainmask = ah->caps.tx_chainmask;
>> common->rx_chainmask = ah->caps.rx_chainmask;
>> } else {
>> common->tx_chainmask = 1;
>> common->rx_chainmask = 1;
>> }
>>
>> ath_print(common, ATH_DBG_CONFIG,
>> "tx chmask: %d, rx chmask: %d\n",
>> common->tx_chainmask,
>> common->rx_chainmask);
>> }
>>
>>
>>
>>>
>>>
>>> Adrian
>>> ___
>>> ath9k-devel mailing list
>>> ath9k-devel@lists.ath9k.org
>>> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>>>
>>
>
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] Not able to connect to an access point with ar9271
Hello, 2010/11/29 Mohammed Shafi : > On Sun, Nov 28, 2010 at 7:49 PM, Matthias Bernges > wrote: >> ,Hello, >> >> 2010/11/26 Mohammed Shafi : >>> On Fri, Nov 26, 2010 at 12:17 AM, Matthias Bernges >>> wrote: Hello, I've a TP-Link TL-WN422G using Atheros AR9271 chipset. I have downloaded and installed compat-wireless-2.6.36-4 and copied the newest ar9271.fw to /lib/firmware. >>> Can you please try with the latest compat-wrieless from >>> http://wireless.kernel.org/download/compat-wireless-2.6/ The driver recognizes the stick and I am able to scan using "iwlist wlan0 scan". But I am not able to connect to a network. I have tried unencrypted und WEP-encrypted networks using iwconfig. No error occurs but when I do iwconfig it says: "Access Point: Not-Associated" >>> while using commands to connect to a AP please disable the Network Manager >> >> Good point. This helped for connecting to WPA networks using wpa_supplicant. >> But the behavior of iwconfig, while connecting to unencrypted or >> WEP-encrypted networks, didn't change. > > Ideally it should be working.Can you just send me the iwconfig > commands you use to connect to WEP-encrypted networks or > open-networks. I have used the following commands: iwconfig wlan0 essid Pasta iwconfig wlan0 essid Pasta key 11 It connects to the same box I was able to connect using WPA2, so it cannot be because of to large distance. I also copy-pasted the commands to a different machine and could successfully connect. Best, Matthias >> I also tried to connect to a WPA2-encrypted network. I copied the config-file from a working machine so the key is definitely correct. [vortexbox.localdomain ~]# wpa_supplicant -i wlan0 -c wpa.conf -Dwext ioctl[SIOCGIWSCAN]: Resource temporarily unavailable ioctl[SIOCSIWSCAN]: Device or resource busy Failed to initiate AP scan. ioctl[SIOCGIWSCAN]: Resource temporarily unavailable Trying to associate with 00:1c:f0:cf:e5:ce (SSID='Pasta' freq=2462 MHz) Associated with 00:1c:f0:cf:e5:ce WPA: 4-Way Handshake failed - pre-shared key may be incorrect CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys ioctl[SIOCSIWSCAN]: Device or resource busy Failed to initiate AP scan. Trying to associate with 00:1c:f0:cf:e5:ce (SSID='Pasta' freq=2462 MHz) Associated with 00:1c:f0:cf:e5:ce WPA: 4-Way Handshake failed - pre-shared key may be incorrect CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys ioctl[SIOCSIWSCAN]: Device or resource busy Failed to initiate AP scan. Trying to associate with 00:1c:f0:cf:e5:ce (SSID='Pasta' freq=2462 MHz) Associated with 00:00:00:00:00:00 CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys ioctl[SIOCSIWSCAN]: Device or resource busy Failed to initiate AP scan. Trying to associate with 00:1c:f0:cf:e5:ce (SSID='Pasta' freq=2462 MHz) Associated with 00:00:00:00:00:00 I don't know if it is relevant, but please mind that the "Associated with" line switches between 00:1c:f0:cf:e5:ce and 00:00:00:00:00:00. My modinfo: [vortexbox.localdomain ~]# modinfo ath9k_htc filename: /lib/modules/2.6.35.6-99.fc14.i686.PAE/kernel/drivers/net/wireless/ath/ath9k/ath9k_htc.ko description: Atheros driver 802.11n HTC based wireless devices license: Dual BSD/GPL author: Atheros Communications srcversion: D567C77238F6355D88D836E alias: usb:v0CF3p1006d*dc*dsc*dp*ic*isc*ip* alias: usb:v0CF3p9271d*dc*dsc*dp*ic*isc*ip* depends: ath9k_hw,mac80211,ath9k_common,ath,cfg80211 vermagic: 2.6.35.6-99.fc14.i686.PAE SMP mod_unload 686 parm: debug:Debugging mask (uint) parm: nohwcrypt:Disable hardware encryption (int) Best, Matthias ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel >>> >> ___ >> ath9k-devel mailing list >> ath9k-devel@lists.ath9k.org >> https://lists.ath9k.org/mailman/listinfo/ath9k-devel >> > ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] [PATCH] ath9k: Move debugfs under ieee80211/[phyname]/ath9k/
From: Ben Greear
This fixes debugfs problems when a phy is renamed,
and is able to remove a bit of code that is no longer
needed.
Signed-off-by: Ben Greear
---
:100644 100644 0c3c74c... 3586c43... M drivers/net/wireless/ath/ath9k/debug.c
:100644 100644 646ff7e... 1e5078b... M drivers/net/wireless/ath/ath9k/debug.h
:100644 100644 7eef1fa... c2852e5... M drivers/net/wireless/ath/ath9k/init.c
drivers/net/wireless/ath/ath9k/debug.c | 35 +++
drivers/net/wireless/ath/ath9k/debug.h | 16 --
drivers/net/wireless/ath/ath9k/init.c | 30 +++
3 files changed, 12 insertions(+), 69 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/debug.c
b/drivers/net/wireless/ath/ath9k/debug.c
index 0c3c74c..3586c43 100644
--- a/drivers/net/wireless/ath/ath9k/debug.c
+++ b/drivers/net/wireless/ath/ath9k/debug.c
@@ -24,8 +24,6 @@
#define REG_READ_D(_ah, _reg) \
ath9k_hw_common(_ah)->ops->read((_ah), (_reg))
-static struct dentry *ath9k_debugfs_root;
-
static int ath9k_debugfs_open(struct inode *inode, struct file *file)
{
file->private_data = inode->i_private;
@@ -878,11 +876,8 @@ int ath9k_init_debug(struct ath_hw *ah)
struct ath_common *common = ath9k_hw_common(ah);
struct ath_softc *sc = (struct ath_softc *) common->priv;
- if (!ath9k_debugfs_root)
- return -ENOENT;
-
- sc->debug.debugfs_phy = debugfs_create_dir(wiphy_name(sc->hw->wiphy),
- ath9k_debugfs_root);
+ sc->debug.debugfs_phy = debugfs_create_dir("ath9k",
+ sc->hw->wiphy->debugfsdir);
if (!sc->debug.debugfs_phy)
return -ENOMEM;
@@ -935,29 +930,7 @@ int ath9k_init_debug(struct ath_hw *ah)
sc->debug.regidx = 0;
return 0;
err:
- ath9k_exit_debug(ah);
- return -ENOMEM;
-}
-
-void ath9k_exit_debug(struct ath_hw *ah)
-{
- struct ath_common *common = ath9k_hw_common(ah);
- struct ath_softc *sc = (struct ath_softc *) common->priv;
-
debugfs_remove_recursive(sc->debug.debugfs_phy);
-}
-
-int ath9k_debug_create_root(void)
-{
- ath9k_debugfs_root = debugfs_create_dir(KBUILD_MODNAME, NULL);
- if (!ath9k_debugfs_root)
- return -ENOENT;
-
- return 0;
-}
-
-void ath9k_debug_remove_root(void)
-{
- debugfs_remove(ath9k_debugfs_root);
- ath9k_debugfs_root = NULL;
+ sc->debug.debugfs_phy = NULL;
+ return -ENOMEM;
}
diff --git a/drivers/net/wireless/ath/ath9k/debug.h
b/drivers/net/wireless/ath/ath9k/debug.h
index 646ff7e..1e5078b 100644
--- a/drivers/net/wireless/ath/ath9k/debug.h
+++ b/drivers/net/wireless/ath/ath9k/debug.h
@@ -164,10 +164,7 @@ struct ath9k_debug {
};
int ath9k_init_debug(struct ath_hw *ah);
-void ath9k_exit_debug(struct ath_hw *ah);
-int ath9k_debug_create_root(void);
-void ath9k_debug_remove_root(void);
void ath_debug_stat_interrupt(struct ath_softc *sc, enum ath9k_int status);
void ath_debug_stat_tx(struct ath_softc *sc, struct ath_buf *bf,
struct ath_tx_status *ts);
@@ -180,19 +177,6 @@ static inline int ath9k_init_debug(struct ath_hw *ah)
return 0;
}
-static inline void ath9k_exit_debug(struct ath_hw *ah)
-{
-}
-
-static inline int ath9k_debug_create_root(void)
-{
- return 0;
-}
-
-static inline void ath9k_debug_remove_root(void)
-{
-}
-
static inline void ath_debug_stat_interrupt(struct ath_softc *sc,
enum ath9k_int status)
{
diff --git a/drivers/net/wireless/ath/ath9k/init.c
b/drivers/net/wireless/ath/ath9k/init.c
index 7eef1fa..c2852e5 100644
--- a/drivers/net/wireless/ath/ath9k/init.c
+++ b/drivers/net/wireless/ath/ath9k/init.c
@@ -565,13 +565,6 @@ static int ath9k_init_softc(u16 devid, struct ath_softc
*sc, u16 subsysid,
if (ret)
goto err_hw;
- ret = ath9k_init_debug(ah);
- if (ret) {
- ath_print(common, ATH_DBG_FATAL,
- "Unable to create debugfs files\n");
- goto err_debug;
- }
-
ret = ath9k_init_queues(sc);
if (ret)
goto err_queues;
@@ -594,8 +587,6 @@ err_btcoex:
if (ATH_TXQ_SETUP(sc, i))
ath_tx_cleanupq(sc, &sc->tx.txq[i]);
err_queues:
- ath9k_exit_debug(ah);
-err_debug:
ath9k_hw_deinit(ah);
err_hw:
tasklet_kill(&sc->intr_tq);
@@ -739,6 +730,13 @@ int ath9k_init_device(u16 devid, struct ath_softc *sc, u16
subsysid,
if (error)
goto error_register;
+ error = ath9k_init_debug(ah);
+ if (error) {
+ ath_print(common, ATH_DBG_FATAL,
+ "Unable to create debugfs files\n");
+ goto error_world;
+ }
+
/* Handle world regulatory */
if (!ath_is_world_regd(reg)) {
error = regulato
Re: [ath9k-devel] [PATCH wireless-next] ath: Rename ath_print to ath_debug
On Mon, Nov 29, 2010 at 2:41 PM, Felix Fietkau wrote: > On 2010-11-29 7:07 AM, Peter Stuge wrote: >> Luis R. Rodriguez wrote: >>> On Sun, Nov 28, 2010 at 3:53 PM, Joe Perches wrote: >>> > Make the function name match the function purpose. >>> > ath_debug is a debug only facility. >>> > ath_print seems too generic a name for a debug only use. >>> >>> Nack, I don't see the point. >> >> The point is to improve readability. I like the patch. > And how exactly does this improve readability? Don't get me wrong, I > generally like to see more cleanups merged to the ath/ath9k drivers > (they do need it, after all). > > But in my opinion, simple renaming churn like this does nothing but > annoy people who want to get other work done at the same time. > Consider the large number of lines touched (and the potential merge > conflicts with other code because of that), relative to the microscopic > aesthetic gain (if any). > > Instead I'd like to see more cleanups that go beyond trivial function > renames. Thanks for putting it so clearly. Agreed. Luis ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH wireless-next] ath: Rename ath_print to ath_debug
On 2010-11-29 7:07 AM, Peter Stuge wrote: > Luis R. Rodriguez wrote: >> On Sun, Nov 28, 2010 at 3:53 PM, Joe Perches wrote: >> > Make the function name match the function purpose. >> > ath_debug is a debug only facility. >> > ath_print seems too generic a name for a debug only use. >> >> Nack, I don't see the point. > > The point is to improve readability. I like the patch. And how exactly does this improve readability? Don't get me wrong, I generally like to see more cleanups merged to the ath/ath9k drivers (they do need it, after all). But in my opinion, simple renaming churn like this does nothing but annoy people who want to get other work done at the same time. Consider the large number of lines touched (and the potential merge conflicts with other code because of that), relative to the microscopic aesthetic gain (if any). Instead I'd like to see more cleanups that go beyond trivial function renames. - Felix ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
[ath9k-devel] Script to crash ath9k with DMA errors.
Here is a script that reliably crashes my ath9k box.
A second box with completely different hardware (except
for ath9k) experiences similar problems.
I am using today's wireless-testing kernel with a few
patches of my own.
You will also need the very latest hostap tree as it has the
optimizations for allowing STAs to share scans. Without
this optimization, I did not see this problem.
A few notes about the script:
* I cannot remove any interfaces, seems a ref-count leak somewhere.
I haven't debugged this issue.
* Without the background ping, it is very hard to reproduce this problem,
but with it, it happens almost every time.
* You'll need to set up your paths at the top of the script.
#!/usr/bin/perl
use strict;
my $iw = "./local/sbin/iw";
my $ip = "./local/sbin/ip";
my $wpa_s = "./local/bin/wpa_supplicant";
my $ssid = "candela-n";
my $key = "wpadmz123";
my $phy = "wiphy0";
my $max = 32;
my $i;
my $bmac = "00:01:02:03:04:";
my $cmd;
# Cleanup previous stuff
runCmd("killall wpa_supplicant");
runCmd("killall ping");
for ($i = 0; $i<$max; $i++) {
# Work around ref-counting bugs in kernel
runCmd("$ip link set sta$i down");
runCmd("$ip addr flush dev sta$i");
runCmd("$ip route flush dev sta$i");
runCmd("$ip -6 addr flush dev sta$i");
runCmd("$ip -6 route flush dev sta$i");
# Bugger, cannot get the ref-count problem to go away.
# runCmd("$iw dev sta$i del");
}
#exit(0);
open(FD, ">pingbg") || die("Couldn't open pingbg.");
print FD "#!/bin/bash\n\n";
print FD "ping \$* > /dev/null 2>&1 &\n";
print FD "echo continuing\n";
close(FD);
runCmd("chmod a+x pingbg");
# Create stations
for ($i = 0; $i<$max; $i++) {
runCmd("$iw phy $phy interface add sta$i type station");
my $mc5 = $i + 1;
if (length($mc5) == 1) {
$mc5 = "0$mc5"; # pad mac octet
}
my $mac = "$bmac$mc5";
runCmd("$ip link set sta$i address $mac");
runCmd("$iw dev sta$i set power_save off");
runCmd("$ip addr add 9.99.1.$mc5/24 dev sta$i");
runCmd("./pingbg -I sta$i 9.99.1.1");
}
# Bring them up with WPA
for ($i = 0; $i<$max; $i++) {
open(FD, ">sta$i" . "_wpa.conf") || die("Couldn't open file: $!\n");
print FD "
ctrl_interface=/var/run/wpa_supplicant
fast_reauth=1
#can_scan_one=1
network={
ssid=\"$ssid\"
proto=WPA
key_mgmt=WPA-PSK
psk=\"$key\"
pairwise=TKIP CCMP
group=TKIP CCMP
}
";
#runCmd("$wpa_s -B -i sta$i -c sta$i" . "_wpa.conf -P sta$i" . "_wpa.pid -t
-f sta$i" . "_wpa.log");
}
# Build command to start one wpa_supplicant for all interfaces.
my $cmd = "$wpa_s -B -g /var/run/wpa_supplicant_if -P
/tmp/wpa_supplicant-all.pid -t -f /tmp/wpa_supplicant_log_all.txt -i sta0 -c
sta0_wpa.conf";
for ($i = 1; $i<$max; $i++) {
$cmd = "$cmd -N -i sta$i -c sta$i" . "_wpa.conf";
}
runCmd($cmd);
sub runCmd {
my $cmd = shift;
print "$cmd\n";
`$cmd`;
}
Example kernel crash output:
ADDRCONF(NETDEV_CHANGE): sta6: link becomes ready
ADDRCONF(NETDEV_CHANGE): sta5: link becomes ready
ADDRCONF(NETDEV_CHANGE): sta4: link becomes ready
ADDRCONF(NETDEV_CHANGE): sta3: link becomes ready
ADDRCONF(NETDEV_CHANGE): sta1: link becomes ready
ADDRCONF(NETDEV_CHANGE): sta0: link becomes ready
padlock: VIA PadLock not detected.
[r...@ath9k-dev1 ~]# ADDRCONF(NETDEV_CHANGE): sta30: link becomes ready
ADDRCONF(NETDEV_CHANGE): sta29: link becomes ready
[ cut here ]
WARNING: at
/home/greearb/git/linux.wireless-testing/drivers/net/wireless/ath/ath9k/recv.c:532
ath_stoprecv+0x90/0x9a [ath9k]()
Hardware name: PDSBM
Could not stop RX, we could be confusing the DMA engine when we start RX up
Modules linked in: aes_i586 aes_generic fuse nfs lockd fscache nfs_acl
auth_rpcgss sunrpc ipv6 uinput arc4 ecb ath9k mac80211 ath9k_common ath9k_hw mi]
Pid: 3505, comm: wpa_supplicant Not tainted 2.6.37-rc3-wl+ #53
Call Trace:
[<78436fe9>] warn_slowpath_common+0x77/0x8c
[] ? ath_stoprecv+0x90/0x9a [ath9k]
[] ? ath_stoprecv+0x90/0x9a [ath9k]
[<7843707a>] warn_slowpath_fmt+0x2e/0x30
[] ath_stoprecv+0x90/0x9a [ath9k]
[] ath_set_channel+0x94/0x1e8 [ath9k]
[<7845a425>] ? mark_held_locks+0x47/0x5f
[<7878e5bb>] ? _raw_spin_unlock_irqrestore+0x3c/0x48
[] ath9k_config+0x344/0x423 [ath9k]
[] ieee80211_hw_config+0x11b/0x125 [mac80211]
[] ieee80211_set_channel+0x74/0x9e [mac80211]
[] cfg80211_set_freq+0xf3/0x12d [cfg80211]
[] ? ieee80211_set_channel+0x0/0x9e [mac80211]
[] cfg80211_mgd_wext_siwfreq+0x108/0x148 [cfg80211]
[] cfg80211_wext_siwfreq+0x42/0xbf [cfg80211]
[<7876e14f>] ioctl_standard_call+0x52/0x28e
[<786f2db3>] ? dev_name_hash+0x16/0x48
[<786f67cc>] ? __dev_get_by_name+0x32/0x3d
[<7876e418>] wext_handle_ioctl+0x8d/0x18d
[] ? cfg80211_wext_siwfreq+0x0/0xbf [cfg80211]
[<786f78f9>] dev_ioctl+0x520/0x53f
[<786e5f7f>] ? sock_ioctl+0x0/0x202
[<786e6175>] sock_ioctl+0x1f6/0x202
[<7878e576>] ? _raw_spin_unlock_irq+0x22/0x2b
[<786e5f7f>] ? sock_ioctl+0x0/0x202
[<784cc151>] do_vfs_ioctl+0x4b1/0x4f6
[<78
Re: [ath9k-devel] Script to crash ath9k with DMA errors.
On Mon, Nov 29, 2010 at 04:28:51PM -0800, Ben Greear wrote:
> Here is a script that reliably crashes my ath9k box.
> A second box with completely different hardware (except
> for ath9k) experiences similar problems.
>
> I am using today's wireless-testing kernel with a few
> patches of my own.
>
> You will also need the very latest hostap tree as it has the
> optimizations for allowing STAs to share scans. Without
> this optimization, I did not see this problem.
>
> A few notes about the script:
>
> * I cannot remove any interfaces, seems a ref-count leak somewhere.
>I haven't debugged this issue.
>
> * Without the background ping, it is very hard to reproduce this problem,
>but with it, it happens almost every time.
>
> * You'll need to set up your paths at the top of the script.
>
>
> #!/usr/bin/perl
>
> use strict;
>
> my $iw = "./local/sbin/iw";
> my $ip = "./local/sbin/ip";
> my $wpa_s = "./local/bin/wpa_supplicant";
> my $ssid = "candela-n";
> my $key = "wpadmz123";
>
> my $phy = "wiphy0";
> my $max = 32;
> my $i;
> my $bmac = "00:01:02:03:04:";
> my $cmd;
>
> # Cleanup previous stuff
> runCmd("killall wpa_supplicant");
> runCmd("killall ping");
>
> for ($i = 0; $i<$max; $i++) {
># Work around ref-counting bugs in kernel
>runCmd("$ip link set sta$i down");
>runCmd("$ip addr flush dev sta$i");
>runCmd("$ip route flush dev sta$i");
>runCmd("$ip -6 addr flush dev sta$i");
>runCmd("$ip -6 route flush dev sta$i");
>
># Bugger, cannot get the ref-count problem to go away.
># runCmd("$iw dev sta$i del");
> }
>
> #exit(0);
>
> open(FD, ">pingbg") || die("Couldn't open pingbg.");
> print FD "#!/bin/bash\n\n";
> print FD "ping \$* > /dev/null 2>&1 &\n";
> print FD "echo continuing\n";
> close(FD);
> runCmd("chmod a+x pingbg");
>
> # Create stations
> for ($i = 0; $i<$max; $i++) {
>runCmd("$iw phy $phy interface add sta$i type station");
>my $mc5 = $i + 1;
>if (length($mc5) == 1) {
> $mc5 = "0$mc5"; # pad mac octet
>}
>my $mac = "$bmac$mc5";
>runCmd("$ip link set sta$i address $mac");
>
>runCmd("$iw dev sta$i set power_save off");
>runCmd("$ip addr add 9.99.1.$mc5/24 dev sta$i");
>runCmd("./pingbg -I sta$i 9.99.1.1");
> }
>
> # Bring them up with WPA
> for ($i = 0; $i<$max; $i++) {
>open(FD, ">sta$i" . "_wpa.conf") || die("Couldn't open file: $!\n");
>print FD "
> ctrl_interface=/var/run/wpa_supplicant
> fast_reauth=1
> #can_scan_one=1
> network={
> ssid=\"$ssid\"
> proto=WPA
> key_mgmt=WPA-PSK
> psk=\"$key\"
> pairwise=TKIP CCMP
> group=TKIP CCMP
> }
> ";
>#runCmd("$wpa_s -B -i sta$i -c sta$i" . "_wpa.conf -P sta$i" . "_wpa.pid
> -t -f sta$i" . "_wpa.log");
> }
>
> # Build command to start one wpa_supplicant for all interfaces.
> my $cmd = "$wpa_s -B -g /var/run/wpa_supplicant_if -P
> /tmp/wpa_supplicant-all.pid -t -f /tmp/wpa_supplicant_log_all.txt -i sta0 -c
> sta0_wpa.conf";
> for ($i = 1; $i<$max; $i++) {
>$cmd = "$cmd -N -i sta$i -c sta$i" . "_wpa.conf";
> }
> runCmd($cmd);
>
> sub runCmd {
>my $cmd = shift;
>print "$cmd\n";
>`$cmd`;
> }
>
>
> Example kernel crash output:
>
> ADDRCONF(NETDEV_CHANGE): sta6: link becomes ready
> ADDRCONF(NETDEV_CHANGE): sta5: link becomes ready
> ADDRCONF(NETDEV_CHANGE): sta4: link becomes ready
> ADDRCONF(NETDEV_CHANGE): sta3: link becomes ready
> ADDRCONF(NETDEV_CHANGE): sta1: link becomes ready
> ADDRCONF(NETDEV_CHANGE): sta0: link becomes ready
> padlock: VIA PadLock not detected.
>
> [r...@ath9k-dev1 ~]# ADDRCONF(NETDEV_CHANGE): sta30: link becomes ready
> ADDRCONF(NETDEV_CHANGE): sta29: link becomes ready
> [ cut here ]
> WARNING: at
> /home/greearb/git/linux.wireless-testing/drivers/net/wireless/ath/ath9k/recv.c:532
> ath_stoprecv+0x90/0x9a [ath9k]()
> Hardware name: PDSBM
> Could not stop RX, we could be confusing the DMA engine when we start RX up
> Modules linked in: aes_i586 aes_generic fuse nfs lockd fscache nfs_acl
> auth_rpcgss sunrpc ipv6 uinput arc4 ecb ath9k mac80211 ath9k_common ath9k_hw
> mi]
> Pid: 3505, comm: wpa_supplicant Not tainted 2.6.37-rc3-wl+ #53
> Call Trace:
> [<78436fe9>] warn_slowpath_common+0x77/0x8c
> [] ? ath_stoprecv+0x90/0x9a [ath9k]
> [] ? ath_stoprecv+0x90/0x9a [ath9k]
> [<7843707a>] warn_slowpath_fmt+0x2e/0x30
> [] ath_stoprecv+0x90/0x9a [ath9k]
> [] ath_set_channel+0x94/0x1e8 [ath9k]
> [<7845a425>] ? mark_held_locks+0x47/0x5f
> [<7878e5bb>] ? _raw_spin_unlock_irqrestore+0x3c/0x48
> [] ath9k_config+0x344/0x423 [ath9k]
> [] ieee80211_hw_config+0x11b/0x125 [mac80211]
> [] ieee80211_set_channel+0x74/0x9e [mac80211]
> [] cfg80211_set_freq+0xf3/0x12d [cfg80211]
> [] ? ieee80211_set_channel+0x0/0x9e [mac80211]
> [] cfg80211_mgd_wext_siwfreq+0x108/0x148 [cfg80211]
> [] cfg80211_wext_siwfreq+0x42/0xbf [cfg80211]
> [<7876e14f>] ioctl_standard_call+0x52/0x28e
> [<786f2db3>] ? dev_name_hash+0x16/0x48
> [<786f67cc
Re: [ath9k-devel] Script to crash ath9k with DMA errors.
On 11/29/2010 04:44 PM, Luis R. Rodriguez wrote:
> On Mon, Nov 29, 2010 at 04:28:51PM -0800, Ben Greear wrote:
>> Here is a script that reliably crashes my ath9k box.
>> A second box with completely different hardware (except
>> for ath9k) experiences similar problems.
>> BUG: unable to handle kernel NULL pointer dereference at 0040
>> IP: [] ath_tx_start+0x461/0x5ef [ath9k]
>> *pde =
>> Oops: [#1] SMP DEBUG_PAGEALLOC
>> last sysfs file: /sys/devices/pci:00/:00:1e.0/:08:01.0/irq
>> Modules linked in: aes_i586 aes_generic fuse nfs lockd fscache nfs_acl
>> auth_rpcgss sunrpc ipv6 uinput arc4 ecb ath9k mac80211 ath9k_common ath9k_hw
>> mi]
>>
>> Pid: 38, comm: kworker/u:1 Tainted: GW 2.6.37-rc3-wl+ #53
>> PDSBM/PDSBM
>> EIP: 0060:[] EFLAGS: 00010246 CPU: 1
>> EIP is at ath_tx_start+0x461/0x5ef [ath9k]
>
> Please use
>
> gdb drivers/net/wireless/ath/ath9k/
> l *(ath_tx_start+0x461)
Usually the machine locks pretty hard with irq errors reported from wired NICs
and/or the hard-drive. I'm not sure that the ath_tx_start
issue is real, or maybe just some un-lucky side-affect of earlier
bugs in this trace.
Reading symbols from
/home/greearb/kernel/2.6/wireless-testing-dbg.p4s/drivers/net/wireless/ath/ath9k/ath9k.ko...done.
(gdb) l *(ath_tx_start+0x461)
0x972e is in ath_tx_start
(/home/greearb/git/linux.wireless-testing/drivers/net/wireless/ath/ath9k/xmit.c:1691).
1686if ((tx_info->flags & IEEE80211_TX_CTL_AMPDU) && txctl->an) {
1687tidno = ieee80211_get_qos_ctl(hdr)[0] &
1688IEEE80211_QOS_CTL_TID_MASK;
1689tid = ATH_AN_2_TID(txctl->an, tidno);
1690
1691WARN_ON(tid->ac->txq != txctl->txq);
1692/*
1693 * Try aggregation if it's a unicast data frame
1694 * and the destination is HT capable.
1695 */
Thanks,
Ben
>
>Luis
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH wireless-next] ath: Rename ath_print to ath_debug
On Mon, 2010-11-29 at 23:41 +0100, Felix Fietkau wrote: > On 2010-11-29 7:07 AM, Peter Stuge wrote: > > Luis R. Rodriguez wrote: > >> On Sun, Nov 28, 2010 at 3:53 PM, Joe Perches wrote: > >> > Make the function name match the function purpose. > >> > ath_debug is a debug only facility. > >> > ath_print seems too generic a name for a debug only use. > >> Nack, I don't see the point. > > > > The point is to improve readability. I like the patch. > And how exactly does this improve readability? Don't get me wrong, I > generally like to see more cleanups merged to the ath/ath9k drivers > (they do need it, after all). It's considered polite to cc the patch author. print is generic, debug is specific. This function has a specific use for debugging not a generic use all for logging. If it was ath_print(level, etc) with KERN_ passed as the first argument that'd be similar to other kernel calls. As is, it's not. > But in my opinion, simple renaming churn like this does nothing but > annoy people who want to get other work done at the same time. This sort of thing can be done when other changes have just been merged to minimize conflicts. > Consider the large number of lines touched (and the potential merge > conflicts with other code because of that), relative to the microscopic > aesthetic gain (if any). > > Instead I'd like to see more cleanups that go beyond trivial function > renames. I gauge my willingness to spend time on subsystems on the maintainers willingness to merge things that improve readability and correctness. cheers, Joe ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
Re: [ath9k-devel] [PATCH wireless-next] ath: Rename ath_print to ath_debug
On 2010-11-30 2:39 AM, Joe Perches wrote: > On Mon, 2010-11-29 at 23:41 +0100, Felix Fietkau wrote: >> On 2010-11-29 7:07 AM, Peter Stuge wrote: >> > Luis R. Rodriguez wrote: >> >> On Sun, Nov 28, 2010 at 3:53 PM, Joe Perches wrote: >> >> > Make the function name match the function purpose. >> >> > ath_debug is a debug only facility. >> >> > ath_print seems too generic a name for a debug only use. >> >> Nack, I don't see the point. >> > >> > The point is to improve readability. I like the patch. >> And how exactly does this improve readability? Don't get me wrong, I >> generally like to see more cleanups merged to the ath/ath9k drivers >> (they do need it, after all). > > It's considered polite to cc the patch author. Sorry, I forgot to add you back. The Cc list was cleared somewhere in this thread and I added a few entries back, but apparently accidentally dropped some of them again. > print is generic, debug is specific. > This function has a specific use for debugging > not a generic use all for logging. > > If it was ath_print(level, etc) with KERN_ > passed as the first argument that'd be similar > to other kernel calls. As is, it's not. > >> But in my opinion, simple renaming churn like this does nothing but >> annoy people who want to get other work done at the same time. > > This sort of thing can be done when other changes have > just been merged to minimize conflicts. > >> Consider the large number of lines touched (and the potential merge >> conflicts with other code because of that), relative to the microscopic >> aesthetic gain (if any). >> >> Instead I'd like to see more cleanups that go beyond trivial function >> renames. > > I gauge my willingness to spend time on subsystems on > the maintainers willingness to merge things that improve > readability and correctness. I'm not trying to discourage you from spending time on improving this code, just doubting the usefulness of such simple function renames. - Felix ___ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
