* Re: [PATCH] p54: Fix regression in 2.6.31-rcX since commit a1091aa - sleeping function called from invalid context
From: Larry Finger @ 2009-07-06 19:43 UTC (permalink / raw)
To: David Miller; +Cc: chunkeey, linux-wireless, linux-kernel
In-Reply-To: <20090706.123441.246532764.davem@davemloft.net>
David Miller wrote:
> From: Christian Lamparter <chunkeey@web.de>
> Date: Mon, 6 Jul 2009 21:19:25 +0200
>
>> On Monday 06 July 2009 21:14:29 David Miller wrote:
>>> If I can't figure it out quickly I'll just simply revert.
>> hmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm
>> [2.6.31] p54: band-aid to restore driver functionality
>> http://patchwork.ozlabs.org/patch/28918/
>>
>> in case someone missed it.
>
> It is so much cleaner to not do multiple things in one patch.
>
> It's also better to completely revert the SKB list handling
> changes first, then add whatever other fixes you want make
> on top.
>
> Partial revert really makes no sense here and is only asking
> for even more potential regressions.
>
> So, like I said, I'm reverting this wholesale unless I can figure
> out a fix quickly.
I'm available for testing.
Larry
^ permalink raw reply
* Re: [PATCH] p54: Fix regression in 2.6.31-rcX since commit a1091aa - sleeping function called from invalid context
From: David Miller @ 2009-07-06 19:34 UTC (permalink / raw)
To: chunkeey; +Cc: Larry.Finger, linux-wireless, linux-kernel
In-Reply-To: <200907062119.25642.chunkeey@web.de>
From: Christian Lamparter <chunkeey@web.de>
Date: Mon, 6 Jul 2009 21:19:25 +0200
> On Monday 06 July 2009 21:14:29 David Miller wrote:
>> If I can't figure it out quickly I'll just simply revert.
> hmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm
> [2.6.31] p54: band-aid to restore driver functionality
> http://patchwork.ozlabs.org/patch/28918/
>
> in case someone missed it.
It is so much cleaner to not do multiple things in one patch.
It's also better to completely revert the SKB list handling
changes first, then add whatever other fixes you want make
on top.
Partial revert really makes no sense here and is only asking
for even more potential regressions.
So, like I said, I'm reverting this wholesale unless I can figure
out a fix quickly.
^ permalink raw reply
* Re: [PATCH] p54: Fix regression in 2.6.31-rcX since commit a1091aa - sleeping function called from invalid context
From: Christian Lamparter @ 2009-07-06 19:19 UTC (permalink / raw)
To: David Miller; +Cc: Larry.Finger, linux-wireless, linux-kernel
In-Reply-To: <20090706.121429.36217952.davem@davemloft.net>
On Monday 06 July 2009 21:14:29 David Miller wrote:
> From: Larry Finger <Larry.Finger@lwfinger.net>
> Date: Mon, 06 Jul 2009 14:07:01 -0500
>
> > Beginning with commit a1091aae19b1d9c85d91c86915a611387f67a26b entitled
> > "p54: Use SKB list handling helpers instead of by-hand code.", the following
> > appears in my logs whenever I try to use my p54usb wireless device:
> >
> > BUG: sleeping function called from invalid context at arch/x86/mm/fault.c:1085
>
> Thanks for tracking this down Larry. I'll have a closer look.
>
> If I can't figure it out quickly I'll just simply revert.
hmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm
[2.6.31] p54: band-aid to restore driver functionality
http://patchwork.ozlabs.org/patch/28918/
in case someone missed it.
Regards,
Chr
^ permalink raw reply
* Re: BUG REPORT: libertas causing kernel lockups
From: Alexander Barinov @ 2009-07-06 19:23 UTC (permalink / raw)
To: Dan Williams; +Cc: Johannes Berg, linux-wireless
In-Reply-To: <1246901395.21990.1.camel@localhost.localdomain>
On Mon, 06 Jul 2009 13:29:55 -0400
Dan Williams <dcbw@redhat.com> wrote:
> On Sun, 2009-07-05 at 12:59 +0400, Alexander Barinov wrote:
> > On Sat, 04 Jul 2009 12:41:42 +0200
> > Johannes Berg <johannes@sipsolutions.net> wrote:
> > > On Sat, 2009-07-04 at 13:03 +0400, Alexander Barinov wrote:
> > > > The initial symptom of the bug was system lockup when executing
> > > > 'ifdown eth0' with 'BUG: scheduling while atomic'. Trying to
> > > > understand the cause of the bug and find a workaround I was
> > > > able to find an easier way to reproduce it. By executing
> > > > 'cat /proc/net/wireless' I get the same bug:
> > > This should have been fixed by
> > > 87057825824973f29cf2f37cff1e549170b2d7e6. For some reason
> > > everybody seems to have assumed that get_wireless_stats can
> > > sleep, which before that commit it could _not_.
> >
> > The patch you have mentioned was not directly applicable to 2.6.30
> > kernel so I pulled wireless-testing git tree and compiled it. This
> > deteriorated the situation further - now after executing
> > 'cat /proc/net/wireless' I get kernel lockup without any further
> > messages.
>
> Can you get anything at all out of the kernel on that? 2.6.29.5 with
> quite recent wireless-testing libertas driver works fine with sd8686
> on my machine (hp 2530p laptop with a Ricoh controller). Can you
> post your backport of that patch too?
The problem is I get no kernel messages at all, just a lockup. Wireless
debug (CONFIG_MAC80211_*_DEBUG) and libertas debug
(CONFIG_LIBERTAS_DEBUG) are on, no "quiet" option on boot. Is there any
other way I can increase level of debug output to be able to give you
some meaningful information with regards to my problem?
BTW, my case is sd8686 on some SDHCI PCI controller, I am not sure how
to find the vendor.
I am not sure which backport you are talking about, as I am using
wireless-testing pulled from git, it should be something around
2.6.31-rc1.
Regards,
Alexander
^ permalink raw reply
* [PATCH] wl12xx: loop off by one.
From: Roel Kluin @ 2009-07-06 19:20 UTC (permalink / raw)
To: kalle.valo, linux-wireless, Andrew Morton
with `while (loop++ < INIT_LOOP)' `loop' reaches -1 after the loop.
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
---
diff --git a/drivers/net/wireless/wl12xx/boot.c b/drivers/net/wireless/wl12xx/boot.c
index 48ac08c..8899905 100644
--- a/drivers/net/wireless/wl12xx/boot.c
+++ b/drivers/net/wireless/wl12xx/boot.c
@@ -247,7 +247,7 @@ int wl12xx_boot_run_firmware(struct wl12xx *wl)
}
}
- if (loop >= INIT_LOOP) {
+ if (loop > INIT_LOOP) {
wl12xx_error("timeout waiting for the hardware to "
"complete initialization");
return -EIO;
^ permalink raw reply related
* Re: [PATCH] p54: Fix regression in 2.6.31-rcX since commit a1091aa - sleeping function called from invalid context
From: David Miller @ 2009-07-06 19:14 UTC (permalink / raw)
To: Larry.Finger; +Cc: linux-wireless, chunkeey, linux-kernel
In-Reply-To: <4a524b55.wIWqgs5uHs2CpdJy%Larry.Finger@lwfinger.net>
From: Larry Finger <Larry.Finger@lwfinger.net>
Date: Mon, 06 Jul 2009 14:07:01 -0500
> Beginning with commit a1091aae19b1d9c85d91c86915a611387f67a26b entitled
> "p54: Use SKB list handling helpers instead of by-hand code.", the following
> appears in my logs whenever I try to use my p54usb wireless device:
>
> BUG: sleeping function called from invalid context at arch/x86/mm/fault.c:1085
Thanks for tracking this down Larry. I'll have a closer look.
If I can't figure it out quickly I'll just simply revert.
^ permalink raw reply
* [PATCH] p54: Fix regression in 2.6.31-rcX since commit a1091aa - sleeping function called from invalid context
From: Larry Finger @ 2009-07-06 19:07 UTC (permalink / raw)
To: davem; +Cc: linux-wireless, chunkeey, linux-kernel
Beginning with commit a1091aae19b1d9c85d91c86915a611387f67a26b entitled
"p54: Use SKB list handling helpers instead of by-hand code.", the following
appears in my logs whenever I try to use my p54usb wireless device:
BUG: sleeping function called from invalid context at arch/x86/mm/fault.c:1085
in_atomic(): 0, irqs_disabled(): 1, pid: 8538, name: modprobe
2 locks held by modprobe/8538:
#0: (&local->queue_stop_reason_lock){-.-...}, at: [<ffffffffa023b99f>]
ieee80211_stop_queues_by_reason+0x28/0x5e [mac80211]
#1: (&mm->mmap_sem){++++++}, at: [<ffffffff80225a4f>] do_page_fault+0xd2/0x1fe
irq event stamp: 25212
hardirqs last enabled at (25211): [<ffffffff80451f28>] _spin_unlock_irqrestore+0x3f/0x47
hardirqs last disabled at (25212): [<ffffffff804520e3>] _spin_lock_irqsave+0x17/0x4b
softirqs last enabled at (24064): [<ffffffff803e9997>] sk_filter+0xba/0xc3
softirqs last disabled at (24062): [<ffffffff803e98f3>] sk_filter+0x16/0xc3
Pid: 8538, comm: modprobe Not tainted 2.6.30-rc6-Linus-00905-g46c3767-dirty #180
Call Trace:
[<ffffffff8025af90>] ? print_irqtrace_events+0xd0/0xd4
[<ffffffff80233384>] __might_sleep+0xf4/0xf6
[<ffffffff80225a99>] do_page_fault+0x11c/0x1fe
[<ffffffff80451f28>] ? _spin_unlock_irqrestore+0x3f/0x47
[<ffffffff804525cf>] page_fault+0x1f/0x30
[<ffffffff80451f28>] ? _spin_unlock_irqrestore+0x3f/0x47
[<ffffffffa023b99f>] ? ieee80211_stop_queues_by_reason+0x28/0x5e [mac80211]
[<ffffffffa023b92b>] ? __ieee80211_stop_queue+0x36/0x82 [mac80211]
[<ffffffff8045210b>] ? _spin_lock_irqsave+0x3f/0x4b
[<ffffffffa023b9b3>] ieee80211_stop_queues_by_reason+0x3c/0x5e [mac80211]
[<ffffffffa023b9e0>] ieee80211_stop_queues+0xb/0xd [mac80211]
[<ffffffffa047c35c>] p54_assign_address+0x164/0x1ec [p54common]
[<ffffffffa047c49a>] p54_alloc_skb+0xb6/0xd3 [p54common]
...
Reverting the hunk that affects p54_assign_address() fixes the problem. When I
tried to determine which change(s) caused the problem, the skb_peek_tail()
seemed to be the problem; however, the system would freeze. I was not able to
recover any log information.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
---
diff --git a/drivers/net/wireless/p54/p54common.c b/drivers/net/wireless/p54/p54common.c
index b618bd1..c5bc55a 100644
--- a/drivers/net/wireless/p54/p54common.c
+++ b/drivers/net/wireless/p54/p54common.c
@@ -1164,21 +1164,23 @@ static int p54_assign_address(struct ieee80211_hw *dev, struct sk_buff *skb,
}
}
- skb_queue_walk(&priv->tx_queue, entry) {
+ entry = priv->tx_queue.next;
+ while (left--) {
u32 hole_size;
info = IEEE80211_SKB_CB(entry);
range = (void *)info->rate_driver_data;
hole_size = range->start_addr - last_addr;
if (!target_skb && hole_size >= len) {
- target_skb = skb_queue_prev(&priv->tx_queue, entry);
+ target_skb = entry->prev;
hole_size -= len;
target_addr = last_addr;
}
largest_hole = max(largest_hole, hole_size);
last_addr = range->end_addr;
+ entry = entry->next;
}
if (!target_skb && priv->rx_end - last_addr >= len) {
- target_skb = skb_peek_tail(&priv->tx_queue);
+ target_skb = priv->tx_queue.prev;
largest_hole = max(largest_hole, priv->rx_end - last_addr - len);
if (!skb_queue_empty(&priv->tx_queue)) {
info = IEEE80211_SKB_CB(target_skb);
^ permalink raw reply related
* [PATCH v2] cfg80211: fix giwrange
From: Johannes Berg @ 2009-07-06 17:40 UTC (permalink / raw)
To: Dave; +Cc: John Linville, linux-wireless
In-Reply-To: <4A523609.5070409@gmail.com>
commit c4c496e49ddbf022e51adbd25cedd071329280db
Author: David Kilroy <kilroyd@googlemail.com>
Date: Thu Jun 18 23:21:14 2009 +0100
cfg80211: Advertise ciphers via WE according to driver capability
Signed-off-by: David Kilroy <kilroyd@googlemail.com>
Acked-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
unfortunately broke iwrange -- it used the variable c
that needs to be 0 for the channel list.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
---
v2: fix bug pointed out by dave
net/wireless/wext-compat.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
--- wireless-testing.orig/net/wireless/wext-compat.c 2009-07-06 12:03:14.000000000 +0200
+++ wireless-testing/net/wireless/wext-compat.c 2009-07-06 19:40:06.000000000 +0200
@@ -154,7 +154,7 @@ int cfg80211_wext_giwrange(struct net_de
struct wireless_dev *wdev = dev->ieee80211_ptr;
struct iw_range *range = (struct iw_range *) extra;
enum ieee80211_band band;
- int c = 0;
+ int i, c = 0;
if (!wdev)
return -EOPNOTSUPP;
@@ -201,8 +201,8 @@ int cfg80211_wext_giwrange(struct net_de
range->avg_qual.noise = range->max_qual.noise / 2;
range->avg_qual.updated = range->max_qual.updated;
- for (c = 0; c < wdev->wiphy->n_cipher_suites; c++) {
- switch (wdev->wiphy->cipher_suites[c]) {
+ for (i = 0; i < wdev->wiphy->n_cipher_suites; i++) {
+ switch (wdev->wiphy->cipher_suites[i]) {
case WLAN_CIPHER_SUITE_TKIP:
range->enc_capa |= (IW_ENC_CAPA_CIPHER_TKIP |
IW_ENC_CAPA_WPA);
@@ -226,7 +226,6 @@ int cfg80211_wext_giwrange(struct net_de
}
for (band = 0; band < IEEE80211_NUM_BANDS; band ++) {
- int i;
struct ieee80211_supported_band *sband;
sband = wdev->wiphy->bands[band];
^ permalink raw reply
* Re: [PATCH] cfg80211: fix giwrange
From: Johannes Berg @ 2009-07-06 17:40 UTC (permalink / raw)
To: Dave; +Cc: John Linville, linux-wireless
In-Reply-To: <4A523609.5070409@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1067 bytes --]
On Mon, 2009-07-06 at 18:36 +0100, Dave wrote:
> Johannes Berg wrote:
> > commit c4c496e49ddbf022e51adbd25cedd071329280db
> > Author: David Kilroy <kilroyd@googlemail.com>
> > Date: Thu Jun 18 23:21:14 2009 +0100
> >
> > cfg80211: Advertise ciphers via WE according to driver capability
> >
> > unfortunately broke iwrange -- it used the variable c
> > that needs to be 0 for the channel list.
>
> Doh! I distinctly recall wonderring whether I should use a separate
> variable. Must've got side-tracked. Sorry :(
No worries.
> Just one thing about the fix though...
>
> > @@ -201,7 +201,7 @@ int cfg80211_wext_giwrange(struct net_de
> > range->avg_qual.noise = range->max_qual.noise / 2;
> > range->avg_qual.updated = range->max_qual.updated;
> >
> > - for (c = 0; c < wdev->wiphy->n_cipher_suites; c++) {
> > + for (i = 0; i < wdev->wiphy->n_cipher_suites; i++) {
> > switch (wdev->wiphy->cipher_suites[c]) {
> ^ needs to be i
Ouch! Thanks, good catch.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH] cfg80211: fix giwrange
From: Dave @ 2009-07-06 17:36 UTC (permalink / raw)
To: Johannes Berg; +Cc: John Linville, linux-wireless
In-Reply-To: <1246828399.4411.7.camel@johannes.local>
Johannes Berg wrote:
> commit c4c496e49ddbf022e51adbd25cedd071329280db
> Author: David Kilroy <kilroyd@googlemail.com>
> Date: Thu Jun 18 23:21:14 2009 +0100
>
> cfg80211: Advertise ciphers via WE according to driver capability
>
> unfortunately broke iwrange -- it used the variable c
> that needs to be 0 for the channel list.
Doh! I distinctly recall wonderring whether I should use a separate
variable. Must've got side-tracked. Sorry :(
Just one thing about the fix though...
> @@ -201,7 +201,7 @@ int cfg80211_wext_giwrange(struct net_de
> range->avg_qual.noise = range->max_qual.noise / 2;
> range->avg_qual.updated = range->max_qual.updated;
>
> - for (c = 0; c < wdev->wiphy->n_cipher_suites; c++) {
> + for (i = 0; i < wdev->wiphy->n_cipher_suites; i++) {
> switch (wdev->wiphy->cipher_suites[c]) {
^ needs to be i
Dave.
^ permalink raw reply
* Re: BUG REPORT: libertas causing kernel lockups
From: Dan Williams @ 2009-07-06 17:29 UTC (permalink / raw)
To: Alexander Barinov; +Cc: Johannes Berg, linux-wireless
In-Reply-To: <20090705125933.5a9f7ce4@dream>
On Sun, 2009-07-05 at 12:59 +0400, Alexander Barinov wrote:
> On Sat, 04 Jul 2009 12:41:42 +0200
> Johannes Berg <johannes@sipsolutions.net> wrote:
> > On Sat, 2009-07-04 at 13:03 +0400, Alexander Barinov wrote:
> > > The initial symptom of the bug was system lockup when executing
> > > 'ifdown eth0' with 'BUG: scheduling while atomic'. Trying to
> > > understand the cause of the bug and find a workaround I was able to
> > > find an easier way to reproduce it. By executing
> > > 'cat /proc/net/wireless' I get the same bug:
> > This should have been fixed by
> > 87057825824973f29cf2f37cff1e549170b2d7e6. For some reason everybody
> > seems to have assumed that get_wireless_stats can sleep, which before
> > that commit it could _not_.
>
> The patch you have mentioned was not directly applicable to 2.6.30
> kernel so I pulled wireless-testing git tree and compiled it. This
> deteriorated the situation further - now after executing
> 'cat /proc/net/wireless' I get kernel lockup without any further
> messages.
Can you get anything at all out of the kernel on that? 2.6.29.5 with
quite recent wireless-testing libertas driver works fine with sd8686 on
my machine (hp 2530p laptop with a Ricoh controller). Can you post your
backport of that patch too?
Dan
^ permalink raw reply
* Re: rt73 in AP mode: PS frames buffered but missing TIM bit?
From: Johannes Berg @ 2009-07-06 17:12 UTC (permalink / raw)
To: Stefan Steuerwald; +Cc: linux-wireless
In-Reply-To: <f76a32050907061006k3bed082fg3428a50370b0889b@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 438 bytes --]
On Mon, 2009-07-06 at 19:06 +0200, Stefan Steuerwald wrote:
> Dear wireless wizards,
>
> I'd like to ask your help, please.
> Summary:
> - I suspect a missing TIM bit when using rt73 in AP mode with my
> powersaving iPod Touch.
> - Despite frames being buffered no TIM bit is getting set (I thought
> it should), station stays asleep.
Sounds like a driver problem, it must not be reacting to set_tim()
properly.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* rt73 in AP mode: PS frames buffered but missing TIM bit?
From: Stefan Steuerwald @ 2009-07-06 17:06 UTC (permalink / raw)
To: linux-wireless
[-- Attachment #1: Type: text/plain, Size: 3107 bytes --]
Dear wireless wizards,
I'd like to ask your help, please.
Summary:
- I suspect a missing TIM bit when using rt73 in AP mode with my
powersaving iPod Touch.
- Despite frames being buffered no TIM bit is getting set (I thought
it should), station stays asleep.
- Symptom is app-level timeout on a TCP connection.
I had asked the list earlier for advice on which USB stick to try for
building an AP (see
http://marc.info/?l=linux-wireless&m=124453569425393&w=2).
I decided to try the rt73. I am aware AP support is broken in the
sense that the chip doesn't seem to know whether certain packets were
successfully transmitted (see patch
http://marc.info/?l=linux-wireless&m=124274853204411&w=2). However, I
am ignorant as to the symptoms of brokenness.
In case you're still reading ;-) ... :
I am using the latest wireless-testing, no further patches.
hostapd v0.6.9
My USB stick is this one (lsusb: ID 07d1:3c03 D-Link System DWL-G122
802.11g Adapter [ralink rt73]).
I am monitoring traffic using a second rt73 usb stick on another computer.
I have a http GET request with a 6 second timeout. The response is
guaranteed to happen after 5 seconds (and I can verify that my server
actually tries to send it in time).
I see the http client timeout after 6 seconds (killing the TCP
connection), with the server's response being sent shortly afterwards.
I suspect the response has actually been sitting there, buffered but
unannounced (see syslog below).
The beacons show no traffic indication, despite the log saying that
frames have been buffered.
Please see the attached capture:
Frame 750: iPod wakes up in preparation for http request
Frame 758: (time 17:40:21.4) http request, response is expected until 17:40:26.4
Frame 764: http request is done, iPod goes to sleep
Frame 822: iPod wakes up (after 6 seconds) because of app-level
timeout (no response received)
Frame 824: iPod kills TCP connection
Frame 826: AP sends http response (too late)
All the beacons in between have no data indicated in TIM (if I read
the TIM structure correctly).
PS debug output actually shows frames being buffered for the iPod at
the expected time (17:40:26) :
Jul 6 17:40:21 xthing kernel: [ 133.355499] wlan0: STA
00:22:41:91:8e:96 aid 1 enters power save mode
Jul 6 17:40:26 xthing kernel: [ 138.143862] STA 00:22:41:91:8e:96
aid 1: PS buffer (entries before 0)
Jul 6 17:40:26 xthing kernel: [ 138.144122] STA 00:22:41:91:8e:96
aid 1: PS buffer (entries before 1)
Jul 6 17:40:26 xthing kernel: [ 138.400307] STA 00:22:41:91:8e:96
aid 1: PS buffer (entries before 2)
Jul 6 17:40:27 xthing kernel: [ 139.075028] wlan0: STA
00:22:41:91:8e:96 aid 1 exits power save mode
Jul 6 17:40:27 xthing kernel: [ 139.075052] wlan0: STA
00:22:41:91:8e:96 aid 1 sending 0 filtered/3 PS frames since STA not
sleeping anymore
Jul 6 17:40:27 xthing kernel: [ 139.294764] wlan0: STA
00:22:41:91:8e:96 aid 1 enters power save mode
Questions:
- Am I thinking into the right direction?
- Is this a symptom of the known broken AP support or may there be a fix?
I'd be happy to supply further debug info.
Thank you,
Stefan.
[-- Attachment #2: ipod-cap-22.cap.bz2 --]
[-- Type: application/x-bzip2, Size: 45786 bytes --]
^ permalink raw reply
* adhoc 11n support
From: Luis R. Rodriguez @ 2009-07-06 16:32 UTC (permalink / raw)
To: xxiao, linux-wireless
Cc: ath9k-devel@lists.ath9k.org, Peter Tarjan, mcgrof@gmail.com,
vitaly
In-Reply-To: <688927.48007.qm@web55301.mail.re4.yahoo.com>
Quoting Jouni's response to me regarding 11n "adhoc" as per IEEE:
<jm> mcgrof: IBSS support in 802.11n is not a specific part of the draft, i.e., one needs to go through
the full draft.. for example, there are IBSS-related specification in 7.3.2.57, 9.13.3.1, 10.3.2.2.2,
11.5.1.1, 11.9.7.2, 11.14.1, 11.14.2; in addition, some AP mode requirements apply, e.g., for radar
detection/DFS, but we are currently handling those by just denying IBSS on channels that could require DFS
So if you get a chance please be sure to read through all that and then send patches for mac80211.
Luis
^ permalink raw reply
* Re: [PATCH] rfkill: prep for rfkill API changes
From: Henrique de Moraes Holschuh @ 2009-07-06 15:58 UTC (permalink / raw)
To: Johannes Berg; +Cc: John Linville, linux-wireless
In-Reply-To: <1246801098.4411.5.camel@johannes.local>
On Sun, 05 Jul 2009, Johannes Berg wrote:
> On Sun, 2009-07-05 at 10:24 -0300, Henrique de Moraes Holschuh wrote:
> > This is good, but not complete. Changes to the API that don't change the
> > size (or those which reduces it) are a problem: they are impossible with a
> > schema that detects API version by the size alone.
>
> Umm, no, we can also add operations as required already.
Yeah, I know. What we can't do is to change the current ones, or drop them.
> _subtlety_ involved in actually doing a size change, nothing more. A
> real event version is _not_ necessary at all. In fact, I would argue
> that basing _anything_ on the "version" rather than the "feature set" is
> useless.
IMO version can tell you the supported feature set, but one could use a
feature set bitmap as well if one wanted. Anyway, if you guys deem the
current way good enough, I am fine with it.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
^ permalink raw reply
* Re: Insist on cfg80211 for new drivers?
From: Nick Kossifidis @ 2009-07-06 15:05 UTC (permalink / raw)
To: Johannes Berg
Cc: Larry Finger, John W. Linville, Dan Williams, Luis R. Rodriguez,
Dave, Karl Relton, dwmw2, linux-wireless
In-Reply-To: <1246892257.20908.14.camel@johannes.local>
2009/7/6 Johannes Berg <johannes@sipsolutions.net>:
> On Mon, 2009-07-06 at 09:45 -0500, Larry Finger wrote:
>> Johannes Berg wrote:
>> >
>> > Should we publish something like this:
>> > http://wireless.kernel.org/wext-statement (don't want it indexed by
>> > google yet so you need to log on to view it), for example on lwn? Just
>> > so more application developers are also aware.
>>
>> I made one small grammatical change. In English, "between" is used
>> when dealing with two entities and "among" if more than two. As there
>> are more than two drivers that share cfg80211 features and code...
>
> Subtle! Thanks Larry, I wasn't aware of this distinction.
>
> johannes
>
Another small change...
As such, drivers written without cfg80211 -> As such, drivers written
without cfg80211 support
Looks fine to me too ;-)
--
GPG ID: 0xD21DB2DB
As you read this post global entropy rises. Have Fun ;-)
Nick
^ permalink raw reply
* Re: Insist on cfg80211 for new drivers?
From: Johannes Berg @ 2009-07-06 14:57 UTC (permalink / raw)
To: Larry Finger
Cc: John W. Linville, Dan Williams, Luis R. Rodriguez, Dave,
Karl Relton, dwmw2, linux-wireless
In-Reply-To: <4A520DF8.2010500@lwfinger.net>
[-- Attachment #1: Type: text/plain, Size: 621 bytes --]
On Mon, 2009-07-06 at 09:45 -0500, Larry Finger wrote:
> Johannes Berg wrote:
> >
> > Should we publish something like this:
> > http://wireless.kernel.org/wext-statement (don't want it indexed by
> > google yet so you need to log on to view it), for example on lwn? Just
> > so more application developers are also aware.
>
> I made one small grammatical change. In English, "between" is used
> when dealing with two entities and "among" if more than two. As there
> are more than two drivers that share cfg80211 features and code...
Subtle! Thanks Larry, I wasn't aware of this distinction.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: Insist on cfg80211 for new drivers?
From: Larry Finger @ 2009-07-06 14:45 UTC (permalink / raw)
To: Johannes Berg
Cc: John W. Linville, Dan Williams, Luis R. Rodriguez, Dave,
Karl Relton, dwmw2, linux-wireless
In-Reply-To: <1246884761.20908.11.camel@johannes.local>
Johannes Berg wrote:
>
> Should we publish something like this:
> http://wireless.kernel.org/wext-statement (don't want it indexed by
> google yet so you need to log on to view it), for example on lwn? Just
> so more application developers are also aware.
I made one small grammatical change. In English, "between" is used
when dealing with two entities and "among" if more than two. As there
are more than two drivers that share cfg80211 features and code...
Otherwise it looks great, and I certainly subscribe to the idea behind it.
Larry
^ permalink raw reply
* Re: Insist on cfg80211 for new drivers?
From: John W. Linville @ 2009-07-06 14:23 UTC (permalink / raw)
To: Johannes Berg
Cc: Dan Williams, Luis R. Rodriguez, Dave, Karl Relton, dwmw2,
linux-wireless
In-Reply-To: <1246884761.20908.11.camel@johannes.local>
On Mon, Jul 06, 2009 at 02:52:40PM +0200, Johannes Berg wrote:
> On Wed, 2009-07-01 at 15:36 -0400, John W. Linville wrote:
> > On Wed, Jul 01, 2009 at 02:35:00PM -0400, Dan Williams wrote:
> >
> > > That's really all I
> > > care about, I don't want another WEXT-based driver accepted; I want all
> > > the new ones using cfg80211.
> >
> > Now there is a discussion we should have had in Berlin...is it time
> > to insist on cfg80211-based configuration for all new drivers?
>
> Should we publish something like this:
> http://wireless.kernel.org/wext-statement (don't want it indexed by
> google yet so you need to log on to view it), for example on lwn? Just
> so more application developers are also aware.
Yes, that seems fine to me.
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
¡Viva Honduras Libre!
^ permalink raw reply
* Re: [WIP] p54: deal with allocation failures in rx path
From: Max Filippov @ 2009-07-06 14:18 UTC (permalink / raw)
To: Christian Lamparter; +Cc: linux-wireless, Larry Finger
In-Reply-To: <200907061600.14196.chunkeey@web.de>
>> Anyway skb that carry data frame will be handed to the mac
>> and replaced with new one. That is, this patch does not eliminate
>> possibility of control frame loss due to insufficient memory.
> control frames loss?
> can you please point me exactly where?
> Since this is a bug that needs to be fixed.
>
> as control frames' skb should be (and hopefully are) always reused.
> (see @ txrx.c line 590 - p54_rx_control -> return skb; )
>
>> Maybe we'd better have separate reusable skb for control frames which
>> is never handed out from the driver?
> well as a matter of fact this is already true for p54pci & p54usb
> (based on the assumption we are really recycling all control frames...
> and not somehow forgot a case and got a leak there?!)
Sorry, now I see, it's ok. Missed these lines in p54_rx_data:
+ tmp = dev_alloc_skb(priv->rx_mtu);
+ if (!tmp)
+ return skb;
--
Max
^ permalink raw reply
* Re: [WIP] p54: deal with allocation failures in rx path
From: Christian Lamparter @ 2009-07-06 14:00 UTC (permalink / raw)
To: Max Filippov; +Cc: linux-wireless, Larry Finger
In-Reply-To: <73aaf0dd0907060611w5a288828h4c4728f52fe4e16c@mail.gmail.com>
On Monday 06 July 2009 15:11:11 Max Filippov wrote:
> > This patch tries to address a long standing issue:
> > how to survive serve memory starvation situations,
> > without losing the device due to missing transfer-buffers.
>
> Christian, how does placement of skb allocation point make a
> difference?
not all drivers are equal... usb is the critical one.
just take a look at the these lines in p54u_rx_cb
skb = dev_alloc_skb(priv->common.rx_mtu + 32);
if (unlikely(!skb)) {
/* TODO check rx queue length and refill *somewhere* */
return;
}
so every time we failed to alloc the replacement skb, we have to
abandon one rx urb, until nothing is left and the user has
to replug/reload. pci is a bit more forgiving, but it can bite as well.
(Note: this scenario is _unlikely_ to happen ever since Larry scaled
down the rx_mtu from 3240 to about 2400 or so - which makes
dev_alloc_skb a 0-order allocation on the most common architectures)
> Anyway skb that carry data frame will be handed to the mac
> and replaced with new one. That is, this patch does not eliminate
> possibility of control frame loss due to insufficient memory.
control frames loss?
can you please point me exactly where?
Since this is a bug that needs to be fixed.
as control frames' skb should be (and hopefully are) always reused.
(see @ txrx.c line 590 - p54_rx_control -> return skb; )
> Maybe we'd better have separate reusable skb for control frames which
> is never handed out from the driver?
well as a matter of fact this is already true for p54pci & p54usb
(based on the assumption we are really recycling all control frames...
and not somehow forgot a case and got a leak there?!)
Regards,
Chr
^ permalink raw reply
* [PATCH] p54: fix queue stall due to underrun
From: Christian Lamparter @ 2009-07-06 13:18 UTC (permalink / raw)
To: linux-wireless; +Cc: John W. Linville, Larry Finger
Larry Finger discovered a weird behavior under load.
In essence, the queue's length count under runs,
which in turn renders the associated ac queue unusable.
Reported-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Christian Lamparter <chunkeey@web.de>
---
diff --git a/drivers/net/wireless/p54/txrx.c b/drivers/net/wireless/p54/txrx.c
index ea074a6..01eadb1 100644
--- a/drivers/net/wireless/p54/txrx.c
+++ b/drivers/net/wireless/p54/txrx.c
@@ -199,7 +199,7 @@ static int p54_tx_qos_accounting_alloc(struct p54_common *priv,
queue = &priv->tx_stats[p54_queue];
spin_lock_irqsave(&priv->tx_stats_lock, flags);
- if (unlikely(queue->len > queue->limit && IS_QOS_QUEUE(p54_queue))) {
+ if (unlikely(queue->len >= queue->limit && IS_QOS_QUEUE(p54_queue))) {
spin_unlock_irqrestore(&priv->tx_stats_lock, flags);
return -ENOSPC;
}
@@ -222,8 +222,11 @@ static void p54_tx_qos_accounting_free(struct p54_common *priv,
if (skb && IS_DATA_FRAME(skb)) {
struct p54_hdr *hdr = (void *) skb->data;
struct p54_tx_data *data = (void *) hdr->data;
+ unsigned long flags;
+ spin_lock_irqsave(&priv->tx_stats_lock, flags);
priv->tx_stats[data->hw_queue].len--;
+ spin_unlock_irqrestore(&priv->tx_stats_lock, flags);
}
p54_wake_queues(priv);
}
@@ -504,7 +507,6 @@ static void p54_rx_eeprom_readback(struct p54_common *priv,
priv->eeprom = NULL;
tmp = p54_find_and_unlink_skb(priv, hdr->req_id);
- p54_tx_qos_accounting_free(priv, tmp);
dev_kfree_skb_any(tmp);
complete(&priv->eeprom_comp);
}
@@ -531,7 +533,6 @@ static void p54_rx_stats(struct p54_common *priv, struct sk_buff *skb)
priv->noise = p54_rssi_to_dbm(priv, le32_to_cpu(stats->noise));
tmp = p54_find_and_unlink_skb(priv, hdr->req_id);
- p54_tx_qos_accounting_free(priv, tmp);
dev_kfree_skb_any(tmp);
}
^ permalink raw reply related
* [PATCH] p54usb: fix stalls caused by urb allocation failures
From: Christian Lamparter @ 2009-07-06 13:17 UTC (permalink / raw)
To: linux-wireless; +Cc: John W. Linville, Larry Finger
This patch squashes a few old bugs, which have been around since
the initial version of p54usb in one form or another.
we never freed a orphaned frame, when were denied the resources,
which are necessary to pass the data into the usb subsystem.
As a result we could end up with a full queue that wasn't emptied,
until the device was brought down.
Signed-off-by: Christian Lamparter <chunkeey@web.de>
---
diff --git a/drivers/net/wireless/p54/p54usb.c b/drivers/net/wireless/p54/p54usb.c
index 461d88f..e44460f 100644
--- a/drivers/net/wireless/p54/p54usb.c
+++ b/drivers/net/wireless/p54/p54usb.c
@@ -246,8 +246,10 @@ static void p54u_tx_lm87(struct ieee80211_hw *dev, struct sk_buff *skb)
struct lm87_tx_hdr *hdr = (void *)skb->data - sizeof(*hdr);
data_urb = usb_alloc_urb(0, GFP_ATOMIC);
- if (!data_urb)
+ if (!data_urb) {
+ p54_free_skb(dev, skb);
return;
+ }
hdr->chksum = p54u_lm87_chksum((__le32 *)skb->data, skb->len);
hdr->device_addr = ((struct p54_hdr *)skb->data)->req_id;
@@ -269,27 +271,22 @@ static void p54u_tx_lm87(struct ieee80211_hw *dev, struct sk_buff *skb)
static void p54u_tx_net2280(struct ieee80211_hw *dev, struct sk_buff *skb)
{
struct p54u_priv *priv = dev->priv;
- struct urb *int_urb, *data_urb;
+ struct urb *int_urb = NULL, *data_urb = NULL;
struct net2280_tx_hdr *hdr = (void *)skb->data - sizeof(*hdr);
- struct net2280_reg_write *reg;
- int err = 0;
+ struct net2280_reg_write *reg = NULL;
+ int err = -ENOMEM;
reg = kmalloc(sizeof(*reg), GFP_ATOMIC);
if (!reg)
- return;
+ goto out;
int_urb = usb_alloc_urb(0, GFP_ATOMIC);
- if (!int_urb) {
- kfree(reg);
- return;
- }
+ if (!int_urb)
+ goto out;
data_urb = usb_alloc_urb(0, GFP_ATOMIC);
- if (!data_urb) {
- kfree(reg);
- usb_free_urb(int_urb);
- return;
- }
+ if (!data_urb)
+ goto out;
reg->port = cpu_to_le16(NET2280_DEV_U32);
reg->addr = cpu_to_le32(P54U_DEV_BASE);
@@ -304,11 +301,12 @@ static void p54u_tx_net2280(struct ieee80211_hw *dev, struct sk_buff *skb)
p54u_tx_dummy_cb, dev);
/*
- * This flag triggers a code path in the USB subsystem that will
- * free what's inside the transfer_buffer after the callback routine
- * has completed.
+ * URB_FREE_BUFFER triggers a code path in the USB subsystem that will
+ * free what is inside the transfer_buffer after the last reference to
+ * the int_urb is dropped.
*/
int_urb->transfer_flags |= URB_FREE_BUFFER | URB_ZERO_PACKET;
+ reg = NULL;
usb_fill_bulk_urb(data_urb, priv->udev,
usb_sndbulkpipe(priv->udev, P54U_PIPE_DATA),
@@ -329,12 +327,12 @@ static void p54u_tx_net2280(struct ieee80211_hw *dev, struct sk_buff *skb)
usb_unanchor_urb(data_urb);
goto out;
}
- out:
+out:
usb_free_urb(int_urb);
usb_free_urb(data_urb);
if (err) {
- skb_pull(skb, sizeof(*hdr));
+ kfree(reg);
p54_free_skb(dev, skb);
}
}
^ permalink raw reply related
* Re: [WIP] p54: deal with allocation failures in rx path
From: Christian Lamparter @ 2009-07-06 13:16 UTC (permalink / raw)
To: Larry Finger; +Cc: linux-wireless
In-Reply-To: <4A51553B.9050204@lwfinger.net>
On Monday 06 July 2009 03:36:59 Larry Finger wrote:
> Christian Lamparter wrote:
>
> > hmm, can you please give this a go? (I hope this patch still applies...)
> > I'm curious if you can dump the tx_queue when p54_alloc_skb fail?
>
> The patch applied with the aid of wiggle.
yeah, I don't want to delay these changes... so they are based on top of
the last _official_ patches, rather than the experimental ones.
> Since adding it, I've had 7 of the disassociation failures, but none of the
> queue len problems.
ohh, forgot to add that...
- do you think you can add another p54_dump_tx_queue
when it "disassociates". I'm curious if the queue was empty or is full
(with what?!)
> I have modified every place that p54_alloc_skb() fails with a printk
> that tells why it failed and then calls p54_dump_tx_queue(), but I
> have not gotten to test it yet. I found an oops when 2.6.31-rc2 is
> booted that I'm bisecting right now.
yeah, in the mean time I'll get these fixes to linville.
Regards,
Chr
^ permalink raw reply
* Re: [WIP] p54: deal with allocation failures in rx path
From: Max Filippov @ 2009-07-06 13:11 UTC (permalink / raw)
To: Christian Lamparter; +Cc: linux-wireless, Larry Finger
In-Reply-To: <200907040053.05654.chunkeey@web.de>
> This patch tries to address a long standing issue:
> how to survive serve memory starvation situations,
> without losing the device due to missing transfer-buffers.
Christian, how does placement of skb allocation point make a
difference? Anyway skb that carry data frame will be handed to the mac
and replaced with new one. That is, this patch does not eliminate
possibility of control frame loss due to insufficient memory.
Maybe we'd better have separate reusable skb for control frames which
is never handed out from the driver?
--
Max
^ 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