* Re: iwlagn and many firmware restarts with Fedora kernel
From: drago01 @ 2010-07-19 22:33 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: linux-wireless
In-Reply-To: <1279565034.4572.36.camel@localhost.localdomain>
On Mon, Jul 19, 2010 at 8:43 PM, Marcel Holtmann <marcel@holtmann.org> wrote:
> Hi,
>
> so during the last few weeks, I have seen a huge amount of firmware
> restarts with my Intel 5350 card and Fedora 13 kernel (2.6.33.6-147).
>
> iwlagn 0000:03:00.0: low ack count detected, restart firmware
> iwlagn 0000:03:00.0: On demand firmware reload
> iwlagn 0000:03:00.0: Stopping AGG while state not ON or starting
> iwlagn 0000:03:00.0: queue number out of range: 0, must be 10 to 19
>
> If this happens then I don't see it once, I normally see this 10-20
> times and the connectivity is stalled until the cards comes back to
> life. I have seen patches that should have fixed this symptom, but they
> might be also send to -stable since this is a major hassle.
>
> The time without connectivity is something around 4-5 minutes or longer
> when this happens. Not really funny.
This happens here too even with the 2.6.34.1-9.fc13.x86_64 kernel;
when this happens reloading the iwlagn module seems to be the only
(quick) way to get it back to life.
^ permalink raw reply
* RE: iwlagn and many firmware restarts with Fedora kernel
From: Marcel Holtmann @ 2010-07-19 23:28 UTC (permalink / raw)
To: Guy, Wey-Yi W; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <E9954878DD1FB34FAE5187FB88C58A350120692494@orsmsx506.amr.corp.intel.com>
Hi Wey,
> so during the last few weeks, I have seen a huge amount of firmware
> restarts with my Intel 5350 card and Fedora 13 kernel (2.6.33.6-147).
>
> iwlagn 0000:03:00.0: low ack count detected, restart firmware
> iwlagn 0000:03:00.0: On demand firmware reload
> iwlagn 0000:03:00.0: Stopping AGG while state not ON or starting
> iwlagn 0000:03:00.0: queue number out of range: 0, must be 10 to 19
>
> If this happens then I don't see it once, I normally see this 10-20
> times and the connectivity is stalled until the cards comes back to
> life. I have seen patches that should have fixed this symptom, but they
> might be also send to -stable since this is a major hassle.
>
> The time without connectivity is something around 4-5 minutes or longer
> when this happens. Not really funny.
>
> Which patch you referring to? I will try to work on submit it to stable.
no patch in particular, I just have seen some commit messages that would
be indicating this got fixed.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH] cfg80211: fix WEXT ioctl GIWFREQ for monitor interfaces
From: David Gnedt @ 2010-07-19 23:28 UTC (permalink / raw)
To: Gábor Stefanik; +Cc: linux-wireless, John W. Linville, Johannes Berg
In-Reply-To: <AANLkTimxBt7dPcZrmAihWq9UKs77qS0cnAxQXIY_55ci@mail.gmail.com>
Am 2010-07-19 23:06, schrieb Gábor Stefanik:
> (BTW, I say that a GIWFREQ on a monitor interface should always return
> the channel the PHY is tuned to at the moment when it is issued. Most
> tools seem to expect this behavior.)
I agree, that would be the expected behaviour.
I am not very familar with the entire wireless subsystem yet, but wouldn't that
imply a interface change in cfg80211 and mac80211 to add an "get_channel" function?
Because if the card is hopping channels (e.g. because of 2 station interfaces on
different channels), only the driver itself can tell what's really the current
channel.
Nevertheless a default implementation for this new "get_channel" can be written
at mac80211 level (or even cfg80211?), which tries to find the current channel
by looking at all virtual interfaces, so only mac80211 drivers which allow
multiple channels (and non-mac80211 drivers) need to implement it.
Regards,
David
^ permalink raw reply
* Re: iwlagn and many firmware restarts with Fedora kernel
From: Marcel Holtmann @ 2010-07-19 23:29 UTC (permalink / raw)
To: drago01; +Cc: linux-wireless
In-Reply-To: <AANLkTinGUQjPoMRmt_jeFgpxLhzma7qhfR14t_tWLvO1@mail.gmail.com>
Hi,
> > so during the last few weeks, I have seen a huge amount of firmware
> > restarts with my Intel 5350 card and Fedora 13 kernel (2.6.33.6-147).
> >
> > iwlagn 0000:03:00.0: low ack count detected, restart firmware
> > iwlagn 0000:03:00.0: On demand firmware reload
> > iwlagn 0000:03:00.0: Stopping AGG while state not ON or starting
> > iwlagn 0000:03:00.0: queue number out of range: 0, must be 10 to 19
> >
> > If this happens then I don't see it once, I normally see this 10-20
> > times and the connectivity is stalled until the cards comes back to
> > life. I have seen patches that should have fixed this symptom, but they
> > might be also send to -stable since this is a major hassle.
> >
> > The time without connectivity is something around 4-5 minutes or longer
> > when this happens. Not really funny.
>
> This happens here too even with the 2.6.34.1-9.fc13.x86_64 kernel;
> when this happens reloading the iwlagn module seems to be the only
> (quick) way to get it back to life.
the quick way is re-loading the module, that is true. Otherwise you have
to sit it out. It always comes back nicely and starts working again.
Regards
Marcel
^ permalink raw reply
* Re: iwlagn and many firmware restarts with Fedora kernel
From: Guy, Wey-Yi @ 2010-07-19 23:56 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: drago01, linux-wireless@vger.kernel.org
In-Reply-To: <1279582174.4572.43.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 1366 bytes --]
Hi drago,
On Mon, 2010-07-19 at 16:29 -0700, Marcel Holtmann wrote:
> Hi,
>
> > > so during the last few weeks, I have seen a huge amount of firmware
> > > restarts with my Intel 5350 card and Fedora 13 kernel (2.6.33.6-147).
> > >
> > > iwlagn 0000:03:00.0: low ack count detected, restart firmware
> > > iwlagn 0000:03:00.0: On demand firmware reload
> > > iwlagn 0000:03:00.0: Stopping AGG while state not ON or starting
> > > iwlagn 0000:03:00.0: queue number out of range: 0, must be 10 to 19
> > >
> > > If this happens then I don't see it once, I normally see this 10-20
> > > times and the connectivity is stalled until the cards comes back to
> > > life. I have seen patches that should have fixed this symptom, but they
> > > might be also send to -stable since this is a major hassle.
> > >
> > > The time without connectivity is something around 4-5 minutes or longer
> > > when this happens. Not really funny.
> >
> > This happens here too even with the 2.6.34.1-9.fc13.x86_64 kernel;
> > when this happens reloading the iwlagn module seems to be the only
> > (quick) way to get it back to life.
>
> the quick way is re-loading the module, that is true. Otherwise you have
> to sit it out. It always comes back nicely and starts working again.
>
Are you using 5350? here I attach a "RFC patch", could you give a try to
see if it help?
Regards
Wey
[-- Attachment #2: 0001-iwlwifi-extend-the-stuck-queue-monitor-timer-for-53.patch --]
[-- Type: text/x-patch, Size: 1715 bytes --]
>From d399851898df57fc03d513c2a336d3f3745b0d10 Mon Sep 17 00:00:00 2001
From: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Date: Mon, 19 Jul 2010 16:38:19 -0700
Subject: [PATCH 1/1] iwlwifi: extend the stuck queue monitor timer for 5350 device
Different hardware has differnet behavior, extend the monitor period
timer from 1 second to 5 seconds to avoid the un-necessary firmware reload
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
---
drivers/net/wireless/iwlwifi/iwl-5000.c | 2 +-
drivers/net/wireless/iwlwifi/iwl-dev.h | 1 +
2 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-5000.c b/drivers/net/wireless/iwlwifi/iwl-5000.c
index 68e282b..4325a53 100644
--- a/drivers/net/wireless/iwlwifi/iwl-5000.c
+++ b/drivers/net/wireless/iwlwifi/iwl-5000.c
@@ -642,7 +642,7 @@ struct iwl_cfg iwl5350_agn_cfg = {
.chain_noise_num_beacons = IWL_CAL_NUM_BEACONS,
.plcp_delta_threshold = IWL_MAX_PLCP_ERR_LONG_THRESHOLD_DEF,
.chain_noise_scale = 1000,
- .monitor_recover_period = IWL_MONITORING_PERIOD,
+ .monitor_recover_period = IWL_LONG_MONITORING_PERIOD,
.max_event_log_size = 512,
.ucode_tracing = true,
.sensitivity_calib_by_driver = true,
diff --git a/drivers/net/wireless/iwlwifi/iwl-dev.h b/drivers/net/wireless/iwlwifi/iwl-dev.h
index 30853c8..d439b80 100644
--- a/drivers/net/wireless/iwlwifi/iwl-dev.h
+++ b/drivers/net/wireless/iwlwifi/iwl-dev.h
@@ -1051,6 +1051,7 @@ struct iwl_event_log {
/* timer constants use to monitor and recover stuck tx queues in mSecs */
#define IWL_MONITORING_PERIOD (1000)
+#define IWL_LONG_MONITORING_PERIOD (5000)
#define IWL_ONE_HUNDRED_MSECS (100)
#define IWL_SIXTY_SECS (60000)
--
1.5.6.3
^ permalink raw reply related
* Re: [PATCH/RFC 1/3] ath5k: log descriptor chains at a new debug level
From: Bruno Randolf @ 2010-07-20 5:01 UTC (permalink / raw)
To: Bob Copeland; +Cc: linux-wireless, ath5k-devel
In-Reply-To: <1279395336-856-2-git-send-email-me@bobcopeland.com>
On Sun July 18 2010 04:35:34 Bob Copeland wrote:
> Descriptors are currently logged with ATH5K_DEBUG_RESET,
> which isn't really apt, and also means we can't see just
> the descriptor setup or just the resets. Add a new
> debug level just for that.
>
> Signed-off-by: Bob Copeland <me@bobcopeland.com>
> ---
> drivers/net/wireless/ath/ath5k/debug.c | 5 +++--
> drivers/net/wireless/ath/ath5k/debug.h | 2 ++
> 2 files changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath5k/debug.c
> b/drivers/net/wireless/ath/ath5k/debug.c index ebb9c23..2222022 100644
> --- a/drivers/net/wireless/ath/ath5k/debug.c
> +++ b/drivers/net/wireless/ath/ath5k/debug.c
> @@ -309,6 +309,7 @@ static const struct {
> { ATH5K_DEBUG_DUMP_TX, "dumptx", "print transmit skb content" },
> { ATH5K_DEBUG_DUMPBANDS, "dumpbands", "dump bands" },
> { ATH5K_DEBUG_ANI, "ani", "adaptive noise immunity" },
> + { ATH5K_DEBUG_DESC, "desc", "descriptor chains" },
> { ATH5K_DEBUG_ANY, "all", "show all debug levels" },
> };
>
> @@ -937,7 +938,7 @@ ath5k_debug_printrxbuffs(struct ath5k_softc *sc, struct
> ath5k_hw *ah) struct ath5k_rx_status rs = {};
> int status;
>
> - if (likely(!(sc->debug.level & ATH5K_DEBUG_RESET)))
> + if (likely(!(sc->debug.level & ATH5K_DEBUG_DESC)))
> return;
>
> printk(KERN_DEBUG "rxdp %x, rxlink %p\n",
> @@ -979,7 +980,7 @@ ath5k_debug_printtxbuf(struct ath5k_softc *sc, struct
> ath5k_buf *bf) struct ath5k_tx_status ts = {};
> int done;
>
> - if (likely(!(sc->debug.level & ATH5K_DEBUG_RESET)))
> + if (likely(!(sc->debug.level & ATH5K_DEBUG_DESC)))
> return;
>
> done = sc->ah->ah_proc_tx_desc(sc->ah, bf->desc, &ts);
> diff --git a/drivers/net/wireless/ath/ath5k/debug.h
> b/drivers/net/wireless/ath/ath5k/debug.h index 606ae94..9b22722 100644
> --- a/drivers/net/wireless/ath/ath5k/debug.h
> +++ b/drivers/net/wireless/ath/ath5k/debug.h
> @@ -95,6 +95,7 @@ struct ath5k_dbg_info {
> * @ATH5K_DEBUG_DUMP_TX: print transmit skb content
> * @ATH5K_DEBUG_DUMPBANDS: dump bands
> * @ATH5K_DEBUG_TRACE: trace function calls
> + * @ATH5K_DEBUG_DESC: descriptor setup
> * @ATH5K_DEBUG_ANY: show at any debug level
> *
> * The debug level is used to control the amount and type of debugging
> output @@ -117,6 +118,7 @@ enum ath5k_debug_level {
> ATH5K_DEBUG_DUMP_TX = 0x00000200,
> ATH5K_DEBUG_DUMPBANDS = 0x00000400,
> ATH5K_DEBUG_ANI = 0x00002000,
> + ATH5K_DEBUG_DESC = 0x00004000,
> ATH5K_DEBUG_ANY = 0xffffffff
> };
Acked-by: Bruno Randolf <br1@einfach.org>
^ permalink raw reply
* Re: [ath5k-devel] [PATCH/RFC 0/3] ath5k: add driver tracepoints
From: Bruno Randolf @ 2010-07-20 5:11 UTC (permalink / raw)
To: ath5k-devel; +Cc: Bob Copeland, linux-wireless
In-Reply-To: <1279395336-856-1-git-send-email-me@bobcopeland.com>
On Sun July 18 2010 04:35:33 Bob Copeland wrote:
> This series adds some tracepoints for reset and tx/rx, with an
> eye toward replacing some of the debug printks we have today.
> Stolen form iwlwifi is the idea of logging entire packets so
> we can generate pcap files from the traces, via something like:
>
> $ mkdir -p ~/.trace-cmd/plugins
> $ cd ~/.trace-cmd/plugins
> $ wget 'http://bobcopeland.com/srcs/ath5k_trace.py'
> $ trace-cmd record -e mac80211 -e ath5k sleep 500
> $ trace-cmd report | less
> $ wireshark /tmp/pcap.out
>
> I quite like the result, but I'd be interested to hear others'
> opinions on the approach. Right now I think these tracepoints
> will be useful in seeing causes of excessive resets, and debugging
> queue hangs.
hmm, this is really nice stuff, but i'm not sure what to do on embedded boards
where we don't have python or where it's not possible to use tracing in
general due to (low) performance reasons. in these cases the kernel printks
are just so much more easy to use... i would actually prefer to keep them...
additionally to the new tracing you made, maybe? otoh we could probably get
tracing enabled on all boards if we really need it, it's just some extra
work...
bruno
^ permalink raw reply
* Re: [PATCH/RFC 3/3] ath5k: trace resets
From: Bruno Randolf @ 2010-07-20 5:20 UTC (permalink / raw)
To: Bob Copeland; +Cc: linux-wireless, ath5k-devel
In-Reply-To: <1279395336-856-4-git-send-email-me@bobcopeland.com>
On Sun July 18 2010 04:35:36 Bob Copeland wrote:
> This change adds a tracepoint for ath5k_reset. We record the
> reason for each reset and the new channel frequency.
>
> Signed-off-by: Bob Copeland <me@bobcopeland.com>
> ---
> drivers/net/wireless/ath/ath5k/ath5k_trace.h | 38 +++++++++++++++++
> drivers/net/wireless/ath/ath5k/base.c | 56
> +++++++------------------- drivers/net/wireless/ath/ath5k/base.h |
> 12 ++++++
> drivers/net/wireless/ath/ath5k/debug.c | 7 ++-
> drivers/net/wireless/ath/ath5k/debug.h | 2 -
> 5 files changed, 70 insertions(+), 45 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath5k/ath5k_trace.h
> b/drivers/net/wireless/ath/ath5k/ath5k_trace.h index 00d9773..3a5112d
> 100644
> --- a/drivers/net/wireless/ath/ath5k/ath5k_trace.h
> +++ b/drivers/net/wireless/ath/ath5k/ath5k_trace.h
> @@ -12,6 +12,44 @@ struct sk_buff;
> #undef TRACE_SYSTEM
> #define TRACE_SYSTEM ath5k
>
> +TRACE_EVENT(ath5k_reset,
> + TP_PROTO(struct ath5k_softc *priv, struct ieee80211_channel *chan,
> + enum ath5k_reset_reason reason),
> +
> + TP_ARGS(priv, chan, reason),
> + TP_STRUCT__entry(
> + PRIV_ENTRY
> + __field(u32, reason)
> + __field(u16, freq)
> + ),
> + TP_fast_assign(
> + PRIV_ASSIGN;
> + __entry->reason = reason;
> + __entry->freq = chan->center_freq;
> + ),
> + TP_printk(
> + "[%p] reset reason=%d freq=%u", __entry->priv,
> + __entry->reason, __entry->freq
> + )
> +);
> +
> +TRACE_EVENT(ath5k_reset_end,
> + TP_PROTO(struct ath5k_softc *priv, int result),
> +
> + TP_ARGS(priv, result),
> + TP_STRUCT__entry(
> + PRIV_ENTRY
> + __field(s32, result)
> + ),
> + TP_fast_assign(
> + PRIV_ASSIGN;
> + __entry->result = (s32) result;
> + ),
> + TP_printk(
> + "[%p] reset ret=%d", __entry->priv, __entry->result
> + )
> +);
> +
> TRACE_EVENT(ath5k_rx,
> TP_PROTO(struct ath5k_softc *priv, struct sk_buff *skb),
> TP_ARGS(priv, skb),
> diff --git a/drivers/net/wireless/ath/ath5k/base.c
> b/drivers/net/wireless/ath/ath5k/base.c index 23a5679..44732b5 100644
> --- a/drivers/net/wireless/ath/ath5k/base.c
> +++ b/drivers/net/wireless/ath/ath5k/base.c
> @@ -224,7 +224,8 @@ static struct pci_driver ath5k_pci_driver = {
> static int ath5k_tx(struct ieee80211_hw *hw, struct sk_buff *skb);
> static int ath5k_tx_queue(struct ieee80211_hw *hw, struct sk_buff *skb,
> struct ath5k_txq *txq);
> -static int ath5k_reset(struct ath5k_softc *sc, struct ieee80211_channel
> *chan); +static int ath5k_reset(struct ath5k_softc *sc, struct
> ieee80211_channel *chan, + enum ath5k_reset_reason
> ath5k_reset_reason);
> static int ath5k_start(struct ieee80211_hw *hw);
> static void ath5k_stop(struct ieee80211_hw *hw);
> static int ath5k_add_interface(struct ieee80211_hw *hw,
> @@ -1120,17 +1121,13 @@ ath5k_setup_bands(struct ieee80211_hw *hw)
> static int
> ath5k_chan_set(struct ath5k_softc *sc, struct ieee80211_channel *chan)
> {
> - ATH5K_DBG(sc, ATH5K_DEBUG_RESET,
> - "channel set, resetting (%u -> %u MHz)\n",
> - sc->curchan->center_freq, chan->center_freq);
> -
> /*
> * To switch channels clear any pending DMA operations;
> * wait long enough for the RX fifo to drain, reset the
> * hardware at the new frequency, and then re-enable
> * the relevant bits of the h/w.
> */
> - return ath5k_reset(sc, chan);
> + return ath5k_reset(sc, chan, RESET_SET_CHANNEL);
> }
>
> static void
> @@ -1615,8 +1612,6 @@ ath5k_txq_drainq(struct ath5k_softc *sc, struct
> ath5k_txq *txq) */
> spin_lock_bh(&txq->lock);
> list_for_each_entry_safe(bf, bf0, &txq->q, list) {
> - ath5k_debug_printtxbuf(sc, bf);
> -
> ath5k_txbuf_free_skb(sc, bf);
>
> spin_lock_bh(&sc->txbuflock);
> @@ -1641,18 +1636,9 @@ ath5k_txq_cleanup(struct ath5k_softc *sc)
> if (likely(!test_bit(ATH_STAT_INVALID, sc->status))) {
> /* don't touch the hardware if marked invalid */
> ath5k_hw_stop_tx_dma(ah, sc->bhalq);
> - ATH5K_DBG(sc, ATH5K_DEBUG_RESET, "beacon queue %x\n",
> - ath5k_hw_get_txdp(ah, sc->bhalq));
> for (i = 0; i < ARRAY_SIZE(sc->txqs); i++)
> - if (sc->txqs[i].setup) {
> + if (sc->txqs[i].setup)
> ath5k_hw_stop_tx_dma(ah, sc->txqs[i].qnum);
> - ATH5K_DBG(sc, ATH5K_DEBUG_RESET, "txq [%u] %x, "
> - "link %p\n",
> - sc->txqs[i].qnum,
> - ath5k_hw_get_txdp(ah,
> - sc->txqs[i].qnum),
> - sc->txqs[i].link);
> - }
> }
>
> for (i = 0; i < ARRAY_SIZE(sc->txqs); i++)
> @@ -1693,9 +1679,6 @@ ath5k_rx_start(struct ath5k_softc *sc)
>
> common->rx_bufsize = roundup(IEEE80211_MAX_LEN, common->cachelsz);
>
> - ATH5K_DBG(sc, ATH5K_DEBUG_RESET, "cachelsz %u rx_bufsize %u\n",
> - common->cachelsz, common->rx_bufsize);
> -
> spin_lock_bh(&sc->rxbuflock);
> sc->rxlink = NULL;
> list_for_each_entry(bf, &sc->rxbuf, list) {
> @@ -2329,8 +2312,7 @@ ath5k_beacon_send(struct ath5k_softc *sc)
> ATH5K_DBG(sc, ATH5K_DEBUG_BEACON,
> "stuck beacon time (%u missed)\n",
> sc->bmisscount);
> - ATH5K_DBG(sc, ATH5K_DEBUG_RESET,
> - "stuck beacon, resetting\n");
> + sc->reset_reason = RESET_STUCK_BEACON;
> ieee80211_queue_work(sc->hw, &sc->reset_work);
> }
> return;
> @@ -2561,8 +2543,6 @@ ath5k_init(struct ath5k_softc *sc)
>
> mutex_lock(&sc->lock);
>
> - ATH5K_DBG(sc, ATH5K_DEBUG_RESET, "mode %d\n", sc->opmode);
> -
> /*
> * Stop anything previously setup. This is safe
> * no matter this is the first time through or not.
> @@ -2582,7 +2562,7 @@ ath5k_init(struct ath5k_softc *sc)
> AR5K_INT_RXORN | AR5K_INT_TXDESC | AR5K_INT_TXEOL |
> AR5K_INT_FATAL | AR5K_INT_GLOBAL | AR5K_INT_MIB;
>
> - ret = ath5k_reset(sc, NULL);
> + ret = ath5k_reset(sc, NULL, RESET_INIT);
> if (ret)
> goto done;
>
> @@ -2608,9 +2588,6 @@ ath5k_stop_locked(struct ath5k_softc *sc)
> {
> struct ath5k_hw *ah = sc->ah;
>
> - ATH5K_DBG(sc, ATH5K_DEBUG_RESET, "invalid %u\n",
> - test_bit(ATH_STAT_INVALID, sc->status));
> -
> /*
> * Shutdown the hardware and driver:
> * stop output from above
> @@ -2686,9 +2663,6 @@ ath5k_stop_hw(struct ath5k_softc *sc)
> * on the device (same as initial state after attach) and
> * leave it idle (keep MAC/BB on warm reset) */
> ret = ath5k_hw_on_hold(sc->ah);
> -
> - ATH5K_DBG(sc, ATH5K_DEBUG_RESET,
> - "putting device to sleep\n");
> }
> ath5k_txbuf_free_skb(sc, sc->bbuf);
>
> @@ -2743,8 +2717,7 @@ ath5k_intr(int irq, void *dev_id)
> * Fatal errors are unrecoverable.
> * Typically these are caused by DMA errors.
> */
> - ATH5K_DBG(sc, ATH5K_DEBUG_RESET,
> - "fatal int, resetting\n");
> + sc->reset_reason = RESET_FATAL;
> ieee80211_queue_work(sc->hw, &sc->reset_work);
> } else if (unlikely(status & AR5K_INT_RXORN)) {
> /*
> @@ -2758,8 +2731,7 @@ ath5k_intr(int irq, void *dev_id)
> */
> sc->stats.rxorn_intr++;
> if (ah->ah_mac_srev < AR5K_SREV_AR5212) {
> - ATH5K_DBG(sc, ATH5K_DEBUG_RESET,
> - "rx overrun, resetting\n");
> + sc->reset_reason = RESET_RXORN;
> ieee80211_queue_work(sc->hw, &sc->reset_work);
> }
> else
> @@ -2829,7 +2801,7 @@ ath5k_tasklet_calibrate(unsigned long data)
> * Rfgain is out of bounds, reset the chip
> * to load new gain values.
> */
> - ATH5K_DBG(sc, ATH5K_DEBUG_RESET, "calibration, resetting\n");
> + sc->reset_reason = RESET_CALIBRATION;
> ieee80211_queue_work(sc->hw, &sc->reset_work);
> }
> if (ath5k_hw_phy_calibrate(ah, sc->curchan))
> @@ -2938,12 +2910,13 @@ drop_packet:
> * This should be called with sc->lock.
> */
> static int
> -ath5k_reset(struct ath5k_softc *sc, struct ieee80211_channel *chan)
> +ath5k_reset(struct ath5k_softc *sc, struct ieee80211_channel *chan,
> + enum ath5k_reset_reason reason)
> {
> struct ath5k_hw *ah = sc->ah;
> int ret;
>
> - ATH5K_DBG(sc, ATH5K_DEBUG_RESET, "resetting\n");
> + trace_ath5k_reset(sc, chan, reason);
>
> ath5k_hw_set_imr(ah, 0);
> synchronize_irq(sc->pdev->irq);
> @@ -2990,8 +2963,9 @@ ath5k_reset(struct ath5k_softc *sc, struct
> ieee80211_channel *chan)
>
> ieee80211_wake_queues(sc->hw);
>
> - return 0;
> + ret = 0;
> err:
> + trace_ath5k_reset_end(sc, ret);
> return ret;
> }
>
> @@ -3001,7 +2975,7 @@ static void ath5k_reset_work(struct work_struct
> *work) reset_work);
>
> mutex_lock(&sc->lock);
> - ath5k_reset(sc, sc->curchan);
> + ath5k_reset(sc, sc->curchan, sc->reset_reason);
> mutex_unlock(&sc->lock);
> }
>
> diff --git a/drivers/net/wireless/ath/ath5k/base.h
> b/drivers/net/wireless/ath/ath5k/base.h index dc1241f..cb6e2be 100644
> --- a/drivers/net/wireless/ath/ath5k/base.h
> +++ b/drivers/net/wireless/ath/ath5k/base.h
> @@ -140,6 +140,17 @@ struct ath5k_statistics {
> unsigned int rxeol_intr;
> };
>
> +/* Reset tracing */
> +enum ath5k_reset_reason {
> + RESET_INIT,
> + RESET_SET_CHANNEL,
> + RESET_STUCK_BEACON,
> + RESET_FATAL,
> + RESET_RXORN,
> + RESET_CALIBRATION,
> + RESET_DEBUGFS,
> +};
> +
> #if CHAN_DEBUG
> #define ATH_CHAN_MAX (26+26+26+200+200)
> #else
> @@ -192,6 +203,7 @@ struct ath5k_softc {
> led_on; /* pin setting for LED on */
>
> struct work_struct reset_work; /* deferred chip reset */
> + enum ath5k_reset_reason reset_reason; /* reason for resetting */
>
> unsigned int rxbufsize; /* rx size based on mtu */
> struct list_head rxbuf; /* receive buffer */
> diff --git a/drivers/net/wireless/ath/ath5k/debug.c
> b/drivers/net/wireless/ath/ath5k/debug.c index d107cd6..9ddbfd5 100644
> --- a/drivers/net/wireless/ath/ath5k/debug.c
> +++ b/drivers/net/wireless/ath/ath5k/debug.c
> @@ -278,7 +278,7 @@ static ssize_t write_file_reset(struct file *file,
> size_t count, loff_t *ppos)
> {
> struct ath5k_softc *sc = file->private_data;
> - ATH5K_DBG(sc, ATH5K_DEBUG_RESET, "debug file triggered reset\n");
> + sc->reset_reason = RESET_DEBUGFS;
> ieee80211_queue_work(sc->hw, &sc->reset_work);
> return count;
> }
> @@ -297,7 +297,6 @@ static const struct {
> const char *name;
> const char *desc;
> } dbg_info[] = {
> - { ATH5K_DEBUG_RESET, "reset", "reset and initialization" },
> { ATH5K_DEBUG_INTR, "intr", "interrupt handling" },
> { ATH5K_DEBUG_MODE, "mode", "mode init/setup" },
> { ATH5K_DEBUG_XMIT, "xmit", "basic xmit operation" },
> @@ -931,6 +930,7 @@ ath5k_debug_printrxbuf(struct ath5k_buf *bf, int done,
> void
> ath5k_debug_printrxbuffs(struct ath5k_softc *sc, struct ath5k_hw *ah)
> {
> +#if 0
> struct ath5k_desc *ds;
> struct ath5k_buf *bf;
> struct ath5k_rx_status rs = {};
> @@ -950,11 +950,13 @@ ath5k_debug_printrxbuffs(struct ath5k_softc *sc,
> struct ath5k_hw *ah) ath5k_debug_printrxbuf(bf, status == 0, &rs);
> }
> spin_unlock_bh(&sc->rxbuflock);
> +#endif
> }
>
> void
> ath5k_debug_printtxbuf(struct ath5k_softc *sc, struct ath5k_buf *bf)
> {
> +#if 0
> struct ath5k_desc *ds = bf->desc;
> struct ath5k_hw_5212_tx_desc *td = &ds->ud.ds_tx5212;
> struct ath5k_tx_status ts = {};
> @@ -971,6 +973,7 @@ ath5k_debug_printtxbuf(struct ath5k_softc *sc, struct
> ath5k_buf *bf) td->tx_ctl.tx_control_2, td->tx_ctl.tx_control_3,
> td->tx_stat.tx_status_0, td->tx_stat.tx_status_1,
> done ? ' ' : (ts.ts_status == 0) ? '*' : '!');
> +#endif
> }
>
> #endif /* ifdef CONFIG_ATH5K_DEBUG */
> diff --git a/drivers/net/wireless/ath/ath5k/debug.h
> b/drivers/net/wireless/ath/ath5k/debug.h index c260b00..8a484f2 100644
> --- a/drivers/net/wireless/ath/ath5k/debug.h
> +++ b/drivers/net/wireless/ath/ath5k/debug.h
> @@ -83,7 +83,6 @@ struct ath5k_dbg_info {
> /**
> * enum ath5k_debug_level - ath5k debug level
> *
> - * @ATH5K_DEBUG_RESET: reset processing
> * @ATH5K_DEBUG_INTR: interrupt handling
> * @ATH5K_DEBUG_MODE: mode init/setup
> * @ATH5K_DEBUG_XMIT: basic xmit operation
> @@ -104,7 +103,6 @@ struct ath5k_dbg_info {
> * be combined together by bitwise OR.
> */
> enum ath5k_debug_level {
> - ATH5K_DEBUG_RESET = 0x00000001,
> ATH5K_DEBUG_INTR = 0x00000002,
> ATH5K_DEBUG_MODE = 0x00000004,
> ATH5K_DEBUG_XMIT = 0x00000008,
again, here my same concerns: printing the reasons for resets is something
which is useful on embedded boards and production setups which can't have
tracing enabled. which is why i want to object against this change!
also adding a reason argument to the reset function just for tracing seems to
be... umm... not so nice... couldn't you add the tracepoints before?
and: didn't we want to split channel change out of reset anyhow?
bruno
^ permalink raw reply
* Re: ath5k Ad Hoc Association
From: Jonathan Guerin @ 2010-07-20 6:39 UTC (permalink / raw)
To: Bob Copeland; +Cc: linux-wireless, ath5k-devel
In-Reply-To: <AANLkTintLd8YTgMQuzbEB36t_i5AL4TePBSDAa7G2zvl@mail.gmail.com>
Hi,
Thanks heaps for replying.
Yes, I've checked the channel (36, 5180) allows beaconing. I've tried
the commands you mentioned, but no luck. If I monitor the interface
from another station, the ath5k drive never appears to beacon.
What I've managed to get working, however, is to start one station
using MadWifi. This definitely beacons, then I bring up the ath5k
interfaces on the other machines using these commands:
*******
# Create interfaces
iw phy phy0 interface add wlan0 type adhoc
iw wlan0 set channel 36
iwconfig wlan0 channel 36
iwconfig wlan0 essid txctest
# Set IP and bring up
ifconfig wlan0 10.0.1.64 netmask 255.255.255.0 up
ifconfig mon0 up
sleep 5
# Scan trick to force association
iwlist scan
*****
They ath5k stations will then correctly join the SSID and I am able to
ping them.
Using the ibss join command doesn't seem to help when I only bring up
ath5k stations - they never seem to beacon at all. This was run from a
monitor interface on the MadWifi node:
****
tcpdump -s 2048 -i mon0 -w dump.pcap
tcpdump: WARNING: mon0: no IPv4 address assigned
tcpdump: listening on mon0, link-type IEEE802_11_RADIO (802.11 plus
radiotap header), capture size 2048 bytes
^C0 packets captured
0 packets received by filter
0 packets dropped by kernel
****
Thanks,
--
Jonathan Guerin
On Tue, Jul 20, 2010 at 5:22 AM, Bob Copeland <me@bobcopeland.com> wrote:
> On Mon, Jul 19, 2010 at 12:35 AM, Jonathan Guerin <jonathan@guerin.id.au> wrote:
>> Hi,
>>
>> I'm trying to get my wireless nodes to associate in ad hoc mode.
> [...]
>> I've built and installed the compat package for this kernel version:
>> compat-wireless-2.6.32.16
>
> Ok, I'm not sure which mainline kernel this corresponds to, but I
> just tested ath5k adhoc with success in the latest wireless-testing
> kernel. Here's what I did:
>
> (had dnsmasq running dhcp for 192.168.10.x, network manager disabled)
>
> $ su
> # modprobe -r ath5k
> # modprobe ath5k
> # iw dev wlan0 set type ibss
> # ifconfig wlan0 192.168.10.1 up
> # iw dev wlan0 ibss join myibss 2462
>
> Then on the other machine (Vista) I just located 'myibss' (so beacons
> are working) and selected it, then successfully pinged 192.168.10.1.
>
> It may depend on which channel you are trying to use; are you on
> a channel that allows beaconing in your regulatory domain?
>
> --
> Bob Copeland %% www.bobcopeland.com
>
^ permalink raw reply
* Re: ath5k Ad Hoc Association
From: Jonathan Guerin @ 2010-07-20 6:59 UTC (permalink / raw)
To: Bob Copeland; +Cc: linux-wireless, ath5k-devel
In-Reply-To: <AANLkTimgt_HdXyGneQMOz7wR7Xs7BBrDUCGoxP1qDcYg@mail.gmail.com>
I've just tried associating with an existing MadWifi station, and the
'ibss join' command doesn't work - the ath5k station eventually gives
up and just creates it's own BSSID.
I used the above method:
# Create interfaces
iw phy phy0 interface add wlan0 type adhoc
iw wlan0 set channel 36
iwconfig wlan0 channel 36
iwconfig wlan0 essid txctest
# Set IP and bring up
ifconfig wlan0 10.0.1.64 netmask 255.255.255.0 up
sleep 5
# Scan trick to force association
iwlist scan
and this works and the station joins the existing Cell ID - I can ping
the other station etc.
Thanks,
--
Jonathan Guerin
On Tue, Jul 20, 2010 at 4:39 PM, Jonathan Guerin <jonathan@guerin.id.au> wrote:
> Hi,
>
> Thanks heaps for replying.
>
> Yes, I've checked the channel (36, 5180) allows beaconing. I've tried
> the commands you mentioned, but no luck. If I monitor the interface
> from another station, the ath5k drive never appears to beacon.
>
> What I've managed to get working, however, is to start one station
> using MadWifi. This definitely beacons, then I bring up the ath5k
> interfaces on the other machines using these commands:
> *******
> # Create interfaces
> iw phy phy0 interface add wlan0 type adhoc
> iw wlan0 set channel 36
> iwconfig wlan0 channel 36
> iwconfig wlan0 essid txctest
>
> # Set IP and bring up
> ifconfig wlan0 10.0.1.64 netmask 255.255.255.0 up
> ifconfig mon0 up
>
> sleep 5
> # Scan trick to force association
> iwlist scan
> *****
>
> They ath5k stations will then correctly join the SSID and I am able to
> ping them.
>
> Using the ibss join command doesn't seem to help when I only bring up
> ath5k stations - they never seem to beacon at all. This was run from a
> monitor interface on the MadWifi node:
> ****
> tcpdump -s 2048 -i mon0 -w dump.pcap
> tcpdump: WARNING: mon0: no IPv4 address assigned
> tcpdump: listening on mon0, link-type IEEE802_11_RADIO (802.11 plus
> radiotap header), capture size 2048 bytes
> ^C0 packets captured
> 0 packets received by filter
> 0 packets dropped by kernel
> ****
>
> Thanks,
>
> --
> Jonathan Guerin
>
>
>
> On Tue, Jul 20, 2010 at 5:22 AM, Bob Copeland <me@bobcopeland.com> wrote:
>> On Mon, Jul 19, 2010 at 12:35 AM, Jonathan Guerin <jonathan@guerin.id.au> wrote:
>>> Hi,
>>>
>>> I'm trying to get my wireless nodes to associate in ad hoc mode.
>> [...]
>>> I've built and installed the compat package for this kernel version:
>>> compat-wireless-2.6.32.16
>>
>> Ok, I'm not sure which mainline kernel this corresponds to, but I
>> just tested ath5k adhoc with success in the latest wireless-testing
>> kernel. Here's what I did:
>>
>> (had dnsmasq running dhcp for 192.168.10.x, network manager disabled)
>>
>> $ su
>> # modprobe -r ath5k
>> # modprobe ath5k
>> # iw dev wlan0 set type ibss
>> # ifconfig wlan0 192.168.10.1 up
>> # iw dev wlan0 ibss join myibss 2462
>>
>> Then on the other machine (Vista) I just located 'myibss' (so beacons
>> are working) and selected it, then successfully pinged 192.168.10.1.
>>
>> It may depend on which channel you are trying to use; are you on
>> a channel that allows beaconing in your regulatory domain?
>>
>> --
>> Bob Copeland %% www.bobcopeland.com
>>
>
^ permalink raw reply
* Re: [ath5k-devel] [PATCH/RFC 0/3] ath5k: add driver tracepoints
From: Johannes Berg @ 2010-07-20 7:54 UTC (permalink / raw)
To: Bruno Randolf; +Cc: ath5k-devel, Bob Copeland, linux-wireless
In-Reply-To: <201007201411.51259.br1@einfach.org>
On Tue, 2010-07-20 at 14:11 +0900, Bruno Randolf wrote:
> hmm, this is really nice stuff, but i'm not sure what to do on embedded boards
> where we don't have python or where it's not possible to use tracing in
> general due to (low) performance reasons
err, tracing has much better performance than printk, and you can get
the trace into a file that you can analyse offline on a "real" machine.
No need for python on the board, and tracing improves performance over
printk.
johannes
^ permalink raw reply
* Re: [PATCH v3] mac80211: remove wep dependency
From: Johannes Berg @ 2010-07-20 10:59 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless
In-Reply-To: <1278529669-9904-1-git-send-email-linville@tuxdriver.com>
On Wed, 2010-07-07 at 15:07 -0400, John W. Linville wrote:
> The current mac80211 code assumes that WEP is always available. If WEP
> fails to initialize, ieee80211_register_hw will always fail.
>
> In some cases (e.g. FIPS certification), the cryptography used by WEP is
> unavailable. However, in such cases there is no good reason why CCMP
> encryption (or even no link level encryption) cannot be used. So, this
> patch removes mac80211's assumption that WEP (and TKIP) will always be
> available for use.
>
> Signed-off-by: John W. Linville <linville@tuxdriver.com>
> ---
> v3 -> actually post changed patch...
> v2 -> make it safe to call ieee80211_wep_free even if ieee80211_wep_init
> had failed
I think this is missing a change like this:
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -1228,6 +1228,10 @@ static int ieee80211_scan(struct wiphy *wiphy,
static int ieee80211_auth(struct wiphy *wiphy, struct net_device *dev,
struct cfg80211_auth_request *req)
{
+ if (req->auth_type == NL80211_AUTHTYPE_SHARED_KEY &&
+ IS_ERR(sdata->local->wep_tx_tfm))
+ return -EINVAL;
+
return ieee80211_mgd_auth(IEEE80211_DEV_TO_SUB_IF(dev), req);
}
since otherwise you could end up trying to encrypt the auth frame with
the uninitialised WEP TFM?
johannes
^ permalink raw reply
* Re: ath5k Ad Hoc Association
From: Bob Copeland @ 2010-07-20 11:20 UTC (permalink / raw)
To: Jonathan Guerin; +Cc: linux-wireless, ath5k-devel
In-Reply-To: <AANLkTimgt_HdXyGneQMOz7wR7Xs7BBrDUCGoxP1qDcYg@mail.gmail.com>
[please don't top post]
On Tue, Jul 20, 2010 at 04:39:29PM +1000, Jonathan Guerin wrote:
> Yes, I've checked the channel (36, 5180) allows beaconing. I've tried
> the commands you mentioned, but no luck. If I monitor the interface
> from another station, the ath5k drive never appears to beacon.
What does "iw phy phy0 info" show?
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* Re: ath5k Ad Hoc Association
From: Holger Schurig @ 2010-07-20 11:50 UTC (permalink / raw)
To: Jonathan Guerin; +Cc: Bob Copeland, linux-wireless, ath5k-devel
In-Reply-To: <AANLkTimgt_HdXyGneQMOz7wR7Xs7BBrDUCGoxP1qDcYg@mail.gmail.com>
> iw phy phy0 interface add wlan0 type adhoc
> iw wlan0 set channel 36
> iwconfig wlan0 channel 36
> iwconfig wlan0 essid txctest
I can't think of ANY reason why you do that. Use "iw", not "iwconfig".
All the last three commands should be replaced with one single "iw dev wlan0
ibss join myibss XXXX", where XXXX is the frequency for channel 36. If in
doubt what this is, just do "iw list" and you'll see it.
^ permalink raw reply
* Re: ath5k Ad Hoc Association
From: Jonathan Guerin @ 2010-07-20 12:05 UTC (permalink / raw)
To: Holger Schurig; +Cc: Bob Copeland, linux-wireless, ath5k-devel
In-Reply-To: <201007201350.48923.holgerschurig@gmail.com>
I understand that it's not the way I'm supposed to do it. What I'm
saying is that it's not working, whereas the other way is! :(
I will play around some more with it tomorrow. It's still baffling as
to why the driver is not beaconing until there is another node tho...
--
Jonathan Guerin
On Tue, Jul 20, 2010 at 9:50 PM, Holger Schurig
<holgerschurig@googlemail.com> wrote:
>> iw phy phy0 interface add wlan0 type adhoc
>> iw wlan0 set channel 36
>> iwconfig wlan0 channel 36
>> iwconfig wlan0 essid txctest
>
> I can't think of ANY reason why you do that. Use "iw", not "iwconfig".
>
> All the last three commands should be replaced with one single "iw dev wlan0
> ibss join myibss XXXX", where XXXX is the frequency for channel 36. If in
> doubt what this is, just do "iw list" and you'll see it.
>
^ permalink raw reply
* Re: [PATCH] cfg80211: fix WEXT ioctl GIWFREQ for monitor interfaces
From: Johannes Berg @ 2010-07-20 13:04 UTC (permalink / raw)
To: David Gnedt; +Cc: Gábor Stefanik, linux-wireless, John W. Linville
In-Reply-To: <4C44DFBB.6070604@davizone.at>
On Tue, 2010-07-20 at 01:28 +0200, David Gnedt wrote:
> Am 2010-07-19 23:06, schrieb Gábor Stefanik:
> > (BTW, I say that a GIWFREQ on a monitor interface should always return
> > the channel the PHY is tuned to at the moment when it is issued. Most
> > tools seem to expect this behavior.)
>
> I agree, that would be the expected behaviour.
>
> I am not very familar with the entire wireless subsystem yet, but wouldn't that
> imply a interface change in cfg80211 and mac80211 to add an "get_channel" function?
Yes, I think so.
> Because if the card is hopping channels (e.g. because of 2 station interfaces on
> different channels), only the driver itself can tell what's really the current
> channel.
Right. Although in that case I'm not sure we should be telling userspace
what channel the monitor interface is on, since there's no single
channel it is on, and I certainly hope userspace won't be requesting the
channel many times per second!
> Nevertheless a default implementation for this new "get_channel" can be written
> at mac80211 level (or even cfg80211?), which tries to find the current channel
> by looking at all virtual interfaces, so only mac80211 drivers which allow
> multiple channels (and non-mac80211 drivers) need to implement it.
Indeed, but I think mac80211 would be more appropriate than cfg80211
since the latter won't really have all the information unless it makes a
whole bunch of assumptions that we'll eventually have to reconsider.
johannes
^ permalink raw reply
* Re: [PATCH/RFC 3/3] ath5k: trace resets
From: Bob Copeland @ 2010-07-20 14:52 UTC (permalink / raw)
To: Bruno Randolf; +Cc: linux-wireless, ath5k-devel, johannes
In-Reply-To: <201007201420.49305.br1@einfach.org>
On Tue, Jul 20, 2010 at 02:20:49PM +0900, Bruno Randolf wrote:
> > @@ -931,6 +930,7 @@ ath5k_debug_printrxbuf(struct ath5k_buf *bf, int done,
> > void
> > ath5k_debug_printrxbuffs(struct ath5k_softc *sc, struct ath5k_hw *ah)
> > {
> > +#if 0
(The above, by the way, is a mistake I'll fix; I forgot to remove it after
doing patch 1/3.)
> again, here my same concerns: printing the reasons for resets is something
> which is useful on embedded boards and production setups which can't have
> tracing enabled. which is why i want to object against this change!
What Johannes said wrt performance: during tracing, only the binary
representations of the data are written to the trace ring buffer, so
unlike the current debug code, we aren't doing printk formatting until
the trace buffer is read. You can save the raw binary data from the
trace and do formatting on another machine.
Another advantage is better granularity: if you only care about watching
tx on the cab queue, you can dynamically filter based on the tracepoint
arguments, something like:
# echo "qnum == 6" > /debug/tracing/events/ath5k/ath5k_tx/filter
With the debug printks, you have to hack the driver or grep and hope
the printk buffer didn't overflow and spill what you were looking for.
One thing I do need to look into is reducing the size, right now
text size went up by about 4k when adding these tracepoints.
> also adding a reason argument to the reset function just for tracing seems to
> be... umm... not so nice... couldn't you add the tracepoints before?
Yeah, it's kind of hacky, but not without precedent; ieee80211_wake_queues
does something similar. But I'm not tied to it, adding another tracepoint
for when and why the reset was scheduled would be OK, or maybe we just
drop the reason and plan on using ftrace to figure that out. It's still
worth keeping tracepoints when reset actually runs and finishes since that
is the most useful information for tracking down race conditions.
> and: didn't we want to split channel change out of reset anyhow?
Of course. When we do so we probably won't need the frequency argument,
but I think that's otherwise orthogonal to this...
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* [PATCH] wireless: correct sparse warning in lib80211_crypt_tkip.c
From: John W. Linville @ 2010-07-20 16:11 UTC (permalink / raw)
To: linux-wireless; +Cc: John W. Linville
CHECK net/wireless/lib80211_crypt_tkip.c
net/wireless/lib80211_crypt_tkip.c:581:27: warning: cast to restricted __le16
Caused by dereferencing a "u8 *" and passing it to le16_to_cpu...
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
net/wireless/lib80211_crypt_tkip.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/wireless/lib80211_crypt_tkip.c b/net/wireless/lib80211_crypt_tkip.c
index 8cbdb32..a7f9956 100644
--- a/net/wireless/lib80211_crypt_tkip.c
+++ b/net/wireless/lib80211_crypt_tkip.c
@@ -578,7 +578,7 @@ static void michael_mic_hdr(struct sk_buff *skb, u8 * hdr)
}
if (ieee80211_is_data_qos(hdr11->frame_control)) {
- hdr[12] = le16_to_cpu(*ieee80211_get_qos_ctl(hdr11))
+ hdr[12] = le16_to_cpu(*((__le16 *)ieee80211_get_qos_ctl(hdr11)))
& IEEE80211_QOS_CTL_TID_MASK;
} else
hdr[12] = 0; /* priority */
--
1.7.1.1
^ permalink raw reply related
* [PATCH] wireless: correct sparse warning in wext-compat.c
From: John W. Linville @ 2010-07-20 16:26 UTC (permalink / raw)
To: linux-wireless; +Cc: John W. Linville
CHECK net/wireless/wext-compat.c
net/wireless/wext-compat.c:1434:5: warning: symbol 'cfg80211_wext_siwpmksa' was not declared. Should it be static?
Add declaration in cfg80211.h. Also add an EXPORT_SYMBOL_GPL, since all
the peer functions have it.
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
include/net/cfg80211.h | 4 ++++
net/wireless/wext-compat.c | 1 +
2 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 9b8b3f4..f68ae54 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -1963,6 +1963,10 @@ int cfg80211_wext_giwap(struct net_device *dev,
struct iw_request_info *info,
struct sockaddr *ap_addr, char *extra);
+int cfg80211_wext_siwpmksa(struct net_device *dev,
+ struct iw_request_info *info,
+ struct iw_point *data, char *extra);
+
/*
* callbacks for asynchronous cfg80211 methods, notification
* functions and BSS handling helpers
diff --git a/net/wireless/wext-compat.c b/net/wireless/wext-compat.c
index 1ff1e9f..bb5e0a5 100644
--- a/net/wireless/wext-compat.c
+++ b/net/wireless/wext-compat.c
@@ -1471,6 +1471,7 @@ int cfg80211_wext_siwpmksa(struct net_device *dev,
return -EOPNOTSUPP;
}
}
+EXPORT_SYMBOL_GPL(cfg80211_wext_siwpmksa);
static const iw_handler cfg80211_handlers[] = {
[IW_IOCTL_IDX(SIOCGIWNAME)] = (iw_handler) cfg80211_wext_giwname,
--
1.7.1.1
^ permalink raw reply related
* Re: [PATCH] wireless: correct sparse warning in wext-compat.c
From: Johannes Berg @ 2010-07-20 16:39 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless
In-Reply-To: <1279643215-13498-1-git-send-email-linville@tuxdriver.com>
On Tue, 2010-07-20 at 12:26 -0400, John W. Linville wrote:
> CHECK net/wireless/wext-compat.c
> net/wireless/wext-compat.c:1434:5: warning: symbol 'cfg80211_wext_siwpmksa' was not declared. Should it be static?
>
> Add declaration in cfg80211.h. Also add an EXPORT_SYMBOL_GPL, since all
> the peer functions have it.
Or it could just be static, since it seems unlikely somebody wants to
use it for orinoco or a similar half-converted driver? Anyway I don't
mind this patch either.
johannes
^ permalink raw reply
* [PATCH] wireless: correct sparse warning in generated regdb.c
From: John W. Linville @ 2010-07-20 16:30 UTC (permalink / raw)
To: linux-wireless; +Cc: John W. Linville
CHECK net/wireless/regdb.c
net/wireless/regdb.c:8:34: warning: symbol 'reg_regdb' was not declared. Should it be static?
net/wireless/regdb.c:11:5: warning: symbol 'reg_regdb_size' was not declared. Should it be static?
Simply include the also generated regdb.h.
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
net/wireless/genregdb.awk | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/net/wireless/genregdb.awk b/net/wireless/genregdb.awk
index 3cc9e69..53c143f 100644
--- a/net/wireless/genregdb.awk
+++ b/net/wireless/genregdb.awk
@@ -21,6 +21,7 @@ BEGIN {
print ""
print "#include <linux/nl80211.h>"
print "#include <net/cfg80211.h>"
+ print "#include \"regdb.h\""
print ""
regdb = "const struct ieee80211_regdomain *reg_regdb[] = {\n"
}
--
1.7.1.1
^ permalink raw reply related
* [PATCH] wireless: mark cfg80211_is_all_idle as static
From: John W. Linville @ 2010-07-20 16:33 UTC (permalink / raw)
To: linux-wireless; +Cc: John W. Linville
CHECK net/wireless/sme.c
net/wireless/sme.c:38:6: warning: symbol 'cfg80211_is_all_idle' was not declared. Should it be static?
It is not used elsewhere, so mark it static.
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
net/wireless/sme.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/wireless/sme.c b/net/wireless/sme.c
index 72222f0..a8c2d6b 100644
--- a/net/wireless/sme.c
+++ b/net/wireless/sme.c
@@ -35,7 +35,7 @@ struct cfg80211_conn {
bool auto_auth, prev_bssid_valid;
};
-bool cfg80211_is_all_idle(void)
+static bool cfg80211_is_all_idle(void)
{
struct cfg80211_registered_device *rdev;
struct wireless_dev *wdev;
--
1.7.1.1
^ permalink raw reply related
* Re: [PATCH] cfg80211: fix WEXT ioctl GIWFREQ for monitor interfaces
From: Gábor Stefanik @ 2010-07-20 16:49 UTC (permalink / raw)
To: Johannes Berg; +Cc: David Gnedt, linux-wireless, John W. Linville
In-Reply-To: <1279631096.3706.33.camel@jlt3.sipsolutions.net>
On Tue, Jul 20, 2010 at 3:04 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Tue, 2010-07-20 at 01:28 +0200, David Gnedt wrote:
>> Am 2010-07-19 23:06, schrieb Gábor Stefanik:
>> > (BTW, I say that a GIWFREQ on a monitor interface should always return
>> > the channel the PHY is tuned to at the moment when it is issued. Most
>> > tools seem to expect this behavior.)
>>
>> I agree, that would be the expected behaviour.
>>
>> I am not very familar with the entire wireless subsystem yet, but wouldn't that
>> imply a interface change in cfg80211 and mac80211 to add an "get_channel" function?
>
> Yes, I think so.
>
>> Because if the card is hopping channels (e.g. because of 2 station interfaces on
>> different channels), only the driver itself can tell what's really the current
>> channel.
>
> Right. Although in that case I'm not sure we should be telling userspace
> what channel the monitor interface is on, since there's no single
> channel it is on, and I certainly hope userspace won't be requesting the
> channel many times per second!
Well, there is no reason why channel-hopping due to multiple virtual
PHYs and channel-hopping by userspace control (see Kismet) should
behave differently GIWFREQ-wise. Also, userspace (apart from maybe
hostapd - I haven't looked into that at all) seems to expect GIWFREQ
on a monitor interface to unconditionally return the channel the radio
is tuned to at the moment.
>
>> Nevertheless a default implementation for this new "get_channel" can be written
>> at mac80211 level (or even cfg80211?), which tries to find the current channel
>> by looking at all virtual interfaces, so only mac80211 drivers which allow
>> multiple channels (and non-mac80211 drivers) need to implement it.
>
> Indeed, but I think mac80211 would be more appropriate than cfg80211
> since the latter won't really have all the information unless it makes a
> whole bunch of assumptions that we'll eventually have to reconsider.
>
> johannes
>
>
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
^ permalink raw reply
* [PATCH] ath9k: correct sparse identified endian bug in ath_paprd_calibrate
From: John W. Linville @ 2010-07-20 17:16 UTC (permalink / raw)
To: linux-wireless; +Cc: John W. Linville
drivers/net/wireless/ath/ath9k/main.c:282:26: warning: incorrect type in assignment (different base types)
drivers/net/wireless/ath/ath9k/main.c:282:26: expected restricted __le16 [usertype] duration_id
drivers/net/wireless/ath/ath9k/main.c:282:26: got int
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
drivers/net/wireless/ath/ath9k/main.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
index d45cf0b..6cf0410 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -279,7 +279,7 @@ void ath_paprd_calibrate(struct work_struct *work)
hdr = (struct ieee80211_hdr *)skb->data;
ftype = IEEE80211_FTYPE_DATA | IEEE80211_STYPE_NULLFUNC;
hdr->frame_control = cpu_to_le16(ftype);
- hdr->duration_id = 10;
+ hdr->duration_id = cpu_to_le16(10);
memcpy(hdr->addr1, hw->wiphy->perm_addr, ETH_ALEN);
memcpy(hdr->addr2, hw->wiphy->perm_addr, ETH_ALEN);
memcpy(hdr->addr3, hw->wiphy->perm_addr, ETH_ALEN);
--
1.7.1.1
^ permalink raw reply related
* [PATCH] ipw2100: mark ipw2100_pm_qos_req static
From: John W. Linville @ 2010-07-20 18:12 UTC (permalink / raw)
To: linux-wireless; +Cc: John W. Linville
CHECK drivers/net/wireless/ipw2x00/ipw2100.c
drivers/net/wireless/ipw2x00/ipw2100.c:177:28: warning: symbol 'ipw2100_pm_qos_req' was not declared. Should it be static?
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
drivers/net/wireless/ipw2x00/ipw2100.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/ipw2x00/ipw2100.c b/drivers/net/wireless/ipw2x00/ipw2100.c
index 18ebd60..5165db9 100644
--- a/drivers/net/wireless/ipw2x00/ipw2100.c
+++ b/drivers/net/wireless/ipw2x00/ipw2100.c
@@ -174,7 +174,7 @@ that only one external action is invoked at a time.
#define DRV_DESCRIPTION "Intel(R) PRO/Wireless 2100 Network Driver"
#define DRV_COPYRIGHT "Copyright(c) 2003-2006 Intel Corporation"
-struct pm_qos_request_list *ipw2100_pm_qos_req;
+static struct pm_qos_request_list *ipw2100_pm_qos_req;
/* Debugging stuff */
#ifdef CONFIG_IPW2100_DEBUG
--
1.7.1.1
^ permalink raw reply related
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