headers
David Miller | 1 Nov 01:03
Favicon

Re: pull request: wireless-next-2.6 2008-10-31

From: "John W. Linville" <linville <at> tuxdriver.com>
Date: Fri, 31 Oct 2008 19:37:35 -0400

> Here is a spooky Halloween pull request for wireless bits intended for
> 2.6.29 -- Boo!  Are you scared?

Best pull request ever :-)

> There is a ton of stuff here.  The good news is that it has been cooking
> in wireless-testing for a while and it seems OK. :-)  There are some
> warning in the build like "‘__IEEE80211_CONF_SHORT_SLOT_TIME’ is
> deprecated".  Don't worry, I already have more patches cooking in
> wireless-testing that will take care of those warnings in the next
> round.
> 
> Please let me know if there are problems!

Pulled, thanks a lot!
Permalink | Reply | 0 comments |
headers
Hin-Tak Leung | 1 Nov 01:07
Picon

Re: [RFC/RFT PATCH 0/2] rtl8187: implement conf_tx callback/correctly ack tx pkts


--- On Fri, 31/10/08, Larry Finger <Larry.Finger@...> wrote:

> With these patches installed, my RTL8187B device was stuck
> at 1 Mbs using the
> 'pid' algorithm. Without them, the rate rapidly
> increases to 54 Mbs. I'm roughly
> 2 m from my AP, and get an indicated signal of -22 dBm and
> a link quality of
> 98/100. My kernel is from wireless-testing
> (v2.6.28-rc2-4159-g6c11cd2) with the
> rtl8187 power control and timing patches submitted earlier.
> There are no changes
> to any of the mac80211 components.

This behavior was mentioned in Herton's e-mail, and said to be likely due to recent rewrite of the
rate-control api?

I am still using the early incarnation of the rate-control patch with 2.6.26.7-86.fc9.x86_64 and
2.6.27.4-69.fc10.x86_64 (by rolling back wireless-testing to 2.6.27.x to match), and my rate does go up
and down (between 11M to 36M just now) and generally feels more responsive. Apologies I haven't looked at
the newly posted rate-control patch yet - is there any significant code difference?

Hin-Tak

Hin-Tak

      
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
(Continue reading)

Permalink | Reply | 4 comments |
headers
Hin-Tak Leung | 1 Nov 01:52
Picon

suspend/hibernate/resume code in wireless drivers.

Hi,

I am just experiencing a problem I read about but I thought I didn't have.
I have always been able to suspend/resume without unloading the rtl8187 module ever since it started to
work reasonably well. It seems that there is some automatic mechanism for unloading any usb network
driver which does not have its own suspend/resume code. But it doesn't work in 2.6.27. 

(I filed this as https://bugzilla.redhat.com/show_bug.cgi?id=469461, and there is a reference to an
upstream bug report).

Anyway, I think this is the likely breakage?

--------------
commit 78d9a487ee961c356e1a934d9a92eca38ffb3a70
Author: Alan Stern <stern@...>
Date:   Mon Jun 23 16:00:40 2008 -0400

    USB: Force unbinding of drivers lacking reset_resume or other methods

    This patch (as1024) takes care of a FIXME issue: Drivers that don't
    have the necessary suspend, resume, reset_resume, pre_reset, or
    post_reset methods will be unbound and their interface reprobed when
    one of the unsupported events occurs.

    This is made slightly more difficult by the fact that bind operations
    won't work during a system sleep transition.  So instead the code has
    to defer the operation until the transition ends.

    Signed-off-by: Alan Stern <stern@...>
    Signed-off-by: Greg Kroah-Hartman <gregkh@...>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andrey Yurovsky | 1 Nov 07:23

[PATCH] mac80211_hwsim: enable Mesh Point operation

Initial mesh support: add Mesh Point to supported interfaces mask and allow 
hwsim to send beacons in mesh mode.

Signed-off-by: Andrey Yurovsky <andrey@...>
diff --git a/drivers/net/wireless/mac80211_hwsim.c b/drivers/net/wireless/mac80211_hwsim.c
index 430d8b1..34f643f 100644
--- a/drivers/net/wireless/mac80211_hwsim.c
+++ b/drivers/net/wireless/mac80211_hwsim.c
@@ -370,7 +370,8 @@ static void mac80211_hwsim_beacon_tx(void *arg, u8 *mac,

 	hwsim_check_magic(vif);

-	if (vif->type != NL80211_IFTYPE_AP)
+	if (vif->type != NL80211_IFTYPE_AP && vif->type !=
+			NL80211_IFTYPE_MESH_POINT)
 		return;

 	skb = ieee80211_beacon_get(hw, vif);
@@ -777,7 +778,8 @@ static int __init init_mac80211_hwsim(void)
 		hw->queues = 4;
 		hw->wiphy->interface_modes =
 			BIT(NL80211_IFTYPE_STATION) |
-			BIT(NL80211_IFTYPE_AP);
+			BIT(NL80211_IFTYPE_AP) |
+			BIT(NL80211_IFTYPE_MESH_POINT);
 		hw->ampdu_queues = 1;

 		/* ask mac80211 to reserve space for magic */

--
(Continue reading)

Permalink | Reply | 1 comment |
headers
Johannes Berg | 1 Nov 09:02
Favicon

Re: [PATCH] mac80211_hwsim: enable Mesh Point operation

On Fri, 2008-10-31 at 23:23 -0700, Andrey Yurovsky wrote:
> Initial mesh support: add Mesh Point to supported interfaces mask and allow 
> hwsim to send beacons in mesh mode.

That'll do AP beacons, right? And it won't really help because all
virtual stations see each other?

> Signed-off-by: Andrey Yurovsky <andrey@...>
> diff --git a/drivers/net/wireless/mac80211_hwsim.c b/drivers/net/wireless/mac80211_hwsim.c
> index 430d8b1..34f643f 100644
> --- a/drivers/net/wireless/mac80211_hwsim.c
> +++ b/drivers/net/wireless/mac80211_hwsim.c
> @@ -370,7 +370,8 @@ static void mac80211_hwsim_beacon_tx(void *arg, u8 *mac,
>  
>  	hwsim_check_magic(vif);
>  
> -	if (vif->type != NL80211_IFTYPE_AP)
> +	if (vif->type != NL80211_IFTYPE_AP && vif->type !=
> +			NL80211_IFTYPE_MESH_POINT)
>  		return;

I think I'd prefer if you'd write it as

if (vif->type != NL80211... &&
    vif->type != NL80211....)
	return;

but ultimately, I don't think it matters much. That above just looks a
little quirky, at least to me. :)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ivo van Doorn | 1 Nov 09:58
Picon

Re: crash with rt61pci when resuming with card ejected

On Friday 31 October 2008, Johannes Berg wrote:
> On Fri, 2008-10-31 at 23:01 +0100, Ivo van Doorn wrote:
> 
> > > Now it crashes in config_pairwise_key or something like that, I can send
> > > you the image if you want.
> > 
> > No need. :)
> > I assume mac80211 calls set_key() to disable all hardware keys when
> > ieee80211_unregister_hw() is being called. I'll cook up a patch to catch
> > that as well.
> 
> Yep, that's it, it does it by way of turning off all interfaces,
> removing all stations etc. Of course, if it would implement
> suspend/resume properly then it would have removed the keys already
> before suspend and be putting them back at resume...

Could you try this patch? It doesn't matter if it is on top or as a replacement
of my previous patch.

This patch should also fix suspend/resume handling in general, I suddenly realized
there was quite a big bug in there regarding EEPROM/CSR handling. 

Thanks,

Ivo

---
diff --git a/drivers/net/wireless/rt2x00/rt2x00pci.c b/drivers/net/wireless/rt2x00/rt2x00pci.c
index adf2876..d2c6bc9 100644
--- a/drivers/net/wireless/rt2x00/rt2x00pci.c
(Continue reading)

Permalink | Reply | 6 comments |
headers
Johannes Berg | 1 Nov 10:15
Favicon

Re: crash with rt61pci when resuming with card ejected

On Sat, 2008-11-01 at 09:58 +0100, Ivo van Doorn wrote:

> Could you try this patch? It doesn't matter if it is on top or as a replacement
> of my previous patch.
> 
> This patch should also fix suspend/resume handling in general, I suddenly realized
> there was quite a big bug in there regarding EEPROM/CSR handling. 

Now it just hangs at resume, rather than crashing. At suspend it already
logs some MCU errors though.

johannes
Permalink | Reply | 5 comments |
headers
Ivo van Doorn | 1 Nov 11:29
Picon

Re: crash with rt61pci when resuming with card ejected

On Saturday 01 November 2008, Johannes Berg wrote:
> On Sat, 2008-11-01 at 09:58 +0100, Ivo van Doorn wrote:
> 
> > Could you try this patch? It doesn't matter if it is on top or as a replacement
> > of my previous patch.
> > 
> > This patch should also fix suspend/resume handling in general, I suddenly realized
> > there was quite a big bug in there regarding EEPROM/CSR handling. 
> 
> Now it just hangs at resume, rather than crashing. At suspend it already
> logs some MCU errors though.

Hmm that is strange, those MCU errors could only come from right before the code I
just changed. :S

In any case, could you revert the previous patches and try this. This is the same LED patch
as before, but I have added the check for set_key() to return immediately when this is called
while the module is busy unloading.

Ivo
---
diff --git a/drivers/net/wireless/rt2x00/rt2x00leds.c b/drivers/net/wireless/rt2x00/rt2x00leds.c
index b362a1c..bbac5c1 100644
--- a/drivers/net/wireless/rt2x00/rt2x00leds.c
+++ b/drivers/net/wireless/rt2x00/rt2x00leds.c
@@ -125,6 +125,7 @@ static int rt2x00leds_register_led(struct rt2x00_dev *rt2x00dev,
 	int retval;

 	led->led_dev.name = name;
+	led->led_dev.brightness = LED_OFF;
(Continue reading)

Permalink | Reply | 4 comments |
headers
Kalle Valo | 1 Nov 12:31
Picon
Picon
Favicon

Re: [PATCH] mac80211: Allow AP mode to be enabled

Terve Jouni,

Jouni Malinen <j <at> w1.fi> writes:

> With the addition of basic rate set and TX queue parameter
> configuration and confirmation that power save buffering is
> working again, mac80211 is now in state that allows AP mode to be
> used without major problems. Consequently, it is time to allow this
> mode to be enabled without having to patch the kernel.
>
> AP mode requires hostapd for management frame processing and as such,
> configuring this mode is only allowed through cfg80211 (not with
> iwconfig and WEXT).

I'm very happy to see this, I have been eagerly waiting for the
official AP support in mac80211.

I tried to test this with latest hostapd (commit b6a55236) and
wireless-testing (commit d80fe0040), but unfortunately I wasn't
succesful. Here's the output from hostapd with b43:

$ sudo ./hostapd -dd wlan1.conf
Configuration file: wlan1.conf
ctrl_interface_group=0
Opening raw packet socket for ifindex 0
BSS count 1, BSSID mask ff:ff:ff:ff:ff:ff (0 bits)
SIOCGIWRANGE: WE(compiled)=22 WE(source)=21 enc_capa=0xf
Failed to update rate sets in kernel module
RATE[0] rate=10 flags=0x2
RATE[1] rate=20 flags=0x6
(Continue reading)

Permalink | Reply | 6 comments |
headers
Johannes Berg | 1 Nov 12:34
Favicon

Re: [PATCH] mac80211: Allow AP mode to be enabled


> I tried to test this with latest hostapd (commit b6a55236) and
> wireless-testing (commit d80fe0040), but unfortunately I wasn't
> succesful. Here's the output from hostapd with b43:
> 
> $ sudo ./hostapd -dd wlan1.conf
> Configuration file: wlan1.conf
> ctrl_interface_group=0
> Opening raw packet socket for ifindex 0
> BSS count 1, BSSID mask ff:ff:ff:ff:ff:ff (0 bits)
> SIOCGIWRANGE: WE(compiled)=22 WE(source)=21 enc_capa=0xf
> Failed to update rate sets in kernel module
> RATE[0] rate=10 flags=0x2
> RATE[1] rate=20 flags=0x6
> RATE[2] rate=55 flags=0x6
> RATE[3] rate=110 flags=0x6
> RATE[4] rate=60 flags=0x0
> RATE[5] rate=90 flags=0x0
> RATE[6] rate=120 flags=0x0
> RATE[7] rate=180 flags=0x0
> RATE[8] rate=240 flags=0x0
> RATE[9] rate=360 flags=0x0
> RATE[10] rate=480 flags=0x0
> RATE[11] rate=540 flags=0x0
> Could not set passive scanning: Unknown error 4294967295
> Flushing old station entries
> Deauthenticate all stations
> Mode: IEEE 802.11g  Channel: 5  Frequency: 2432 MHz
> Failed to set CTS protect in kernel driver
> Failed to set Short Slot Time option in kernel driver
(Continue reading)

Permalink | Reply | 0 comments |

Gmane