* Re: carl9170 802.11n-AP
From: Christian Lamparter @ 2011-01-20 18:31 UTC (permalink / raw)
To: Helge Lenz; +Cc: linux-wireless
In-Reply-To: <4D380E46.6070906@gmail.com>
On Thursday 20 January 2011 11:28:22 Helge Lenz wrote:
> Any news about this issue?
no news, unless you have news about a new generation of ar9170 chip.
The current one has serve problems with 802.11e - which has become
mandatory for 802.11n - and aggregation. So going for full 802.11n
support [including AP] is sort of pointless...
If you are looking for a 802.11n AP, so why not start with one?
Best Regards,
Chr
^ permalink raw reply
* Re: [RFC 2/3] mac80211: Support scanning only current active channel.
From: Johannes Berg @ 2011-01-20 18:25 UTC (permalink / raw)
To: Ben Greear; +Cc: linux-wireless
In-Reply-To: <4D387D25.7080902@candelatech.com>
On Thu, 2011-01-20 at 10:21 -0800, Ben Greear wrote:
> > No, it can't actually determine the order -- we sort them in cfg80211
> > anyway to de-duplicate them.
>
> Ok, so assuming we re-work scanning across the board, maybe the first
> thing is to sort them such that the current channel is always first
> (if it's in the list at all)?
Yeah I guess mac80211 could do that -- I wouldn't necessarily do it in
cfg80211. However, I'm not convinced it's necessary.
> >> It seems to me that it would take quite a bit of re-work of the
> >> mac80211 scanning logic to deal with scanning on the current
> >> channel w/out affecting other tx/rx packets (as my patch attempts
> >> to do), without setting some explicit flag before you enter
> >> the scan state machine.
> >
> > Yeah, so maybe it needs some re-work, but I think what you're doing is a
> > pretty strange hack.
>
> If you have time to write some patches, I'll be happy to test them on
> our ath9k and ath5k systems.
I don't, unfortunately, at least not now.
> If you don't, then I can make an attempt. Suggestions for an acceptable
> way to go about doing this would be welcome.
Well I'd start by looking at the offchannel code and seeing if it has
the flushing in all the right places. I don't think it does, so drivers
attempt to work around it by flushing on channel changes. That could be
improved first.
Then I'd again look at the offchannel code and see how it can behave
better when it's not actually going offchannel -- not stop beaconing
etc., just reprogram the filters or so. That way, I'm not even sure if
modifying much of the scan code will even be necessary, and I think you
wouldn't even have to sort the channel list differently.
johannes
^ permalink raw reply
* Re: [RFC 2/3] mac80211: Support scanning only current active channel.
From: Ben Greear @ 2011-01-20 18:21 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1295547439.3693.46.camel@jlt3.sipsolutions.net>
On 01/20/2011 10:17 AM, Johannes Berg wrote:
> On Thu, 2011-01-20 at 10:06 -0800, Ben Greear wrote:
>
>>> This doesn't seem to make much sense either -- even if we do a scan over
>>> multiple channels we should be able to optimise the part on the current
>>> channel (maybe put it at the beginning or end too).
>>
>> Maybe..but user-space can specify the channels it wants to scan,
>> and I assume that means what order to scan them in. I have no
>> idea if changing that order would confuse some application.
>
> No, it can't actually determine the order -- we sort them in cfg80211
> anyway to de-duplicate them.
Ok, so assuming we re-work scanning across the board, maybe the first
thing is to sort them such that the current channel is always first
(if it's in the list at all)?
>> It seems to me that it would take quite a bit of re-work of the
>> mac80211 scanning logic to deal with scanning on the current
>> channel w/out affecting other tx/rx packets (as my patch attempts
>> to do), without setting some explicit flag before you enter
>> the scan state machine.
>
> Yeah, so maybe it needs some re-work, but I think what you're doing is a
> pretty strange hack.
If you have time to write some patches, I'll be happy to test them on
our ath9k and ath5k systems.
If you don't, then I can make an attempt. Suggestions for an acceptable
way to go about doing this would be welcome.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [RFC 2/3] mac80211: Support scanning only current active channel.
From: Johannes Berg @ 2011-01-20 18:17 UTC (permalink / raw)
To: Ben Greear; +Cc: linux-wireless
In-Reply-To: <4D3879A6.2060909@candelatech.com>
On Thu, 2011-01-20 at 10:06 -0800, Ben Greear wrote:
> > This doesn't seem to make much sense either -- even if we do a scan over
> > multiple channels we should be able to optimise the part on the current
> > channel (maybe put it at the beginning or end too).
>
> Maybe..but user-space can specify the channels it wants to scan,
> and I assume that means what order to scan them in. I have no
> idea if changing that order would confuse some application.
No, it can't actually determine the order -- we sort them in cfg80211
anyway to de-duplicate them.
> It seems to me that it would take quite a bit of re-work of the
> mac80211 scanning logic to deal with scanning on the current
> channel w/out affecting other tx/rx packets (as my patch attempts
> to do), without setting some explicit flag before you enter
> the scan state machine.
Yeah, so maybe it needs some re-work, but I think what you're doing is a
pretty strange hack.
johannes
^ permalink raw reply
* Re: [RFC 2/3] mac80211: Support scanning only current active channel.
From: Ben Greear @ 2011-01-20 18:06 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1295545143.3693.44.camel@jlt3.sipsolutions.net>
On 01/20/2011 09:39 AM, Johannes Berg wrote:
> On Thu, 2011-01-20 at 09:32 -0800, greearb@candelatech.com wrote:
>
>> - ieee80211_offchannel_stop_beaconing(local);
>> + if (local->ops->sw_scan_start_cur&&
>> + local->scan_req->n_channels == 1&&
>> + local->scan_req->channels[0] == local->hw.conf.channel) {
>> + __set_bit(SCAN_ON_CUR_CHANNEL,&local->scanning);
>> + drv_sw_scan_start_cur(local, true);
>> + } else
>> + drv_sw_scan_start(local);
>
> This doesn't seem to make much sense either -- even if we do a scan over
> multiple channels we should be able to optimise the part on the current
> channel (maybe put it at the beginning or end too).
Maybe..but user-space can specify the channels it wants to scan,
and I assume that means what order to scan them in. I have no
idea if changing that order would confuse some application.
It seems to me that it would take quite a bit of re-work of the
mac80211 scanning logic to deal with scanning on the current
channel w/out affecting other tx/rx packets (as my patch attempts
to do), without setting some explicit flag before you enter
the scan state machine.
Thanks,
Ben
>
> johannes
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [RFC 1/3] mac80211: Support sw_scan_start_cur
From: Ben Greear @ 2011-01-20 17:52 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1295545044.3693.43.camel@jlt3.sipsolutions.net>
On 01/20/2011 09:37 AM, Johannes Berg wrote:
> On Thu, 2011-01-20 at 09:32 -0800, greearb@candelatech.com wrote:
>> From: Ben Greear<greearb@candelatech.com>
>>
>> This method is called when driver can support
>> scanning the currect active channel without otherwise
>> impeding traffic on that channel. The mac80211 scan
>> logic may call this when we are only scanning on the
>> active channel and thus do not need to go off channel.
>
> I frankly don't see any point telling the driver about this. Looking at
> the ath9k patch you sent, it seems to avoid some things like flushing --
> but the flushing should be controlled by mac80211 already (or converted
> to be) so that it's not necessary to have this.
mac80211 + ath9k is a house of cards, and this seemed the least
invasive approach. It also lets us not change behaviour for
the rest of the drivers until they are audited and potentially
updated. At best I can test/hack on ath5k and ath9k. These are
touchy enough, and other drivers may be even more twitchy...
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [RFC PATCH 10/17] zd1211rw: implement beacon fetching and handling ieee80211_get_buffered_bc()
From: Christian Lamparter @ 2011-01-20 17:43 UTC (permalink / raw)
To: Jussi Kivilinna; +Cc: linux-wireless, Daniel Drake, Ulrich Kunitz
In-Reply-To: <20110120101606.53052h18mlpyp8w0@hayate.sektori.org>
On Thursday 20 January 2011 09:16:06 Jussi Kivilinna wrote:
> Quoting Christian Lamparter <chunkeey@googlemail.com>:
>> On Wednesday 19 January 2011 19:49:03 Jussi Kivilinna wrote:
>>> Quoting Christian Lamparter <chunkeey@googlemail.com>:
>>>> On Sunday 09 January 2011 16:46:56 Jussi Kivilinna wrote:
>>>>> Quoting Christian Lamparter <chunkeey@googlemail.com>:
>>>>>> Since zd_beacon_done also uploads the next beacon so long in advance,
>>>>>> there could be an equally long race between the outdated state of the
>>>>>> next beacon's DTIM broadcast traffic indicator (802.11-2007 7.3.2.6)
>>>>>> which -in your case- was uploaded almost a beacon interval ago and
>>>>>> the xmit of ieee80211_get_buffered_bc *now*.
>>>>>>
>>>>>> The dtim bc/mc bit might be not set, when a mc/bc arrived after the
>>>>>> beacon was uploaded, but before the "beacon done event" from the
>>>>>> hardware. So, dozing stations don't expect the broadcast traffic
>>>>>> and of course, they might miss it completely.
>>>>>>
>>>>>> It's probably better to fix this in mac80211 (see the attached hack).
>>>>>
>>>>> Ok, should I add this to my patchset?
>>>> well, difficult to say. As far as I can say, it should be correct for "your
>>>> case". But, on the other hand: what about solutions that can't buffer
>>>> mc/bc frames (and needs to call ieee80211_get_buffered_bc), however the
>>>> firmware is clever enough to maintain a beacon internally (so they
>>>> won't call ieee80211_beacon_get and only relies on set_tim)?
>>>>
>>>> Sure, it's just a unlikely corner case... In fact, I didn't check if
>>>> that's even possible, but it does sound reasonable to some extend.
>>>
>>> From what I checked none of currect driver/device is such.
>>> Maybe if such device appears then !bss->dtim_bc_mc check in
>>> ieee80211_beacon_add_tim() could be masked with driver flag (something
>>> like
>>> IEEE80211_HW_CAN_AND_HANDLE_BEACON_BUT_STILL_NEEDS_HOST_BROADCAST_PS_BUFFERING).
>>
>> True, but a recent discussion into this matter have made parts of the
>> API you are planning to use sort-of "deprecated"? [I think?]
>>
>> http://marc.info/?l=linux-wireless&m=129463297300480
>>
>> I don't know the exact details, but I'm sure Kvalo does have his reasons.
>> [afaik it has to do with wl12xx, he even explained it once, but I can't
>> find that mail anymore].
>>
>
> What I understood from that thread is that rt2x00/usb doesn't have HW
> buffering and doesn't enable IEEE80211_HW_HOST_BROADCAST_PS_BUFFERING
> (rt2x00/pci does), and yet enables AP-mode. Driver has this comment:
> /*
> * Initialize all hw fields.
> *
> * Don't set IEEE80211_HW_HOST_BROADCAST_PS_BUFFERING unless we are
> * capable of sending the buffered frames out after the DTIM
> * transmission using rt2x00lib_beacondone. This will send out
> * multicast and broadcast traffic immediately instead of buffering it
> * infinitly and thus dropping it after some time.
> */
My bad, you are right. This is not something to worry about anymore.
> > One more thing, is there a tx-control flag to instruct the HW/FW to write
> > the TSF into probe response frames, just like it does for beacons frames?
> >
> > Sure, this feature is far more important for IBSS, but the 802.11-2007
> > specs @11.1.4 says that a STA might use beacons or probe responses to
> > synchronize its timers. [However 11.1.1.1 and 11.1.3.4 say that STAs
> > should "only" pick this information from beacons, if I'm not mistaken?!]
> > (Also a uniform "0..0" timestamp in every probe-response looks so sad.)
> >
>
> No such flag I'm afraid. Vendor driver appears to be reading
> tsf-register from driver and writing value to probe response frames,
> maybe something I should add to zd1211rw too.
It's more of a cosmetic thing, but very difficult to get it right without
firmware/hw support [over an usb]. So you might just leave it as it
is...
Best regards,
Christian
^ permalink raw reply
* Re: [RFC 2/3] mac80211: Support scanning only current active channel.
From: Johannes Berg @ 2011-01-20 17:39 UTC (permalink / raw)
To: greearb; +Cc: linux-wireless
In-Reply-To: <1295544750-6704-2-git-send-email-greearb@candelatech.com>
On Thu, 2011-01-20 at 09:32 -0800, greearb@candelatech.com wrote:
> - ieee80211_offchannel_stop_beaconing(local);
> + if (local->ops->sw_scan_start_cur &&
> + local->scan_req->n_channels == 1 &&
> + local->scan_req->channels[0] == local->hw.conf.channel) {
> + __set_bit(SCAN_ON_CUR_CHANNEL, &local->scanning);
> + drv_sw_scan_start_cur(local, true);
> + } else
> + drv_sw_scan_start(local);
This doesn't seem to make much sense either -- even if we do a scan over
multiple channels we should be able to optimise the part on the current
channel (maybe put it at the beginning or end too).
johannes
^ permalink raw reply
* Re: [RFC 1/3] mac80211: Support sw_scan_start_cur
From: Johannes Berg @ 2011-01-20 17:37 UTC (permalink / raw)
To: greearb; +Cc: linux-wireless
In-Reply-To: <1295544750-6704-1-git-send-email-greearb@candelatech.com>
On Thu, 2011-01-20 at 09:32 -0800, greearb@candelatech.com wrote:
> From: Ben Greear <greearb@candelatech.com>
>
> This method is called when driver can support
> scanning the currect active channel without otherwise
> impeding traffic on that channel. The mac80211 scan
> logic may call this when we are only scanning on the
> active channel and thus do not need to go off channel.
I frankly don't see any point telling the driver about this. Looking at
the ath9k patch you sent, it seems to avoid some things like flushing --
but the flushing should be controlled by mac80211 already (or converted
to be) so that it's not necessary to have this.
johannes
^ permalink raw reply
* [RFC 2/3] mac80211: Support scanning only current active channel.
From: greearb @ 2011-01-20 17:32 UTC (permalink / raw)
To: linux-wireless; +Cc: Ben Greear
In-Reply-To: <1295544750-6704-1-git-send-email-greearb@candelatech.com>
From: Ben Greear <greearb@candelatech.com>
This allows user-space to request scan on only the current
channel and have that not interfere with other traffic.
Especially useful when using virtual stations that must
all run on the same channel anyway.
Signed-off-by: Ben Greear <greearb@candelatech.com>
---
:100644 100644 78af32d... 7cd7af8... M net/mac80211/driver-ops.h
:100644 100644 fbabbc2... 8c6d253... M net/mac80211/driver-trace.h
:100644 100644 c47d7c0... 388db0e... M net/mac80211/ieee80211_i.h
:100644 100644 1236710... b1767a5... M net/mac80211/rx.c
:100644 100644 fb274db... b42e5ad... M net/mac80211/scan.c
net/mac80211/driver-ops.h | 12 ++++++++
net/mac80211/driver-trace.h | 18 ++++++++++++
net/mac80211/ieee80211_i.h | 3 ++
net/mac80211/rx.c | 1 +
net/mac80211/scan.c | 61 +++++++++++++++++++++++++++++++-----------
5 files changed, 79 insertions(+), 16 deletions(-)
diff --git a/net/mac80211/driver-ops.h b/net/mac80211/driver-ops.h
index 78af32d..7cd7af8 100644
--- a/net/mac80211/driver-ops.h
+++ b/net/mac80211/driver-ops.h
@@ -201,6 +201,18 @@ static inline void drv_sw_scan_start(struct ieee80211_local *local)
trace_drv_return_void(local);
}
+static inline void drv_sw_scan_start_cur(struct ieee80211_local *local,
+ bool cur_channel_only)
+{
+ might_sleep();
+
+ trace_drv_sw_scan_start_cur(local);
+ if (local->ops->sw_scan_start_cur)
+ local->ops->sw_scan_start_cur(&local->hw,
+ cur_channel_only);
+ trace_drv_return_void(local);
+}
+
static inline void drv_sw_scan_complete(struct ieee80211_local *local)
{
might_sleep();
diff --git a/net/mac80211/driver-trace.h b/net/mac80211/driver-trace.h
index fbabbc2..8c6d253 100644
--- a/net/mac80211/driver-trace.h
+++ b/net/mac80211/driver-trace.h
@@ -457,6 +457,24 @@ TRACE_EVENT(drv_sw_scan_start,
)
);
+TRACE_EVENT(drv_sw_scan_start_cur,
+ TP_PROTO(struct ieee80211_local *local),
+
+ TP_ARGS(local),
+
+ TP_STRUCT__entry(
+ LOCAL_ENTRY
+ ),
+
+ TP_fast_assign(
+ LOCAL_ASSIGN;
+ ),
+
+ TP_printk(
+ LOCAL_PR_FMT, LOCAL_PR_ARG
+ )
+);
+
TRACE_EVENT(drv_sw_scan_complete,
TP_PROTO(struct ieee80211_local *local),
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index c47d7c0..388db0e 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -660,6 +660,8 @@ struct tpt_led_trigger {
* that the scan completed.
* @SCAN_ABORTED: Set for our scan work function when the driver reported
* a scan complete for an aborted scan.
+ * @SCAN_ON_CUR_CHANNEL: Set when we are scanning only on the current
+ * channel. This means no off/on-channel logic needs to be run.
*/
enum {
SCAN_SW_SCANNING,
@@ -667,6 +669,7 @@ enum {
SCAN_OFF_CHANNEL,
SCAN_COMPLETED,
SCAN_ABORTED,
+ SCAN_ON_CUR_CHANNEL,
};
/**
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index 1236710..b1767a5 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -2749,6 +2749,7 @@ static void __ieee80211_rx_handle_packet(struct ieee80211_hw *hw,
local->dot11ReceivedFragmentCount++;
if (unlikely(test_bit(SCAN_HW_SCANNING, &local->scanning) ||
+ test_bit(SCAN_ON_CUR_CHANNEL, &local->scanning) ||
test_bit(SCAN_OFF_CHANNEL, &local->scanning)))
status->rx_flags |= IEEE80211_RX_IN_SCAN;
diff --git a/net/mac80211/scan.c b/net/mac80211/scan.c
index fb274db..b42e5ad 100644
--- a/net/mac80211/scan.c
+++ b/net/mac80211/scan.c
@@ -293,11 +293,17 @@ static void __ieee80211_scan_completed_finish(struct ieee80211_hw *hw,
{
struct ieee80211_local *local = hw_to_local(hw);
- ieee80211_hw_config(local, IEEE80211_CONF_CHANGE_CHANNEL);
+ if (!test_bit(SCAN_ON_CUR_CHANNEL, &local->scanning))
+ ieee80211_hw_config(local, IEEE80211_CONF_CHANGE_CHANNEL);
+
if (!was_hw_scan) {
ieee80211_configure_filter(local);
drv_sw_scan_complete(local);
- ieee80211_offchannel_return(local, true);
+ if (!test_bit(SCAN_ON_CUR_CHANNEL, &local->scanning))
+ /* Don't call this if we never left the channel. */
+ ieee80211_offchannel_return(local, true);
+ else
+ __clear_bit(SCAN_ON_CUR_CHANNEL, &local->scanning);
}
mutex_lock(&local->mtx);
@@ -338,15 +344,28 @@ static int ieee80211_start_sw_scan(struct ieee80211_local *local)
* nullfunc frames and probe requests will be dropped in
* ieee80211_tx_h_check_assoc().
*/
- drv_sw_scan_start(local);
- ieee80211_offchannel_stop_beaconing(local);
+ if (local->ops->sw_scan_start_cur &&
+ local->scan_req->n_channels == 1 &&
+ local->scan_req->channels[0] == local->hw.conf.channel) {
+ __set_bit(SCAN_ON_CUR_CHANNEL, &local->scanning);
+ drv_sw_scan_start_cur(local, true);
+ } else
+ drv_sw_scan_start(local);
+
+ /* If we are scanning one channel, and only our own channel
+ * then we don't need to call the off-channel logic.
+ */
+ if (!test_bit(SCAN_ON_CUR_CHANNEL, &local->scanning)) {
+ ieee80211_offchannel_stop_beaconing(local);
+ local->leave_oper_channel_time = 0;
+ }
- local->leave_oper_channel_time = 0;
local->next_scan_state = SCAN_DECISION;
local->scan_channel_idx = 0;
- drv_flush(local, false);
+ if (!test_bit(SCAN_ON_CUR_CHANNEL, &local->scanning))
+ drv_flush(local, false);
ieee80211_configure_filter(local);
@@ -522,10 +541,14 @@ static void ieee80211_scan_state_decision(struct ieee80211_local *local,
local->next_scan_state = SCAN_SET_CHANNEL;
} else {
/*
- * we're on the operating channel currently, let's
- * leave that channel now to scan another one
+ * We're on the operating channel currently, Leave that
+ * channel only if we are probing more than the current
+ * channel.
*/
- local->next_scan_state = SCAN_LEAVE_OPER_CHANNEL;
+ if (test_bit(SCAN_ON_CUR_CHANNEL, &local->scanning))
+ local->next_scan_state = SCAN_SET_CHANNEL;
+ else
+ local->next_scan_state = SCAN_LEAVE_OPER_CHANNEL;
}
*next_delay = 0;
@@ -559,14 +582,19 @@ static void ieee80211_scan_state_enter_oper_channel(struct ieee80211_local *loca
{
/* switch back to the operating channel */
local->scan_channel = NULL;
- ieee80211_hw_config(local, IEEE80211_CONF_CHANGE_CHANNEL);
- /*
- * Only re-enable station mode interface now; beaconing will be
- * re-enabled once the full scan has been completed.
+ /* We only return if we ever left, and should never leave if
+ * scanning single channel that is also the operating channel.
*/
- ieee80211_offchannel_return(local, false);
+ if (!test_bit(SCAN_ON_CUR_CHANNEL, &local->scanning)) {
+ ieee80211_hw_config(local, IEEE80211_CONF_CHANGE_CHANNEL);
+ /*
+ * Only re-enable station mode interface now; beaconing will be
+ * re-enabled once the full scan has been completed.
+ */
+ ieee80211_offchannel_return(local, false);
+ }
__clear_bit(SCAN_OFF_CHANNEL, &local->scanning);
*next_delay = HZ / 5;
@@ -583,8 +611,9 @@ static void ieee80211_scan_state_set_channel(struct ieee80211_local *local,
chan = local->scan_req->channels[local->scan_channel_idx];
local->scan_channel = chan;
- if (ieee80211_hw_config(local, IEEE80211_CONF_CHANGE_CHANNEL))
- skip = 1;
+ if (local->hw.conf.channel != chan)
+ if (ieee80211_hw_config(local, IEEE80211_CONF_CHANGE_CHANNEL))
+ skip = 1;
/* advance state machine to next channel/band */
local->scan_channel_idx++;
--
1.7.2.3
^ permalink raw reply related
* [RFC 1/3] mac80211: Support sw_scan_start_cur
From: greearb @ 2011-01-20 17:32 UTC (permalink / raw)
To: linux-wireless; +Cc: Ben Greear
From: Ben Greear <greearb@candelatech.com>
This method is called when driver can support
scanning the currect active channel without otherwise
impeding traffic on that channel. The mac80211 scan
logic may call this when we are only scanning on the
active channel and thus do not need to go off channel.
Signed-off-by: Ben Greear <greearb@candelatech.com>
---
:100644 100644 d6b0045... 3e89ae7... M include/net/mac80211.h
include/net/mac80211.h | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index d6b0045..3e89ae7 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -1672,6 +1672,12 @@ enum ieee80211_ampdu_mlme_action {
* is started. Can be NULL, if the driver doesn't need this notification.
* The callback can sleep.
*
+ * @sw_scan_start_cur: Notifier function that is called just before a software
+ * scan on only the current channel is started. If NULL, sw_scan_start
+ * will be used instead. sw_scan_start_cur with second argument set to
+ * false should be treated identically to sw_scan_start.
+ * The callback can sleep.
+ *
* @sw_scan_complete: Notifier function that is called just after a
* software scan finished. Can be NULL, if the driver doesn't need
* this notification.
@@ -1820,6 +1826,8 @@ struct ieee80211_ops {
int (*hw_scan)(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
struct cfg80211_scan_request *req);
void (*sw_scan_start)(struct ieee80211_hw *hw);
+ void (*sw_scan_start_cur)(struct ieee80211_hw *hw,
+ bool cur_channel_only);
void (*sw_scan_complete)(struct ieee80211_hw *hw);
int (*get_stats)(struct ieee80211_hw *hw,
struct ieee80211_low_level_stats *stats);
--
1.7.2.3
^ permalink raw reply related
* [RFC 3/3] ath9k: Support scanning on current channel.
From: greearb @ 2011-01-20 17:32 UTC (permalink / raw)
To: linux-wireless; +Cc: Ben Greear
In-Reply-To: <1295544750-6704-1-git-send-email-greearb@candelatech.com>
From: Ben Greear <greearb@candelatech.com>
This adds support for scanning on only the current
channel. We do not need to flush xmit queues or
otherwise impede traffic in this scenario.
Signed-off-by: Ben Greear <greearb@candelatech.com>
---
:100644 100644 dab0271... fa5bd0d... M drivers/net/wireless/ath/ath9k/ath9k.h
:100644 100644 333486d... ef182d1... M drivers/net/wireless/ath/ath9k/debug.c
:100644 100644 f01de0e... a2454ba... M drivers/net/wireless/ath/ath9k/main.c
:100644 100644 d205c66... 261a68a... M drivers/net/wireless/ath/ath9k/virtual.c
drivers/net/wireless/ath/ath9k/ath9k.h | 1 +
drivers/net/wireless/ath/ath9k/debug.c | 2 ++
drivers/net/wireless/ath/ath9k/main.c | 22 ++++++++++++++++++----
drivers/net/wireless/ath/ath9k/virtual.c | 6 ++++--
4 files changed, 25 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ath9k.h b/drivers/net/wireless/ath/ath9k/ath9k.h
index dab0271..fa5bd0d 100644
--- a/drivers/net/wireless/ath/ath9k/ath9k.h
+++ b/drivers/net/wireless/ath/ath9k/ath9k.h
@@ -672,6 +672,7 @@ struct ath_wiphy {
ATH_WIPHY_PAUSING,
ATH_WIPHY_PAUSED,
ATH_WIPHY_SCAN,
+ ATH_WIPHY_SCAN_CUR,
} state;
bool idle;
int chan_idx;
diff --git a/drivers/net/wireless/ath/ath9k/debug.c b/drivers/net/wireless/ath/ath9k/debug.c
index 333486d..ef182d1 100644
--- a/drivers/net/wireless/ath/ath9k/debug.c
+++ b/drivers/net/wireless/ath/ath9k/debug.c
@@ -394,6 +394,8 @@ static const char * ath_wiphy_state_str(enum ath_wiphy_state state)
return "PAUSED";
case ATH_WIPHY_SCAN:
return "SCAN";
+ case ATH_WIPHY_SCAN_CUR:
+ return "SCAN_CUR";
}
return "?";
}
diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
index f01de0e..a2454ba 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -1220,7 +1220,9 @@ static int ath9k_tx(struct ieee80211_hw *hw,
struct ath_tx_control txctl;
struct ieee80211_hdr *hdr = (struct ieee80211_hdr *) skb->data;
- if (aphy->state != ATH_WIPHY_ACTIVE && aphy->state != ATH_WIPHY_SCAN) {
+ if (aphy->state != ATH_WIPHY_ACTIVE &&
+ aphy->state != ATH_WIPHY_SCAN_CUR &&
+ aphy->state != ATH_WIPHY_SCAN) {
ath_dbg(common, ATH_DBG_XMIT,
"ath9k: %s: TX in unexpected wiphy state %d\n",
wiphy_name(hw->wiphy), aphy->state);
@@ -1803,6 +1805,7 @@ static int ath9k_config(struct ieee80211_hw *hw, u32 changed)
sc->sc_flags &= ~SC_OP_OFFCHANNEL;
if (aphy->state == ATH_WIPHY_SCAN ||
+ aphy->state == ATH_WIPHY_SCAN_CUR ||
aphy->state == ATH_WIPHY_ACTIVE)
ath9k_wiphy_pause_all_forced(sc, aphy);
else {
@@ -2262,7 +2265,8 @@ static int ath9k_get_survey(struct ieee80211_hw *hw, int idx,
return 0;
}
-static void ath9k_sw_scan_start(struct ieee80211_hw *hw)
+static void ath9k_sw_scan_start_cur(struct ieee80211_hw *hw,
+ bool cur_only)
{
struct ath_wiphy *aphy = hw->priv;
struct ath_softc *sc = aphy->sc;
@@ -2280,11 +2284,20 @@ static void ath9k_sw_scan_start(struct ieee80211_hw *hw)
return;
}
- aphy->state = ATH_WIPHY_SCAN;
- ath9k_wiphy_pause_all_forced(sc, aphy);
+ if (cur_only)
+ aphy->state = ATH_WIPHY_SCAN_CUR;
+ else {
+ aphy->state = ATH_WIPHY_SCAN;
+ ath9k_wiphy_pause_all_forced(sc, aphy);
+ }
mutex_unlock(&sc->mutex);
}
+static void ath9k_sw_scan_start(struct ieee80211_hw *hw)
+{
+ ath9k_sw_scan_start_cur(hw, false);
+}
+
/*
* XXX: this requires a revisit after the driver
* scan_complete gets moved to another place/removed in mac80211.
@@ -2331,6 +2344,7 @@ struct ieee80211_ops ath9k_ops = {
.ampdu_action = ath9k_ampdu_action,
.get_survey = ath9k_get_survey,
.sw_scan_start = ath9k_sw_scan_start,
+ .sw_scan_start_cur = ath9k_sw_scan_start_cur,
.sw_scan_complete = ath9k_sw_scan_complete,
.rfkill_poll = ath9k_rfkill_poll_state,
.set_coverage_class = ath9k_set_coverage_class,
diff --git a/drivers/net/wireless/ath/ath9k/virtual.c b/drivers/net/wireless/ath/ath9k/virtual.c
index d205c66..261a68a 100644
--- a/drivers/net/wireless/ath/ath9k/virtual.c
+++ b/drivers/net/wireless/ath/ath9k/virtual.c
@@ -176,11 +176,13 @@ static bool ath9k_wiphy_pausing(struct ath_softc *sc)
static bool __ath9k_wiphy_scanning(struct ath_softc *sc)
{
int i;
- if (sc->pri_wiphy->state == ATH_WIPHY_SCAN)
+ if (sc->pri_wiphy->state == ATH_WIPHY_SCAN ||
+ sc->pri_wiphy->state == ATH_WIPHY_SCAN_CUR)
return true;
for (i = 0; i < sc->num_sec_wiphy; i++) {
if (sc->sec_wiphy[i] &&
- sc->sec_wiphy[i]->state == ATH_WIPHY_SCAN)
+ (sc->sec_wiphy[i]->state == ATH_WIPHY_SCAN ||
+ sc->sec_wiphy[i]->state == ATH_WIPHY_SCAN_CUR))
return true;
}
return false;
--
1.7.2.3
^ permalink raw reply related
* Re: [PATCH] ath9k: Try more than one queue when scheduling new aggregate.
From: Felix Fietkau @ 2011-01-20 17:12 UTC (permalink / raw)
To: greearb; +Cc: linux-wireless, ath9k-devel
In-Reply-To: <1295400600-20596-1-git-send-email-greearb@candelatech.com>
On 2011-01-19 2:30 AM, greearb@candelatech.com wrote:
> From: Ben Greear <greearb@candelatech.com>
>
> Try all xmit queues until the hardware buffers are full.
Acked-by: Felix Fietkau <nbd@openwrt.org>
^ permalink raw reply
* [PATCH wireless-2.6.38] iwlwifi: don't read sku information from EEPROM for 4965
From: Wey-Yi Guy @ 2011-01-20 16:08 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, ipw3945-devel, Wey-Yi Guy
For all the new devices, the sku information should read from EEPROM
but for legacy devices such as 4965, appearly the EEPROM does not
contain the necessary information. so skip the read from EEPROM
and go back to use software configuration.
Reported-by: Helmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Tested-by: Helmut Schaa <helmut.schaa@googlemail.com>
---
this patch is also available from wireless-2.6 branch on
git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-2.6.git
---
drivers/net/wireless/iwlwifi/iwl-4965.c | 1 +
drivers/net/wireless/iwlwifi/iwl-agn-eeprom.c | 11 +++++++----
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-4965.c b/drivers/net/wireless/iwlwifi/iwl-4965.c
index 3f1e5f1..91a9f52 100644
--- a/drivers/net/wireless/iwlwifi/iwl-4965.c
+++ b/drivers/net/wireless/iwlwifi/iwl-4965.c
@@ -2624,6 +2624,7 @@ struct iwl_cfg iwl4965_agn_cfg = {
.fw_name_pre = IWL4965_FW_PRE,
.ucode_api_max = IWL4965_UCODE_API_MAX,
.ucode_api_min = IWL4965_UCODE_API_MIN,
+ .sku = IWL_SKU_A|IWL_SKU_G|IWL_SKU_N,
.valid_tx_ant = ANT_AB,
.valid_rx_ant = ANT_ABC,
.eeprom_ver = EEPROM_4965_EEPROM_VERSION,
diff --git a/drivers/net/wireless/iwlwifi/iwl-agn-eeprom.c b/drivers/net/wireless/iwlwifi/iwl-agn-eeprom.c
index 14ceb4d..27b5a3e 100644
--- a/drivers/net/wireless/iwlwifi/iwl-agn-eeprom.c
+++ b/drivers/net/wireless/iwlwifi/iwl-agn-eeprom.c
@@ -152,11 +152,14 @@ int iwl_eeprom_check_sku(struct iwl_priv *priv)
eeprom_sku = iwl_eeprom_query16(priv, EEPROM_SKU_CAP);
- priv->cfg->sku = ((eeprom_sku & EEPROM_SKU_CAP_BAND_SELECTION) >>
+ if (!priv->cfg->sku) {
+ /* not using sku overwrite */
+ priv->cfg->sku =
+ ((eeprom_sku & EEPROM_SKU_CAP_BAND_SELECTION) >>
EEPROM_SKU_CAP_BAND_POS);
- if (eeprom_sku & EEPROM_SKU_CAP_11N_ENABLE)
- priv->cfg->sku |= IWL_SKU_N;
-
+ if (eeprom_sku & EEPROM_SKU_CAP_11N_ENABLE)
+ priv->cfg->sku |= IWL_SKU_N;
+ }
if (!priv->cfg->sku) {
IWL_ERR(priv, "Invalid device sku\n");
return -EINVAL;
--
1.7.0.4
^ permalink raw reply related
* Re: iwl4965: 11n broken
From: Guy, Wey-Yi @ 2011-01-20 15:49 UTC (permalink / raw)
To: Helmut Schaa; +Cc: linux-wireless@vger.kernel.org, Johannes Berg
In-Reply-To: <201101201646.21583.helmut.schaa@googlemail.com>
On Thu, 2011-01-20 at 07:46 -0800, Helmut Schaa wrote:
> Am Donnerstag, 20. Januar 2011 schrieb Guy, Wey-Yi:
> > Sorry for the mistake, here I attach the patch to address this issue.
> > Please give a try to see if it fix it, I will also push this patch
> > upstream if works for you.
>
> Sure, works fine. Feel free to add a
>
> Tested-by: Helmut Schaa <helmut.schaa@googlemail.com>
>
> to the patch when submitting.
>
Thank you for the quick response and sorry for the mistake
Wey
^ permalink raw reply
* Re: iwl4965: 11n broken
From: Helmut Schaa @ 2011-01-20 15:46 UTC (permalink / raw)
To: Guy, Wey-Yi; +Cc: linux-wireless@vger.kernel.org, Johannes Berg
In-Reply-To: <1295537707.21281.1.camel@wwguy-ubuntu>
Am Donnerstag, 20. Januar 2011 schrieb Guy, Wey-Yi:
> Sorry for the mistake, here I attach the patch to address this issue.
> Please give a try to see if it fix it, I will also push this patch
> upstream if works for you.
Sure, works fine. Feel free to add a
Tested-by: Helmut Schaa <helmut.schaa@googlemail.com>
to the patch when submitting.
Thanks,
Helmut
^ permalink raw reply
* Re: iwl4965: 11n broken
From: Guy, Wey-Yi @ 2011-01-20 15:35 UTC (permalink / raw)
To: Helmut Schaa; +Cc: linux-wireless@vger.kernel.org, Johannes Berg
In-Reply-To: <201101201242.24680.helmut.schaa@googlemail.com>
[-- Attachment #1: Type: text/plain, Size: 1134 bytes --]
Hi Helmut,
On Thu, 2011-01-20 at 03:42 -0800, Helmut Schaa wrote:
> Hi,
>
> I've just updated my workstation to wireless-testing from last
> week (2.6.37-wl-default+). When associating to a 11n router the
> card only associates as 11g, the assoc request doesn't contain
> any HT IEs.
>
> The causing commit is:
>
> commit 21a5b3c6b19a8b8972ccdd55389be28a8b7c9180
> Author: Wey-Yi Guy <wey-yi.w.guy@intel.com>
> Date: Wed Nov 10 13:32:59 2010 -0800
>
> iwlagn: use SKU information in the EEPROM
>
> EEPROM contain the SKU information for the device, use it.
>
> Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
>
>
> Seems as if the device eeprom hasn't set EEPROM_SKU_CAP_11N_ENABLE and thus
> iwlagn thinks the device is not 11n capable.
>
> Ideas? Should we just revert the 4965 part of the patch and modify
> iwl_eeprom_check_sku to allow overwriting the sku field? Do 4965 devices
> exists that are not 11n capable?
>
Sorry for the mistake, here I attach the patch to address this issue.
Please give a try to see if it fix it, I will also push this patch
upstream if works for you.
Thanks
Wey
[-- Attachment #2: 0001-iwlwifi-don-t-read-sku-information-from-EEPROM-for.patch --]
[-- Type: text/x-patch, Size: 2094 bytes --]
>From 98af51fc1635b2b2138e66def03acc1fe8eb8329 Mon Sep 17 00:00:00 2001
From: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Date: Thu, 20 Jan 2011 07:32:06 -0800
Subject: [PATCH 1/1] iwlwifi: don't read sku information from EEPROM for 4965
For all the new devices, the sku information should read from EEPROM
but for legacy devices such as 4965, appearly the EEPROM does not
contain the necessary information. so skip the read from EEPROM
and go back to use software configuration.
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
---
drivers/net/wireless/iwlwifi/iwl-4965.c | 1 +
drivers/net/wireless/iwlwifi/iwl-agn-eeprom.c | 11 +++++++----
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-4965.c b/drivers/net/wireless/iwlwifi/iwl-4965.c
index dada0c3..6eae0b0 100644
--- a/drivers/net/wireless/iwlwifi/iwl-4965.c
+++ b/drivers/net/wireless/iwlwifi/iwl-4965.c
@@ -2621,6 +2621,7 @@ struct iwl_cfg iwl4965_agn_cfg = {
.fw_name_pre = IWL4965_FW_PRE,
.ucode_api_max = IWL4965_UCODE_API_MAX,
.ucode_api_min = IWL4965_UCODE_API_MIN,
+ .sku = IWL_SKU_A|IWL_SKU_G|IWL_SKU_N,
.valid_tx_ant = ANT_AB,
.valid_rx_ant = ANT_ABC,
.eeprom_ver = EEPROM_4965_EEPROM_VERSION,
diff --git a/drivers/net/wireless/iwlwifi/iwl-agn-eeprom.c b/drivers/net/wireless/iwlwifi/iwl-agn-eeprom.c
index 14ceb4d..27b5a3e 100644
--- a/drivers/net/wireless/iwlwifi/iwl-agn-eeprom.c
+++ b/drivers/net/wireless/iwlwifi/iwl-agn-eeprom.c
@@ -152,11 +152,14 @@ int iwl_eeprom_check_sku(struct iwl_priv *priv)
eeprom_sku = iwl_eeprom_query16(priv, EEPROM_SKU_CAP);
- priv->cfg->sku = ((eeprom_sku & EEPROM_SKU_CAP_BAND_SELECTION) >>
+ if (!priv->cfg->sku) {
+ /* not using sku overwrite */
+ priv->cfg->sku =
+ ((eeprom_sku & EEPROM_SKU_CAP_BAND_SELECTION) >>
EEPROM_SKU_CAP_BAND_POS);
- if (eeprom_sku & EEPROM_SKU_CAP_11N_ENABLE)
- priv->cfg->sku |= IWL_SKU_N;
-
+ if (eeprom_sku & EEPROM_SKU_CAP_11N_ENABLE)
+ priv->cfg->sku |= IWL_SKU_N;
+ }
if (!priv->cfg->sku) {
IWL_ERR(priv, "Invalid device sku\n");
return -EINVAL;
--
1.6.0.4
^ permalink raw reply related
* RE: [PATCH] Kernel Panic on Associate with brcm80211.
From: Ilya Kogan @ 2011-01-20 13:51 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <400C43189542CE41BC0A5B252FC90136952F059551@SJEXCHCCR02.corp.ad.broadcom.com>
Hey,
> I posted an official patch (removing the assert) to the staging repository
as
> I did run into this same issue. It will take some time before it is
propagated.
> As this is a staging driver patches are to be sent to
devel@linuxdriverproject.org
> (see http://driverdev.linuxdriverproject.org/pipermail/devel/).
Thanks very much, guess I'm not as crazy as I thought. I'm seeing a lot more
of the
AC_BE txop exceeded phylen errors. For some reason, I cannot maintain TCP
connections either. I haven't had a chance to wireshark the behavior, but
even if
I'm not doing a lot of data transfers, my connections will die randomly with
no indications
as to why. I don't lose my AP association and nothing gets reinitialized.
I'm not sure if
this problem is related to the errors as they don't reliably happen around
when the
connections give out. By the way, in case there's any question, I've
confirmed that the
card works correctly on Windows.
Thanks,
-- Ilya Kogan
^ permalink raw reply
* Re: htc dream wl1251 and MSM_GPIO_TO_INT(29)
From: Denis 'GNUtoo' Carikli @ 2011-01-20 12:55 UTC (permalink / raw)
To: Bob Copeland; +Cc: Kalle Valo, Grazvydas Ignotas, linux-wireless
In-Reply-To: <20110117150853.GC20703@hash.localnet>
> > fail_irq:
> > printk("trout wifi GPIO failed\n");
> > gpio_free(TROUT_WIFI_IRQ_GPIO);
>
> But you always free a gpio here, shouldn't there be a return in there
> before the fail_irq label?
I forgot the return, I wrote/copied(from omap3-pandora ) the code when I
was tired,I shouldn't write code when I'm that tired.
> also make sure you still have the dummy msm_wifi platform device too,
yes I have it
> and
> that the msm_wifi driver is getting a struct wifi_platform_data.
it seem to get it
> Unfortunately, I don't know of an easy way to debug livelocks due to
> interrupt storms other than by disabling everything and then enabling one
> thing at a time until it breaks again.
>
> It's obviously going to be a lot of work, but if you can manage to get
> a current kernel booting on your hardware and dump the msm_wifi module,
> that would be the ideal approach.
I've an old linux-next kernel booting but with no way to control the
phone, fortunately the gadget driver was merged in linux-next recently.
I'll try to resolve some compilation issues and to make it work first.
Denis.
^ permalink raw reply
* RE: [PATCH] Kernel Panic on Associate with brcm80211.
From: Arend Van Spriel @ 2011-01-20 12:23 UTC (permalink / raw)
To: zach, linux-wireless@vger.kernel.org
In-Reply-To: <loom.20110120T120235-29@post.gmane.org>
Hi Zach, Ilya,
I posted an official patch (removing the assert) to the staging repository as I did run into this same issue. It will take some time before it is propagated. As this is a staging driver patches are to be sent to devel@linuxdriverproject.org (see http://driverdev.linuxdriverproject.org/pipermail/devel/).
Gr. AvS
________________________________________
From: linux-wireless-owner@vger.kernel.org [linux-wireless-owner@vger.kernel.org] On Behalf Of zach [conflatulence@gmail.com]
Sent: Thursday, January 20, 2011 12:21 PM
To: linux-wireless@vger.kernel.org
Subject: Re: [PATCH] Kernel Panic on Associate with brcm80211.
Ilya Kogan <ikogan@...> writes:
>
> I'm going to admit I'm fairly new to this but after some reading, I
> couldn't quite understand why there is an assertion ensuring that the
> sk_buff being sent is not cloned. I was going to see what exploded if I
> removed it and to my surprise...nothing did. In fact, except for a few
>
> [12014.013409] wl0: wlc_d11hdrs_mac80211: AC_BE txop exceeded phylen
> 382/256 dur 3562/1504
>
> things seem to work fine. I'll be doing some more testing with this over
> the next couple of days. What obvious thing does this break horribly?
>
Hi, I think I had the same panic on emachines em350 with BCM4313 using Fedora 14
and kernel 2.6.38-rc1. Network manager applet shows little blue dots going round
and then panic. Applying your change solved it. Thanks!
Photo of panic
http://picasaweb.google.com/lh/photo/hWEO_uFGNO-jAKjqhyJvkLevz6n8KX8fvZ44UIlA3yw?feat=directlink
config http://pastebin.com/9z8AmJ3E
zach
--
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
* iwl4965: 11n broken
From: Helmut Schaa @ 2011-01-20 11:42 UTC (permalink / raw)
To: linux-wireless; +Cc: Wey-Yi Guy, Johannes Berg
Hi,
I've just updated my workstation to wireless-testing from last
week (2.6.37-wl-default+). When associating to a 11n router the
card only associates as 11g, the assoc request doesn't contain
any HT IEs.
The causing commit is:
commit 21a5b3c6b19a8b8972ccdd55389be28a8b7c9180
Author: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Date: Wed Nov 10 13:32:59 2010 -0800
iwlagn: use SKU information in the EEPROM
EEPROM contain the SKU information for the device, use it.
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Seems as if the device eeprom hasn't set EEPROM_SKU_CAP_11N_ENABLE and thus
iwlagn thinks the device is not 11n capable.
Ideas? Should we just revert the 4965 part of the patch and modify
iwl_eeprom_check_sku to allow overwriting the sku field? Do 4965 devices
exists that are not 11n capable?
Thanks,
Helmut
^ permalink raw reply
* Re: [PATCH] Kernel Panic on Associate with brcm80211.
From: zach @ 2011-01-20 11:21 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <4D3521FD.9020001@mythicnet.org>
Ilya Kogan <ikogan@...> writes:
>
> I'm going to admit I'm fairly new to this but after some reading, I
> couldn't quite understand why there is an assertion ensuring that the
> sk_buff being sent is not cloned. I was going to see what exploded if I
> removed it and to my surprise...nothing did. In fact, except for a few
>
> [12014.013409] wl0: wlc_d11hdrs_mac80211: AC_BE txop exceeded phylen
> 382/256 dur 3562/1504
>
> things seem to work fine. I'll be doing some more testing with this over
> the next couple of days. What obvious thing does this break horribly?
>
Hi, I think I had the same panic on emachines em350 with BCM4313 using Fedora 14
and kernel 2.6.38-rc1. Network manager applet shows little blue dots going round
and then panic. Applying your change solved it. Thanks!
Photo of panic
http://picasaweb.google.com/lh/photo/hWEO_uFGNO-jAKjqhyJvkLevz6n8KX8fvZ44UIlA3yw?feat=directlink
config http://pastebin.com/9z8AmJ3E
zach
^ permalink raw reply
* Re: [RFT 0/8] Clean proto/ethernet.h and remove it.
From: Jonas Gorski @ 2011-01-20 11:12 UTC (permalink / raw)
To: Arend Van Spriel
Cc: linux-wireless@vger.kernel.org, devel@linuxdriverproject.org,
gregkh@suse.de, Brett Rudley, Henry Ptasinski, Dowan Kim,
Roland Vossen
In-Reply-To: <400C43189542CE41BC0A5B252FC90136952F05954D@SJEXCHCCR02.corp.ad.broadcom.com>
Hi Arend,
On 20/01/2011, Arend Van Spriel <arend@broadcom.com> wrote:
> The brcm80211 driver is currently a staging driver and as such maintained by
> GregKH
Oh, you are right. I only looked at the brcm80211 entry in
MAINTAINERS, which did no mention of both.
> (git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging-2.6.git). In
> the staging-next branch of that repository similar patches have already been
> posted. Maybe they are still in the queue.
The last commit I could found in staging-2.6.git was from December
16th, so I thought I was safe, but appearently I wasn't. (I also
didn't see that there was a separate ML for staging drivers). Thanks
for the head-up.
So please ignore this patch series ;-).
Regards,
Jonas Gorski
^ permalink raw reply
* Re: carl9170 802.11n-AP
From: Helge Lenz @ 2011-01-20 10:28 UTC (permalink / raw)
To: linux-wireless
Thomas <messier31@...> writes:
>
> Today I tried a different wifi card on the client side, instead of
the Intel
> 5100, but the problem remains the same. The carl9170 driver on my server
> crashes at some point randomly (only in 802.11n mode). The traceback
shows
> the error at tx.c but everytime in a different line. So I guess there
must
> be a race condition somewhere.
>
> Here you can find the error report of some crashes:
> http://www.mikrocontroller.net/attachment/95144/bugreport.txt
>
> Server hardware is a Seagate Dockstar with OpenWrt running on it. I
heard
> from another user with Debian, who has the same problem.
>
> Regards,
>
> Thomas
>
> --
> To unsubscribe from this list: send the line "unsubscribe
linux-wireless" in
> the body of a message to majordomo@...
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
Any news about this issue? I have the same problem on a Seagate Goflex
Net running debian (Linux debian 2.6.35.4 #9 PREEMPT Tue Jan 18 13:03:42
UTC 2011 armv5tel GNU/Linux). The kernel and the wireless drivers
(compat-wireless-v2.6.37-4) are compiled natively on the box and when I
try to transmit some data I get the following errors in dmesg:
------------[ cut here ]------------
[ 1015.070483] WARNING: at
/usr/src/compat-wireless-2.6.37-4/drivers/net/wireless/ath/carl9170/tx.c:1239
carl9170_op_tx+0x628/0x858 [carl9170]()
[ 1015.083442] Modules linked in:
[ 1015.086361] usb 1-1.2: restart device (5)
[ 1015.090604] carl9170 mac80211 ath cfg80211 compat ipv6 hmac
sha1_generic sata_mv mv_cesa [last unloaded: compat]
[ 1015.101057] [<c003058c>] (unwind_backtrace+0x0/0xf0) from
[<c003d6c4>] (warn_slowpath_common+0x4c/0x64)
[ 1015.110504] [<c003d6c4>] (warn_slowpath_common+0x4c/0x64) from
[<c003d6f4>] (warn_slowpath_null+0x18/0x1c)
[ 1015.120248] [<c003d6f4>] (warn_slowpath_null+0x18/0x1c) from
[<bf1841c4>] (carl9170_op_tx+0x628/0x858 [carl9170])
[ 1015.130702] [<bf1841c4>] (carl9170_op_tx+0x628/0x858 [carl9170]) from
[<bf153b8c>] (__ieee80211_tx+0x14c/0x1c8 [mac80211])
[ 1015.141928] [<bf153b8c>] (__ieee80211_tx+0x14c/0x1c8 [mac80211]) from
[<bf153cf4>] (ieee80211_tx+0xec/0x29c [mac80211])
[ 1015.152885] [<bf153cf4>] (ieee80211_tx+0xec/0x29c [mac80211]) from
[<bf1549e0>] (ieee80211_tx_pending+0x138/0x2a8 [mac80211])
[ 1015.164325] [<bf1549e0>] (ieee80211_tx_pending+0x138/0x2a8
[mac80211]) from [<c00426d0>] (tasklet_action+0x84/0xe4)
[ 1015.174835] [<c00426d0>] (tasklet_action+0x84/0xe4) from [<c0042d14>]
(__do_softirq+0x8c/0x124)
[ 1015.183594] [<c0042d14>] (__do_softirq+0x8c/0x124) from [<c0042df4>]
(irq_exit+0x48/0xa0)
[ 1015.191832] [<c0042df4>] (irq_exit+0x48/0xa0) from [<c002b070>]
(asm_do_IRQ+0x70/0x8c)
[ 1015.199799] [<c002b070>] (asm_do_IRQ+0x70/0x8c) from [<c03b15a8>]
(__irq_svc+0x48/0xa8)
[ 1015.207855] Exception stack(0xc04d7f48 to 0xc04d7f90)
[ 1015.212943] 7f40: 000f1d68 000003e8 000f1d68
20000013 c04dd8d8 c04dd8d8
[ 1015.221175] 7f60: c05a6960 c04da330 00024068 56251311 00023f30
00000000 3b0add45 c04d7f90
[ 1015.229394] 7f80: c005cecc c0034608 20000013 ffffffff
[ 1015.234490] [<c03b15a8>] (__irq_svc+0x48/0xa8) from [<c0034608>]
(kirkwood_enter_idle+0x64/0x90)
[ 1015.243342] [<c0034608>] (kirkwood_enter_idle+0x64/0x90) from
[<c02de684>] (cpuidle_idle_call+0xb0/0x110)
[ 1015.252976] [<c02de684>] (cpuidle_idle_call+0xb0/0x110) from
[<c002c9e0>] (cpu_idle+0x60/0xb8)
[ 1015.261649] [<c002c9e0>] (cpu_idle+0x60/0xb8) from [<c0008988>]
(start_kernel+0x280/0x2e0)
[ 1015.269965] [<c0008988>] (start_kernel+0x280/0x2e0) from [<00008034>]
(0x8034)
[ 1015.277231] ---[ end trace 2ef0e9214ceebf4c ]---
[ 1515.714312] ------------[ cut here ]------------
[ 1515.719006] WARNING: at
/usr/src/compat-wireless-2.6.37-4/drivers/net/wireless/ath/carl9170/tx.c:300
carl9170_tx_status+0x230/0x3e4 [carl9170]()
[ 1515.732047] Modules linked in: carl9170 mac80211 ath cfg80211 compat
ipv6 hmac sha1_generic sata_mv mv_cesa [last unloaded: compat]
[ 1515.744065] [<c003058c>] (unwind_backtrace+0x0/0xf0) from
[<c003d6c4>] (warn_slowpath_common+0x4c/0x64)
[ 1515.753525] [<c003d6c4>] (warn_slowpath_common+0x4c/0x64) from
[<c003d6f4>] (warn_slowpath_null+0x18/0x1c)
[ 1515.763263] [<c003d6f4>] (warn_slowpath_null+0x18/0x1c) from
[<bf183388>] (carl9170_tx_status+0x230/0x3e4 [carl9170])
[ 1515.773980] [<bf183388>] (carl9170_tx_status+0x230/0x3e4 [carl9170])
from [<bf184320>] (carl9170_op_tx+0x784/0x858 [carl9170])
[ 1515.785557] [<bf184320>] (carl9170_op_tx+0x784/0x858 [carl9170]) from
[<bf153b8c>] (__ieee80211_tx+0x14c/0x1c8 [mac80211])
[ 1515.797154] [<bf153b8c>] (__ieee80211_tx+0x14c/0x1c8 [mac80211]) from
[<bf153cf4>] (ieee80211_tx+0xec/0x29c [mac80211])
[ 1515.808120] [<bf153cf4>] (ieee80211_tx+0xec/0x29c [mac80211]) from
[<bf15406c>] (ieee80211_xmit+0x1c8/0x1fc [mac80211])
[ 1515.819079] [<bf15406c>] (ieee80211_xmit+0x1c8/0x1fc [mac80211]) from
[<bf15538c>] (ieee80211_subif_start_xmit+0x804/0x83c [mac80211])
[ 1515.831306] [<bf15538c>] (ieee80211_subif_start_xmit+0x804/0x83c
[mac80211]) from [<c0315020>] (dev_hard_start_xmit+0x2a0/0x3ac)
[ 1515.842948] [<c0315020>] (dev_hard_start_xmit+0x2a0/0x3ac) from
[<c03273d8>] (sch_direct_xmit+0x80/0x204)
[ 1515.852580] [<c03273d8>] (sch_direct_xmit+0x80/0x204) from
[<c03155d0>] (dev_queue_xmit+0x368/0x5b0)
[ 1515.861785] [<c03155d0>] (dev_queue_xmit+0x368/0x5b0) from
[<c035ecf0>] (arp_process+0x32c/0x6f8)
[ 1515.870722] [<c035ecf0>] (arp_process+0x32c/0x6f8) from [<c0313fd0>]
(__netif_receive_skb+0x474/0x4cc)
[ 1515.880134] [<c0313fd0>] (__netif_receive_skb+0x474/0x4cc) from
[<bf14ef58>] (ieee80211_deliver_skb+0x130/0x168 [mac80211])
[ 1515.891445] [<bf14ef58>] (ieee80211_deliver_skb+0x130/0x168
[mac80211]) from [<bf150614>] (ieee80211_rx_handlers+0x1308/0x18b0
[mac80211])
[ 1515.904526] [<bf150614>] (ieee80211_rx_handlers+0x1308/0x18b0
[mac80211]) from [<bf1514c8>]
(ieee80211_prepare_and_rx_handle+0x90c/0x960 [mac80211])
[ 1515.918092] [<bf1514c8>] (ieee80211_prepare_and_rx_handle+0x90c/0x960
[mac80211]) from [<bf151d88>] (ieee80211_rx+0x86c/0x924 [mac80211])
[ 1515.930594] [<bf151d88>] (ieee80211_rx+0x86c/0x924 [mac80211]) from
[<bf185100>] (__carl9170_rx+0x808/0x860 [carl9170])
[ 1515.941482] [<bf185100>] (__carl9170_rx+0x808/0x860 [carl9170]) from
[<bf185328>] (carl9170_rx_stream+0x1d0/0x334 [carl9170])
[ 1515.952890] [<bf185328>] (carl9170_rx_stream+0x1d0/0x334 [carl9170])
from [<bf17d61c>] (carl9170_usb_tasklet+0x68/0xcc [carl9170])
[ 1515.964720] [<bf17d61c>] (carl9170_usb_tasklet+0x68/0xcc [carl9170])
from [<c00425f0>] (tasklet_hi_action+0x88/0xe4)
[ 1515.975565] [<c00425f0>] (tasklet_hi_action+0x88/0xe4) from
[<c0042d14>] (__do_softirq+0x8c/0x124)
[ 1515.984582] [<c0042d14>] (__do_softirq+0x8c/0x124) from [<c0042df4>]
(irq_exit+0x48/0xa0)
[ 1515.992821] [<c0042df4>] (irq_exit+0x48/0xa0) from [<c002b070>]
(asm_do_IRQ+0x70/0x8c)
[ 1516.000943] [<c002b070>] (asm_do_IRQ+0x70/0x8c) from [<c03b15a8>]
(__irq_svc+0x48/0xa8)
[ 1516.008990] Exception stack(0xc04d7f48 to 0xc04d7f90)
[ 1516.014083] 7f40: 0009c1d3 000003e8 0009c1d3
20000013 c04dd868 c04dd878
[ 1516.022312] 7f60: c05a6960 c04da330 00024068 56251311 00023f30
00000000 261d2322 c04d7f90
[ 1516.030531] 7f80: c005cecc c0034608 20000013 ffffffff
[ 1516.035628] [<c03b15a8>] (__irq_svc+0x48/0xa8) from [<c0034608>]
(kirkwood_enter_idle+0x64/0x90)
[ 1516.044480] [<c0034608>] (kirkwood_enter_idle+0x64/0x90) from
[<c02de684>] (cpuidle_idle_call+0xb0/0x110)
[ 1516.054112] [<c02de684>] (cpuidle_idle_call+0xb0/0x110) from
[<c002c9e0>] (cpu_idle+0x60/0xb8)
[ 1516.062786] [<c002c9e0>] (cpu_idle+0x60/0xb8) from [<c0008988>]
(start_kernel+0x280/0x2e0)
[ 1516.071111] [<c0008988>] (start_kernel+0x280/0x2e0) from [<00008034>]
(0x8034)
[ 1516.078367] ---[ end trace 2ef0e9214ceebf4d ]---
If I can do anything to debug the error any further I am more then
willing to help.
Thanks, Helge.
^ permalink raw reply
* Re: [RFC 1/4] mac80211: support for IEEE80211N in IBSS
From: Johannes Berg @ 2011-01-20 10:20 UTC (permalink / raw)
To: Alexander Simon; +Cc: linux-wireless
In-Reply-To: <loom.20110120T110320-779@post.gmane.org>
On Thu, 2011-01-20 at 10:15 +0000, Alexander Simon wrote:
> > Of course I'd accept that Reducing duplicated code is good, and I
> > can deal with patches touching many files. Though it'd be nice to do the
> > necessary refactoring first.
> Ok give me some time and I'll have a look at util.c.
Thanks.
> > A nice touch, btw, would be if you included a diffstat. Maybe you should
> > look at using quilt or git to submit patches which help you automate a
> > lot of things.
> Actually I don't like git, but when this is getting something bigger,I'll agree
> to use it :)
I personally rarely use it for the kernel (even if I know how to very
well), mostly because rebasing is slow for me ... quilt helps a lot too.
If you intend to submit more patches than this series I suggest you
learn at least one of them, it'll make your life easier :-)
> > I'm sorry, I don't understand what you mean by "a separate option"? With
> > the approach that you've posted patches for you need to tell iw whether
> > you want HT or not, right?
> What i mean is, right now there's just one option - setting the HT channel.
> There could be less (the card automatically enables HT and uses it for a station
> that advertises HT), or even more (as in hostapd.confs HT section). Or there
> could be a module option to switch ht for ibss on or off. So, i'm asking about
> the "ideal" interface...
Hmm, I guess you have a point there -- restricting it to HT40- doesn't
make much sense since then you can't merge with another IBSS that is
using HT40+. I guess just enable/disable HT makes more sense?
johannes
^ 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