* [RFC] mac80211: indicate BA window size with IEEE80211_AMPDU_TX_OPERATIONAL drv_ampud_action
From: yogeshp @ 2010-07-15 13:18 UTC (permalink / raw)
To: linville; +Cc: Nishant Sarmukadam, Pradeep Nemavat, linux-wireless
BA window size for a successful BA setup is not made available to the driver by
mac80211. The patch below gets the BA window size from addba response and
indicates it to driver through IEEE80211_AMPDU_TX_OPERATIONAL drv_ampdu_action.
Signed-off-by: yogeshp@marvell.com
Signed-off-by: nishants@marvell.com
---
include/net/mac80211.h | 3 ++-
net/mac80211/agg-rx.c | 4 ++--
net/mac80211/agg-tx.c | 17 ++++++++++-------
net/mac80211/driver-ops.h | 6 +++---
net/mac80211/driver-trace.h | 2 +-
net/mac80211/sta_info.h | 1 +
6 files changed, 19 insertions(+), 14 deletions(-)
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index 7f256e2..29ff874 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -1734,7 +1734,8 @@ struct ieee80211_ops {
int (*ampdu_action)(struct ieee80211_hw *hw,
struct ieee80211_vif *vif,
enum ieee80211_ampdu_mlme_action action,
- struct ieee80211_sta *sta, u16 tid, u16 *ssn);
+ struct ieee80211_sta *sta, u16 tid,
+ u16 buf_size, u16 *ssn);
int (*get_survey)(struct ieee80211_hw *hw, int idx,
struct survey_info *survey);
void (*rfkill_poll)(struct ieee80211_hw *hw);
diff --git a/net/mac80211/agg-rx.c b/net/mac80211/agg-rx.c
index 965b272..8a2522f 100644
--- a/net/mac80211/agg-rx.c
+++ b/net/mac80211/agg-rx.c
@@ -76,7 +76,7 @@ void ___ieee80211_stop_rx_ba_session(struct sta_info *sta, u16 tid,
#endif /* CONFIG_MAC80211_HT_DEBUG */
if (drv_ampdu_action(local, sta->sdata, IEEE80211_AMPDU_RX_STOP,
- &sta->sta, tid, NULL))
+ &sta->sta, tid, 0, NULL))
printk(KERN_DEBUG "HW problem - can not stop rx "
"aggregation for tid %d\n", tid);
@@ -274,7 +274,7 @@ void ieee80211_process_addba_request(struct ieee80211_local *local,
}
ret = drv_ampdu_action(local, sta->sdata, IEEE80211_AMPDU_RX_START,
- &sta->sta, tid, &start_seq_num);
+ &sta->sta, tid, 0, &start_seq_num);
#ifdef CONFIG_MAC80211_HT_DEBUG
printk(KERN_DEBUG "Rx A-MPDU request on tid %d result %d\n", tid, ret);
#endif /* CONFIG_MAC80211_HT_DEBUG */
diff --git a/net/mac80211/agg-tx.c b/net/mac80211/agg-tx.c
index c893f23..4332ca8 100644
--- a/net/mac80211/agg-tx.c
+++ b/net/mac80211/agg-tx.c
@@ -186,7 +186,7 @@ int ___ieee80211_stop_tx_ba_session(struct sta_info *sta, u16 tid,
ret = drv_ampdu_action(local, sta->sdata,
IEEE80211_AMPDU_TX_STOP,
- &sta->sta, tid, NULL);
+ &sta->sta, tid, 0, NULL);
/* HW shall not deny going back to legacy */
if (WARN_ON(ret)) {
@@ -307,7 +307,7 @@ void ieee80211_tx_ba_session_handle_start(struct sta_info *sta, int tid)
start_seq_num = sta->tid_seq[tid] >> 4;
ret = drv_ampdu_action(local, sdata, IEEE80211_AMPDU_TX_START,
- &sta->sta, tid, &start_seq_num);
+ &sta->sta, tid, 0, &start_seq_num);
if (ret) {
#ifdef CONFIG_MAC80211_HT_DEBUG
printk(KERN_DEBUG "BA request denied - HW unavailable for"
@@ -470,7 +470,7 @@ ieee80211_agg_splice_finish(struct ieee80211_local *local, u16 tid)
}
static void ieee80211_agg_tx_operational(struct ieee80211_local *local,
- struct sta_info *sta, u16 tid)
+ struct sta_info *sta, u16 tid, u16 buf_size)
{
lockdep_assert_held(&sta->ampdu_mlme.mtx);
@@ -480,7 +480,7 @@ static void ieee80211_agg_tx_operational(struct ieee80211_local *local,
drv_ampdu_action(local, sta->sdata,
IEEE80211_AMPDU_TX_OPERATIONAL,
- &sta->sta, tid, NULL);
+ &sta->sta, tid, buf_size, NULL);
/*
* synchronize with TX path, while splicing the TX path
@@ -541,7 +541,7 @@ void ieee80211_start_tx_ba_cb(struct ieee80211_vif *vif, u8 *ra, u16 tid)
goto unlock;
if (test_bit(HT_AGG_STATE_RESPONSE_RECEIVED, &tid_tx->state))
- ieee80211_agg_tx_operational(local, sta, tid);
+ ieee80211_agg_tx_operational(local, sta, tid, tid_tx->buf_size);
unlock:
mutex_unlock(&sta->ampdu_mlme.mtx);
@@ -733,10 +733,11 @@ void ieee80211_process_addba_resp(struct ieee80211_local *local,
size_t len)
{
struct tid_ampdu_tx *tid_tx;
- u16 capab, tid;
+ u16 capab, tid, buf_size;
capab = le16_to_cpu(mgmt->u.action.u.addba_resp.capab);
tid = (capab & IEEE80211_ADDBA_PARAM_TID_MASK) >> 2;
+ buf_size = (capab & IEEE80211_ADDBA_PARAM_BUF_SIZE_MASK) >> 6;
mutex_lock(&sta->ampdu_mlme.mtx);
@@ -753,6 +754,8 @@ void ieee80211_process_addba_resp(struct ieee80211_local *local,
del_timer(&tid_tx->addba_resp_timer);
+ tid_tx->buf_size = buf_size;
+
#ifdef CONFIG_MAC80211_HT_DEBUG
printk(KERN_DEBUG "switched off addBA timer for tid %d\n", tid);
#endif
@@ -766,7 +769,7 @@ void ieee80211_process_addba_resp(struct ieee80211_local *local,
}
if (test_bit(HT_AGG_STATE_DRV_READY, &tid_tx->state))
- ieee80211_agg_tx_operational(local, sta, tid);
+ ieee80211_agg_tx_operational(local, sta, tid, buf_size);
sta->ampdu_mlme.addba_req_num[tid] = 0;
} else {
diff --git a/net/mac80211/driver-ops.h b/net/mac80211/driver-ops.h
index 14123dc..383eee7 100644
--- a/net/mac80211/driver-ops.h
+++ b/net/mac80211/driver-ops.h
@@ -354,17 +354,17 @@ static inline int drv_ampdu_action(struct ieee80211_local *local,
struct ieee80211_sub_if_data *sdata,
enum ieee80211_ampdu_mlme_action action,
struct ieee80211_sta *sta, u16 tid,
- u16 *ssn)
+ u16 buf_size, u16 *ssn)
{
int ret = -EOPNOTSUPP;
might_sleep();
- trace_drv_ampdu_action(local, sdata, action, sta, tid, ssn);
+ trace_drv_ampdu_action(local, sdata, action, sta, tid, buf_size, ssn);
if (local->ops->ampdu_action)
ret = local->ops->ampdu_action(&local->hw, &sdata->vif, action,
- sta, tid, ssn);
+ sta, tid, buf_size, ssn);
trace_drv_return_int(local, ret);
diff --git a/net/mac80211/driver-trace.h b/net/mac80211/driver-trace.h
index 5d5d2a9..c98bce0 100644
--- a/net/mac80211/driver-trace.h
+++ b/net/mac80211/driver-trace.h
@@ -733,7 +733,7 @@ TRACE_EVENT(drv_ampdu_action,
struct ieee80211_sub_if_data *sdata,
enum ieee80211_ampdu_mlme_action action,
struct ieee80211_sta *sta, u16 tid,
- u16 *ssn),
+ u16 buf_size, u16 *ssn),
TP_ARGS(local, sdata, action, sta, tid, ssn),
diff --git a/net/mac80211/sta_info.h b/net/mac80211/sta_info.h
index 54262e7..6685d4d 100644
--- a/net/mac80211/sta_info.h
+++ b/net/mac80211/sta_info.h
@@ -95,6 +95,7 @@ struct tid_ampdu_tx {
unsigned long state;
u8 dialog_token;
u8 stop_initiator;
+ u16 buf_size;
};
/**
--
1.5.4.1
^ permalink raw reply related
* Re: Bug#588196: b43: does not join multicast groups
From: Simon Richter @ 2010-07-15 8:51 UTC (permalink / raw)
To: Michael Büsch
Cc: Larry Finger, Ben Hutchings, Stefano Brivio, linux-wireless,
588196
In-Reply-To: <4C3DB065.70009@bu3sch.de>
Hi,
On Wed, Jul 14, 2010 at 02:41:09PM +0200, Michael Büsch wrote:
> The same applies to receiving. The RX queue is also dropped on switch
> from DMA to PIO.
Sure, but the packet is repeated every ten seconds. The problem is that
none of those packets is received, even long after the switch to PIO.
> >advertisement, sent to 33:33:00:00:00:01). I have no idea where the
> >packet is dropped; from my somewhat limited understanding of 802.11, I'd
> >expect the frames to be treated like broadcast frames by the AP, so it'd
> >be the receiver dropping them in the MAC filter.
> The actual switch from DMA to PIO mode completely reinitializes
> the hardware and drops all queues.
Would it be possible to reinitialize the multicast filter at this point?
Simon
^ permalink raw reply
* Re: [PATCH 01/11] Removing dead RT2800PCI_SOC
From: Bartlomiej Zolnierkiewicz @ 2010-07-15 8:41 UTC (permalink / raw)
To: Felix Fietkau
Cc: John W. Linville, Ivo Van Doorn, Christoph Egger,
Gertjan van Wingerde, Helmut Schaa, linux-wireless, users, netdev,
linux-kernel, vamos-dev, Luis Correia
In-Reply-To: <4C3DCD5C.1080705@openwrt.org>
On Wednesday 14 July 2010 04:44:44 pm Felix Fietkau wrote:
> On 2010-07-14 3:15 PM, John W. Linville wrote:
> > On Wed, Jul 14, 2010 at 02:52:14PM +0200, Ivo Van Doorn wrote:
> >> On Wed, Jul 14, 2010 at 2:46 PM, Luis Correia <luis.f.correia@gmail.com> wrote:
> >> > On Wed, Jul 14, 2010 at 13:39, Christoph Egger <siccegge@cs.fau.de> wrote:
> >> >> While RT2800PCI_SOC exists in Kconfig, it depends on either
> >> >> RALINK_RT288X or RALINK_RT305X which are both not available in Kconfig
> >> >> so all Code depending on that can't ever be selected and, if there's
> >> >> no plan to add these options, should be cleaned up
> >> >>
> >> >> Signed-off-by: Christoph Egger <siccegge@cs.fau.de>
> >> >
> >> > NAK,
> >> >
> >> > this is not dead code, it is needed for the Ralink System-on-Chip
> >> > Platform devices.
> >> >
> >> > While I can't fix Kconfig errors and the current KConfig file may be
> >> > wrong, this code cannot and will not be deleted.
> >>
> >> When the config option was introduced, the config options RALINK_RT288X and
> >> RALINK_RT305X were supposed to be merged as well soon after by somebody (Felix?)
> >>
> >> But since testing is done on SoC boards by Helmut and Felix, I assume the code
> >> isn't dead but actually in use.
> >
> > Perhaps Helmut and Felix can send us the missing code?
> The missing code is a MIPS platform port, which is currently being
> maintained in OpenWrt, but is not ready for upstream submission yet.
> I'm not working on this code at the moment, but I think it will be
> submitted once it's ready.
People are using automatic scripts to catch unused config options nowadays
so the issue is quite likely to come back again sooner or later..
Would it be possible to improve situation somehow till the missing parts
get merged? Maybe by adding a tiny comment documenting RT2800PCI_SOC
situation to Kconfig (if the config option itself really cannot be removed)
until all code is ready etc.?
I bet that Christoph would be willing to update his patch if you ask him
nicely..
Thanks,
--
Bartlomiej Zolnierkiewicz
^ permalink raw reply
* [patch] orinoco_usb: potential null dereference
From: Dan Carpenter @ 2010-07-15 8:23 UTC (permalink / raw)
To: Pavel Roskin
Cc: David Gibson, John W. Linville, David Kilroy, linux-wireless,
orinoco-devel, kernel-janitors
Smatch complains that "upriv->read_urb" gets dereferenced before
checking for NULL. It turns out that it's possible for
"upriv->read_urb" to be NULL so I added checks around the dereferences.
Also I remove an "if (upriv->bap_buf != NULL)" check because
"kfree(NULL) is OK.
Signed-off-by: Dan Carpenter <error27@gmail.com>
diff --git a/drivers/net/wireless/orinoco/orinoco_usb.c b/drivers/net/wireless/orinoco/orinoco_usb.c
index 78f089b..11d5ec2 100644
--- a/drivers/net/wireless/orinoco/orinoco_usb.c
+++ b/drivers/net/wireless/orinoco/orinoco_usb.c
@@ -1504,16 +1504,16 @@ static inline void ezusb_delete(struct ezusb_priv *upriv)
ezusb_ctx_complete(list_entry(item,
struct request_context, list));
- if (upriv->read_urb->status == -EINPROGRESS)
+ if (upriv->read_urb && upriv->read_urb->status == -EINPROGRESS)
printk(KERN_ERR PFX "Some URB in progress\n");
mutex_unlock(&upriv->mtx);
- kfree(upriv->read_urb->transfer_buffer);
- if (upriv->bap_buf != NULL)
- kfree(upriv->bap_buf);
- if (upriv->read_urb != NULL)
+ if (upriv->read_urb) {
+ kfree(upriv->read_urb->transfer_buffer);
usb_free_urb(upriv->read_urb);
+ }
+ kfree(upriv->bap_buf);
if (upriv->dev) {
struct orinoco_private *priv = ndev_priv(upriv->dev);
orinoco_if_del(priv);
^ permalink raw reply related
* Re: [PATCH] ath9k_hw: Fix AR9003 MPDU delimeter CRC check for middle subframes
From: Luis R. Rodriguez @ 2010-07-15 4:21 UTC (permalink / raw)
To: Satya; +Cc: linville, linux-wireless, Tushit Jain, Kyungwan Nam
In-Reply-To: <003201cb23cd$527f3f90$aa01a8c0@satya>
On Wed, Jul 14, 2010 at 8:24 PM, Satya <satya.rao@redpinesignals.com> wrote:
>
> I just wonder if the delimiter length CRC is wrong, where from we
> get the length of the data packet to get to a state where we say
> we have received the data packet with correct CRC ?
>
> I am not sure about this. I appreciate if someone could clarify this.
> Thanks.
Great question :), Kyungwan, Kyungwan?
PS. This e-mail thread is on a public mailing list.
Luis
^ permalink raw reply
* Re: [PATCH] ath9k_hw: Fix AR9003 MPDU delimeter CRC check for middle subframes
From: Satya @ 2010-07-15 3:24 UTC (permalink / raw)
To: Luis R. Rodriguez, linville
Cc: linux-wireless, Luis R. Rodriguez, Tushit Jain, Kyungwan Nam
In-Reply-To: <1279152521-10805-1-git-send-email-lrodriguez@atheros.com>
I just wonder if the delimiter length CRC is wrong, where from we
get the length of the data packet to get to a state where we say
we have received the data packet with correct CRC ?
I am not sure about this. I appreciate if someone could clarify this.
Thanks.
Regards,
Satya.
----- Original Message -----
From: "Luis R. Rodriguez" <lrodriguez@atheros.com>
To: <linville@tuxdriver.com>
Cc: <linux-wireless@vger.kernel.org>; "Luis R. Rodriguez"
<lrodriguez@atheros.com>; "Tushit Jain" <tushit.jain@atheros.com>; "Kyungwan
Nam" <kyungwan.nam@atheros.com>
Sent: Thursday, July 15, 2010 5:38 AM
Subject: [PATCH] ath9k_hw: Fix AR9003 MPDU delimeter CRC check for middle
subframes
> An A-MPDU may contain several subframes each containing its own
> CRC for the data. Each subframe also has a respective CRC for the
> MPDU length and 4 reserved bits (aka delimeter CRC). AR9003 will
> ACK frames that have a valid data CRC but have failed to pass the
> CRC for the MPDU length, if and only if the subframe is not the
> last subframe in an A-MPDU and if an OFDM phy OFDM reset error has
> been caught. Discarding those subframes results in packet loss under
> heavy stress conditions, an example being UDP video. Since the
> frames are ACK'd by hardware we need to let these frames through
> and process them as valid frames.
>
> Cc: Tushit Jain <tushit.jain@atheros.com>
> Cc: Kyungwan Nam <kyungwan.nam@atheros.com>
> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
> ---
> drivers/net/wireless/ath/ath9k/ar9003_mac.c | 31
> +++++++++++++++++++++++++-
> 1 files changed, 29 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath9k/ar9003_mac.c
> b/drivers/net/wireless/ath/ath9k/ar9003_mac.c
> index 06ef710..5b995be 100644
> --- a/drivers/net/wireless/ath/ath9k/ar9003_mac.c
> +++ b/drivers/net/wireless/ath/ath9k/ar9003_mac.c
> @@ -579,12 +579,39 @@ int ath9k_hw_process_rxdesc_edma(struct ath_hw *ah,
> struct ath_rx_status *rxs,
> rxs->rs_flags |= ATH9K_RX_DECRYPT_BUSY;
>
> if ((rxsp->status11 & AR_RxFrameOK) == 0) {
> + /*
> + * AR_CRCErr will bet set to true if we're on the last
> + * subframe and the AR_PostDelimCRCErr is caught.
> + * In a way this also gives us a guarantee that when
> + * (!(AR_CRCErr) && (AR_PostDelimCRCErr)) we cannot
> + * possibly be reviewing the last subframe. AR_CRCErr
> + * is the CRC of the actual data.
> + */
> if (rxsp->status11 & AR_CRCErr) {
> rxs->rs_status |= ATH9K_RXERR_CRC;
> } else if (rxsp->status11 & AR_PHYErr) {
> - rxs->rs_status |= ATH9K_RXERR_PHY;
> phyerr = MS(rxsp->status11, AR_PHYErrCode);
> - rxs->rs_phyerr = phyerr;
> + /*
> + * If we reach a point here where AR_PostDelimCRCErr is
> + * true it implies we're *not* on the last subframe. In
> + * in that case that we know already that the CRC of
> + * the frame was OK, and MAC would send an ACK for that
> + * subframe, even if we did get a phy error of type
> + * ATH9K_PHYERR_OFDM_RESTART. This is only applicable
> + * to frame that are prior to the last subframe.
> + * The AR_PostDelimCRCErr is the CRC for the MPDU
> + * delimiter, which contains the 4 reserved bits,
> + * the MPDU length (12 bits), and follows the MPDU
> + * delimiter for an A-MPDU subframe (0x4E = 'N' ASCII).
> + */
> + if ((phyerr == ATH9K_PHYERR_OFDM_RESTART) &&
> + (rxsp->status11 & AR_PostDelimCRCErr)) {
> + rxs->rs_phyerr = 0;
> + } else {
> + rxs->rs_status |= ATH9K_RXERR_PHY;
> + rxs->rs_phyerr = phyerr;
> + }
> +
> } else if (rxsp->status11 & AR_DecryptCRCErr) {
> rxs->rs_status |= ATH9K_RXERR_DECRYPT;
> } else if (rxsp->status11 & AR_MichaelErr) {
> --
> 1.7.0.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless"
> in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
^ permalink raw reply
* [PATCH] ath9k_hw: Fix AR9003 MPDU delimeter CRC check for middle subframes
From: Luis R. Rodriguez @ 2010-07-15 0:08 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Luis R. Rodriguez, Tushit Jain, Kyungwan Nam
An A-MPDU may contain several subframes each containing its own
CRC for the data. Each subframe also has a respective CRC for the
MPDU length and 4 reserved bits (aka delimeter CRC). AR9003 will
ACK frames that have a valid data CRC but have failed to pass the
CRC for the MPDU length, if and only if the subframe is not the
last subframe in an A-MPDU and if an OFDM phy OFDM reset error has
been caught. Discarding those subframes results in packet loss under
heavy stress conditions, an example being UDP video. Since the
frames are ACK'd by hardware we need to let these frames through
and process them as valid frames.
Cc: Tushit Jain <tushit.jain@atheros.com>
Cc: Kyungwan Nam <kyungwan.nam@atheros.com>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
drivers/net/wireless/ath/ath9k/ar9003_mac.c | 31 +++++++++++++++++++++++++-
1 files changed, 29 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ar9003_mac.c b/drivers/net/wireless/ath/ath9k/ar9003_mac.c
index 06ef710..5b995be 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_mac.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_mac.c
@@ -579,12 +579,39 @@ int ath9k_hw_process_rxdesc_edma(struct ath_hw *ah, struct ath_rx_status *rxs,
rxs->rs_flags |= ATH9K_RX_DECRYPT_BUSY;
if ((rxsp->status11 & AR_RxFrameOK) == 0) {
+ /*
+ * AR_CRCErr will bet set to true if we're on the last
+ * subframe and the AR_PostDelimCRCErr is caught.
+ * In a way this also gives us a guarantee that when
+ * (!(AR_CRCErr) && (AR_PostDelimCRCErr)) we cannot
+ * possibly be reviewing the last subframe. AR_CRCErr
+ * is the CRC of the actual data.
+ */
if (rxsp->status11 & AR_CRCErr) {
rxs->rs_status |= ATH9K_RXERR_CRC;
} else if (rxsp->status11 & AR_PHYErr) {
- rxs->rs_status |= ATH9K_RXERR_PHY;
phyerr = MS(rxsp->status11, AR_PHYErrCode);
- rxs->rs_phyerr = phyerr;
+ /*
+ * If we reach a point here where AR_PostDelimCRCErr is
+ * true it implies we're *not* on the last subframe. In
+ * in that case that we know already that the CRC of
+ * the frame was OK, and MAC would send an ACK for that
+ * subframe, even if we did get a phy error of type
+ * ATH9K_PHYERR_OFDM_RESTART. This is only applicable
+ * to frame that are prior to the last subframe.
+ * The AR_PostDelimCRCErr is the CRC for the MPDU
+ * delimiter, which contains the 4 reserved bits,
+ * the MPDU length (12 bits), and follows the MPDU
+ * delimiter for an A-MPDU subframe (0x4E = 'N' ASCII).
+ */
+ if ((phyerr == ATH9K_PHYERR_OFDM_RESTART) &&
+ (rxsp->status11 & AR_PostDelimCRCErr)) {
+ rxs->rs_phyerr = 0;
+ } else {
+ rxs->rs_status |= ATH9K_RXERR_PHY;
+ rxs->rs_phyerr = phyerr;
+ }
+
} else if (rxsp->status11 & AR_DecryptCRCErr) {
rxs->rs_status |= ATH9K_RXERR_DECRYPT;
} else if (rxsp->status11 & AR_MichaelErr) {
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH] minstrel_ht: fix freeze with legacy hardware
From: Felix Fietkau @ 2010-07-14 21:50 UTC (permalink / raw)
To: Christian Lamparter; +Cc: linux-wireless, John W Linville
In-Reply-To: <201007142343.33937.chunkeey@googlemail.com>
On 2010-07-14 11:43 PM, Christian Lamparter wrote:
> Ever since minstrel_ht was prompted to be the default RC,
> I had an this odd freeze in ieee80211_tx_status,
> whenever I tried to connect my p54*(legacy 11abg) to
> a 802.11n network.
>
> Apparently, minstrel_ht was not interested if the hardware
> supported 802.11n or not?
>
> Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
> ---
> Note: There's another possible way to fix this.
> We can simply AND sta's ht_supported bool with
> the setting in sband's ht_supported.
>
> The advantage is that we won't need this patch
> and the procedure would "match" to what we did
> with the ht_cap flags.
>
> This is up for debate... But in the meantime,
> here's a fix.
>
> P.S.: is there a valid operation situation
> where sta is be NULL, but priv_sta isn't?
Either of those two options is OK with me. I would prefer masking it in
mac80211 though, since the sta ht setting are already partially masked
by hw capabilities.
- Felix
^ permalink raw reply
* [PATCH] minstrel_ht: fix freeze with legacy hardware
From: Christian Lamparter @ 2010-07-14 21:43 UTC (permalink / raw)
To: linux-wireless; +Cc: John W Linville, Felix Fietkau
Ever since minstrel_ht was prompted to be the default RC,
I had an this odd freeze in ieee80211_tx_status,
whenever I tried to connect my p54*(legacy 11abg) to
a 802.11n network.
Apparently, minstrel_ht was not interested if the hardware
supported 802.11n or not?
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
---
Note: There's another possible way to fix this.
We can simply AND sta's ht_supported bool with
the setting in sband's ht_supported.
The advantage is that we won't need this patch
and the procedure would "match" to what we did
with the ht_cap flags.
This is up for debate... But in the meantime,
here's a fix.
P.S.: is there a valid operation situation
where sta is be NULL, but priv_sta isn't?
---
diff --git a/net/mac80211/rc80211_minstrel_ht.c b/net/mac80211/rc80211_minstrel_ht.c
index b5ace24..8ad3630 100644
--- a/net/mac80211/rc80211_minstrel_ht.c
+++ b/net/mac80211/rc80211_minstrel_ht.c
@@ -635,8 +635,12 @@ minstrel_ht_update_caps(void *priv, struct ieee80211_supported_band *sband,
int stbc;
int i;
- /* fall back to the old minstrel for legacy stations */
- if (sta && !sta->ht_cap.ht_supported) {
+ /*
+ * fall back to the old minstrel for legacy stations,
+ * or on legacy hardware.
+ */
+ if ((sta && !sta->ht_cap.ht_supported) ||
+ !sband->ht_cap.ht_supported) {
msp->is_ht = false;
memset(&msp->legacy, 0, sizeof(msp->legacy));
msp->legacy.r = msp->ratelist;
^ permalink raw reply related
* Re: [PATCH] compat-wireless: backport threaded-irq for rt2x00
From: Luis R. Rodriguez @ 2010-07-14 21:41 UTC (permalink / raw)
To: Hauke Mehrtens; +Cc: linux-wireless, mcgrof, philipp_subx
In-Reply-To: <1279140598-6509-1-git-send-email-hauke@hauke-m.de>
On Wed, Jul 14, 2010 at 1:49 PM, Hauke Mehrtens <hauke@hauke-m.de> wrote:
> This backport was done like for the b43 driver. This was just build tested.
>
> Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Thanks!!! Applied
Luis
^ permalink raw reply
* Re: Rate control & USB
From: Ivo Van Doorn @ 2010-07-14 21:36 UTC (permalink / raw)
To: Julian Calaby; +Cc: Helmut Schaa, linux-wireless, Johannes Berg, Felix Fietkau
In-Reply-To: <AANLkTilWtwXuJ8ZA_QHDGURnbTOwlJXivBewSvAr4ncj@mail.gmail.com>
On Wed, Jul 14, 2010 at 3:53 AM, Julian Calaby <julian.calaby@gmail.com> wrote:
> On Wed, Jul 14, 2010 at 05:51, Ivo Van Doorn <ivdoorn@gmail.com> wrote:
>> On Tue, Jul 13, 2010 at 9:15 PM, Helmut Schaa
>> <helmut.schaa@googlemail.com> wrote:
>>> Am Dienstag 13 Juli 2010 schrieb Ivo Van Doorn:
>>>> On Mon, Jul 12, 2010 at 9:14 PM, Helmut Schaa
>>>> <helmut.schaa@googlemail.com> wrote:
>>>> > Am Montag 12 Juli 2010 schrieb Ivo Van Doorn:
>>>> >> I am currently looking into the old problem of the mac80211 rate
>>>> >> control algorithms
>>>> >> and USB devices. The Ralink USB devices (and as far as I know, the
>>>> >> other USB devices
>>>> >> as well), do not work well with the PID and Minstrel algorithms. This
>>>> >> is caused by the
>>>> >> fact that USB devices do not report the TX status to mac80211.
>>>> >
>>>> > Ivo, do you know by any chance if the USB devices also have a TX_STA_FIFO
>>>> > register like the PCI variants? Does it contain useful data or just crap?
>>>>
>>>> Well I guess he has the registers (we don't have rt2870 specific specsheets,
>>>> but the register definitions from the original Ralink driver to
>>>> suggest the register
>>>> is there). However, even if it contains valid data, how do you want to match
>>>> the contents of that register with the sent frames in the queue?
>>>
>>> We could stuff a unique packet ID into the TXWI and the TX_STA_FIFO should
>>> contain the same ID alongside the TX status after the frame was processed
>>> by the hw.
>>
>> True, but we would have the same problem in rt2800pci, that the number
>> of bits is too limited to completely identify a queue + queue index correctly.
>
> We could have a table that matches queue and queue index to the
> packet's ID. So if we're sending packet #47 from queue #1, and it gets
> assigned id #9, then we drop that information into the table - so when
> the hardware tells us the status of packet id #9 we can look up which
> queue it is and send it to the right place.
True, but the overhead of having that lookup table is not really worth
it I believe.
This solution depends on the number of bits available, thus it works
only for rt2800usb,
while with a different RC method I am looking for a more generic solution.
> Of course, this means storing a stack of extra data in system memory,
> as well as having the complexity of looking up the queue data when we
> get the status back, but if we've only got limited bits, then that'll
> set a hard limit on the amount of data and time to retrieve, and we
> may not even need all of it unless the hardware's running at full
> capacity. We could reduce it further if we don't need a status of
> *every* packet - we could potentially get away with only storing data
> for, let's say, every fourth packet or something.
Well it should be up to the RC algorithm to indicate for which frames
it at least demands a TX status and for which frames it is less important.
> As we're likely to see similarly crippled devices elsewhere, maybe we
> could incorporate this type of accounting into mac80211 somewhere.
That really depends on which devices actually have the TX status reporting
registers without any mapping to a real packet. I think there are more devices
without TX status reporting and without TX status registers, than those with the
TX status registers.
Ivo
^ permalink raw reply
* [PATCH] compat-wireless: backport threaded-irq for rt2x00
From: Hauke Mehrtens @ 2010-07-14 20:49 UTC (permalink / raw)
To: lrodriguez; +Cc: linux-wireless, mcgrof, philipp_subx, Hauke Mehrtens
This backport was done like for the b43 driver. This was just build tested.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
---
patches/09-threaded-irq.patch | 55 +++++++++++++++++++++++++++++++++++++++++
1 files changed, 55 insertions(+), 0 deletions(-)
diff --git a/patches/09-threaded-irq.patch b/patches/09-threaded-irq.patch
index c1a33e1..cdc506d 100644
--- a/patches/09-threaded-irq.patch
+++ b/patches/09-threaded-irq.patch
@@ -61,3 +61,58 @@ thread in process context as well.
};
/* Data structure for the WLAN parts (802.11 cores) of the b43 chip. */
+--- a/drivers/net/wireless/rt2x00/rt2x00.h
++++ b/drivers/net/wireless/rt2x00/rt2x00.h
+@@ -882,6 +882,9 @@ struct rt2x00_dev {
+ * and interrupt thread routine.
+ */
+ u32 irqvalue[2];
++#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,31)
++ struct compat_threaded_irq irq_compat;
++#endif
+ };
+
+ /*
+--- a/drivers/net/wireless/rt2x00/rt2x00pci.c
++++ b/drivers/net/wireless/rt2x00/rt2x00pci.c
+@@ -153,10 +153,18 @@ int rt2x00pci_initialize(struct rt2x00_d
+ /*
+ * Register interrupt handler.
+ */
++#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,31)
++ status = compat_request_threaded_irq(&rt2x00dev->irq_compat,
++ rt2x00dev->irq,
++ rt2x00dev->ops->lib->irq_handler,
++ rt2x00dev->ops->lib->irq_handler_thread,
++ IRQF_SHARED, rt2x00dev->name, rt2x00dev);
++#else
+ status = request_threaded_irq(rt2x00dev->irq,
+ rt2x00dev->ops->lib->irq_handler,
+ rt2x00dev->ops->lib->irq_handler_thread,
+ IRQF_SHARED, rt2x00dev->name, rt2x00dev);
++#endif
+ if (status) {
+ ERROR(rt2x00dev, "IRQ %d allocation failed (error %d).\n",
+ rt2x00dev->irq, status);
+@@ -180,7 +188,11 @@ void rt2x00pci_uninitialize(struct rt2x0
+ /*
+ * Free irq line.
+ */
++#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,31)
++ compat_free_threaded_irq(&rt2x00dev->irq_compat);
++#else
+ free_irq(rt2x00dev->irq, rt2x00dev);
++#endif
+
+ /*
+ * Free DMA
+@@ -195,6 +207,9 @@ EXPORT_SYMBOL_GPL(rt2x00pci_uninitialize
+ */
+ static void rt2x00pci_free_reg(struct rt2x00_dev *rt2x00dev)
+ {
++#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,31)
++ compat_destroy_threaded_irq(&rt2x00dev->irq_compat);
++#endif
+ kfree(rt2x00dev->rf);
+ rt2x00dev->rf = NULL;
+
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH] compat-wireless: fix build of ath5k for CONFIG_PM_SLEEP=n
From: Luis R. Rodriguez @ 2010-07-14 20:32 UTC (permalink / raw)
To: Philip A. Prindeville
Cc: Luis Rodriguez, Hauke Mehrtens, linux-wireless@vger.kernel.org,
mcgrof@infradead.org
In-Reply-To: <4C3E1315.5050607@redfish-solutions.com>
On Wed, Jul 14, 2010 at 12:42:13PM -0700, Philip A. Prindeville wrote:
> On 07/14/2010 12:33 PM, Luis R. Rodriguez wrote:
> > On Wed, Jul 14, 2010 at 11:11 AM, Philip A. Prindeville
> > <philipp_subx@redfish-solutions.com> wrote:
> >> On 07/13/2010 04:44 PM, Luis R. Rodriguez wrote:
> >>> On Tue, Jul 13, 2010 at 2:54 PM, Luis R. Rodriguez
> >>> <lrodriguez@atheros.com> wrote:
> >>>> On Mon, Jul 12, 2010 at 12:19 PM, Philip A. Prindeville
> >>>> <philipp_subx@redfish-solutions.com> wrote:
> >>>>> On 07/12/2010 09:30 AM, Luis R. Rodriguez wrote:
> >>>>>> On Sun, Jul 11, 2010 at 1:23 PM, Hauke Mehrtens <hauke@hauke-m.de> wrote:
> >>>>>>> suspend and resume are activated in ath5k if CONFIG_PM_SLEEP is set and
> >>>>>>> not if just CONFIG_PM is set.
> >>>>>>>
> >>>>>>> This should fix the problems reported by Philip Prindeville.
> >>>>>>>
> >>>>>>> Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
> >>>>>>
> >>>>>> Thanks! Applied and pushed out, at noon we'll have a new tarball with this.
> >>>>>>
> >>>>>> Luis
> >>>>>
> >>>>> And...
> >>>>>
> >>>>>
> >>>>> CC [M] /home/philipp/kernel/build_i586/compat-wireless-2010-07-12/net/bluetooth/l2cap.o
> >>>>> /home/philipp/kernel/build_i586/compat-wireless-2010-07-12/net/bluetooth/l2cap.c: In function 'l2cap_data_channel':
> >>>>> /home/philipp/kernel/build_i586/compat-wireless-2010-07-12/net/bluetooth/l2cap.c:4352: error: void value not ignored as it ought to be
> >>>>> make[4]: *** [/home/philipp/kernel/build_i586/compat-wireless-2010-07-12/net/bluetooth/l2cap.o] Error 1
> >>>>> make[3]: *** [/home/philipp/kernel/build_i586/compat-wireless-2010-07-12/net/bluetooth] Error 2
> >>>>> make[2]: *** [_module_/home/philipp/kernel/build_i586/compat-wireless-2010-07-12] Error 2
> >>>>> make[2]: Leaving directory `/home/philipp/kernel/build_i586/linux-2.6.27.48-astlinux'
> >>>>> make[1]: *** [modules] Error 2
> >>>>> make[1]: Leaving directory `/home/philipp/kernel/build_i586/compat-wireless-2010-07-12'
> >>>>> make: *** [/home/philipp/kernel/build_i586/compat-wireless-2010-07-12/net/wireless/lib80211.ko] Error 2
> >>>>
> >>>> Thanks for reporting this, I am working on it now.
> >>>
> >>> This is now fixed, I'll push out a new tarball shortly.
> >>>
> >>> Luis
> >>
> >> That tarball never made it out... can you please retry?
> >
> > The cronjob kicks off at noon PST time.
> >
> > Luis
>
> Just picked up the tarball:
>
> /home/philipp/kernel/build_i586/compat-wireless-2010-07-14/drivers/net/wireless/rt2x00/rt2x00pci.c: In function 'rt2x00pci_initialize':
> /home/philipp/kernel/build_i586/compat-wireless-2010-07-14/drivers/net/wireless/rt2x00/rt2x00pci.c:156: error: implicit declaration of function 'request_threaded_irq'
> make[5]: *** [/home/philipp/kernel/build_i586/compat-wireless-2010-07-14/drivers/net/wireless/rt2x00/rt2x00pci.o] Error 1
> make[4]: *** [/home/philipp/kernel/build_i586/compat-wireless-2010-07-14/drivers/net/wireless/rt2x00] Error 2
> make[4]: *** Waiting for unfinished jobs....
>
>
> I'm thinking that it might be good to have a variety of nightly builds to detect damage. Do you all have infrastructure for that?
Yeah, feel free to send patches against this to enable that:
git://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/compat-user.git
Otherwise I'll get to it when I can.
> This is building against 2.6.27.48
Hauke pointed out threaded ISR stuff needs to be done as was done with b43.
Luis
^ permalink raw reply
* Re: [PATCH] compat-wireless: fix build of ath5k for CONFIG_PM_SLEEP=n
From: Philip A. Prindeville @ 2010-07-14 19:42 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: Hauke Mehrtens, linux-wireless, mcgrof
In-Reply-To: <AANLkTikzEMY_Ya_QY7XkaNv441YxBcJngEoBYJUYJUA1@mail.gmail.com>
On 07/14/2010 12:33 PM, Luis R. Rodriguez wrote:
> On Wed, Jul 14, 2010 at 11:11 AM, Philip A. Prindeville
> <philipp_subx@redfish-solutions.com> wrote:
>> On 07/13/2010 04:44 PM, Luis R. Rodriguez wrote:
>>> On Tue, Jul 13, 2010 at 2:54 PM, Luis R. Rodriguez
>>> <lrodriguez@atheros.com> wrote:
>>>> On Mon, Jul 12, 2010 at 12:19 PM, Philip A. Prindeville
>>>> <philipp_subx@redfish-solutions.com> wrote:
>>>>> On 07/12/2010 09:30 AM, Luis R. Rodriguez wrote:
>>>>>> On Sun, Jul 11, 2010 at 1:23 PM, Hauke Mehrtens <hauke@hauke-m.de> wrote:
>>>>>>> suspend and resume are activated in ath5k if CONFIG_PM_SLEEP is set and
>>>>>>> not if just CONFIG_PM is set.
>>>>>>>
>>>>>>> This should fix the problems reported by Philip Prindeville.
>>>>>>>
>>>>>>> Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
>>>>>>
>>>>>> Thanks! Applied and pushed out, at noon we'll have a new tarball with this.
>>>>>>
>>>>>> Luis
>>>>>
>>>>> And...
>>>>>
>>>>>
>>>>> CC [M] /home/philipp/kernel/build_i586/compat-wireless-2010-07-12/net/bluetooth/l2cap.o
>>>>> /home/philipp/kernel/build_i586/compat-wireless-2010-07-12/net/bluetooth/l2cap.c: In function 'l2cap_data_channel':
>>>>> /home/philipp/kernel/build_i586/compat-wireless-2010-07-12/net/bluetooth/l2cap.c:4352: error: void value not ignored as it ought to be
>>>>> make[4]: *** [/home/philipp/kernel/build_i586/compat-wireless-2010-07-12/net/bluetooth/l2cap.o] Error 1
>>>>> make[3]: *** [/home/philipp/kernel/build_i586/compat-wireless-2010-07-12/net/bluetooth] Error 2
>>>>> make[2]: *** [_module_/home/philipp/kernel/build_i586/compat-wireless-2010-07-12] Error 2
>>>>> make[2]: Leaving directory `/home/philipp/kernel/build_i586/linux-2.6.27.48-astlinux'
>>>>> make[1]: *** [modules] Error 2
>>>>> make[1]: Leaving directory `/home/philipp/kernel/build_i586/compat-wireless-2010-07-12'
>>>>> make: *** [/home/philipp/kernel/build_i586/compat-wireless-2010-07-12/net/wireless/lib80211.ko] Error 2
>>>>
>>>> Thanks for reporting this, I am working on it now.
>>>
>>> This is now fixed, I'll push out a new tarball shortly.
>>>
>>> Luis
>>
>> That tarball never made it out... can you please retry?
>
> The cronjob kicks off at noon PST time.
>
> Luis
Just picked up the tarball:
/home/philipp/kernel/build_i586/compat-wireless-2010-07-14/drivers/net/wireless/rt2x00/rt2x00pci.c: In function 'rt2x00pci_initialize':
/home/philipp/kernel/build_i586/compat-wireless-2010-07-14/drivers/net/wireless/rt2x00/rt2x00pci.c:156: error: implicit declaration of function 'request_threaded_irq'
make[5]: *** [/home/philipp/kernel/build_i586/compat-wireless-2010-07-14/drivers/net/wireless/rt2x00/rt2x00pci.o] Error 1
make[4]: *** [/home/philipp/kernel/build_i586/compat-wireless-2010-07-14/drivers/net/wireless/rt2x00] Error 2
make[4]: *** Waiting for unfinished jobs....
I'm thinking that it might be good to have a variety of nightly builds to detect damage. Do you all have infrastructure for that?
This is building against 2.6.27.48
^ permalink raw reply
* Compat-wireless release for 2010-07-14 is baked
From: Compat-wireless cronjob account @ 2010-07-14 19:03 UTC (permalink / raw)
To: linux-wireless
>From git://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/compat-wireless-2.6
5a1a386..73374eb master -> origin/master
bff9ce9..f88f925 wl -> origin/wl
>From git://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/compat-wireless-2.6
* [new tag] compat-wireless-2010-07-13 -> compat-wireless-2010-07-13
>From git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next
122c2ee..521acd5 history -> origin/history
+ 7e28ebb...c9ce0c0 master -> origin/master (forced update)
* [new tag] next-20100714 -> next-20100714
compat-wireless code metrics
495977 - Total upstream lines of code being pulled
1425 - backport code changes
1191 - backport code additions
234 - backport code deletions
5766 - backport from compat module
7191 - total backport code
1.4499 - % of code consists of backport work
1218 - Crap changes not yet posted
1179 - Crap additions not yet posted
39 - Crap deletions not yet posted
0.2456 - % of crap code
Base tree: linux-next.git
Base tree version: next-20100714
compat-wireless release: compat-wireless-2010-07-13-1-g73374eb
^ permalink raw reply
* Re: [PATCH 1/3] ath9k: implement mac80211 flush op
From: Luis R. Rodriguez @ 2010-07-14 18:36 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Luis R. Rodriguez
In-Reply-To: <1279070845-29442-2-git-send-email-lrodriguez@atheros.com>
On Tue, Jul 13, 2010 at 6:27 PM, Luis R. Rodriguez
<lrodriguez@atheros.com> wrote:
> This implements the mac80211 flush callback to let mac80211
> flush the hardware queues when it deems appropriate.
>
> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
John, sorry, please hold off on this one, I need to do some more tests.
Luis
^ permalink raw reply
* Re: [PATCH] compat-wireless: fix build of ath5k for CONFIG_PM_SLEEP=n
From: Luis R. Rodriguez @ 2010-07-14 18:33 UTC (permalink / raw)
To: Philip A. Prindeville; +Cc: Hauke Mehrtens, linux-wireless, mcgrof
In-Reply-To: <4C3DFDB5.10904@redfish-solutions.com>
On Wed, Jul 14, 2010 at 11:11 AM, Philip A. Prindeville
<philipp_subx@redfish-solutions.com> wrote:
> On 07/13/2010 04:44 PM, Luis R. Rodriguez wrote:
>> On Tue, Jul 13, 2010 at 2:54 PM, Luis R. Rodriguez
>> <lrodriguez@atheros.com> wrote:
>>> On Mon, Jul 12, 2010 at 12:19 PM, Philip A. Prindeville
>>> <philipp_subx@redfish-solutions.com> wrote:
>>>> On 07/12/2010 09:30 AM, Luis R. Rodriguez wrote:
>>>>> On Sun, Jul 11, 2010 at 1:23 PM, Hauke Mehrtens <hauke@hauke-m.de> wrote:
>>>>>> suspend and resume are activated in ath5k if CONFIG_PM_SLEEP is set and
>>>>>> not if just CONFIG_PM is set.
>>>>>>
>>>>>> This should fix the problems reported by Philip Prindeville.
>>>>>>
>>>>>> Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
>>>>>
>>>>> Thanks! Applied and pushed out, at noon we'll have a new tarball with this.
>>>>>
>>>>> Luis
>>>>
>>>> And...
>>>>
>>>>
>>>> CC [M] /home/philipp/kernel/build_i586/compat-wireless-2010-07-12/net/bluetooth/l2cap.o
>>>> /home/philipp/kernel/build_i586/compat-wireless-2010-07-12/net/bluetooth/l2cap.c: In function 'l2cap_data_channel':
>>>> /home/philipp/kernel/build_i586/compat-wireless-2010-07-12/net/bluetooth/l2cap.c:4352: error: void value not ignored as it ought to be
>>>> make[4]: *** [/home/philipp/kernel/build_i586/compat-wireless-2010-07-12/net/bluetooth/l2cap.o] Error 1
>>>> make[3]: *** [/home/philipp/kernel/build_i586/compat-wireless-2010-07-12/net/bluetooth] Error 2
>>>> make[2]: *** [_module_/home/philipp/kernel/build_i586/compat-wireless-2010-07-12] Error 2
>>>> make[2]: Leaving directory `/home/philipp/kernel/build_i586/linux-2.6.27.48-astlinux'
>>>> make[1]: *** [modules] Error 2
>>>> make[1]: Leaving directory `/home/philipp/kernel/build_i586/compat-wireless-2010-07-12'
>>>> make: *** [/home/philipp/kernel/build_i586/compat-wireless-2010-07-12/net/wireless/lib80211.ko] Error 2
>>>
>>> Thanks for reporting this, I am working on it now.
>>
>> This is now fixed, I'll push out a new tarball shortly.
>>
>> Luis
>
> That tarball never made it out... can you please retry?
The cronjob kicks off at noon PST time.
Luis
^ permalink raw reply
* Re: [PATCH] compat-wireless: fix build of ath5k for CONFIG_PM_SLEEP=n
From: Philip A. Prindeville @ 2010-07-14 18:11 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: Hauke Mehrtens, linux-wireless, mcgrof
In-Reply-To: <AANLkTilVf_eOMqvYwcz5XrSVFuk3RNLl7SoVOj-6L6Fu@mail.gmail.com>
On 07/13/2010 04:44 PM, Luis R. Rodriguez wrote:
> On Tue, Jul 13, 2010 at 2:54 PM, Luis R. Rodriguez
> <lrodriguez@atheros.com> wrote:
>> On Mon, Jul 12, 2010 at 12:19 PM, Philip A. Prindeville
>> <philipp_subx@redfish-solutions.com> wrote:
>>> On 07/12/2010 09:30 AM, Luis R. Rodriguez wrote:
>>>> On Sun, Jul 11, 2010 at 1:23 PM, Hauke Mehrtens <hauke@hauke-m.de> wrote:
>>>>> suspend and resume are activated in ath5k if CONFIG_PM_SLEEP is set and
>>>>> not if just CONFIG_PM is set.
>>>>>
>>>>> This should fix the problems reported by Philip Prindeville.
>>>>>
>>>>> Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
>>>>
>>>> Thanks! Applied and pushed out, at noon we'll have a new tarball with this.
>>>>
>>>> Luis
>>>
>>> And...
>>>
>>>
>>> CC [M] /home/philipp/kernel/build_i586/compat-wireless-2010-07-12/net/bluetooth/l2cap.o
>>> /home/philipp/kernel/build_i586/compat-wireless-2010-07-12/net/bluetooth/l2cap.c: In function 'l2cap_data_channel':
>>> /home/philipp/kernel/build_i586/compat-wireless-2010-07-12/net/bluetooth/l2cap.c:4352: error: void value not ignored as it ought to be
>>> make[4]: *** [/home/philipp/kernel/build_i586/compat-wireless-2010-07-12/net/bluetooth/l2cap.o] Error 1
>>> make[3]: *** [/home/philipp/kernel/build_i586/compat-wireless-2010-07-12/net/bluetooth] Error 2
>>> make[2]: *** [_module_/home/philipp/kernel/build_i586/compat-wireless-2010-07-12] Error 2
>>> make[2]: Leaving directory `/home/philipp/kernel/build_i586/linux-2.6.27.48-astlinux'
>>> make[1]: *** [modules] Error 2
>>> make[1]: Leaving directory `/home/philipp/kernel/build_i586/compat-wireless-2010-07-12'
>>> make: *** [/home/philipp/kernel/build_i586/compat-wireless-2010-07-12/net/wireless/lib80211.ko] Error 2
>>
>> Thanks for reporting this, I am working on it now.
>
> This is now fixed, I'll push out a new tarball shortly.
>
> Luis
That tarball never made it out... can you please retry?
Thanks.
^ permalink raw reply
* Re: commit 062bee448bd539580ef9f64efe50fdfe04eeb103 broke my iwlagn 5100
From: Guy, Wey-Yi @ 2010-07-14 17:44 UTC (permalink / raw)
To: Johannes Berg; +Cc: Florian Klink, linux-wireless@vger.kernel.org
In-Reply-To: <1279129005.3723.8.camel@jlt3.sipsolutions.net>
Hi Florian,
On Wed, 2010-07-14 at 10:36 -0700, Johannes Berg wrote:
> On Wed, 2010-07-14 at 10:27 -0700, Guy, Wey-Yi wrote:
> > Johannes,
> >
> > On Wed, 2010-07-14 at 09:36 -0700, Florian Klink wrote:
> > > Hi,
> > >
> > > I did a dmesg with 2.6.35-rc5 and debug=0x43fff.
> > > You can get it here: http://pastebin.com/Q6eCdPZR
> >
> > >
> > >
> > based on the log sent by Florian, I did not see bss_info_change with
> > current BSSID from mac80211. any thought?
> >
> > I am expected to see something like this,
> >
> > [165796.572969] ieee80211 phy3: U iwl_bss_info_changed changes =
> > 0xFD
> > [165796.572972] ieee80211 phy3: U iwl_bss_info_changed BSSID
> > 00:25:9c:d0:9f:e1
> > [165796.572976] ieee80211 phy3: U iwl_bss_info_changed ERP_PREAMBLE 1
>
> That'd only happen _after_ association, not before, and assoc fails
> here.
>
Could you try different channel instead of channel 12 to see if the
problem still there?
Thanks
Wey
>
^ permalink raw reply
* Re: commit 062bee448bd539580ef9f64efe50fdfe04eeb103 broke my iwlagn 5100
From: Johannes Berg @ 2010-07-14 17:36 UTC (permalink / raw)
To: Guy, Wey-Yi; +Cc: Florian Klink, linux-wireless@vger.kernel.org
In-Reply-To: <1279128461.19725.34.camel@wwguy-ubuntu>
On Wed, 2010-07-14 at 10:27 -0700, Guy, Wey-Yi wrote:
> Johannes,
>
> On Wed, 2010-07-14 at 09:36 -0700, Florian Klink wrote:
> > Hi,
> >
> > I did a dmesg with 2.6.35-rc5 and debug=0x43fff.
> > You can get it here: http://pastebin.com/Q6eCdPZR
>
> >
> >
> based on the log sent by Florian, I did not see bss_info_change with
> current BSSID from mac80211. any thought?
>
> I am expected to see something like this,
>
> [165796.572969] ieee80211 phy3: U iwl_bss_info_changed changes =
> 0xFD
> [165796.572972] ieee80211 phy3: U iwl_bss_info_changed BSSID
> 00:25:9c:d0:9f:e1
> [165796.572976] ieee80211 phy3: U iwl_bss_info_changed ERP_PREAMBLE 1
That'd only happen _after_ association, not before, and assoc fails
here.
johannes
^ permalink raw reply
* Re: commit 062bee448bd539580ef9f64efe50fdfe04eeb103 broke my iwlagn 5100
From: Guy, Wey-Yi @ 2010-07-14 17:27 UTC (permalink / raw)
To: Florian Klink; +Cc: Johannes Berg, linux-wireless@vger.kernel.org
In-Reply-To: <2af581f49d0d7786326de05682b92382@imap.flokli.de>
Johannes,
On Wed, 2010-07-14 at 09:36 -0700, Florian Klink wrote:
> Hi,
>
> I did a dmesg with 2.6.35-rc5 and debug=0x43fff.
> You can get it here: http://pastebin.com/Q6eCdPZR
>
>
based on the log sent by Florian, I did not see bss_info_change with
current BSSID from mac80211. any thought?
I am expected to see something like this,
[165796.572969] ieee80211 phy3: U iwl_bss_info_changed changes =
0xFD
[165796.572972] ieee80211 phy3: U iwl_bss_info_changed BSSID
00:25:9c:d0:9f:e1
[165796.572976] ieee80211 phy3: U iwl_bss_info_changed ERP_PREAMBLE 1
Regards
Wey
^ permalink raw reply
* [ANN] iw: v0.9.20
From: wireless @ 2010-07-14 17:04 UTC (permalink / raw)
To: linux-wireless
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1697 bytes --]
A new release of iw (v0.9.20) is available at:
http://wireless.kernel.org/download/iw/iw-0.9.20.tar.bz2
SHA1 sum: 75baf7d5fda2fb4e82c8c979caccc489d0170e45
Here is the short log of the changes included in this
release:
Bruno Randolf (2):
iw: fix makefile for cqm
iw: add channel command name
Christian Lamparter (1):
iw: fix ampdu spacing & max amsdu length reporting
Johannes Berg (19):
update nl80211.h
print unknown commands in supported list with number
add off-channel command
fix scan show_both_ie_sets
update nl80211.h
make commands array easier to handle
update nl80211.h
display unknown WPS TLVs
print max scan IE length
add hex parser util
allow adding IEs to scan
sync nl80211.h from wireless-testing
fix number parsing bugs
update nl80211.h from wireless-testing
allow "link" command to print something for ibss
split out multicast group adding
improve connect vs. notification race behaviour
update nl80211.h
version 0.9.20
Jouni Malinen (2):
iw: Add support for showing Beacon IEs and TIM IE
iw: Parse some common WPS attributes
Juuso Oikarinen (1):
iw: Add support for connection quality monitor configuation
Kalle Valo (1):
iw: add set/get power_save commands
Luciano Coelho (1):
iw: change install command to make it compatible with ancient coreutils
Luis R. Rodriguez (2):
iw: add country IE parsing
iw: fix typo on LDPC capability
Lukáš Turek (1):
iw: Add support for NL80211_ATTR_WIPHY_COVERAGE_CLASS
Teemu Paasikivi (1):
iw: Configure basic rates when joining ibss network
^ permalink raw reply
* Re: commit 062bee448bd539580ef9f64efe50fdfe04eeb103 broke my iwlagn 5100
From: Florian Klink @ 2010-07-14 16:36 UTC (permalink / raw)
To: Guy, Wey-Yi; +Cc: Johannes Berg, linux-wireless, flokli
In-Reply-To: <1279121328.19725.27.camel@wwguy-ubuntu>
Hi,
I did a dmesg with 2.6.35-rc5 and debug=0x43fff.
You can get it here: http://pastebin.com/Q6eCdPZR
Florian
On Wed, 14 Jul 2010 08:28:48 -0700, "Guy, Wey-Yi"
<wey-yi.w.guy@intel.com> wrote:
> Hi Florian,
>
> On Wed, 2010-07-14 at 03:06 -0700, Florian Klink wrote:
>> Thanks ;-)
>>
>> On Wed, 14 Jul 2010 12:00:55 +0200, Johannes Berg
>> <johannes@sipsolutions.net> wrote:
>> > [correct wey-yi's address, remove reinette]
>> >
>> > On Wed, 2010-07-14 at 11:33 +0200, Florian Klink wrote:
>> >> Hi,
>> >>
>> >> I hope I'm writing to the right addresses, this is my first kernel bug
>> >> report :-)
>> >>
>> >> I regulary build linus' tree from git. One day, my wireless card was
>> >> unable to connect to the access point. dmesg showed something like this:
>> >>
>> >> [ 122.290949] wlan0: direct probe to 00:15:0c:xx:xx:xx (try 1)
>> >> [ 122.490158] wlan0: direct probe to 00:15:0c:xx:xx:xx (try 2)
>> >> [ 122.690057] wlan0: direct probe to 00:15:0c:xx:xx:xx (try 3)
>> >> [ 122.890031] wlan0: direct probe to 00:15:0c:xx:xx:xx timed out
>> >>
>> >> At first, I thought is was some link quality problem and tried it next
>> >> to the access point, but it still didn't work.
>> >> I booted another (older) kernel and with this one, the card was able to
>> >> connect without any problems.
>> >>
>> >> I bisected the problem and came to commit
>> >> 062bee448bd539580ef9f64efe50fdfe04eeb103
>> >> iwlwifi: set TX_CMD_FLAG_PROT_REQUIRE_MSK in tx_flag
>> >> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=062bee448bd539580ef9f64efe50fdfe04eeb103
>> >>
>> >> My wireless card is a Intel Corporation Wireless WiFi Link 5100.
>> >>
>> >> Will provide more info if needed.
>> >>
> Could you please load the iwlagn module with module parameter
> debug=0x43fff and forward us the dmesg log
>
> Thanks
> Wey
>>
^ permalink raw reply
* Re: [PATCH 2/3] ath9k_htc: implement mac80211 flush op
From: Luis R. Rodriguez @ 2010-07-14 15:37 UTC (permalink / raw)
To: Sujith; +Cc: linville@tuxdriver.com, linux-wireless@vger.kernel.org
In-Reply-To: <19517.12171.792656.215696@gargle.gargle.HOWL>
On Tue, Jul 13, 2010 at 8:31 PM, Sujith <Sujith.Manoharan@atheros.com> wrote:
> Luis R. Rodriguez wrote:
>> This implements the mac80211 flush callback to let mac80211
>> flush the hardware queues when it deems appropriate.
>>
>> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
>> ---
>> drivers/net/wireless/ath/ath9k/htc_drv_main.c | 24 ++++++++++++++++++++++++
>> 1 files changed, 24 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_main.c b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
>> index e38ca66..fc234a7 100644
>> --- a/drivers/net/wireless/ath/ath9k/htc_drv_main.c
>> +++ b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
>> @@ -1803,6 +1803,29 @@ static void ath9k_htc_set_coverage_class(struct ieee80211_hw *hw,
>> mutex_unlock(&priv->mutex);
>> }
>>
>> +static void ath9k_htc_flush(struct ieee80211_hw *hw, bool drop)
>> +{
>> + struct ath9k_htc_priv *priv = hw->priv;
>> + u8 cmd_rsp;
>> + int ret;
>> +
>> + mutex_lock(&priv->mutex);
>> +
>> + if (priv->op_flags & OP_INVALID)
>> + goto err;
>> +
>> + ath9k_htc_ps_wakeup(priv);
>> +
>> + WMI_CMD(WMI_DRAIN_TXQ_ALL_CMDID);
>> + if (drop)
>> + skb_queue_purge(&priv->tx_queue);
>> +
>> + ath9k_htc_ps_restore(priv);
>> +
>> +err:
>> + mutex_unlock(&priv->mutex);
>> +}
>> +
>
> I don't think this would work.
>
> Queuing of packets is done in the HIF (USB) layer.
> Flushing would require dropping (or not) the buffered packets in the
> USB layer.
Ah yes, good point, but I don't see us doing an HIF flush prior to
scan either. Even in the cas where we can rm -rf everything I don't
see us doing an HIF flush, for example device stop, or as you noted
ath9k_htc_radio_disable().
> Also, we don't actually require this, since IDLE state
> is handled in radio_disable(), where everything is flushed properly ...
flush() is for other uses, like prior to scanning, it would mean we
can remove some code from where we do flushes as mac80211 would do
that for us in proper places. It also means we can address flushing
within mac80211 instead of the core driver, and we'd do it in one
place, mac80211 instead of drivers.
Luis
^ permalink raw reply
* ubuntu 9.04 WLAN no
From: Arne Bahr @ 2010-07-14 15:31 UTC (permalink / raw)
To: linux-wireless
Hi,
I have a problem with my Laptop Samsung x10:
WLAN card: IEEE 802.11b
my Laptop allways says: no IP-Adress obtained
I´m pretty new with Linux and need help. All drivers are known.
Arne
--
GMX DSL: Internet-, Telefon- und Handy-Flat ab 19,99 EUR/mtl.
Bis zu 150 EUR Startguthaben inklusive! http://portal.gmx.net/de/go/dsl
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox