* Re: Problems with "cfg80211: fix SME connect" commit
From: Hin-Tak Leung @ 2009-09-30 21:17 UTC (permalink / raw)
To: Johannes Berg; +Cc: Albert Herranz, Holger Schurig, linville, linux-wireless
In-Reply-To: <1253965154.5122.7.camel@johannes.local>
On Sat, Sep 26, 2009 at 12:39 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> The extra deauth is because cfg80211 already starts the auth with the
> BSS before wpa_supplicant set the BSSID, and then when setting the BSSID
> it asks for deauth, but before we ever actually did anything... I think
> we'll just have to live with that, since it's hard to fix in the layered
> design we have now.
Hmm, I looked at the AP log, and the deauth is there... also I think
due to recent changes, association takes longer now. Is there
something that can be done in userland, for example?
Hin-Tak
^ permalink raw reply
* [PATCH 2.6.32] mac80211: fix vlan and optimise RX
From: Johannes Berg @ 2009-09-30 20:18 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless, Blaž Bačnik
In-Reply-To: <1254341787.3959.11.camel@johannes.local>
When receiving data frames, we can send them only to
the interface they belong to based on transmitting
station (this doesn't work for probe requests). Also,
don't try to handle other frames for AP_VLAN at all
since those interface should only receive data.
Additionally, the transmit side must check that the
station we're sending a frame to is actually on the
interface we're transmitting on, and not transmit
packets to functions that live on other interfaces,
so validate that as well.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Cc: stable@kernel.org
---
net/mac80211/rx.c | 10 ++++++++--
net/mac80211/tx.c | 3 ++-
2 files changed, 10 insertions(+), 3 deletions(-)
--- wireless-testing.orig/net/mac80211/rx.c 2009-09-30 21:38:59.000000000 +0200
+++ wireless-testing/net/mac80211/rx.c 2009-09-30 22:09:54.000000000 +0200
@@ -2164,11 +2164,17 @@ static void __ieee80211_rx_handle_packet
skb = rx.skb;
- list_for_each_entry_rcu(sdata, &local->interfaces, list) {
+ if (rx.sdata && ieee80211_is_data(hdr->frame_control)) {
+ rx.flags |= IEEE80211_RX_RA_MATCH;
+ prepares = prepare_for_handlers(rx.sdata, &rx, hdr);
+ if (prepares)
+ prev = rx.sdata;
+ } else list_for_each_entry_rcu(sdata, &local->interfaces, list) {
if (!netif_running(sdata->dev))
continue;
- if (sdata->vif.type == NL80211_IFTYPE_MONITOR)
+ if (sdata->vif.type == NL80211_IFTYPE_MONITOR ||
+ sdata->vif.type == NL80211_IFTYPE_AP_VLAN)
continue;
rx.flags |= IEEE80211_RX_RA_MATCH;
--- wireless-testing.orig/net/mac80211/tx.c 2009-09-30 21:49:34.000000000 +0200
+++ wireless-testing/net/mac80211/tx.c 2009-09-30 22:04:25.000000000 +0200
@@ -1704,7 +1704,8 @@ netdev_tx_t ieee80211_subif_start_xmit(s
if (!is_multicast_ether_addr(hdr.addr1)) {
rcu_read_lock();
sta = sta_info_get(local, hdr.addr1);
- if (sta)
+ /* XXX: in the future, use sdata to look up the sta */
+ if (sta && sta->sdata == sdata)
sta_flags = get_sta_flags(sta);
rcu_read_unlock();
}
^ permalink raw reply
* Re: VLAN traffic appearing on the wrong iface
From: Johannes Berg @ 2009-09-30 20:16 UTC (permalink / raw)
To: Blaž Bačnik; +Cc: linux-wireless
In-Reply-To: <57b62e7d0909291754x352ae254sa33ee7efb430d497@mail.gmail.com>
On Wed, 2009-09-30 at 02:54 +0200, Blaž Bačnik wrote:
> I use RADIUS-assigned vlans with my AP. Hostapd reports vlan change
> during authentication and the station appears on correct vlan
> according to "iw dev ... station dump". But actual packets keep coming
> in on the default interface (wlan0), not the vlan one (eg. wlan0.2).
Actually, it looks like they come in on both :)
> I also tried taking RADIUS out of the loop, so I used hostapd's
> "accept_mac_file" with specified vlan and I think I might have found
> another bug. After applying the patch below (for I believe a rather
> obvious typo), kernel started oopsing and I gave up. If needed, I can
> provide config files for either hostapd or freeradius server, though
> it looks like this is a driver problem.
I can't reproduce that oops, but we have a fix to the issue which I'll
send separately.
johannes
^ permalink raw reply
* unused header file drivers/net/wireless/wl12xx/wl1251_netlink.h?
From: Robert P. J. Day @ 2009-09-30 19:55 UTC (permalink / raw)
To: linux-wireless
as best i can tell, that header file is entirely unreferenced by
anything in the tree. just an observation.
rday
--
========================================================================
Robert P. J. Day Waterloo, Ontario, CANADA
Linux Consulting, Training and Annoying Kernel Pedantry.
Web page: http://crashcourse.ca
Twitter: http://twitter.com/rpjday
========================================================================
^ permalink raw reply
* Making Intel WiFi Link 1000 usable in 2.6.31
From: reinette chatre @ 2009-09-30 19:34 UTC (permalink / raw)
To: stable; +Cc: linux-wireless
Hi,
A few distributions would like to enable the new 1000 series Intel
wireless hardware (Intel WiFi Link 1000BGN) in their next releases that
are based on 2.6.31. This hardware is not usable in 2.6.31, but it can
be enabled in this kernel with the addition of five patches.
Until now we have been providing the distributions with this list of
patches to do their own backporting.
Since this seems to be a general problem for distributions and users
alike, is it possible to consider these enabling patches for inclusion
into 2.6.31?
Here is the list:
commit cc0f555d511a5fe9d4519334c8f674a1dbab9e3a
Author: Jay Sternberg <jay.e.sternberg@intel.com>
Date: Fri Jul 17 09:30:16 2009 -0700
iwlwifi: Handle new firmware file with ucode build number in header
commit cce53aa347c1e023d967b1cb1aa393c725aedba5
Author: Jay Sternberg <jay.e.sternberg@intel.com>
Date: Fri Jul 17 09:30:22 2009 -0700
iwlwifi: update 1000 series API version to match firmware
commit 02c06e4abc0680afd31bf481a803541556757fb6
Author: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Date: Fri Jul 17 09:30:14 2009 -0700
iwlagn: modify digital SVR for 1000
commit 415e49936b4b29b34c2fb561eeab867d41fc43a6
Author: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Date: Thu Aug 13 13:30:54 2009 -0700
iwlwifi: traverse linklist to find the valid OTP block
commit f7ea097d9b4e61a816c041c92548aad7c7ed7915
Author: Reinette Chatre <reinette.chatre@intel.com>
Date: Fri Jul 24 11:13:12 2009 -0700
iwlagn: fix null pointer access during ucode load on 1000
Thank you very much
Reinette
^ permalink raw reply
* Re: [PATCH] compat-wireless: Fix b44 build issues.
From: Luis R. Rodriguez @ 2009-09-30 19:30 UTC (permalink / raw)
To: Tim Gardner; +Cc: linux-wireless
In-Reply-To: <20090930170000.09582F88DD@sepang.rtg.net>
On Wed, Sep 30, 2009 at 10:00 AM, Tim Gardner <timg@tpi.com> wrote:
> From 553180d80860c6090b7d82f809ea7131afca01d6 Mon Sep 17 00:00:00 2001
> From: Tim Gardner <tim.gardner@canonical.com>
> Date: Wed, 30 Sep 2009 10:02:35 -0600
> Subject: [PATCH] compat-wireless: Fix b44 build issues.
>
> Even though CONFIG_B44 is defined, there is no Makefile
> created in drivers/net. This failure to build allows the
> in-kernel version of b44 to get loaded with a compat-wireless
> version of ssb.ko, never a good thing.
>
> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Applied thanks. I must've fat fingered a commit and push after testing
driver-select, whoopsie.. sorry about that.
Luis
^ permalink raw reply
* Re: iwl-1000 firmware versions 1 and 2 are nowhere to be found
From: Luis R. Rodriguez @ 2009-09-30 19:13 UTC (permalink / raw)
To: reinette chatre; +Cc: tim.gardner@canonical.com, linux-wireless@vger.kernel.org
In-Reply-To: <1254334586.26521.1617.camel@rc-desk>
On Wed, Sep 30, 2009 at 11:16 AM, reinette chatre
<reinette.chatre@intel.com> wrote:
> Hi Tim,
>
> On Wed, 2009-09-30 at 11:03 -0700, Tim Gardner wrote:
>> I've got a user complaining that the iwl-1000 firmware version required
>> by 2.6.31 doesn't exist. Indeed, IWL1000_UCODE_API_MAX is 2, yet the
>> only firmware available from http://intellinuxwireless.org/?n=Downloads
>> is iwlwifi-1000-3.ucode. Shall I just tell him to install compat-wireless ?
>>
>> BugLink: http://bugs.launchpad.net/bugs/439285
>>
>
> 2.6.31 needs a few more patches to fully support 1000 series
So just a heads up the stable compat-wireless stuff is here:
http://wireless.kernel.org/en/users/Download/stable/
I'll soon make a release based on 2.6.32-rc1, but I thought 2.6.32-rc1
was going to be busted, not sure yet, it may be. We probably should
wait for rc2.
Luis
^ permalink raw reply
* Re: [ath9k-devel] Possible to set MCS Index?
From: Luis R. Rodriguez @ 2009-09-30 19:04 UTC (permalink / raw)
To: Matt Tierney; +Cc: ath9k-devel@lists.ath9k.org, linux-wireless
In-Reply-To: <d355d36c0909301116l5b6f05f2s4834a47142810a54@mail.gmail.com>
On Wed, Sep 30, 2009 at 11:16 AM, Matt Tierney
<matt.tierney@post.harvard.edu> wrote:
>
>> mac80211 rate control code is MCS rate unaware, but we do at least
>> let drivers pass the MCS rate for tx status reporting. ath9k
>> unfortunately reports back the wrong MCS rate though because
>> of the way ath9k rate control works...
>
> Hm. I'm confused. I realize iw and the ath9k driver might be separate
> entities, but it seemed like iw was corroborating ath9k debug output with my
> setup. /sys/kernel/debug/ath9k/phy0/rcstat showed that one packet was
> successfully sent at the maximum rate possible with MCS Index 12 (162 Mbps)
> and index 12 seems to have that 1 bit flipped as the highest index in the
> "HT MCS Set" I copied in my `iw list` printout; albeit, that was one packet
> successfully sent compared to 1261 at 81.5 Mbps and 254 at 54 Mbps. Anyway,
> I thought that the HT MCS Set indicated the correct values (as seen in the
> ath9k rcstat) but I think you're saying it might not =(
No, ath9k debugfs rcstat is fine. What we do not set properly for
mac80211 is the rx status bit rate for MCS rates, this means iw
station dump thing won't give you the right MCS rate.
> Is there a way for me to capture the MCS rate info sent from the driver for
> my own debugging view then? (It's not clear to me which ath9k debug bits to
> set in order to get that information when I modprobe ath9k, if there is a
> set that would give me that information).
You were using the right thing for now:
http://wireless.kernel.org/en/users/Drivers/ath9k/debug#rcstat
>> The first step then is to make mac80211 rate controle code MCS
>> aware and adding MCS rate control support to minstrel, for example.
>>
>> For ath9k it'd be nice to fix the rate control code to be able
>> to report the right MCS index, I really am not sure how involved
>> that is as I've tried to stay away from the rate control code.
>
> I see - this is messier than I anticipated... So, is what I'm trying to do
> (set MCS tx rates) something that I should examine in mac80211 code or is
> ath9k the place to be? (I'm not familiar with how all the pieces of ath9k,
> mac80211, nl80211, cfg80211, etc fit together so that's all contributing to
> my confusion...)
Try to work on a debugfs way to do this first. Something like:
echo 15 > /sys/kernel/debug/ath9k/phy0/mcs-rate
To set MCS 15 statically.
>> A good step would be to get ath9k rate control to be switchable
>> to minstrel, for example. This can be done as a module parameter
>> to start but eventually I think it'd be nice to be able to switch
>> through iw on any given device. That would require quite a lot of
>> work though.
>
> Any suggestions on how to start thinking about this? Are there examples in
> the ath9k code of making this sort of adaptation?
As I said above, the easy way would be through debugfs. The nice thing
about debugfs is we can remove it at will later.
>> Once mac80211 is MCS rate control aware the next step would be to
>> add a commands to set an MCS rate.
>>
>> The cheesy and quick way to this for ath9k would be through
>> ath9k/debufs.c
>
> Would this be able to actually set an MCS rate though?
Why not?
> I thought that
> debug.c was composed of 'read-only' features.
Nope, you can echo to wiphy file to add a new virtual wiphy for
example, or to the debug file to change the debug level on demand. Hm,
I guess no one reads documentation or we need to really work harder on
promoting our wireless wiki.
> If it is possible, then this
> is the quick and dirty fix I'd like to use now,
Go for it.
Luis
^ permalink raw reply
* Re: [PATCH] net: fix NOHZ: local_softirq_pending 08
From: John W. Linville @ 2009-09-30 18:47 UTC (permalink / raw)
To: Oliver Hartkopp
Cc: David Miller, Johannes Berg, Michael Buesch, Kalle Valo,
linux-wireless, netdev
In-Reply-To: <4AC3A0F1.3060306@hartkopp.net>
On Wed, Sep 30, 2009 at 08:18:25PM +0200, Oliver Hartkopp wrote:
> Socket buffers that are generated and received inside softirqs or from process
> context must not use netif_rx() that's intended to be used from irq context only.
>
> This patch introduces a new helper function netif_rx_ti(skb) that tests for
> in_interrupt() before invoking netif_rx() or netif_rx_ni().
>
> It fixes the ratelimited kernel warning
>
> NOHZ: local_softirq_pending 08
>
> in the mac80211 and can subsystems.
>
> Signed-off-by: Oliver Hartkopp <oliver@hartkopp.net>
http://bugzilla.kernel.org/show_bug.cgi?id=14278
Acked-by: John W. Linville <linville@tuxdriver.com>
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: iwl-1000 firmware versions 1 and 2 are nowhere to be found
From: John W. Linville @ 2009-09-30 18:45 UTC (permalink / raw)
To: reinette chatre
Cc: tim.gardner@canonical.com, linux-wireless@vger.kernel.org, stable
In-Reply-To: <1254334586.26521.1617.camel@rc-desk>
Perhaps these should go in the stable series?
John
On Wed, Sep 30, 2009 at 11:16:26AM -0700, reinette chatre wrote:
> Hi Tim,
>
> On Wed, 2009-09-30 at 11:03 -0700, Tim Gardner wrote:
> > I've got a user complaining that the iwl-1000 firmware version required
> > by 2.6.31 doesn't exist. Indeed, IWL1000_UCODE_API_MAX is 2, yet the
> > only firmware available from http://intellinuxwireless.org/?n=Downloads
> > is iwlwifi-1000-3.ucode. Shall I just tell him to install compat-wireless ?
> >
> > BugLink: http://bugs.launchpad.net/bugs/439285
> >
>
> 2.6.31 needs a few more patches to fully support 1000 series, among
> these is the patch that can parse a new ucode header format and another
> patch to update the ucode API.
>
> Depending on the requirements it may be easier to backport those patches
> or to just use compat-wireless. That will be the user's decision.
>
> Here is the list of patches:
>
> commit cc0f555d511a5fe9d4519334c8f674a1dbab9e3a
> Author: Jay Sternberg <jay.e.sternberg@intel.com>
> Date: Fri Jul 17 09:30:16 2009 -0700
>
> iwlwifi: Handle new firmware file with ucode build number in header
>
> commit cce53aa347c1e023d967b1cb1aa393c725aedba5
> Author: Jay Sternberg <jay.e.sternberg@intel.com>
> Date: Fri Jul 17 09:30:22 2009 -0700
>
> iwlwifi: update 1000 series API version to match firmware
>
> commit 02c06e4abc0680afd31bf481a803541556757fb6
> Author: Wey-Yi Guy <wey-yi.w.guy@intel.com>
> Date: Fri Jul 17 09:30:14 2009 -0700
>
> iwlagn: modify digital SVR for 1000
>
> commit 415e49936b4b29b34c2fb561eeab867d41fc43a6
> Author: Wey-Yi Guy <wey-yi.w.guy@intel.com>
> Date: Thu Aug 13 13:30:54 2009 -0700
>
> iwlwifi: traverse linklist to find the valid OTP block
>
> commit f7ea097d9b4e61a816c041c92548aad7c7ed7915
> Author: Reinette Chatre <reinette.chatre@intel.com>
> Date: Fri Jul 24 11:13:12 2009 -0700
>
> iwlagn: fix null pointer access during ucode load on 1000
>
> Reinette
>
>
>
>
> --
> 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
>
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: iwl-1000 firmware versions 1 and 2 are nowhere to be found
From: Tim Gardner @ 2009-09-30 18:54 UTC (permalink / raw)
To: reinette chatre; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1254334586.26521.1617.camel@rc-desk>
reinette chatre wrote:
> Hi Tim,
>
> On Wed, 2009-09-30 at 11:03 -0700, Tim Gardner wrote:
>> I've got a user complaining that the iwl-1000 firmware version required
>> by 2.6.31 doesn't exist. Indeed, IWL1000_UCODE_API_MAX is 2, yet the
>> only firmware available from http://intellinuxwireless.org/?n=Downloads
>> is iwlwifi-1000-3.ucode. Shall I just tell him to install compat-wireless ?
>>
>> BugLink: http://bugs.launchpad.net/bugs/439285
>>
>
> 2.6.31 needs a few more patches to fully support 1000 series, among
> these is the patch that can parse a new ucode header format and another
> patch to update the ucode API.
>
> Depending on the requirements it may be easier to backport those patches
> or to just use compat-wireless. That will be the user's decision.
>
> Here is the list of patches:
>
> commit cc0f555d511a5fe9d4519334c8f674a1dbab9e3a
> Author: Jay Sternberg <jay.e.sternberg@intel.com>
> Date: Fri Jul 17 09:30:16 2009 -0700
>
> iwlwifi: Handle new firmware file with ucode build number in header
>
> commit cce53aa347c1e023d967b1cb1aa393c725aedba5
> Author: Jay Sternberg <jay.e.sternberg@intel.com>
> Date: Fri Jul 17 09:30:22 2009 -0700
>
> iwlwifi: update 1000 series API version to match firmware
>
> commit 02c06e4abc0680afd31bf481a803541556757fb6
> Author: Wey-Yi Guy <wey-yi.w.guy@intel.com>
> Date: Fri Jul 17 09:30:14 2009 -0700
>
> iwlagn: modify digital SVR for 1000
>
> commit 415e49936b4b29b34c2fb561eeab867d41fc43a6
> Author: Wey-Yi Guy <wey-yi.w.guy@intel.com>
> Date: Thu Aug 13 13:30:54 2009 -0700
>
> iwlwifi: traverse linklist to find the valid OTP block
>
> commit f7ea097d9b4e61a816c041c92548aad7c7ed7915
> Author: Reinette Chatre <reinette.chatre@intel.com>
> Date: Fri Jul 24 11:13:12 2009 -0700
>
> iwlagn: fix null pointer access during ucode load on 1000
>
> Reinette
>
Hmm, I think I'll just disable the 2 PCI IDs for these cards since they
never really worked in 2.6.31 anyways. Does that make sense to you? The
above patch sets are too invasive at this point in the Karmic release
cycle. compat-wireless to the rescue.
rtg
--
Tim Gardner tim.gardner@canonical.com
^ permalink raw reply
* [PATCH] net: fix NOHZ: local_softirq_pending 08
From: Oliver Hartkopp @ 2009-09-30 18:18 UTC (permalink / raw)
To: David Miller
Cc: Johannes Berg, Michael Buesch, Kalle Valo, John W. Linville,
linux-wireless, netdev
In-Reply-To: <4AC39A90.6060602@hartkopp.net>
[-- Attachment #1: Type: text/plain, Size: 478 bytes --]
Socket buffers that are generated and received inside softirqs or from process
context must not use netif_rx() that's intended to be used from irq context only.
This patch introduces a new helper function netif_rx_ti(skb) that tests for
in_interrupt() before invoking netif_rx() or netif_rx_ni().
It fixes the ratelimited kernel warning
NOHZ: local_softirq_pending 08
in the mac80211 and can subsystems.
Signed-off-by: Oliver Hartkopp <oliver@hartkopp.net>
---
[-- Attachment #2: net-NOHZ-local_softirq_pending-08.patch --]
[-- Type: text/x-patch, Size: 4031 bytes --]
diff --git a/drivers/net/can/vcan.c b/drivers/net/can/vcan.c
index 80ac563..899f3d3 100644
--- a/drivers/net/can/vcan.c
+++ b/drivers/net/can/vcan.c
@@ -80,7 +80,7 @@ static void vcan_rx(struct sk_buff *skb, struct net_device *dev)
skb->dev = dev;
skb->ip_summed = CHECKSUM_UNNECESSARY;
- netif_rx_ni(skb);
+ netif_rx_ti(skb);
}
static netdev_tx_t vcan_tx(struct sk_buff *skb, struct net_device *dev)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 94958c1..dc8dfb2 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -1509,6 +1509,19 @@ extern int netdev_budget;
extern void netdev_run_todo(void);
/**
+ * netif_rx_ti - test for irq context and post buffer to the network code
+ * @skb: buffer to post
+ *
+ */
+static inline int netif_rx_ti(struct sk_buff *skb)
+{
+ if (in_interrupt())
+ return netif_rx(skb);
+ else
+ return netif_rx_ni(skb);
+}
+
+/**
* dev_put - release reference to device
* @dev: network device
*
diff --git a/net/can/af_can.c b/net/can/af_can.c
index 6068321..c21e7f4 100644
--- a/net/can/af_can.c
+++ b/net/can/af_can.c
@@ -199,8 +199,6 @@ static int can_create(struct net *net, struct socket *sock, int protocol)
* @skb: pointer to socket buffer with CAN frame in data section
* @loop: loopback for listeners on local CAN sockets (recommended default!)
*
- * Due to the loopback this routine must not be called from hardirq context.
- *
* Return:
* 0 on success
* -ENETDOWN when the selected interface is down
@@ -280,7 +278,7 @@ int can_send(struct sk_buff *skb, int loop)
}
if (newskb)
- netif_rx_ni(newskb);
+ netif_rx_ti(newskb);
/* update statistics */
can_stats.tx_frames++;
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index 5608f6c..bbcb4cb 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -606,7 +606,7 @@ static void ieee80211_send_layer2_update(struct sta_info *sta)
skb->dev = sta->sdata->dev;
skb->protocol = eth_type_trans(skb, sta->sdata->dev);
memset(skb->cb, 0, sizeof(skb->cb));
- netif_rx(skb);
+ netif_rx_ti(skb);
}
static void sta_apply_parameters(struct ieee80211_local *local,
diff --git a/net/mac80211/main.c b/net/mac80211/main.c
index 797f539..1109f99 100644
--- a/net/mac80211/main.c
+++ b/net/mac80211/main.c
@@ -591,7 +591,7 @@ void ieee80211_tx_status(struct ieee80211_hw *hw, struct sk_buff *skb)
skb2 = skb_clone(skb, GFP_ATOMIC);
if (skb2) {
skb2->dev = prev_dev;
- netif_rx(skb2);
+ netif_rx_ti(skb2);
}
}
@@ -600,7 +600,7 @@ void ieee80211_tx_status(struct ieee80211_hw *hw, struct sk_buff *skb)
}
if (prev_dev) {
skb->dev = prev_dev;
- netif_rx(skb);
+ netif_rx_ti(skb);
skb = NULL;
}
rcu_read_unlock();
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index c01588f..5bb7c04 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -309,7 +309,7 @@ ieee80211_rx_monitor(struct ieee80211_local *local, struct sk_buff *origskb,
skb2 = skb_clone(skb, GFP_ATOMIC);
if (skb2) {
skb2->dev = prev_dev;
- netif_rx(skb2);
+ netif_rx_ti(skb2);
}
}
@@ -320,7 +320,7 @@ ieee80211_rx_monitor(struct ieee80211_local *local, struct sk_buff *origskb,
if (prev_dev) {
skb->dev = prev_dev;
- netif_rx(skb);
+ netif_rx_ti(skb);
} else
dev_kfree_skb(skb);
@@ -1349,7 +1349,7 @@ ieee80211_deliver_skb(struct ieee80211_rx_data *rx)
/* deliver to local stack */
skb->protocol = eth_type_trans(skb, dev);
memset(skb->cb, 0, sizeof(skb->cb));
- netif_rx(skb);
+ netif_rx_ti(skb);
}
}
@@ -1943,7 +1943,7 @@ static void ieee80211_rx_cooked_monitor(struct ieee80211_rx_data *rx)
skb2 = skb_clone(skb, GFP_ATOMIC);
if (skb2) {
skb2->dev = prev_dev;
- netif_rx(skb2);
+ netif_rx_ti(skb2);
}
}
@@ -1954,7 +1954,7 @@ static void ieee80211_rx_cooked_monitor(struct ieee80211_rx_data *rx)
if (prev_dev) {
skb->dev = prev_dev;
- netif_rx(skb);
+ netif_rx_ti(skb);
skb = NULL;
} else
goto out_free_skb;
^ permalink raw reply related
* Re: iwl-1000 firmware versions 1 and 2 are nowhere to be found
From: reinette chatre @ 2009-09-30 18:16 UTC (permalink / raw)
To: tim.gardner@canonical.com; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <4AC39D6F.5070308@canonical.com>
Hi Tim,
On Wed, 2009-09-30 at 11:03 -0700, Tim Gardner wrote:
> I've got a user complaining that the iwl-1000 firmware version required
> by 2.6.31 doesn't exist. Indeed, IWL1000_UCODE_API_MAX is 2, yet the
> only firmware available from http://intellinuxwireless.org/?n=Downloads
> is iwlwifi-1000-3.ucode. Shall I just tell him to install compat-wireless ?
>
> BugLink: http://bugs.launchpad.net/bugs/439285
>
2.6.31 needs a few more patches to fully support 1000 series, among
these is the patch that can parse a new ucode header format and another
patch to update the ucode API.
Depending on the requirements it may be easier to backport those patches
or to just use compat-wireless. That will be the user's decision.
Here is the list of patches:
commit cc0f555d511a5fe9d4519334c8f674a1dbab9e3a
Author: Jay Sternberg <jay.e.sternberg@intel.com>
Date: Fri Jul 17 09:30:16 2009 -0700
iwlwifi: Handle new firmware file with ucode build number in header
commit cce53aa347c1e023d967b1cb1aa393c725aedba5
Author: Jay Sternberg <jay.e.sternberg@intel.com>
Date: Fri Jul 17 09:30:22 2009 -0700
iwlwifi: update 1000 series API version to match firmware
commit 02c06e4abc0680afd31bf481a803541556757fb6
Author: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Date: Fri Jul 17 09:30:14 2009 -0700
iwlagn: modify digital SVR for 1000
commit 415e49936b4b29b34c2fb561eeab867d41fc43a6
Author: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Date: Thu Aug 13 13:30:54 2009 -0700
iwlwifi: traverse linklist to find the valid OTP block
commit f7ea097d9b4e61a816c041c92548aad7c7ed7915
Author: Reinette Chatre <reinette.chatre@intel.com>
Date: Fri Jul 24 11:13:12 2009 -0700
iwlagn: fix null pointer access during ucode load on 1000
Reinette
^ permalink raw reply
* iwl-1000 firmware versions 1 and 2 are nowhere to be found
From: Tim Gardner @ 2009-09-30 18:03 UTC (permalink / raw)
To: reinette chatre; +Cc: linux-wireless@vger.kernel.org
Reinette,
I've got a user complaining that the iwl-1000 firmware version required
by 2.6.31 doesn't exist. Indeed, IWL1000_UCODE_API_MAX is 2, yet the
only firmware available from http://intellinuxwireless.org/?n=Downloads
is iwlwifi-1000-3.ucode. Shall I just tell him to install compat-wireless ?
BugLink: http://bugs.launchpad.net/bugs/439285
rtg
--
Tim Gardner tim.gardner@canonical.com
^ permalink raw reply
* Re: VLAN traffic appearing on the wrong iface
From: Jouni Malinen @ 2009-09-30 17:51 UTC (permalink / raw)
To: Blaž Bačnik; +Cc: linux-wireless
In-Reply-To: <57b62e7d0909291754x352ae254sa33ee7efb430d497@mail.gmail.com>
On Wed, Sep 30, 2009 at 02:54:10AM +0200, Blaž Bačnik wrote:
> I use RADIUS-assigned vlans with my AP. Hostapd reports vlan change
> during authentication and the station appears on correct vlan
> according to "iw dev ... station dump". But actual packets keep coming
> in on the default interface (wlan0), not the vlan one (eg. wlan0.2).
You will need (at least) the following fix in hostapd to get this
working:
http://w1.fi/gitweb/gitweb.cgi?p=hostap.git;a=commitdiff;h=1c766b094a82a669a1d0bb7f8d132b322e56e81d
I have not tested whether this actually works, so no guarantees on that
being the only remaining issue.
> I also tried taking RADIUS out of the loop, so I used hostapd's
> "accept_mac_file" with specified vlan and I think I might have found
> another bug. After applying the patch below (for I believe a rather
> obvious typo), kernel started oopsing and I gave up. If needed, I can
> provide config files for either hostapd or freeradius server, though
> it looks like this is a driver problem.
Thanks for the hostapd patch (even better thanks would have been given
should it have been sent to the hostap mailing list or me ;-). It is now
in the current development (0.7.x) tree for hostapd (with the additional
fix I mentioned above). If you can test one, it would be interesting to
hear whether VLANs are actually working now.
As far as the kernel oops is concerned, that does not sound good..
hostapd should not have been able to trigger such a thing even with the
not-yey-fixed driver_nl80211.c.. Some more details on this could be
useful if I cannot easily reproduce the oops.
--
Jouni Malinen PGP id EFC895FA
^ permalink raw reply
* Re: mac80211: NOHZ: local_softirq_pending 08
From: Oliver Hartkopp @ 2009-09-30 17:51 UTC (permalink / raw)
To: Johannes Berg
Cc: Michael Buesch, Kalle Valo, John W. Linville, linux-wireless,
netdev
In-Reply-To: <1254324077.3959.7.camel@johannes.local>
Johannes Berg wrote:
> On Wed, 2009-09-30 at 17:10 +0200, Michael Buesch wrote:
>> On Wednesday 30 September 2009 16:54:26 Johannes Berg wrote:
>>> On Wed, 2009-09-30 at 17:47 +0300, Kalle Valo wrote:
>>>
>>>> I agree with Michael. The bug is real and I have verified that
>>>> Michael's patch fixes the issue. Better to apply the patch now, it's
>>>> trivial to change the implementation if/when the network stack has
>>>> support for this.
>>> FWIW, I think in mac80211 the in_interrupt() check can never return true
>>> since we postpone all RX to the tasklet. But the tasklet seems to be ok
>>> -- so should it really be in_interrupt()?
>> I think a tasklet is also in_interrupt(), because it's a softirq.
>
> Ah, yes, indeed, in_interrupt() vs. in_irq().
>
Oops!
I missed that for my previous patch i added for two occurrences in the CAN
sources.
I'm currently compiling the patch for netif_rx_ti() and will post it in some
minutes (for CAN and mac80211) when it runs without probs.
Regards,
Oliver
^ permalink raw reply
* Re: [ath9k-devel] Possible to set MCS Index?
From: John W. Linville @ 2009-09-30 17:23 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Matt Tierney, ath9k-devel@lists.ath9k.org, linux-wireless
In-Reply-To: <20090930164853.GA5730@mosca>
On Wed, Sep 30, 2009 at 09:48:53AM -0700, Luis R. Rodriguez wrote:
> A good step would be to get ath9k rate control to be switchable
> to minstrel, for example. This can be done as a module parameter
> to start but eventually I think it'd be nice to be able to switch
> through iw on any given device. That would require quite a lot of
> work though.
ACK to the above...
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: [iw PATCH] default install to $(PREFIX)/sbin
From: Tim Gardner @ 2009-09-30 17:21 UTC (permalink / raw)
To: John W. Linville; +Cc: johannes, linux-wireless
In-Reply-To: <1254316786-4670-1-git-send-email-linville@tuxdriver.com>
John W. Linville wrote:
> The iw utility isn't generally useful to normal users, so move it to
> $(PREFIX)/sbin with other system management executables.
>
> Signed-off-by: John W. Linville <linville@tuxdriver.com>
> ---
> As "suggested" by Johannes... :-)
>
> Makefile | 6 +++---
> 1 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index cb5fcc1..68bef4d 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -3,7 +3,7 @@
> MAKEFLAGS += --no-print-directory
>
> PREFIX ?= /usr
> -BINDIR ?= $(PREFIX)/bin
> +SBINDIR ?= $(PREFIX)/sbin
> MANDIR ?= $(PREFIX)/share/man
> PKG_CONFIG ?= pkg-config
>
> @@ -85,8 +85,8 @@ check:
>
> install: iw iw.8.gz
> @$(NQ) ' INST iw'
> - $(Q)$(MKDIR) $(DESTDIR)$(BINDIR)
> - $(Q)$(INSTALL) -m 755 -t $(DESTDIR)$(BINDIR) iw
> + $(Q)$(MKDIR) $(DESTDIR)$(SBINDIR)
> + $(Q)$(INSTALL) -m 755 -t $(DESTDIR)$(SBINDIR) iw
> @$(NQ) ' INST iw.8'
> $(Q)$(MKDIR) $(DESTDIR)$(MANDIR)/man8/
> $(Q)$(INSTALL) -m 644 -t $(DESTDIR)$(MANDIR)/man8/ iw.8.gz
FWIW Ubuntu wireless-tools drops rfkill in /sbin, where I think tools
that require root for changes should live.
rtg
--
Tim Gardner tim.gardner@canonical.com
^ permalink raw reply
* Re: A problem loading ssb module
From: Tim Gardner @ 2009-09-30 16:59 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Luis Rodriguez, Luis R. Rodriguez, Clyde McPherson,
Hauke Mehrtens, linux-wireless, bcm43xx-dev@lists.berlios.de
In-Reply-To: <20090928210058.GD7788@mosca>
Luis R. Rodriguez wrote:
> On Mon, Sep 28, 2009 at 01:38:46PM -0700, Tim Gardner wrote:
>> Luis R. Rodriguez wrote:
>>> On Mon, Sep 28, 2009 at 01:00:55PM -0700, Tim Gardner wrote:
>>>> Luis R. Rodriguez wrote:
>>>>> On Sun, Sep 27, 2009 at 12:50:19PM -0700, Luis R. Rodriguez wrote:
>>>>>> On Sun, Sep 27, 2009 at 8:15 AM, Clyde McPherson <ccmcphe@verizon.net> wrote:
>>>>>>>> On Thu, Sep 24, 2009 at 11:33 AM, Hauke Mehrtens <hauke@hauke-m.de> wrote:
>>>>>>>>
>>>>>>>>> Bryan Wu wrote:
>>>>>>>>>
>>>>>>>>>> Mauro Di Domenico wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi,
>>>>>>>>>>> I'm testing new b43 modules for my 14e4:4315 broadcom card.
>>>>>>>>>>> I've compiled and installed compat-wireless-2009-09-16 in a debian
>>>>>>>>>>> machine with kernel version 2.6.30-6.
>>>>>>>>>>>
>>>>>>>>>>> During the boot I experience this problem:
>>>>>>>>>>>
>>>>>>>>>>> $ dmesg|egrep "b43|ssb"
>>>>>>>>>>>
>>>>>>>>>>> [ 2.384463] b43-pci-bridge 0000:06:00.0: PCI INT A -> GSI 17 (level,
>>>>>>>>>>> low) -> IRQ 17
>>>>>>>>>>> [ 2.384477] b43-pci-bridge 0000:06:00.0: setting latency timer to 64
>>>>>>>>>>> [ 2.544344] ssb: Sonics Silicon Backplane found on PCI device
>>>>>>>>>>> 0000:06:00.0
>>>>>>>>>>> [ 6.968981] b43: disagrees about version of symbol
>>>>>>>>>>> ssb_device_is_enabled
>>>>>>>>>>> [ 6.968986] b43: Unknown symbol ssb_device_is_enabled
>>>>>>>>>>> [ 6.969280] b43: Unknown symbol ssb_pmu_set_ldo_paref
>>>>>>>>>>> [ 6.969407] b43: disagrees about version of symbol
>>>>>>>>>>> ssb_pcicore_dev_irqvecs_enable
>>>>>>>>>>> [ 6.969410] b43: Unknown symbol ssb_pcicore_dev_irqvecs_enable
>>>>>>>>>>> .....
>>>>>>>>>>> ....
>>>>>>>>>>> ...
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> I faced the exactly same issue as Mauro did. +1 from me, but currently
>>>>>>>>>> have
>>>>>>>>>> no time to take a deeper look.
>>>>>>>>>>
>>>>>>>>>> Thanks
>>>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> I had the same problem with the ssb module and compat-wireless in ubuntu
>>>>>>>>> 9.04. The problem is that the ssb module is integrated into the
>>>>>>>>> initramfs image. The version out of the initramfs image is loaded on
>>>>>>>>> startup and not the version of compat-wireless. Running "sudo
>>>>>>>>> update-initramfs -u" after installing compat-wireless and restaing the
>>>>>>>>> system fixes the problem for me. Either Debian/Ubuntu should remove ssb
>>>>>>>>> form default initramfs image or compat-wireless should update the image
>>>>>>>>> with the install command. At least the compat-wireless documentation
>>>>>>>>> needs an update.
>>>>>>>>>
>>>>>>>>> Hauke
>>>>>>>>>
>>>>>>>>> (adding Luis and linux-wireless list)
>>>>>>>>>
>>>>>>>> Tim, do you guys update the initramfs upon installation of lbm? If a
>>>>>>>> user does not use lbm and uses compat-wireless I suppose we need to do
>>>>>>>> something similar.
>>>>>>>>
>>>>>>>> Luis
>>>>>>>> _______________________________________________
>>>>>>>> Bcm43xx-dev mailing list
>>>>>>>> Bcm43xx-dev@lists.berlios.de
>>>>>>>> https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
>>>>>>>>
>>>>>>> All:
>>>>>>> I have a large group that uses the ssb module along with the Broadcom 4318,
>>>>>>> in a CF form factor. If the CF card is inserted before boot, and the ssb
>>>>>>> module is not in the initrd process, the laptops lock up and do not become
>>>>>>> operational. The solution to this problem is/was adding the ssb.ko to the
>>>>>>> initrd process. So I agree with Luis on this, the ssb module will have to be
>>>>>>> added/updated to the initrd process. As for PCI operations, I don't know,
>>>>>>> but for PCMCIA operations ssb.ko has to be added and/or updated. Anytime I
>>>>>>> am testing new releases of b43, I run "update-initramfs -u" to update the
>>>>>>> ssb module. (Sometimes you can do a rmmod ssb and rmmod b43, and then
>>>>>>> modprobe them back in. - This saves a reboot)
>>>>>> But why is ssb, b43, b44 needed upon early boot?
>>>>> OK the reason seems to be netboot. Yeah the only fix for distros who want
>>>>> this on the initramfs is to update it after a compat-wireless package is
>>>>> installed. I suppose we can add a hook to compat-wireless for each distro.
>>>>> I'm only familiar with Ubuntu way of doing this so if people are interested
>>>>> in other distros you'll need to point/test how to do this on there.
>>>>>
>>>>> Please try this patch against compat-wireless: (also attached)
>>>>>
>>>>> From 99af88246c2de71aa799de2b63f9d9ccac41634f Mon Sep 17 00:00:00 2001
>>>>> From: Luis R. Rodriguez <lrodriguez@atheros.com>
>>>>> Date: Sun, 27 Sep 2009 13:58:22 -0700
>>>>> Subject: [PATCH] Add scripts/update-initramfs and use it
>>>>>
>>>>> Some distributions may ship b44 and ssb on the initramfs for
>>>>> netboot. To help with this we need to update the initrafms
>>>>> for those distributions.
>>>>>
>>>>> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
>>>>> ---
>>>>> Makefile | 1 +
>>>>> scripts/update-initramfs | 33 +++++++++++++++++++++++++++++++++
>>>>> 2 files changed, 34 insertions(+), 0 deletions(-)
>>>>> create mode 100755 scripts/update-initramfs
>>>>>
>>>>> diff --git a/Makefile b/Makefile
>>>>> index ab97de0..c7333a2 100644
>>>>> --- a/Makefile
>>>>> +++ b/Makefile
>>>>> @@ -65,6 +65,7 @@ install: uninstall install-modules install-scripts
>>>>> install-modules: modules
>>>>> $(MAKE) -C $(KLIB_BUILD) M=$(PWD) $(KMODDIR_ARG) $(KMODPATH_ARG) \
>>>>> modules_install
>>>>> + @./scripts/update-initramfs
>>>>>
>>>>> install-scripts:
>>>>> @# All the scripts we can use
>>>>> diff --git a/scripts/update-initramfs b/scripts/update-initramfs
>>>>> new file mode 100755
>>>>> index 0000000..412d885
>>>>> --- /dev/null
>>>>> +++ b/scripts/update-initramfs
>>>>> @@ -0,0 +1,33 @@
>>>>> +#!/bin/bash
>>>>> +# Copyright 2009 Luis R. Rodriguez <mcgrof@gmail.com>
>>>>> +#
>>>>> +# Since we provide ssb, the Ethernet module b44 some people may
>>>>> +# rely on it to netboot, so update the initrafms for each
>>>>> +# distribution.
>>>>> +#
>>>>> +# Note that in the future people may want to wireless-boot
>>>>> +# so this will help with that as well.
>>>>> +
>>>>> +LSB_RED_ID=$(/usr/bin/lsb_release -i -s)
>>>>> +
>>>>> +KLIB=/lib/modules/2.6.31-wl/build
>>>>> +ver=$(echo $KLIB | awk -F "/lib/modules/" '{print $2}' | awk -F"/" '{print $1}')
>>>>> +dir=/boot/
>>>>> +
>>>>> +case $LSB_RED_ID in
>>>>> +"Ubuntu")
>>>>> + echo "Updating Ubuntu's initramfs for $ver under $dir ..."
>>>>> + mkinitramfs -o $dir/initrd.img-$ver $ver
>>>>> + echo "Will now run update-grub to ensure grub will find the new initramfs ..."
>>>>> + update-grub
>>>>> + ;;
>>>>> +*)
>>>>> + echo "Warning:"
>>>>> + echo "You may or may not need to update your initframfs, you should if"
>>>>> + echo "any of the modules installed are part of your initramfs. To add"
>>>>> + echo "support for your distribution to do this automatically send a"
>>>>> + echo "patch against $0. If your distribution does not require this"
>>>>> + echo "send a patch against the '/usr/bin/lsb_release -i -s': $LSB_RED_ID"
>>>>> + echo "tag for your distribution to avoid this warning."
>>>>> + ;;
>>>>> +esac
>>>>>
>>>> Luis - I'll do something similar in a post install script for Karmic LBM
>>> Great, thanks for the heads up.
>>>
>>>> since the install-modules target in your makefile isn't used for a
>>>> debian install.
>>> Not sure I followed this part, what do you mean?
>>>
>> It has to do with the way debian packages are installed. In the case of
>> LBM, the .ko files from the binary package are simply copied to their
>> target locations during 'apt-get install'. Therefore, a post
>> installation script needs to be run that updates the initramfs.
>
> Oh I see, the debian/rules file entry for install, got it.
>
> Luis
>
Ok, this turned out to not be a debian package problem. Rather its a
build issue for compat-wireless. Patch to follow.
rtg
--
Tim Gardner tim.gardner@canonical.com
^ permalink raw reply
* [PATCH] compat-wireless: Fix b44 build issues.
From: Tim Gardner @ 2009-09-30 17:00 UTC (permalink / raw)
To: linux-wireless; +Cc: lrodriguez
>From 553180d80860c6090b7d82f809ea7131afca01d6 Mon Sep 17 00:00:00 2001
From: Tim Gardner <tim.gardner@canonical.com>
Date: Wed, 30 Sep 2009 10:02:35 -0600
Subject: [PATCH] compat-wireless: Fix b44 build issues.
Even though CONFIG_B44 is defined, there is no Makefile
created in drivers/net. This failure to build allows the
in-kernel version of b44 to get loaded with a compat-wireless
version of ssb.ko, never a good thing.
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
---
Makefile | 1 +
scripts/admin-update.sh | 1 +
2 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/Makefile b/Makefile
index c7333a2..fa9aadc 100644
--- a/Makefile
+++ b/Makefile
@@ -24,6 +24,7 @@ ifeq ($(ONLY_CORE),)
obj-m += \
drivers/ssb/ \
drivers/misc/eeprom/ \
+ drivers/net/ \
drivers/net/usb/ \
drivers/net/wireless/
endif
diff --git a/scripts/admin-update.sh b/scripts/admin-update.sh
index c65952d..cb42fe7 100755
--- a/scripts/admin-update.sh
+++ b/scripts/admin-update.sh
@@ -149,6 +149,7 @@ done
# b44 is dependent on ssb, so its has to be rebuilt as well.
DIR="drivers/net"
cp $GIT_TREE/$DIR/b44.[ch] $DIR
+echo "obj-m += b44.o" > $DIR/Makefile
# Misc
mkdir -p drivers/misc/eeprom/
--
1.6.2.4
^ permalink raw reply related
* Re: [ath9k-devel] Possible to set MCS Index?
From: Luis R. Rodriguez @ 2009-09-30 16:48 UTC (permalink / raw)
To: Matt Tierney; +Cc: ath9k-devel@lists.ath9k.org, linux-wireless
In-Reply-To: <d355d36c0909300814w302f11a4rb5b23a80aee36c43@mail.gmail.com>
On Wed, Sep 30, 2009 at 08:14:57AM -0700, Matt Tierney wrote:
> This might be a naive question, but I was wondering if it's
> possible to set the MCS index either from a high level interface
> or through a hack in the ath9k code. I'd like to fix the MCS Index
> to 15 but I don't know where that is set or if I can 'force' it
> through modifying the ath9k code in wireless-testing. (It doesn't
> appear as if iw provides that sort of functionality and it wasn't
> clear that I could specify a HT rate in hostapd.conf.)
mac80211 rate control code is MCS rate unaware, but we do at least
let drivers pass the MCS rate for tx status reporting. ath9k
unfortunately reports back the wrong MCS rate though because
of the way ath9k rate control works... it seems correcting this
requires a rewrite of our ath9k rate control code and no one has
prioritized on that as its a non-functional fix.
The first step then is to make mac80211 rate controle code MCS
aware and adding MCS rate control support to minstrel, for example.
For ath9k it'd be nice to fix the rate control code to be able
to report the right MCS index, I really am not sure how involved
that is as I've tried to stay away from the rate control code.
A good step would be to get ath9k rate control to be switchable
to minstrel, for example. This can be done as a module parameter
to start but eventually I think it'd be nice to be able to switch
through iw on any given device. That would require quite a lot of
work though.
Once mac80211 is MCS rate control aware the next step would be to
add a commands to set an MCS rate.
The cheesy and quick way to this for ath9k would be through
ath9k/debufs.c
Luis
^ permalink raw reply
* Re: mac80211: NOHZ: local_softirq_pending 08
From: Johannes Berg @ 2009-09-30 15:21 UTC (permalink / raw)
To: Michael Buesch
Cc: Kalle Valo, Oliver Hartkopp, John W. Linville, linux-wireless,
netdev
In-Reply-To: <200909301710.31082.mb@bu3sch.de>
[-- Attachment #1: Type: text/plain, Size: 773 bytes --]
On Wed, 2009-09-30 at 17:10 +0200, Michael Buesch wrote:
> On Wednesday 30 September 2009 16:54:26 Johannes Berg wrote:
> > On Wed, 2009-09-30 at 17:47 +0300, Kalle Valo wrote:
> >
> > > I agree with Michael. The bug is real and I have verified that
> > > Michael's patch fixes the issue. Better to apply the patch now, it's
> > > trivial to change the implementation if/when the network stack has
> > > support for this.
> >
> > FWIW, I think in mac80211 the in_interrupt() check can never return true
> > since we postpone all RX to the tasklet. But the tasklet seems to be ok
> > -- so should it really be in_interrupt()?
>
> I think a tasklet is also in_interrupt(), because it's a softirq.
Ah, yes, indeed, in_interrupt() vs. in_irq().
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: mac80211: NOHZ: local_softirq_pending 08
From: Michael Buesch @ 2009-09-30 15:10 UTC (permalink / raw)
To: Johannes Berg
Cc: Kalle Valo, Oliver Hartkopp, John W. Linville, linux-wireless,
netdev
In-Reply-To: <1254322466.3959.5.camel@johannes.local>
On Wednesday 30 September 2009 16:54:26 Johannes Berg wrote:
> On Wed, 2009-09-30 at 17:47 +0300, Kalle Valo wrote:
>
> > I agree with Michael. The bug is real and I have verified that
> > Michael's patch fixes the issue. Better to apply the patch now, it's
> > trivial to change the implementation if/when the network stack has
> > support for this.
>
> FWIW, I think in mac80211 the in_interrupt() check can never return true
> since we postpone all RX to the tasklet. But the tasklet seems to be ok
> -- so should it really be in_interrupt()?
I think a tasklet is also in_interrupt(), because it's a softirq.
in_interrupt() returns false in process context. The problem appeared when
the b43 driver started passing RX frames while being in process context (threaded IRQ).
It previously was in tasklet (= softirq) context.
--
Greetings, Michael.
^ permalink raw reply
* Re: B43 Module on Compaq HP615 Laptop
From: Larry Finger @ 2009-09-30 15:01 UTC (permalink / raw)
To: Reiner Schmidt; +Cc: linux-wireless
In-Reply-To: <200909301304.33903.schmidtreiner@gmx.net>
Reiner Schmidt wrote:
> Hello,
> I am trying to install the newest compat-wireless package (from 30.09.2009)
> onto this notebook. It has a Broadcom 4312 compatible WLAN device on it .
> Its id is:14e4:4315.
> I use s debian sidux distribution with an 2.6.29-4 liquorix-kernel.
> Unfortunately I can currently use newer kernels on this notebook because it
> wouldn't boot up. Tried several 2.6.30 and -31 kernels up too 2.6.31-1.
>
> Compiling the package works so far but when loading the module b43 manually or
> via /etc/modules it complains heavily about ssb-related issues.
Some distros include b44 and ssb in their initrd so that the box can
netboot. It is likely that yours is one of them. In this case, this
means that the wrong ssb is already loaded when you try to load b43.
The solution that Gabor gave you is correct; however if you rebuild
mkinitrd after building the compat modules, then it should work.
Larry
^ permalink raw reply
* Re: mac80211: NOHZ: local_softirq_pending 08
From: Johannes Berg @ 2009-09-30 14:54 UTC (permalink / raw)
To: Kalle Valo
Cc: Michael Buesch, Oliver Hartkopp, John W. Linville, linux-wireless,
netdev
In-Reply-To: <87ocosqykb.fsf@purkki.valot.fi>
[-- Attachment #1: Type: text/plain, Size: 489 bytes --]
On Wed, 2009-09-30 at 17:47 +0300, Kalle Valo wrote:
> I agree with Michael. The bug is real and I have verified that
> Michael's patch fixes the issue. Better to apply the patch now, it's
> trivial to change the implementation if/when the network stack has
> support for this.
FWIW, I think in mac80211 the in_interrupt() check can never return true
since we postpone all RX to the tasklet. But the tasklet seems to be ok
-- so should it really be in_interrupt()?
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ 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