* [PATCH v4 00/18] AP mode support for wl12xx
From: Arik Nemtsov @ 2010-12-29 23:31 UTC (permalink / raw)
To: linux-wireless; +Cc: Luciano Coelho, Arik Nemtsov
These patches add access point mode support to the wl12xx driver.
This mode uses a separate firmware and has a different initialization
sequence.
In all instances, the flow has been split according to the operating
mode of the driver (AP/STA), so as not to affect STA mode functionality.
v1->2: rebased on latest wl12xx tree
v2->3: refactoring
v3->4: cross-patch fix
Arik Nemtsov (18):
wl1271: Add AP related configuration to conf_drv_settings
wl1271: AP mode - AP specific CMD_CONFIGURE sub-commands
wl1271: AP mode - add AP specific event
wl1271: AP-mode high level commands
wl1271: AP mode - workaround for FW bug on station remove
wl1271: AP mode - init sequence
wl1271: AP specific RX filter configuration
wl1271: Add AP related definitions to HOST-FW interface
wl1271: Configure AP on BSS info change
wl1271: AP mode config in ieee80211_ops.config
wl1271: AP mode - change filter config
wl1271: AP mode - add STA add/remove ops
wl1271: AP mode - changes in TX path
wl1271: AP mode - record TX configuration settings
wl1271: AP mode - encryption support
wl1271: AP mode - fetch appropriate firmware for AP
wl1271: Read MAC address from NVS file on HW startup
wl1271: Enable AP-mode
drivers/net/wireless/wl12xx/acx.c | 62 ++-
drivers/net/wireless/wl12xx/acx.h | 29 +-
drivers/net/wireless/wl12xx/boot.c | 11 +-
drivers/net/wireless/wl12xx/cmd.c | 300 +++++++++-
drivers/net/wireless/wl12xx/cmd.h | 147 ++++-
drivers/net/wireless/wl12xx/conf.h | 52 ++-
drivers/net/wireless/wl12xx/event.c | 7 +-
drivers/net/wireless/wl12xx/event.h | 8 +-
drivers/net/wireless/wl12xx/init.c | 352 ++++++++---
drivers/net/wireless/wl12xx/init.h | 2 +-
drivers/net/wireless/wl12xx/main.c | 955 +++++++++++++++++++++-------
drivers/net/wireless/wl12xx/rx.c | 11 +
drivers/net/wireless/wl12xx/rx.h | 11 +-
drivers/net/wireless/wl12xx/tx.c | 105 +++-
drivers/net/wireless/wl12xx/tx.h | 10 +-
drivers/net/wireless/wl12xx/wl12xx.h | 68 ++-
drivers/net/wireless/wl12xx/wl12xx_80211.h | 5 +
17 files changed, 1770 insertions(+), 365 deletions(-)
^ permalink raw reply
* 2.6.37-rc8: Reported regressions 2.6.35 -> 2.6.36
From: Rafael J. Wysocki @ 2010-12-29 23:18 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Maciej Rutecki, Florian Mickler, Andrew Morton, Linus Torvalds,
Kernel Testers List, Network Development, Linux ACPI,
Linux PM List, Linux SCSI List, Linux Wireless List, DRI
[NOTE: This most likely is the last summary report of regressions introduced
between 2.6.35 and 2.6.36.]
This message contains a list of some post-2.6.35 regressions introduced before
2.6.36, for which there are no fixes in the mainline known to the tracking team.
If any of them have been fixed already, please let us know.
If you know of any other unresolved post-2.6.35 regressions, please let us know
either and we'll add them to the list. Also, please let us know if any
of the entries below are invalid.
Each entry from the list will be sent additionally in an automatic reply to
this message with CCs to the people involved in reporting and handling the
issue.
Listed regressions statistics:
Date Total Pending Unresolved
----------------------------------------
2010-12-30 99 22 20
2010-12-19 98 28 23
2010-12-05 95 34 31
2010-11-19 92 38 34
2010-10-17 70 27 27
2010-10-10 56 16 15
2010-10-03 52 16 14
2010-09-26 46 15 13
2010-09-20 38 15 15
2010-09-12 28 14 13
2010-08-30 21 16 15
Unresolved regressions
----------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=24752
Subject : Random crashes easily reproducible with make -j5 - intel i915 - kernel 2.6.36 on intel/nvidia hybrid graphics machine
Submitter : Giacomo <delleceste@gmail.com>
Date : 2010-12-10 8:57 (20 days old)
Message-ID : <AANLkTimkQM94u9iz7FVVjehB0mwDwfkNwKhF2F2tYq-r@mail.gmail.com>
References : http://marc.info/?l=linux-kernel&m=129197146619176&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=24722
Subject : Disconnecting my USB mouse hangs the machine and issues kernel warning
Submitter : Heinz Diehl <htd@fancy-poultry.org>
Date : 2010-12-12 12:42 (18 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=24392
Subject : AGP aperture disabled, worked in 2.6.35
Submitter : Stephen Kitt <steve@sk2.org>
Date : 2010-12-06 06:31 (24 days old)
First-Bad-Commit: http://git.kernel.org/linus/http://git.kernel.org/linus/96576a9e1a0cdb8a43d3af5846be0948f52b4460
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=24202
Subject : [830] drm:intel_prepare_page_flip, *ERROR* Prepared flip multiple times
Submitter : mkkot <marcin2006@gmail.com>
Date : 2010-12-02 14:10 (28 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=23812
Subject : HAL does not provide battery information on RHEL5 and CentOS-5
Submitter : Dag Wieers <dag@wieers.com>
Date : 2010-11-26 18:08 (34 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=22842
Subject : iwl3945 suddenly stops working
Submitter : Felipe Contreras <felipe.contreras@gmail.com>
Date : 2010-11-14 11:14 (46 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=22782
Subject : 2.6.36: general protection fault during lockfs lockspace removal
Submitter : nik@linuxbox.cz <nik@linuxbox.cz>
Date : 2010-11-12 12:05 (48 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=22172
Subject : alsa-util.c: snd_pcm_avail_delay() returned strange values: delay 0 is less than avail 32
Submitter : Tobias <devnull@plzk.org>
Date : 2010-11-06 09:33 (54 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=22092
Subject : Kernel v2.6.36 trouble on USB disconnect
Submitter : Ketil Froyn <ketil@froyn.name>
Date : 2010-10-29 8:05 (62 days old)
Message-ID : <<AANLkTik5qVxkEGVAA1PSOGk2KTW+ekHpSwttsQEWzWj+@mail.gmail.com>>
References : http://marc.info/?l=linux-kernel&m=128833956503607&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=21652
Subject : several problems with intel graphics since 2.6.36
Submitter : Norbert Preining <preining@logic.at>
Date : 2010-10-27 14:32 (64 days old)
Message-ID : <20101027143252.GA8676@gamma.logic.tuwien.ac.at>
References : http://marc.info/?l=linux-kernel&m=128818998630241&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=21402
Subject : [KVM] Noacpi Windows guest can not boot up on 32bit KVM host
Submitter : xudong <xudong.hao@intel.com>
Date : 2010-10-29 03:01 (62 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=20332
Subject : [LogFS] [2.6.36-rc7] Kernel BUG at lib/btree.c:465!
Submitter : Prasad Joshi <prasadjoshi124@gmail.com>
Date : 2010-10-12 18:56 (79 days old)
Message-ID : <AANLkTimAbCZNhLQ5nADUiAC+7JpAeJBEmjFwdxyZ-FxO@mail.gmail.com>
References : http://marc.info/?l=linux-kernel&m=128690910501830&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=20322
Subject : 2.6.36-rc7: inconsistent lock state: inconsistent {IN-RECLAIM_FS-R} -> {RECLAIM_FS-ON-W} usage.
Submitter : Dave Jones <davej@redhat.com>
Date : 2010-10-11 20:10 (80 days old)
Message-ID : <20101011201007.GA29707@redhat.com>
References : http://marc.info/?l=linux-kernel&m=128682782828453&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=20232
Subject : kworker consumes ~100% CPU on HP Elitebook 8540w running 2.6.36_rc6-git4
Submitter : Ozan Caglayan <ozan@pardus.org.tr>
Date : 2010-10-13 06:13 (78 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=19392
Subject : WARNING: at drivers/net/wireless/ath/ath5k/base.c:3475 ath5k_bss_info_changed+0x44/0x168 [ath5k]()
Submitter : Justin Mattock <justinmattock@gmail.com>
Date : 2010-09-28 22:30 (93 days old)
Message-ID : <<AANLkTim5WCGKPvEkOkO_YnMF9pg8mvLfQoFBNUFpfa_k@mail.gmail.com>>
References : http://marc.info/?l=linux-kernel&m=128571307018635&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=19372
Subject : 2.6.36-rc6: WARNING: at drivers/gpu/drm/radeon/radeon_fence.c:235 radeon_fence_wait+0x35a/0x3c0
Submitter : Alexey Dobriyan <adobriyan@gmail.com>
Date : 2010-09-29 21:29 (92 days old)
Message-ID : <20100929212923.GA5578@core2.telecom.by>
References : http://marc.info/?l=linux-kernel&m=128579579400315&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=19052
Subject : 2.6.36-rc5-git1 -- [drm:i915_report_and_clear_eir] *ERROR* EIR stuck: 0x00000010, masking
Submitter : Miles Lane <miles.lane@gmail.com>
Date : 2010-09-22 23:47 (99 days old)
Message-ID : <AANLkTikWQjUQjFJU9MO1+XbSLAEE-GARz+S+Dz2Fgu4h@mail.gmail.com>
References : http://marc.info/?l=linux-kernel&m=128519926626322&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=17121
Subject : Two blank rectangles more than 10 cm long when booting
Submitter : Eric Valette <eric.valette@free.fr>
Date : 2010-08-26 17:24 (126 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=17061
Subject : 2.6.36-rc1 on zaurus: bluetooth regression
Submitter : Pavel Machek <pavel@ucw.cz>
Date : 2010-08-21 15:24 (131 days old)
Message-ID : <20100821152445.GA1536@ucw.cz>
References : http://marc.info/?l=linux-kernel&m=128240433828087&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16951
Subject : hackbench regression with 2.6.36-rc1
Submitter : Zhang, Yanmin <yanmin_zhang@linux.intel.com>
Date : 2010-08-18 6:18 (134 days old)
Message-ID : <1282112318.21202.8.camel@ymzhang.sh.intel.com>
References : http://marc.info/?l=linux-kernel&m=128211235904910&w=2
Regressions with patches
------------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=21092
Subject : Kernel 2.6.36 Bug during quotaon on reiserfs
Submitter : <markus.gapp@gmx.net>
Date : 2010-10-24 16:57 (67 days old)
Handled-By : Jan Kara <jack@suse.cz>
Patch : https://bugzilla.kernel.org/attachment.cgi?id=35292
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16971
Subject : qla4xxx compile failure on 32-bit PowerPC: missing readq and writeq
Submitter : Meelis Roos <mroos@linux.ee>
Date : 2010-08-19 21:03 (133 days old)
Message-ID : <<<alpine.SOC.1.00.1008192359310.19654@math.ut.ee>>>
References : http://marc.info/?l=linux-kernel&m=128225184900892&w=2
Patch : http://marc.info/?l=linux-scsi&m=128590267608876&w=2
For details, please visit the bug entries and follow the links given in
references.
As you can see, there is a Bugzilla entry for each of the listed regressions.
There also is a Bugzilla entry used for tracking the regressions introduced
between 2.6.35 and 2.6.36, unresolved as well as resolved, at:
http://bugzilla.kernel.org/show_bug.cgi?id=16444
Please let the tracking team know if there are any Bugzilla entries that
should be added to the list in there.
Thanks!
^ permalink raw reply
* [RFC] mac80211: serialize rx path workers
From: Christian Lamparter @ 2010-12-29 23:15 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg
This patch addresses the issue of serialization between
the main rx path and various reorder release timers.
<http://www.spinics.net/lists/linux-wireless/msg57214.html>
As discussed before, we can choose between:
1. get a new rx-path lock
2. convert all drivers to use ieee80211_rx_irqsafe
and let the tasklet handle the timeout procedure.
3. call the release reorder code from within ieee80211_rx()
(e.g.: before returning back to the driver)
4. like 1. but without the global "lock".
(this patch)
5. ... maybe more?
Seems like we are spoilt for choice?
However, each way does have its own unique drawback.
1. Locking is easy to implement but hard to maintain.
Furthermore, Johannes worked very hard to get rid
of as many as possible.
2. converting the drivers to ieee80211_rx_irqsafe has
the drawback that frames have to go through several
queues and tasklets/workers (driver and mac80211)
before they can be passed on to net-core (backlog).
I tried this approach before and on a UP-system
ath9k struggled to reach even 11g speeds.
3. Not so bad, but in order to work properly the driver
needs to "deliver" a constant stream of frames.
Which isn't a problem, as long as beacons are not
filtered and the beacon interval is reasonably short.
So, what should we do?
The attached solution is so far the easiest to implement.
It converts the previously local "frames" queue into
a global rx queue (reorder_release). This way, everyone
(be it the main rx-path or some reorder release timeout)
can add frames to it.
Now, only one active rx handler worker (ieee80211_rx_handlers)
is needed. All other threads which have lost the race of
"runnning_rx_handlers" can now simply "return", knowing that
the thread who had the "edge" will also take care of their
workload.
(not the most intelligent bits, but it's getting late...)
---
Don't forget that the reorder release timers have been
disabled. If you want to test this patch, you must also
revert "mac80211: temporarily disable reorder release timer"
(15943a72c7d2031c9150917ca9161a9f891d455a in wt.git)
Regards,
Chr
ieee80211_i.h | 3 ++
main.c | 4 ++
rx.c | 82 +++++++++++++++++++++++++---------------------------------
3 files changed, 43 insertions(+), 46 deletions(-)
---
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index a0cf5ab..57b223a 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -704,6 +704,9 @@ struct ieee80211_local {
struct work_struct work_work;
struct sk_buff_head work_skb_queue;
+ struct sk_buff_head reorder_release;
+ atomic_t running_rx_handlers;
+
/*
* private workqueue to mac80211. mac80211 makes this accessible
* via ieee80211_queue_work()
diff --git a/net/mac80211/main.c b/net/mac80211/main.c
index 32e58ee..18f7e9a 100644
--- a/net/mac80211/main.c
+++ b/net/mac80211/main.c
@@ -569,6 +569,9 @@ struct ieee80211_hw *ieee80211_alloc_hw(size_t priv_data_len,
spin_lock_init(&local->filter_lock);
spin_lock_init(&local->queue_stop_reason_lock);
+ skb_queue_head_init(&local->reorder_release);
+ atomic_set(&local->running_rx_handlers, 0);
+
INIT_DELAYED_WORK(&local->scan_work, ieee80211_scan_work);
ieee80211_work_init(local);
@@ -917,6 +920,7 @@ void ieee80211_unregister_hw(struct ieee80211_hw *hw)
wiphy_warn(local->hw.wiphy, "skb_queue not empty\n");
skb_queue_purge(&local->skb_queue);
skb_queue_purge(&local->skb_queue_unreliable);
+ skb_queue_purge(&local->reorder_release);
destroy_workqueue(local->workqueue);
wiphy_unregister(local->hw.wiphy);
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index 5e9d3bc..842824e 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -533,9 +533,9 @@ static inline u16 seq_sub(u16 sq1, u16 sq2)
static void ieee80211_release_reorder_frame(struct ieee80211_hw *hw,
struct tid_ampdu_rx *tid_agg_rx,
- int index,
- struct sk_buff_head *frames)
+ int index)
{
+ struct ieee80211_local *local = hw_to_local(hw);
struct sk_buff *skb = tid_agg_rx->reorder_buf[index];
lockdep_assert_held(&tid_agg_rx->reorder_lock);
@@ -546,7 +546,7 @@ static void ieee80211_release_reorder_frame(struct ieee80211_hw *hw,
/* release the frame from the reorder ring buffer */
tid_agg_rx->stored_mpdu_num--;
tid_agg_rx->reorder_buf[index] = NULL;
- __skb_queue_tail(frames, skb);
+ skb_queue_tail(&local->reorder_release, skb);
no_frame:
tid_agg_rx->head_seq_num = seq_inc(tid_agg_rx->head_seq_num);
@@ -554,8 +554,7 @@ no_frame:
static void ieee80211_release_reorder_frames(struct ieee80211_hw *hw,
struct tid_ampdu_rx *tid_agg_rx,
- u16 head_seq_num,
- struct sk_buff_head *frames)
+ u16 head_seq_num)
{
int index;
@@ -564,7 +563,7 @@ static void ieee80211_release_reorder_frames(struct ieee80211_hw *hw,
while (seq_less(tid_agg_rx->head_seq_num, head_seq_num)) {
index = seq_sub(tid_agg_rx->head_seq_num, tid_agg_rx->ssn) %
tid_agg_rx->buf_size;
- ieee80211_release_reorder_frame(hw, tid_agg_rx, index, frames);
+ ieee80211_release_reorder_frame(hw, tid_agg_rx, index);
}
}
@@ -580,8 +579,7 @@ static void ieee80211_release_reorder_frames(struct ieee80211_hw *hw,
#define HT_RX_REORDER_BUF_TIMEOUT (HZ / 10)
static void ieee80211_sta_reorder_release(struct ieee80211_hw *hw,
- struct tid_ampdu_rx *tid_agg_rx,
- struct sk_buff_head *frames)
+ struct tid_ampdu_rx *tid_agg_rx)
{
int index, j;
@@ -612,8 +610,7 @@ static void ieee80211_sta_reorder_release(struct ieee80211_hw *hw,
wiphy_debug(hw->wiphy,
"release an RX reorder frame due to timeout on earlier frames\n");
#endif
- ieee80211_release_reorder_frame(hw, tid_agg_rx,
- j, frames);
+ ieee80211_release_reorder_frame(hw, tid_agg_rx, j);
/*
* Increment the head seq# also for the skipped slots.
@@ -623,7 +620,7 @@ static void ieee80211_sta_reorder_release(struct ieee80211_hw *hw,
skipped = 0;
}
} else while (tid_agg_rx->reorder_buf[index]) {
- ieee80211_release_reorder_frame(hw, tid_agg_rx, index, frames);
+ ieee80211_release_reorder_frame(hw, tid_agg_rx, index);
index = seq_sub(tid_agg_rx->head_seq_num, tid_agg_rx->ssn) %
tid_agg_rx->buf_size;
}
@@ -679,8 +675,7 @@ set_release_timer:
*/
static bool ieee80211_sta_manage_reorder_buf(struct ieee80211_hw *hw,
struct tid_ampdu_rx *tid_agg_rx,
- struct sk_buff *skb,
- struct sk_buff_head *frames)
+ struct sk_buff *skb)
{
struct ieee80211_hdr *hdr = (struct ieee80211_hdr *) skb->data;
u16 sc = le16_to_cpu(hdr->seq_ctrl);
@@ -707,8 +702,7 @@ static bool ieee80211_sta_manage_reorder_buf(struct ieee80211_hw *hw,
if (!seq_less(mpdu_seq_num, head_seq_num + buf_size)) {
head_seq_num = seq_inc(seq_sub(mpdu_seq_num, buf_size));
/* release stored frames up to new head to stack */
- ieee80211_release_reorder_frames(hw, tid_agg_rx, head_seq_num,
- frames);
+ ieee80211_release_reorder_frames(hw, tid_agg_rx, head_seq_num);
}
/* Now the new frame is always in the range of the reordering buffer */
@@ -736,7 +730,7 @@ static bool ieee80211_sta_manage_reorder_buf(struct ieee80211_hw *hw,
tid_agg_rx->reorder_buf[index] = skb;
tid_agg_rx->reorder_time[index] = jiffies;
tid_agg_rx->stored_mpdu_num++;
- ieee80211_sta_reorder_release(hw, tid_agg_rx, frames);
+ ieee80211_sta_reorder_release(hw, tid_agg_rx);
out:
spin_unlock(&tid_agg_rx->reorder_lock);
@@ -747,8 +741,7 @@ static bool ieee80211_sta_manage_reorder_buf(struct ieee80211_hw *hw,
* Reorder MPDUs from A-MPDUs, keeping them on a buffer. Returns
* true if the MPDU was buffered, false if it should be processed.
*/
-static void ieee80211_rx_reorder_ampdu(struct ieee80211_rx_data *rx,
- struct sk_buff_head *frames)
+static void ieee80211_rx_reorder_ampdu(struct ieee80211_rx_data *rx)
{
struct sk_buff *skb = rx->skb;
struct ieee80211_local *local = rx->local;
@@ -803,11 +796,11 @@ static void ieee80211_rx_reorder_ampdu(struct ieee80211_rx_data *rx,
* sure that we cannot get to it any more before doing
* anything with it.
*/
- if (ieee80211_sta_manage_reorder_buf(hw, tid_agg_rx, skb, frames))
+ if (ieee80211_sta_manage_reorder_buf(hw, tid_agg_rx, skb))
return;
dont_reorder:
- __skb_queue_tail(frames, skb);
+ skb_queue_tail(&local->reorder_release, skb);
}
static ieee80211_rx_result debug_noinline
@@ -1930,7 +1923,7 @@ ieee80211_rx_h_data(struct ieee80211_rx_data *rx)
}
static ieee80211_rx_result debug_noinline
-ieee80211_rx_h_ctrl(struct ieee80211_rx_data *rx, struct sk_buff_head *frames)
+ieee80211_rx_h_ctrl(struct ieee80211_rx_data *rx)
{
struct ieee80211_local *local = rx->local;
struct ieee80211_hw *hw = &local->hw;
@@ -1970,8 +1963,7 @@ ieee80211_rx_h_ctrl(struct ieee80211_rx_data *rx, struct sk_buff_head *frames)
spin_lock(&tid_agg_rx->reorder_lock);
/* release stored frames up to start of BAR */
- ieee80211_release_reorder_frames(hw, tid_agg_rx, start_seq_num,
- frames);
+ ieee80211_release_reorder_frames(hw, tid_agg_rx, start_seq_num);
spin_unlock(&tid_agg_rx->reorder_lock);
kfree_skb(skb);
@@ -2488,8 +2480,7 @@ static void ieee80211_rx_handlers_result(struct ieee80211_rx_data *rx,
}
}
-static void ieee80211_rx_handlers(struct ieee80211_rx_data *rx,
- struct sk_buff_head *frames)
+static void ieee80211_rx_handlers(struct ieee80211_rx_data *rx)
{
ieee80211_rx_result res = RX_DROP_MONITOR;
struct sk_buff *skb;
@@ -2501,7 +2492,13 @@ static void ieee80211_rx_handlers(struct ieee80211_rx_data *rx,
goto rxh_next; \
} while (0);
- while ((skb = __skb_dequeue(frames))) {
+rerun:
+ if (atomic_inc_return(&rx->local->running_rx_handlers) > 1) {
+ atomic_dec(&rx->local->running_rx_handlers);
+ return;
+ }
+
+ while ((skb = skb_dequeue(&rx->local->reorder_release))) {
/*
* all the other fields are valid across frames
* that belong to an aMPDU since they are on the
@@ -2524,12 +2521,7 @@ static void ieee80211_rx_handlers(struct ieee80211_rx_data *rx,
CALL_RXH(ieee80211_rx_h_mesh_fwding);
#endif
CALL_RXH(ieee80211_rx_h_data)
-
- /* special treatment -- needs the queue */
- res = ieee80211_rx_h_ctrl(rx, frames);
- if (res != RX_CONTINUE)
- goto rxh_next;
-
+ CALL_RXH(ieee80211_rx_h_ctrl);
CALL_RXH(ieee80211_rx_h_mgmt_check)
CALL_RXH(ieee80211_rx_h_action)
CALL_RXH(ieee80211_rx_h_userspace_mgmt)
@@ -2541,15 +2533,16 @@ static void ieee80211_rx_handlers(struct ieee80211_rx_data *rx,
#undef CALL_RXH
}
+
+ atomic_dec(&rx->local->running_rx_handlers);
+ if (!skb_queue_empty(&rx->local->reorder_release))
+ goto rerun;
}
static void ieee80211_invoke_rx_handlers(struct ieee80211_rx_data *rx)
{
- struct sk_buff_head reorder_release;
ieee80211_rx_result res = RX_DROP_MONITOR;
- __skb_queue_head_init(&reorder_release);
-
#define CALL_RXH(rxh) \
do { \
res = rxh(rx); \
@@ -2560,9 +2553,9 @@ static void ieee80211_invoke_rx_handlers(struct ieee80211_rx_data *rx)
CALL_RXH(ieee80211_rx_h_passive_scan)
CALL_RXH(ieee80211_rx_h_check)
- ieee80211_rx_reorder_ampdu(rx, &reorder_release);
+ ieee80211_rx_reorder_ampdu(rx);
- ieee80211_rx_handlers(rx, &reorder_release);
+ ieee80211_rx_handlers(rx);
return;
rxh_next:
@@ -2577,7 +2570,6 @@ static void ieee80211_invoke_rx_handlers(struct ieee80211_rx_data *rx)
*/
void ieee80211_release_reorder_timeout(struct sta_info *sta, int tid)
{
- struct sk_buff_head frames;
struct ieee80211_rx_data rx = {
.sta = sta,
.sdata = sta->sdata,
@@ -2590,13 +2582,11 @@ void ieee80211_release_reorder_timeout(struct sta_info *sta, int tid)
if (!tid_agg_rx)
return;
- __skb_queue_head_init(&frames);
-
spin_lock(&tid_agg_rx->reorder_lock);
- ieee80211_sta_reorder_release(&sta->local->hw, tid_agg_rx, &frames);
+ ieee80211_sta_reorder_release(&sta->local->hw, tid_agg_rx);
spin_unlock(&tid_agg_rx->reorder_lock);
- ieee80211_rx_handlers(&rx, &frames);
+ ieee80211_rx_handlers(&rx);
}
/* main receive path */
^ permalink raw reply related
* 2.6.37-rc8: Reported regressions from 2.6.36
From: Rafael J. Wysocki @ 2010-12-29 22:59 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Maciej Rutecki, Florian Mickler, Andrew Morton, Linus Torvalds,
Kernel Testers List, Network Development, Linux ACPI,
Linux PM List, Linux SCSI List, Linux Wireless List, DRI
This message contains a list of some regressions from 2.6.36,
for which there are no fixes in the mainline known to the tracking team.
If any of them have been fixed already, please let us know.
If you know of any other unresolved regressions from 2.6.36, please let us
know either and we'll add them to the list. Also, please let us know
if any of the entries below are invalid.
Each entry from the list will be sent additionally in an automatic reply
to this message with CCs to the people involved in reporting and handling
the issue.
Listed regressions statistics:
Date Total Pending Unresolved
----------------------------------------
2010-12-30 85 32 26
2010-12-19 73 28 24
2010-12-03 55 25 19
2010-11-19 39 29 25
Unresolved regressions
----------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=25842
Subject : thinkpad T410s intel i915 regression
Submitter : Travis Hume <travis@computoring.org>
Date : 2010-12-29 18:21 (1 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=25822
Subject : [BUG] kernel BUG at mm/truncate.c:479! on 2.6.37-rc8
Submitter : Gurudas Pai <gurudas.pai@oracle.com>
Date : 2010-12-29 6:58 (1 days old)
Message-ID : <4D1AD935.1020504@oracle.com>
References : http://marc.info/?l=linux-kernel&m=129360511222037&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=25812
Subject : 2.6.37-rc7: Regression: b43: crashes in hwrng_register()
Submitter : Mario 'BitKoenig' Holbe <Mario.Holbe@tu-ilmenau.de>
Date : 2010-12-28 13:32 (2 days old)
Message-ID : <slrnihjpnh.7t4.Mario.Holbe@darkside.dyn.samba-tng.org>
References : http://marc.info/?l=linux-kernel&m=129354319002301&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=25602
Subject : [regression] 2.6.37-rc5: scsi_eh_11 CPU loop
Submitter : Martin Steigerwald <Martin@lichtvoll.de>
Date : 2010-12-20 10:05 (10 days old)
Message-ID : <201012201105.08993.Martin@lichtvoll.de>
References : http://marc.info/?l=linux-kernel&m=129283954108331&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=25432
Subject : Alpha fails to build with gcc 4.4
Submitter : Ben Hutchings <ben@decadent.org.uk>
Date : 2010-12-22 01:55 (8 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=25402
Subject : kernel (2.6.37-8-generic_amd64) panic on boot (with message "map_single: bounce buffer is not DMA'ble) - possible regression !!!
Submitter : carlos <carlos.palma@ono.com>
Date : 2010-12-21 19:58 (9 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=25392
Subject : scsi_eh_11 CPU loop
Submitter : Zhang, Yanmin <yanmin_zhang@linux.intel.com>
Date : 2010-08-18 6:18 (134 days old)
Message-ID : <1282112318.21202.8.camel@ymzhang.sh.intel.com>
References : http://marc.info/?t=129283967100004&r=1&w=2
http://lkml.org/lkml/2010/12/20/52
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=24882
Subject : PM/Hibernate: Memory corruption patch introduces regression (2.6.36.2)
Submitter : <akwatts@ymail.com>
Date : 2010-12-14 04:00 (16 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=24822
Subject : Embedded DisplayPort is detected wrongly on HP ProBook 5320m
Submitter : Takashi Iwai <tiwai@suse.de>
Date : 2010-12-13 11:09 (17 days old)
Handled-By : Chris Wilson <chris@chris-wilson.co.uk>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=24772
Subject : Crash with btrfs rootfs on dm-crypt [ kernel BUG at fs/btrfs/inode.c:806! ] on linux 2.6.37-rc5
Submitter : Fabio Comolli <fabio.comolli@gmail.com>
Date : 2010-12-10 20:30 (20 days old)
Message-ID : <AANLkTi=j9zsaYNcu=NgGV=HfE-3rNHzVswov8VrgwjQp@mail.gmail.com>
References : http://marc.info/?l=linux-kernel&m=129201308706568&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=24762
Subject : BUG at perf_ctx_adjust_freq (kernel/perf_event.c:1582)
Submitter : Chris Wilson <chris@chris-wilson.co.uk>
Date : 2010-12-10 12:00 (20 days old)
Message-ID : <c6d829$pqibha@fmsmga001.fm.intel.com>
References : http://marc.info/?l=linux-kernel&m=129198247531612&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=24592
Subject : 2.6.37-rc5: NULL pointer oops in selinux_socket_unix_stream_connect
Submitter : Jeremy Fitzhardinge <jeremy@goop.org>
Date : 2010-12-08 21:09 (22 days old)
Message-ID : <4CFFF3F3.90100@goop.org>
References : http://marc.info/?l=linux-kernel&m=129184256629712&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=24582
Subject : Kernel Oops at tty_buffer_request_room when using pppd program (2.6.37-rc4)
Submitter : baoyb <baoyb@avit.org.cn>
Date : 2010-12-08 13:55 (22 days old)
Message-ID : <EF6DDE218DB34702B1FA84D6CD7EA771@baoyb>
References : http://marc.info/?l=linux-kernel&m=129181763525738&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=24372
Subject : kdump broken on 2.6.37-rc4
Submitter : Stanislaw Gruszka <sgruszka@redhat.com>
Date : 2010-12-03 11:16 (27 days old)
Message-ID : <20101203111623.GA2741@redhat.com>
References : http://marc.info/?l=linux-kernel&m=129137502323003&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=24362
Subject : perf hw in kexeced kernel broken in tip
Submitter : Yinghai Lu <yinghai@kernel.org>
Date : 2010-12-01 8:00 (29 days old)
First-Bad-Commit: http://git.kernel.org/linus/33c6d6a7ad0ffab9b1b15f8e4107a2af072a05a0
Message-ID : <4CF60095.1020900@kernel.org>
References : http://marc.info/?l=linux-kernel&m=129119055922065&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=24272
Subject : iotop reports insane per-process disk read/write statistics
Submitter : Brian Rogers <brian@xyzw.org>
Date : 2010-12-03 12:00 (27 days old)
First-Bad-Commit: http://git.kernel.org/linus/85893120699f8bae8caa12a8ee18ab5fceac978e
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=23902
Subject : [BUG] 2.6.37-rc3 massive interactivity regression on ARM
Submitter : Mikael Pettersson <mikpe@it.uu.se>
Date : 2010-11-27 15:16 (33 days old)
First-Bad-Commit: http://git.kernel.org/linus/305e6835e05513406fa12820e40e4a8ecb63743c
Message-ID : <<19697.8378.717761.236202@pilspetsen.it.uu.se>>
References : http://marc.info/?l=linux-kernel&m=129087098911837&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=23472
Subject : 2.6.37-rc2 vs. 2.6.36 laptop backlight changes?
Submitter : Patrick Schaaf <netdev@bof.de>
Date : 2010-11-17 13:41 (43 days old)
Message-ID : <1290001262.5727.2.camel@lat1>
References : http://marc.info/?l=linux-kernel&m=129000127920912&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=23102
Subject : [bisected] i915 regression in post 2.6.36 kernels
Submitter : Johannes Hirte <johannes.hirte@fem.tu-ilmenau.de>
Date : 2010-11-10 7:02 (50 days old)
Message-ID : <201011100802.20332.johannes.hirte@fem.tu-ilmenau.de>
References : http://marc.info/?l=linux-kernel&m=128937310017057&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=22942
Subject : [2.6.37-rc1, OOM] virtblk: OOM in do_virtblk_request()
Submitter : Dave Chinner <david@fromorbit.com>
Date : 2010-11-05 1:30 (55 days old)
Message-ID : <20101105013003.GE13830@dastard>
References : http://marc.info/?l=linux-kernel&m=128892062917641&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=22912
Subject : spi_lm70llp module crash on unload (2.6.37-rc1)
Submitter : Randy Dunlap <randy.dunlap@oracle.com>
Date : 2010-11-05 0:16 (55 days old)
Message-ID : <20101104171620.00d8c95d.randy.dunlap@oracle.com>
References : http://marc.info/?l=linux-kernel&m=128891627913647&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=22882
Subject : (2.6.37-rc1) amd64-agp module crashed on second load
Submitter : Randy Dunlap <randy.dunlap@oracle.com>
Date : 2010-11-05 0:13 (55 days old)
Message-ID : <20101104171333.fea1f498.randy.dunlap@oracle.com>
References : http://marc.info/?l=linux-kernel&m=128891605213447&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=22642
Subject : 2.6.37-rc1: Disk takes 10 seconds to resume - MacBook2,1
Submitter : Tobias <devnull@plzk.org>
Date : 2010-11-10 19:33 (50 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=22562
Subject : Regression in 2.6.37-rc1 - logs spammed with "unable to enumerate USB port" - bisected to commit 3df7169e
Submitter : Larry Finger <Larry.Finger@lwfinger.net>
Date : 2010-11-02 22:32 (58 days old)
First-Bad-Commit: http://git.kernel.org/linus/3df7169e73fc1d71a39cffeacc969f6840cdf52b
Message-ID : <4CD09166.4060202@lwfinger.net>
References : http://marc.info/?l=linux-kernel&m=128873713207906&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=22542
Subject : [2.6.37-rc1] drm:i195 errors
Submitter : Paul Rolland <rol@witbe.net>
Date : 2010-11-02 14:58 (58 days old)
Message-ID : <20101102155813.09cb2c6e@tux.DEF.witbe.net>
References : http://marc.info/?l=linux-kernel&m=128870991628970&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=22472
Subject : vga_switcheroo fails to switch from intel to ati
Submitter : Radu Andries <admiral0@tuxfamily.org>
Date : 2010-11-08 16:46 (52 days old)
Regressions with patches
------------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=25442
Subject : ixp4xx defines FREQ macro; conflicts with gspca/ov519 driver
Submitter : Ben Hutchings <ben@decadent.org.uk>
Date : 2010-12-22 02:02 (8 days old)
Handled-By : Ben Hutchings <ben@decadent.org.uk>
Patch : https://bugzilla.kernel.org/attachment.cgi?id=41252
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=25422
Subject : nouveau fails to build on ia64
Submitter : Ben Hutchings <ben@decadent.org.uk>
Date : 2010-12-22 01:49 (8 days old)
Handled-By : Ben Hutchings <ben@decadent.org.uk>
Patch : https://bugzilla.kernel.org/attachment.cgi?id=41242
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=25012
Subject : BUG: i915 causes NULL pointer dereference in 2.6.37-rc5-git4
Submitter : Tõnu Raitviir <jussuf@linux.ee>
Date : 2010-12-15 12:48 (15 days old)
First-Bad-Commit: http://git.kernel.org/linus/da79de97d254145dcb7c08c978b1093eac15ec9c
Message-ID : <alpine.DEB.2.00.1012151238570.4797@jbbyvx.ohzcpyho.rr>
References : http://www.spinics.net/lists/dri-devel/msg06282.html
Handled-By : Chris Wilson <chris@chris-wilson.co.uk>
Patch : https://bugzilla.kernel.org/attachment.cgi?id=41502
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=22812
Subject : kernel oops on 2.6.37-rc1
Submitter : Andrew <atswartz@gmail.com>
Date : 2010-11-12 16:05 (48 days old)
First-Bad-Commit: http://git.kernel.org/linus/a68c439b1966c91f0ef474e2bf275d6792312726
Patch : https://bugzilla.kernel.org/attachment.cgi?id=41192
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=22672
Subject : Regression in 2.6.37-rc1 for Intel 945 Graphics Adapter - bisected to commit e9e331a
Submitter : Larry Finger <Larry.Finger@lwfinger.net>
Date : 2010-11-11 01:56 (49 days old)
References : https://bugs.freedesktop.org/show_bug.cgi?id=31803
http://marc.info/?l=linux-kernel&m=128944001311444&w=2
http://www.mail-archive.com/intel-gfx@lists.freedesktop.org/msg02235.html
Patch : https://patchwork.kernel.org/patch/359472/
https://patchwork.kernel.org/patch/359502/
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=22662
Subject : divide error in select_task_rq_fair()
Submitter : Myron Stowe <myron.stowe@hp.com>
Date : 2010-11-10 23:58 (50 days old)
Patch : http://lkml.org/lkml/2010/11/13/176
http://lkml.org/lkml/2010/11/13/181
For details, please visit the bug entries and follow the links given in
references.
As you can see, there is a Bugzilla entry for each of the listed regressions.
There also is a Bugzilla entry used for tracking the regressions from 2.6.36,
unresolved as well as resolved, at:
http://bugzilla.kernel.org/show_bug.cgi?id=21782
Please let the tracking team know if there are any Bugzilla entries that
should be added to the list in there.
Thanks!
^ permalink raw reply
* Re: [PATCH v3 14/18] wl1271: AP mode - record TX configuration settings
From: Luciano Coelho @ 2010-12-29 22:35 UTC (permalink / raw)
To: ext Arik Nemtsov; +Cc: linux-wireless
In-Reply-To: <AANLkTi=tTx=XZ0nFnTsds1F1X2saSYiVmgSxWL1zU-GY@mail.gmail.com>
On Wed, 2010-12-29 at 23:11 +0200, ext Arik Nemtsov wrote:
> On Wed, Dec 29, 2010 at 11:21, Luciano Coelho <luciano.coelho@nokia.com> wrote:
> > On Tue, 2010-12-28 at 19:36 +0200, ext Arik Nemtsov wrote:
> >>
> >> diff --git a/drivers/net/wireless/wl12xx/main.c
> >> b/drivers/net/wireless/wl12xx/main.c
> >> index 3747d98..ea61ae7 100644
> >> --- a/drivers/net/wireless/wl12xx/main.c
> >> +++ b/drivers/net/wireless/wl12xx/main.c
> >> @@ -1433,6 +1433,8 @@ static int wl1271_op_config(struct ieee80211_hw
> >> *hw, u32 changed)
> >> goto out;
> >> }
> >>
> >> + is_ap = (wl->bss_type == BSS_TYPE_AP_BSS);
> >> +
> >> ret = wl1271_ps_elp_wakeup(wl, false);
> >> if (ret < 0)
> >> goto out;
> >
> > Did you forget to fix this one? As we discussed, this should be in
> > 10/18.
> >
>
> Actually it was added in 10/18 (at the beginning of the function), but
> I forgot to remove it from 14/18.
> The correct place to set this is here after the mutex is held, so I've
> moved this line to 10/18 (for good this time I hope).
Yes, after I wrote this email, I checked 10/18 and it was there together
with the is_ap declaration, but, as you said, better do it after the
mutex is locked.
--
Cheers,
Luca.
^ permalink raw reply
* [PATCH] cfg80211: fix transposition of words in printk
From: Bob Copeland @ 2010-12-29 22:09 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Bob Copeland
Fixes the misplaced article in the following:
"cfg80211: Updating information on frequency 5785 MHz for
20 a MHz width channel with regulatory rule:"
Signed-off-by: Bob Copeland <me@bobcopeland.com>
---
Take 2, sorry for the noise...
net/wireless/reg.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 99d4183..37693b6 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -752,7 +752,7 @@ static void chan_reg_rule_print_dbg(struct ieee80211_channel *chan,
snprintf(max_antenna_gain, 32, "%d", power_rule->max_antenna_gain);
REG_DBG_PRINT("Updating information on frequency %d MHz "
- "for %d a MHz width channel with regulatory rule:\n",
+ "for a %d MHz width channel with regulatory rule:\n",
chan->center_freq,
KHZ_TO_MHZ(desired_bw_khz));
--
1.7.1.1
^ permalink raw reply related
* Re: # $linville='linville@tuxdriver.com';
From: Bob Copeland @ 2010-12-29 22:07 UTC (permalink / raw)
To: linville; +Cc: linux-wireless
In-Reply-To: <1293659584-9249-1-git-send-email-me@bobcopeland.com>
On Wed, Dec 29, 2010 at 4:53 PM, Bob Copeland <me@bobcopeland.com> wrote:
> @to = (
> $linville,
> );
>
> @cc = (
> $wl
> );
Heh, wrong args to my mailer script...
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* # $linville='linville@tuxdriver.com';
From: Bob Copeland @ 2010-12-29 21:53 UTC (permalink / raw)
To: linville; +Cc: linux-wireless
@to = (
$linville,
);
@cc = (
$wl
);
^ permalink raw reply
* Re: wl1271: how to use without runtime pm
From: Ohad Ben-Cohen @ 2010-12-29 21:22 UTC (permalink / raw)
To: Sergey Matyukevich; +Cc: Luciano Coelho, linux-wireless
In-Reply-To: <20101230000737.74d30852@lair>
On Wed, Dec 29, 2010 at 11:07 PM, Sergey Matyukevich <geomatsi@gmail.com> wrote:
> So the question is: what is the proper use of wl1271 driver in the case
> when wl1271 card is powered all the time ?
The wl1271 driver assumes it can control the power of the card.
If your card's power is always on, you will not be able to toggle the
interface down and up (as you have experienced).
It might be possible to change the driver around this "limitation",
but I'm not sure anyone has ever really tried.
^ permalink raw reply
* Re: [PATCH v3 14/18] wl1271: AP mode - record TX configuration settings
From: Arik Nemtsov @ 2010-12-29 21:11 UTC (permalink / raw)
To: Luciano Coelho; +Cc: linux-wireless
In-Reply-To: <1293614508.15791.0.camel@powerslave>
On Wed, Dec 29, 2010 at 11:21, Luciano Coelho <luciano.coelho@nokia.com> wrote:
> On Tue, 2010-12-28 at 19:36 +0200, ext Arik Nemtsov wrote:
>>
>> diff --git a/drivers/net/wireless/wl12xx/main.c
>> b/drivers/net/wireless/wl12xx/main.c
>> index 3747d98..ea61ae7 100644
>> --- a/drivers/net/wireless/wl12xx/main.c
>> +++ b/drivers/net/wireless/wl12xx/main.c
>> @@ -1433,6 +1433,8 @@ static int wl1271_op_config(struct ieee80211_hw
>> *hw, u32 changed)
>> goto out;
>> }
>>
>> + is_ap = (wl->bss_type == BSS_TYPE_AP_BSS);
>> +
>> ret = wl1271_ps_elp_wakeup(wl, false);
>> if (ret < 0)
>> goto out;
>
> Did you forget to fix this one? As we discussed, this should be in
> 10/18.
>
Actually it was added in 10/18 (at the beginning of the function), but
I forgot to remove it from 14/18.
The correct place to set this is here after the mutex is held, so I've
moved this line to 10/18 (for good this time I hope).
Thanks,
Arik
^ permalink raw reply
* wl1271: how to use without runtime pm
From: Sergey Matyukevich @ 2010-12-29 21:07 UTC (permalink / raw)
To: Luciano Coelho; +Cc: linux-wireless
Hello Luciano,
I use omap3evm board with wl1271 extension module. Current version of
wl1271 driver works fine on upstream kernel and (with minor
modifications resulting from older mac80211) on 2.6.32 kernel with
integrated SDIO runtime PM patches from Ohad Ben-Cohen.
In the current kernel runtime PM support is always enabled for
omap2plus boards. However this is not the case for the earlier kernels.
Besides, on some other boards there might be no gpio pin to control
power supply of wl1271 card.
So the question is: what is the proper use of wl1271 driver in the case
when wl1271 card is powered all the time ?
In a simple experiment I removed all pm_runtime functions from
wl1271_sdio.c and removed MMC_CAP_POWER_OFF_CARD flag from mmc slot
settings in board file. However I can't do ifdown/ifup procedure
properly:
root@omap3evm_minimal:~# ifconfig wlan0 down
root@omap3evm_minimal:~# ifconfig wlan0 up
[ 55.313201] wl1271: ERROR timeout waiting for the hardware to
complete initialization
[ 58.813964] wl1271: ERROR timeout waiting for the hardware to
complete initialization
[ 60.648651] wl1271: ERROR sdio read failed (-110)
[ 60.653686] wl1271: ERROR sdio write failed (-110)
[ 62.057067] wl1271: ERROR sdio read failed (-110)
[ 62.062072] wl1271: ERROR chip id doesn't match after firmware boot
[ 62.068786] wl1271: ERROR firmware boot failed despite 3 retries
ifconfig: SIOCSIFFLAGS: Input/output error
It looks like init procedure of wl1271 card can not be done twice
without powering off wl1271 card.
Thanks,
Sergey
^ permalink raw reply
* Re: [ath5k-devel] [PATCH 1/6] ath5k: Always write tx powertable on hw
From: Bob Copeland @ 2010-12-29 21:02 UTC (permalink / raw)
To: ath5k-devel, linux-wireless, linville, me, mcgrof, jirislaby, nbd,
br1, sedat.dilek
In-Reply-To: <20101203040300.GA2988@makis.mantri>
On Thu, Dec 2, 2010 at 11:03 PM, Nick Kossifidis <mickflemm@gmail.com> wrote:
> * By skipping tx power table calibration we also skip setting
> tx power table on hw. Make sure we always write tx power table
> on hw since it gets cleared on reset.
>
> Signed-off-by: Nick Kossifidis <mickflemm@gmail.com>
Just a very late heads-up, this patch seems to be causing problems
for me.
Seems a bit weird given the content, but the symptom is that
when I bring up the device none of my probe requests are actually
getting sent, according to wireshark captures from another device.
Reverting just this patch helps, so my power table must be broken
at start up.
I saw that Bruno had a later series that touched this area, so I'll
try them next.
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* Compat-wireless release for 2010-12-29 is baked
From: Compat-wireless cronjob account @ 2010-12-29 20:04 UTC (permalink / raw)
To: linux-wireless
>From git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next
9688efd..2c4665a history -> origin/history
+ b79b3fb...fd9ae9b master -> origin/master (forced update)
ffc96d6..b52e2a6 stable -> origin/stable
* [new tag] next-20101229 -> next-20101229
cat: /var/opt/compat/compat-wireless-2.6/compat_version: No such file or directory
cat: compat_base_tree: No such file or directory
cat: compat_base_tree_version: No such file or directory
cat: compat_version: No such file or directory
cat: /var/opt/compat/compat-wireless-2.6/compat_version: No such file or directory
scripts/Makefile.clean:17: /var/opt/compat/compat-wireless-2.6/drivers/net/wireless/hostap/Makefile: No such file or directory
make[4]: *** No rule to make target `/var/opt/compat/compat-wireless-2.6/drivers/net/wireless/hostap/Makefile'. Stop.
make[3]: *** [/var/opt/compat/compat-wireless-2.6/drivers/net/wireless/hostap] Error 2
make[2]: *** [/var/opt/compat/compat-wireless-2.6/drivers/net/wireless] Error 2
make[1]: *** [_clean_/var/opt/compat/compat-wireless-2.6] Error 2
make: *** [clean] Error 2
compat-wireless code metrics
774936 - Total upstream lines of code being pulled
^ permalink raw reply
* [PATCH] Staging: ath6kl: fix potential buffer overflow
From: Vipin Mehta @ 2010-12-29 20:01 UTC (permalink / raw)
To: greg; +Cc: linux-wireless, simbwa, error27, devel, Vipin Mehta
From: Phillip Simbwa <simbwa@gmail.com>
Off by one
Signed-off-by: Phillip Simbwa <simbwa at gmail dot com>
Signed-off-by: Vipin Mehta <vmehta@atheros.com>
---
.../staging/ath6kl/miscdrv/ar3kps/ar3kpsconfig.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/ath6kl/miscdrv/ar3kps/ar3kpsconfig.c b/drivers/staging/ath6kl/miscdrv/ar3kps/ar3kpsconfig.c
index 0e298db..29b8ab4 100644
--- a/drivers/staging/ath6kl/miscdrv/ar3kps/ar3kpsconfig.c
+++ b/drivers/staging/ath6kl/miscdrv/ar3kps/ar3kpsconfig.c
@@ -360,8 +360,8 @@ int PSSendOps(void *arg)
status = 1;
goto complete;
}
- len = (firmware->size > MAX_BDADDR_FORMAT_LENGTH)? MAX_BDADDR_FORMAT_LENGTH: firmware->size;
- memcpy(config_bdaddr, firmware->data,len);
+ len = min(firmware->size, MAX_BDADDR_FORMAT_LENGTH - 1);
+ memcpy(config_bdaddr, firmware->data, len);
config_bdaddr[len] = '\0';
write_bdaddr(hdev,config_bdaddr,BDADDR_TYPE_STRING);
A_RELEASE_FIRMWARE(firmware);
--
1.6.3.3
^ permalink raw reply related
* Re: 2.6.37-rc7: Regression: b43: crashes in hwrng_register()
From: Mario 'BitKoenig' Holbe @ 2010-12-29 19:54 UTC (permalink / raw)
To: Larry Finger; +Cc: LKML, wireless, b43-dev
In-Reply-To: <4D1A8200.4010609@lwfinger.net>
[-- Attachment #1.1: Type: text/plain, Size: 3124 bytes --]
Hello Larry,
On Tue, Dec 28, 2010 at 06:34:08PM -0600, Larry Finger wrote:
> Mario Holbe wrote:
> > on 2.6.37-rc7 the b43 driver crashes in hwrng_register(). This makes the
...
> > This issue does also exist in 2.6.37-rc5.
> > This issue does not exist in 2.6.36.2.
...
> > [ 29.868632] BUG: unable to handle kernel paging request at 907cde0c
> > [ 29.868640] IP: [<f8d543cc>] hwrng_register+0x4c/0x139 [rng_core]
...
> > [ 29.868884] Call Trace:
> > [ 29.868909] [<f8e5a870>] ? b43_wireless_core_init+0xd0c/0xdd6 [b43]
>
> I almost missed this posting.
You're welcome :)
> Please post wireless problems with
> linux-wireless@vger.kernel.org for better visibility.
Sorry and thanks for completing the CC: list.
> I have a BCM4312 (14e4:4315) on a netbook that does not have this problem, thus
> I will have to rely on your debugging. An additional difficulty is that the only
> changes to b43 between 2.6.36 and 2.6.37 are adding an additional PCI ID, some
> fixes to the SDIO driver, and some code for an 802.11n device. None of these
> should affect your 802.11 b/g unit.
>
> Is it possible for you to bisect between 2.6.36 and 2.6.37-rc5? I wish I could
> suggest some way to minimize the number of commits and builds, but the problem
> could be anywhere.
To be honest, I never bisected such a huge amount of commits before and
I'm somewhat afraid of doing it.
However, I think I'm able to nail the issue down to:
commit 84c164a34ffe67908a932a2d641ec1a80c2d5435 which went to 2.6.37-rc1.
Author: John W. Linville <linville@tuxdriver.com>
Date: Fri Aug 6 15:31:45 2010 -0400
b43: move hwrng registration driver to wireless core initialization
Message-ID: <1281126412-5089-1-git-send-email-linville@tuxdriver.com>
http://marc.info/?l=linux-wireless&m=128112658829379&w=2
I did 2 things:
1. I (manually) reverted 84c164a34ffe67908a932a2d641ec1a80c2d5435 from
2.6.37-rc7: The crash disappears, b43 is useable.
2. I added 84c164a34ffe67908a932a2d641ec1a80c2d5435 to 2.6.36.2: The
crash shows up as with vanilla 2.6.37-rc7.
I'm not sure why this is not reproducible for you, probably it has
something to do with the VIA Nano having a second HW-RNG driven by
via-rng. I experienced crashes in the past with earlier kernels when I
tried to move RNGs around via /sys/devices/virtual/misc/hw_random, but
never took the time to trace them down since I just got it working :)
Oh, I'm still able to trigger a crash with
$ cat /sys/devices/virtual/misc/hw_random/rng_available
on 2.6.37-rc7 without 84c164a34ffe67908a932a2d641ec1a80c2d5435 as well
as on vanilla 2.6.36.2. Probably this is (better) reproducible for you?
I suspect both (the 84c164a34ffe67908a932a2d641ec1a80c2d5435 crash as
well as the cat rng_available crash) having something to do with a
partially uninitialized rng-struct, or better: parts of the rng-struct
that are free()d too early (i.e. within its lifetime).
regards
Mario
--
Doing it right is no excuse for not meeting the schedule.
-- Plant Manager, Delphi Corporation
[-- Attachment #1.2: 2.6.36.2.rng_available-crash.dmesg --]
[-- Type: text/plain, Size: 3304 bytes --]
[ 389.303538] BUG: unable to handle kernel paging request at 288dcb5b
[ 389.303553] IP: [<f8dda34c>] hwrng_attr_available_show+0x5c/0x90 [rng_core]
[ 389.303582] *pde = 00000000
[ 389.303591] Oops: 0000 [#1] SMP
[ 389.303599] last sysfs file: /sys/devices/virtual/misc/hw_random/rng_available
[ 389.303609] Modules linked in: uinput via drm sco bnep rfcomm l2cap crc16 parport_pc ppdev lp parport sbs sbshc power_meter pci_slot hed fan container acpi_cpufreq mperf cpufreq_conservative cpufreq_userspace cpufreq_stats cpufreq_powersave dm_crypt fuse loop eeprom via_cputemp i2c_dev nvram padlock_aes aes_i586 aes_generic padlock_sha sha256_generic sha1_generic via_rng msr cpuid snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_pcm_oss snd_mixer_oss snd_pcm arc4 joydev ecb snd_seq_midi b43 rng_core snd_rawmidi snd_seq_midi_event mac80211 snd_seq uvcvideo video snd_timer cfg80211 snd_seq_device videodev v4l1_compat ideapad_laptop snd btusb i2c_viapro led_class sparse_keymap bluetooth tpm_tis tpm wmi output i2c_core battery tpm_bios shpchp processor ac soundcore rfkill pcspkr pci_hotplug snd_page_alloc psmouse button serio_raw evdev ext3 jbd mbcache raid10 raid456 async_raid6_recov async_pq raid6_pq async_xor xor async_memcpy async_tx raid1 raid0 multipath linear md_mod dm_mirror dm_region_hash dm_log dm_mod btrfs zlib_deflate crc32c libcrc32c sd_mod crc_t10dif ata_generic pata_via libata uhci_hcd ehci_hcd ssb scsi_mod usbcore tg3 via_sdmmc pcmcia mmc_core libphy thermal thermal_sys pcmcia_core nls_base [last unloaded: scsi_wait_scan]
[ 389.303871]
[ 389.303882] Pid: 3004, comm: cat Not tainted 2.6.36.2 #1 MoutCook/20021,2959
[ 389.303893] EIP: 0060:[<f8dda34c>] EFLAGS: 00010216 CPU: 0
[ 389.303908] EIP is at hwrng_attr_available_show+0x5c/0x90 [rng_core]
[ 389.303918] EAX: f5da2000 EBX: 288dcb3f ECX: 00000ff1 EDX: f8dda571
[ 389.303928] ESI: f5da2000 EDI: 0000000d EBP: 00000fff ESP: f6841f30
[ 389.303937] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
[ 389.303948] Process cat (pid: 3004, ti=f6840000 task=f5c9f180 task.ti=f6840000)
[ 389.303955] Stack:
[ 389.303960] f8dda618 fffffffb f8dda2f0 c12b1834 c11bd17e f5ccaf40 f69fe330 f6841f9c
[ 389.303978] <0> c10f8244 f5d9bcc0 f5ccaf54 f69c7e08 09a66000 00008000 f5d9bcc0 09a66000
[ 389.303997] <0> c10f81b8 f6841f9c c10b7774 f6841f9c c1282259 f5d9bcc0 fffffff7 09a66000
[ 389.304015] Call Trace:
[ 389.304015] [<f8dda2f0>] ? hwrng_attr_available_show+0x0/0x90 [rng_core]
[ 389.304015] [<c11bd17e>] ? dev_attr_show+0x16/0x32
[ 389.304015] [<c10f8244>] ? sysfs_read_file+0x8c/0xf5
[ 389.304015] [<c10f81b8>] ? sysfs_read_file+0x0/0xf5
[ 389.304015] [<c10b7774>] ? vfs_read+0x7c/0xd6
[ 389.304015] [<c1282259>] ? do_page_fault+0x26d/0x2cf
[ 389.304015] [<c10b7861>] ? sys_read+0x3c/0x60
[ 389.304015] [<c1002f1f>] ? sysenter_do_call+0x12/0x28
[ 389.304015] Code: e9 89 f0 29 f9 e8 ef 63 36 c8 8b 03 e8 60 64 36 c8 89 e9 ba 71 a5 dd f8 8d 3c 38 89 f0 29 f9 47 e8 d4 63 36 c8 8b 5b 1c 83 eb 1c <8b> 43 1c 0f 18 00 90 81 fb d0 a5 dd f8 75 c3 b9 ff 0f 00 00 ba
[ 389.304015] EIP: [<f8dda34c>] hwrng_attr_available_show+0x5c/0x90 [rng_core] SS:ESP 0068:f6841f30
[ 389.304015] CR2: 00000000288dcb5b
[ 389.304311] ---[ end trace a1f28568aee0d057 ]---
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 482 bytes --]
^ permalink raw reply
* Re: [PATCH] p54: fix compiler-warning when no P54_LEDS are configured
From: Johannes Berg @ 2010-12-29 18:13 UTC (permalink / raw)
To: christoph.paasch; +Cc: Larry Finger, linville, linux-wireless, chunkeey
In-Reply-To: <201012291816.27302.christoph.paasch@uclouvain.be>
On Wed, 2010-12-29 at 18:16 +0100, Christoph Paasch wrote:
> +#if defined(CONFIG_DEBUG_MUTEXES) || defined(CONFIG_P54_LEDS)
> struct p54_common *priv = dev->priv;
> +#endif
It seems a lot simpler to just add __maybe_unused...
johannes
^ permalink raw reply
* Re: [PATCH] p54: fix compiler-warning when no P54_LEDS are configured
From: Larry Finger @ 2010-12-29 17:32 UTC (permalink / raw)
To: christoph.paasch; +Cc: linville, linux-wireless, chunkeey
In-Reply-To: <201012291816.27302.christoph.paasch@uclouvain.be>
On 12/29/2010 11:16 AM, Christoph Paasch wrote:
> On Wednesday, December 29, 2010 wrote Larry Finger:
>> I was too quick to ACK this. The second hunk causes a compiler ERROR as
>> priv is needed in the mutex_destroy() calls.
>
> Oups, sorry. I did not have CONFIG_DEBUG_MUTEXES enabled when trying it out.
> Thus the compile-error did not happen.
>
> What about the following patch?
It seems to be what is needed if the mutex_destroy() calls are compiled away.
> From 5701b5f5ffbf0927025906e968c957f3b2292ece Mon Sep 17 00:00:00 2001
> From: Christoph Paasch <christoph.paasch@uclouvain.be>
> Date: Wed, 29 Dec 2010 12:40:43 +0100
> Subject: [PATCH] p54: fix compiler-warning when no P54_LEDS are configured
>
> The priv-variable is unused when compiling without CONFIG_P54_LEDS.
>
> Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
> ---
> drivers/net/wireless/p54/main.c | 4 ++++
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/wireless/p54/main.c b/drivers/net/wireless/p54/main.c
> index 622d27b..56ea1ce 100644
> --- a/drivers/net/wireless/p54/main.c
> +++ b/drivers/net/wireless/p54/main.c
> @@ -611,7 +611,9 @@ EXPORT_SYMBOL_GPL(p54_init_common);
>
> int p54_register_common(struct ieee80211_hw *dev, struct device *pdev)
> {
> +#ifdef CONFIG_P54_LEDS
> struct p54_common *priv = dev->priv;
> +#endif /* CONFIG_P54_LEDS */
> int err;
>
> err = ieee80211_register_hw(dev);
> @@ -653,7 +655,9 @@ EXPORT_SYMBOL_GPL(p54_free_common);
>
> void p54_unregister_common(struct ieee80211_hw *dev)
> {
> +#if defined(CONFIG_DEBUG_MUTEXES) || defined(CONFIG_P54_LEDS)
> struct p54_common *priv = dev->priv;
> +#endif
>
> #ifdef CONFIG_P54_LEDS
> p54_unregister_leds(priv);
Larry
^ permalink raw reply
* Re: [PATCH] p54: fix compiler-warning when no P54_LEDS are configured
From: Christoph Paasch @ 2010-12-29 17:16 UTC (permalink / raw)
To: Larry Finger; +Cc: linville, linux-wireless, chunkeey
In-Reply-To: <4D1B65D7.8090103@lwfinger.net>
On Wednesday, December 29, 2010 wrote Larry Finger:
> I was too quick to ACK this. The second hunk causes a compiler ERROR as
> priv is needed in the mutex_destroy() calls.
Oups, sorry. I did not have CONFIG_DEBUG_MUTEXES enabled when trying it out.
Thus the compile-error did not happen.
What about the following patch?
>From 5701b5f5ffbf0927025906e968c957f3b2292ece Mon Sep 17 00:00:00 2001
From: Christoph Paasch <christoph.paasch@uclouvain.be>
Date: Wed, 29 Dec 2010 12:40:43 +0100
Subject: [PATCH] p54: fix compiler-warning when no P54_LEDS are configured
The priv-variable is unused when compiling without CONFIG_P54_LEDS.
Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
---
drivers/net/wireless/p54/main.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/p54/main.c b/drivers/net/wireless/p54/main.c
index 622d27b..56ea1ce 100644
--- a/drivers/net/wireless/p54/main.c
+++ b/drivers/net/wireless/p54/main.c
@@ -611,7 +611,9 @@ EXPORT_SYMBOL_GPL(p54_init_common);
int p54_register_common(struct ieee80211_hw *dev, struct device *pdev)
{
+#ifdef CONFIG_P54_LEDS
struct p54_common *priv = dev->priv;
+#endif /* CONFIG_P54_LEDS */
int err;
err = ieee80211_register_hw(dev);
@@ -653,7 +655,9 @@ EXPORT_SYMBOL_GPL(p54_free_common);
void p54_unregister_common(struct ieee80211_hw *dev)
{
+#if defined(CONFIG_DEBUG_MUTEXES) || defined(CONFIG_P54_LEDS)
struct p54_common *priv = dev->priv;
+#endif
#ifdef CONFIG_P54_LEDS
p54_unregister_leds(priv);
--
1.7.1
--
Christoph Paasch
Research Assistant
IP Networking Lab --- http://inl.info.ucl.ac.be
MultiPath TCP --- http://inl.info.ucl.ac.be/mptcp
Université Catholique de Louvain
www.rollerbulls.be
--
^ permalink raw reply related
* Re: Compile error for the last week inside rtlwifi/base.c
From: Larry Finger @ 2010-12-29 16:56 UTC (permalink / raw)
To: Weedy; +Cc: linux-wireless
In-Reply-To: <loom.20101229T034155-409@post.gmane.org>
On 12/28/2010 08:43 PM, Weedy wrote:
> Larry Finger <Larry.Finger@...> writes:
>
>> Older kernels used create_workqueue(), which is replaced by alloc_workqueue()
>> If you really need the driver for RTL8192CE/RTL8188CE, then apply the patch
>> shown below. If you do not need the driver, then disable it in the
>> configuration.
>>
>> Larry
>
> Actually I need RTL8192USB, I guess I need to wait more?
What are the USB Ids as shown by the lsusb command?
Larry
^ permalink raw reply
* Re: [PATCH] p54: fix compiler-warning when no P54_LEDS are configured
From: Larry Finger @ 2010-12-29 16:46 UTC (permalink / raw)
To: Christoph Paasch; +Cc: linville, linux-wireless, chunkeey
In-Reply-To: <1293635679-9783-1-git-send-email-christoph.paasch@uclouvain.be>
On 12/29/2010 09:14 AM, Christoph Paasch wrote:
> The priv-variable is unused when compiling without CONFIG_P54_LEDS.
>
> Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
> ---
> drivers/net/wireless/p54/main.c | 4 +++-
> 1 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/wireless/p54/main.c b/drivers/net/wireless/p54/main.c
> index 622d27b..a6802f5 100644
> --- a/drivers/net/wireless/p54/main.c
> +++ b/drivers/net/wireless/p54/main.c
> @@ -611,7 +611,9 @@ EXPORT_SYMBOL_GPL(p54_init_common);
>
> int p54_register_common(struct ieee80211_hw *dev, struct device *pdev)
> {
> +#ifdef CONFIG_P54_LEDS
> struct p54_common *priv = dev->priv;
> +#endif /* CONFIG_P54_LEDS */
> int err;
>
> err = ieee80211_register_hw(dev);
> @@ -653,9 +655,9 @@ EXPORT_SYMBOL_GPL(p54_free_common);
>
> void p54_unregister_common(struct ieee80211_hw *dev)
> {
> +#ifdef CONFIG_P54_LEDS
> struct p54_common *priv = dev->priv;
>
> -#ifdef CONFIG_P54_LEDS
> p54_unregister_leds(priv);
> #endif /* CONFIG_P54_LEDS */
>
I was too quick to ACK this. The second hunk causes a compiler ERROR as priv is
needed in the mutex_destroy() calls.
NACK
Larry
^ permalink raw reply
* Re: [PATCH] p54: fix compiler-warning when no P54_LEDS are configured
From: Larry Finger @ 2010-12-29 16:19 UTC (permalink / raw)
To: Christoph Paasch; +Cc: linville, linux-wireless, chunkeey
In-Reply-To: <1293635679-9783-1-git-send-email-christoph.paasch@uclouvain.be>
On 12/29/2010 09:14 AM, Christoph Paasch wrote:
> The priv-variable is unused when compiling without CONFIG_P54_LEDS.
>
> Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
> ---
> drivers/net/wireless/p54/main.c | 4 +++-
> 1 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/wireless/p54/main.c b/drivers/net/wireless/p54/main.c
> index 622d27b..a6802f5 100644
> --- a/drivers/net/wireless/p54/main.c
> +++ b/drivers/net/wireless/p54/main.c
> @@ -611,7 +611,9 @@ EXPORT_SYMBOL_GPL(p54_init_common);
>
> int p54_register_common(struct ieee80211_hw *dev, struct device *pdev)
> {
> +#ifdef CONFIG_P54_LEDS
> struct p54_common *priv = dev->priv;
> +#endif /* CONFIG_P54_LEDS */
> int err;
>
> err = ieee80211_register_hw(dev);
> @@ -653,9 +655,9 @@ EXPORT_SYMBOL_GPL(p54_free_common);
>
> void p54_unregister_common(struct ieee80211_hw *dev)
> {
> +#ifdef CONFIG_P54_LEDS
> struct p54_common *priv = dev->priv;
>
> -#ifdef CONFIG_P54_LEDS
> p54_unregister_leds(priv);
> #endif /* CONFIG_P54_LEDS */
>
ACKed-by: Larry Finger <Larry.Finger@lwfinger.net>
^ permalink raw reply
* Re: BUG: while bridging Ethernet and wireless device:
From: Tomas Winkler @ 2010-12-29 16:12 UTC (permalink / raw)
To: Johannes Berg
Cc: linux-netdev, linux-wireless,
YOSHIFUJI Hideaki / 吉藤英明
In-Reply-To: <1293635067.3546.16.camel@jlt3.sipsolutions.net>
2010/12/29 Johannes Berg <johannes@sipsolutions.net>:
> On Thu, 2010-12-16 at 14:11 +0200, Tomas Winkler wrote:
>> Will be happy if someone can give me some more insight. (kernel 2.6.37-rc5)
>
> Tomas looked into it a bit more and told me that it happens on IPv6
> packets. To recap, he gets
>
> kernel BUG at include/linux/skbuff.h:1178!
> with
> EIP: [<f83edd65>] br_multicast_rcv+0xc95/0xe1c [bridge]
>
> Also remember that the packets are almost fully nonlinear, when they get
> here they likely have almost no data in the skb header.
>
> I then looked at br_multicast_ipv6_rcv(), and it looks fishy:
>
> Up to:
> skb2 = skb_clone(skb, GFP_ATOMIC);
>
> everything's fine, since ipv6_skip_exthdr() will use
> skb_header_pointer(). At this point, offset is the result of
> ipv6_skip_exthdr(). Remember that skb_clone() is not skb_copy().
So far I can confirm that switching to sbk_copy fixes the crash.
Thanks
Tomas
^ permalink raw reply
* [PATCH] p54: fix compiler-warning when no P54_LEDS are configured
From: Christoph Paasch @ 2010-12-29 15:14 UTC (permalink / raw)
To: linville; +Cc: Christoph Paasch, linux-wireless, chunkeey
The priv-variable is unused when compiling without CONFIG_P54_LEDS.
Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
---
drivers/net/wireless/p54/main.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/p54/main.c b/drivers/net/wireless/p54/main.c
index 622d27b..a6802f5 100644
--- a/drivers/net/wireless/p54/main.c
+++ b/drivers/net/wireless/p54/main.c
@@ -611,7 +611,9 @@ EXPORT_SYMBOL_GPL(p54_init_common);
int p54_register_common(struct ieee80211_hw *dev, struct device *pdev)
{
+#ifdef CONFIG_P54_LEDS
struct p54_common *priv = dev->priv;
+#endif /* CONFIG_P54_LEDS */
int err;
err = ieee80211_register_hw(dev);
@@ -653,9 +655,9 @@ EXPORT_SYMBOL_GPL(p54_free_common);
void p54_unregister_common(struct ieee80211_hw *dev)
{
+#ifdef CONFIG_P54_LEDS
struct p54_common *priv = dev->priv;
-#ifdef CONFIG_P54_LEDS
p54_unregister_leds(priv);
#endif /* CONFIG_P54_LEDS */
--
1.7.1
^ permalink raw reply related
* Re: BUG: while bridging Ethernet and wireless device:
From: Johannes Berg @ 2010-12-29 15:04 UTC (permalink / raw)
To: Tomas Winkler
Cc: linux-netdev, linux-wireless,
YOSHIFUJI Hideaki / 吉藤英明
In-Reply-To: <AANLkTikYvBspVmAZ0DCMXJ-3WxkotwX+n8NpTtM+97_i@mail.gmail.com>
On Thu, 2010-12-16 at 14:11 +0200, Tomas Winkler wrote:
> Will be happy if someone can give me some more insight. (kernel 2.6.37-rc5)
Tomas looked into it a bit more and told me that it happens on IPv6
packets. To recap, he gets
kernel BUG at include/linux/skbuff.h:1178!
with
EIP: [<f83edd65>] br_multicast_rcv+0xc95/0xe1c [bridge]
Also remember that the packets are almost fully nonlinear, when they get
here they likely have almost no data in the skb header.
I then looked at br_multicast_ipv6_rcv(), and it looks fishy:
Up to:
skb2 = skb_clone(skb, GFP_ATOMIC);
everything's fine, since ipv6_skip_exthdr() will use
skb_header_pointer(). At this point, offset is the result of
ipv6_skip_exthdr(). Remember that skb_clone() is not skb_copy().
Then, however, we do
__skb_pull(skb2, offset);
At this point, however, I don't see anything that guarantees that all
"offset" bytes are part of the headroom -- and indeed I think this is
where it crashes.
If it didn't crash, because this many bytes were part of the header,
continuing further into the function, however, we could still crash:
if (!pskb_may_pull(skb2, sizeof(*icmp6h)))
goto out;
now makes sure that we can read the ICMPv6 header. Later, however, we do
case ICMPV6_MGM_REPORT:
{
struct mld_msg *mld = (struct mld_msg *)icmp6h;
BR_INPUT_SKB_CB(skb2)->mrouters_only = 1;
err = br_ip6_multicast_add_group(br, port, &mld->mld_mca);
which seems just as unsafe since "mld_mca" need not be part of the
header of the SKB. Similarly in another branch of this.
Additionally, I'm not convinced that there even is guaranteed to be
enough space in the SKB at all for the entire "struct mld_msg".
And finally, the error path in this function is confusing. Below patch
should be fine since unlike IPv4 (where this was copied maybe?) this
code unconditionally clones the SKB.
johannes
---
net/bridge/br_multicast.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
--- wireless-testing.orig/net/bridge/br_multicast.c 2010-12-29 15:45:03.000000000 +0100
+++ wireless-testing/net/bridge/br_multicast.c 2010-12-29 16:03:03.000000000 +0100
@@ -1430,7 +1430,7 @@ static int br_multicast_ipv6_rcv(struct
struct net_bridge_port *port,
struct sk_buff *skb)
{
- struct sk_buff *skb2 = skb;
+ struct sk_buff *skb2;
struct ipv6hdr *ip6h;
struct icmp6hdr *icmp6h;
u8 nexthdr;
@@ -1535,9 +1535,7 @@ static int br_multicast_ipv6_rcv(struct
}
out:
- __skb_push(skb2, offset);
- if (skb2 != skb)
- kfree_skb(skb2);
+ kfree_skb(skb2);
return err;
}
#endif
^ permalink raw reply
* Re: [PATCH RFC] mac80211: Extend channel to frequency mapping for 802.11j
From: Dave Kilroy @ 2010-12-29 13:55 UTC (permalink / raw)
To: Johannes Berg; +Cc: Bruno Randolf, linville, linux-wireless
In-Reply-To: <1293529983.3526.9.camel@jlt3.sipsolutions.net>
On Tue, Dec 28, 2010 at 9:53 AM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Tue, 2010-12-28 at 10:51 +0100, Johannes Berg wrote:
>
>> > ieee80211_dsss_chan_to_freq - atmel, airo, wl3501_cs, orinoco, rndis_wlan
>> > ieee80211_freq_to_dsss_chan - atmel, airo, orinoco, zd1201
>> >
>> > Anyhow i guess it would make sense to have a common channel to frequency
>> > mapping function for mac80211 and other wireless drivers? The problem is now
>> > we have to use enum ieee80211_band which is defined cfg80211.h...
>
> Interestingly, I just noticed that the above ones also have different
> semantics -- they try to round to the nearest channel rather than
> returning an error if the center frequency isn't exact.
I suspect I introduced these functions while refactoring orinoco (well
before the cfg80211 conversion). If I recall correctly, there was no
specific reason for the round to nearest behaviour - it just seemed
more appropriate than rounding down the frequencies. So if it helps, I
don't see why we shouldn't modify the behaviour of the ieee80211
functions where necessary.
Dave.
^ 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