* Re: [PATCH] cfg80211: Fix user-space crda query stall
From: Luis R. Rodriguez @ 2010-05-25 19:19 UTC (permalink / raw)
To: Juuso Oikarinen; +Cc: linville, linux-wireless
In-Reply-To: <AANLkTinMo6L_LuCgcu9izxUVsFbi7kamHD2F_xThwJ2R@mail.gmail.com>
On Tue, May 25, 2010 at 12:02 PM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
> On Mon, May 24, 2010 at 11:50 PM, Juuso Oikarinen
> <juuso.oikarinen@nokia.com> wrote:
>> The userspace crda utility can fail to respond to kernel requests in (at least)
>> two scenarios: it is not runnable for any reason, or it is invoked with a
>> country code not in its database.
>>
>> When the userspace crda utility fails to respond to kernel requests (i.e. it
>> does not use NL80211_CMD_SET_REG to provide the kernel regulatory information
>> for the requested country) the kernel crda subsystem will stall. It will
>> refuse to process any further regulatory hints. This is easiest demonstrated
>> by using for instance the "iw" tool:
>>
>> iw reg set EU
>> iw reg set US
>>
>> "EU" is not a country code present in the database, so user space crda will
>> not respond. Attempting to define US after that will be silently ignored
>> (internally, an -EAGAIN is the result, as the "EU" request is still
>> "being processed".)
>>
>> To fix this issue, this patch implements timeout protection for the userspace
>> crda invocation. If there is no response for five seconds, the crda code will
>> force itself to the world regulatory domain for maximum safety.
>>
>> Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
>
> This is a great idea, I really like it and appreciate you taking the
> time to work on this, however to do this it requires a little more
> work and will point out the notes below. So NACK for now but with some
> fixes I think this would be great.
>
>> ---
>> net/wireless/reg.c | 44 ++++++++++++++++++++++++++++++++++++++++++++
>> 1 files changed, 44 insertions(+), 0 deletions(-)
>>
>> diff --git a/net/wireless/reg.c b/net/wireless/reg.c
>> index 8f0d97d..6c945f0 100644
>> --- a/net/wireless/reg.c
>> +++ b/net/wireless/reg.c
>> @@ -385,6 +385,40 @@ static inline void reg_regdb_query(const char *alpha2) {}
>> #endif /* CONFIG_CFG80211_INTERNAL_REGDB */
>>
>> /*
>> + * This gets invoked if crda in userspace is not responding (it's not getting
>> + * executed or the country code in the hint is not in the database.
>> + */
>> +
>> +static void call_crda_timeout_work(struct work_struct *work)
>> +{
>> + if (!last_request)
>> + return;
>> +
>> + printk(KERN_INFO "cfg80211: crda request timed out, reverting to 00\n");
>> +
>> + mutex_lock(&cfg80211_mutex);
>> +
>> + /*
>> + * As we are not getting data for the current country, force us back
>> + * to the world regdomain.
>> + */
>> + last_request->alpha2[0] = '0';
>> + last_request->alpha2[1] = '0';
>> + set_regdom(cfg80211_world_regdom);
>> + mutex_unlock(&cfg80211_mutex);
>> +}
>
>
> Actually you may want to consider using restore_regulatory_settings()
> instead as that would:
>
> * set the world regdom
> * then set the first user specified regulatory domain if they had one picked
>
> This would mean we would go into a loop here though if the user had
> specified 'EU' though so this routine first needs to be fixed to
> annotate a regulatory domain as invalid. Note that a regulatory cannot
> be invalid if CRDA just times out -- CRDA could time out if it was not
> present. So this is a bit tricky and not sure how to resolve it. John
> recently added support for building the regulatory database as part of
> the kernel but at the same time support letting CRDA still update the
> same info if it is present. Then for those setup it could be possible
> 'DE' exists on the core kernel regulatory database but if CRDA is not
> installed then CRDA will time out.
>
> Maybe what we can do is if both the internal kernel regdb *and* CRDA
> times out then mark the user specified request as invalid and restore
> to using the world regdom. This would allow the user to later install
> a CRDA with some newer regdb in userspace, for example. This allows
> for upgrading the db itself from userspace without making kernel
> changes. It allows for countries to be created.
>
>> +
>> +static DECLARE_WORK(crda_uevent_timeout_work, call_crda_timeout_work);
>> +
>> +#define CRDA_UEVENT_TIMEOUT 5000
>> +static void crda_uevent_timeout(unsigned long data)
>> +{
>> + schedule_work(&crda_uevent_timeout_work);
>> +}
>> +
>> +static DEFINE_TIMER(crda_uevent_timer, crda_uevent_timeout, 0, 0);
>
> I would prefer we use a completion here, seems a little cleaner. Check
> out ath9k/wmi.c for cmd_wait and its use with init_completion() and
> complete().
Actually it makes no sense to linger a thread here waiting for a
completion, your approach is better, never mind this comment.
Luis
^ permalink raw reply
* Re: pull request: wireless-2.6 2010-05-25
From: Thomas Backlund @ 2010-05-25 19:35 UTC (permalink / raw)
To: sedat.dilek
Cc: Sedat Dilek, John W. Linville, davem, linux-wireless, netdev,
linux-kernel
In-Reply-To: <AANLkTilMYGSprjMnmRHlZPMvk1KLd1Yeqd_l26yyVRT6@mail.gmail.com>
25.05.2010 22:23, Sedat Dilek skrev:
> "[1/2] iwlwifi: fix internal scan race" [1] is in this pull request.
> Isn't "[2/2] iwlagn: work around rate scaling reset delay" [2] missing?
> IIRC, both fixes were sent as a double-patch.
>
It's already upstream:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=3bce6066263efb5733ee2141ac8b56684fb3b0a7
> - Sedat -
>
> [1] https://patchwork.kernel.org/patch/99439/
> [2] https://patchwork.kernel.org/patch/99438/
>
--
Thomas
^ permalink raw reply
* What does it mean: "Failed to create interface mon.wlan0."?
From: Jaroslav Fojtik @ 2010-05-25 19:57 UTC (permalink / raw)
To: linux-wireless
Dear Luis R. Rodriguez & ATH5k users,
> > it looks that compat-wireless-2010-05-21 scans when associated.
> > But compat-wireless-2010-05-21 seems to be so defective that I cannot
> > use it.
>
> http://wireless.kernel.org/en/users/Documentation/Reporting_bugs
>
> Being a little more descriptive would help.
I wished to create a separate thread.
ATH5k stopped to work with this message in dmesg:
Failed to create interface mon.wlan0.
nl80211 driver initialization failed.
But ifconfig lists mon.wlan0 without any problem.
And compat-wireless-2.6.34-rc4 does not suffer with this issue.
regards
Jara
^ permalink raw reply
* Re: pull request: wireless-2.6 2010-05-25
From: David Miller @ 2010-05-25 20:15 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20100525170401.GE31753@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Tue, 25 May 2010 13:04:02 -0400
> git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git master
Pulled, thanks John.
^ permalink raw reply
* Re: pull request: wireless-2.6 2010-05-25
From: Gertjan van Wingerde @ 2010-05-25 20:29 UTC (permalink / raw)
To: John W. Linville; +Cc: davem, linux-wireless, netdev, linux-kernel
In-Reply-To: <20100525170401.GE31753@tuxdriver.com>
John,
On 05/25/10 19:04, John W. Linville wrote:
> Dave,
>
> Here are a number of fixes intended for 2.6.35. Included are some
> warning fixes from Randy, some smatch-identified fixes from Dan, some
> fixes for using ath9k and IBSS mode, the removal of a PCI ID that was
> optimistically added to ath9k, and a smattering of other driver fixes.
> This also includes a revert of "ath9k: Group Key fix for VAPs" which
> was reported to cause regressions due to a mac80211 change inside it
> that snuck past us... :-(
>
> Anyway, these are mostly small(ish) and obvious. Please let me know
> if there are problems!
>
> Thanks,
>
> John
>
> ---
>
> The following changes since commit acfbe96a3035639619a6533e04d88ed4ef9ccb61:
<snip>
>
> Gertjan van Wingerde (2):
> rt2x00: Fix rt2800usb TX descriptor writing.
The patch causing the breakage this patch fixes wasn't actually upstream yet. So,
applying this patch only is now introducing a bug in 2.6.35. I guess it is better
to revert this patch for 2.6.35.
Sorry for not being clearer about it when sending the patch to you.
---
Gertjan.
^ permalink raw reply
* RE: wireless-regdb: A band is missing for IL
From: David Quan @ 2010-05-25 20:39 UTC (permalink / raw)
To: Luis R. Rodriguez, Emmanuel Grumbach, Michael Green
Cc: linville@tuxdriver.com, linux-wireless@vger.kernel.org
In-Reply-To: <AANLkTikUhVoBKe95N_kkpXvSEsr845viGp5IhHZTVN2n@mail.gmail.com>
Israel follows ETSI3_WORLD,
this means
Unii1 + Unii2 is supported. Unii2 requires DFS for APs.
2ghz Ch1-13 supported.
-----Original Message-----
From: Luis R. Rodriguez [mailto:mcgrof@gmail.com]
Sent: Tuesday, May 25, 2010 12:08 PM
To: Emmanuel Grumbach; Michael Green; David Quan
Cc: linville@tuxdriver.com; linux-wireless@vger.kernel.org
Subject: Re: wireless-regdb: A band is missing for IL
Michael, please review and let us know what you think.
Luis
On Tue, May 25, 2010 at 12:03 AM, Emmanuel Grumbach <egrumbach@gmail.com> wrote:
> According to http://en.wikipedia.org/wiki/List_of_WLAN_channels#5.C2.A0GHz_.28802.11a.2Fh.2Fj.2Fn.29
>
> Channels 34 - 64 are allowed in 20 Mhz in Israel. This is not what is
> written in db.txt:
>
> country IL:
> (2402 - 2482 @ 40), (N/A, 20)
>
> This wikipedia page relies on an official page from the Israel
> Ministry of the Communication.
>
> Emmanuel Grumbach
> egrumbach@gmail.com
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: pull request: wireless-2.6 2010-05-25
From: John W. Linville @ 2010-05-25 20:42 UTC (permalink / raw)
To: Gertjan van Wingerde; +Cc: davem, linux-wireless, netdev, linux-kernel
In-Reply-To: <4BFC331A.9030606@gmail.com>
On Tue, May 25, 2010 at 10:29:14PM +0200, Gertjan van Wingerde wrote:
> On 05/25/10 19:04, John W. Linville wrote:
> > Gertjan van Wingerde (2):
> > rt2x00: Fix rt2800usb TX descriptor writing.
>
> The patch causing the breakage this patch fixes wasn't actually upstream yet. So,
> applying this patch only is now introducing a bug in 2.6.35. I guess it is better
> to revert this patch for 2.6.35.
Hmmm...OK. Which patch introduces the bug this was intended to fix?
John
--
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: pull request: wireless-2.6 2010-05-25
From: reinette chatre @ 2010-05-25 21:08 UTC (permalink / raw)
To: Thomas Backlund
Cc: sedat.dilek@gmail.com, Sedat Dilek, John W. Linville,
davem@davemloft.net, linux-wireless@vger.kernel.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <4BFC2677.7050509@mandriva.org>
On Tue, 2010-05-25 at 12:35 -0700, Thomas Backlund wrote:
> 25.05.2010 22:23, Sedat Dilek skrev:
> > "[1/2] iwlwifi: fix internal scan race" [1] is in this pull request.
> > Isn't "[2/2] iwlagn: work around rate scaling reset delay" [2] missing?
> > IIRC, both fixes were sent as a double-patch.
> >
>
> It's already upstream:
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=3bce6066263efb5733ee2141ac8b56684fb3b0a7
Yes, thank you, [2] was sent upstream (targeting 2.6.35) a while ago but
was later determined to be needed in 2.6.34 also. That is why it was
sent together with another fix targeting 2.6.34 ... both were sent
before 2.6.34 was released in the hopes that they will make it into
2.6.34. Unfortunately these patches did not make it into 2.6.34 and with
[2] already in 2.6.35 only [1] needed to be added there.
We will now have to send these patches to stable to get them into
2.6.34.
Reinette
^ permalink raw reply
* Re: pull request: wireless-2.6 2010-05-25
From: Gertjan van Wingerde @ 2010-05-25 21:18 UTC (permalink / raw)
To: John W. Linville; +Cc: davem, linux-wireless, netdev, linux-kernel
In-Reply-To: <20100525204235.GA27002@tuxdriver.com>
On 05/25/10 22:42, John W. Linville wrote:
> On Tue, May 25, 2010 at 10:29:14PM +0200, Gertjan van Wingerde wrote:
>> On 05/25/10 19:04, John W. Linville wrote:
>
>>> Gertjan van Wingerde (2):
>>> rt2x00: Fix rt2800usb TX descriptor writing.
>>
>> The patch causing the breakage this patch fixes wasn't actually upstream yet. So,
>> applying this patch only is now introducing a bug in 2.6.35. I guess it is better
>> to revert this patch for 2.6.35.
>
> Hmmm...OK. Which patch introduces the bug this was intended to fix?
>
It's this one:
http://marc.info/?l=linux-wireless&m=127374343617025&w=2
But that patch depends on a number of other unapplied patches :-(, namely:
http://marc.info/?l=linux-wireless&m=127374940425538&w=2
http://marc.info/?l=linux-wireless&m=127374344617058&w=2
and
http://marc.info/?l=linux-wireless&m=127374343217011&w=2
---
Gertjan.
^ permalink raw reply
* [PATCH 2.6.35] ar9170usb: fix read from freed driver context
From: Christian Lamparter @ 2010-05-25 21:58 UTC (permalink / raw)
To: linux-wireless; +Cc: linville
Commit "ar9170: wait for asynchronous firmware loading"
introduced a bug, which is triggered by fatal errors
while the driver is initializing the device.
BUG: unable to handle kernel paging request at 6b6b6bf7
IP: [<c117b567>] kobject_put+0x7/0x70
*pde = 00000000
Oops: 0000 [#1] PREEMPT
last sysfs file: /sys/devices/platform/hdaps/position
Modules linked in: ar9170usb [...]
Pid: 6246, comm: firmware/ar9170 Not tainted 2.6.34-wl #54
EIP: 0060:[<c117b567>] EFLAGS: 00010206 CPU: 0
EIP is at kobject_put+0x7/0x70
EAX: 6b6b6bd7 EBX: f4d3d0e0 ECX: f5ba9124 EDX: f6af2a7c
ESI: 00000000 EDI: f4d3d0e0 EBP: 00000000 ESP: f5e98f9c
DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068
Process firmware/ar9170 (pid: 6246)
Stack:
c12532ed 00000246 f5bfaa70 f8487353 f4d3d0e0
Call Trace:
[<c12532ed>] ? device_release_driver+0x1d/0x30
[<f8487353>] ? ar9170_usb_firmware_failed+0x43/0x70 [ar9170usb]
[<c125983c>] ? request_firmware_work_func+0x2c/0x70
[<c1259810>] ? request_firmware_work_func+0x0/0x70
[<c10413f4>] ? kthread+0x74/0x80
[<c1041380>] ? kthread+0x0/0x80
[<c1003136>] ? kernel_thread_helper+0x6/0x10
Code: 40 d3 f2 ff 85 c0 89 c3 74 0a ba 44 86 4c c1 e8 [...]
EIP: [<c117b567>] kobject_put+0x7/0x70 SS:ESP 0068:f5e98f9c
CR2: 000000006b6b6bf7
---[ end trace e81abb992434b410 ]---
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
---
diff --git a/drivers/net/wireless/ath/ar9170/usb.c b/drivers/net/wireless/ath/ar9170/usb.c
index 82ab532..a93dc18 100644
--- a/drivers/net/wireless/ath/ar9170/usb.c
+++ b/drivers/net/wireless/ath/ar9170/usb.c
@@ -739,17 +739,27 @@ err_out:
static void ar9170_usb_firmware_failed(struct ar9170_usb *aru)
{
struct device *parent = aru->udev->dev.parent;
+ struct usb_device *udev;
+
+ /*
+ * Store a copy of the usb_device pointer locally.
+ * This is because device_release_driver initiates
+ * ar9170_usb_disconnect, which in turn frees our
+ * driver context (aru).
+ */
+ udev = aru->udev;
complete(&aru->firmware_loading_complete);
/* unbind anything failed */
if (parent)
device_lock(parent);
- device_release_driver(&aru->udev->dev);
+
+ device_release_driver(&udev->dev);
if (parent)
device_unlock(parent);
- usb_put_dev(aru->udev);
+ usb_put_dev(udev);
}
static void ar9170_usb_firmware_finish(const struct firmware *fw, void *context)
^ permalink raw reply related
* Re: iwl3945 dies (oops) in post 2.6.34 kernels
From: Sedat Dilek @ 2010-05-25 22:34 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Abhijeet Kolekar, Johannes Berg, linux-wireless@vger.kernel.org,
LKML, 582906
In-Reply-To: <201005251027.32778.dmitry.torokhov@gmail.com>
[ CC <582906@bugs.debian.org> ]
Unfortunately, I didn't notice I compiled compat-wireless (2010-05-21)
on user request against linux-image-2.6.32-5-686 and was using it
since then.
AFAICS Debian Bug #582906 can be closed.
$ dpkg -l | grep linux-image
ii linux-image-2.6.32-5-686
2.6.32-13 Linux 2.6.32 for modern PCs
$ sudo lsmod | grep iwl | sort
cfg80211 100582 3 iwl3945,iwlcore,mac80211
compat_firmware_class 4683 1 iwl3945
iwl3945 45461 0
iwlcore 58688 1 iwl3945
mac80211 140617 2 iwl3945,iwlcore
On first sight it seems both patches fixed the issue here:
sd@seduxbox:~/src/compat-wireless/compat-wireless-2010-05-21$ cat
.pc/applied-patches
iwlwifi-fix-internal-scan-race.patch
temp.patch
By the way, iwlwifi-fix-internal-scan-race.patch alone did it not.
Any ideas for a testcase to be sure the problem is really fixed, now?
- Sedat -
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=582906
P.S.:
$ dmesg | egrep -i 'iwl|80211|wlan'
[ 9.854377] cfg80211: Calling CRDA to update world regulatory domain
[ 11.196129] iwl3945: Intel(R) PRO/Wireless 3945ABG/BG Network
Connection driver for Linux, in-tree:s
[ 11.196132] iwl3945: Copyright(c) 2003-2010 Intel Corporation
[ 11.196215] iwl3945 0000:10:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
[ 11.196229] iwl3945 0000:10:00.0: setting latency timer to 64
[ 11.250133] iwl3945 0000:10:00.0: Tunable channels: 13 802.11bg, 23
802.11a channels
[ 11.250136] iwl3945 0000:10:00.0: Detected Intel Wireless WiFi Link 3945ABG
[ 11.250277] iwl3945 0000:10:00.0: irq 29 for MSI/MSI-X
[ 11.437198] cfg80211: World regulatory domain updated:
[ 11.792890] phy0: Selected rate control algorithm 'iwl-3945-rs'
[ 20.000982] iwl3945 0000:10:00.0: loaded firmware version 15.32.2.9
[ 20.090054] ADDRCONF(NETDEV_UP): wlan0: link is not ready
[ 30.185858] wlan0: direct probe to 00:04:0e:e4:00:3d (try 1)
[ 30.188652] wlan0: direct probe responded
[ 30.200042] wlan0: authenticate with 00:04:0e:e4:00:3d (try 1)
[ 30.203234] wlan0: authenticated
[ 30.203856] wlan0: associate with 00:04:0e:e4:00:3d (try 1)
[ 30.400035] wlan0: associate with 00:04:0e:e4:00:3d (try 2)
[ 30.404960] wlan0: RX AssocResp from 00:04:0e:e4:00:3d (capab=0x411
status=0 aid=1)
[ 30.404966] wlan0: associated
[ 30.406500] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[ 41.048032] wlan0: no IPv6 routers present
On Tue, May 25, 2010 at 7:27 PM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
> On Tuesday 25 May 2010 10:08:22 am Abhijeet Kolekar wrote:
>> On Tue, 2010-05-25 at 10:01 -0700, Johannes Berg wrote:
>> > On Tue, 2010-05-25 at 09:39 -0700, Dmitry Torokhov wrote:
>> > > Hi,
>> > >
>> > > I am getting the following crashers in iwl3945 after updating to
>> > > post-2.6.34 kernels. This is with the pull from Linus's tree as of last
>> > > night (the taint is from nvidia module):
>> > >
>> > > [ 3330.630734] general protection fault: 0000 [#1] PREEMPT SMP
>> > > [ 3330.630752] last sysfs file: /sys/devices/platform/dock.0/docked
>> > > [ 3330.630761] CPU 0
>> > > [ 3330.630766] Modules linked in: cryptd aes_x86_64 aes_generic fuse
>> > > rfcomm sco bnep l2cap autofs4 coretemp hwmon sunrpc ppdev parport_pc
>> > > parport acpi_cpufreq mperf uinput nvidia(P) snd_hda_codec_idt arc4
>> > > snd_hda_intel ecb snd_hda_codec snd_hwdep iwl3945 joydev snd_seq
>> > > snd_seq_device snd_pcm iwlcore mac80211 snd_timer cfg80211 snd psmouse
>> > > iTCO_wdt dell_wmi iTCO_vendor_support serio_raw tg3 battery
>> > > dell_laptop dcdbas soundcore snd_page_alloc btusb bluetooth video
>> > > pcspkr mac_hid ac wmi libphy firewire_ohci i2c_i801 firewire_core
>> > > yenta_socket crc_itu_t ohci_hcd [last unloaded: microcode] [
>> > > 3330.630950]
>> > > [ 3330.630958] Pid: 455, comm: iwl3945 Tainted: P 2.6.35-rc0
>> > > #293 0WM416/Latitude D630 [ 3330.630967] RIP:
>> > > 0010:[<ffffffffa01e70d3>] [<ffffffffa01e70d3>]
>> > > iwl3945_get_channels_for_scan+0xe3/0x460 [iwl3945]
>> >
>> > http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2208
>>
>> Can you please try this patch and report your findings?
>>
>> http://bugzilla.intellinuxwireless.org/attachment.cgi?id=2447
>>
>
> Thanks, will try both this patch and the one John mention. Later tonight
> though.
>
> --
> Dmitry
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: Path for fixed channel issue in aircrack-ng suite
From: Gábor Stefanik @ 2010-05-25 22:54 UTC (permalink / raw)
To: Johannes Berg; +Cc: Joker Joker, linux-wireless
In-Reply-To: <1274775071.3635.4.camel@jlt3.sipsolutions.net>
On Tue, May 25, 2010 at 10:11 AM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Tue, 2010-05-25 at 01:07 -0400, Joker Joker wrote:
>> Below is a patch to fix monitor mode channel issue for aircrack-ng suit
>> (fixed channel mon0: -1)
>>
>> diff --git a/net/wireless/chan.c b/net/wireless/chan.c
>> index d92d088..93f6c19 100644
>> --- a/net/wireless/chan.c
>> +++ b/net/wireless/chan.c
>> @@ -48,6 +48,7 @@ int cfg80211_set_freq(struct cfg80211_registered_device *rdev,
>> enum nl80211_channel_type channel_type)
>> {
>> struct ieee80211_channel *chan;
>> + struct wireless_dev *old_wdev = wdev;
>> int result;
>>
>> if (wdev->iftype == NL80211_IFTYPE_MONITOR)
>> @@ -73,8 +74,8 @@ int cfg80211_set_freq(struct cfg80211_registered_device *rdev,
>> if (result)
>> return result;
>>
>> - if (wdev)
>> - wdev->channel = chan;
>> + wdev = old_wdev;
>> + wdev->channel = chan;
>
> NACK. That will crash when there really is no interface being passed in.
>
> johannes
>
> --
> 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
>
Well, the original version already dereferences wdev in "if
(wdev->iftype...", so the crash is nothing new if it exists.
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
^ permalink raw reply
* Re: ath5k past 2.6.30 breaks monitor mode (and thus the aircrack suite)
From: Gábor Stefanik @ 2010-05-25 22:59 UTC (permalink / raw)
To: Bob Copeland; +Cc: Weedy, linux-wireless, Johannes Berg
In-Reply-To: <AANLkTinyGlwqq4xshLU5Ol74p0VfcUXBjBGKXlsB2pMy@mail.gmail.com>
On Tue, May 25, 2010 at 4:53 PM, Bob Copeland <me@bobcopeland.com> wrote:
> 2010/5/25 Weedy <weedy2887@gmail.com>:
>> 2010/5/24 Gábor Stefanik <netrolller.3d@gmail.com>:
>>> 2010/5/25 Weedy <weedy2887@gmail.com>:
>>>> 2010/5/23 Gábor Stefanik <netrolller.3d@gmail.com>:
>>>>> In the meantime, one thing to test: Add a printk of sc->opmode.
>>>>
>>>> May 24 22:04:20 tiny-h4x kernel: [41147.243149] sc->opmode: 02 (over9000 times)
>>>>
>>>> So i'm guessing I did it wrong (I don't know C).
>>>> printk(KERN_NOTICE "sc->opmode: %02x\n", sc->opmode);
>>>>
>>>
>>> No, that is correct, and proves my theory (2 is NL80211_IFTYPE_STATION
>>> - it should be 6 for monitor mode).
>>>
>>> BTW, please use "Reply to all".
>>>
>> gmail got rid of the "Reply to all by default" option :<
>>
>> When you have a patch I will be waiting.
>
> Sorry, I missed this thread somehow. Thanks for the detective
> work and apologies for my stupid goof. Gábor, are you prepping
> a patch? I can fix it if you like.
>
If you can, please fix it - I know what the bug is, but have no solid
idea about a fix.
(The long-term fix of course would be to make mac80211 say
NL80211_IFTYPE_MONITOR for monitor interfaces, but AFAIK it is
impossible or unwanted - Johannes can probably shed more light on
this. One thing is sure: saying NL80211_IFTYPE_STATION when only a
monitor interface is active is wrong; it should be IFTYPE_MONITOR, or
if that is impossible, IFTYPE_INVALID.)
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
^ permalink raw reply
* Re: Realtek rtl8188 support?
From: Frederic Leroy @ 2010-05-25 23:00 UTC (permalink / raw)
To: Paul Thomas
Cc: Pavel Roskin, Gábor Stefanik, linux-wireless, Andrea Merello,
Jerry chuang
In-Reply-To: <AANLkTinUyRtemRZAN_IS7IqE033GPyKFe77FC94TcTYu@mail.gmail.com>
Hi Paul,
Le Mon, 24 May 2010 17:16:15 -0700,
Paul Thomas <pthomas8589@gmail.com> a écrit :
> On Mon, Mar 29, 2010 at 3:19 PM, Paul Thomas <pthomas8589@gmail.com>
> wrote:
> > OK, I'd love to get to where Pavel & Gabor are, but I think I'm
> > having trouble with the PCI dependency. I'm on an arm platform
> > without PCI (atmel at91sam9g20). If I remove the PCI dependency
> > from the Kconfig it does compile with warnings, and then when the
> > module loads I get "r8192s_usb: Unknown symbol wireless_send_event".
> [...]
> I haven't seen any activity on this driver in awhile. Is anyone
> working on it? My main request is to remove the PCI dependency. Any
> chance of this?
I started to work on this driver ago. But I didn't continue until
yesterday.
My adapter worked only once the first time. I have the feeling that
there need a lot of work on it until it may work.
I'm slow but still alive ;-) I will try to remove the dependency and
come back to you.
--
Frédéric Leroy
^ permalink raw reply
* Re: iwl3945 bug in 2.6.34
From: reinette chatre @ 2010-05-25 23:29 UTC (permalink / raw)
To: Satish Eerpini; +Cc: linux-kernel, linux-wireless@vger.kernel.org
In-Reply-To: <1274738896.2091.15438.camel@rchatre-DESK>
[-- Attachment #1: Type: text/plain, Size: 1141 bytes --]
Hi Satish,
On Mon, 2010-05-24 at 15:08 -0700, reinette chatre wrote:
> On Mon, 2010-05-24 at 11:33 -0700, reinette chatre wrote:
> > On Sat, 2010-05-22 at 23:25 -0700, Satish Eerpini wrote:
> >
> > > No probe response from AP 00:1b:da:2a:a1:53 after 500ms, disconnecting.
> > > iwl3945 0000:10:00.0: Error sending REPLY_RXON: time out after 500ms.
> > > iwl3945 0000:10:00.0: Error setting new configuration (-110).
> > > iwl3945 0000:10:00.0: Error sending REPLY_RXON: time out after 500ms.
> > > iwl3945 0000:10:00.0: Error setting new configuration (-110).
> >
> > This did not use to be an issue with 3945 and unfortunately we do not
> > know what is triggering it now. Please try the "Enable stuck queue
> > detection on 3945" patch that is attached to
> > http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=1834 as a
> > workaround.
>
> Actually, sorry, but that patch will not work on 2.6.34 since the
> feature it enables is not present there - it will be in 2.6.35 though.
> To enable the feature in 2.6.34 will take some more backporting effort
> that I'm looking into now.
Please try the attached two patches.
Reinette
[-- Attachment #2: 0001-iwlwifi-Recover-TX-flow-stall-due-to-stuck-queue.patch --]
[-- Type: text/x-patch, Size: 18496 bytes --]
>From acbbe6efb2aa8c68a2cf8a41364dead2002f5d46 Mon Sep 17 00:00:00 2001
From: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Date: Mon, 1 Mar 2010 17:23:50 -0800
Subject: [PATCH 1/2] iwlwifi: Recover TX flow stall due to stuck queue
Monitors the internal TX queues periodically. When a queue is stuck
for some unknown conditions causing the throughput to drop and the
transfer is stop, the driver will force firmware reload and bring the
system back to normal operational state.
The iwlwifi devices behave differently in this regard so this feature is
made part of the ops infrastructure so we can have more control on how to
monitor and recover from tx queue stall case per device.
Signed-off-by: Trieu 'Andrew' Nguyen <trieux.t.nguyen@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
---
drivers/net/wireless/iwlwifi/iwl-1000.c | 3 +
drivers/net/wireless/iwlwifi/iwl-3945.c | 2 +
drivers/net/wireless/iwlwifi/iwl-4965.c | 1 +
drivers/net/wireless/iwlwifi/iwl-5000.c | 9 +++
drivers/net/wireless/iwlwifi/iwl-6000.c | 8 ++
drivers/net/wireless/iwlwifi/iwl-agn.c | 16 +++++
drivers/net/wireless/iwlwifi/iwl-core.c | 93 +++++++++++++++++++++++++++
drivers/net/wireless/iwlwifi/iwl-core.h | 7 ++
drivers/net/wireless/iwlwifi/iwl-dev.h | 10 +++
drivers/net/wireless/iwlwifi/iwl-tx.c | 2 +
drivers/net/wireless/iwlwifi/iwl3945-base.c | 16 +++++
11 files changed, 167 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-1000.c b/drivers/net/wireless/iwlwifi/iwl-1000.c
index 3bf2e6e..89dc401 100644
--- a/drivers/net/wireless/iwlwifi/iwl-1000.c
+++ b/drivers/net/wireless/iwlwifi/iwl-1000.c
@@ -211,6 +211,7 @@ static struct iwl_lib_ops iwl1000_lib = {
.set_ct_kill = iwl1000_set_ct_threshold,
},
.add_bcast_station = iwl_add_bcast_station,
+ .recover_from_tx_stall = iwl_bg_monitor_recover,
};
static const struct iwl_ops iwl1000_ops = {
@@ -248,6 +249,7 @@ struct iwl_cfg iwl1000_bgn_cfg = {
.support_ct_kill_exit = true,
.plcp_delta_threshold = IWL_MAX_PLCP_ERR_EXT_LONG_THRESHOLD_DEF,
.chain_noise_scale = 1000,
+ .monitor_recover_period = IWL_MONITORING_PERIOD,
};
struct iwl_cfg iwl1000_bg_cfg = {
@@ -276,6 +278,7 @@ struct iwl_cfg iwl1000_bg_cfg = {
.support_ct_kill_exit = true,
.plcp_delta_threshold = IWL_MAX_PLCP_ERR_EXT_LONG_THRESHOLD_DEF,
.chain_noise_scale = 1000,
+ .monitor_recover_period = IWL_MONITORING_PERIOD,
};
MODULE_FIRMWARE(IWL1000_MODULE_FIRMWARE(IWL1000_UCODE_API_MAX));
diff --git a/drivers/net/wireless/iwlwifi/iwl-3945.c b/drivers/net/wireless/iwlwifi/iwl-3945.c
index 0728054..caebec4 100644
--- a/drivers/net/wireless/iwlwifi/iwl-3945.c
+++ b/drivers/net/wireless/iwlwifi/iwl-3945.c
@@ -2827,6 +2827,7 @@ static struct iwl_cfg iwl3945_bg_cfg = {
.led_compensation = 64,
.broken_powersave = true,
.plcp_delta_threshold = IWL_MAX_PLCP_ERR_THRESHOLD_DEF,
+ .monitor_recover_period = IWL_MONITORING_PERIOD,
};
static struct iwl_cfg iwl3945_abg_cfg = {
@@ -2845,6 +2846,7 @@ static struct iwl_cfg iwl3945_abg_cfg = {
.led_compensation = 64,
.broken_powersave = true,
.plcp_delta_threshold = IWL_MAX_PLCP_ERR_THRESHOLD_DEF,
+ .monitor_recover_period = IWL_MONITORING_PERIOD,
};
DEFINE_PCI_DEVICE_TABLE(iwl3945_hw_card_ids) = {
diff --git a/drivers/net/wireless/iwlwifi/iwl-4965.c b/drivers/net/wireless/iwlwifi/iwl-4965.c
index 8972166..aa49a6e 100644
--- a/drivers/net/wireless/iwlwifi/iwl-4965.c
+++ b/drivers/net/wireless/iwlwifi/iwl-4965.c
@@ -2251,6 +2251,7 @@ struct iwl_cfg iwl4965_agn_cfg = {
.led_compensation = 61,
.chain_noise_num_beacons = IWL4965_CAL_NUM_BEACONS,
.plcp_delta_threshold = IWL_MAX_PLCP_ERR_THRESHOLD_DEF,
+ .monitor_recover_period = IWL_MONITORING_PERIOD,
};
/* Module firmware */
diff --git a/drivers/net/wireless/iwlwifi/iwl-5000.c b/drivers/net/wireless/iwlwifi/iwl-5000.c
index e476acb..d05fad4 100644
--- a/drivers/net/wireless/iwlwifi/iwl-5000.c
+++ b/drivers/net/wireless/iwlwifi/iwl-5000.c
@@ -1500,6 +1500,7 @@ struct iwl_lib_ops iwl5000_lib = {
.set_ct_kill = iwl5000_set_ct_threshold,
},
.add_bcast_station = iwl_add_bcast_station,
+ .recover_from_tx_stall = iwl_bg_monitor_recover,
};
static struct iwl_lib_ops iwl5150_lib = {
@@ -1554,6 +1555,7 @@ static struct iwl_lib_ops iwl5150_lib = {
.set_ct_kill = iwl5150_set_ct_threshold,
},
.add_bcast_station = iwl_add_bcast_station,
+ .recover_from_tx_stall = iwl_bg_monitor_recover,
};
static const struct iwl_ops iwl5000_ops = {
@@ -1603,6 +1605,7 @@ struct iwl_cfg iwl5300_agn_cfg = {
.chain_noise_num_beacons = IWL_CAL_NUM_BEACONS,
.plcp_delta_threshold = IWL_MAX_PLCP_ERR_LONG_THRESHOLD_DEF,
.chain_noise_scale = 1000,
+ .monitor_recover_period = IWL_MONITORING_PERIOD,
};
struct iwl_cfg iwl5100_bgn_cfg = {
@@ -1629,6 +1632,7 @@ struct iwl_cfg iwl5100_bgn_cfg = {
.chain_noise_num_beacons = IWL_CAL_NUM_BEACONS,
.plcp_delta_threshold = IWL_MAX_PLCP_ERR_LONG_THRESHOLD_DEF,
.chain_noise_scale = 1000,
+ .monitor_recover_period = IWL_MONITORING_PERIOD,
};
struct iwl_cfg iwl5100_abg_cfg = {
@@ -1653,6 +1657,7 @@ struct iwl_cfg iwl5100_abg_cfg = {
.chain_noise_num_beacons = IWL_CAL_NUM_BEACONS,
.plcp_delta_threshold = IWL_MAX_PLCP_ERR_LONG_THRESHOLD_DEF,
.chain_noise_scale = 1000,
+ .monitor_recover_period = IWL_MONITORING_PERIOD,
};
struct iwl_cfg iwl5100_agn_cfg = {
@@ -1679,6 +1684,7 @@ struct iwl_cfg iwl5100_agn_cfg = {
.chain_noise_num_beacons = IWL_CAL_NUM_BEACONS,
.plcp_delta_threshold = IWL_MAX_PLCP_ERR_LONG_THRESHOLD_DEF,
.chain_noise_scale = 1000,
+ .monitor_recover_period = IWL_MONITORING_PERIOD,
};
struct iwl_cfg iwl5350_agn_cfg = {
@@ -1705,6 +1711,7 @@ struct iwl_cfg iwl5350_agn_cfg = {
.chain_noise_num_beacons = IWL_CAL_NUM_BEACONS,
.plcp_delta_threshold = IWL_MAX_PLCP_ERR_LONG_THRESHOLD_DEF,
.chain_noise_scale = 1000,
+ .monitor_recover_period = IWL_MONITORING_PERIOD,
};
struct iwl_cfg iwl5150_agn_cfg = {
@@ -1731,6 +1738,7 @@ struct iwl_cfg iwl5150_agn_cfg = {
.chain_noise_num_beacons = IWL_CAL_NUM_BEACONS,
.plcp_delta_threshold = IWL_MAX_PLCP_ERR_LONG_THRESHOLD_DEF,
.chain_noise_scale = 1000,
+ .monitor_recover_period = IWL_MONITORING_PERIOD,
};
struct iwl_cfg iwl5150_abg_cfg = {
@@ -1755,6 +1763,7 @@ struct iwl_cfg iwl5150_abg_cfg = {
.chain_noise_num_beacons = IWL_CAL_NUM_BEACONS,
.plcp_delta_threshold = IWL_MAX_PLCP_ERR_LONG_THRESHOLD_DEF,
.chain_noise_scale = 1000,
+ .monitor_recover_period = IWL_MONITORING_PERIOD,
};
MODULE_FIRMWARE(IWL5000_MODULE_FIRMWARE(IWL5000_UCODE_API_MAX));
diff --git a/drivers/net/wireless/iwlwifi/iwl-6000.c b/drivers/net/wireless/iwlwifi/iwl-6000.c
index 92b3e64..0c965cd 100644
--- a/drivers/net/wireless/iwlwifi/iwl-6000.c
+++ b/drivers/net/wireless/iwlwifi/iwl-6000.c
@@ -277,6 +277,7 @@ static struct iwl_lib_ops iwl6000_lib = {
.set_ct_kill = iwl6000_set_ct_threshold,
},
.add_bcast_station = iwl_add_bcast_station,
+ .recover_from_tx_stall = iwl_bg_monitor_recover,
};
static const struct iwl_ops iwl6000_ops = {
@@ -342,6 +343,7 @@ static struct iwl_lib_ops iwl6050_lib = {
.set_calib_version = iwl6050_set_calib_version,
},
.add_bcast_station = iwl_add_bcast_station,
+ .recover_from_tx_stall = iwl_bg_monitor_recover,
};
static const struct iwl_ops iwl6050_ops = {
@@ -385,6 +387,7 @@ struct iwl_cfg iwl6000i_2agn_cfg = {
.support_ct_kill_exit = true,
.plcp_delta_threshold = IWL_MAX_PLCP_ERR_THRESHOLD_DEF,
.chain_noise_scale = 1000,
+ .monitor_recover_period = IWL_MONITORING_PERIOD,
};
struct iwl_cfg iwl6000i_2abg_cfg = {
@@ -416,6 +419,7 @@ struct iwl_cfg iwl6000i_2abg_cfg = {
.support_ct_kill_exit = true,
.plcp_delta_threshold = IWL_MAX_PLCP_ERR_THRESHOLD_DEF,
.chain_noise_scale = 1000,
+ .monitor_recover_period = IWL_MONITORING_PERIOD,
};
struct iwl_cfg iwl6000i_2bg_cfg = {
@@ -447,6 +451,7 @@ struct iwl_cfg iwl6000i_2bg_cfg = {
.support_ct_kill_exit = true,
.plcp_delta_threshold = IWL_MAX_PLCP_ERR_THRESHOLD_DEF,
.chain_noise_scale = 1000,
+ .monitor_recover_period = IWL_MONITORING_PERIOD,
};
struct iwl_cfg iwl6050_2agn_cfg = {
@@ -479,6 +484,7 @@ struct iwl_cfg iwl6050_2agn_cfg = {
.support_ct_kill_exit = true,
.plcp_delta_threshold = IWL_MAX_PLCP_ERR_THRESHOLD_DEF,
.chain_noise_scale = 1500,
+ .monitor_recover_period = IWL_MONITORING_PERIOD,
};
struct iwl_cfg iwl6050_2abg_cfg = {
@@ -510,6 +516,7 @@ struct iwl_cfg iwl6050_2abg_cfg = {
.support_ct_kill_exit = true,
.plcp_delta_threshold = IWL_MAX_PLCP_ERR_THRESHOLD_DEF,
.chain_noise_scale = 1500,
+ .monitor_recover_period = IWL_MONITORING_PERIOD,
};
struct iwl_cfg iwl6000_3agn_cfg = {
@@ -542,6 +549,7 @@ struct iwl_cfg iwl6000_3agn_cfg = {
.support_ct_kill_exit = true,
.plcp_delta_threshold = IWL_MAX_PLCP_ERR_THRESHOLD_DEF,
.chain_noise_scale = 1000,
+ .monitor_recover_period = IWL_MONITORING_PERIOD,
};
MODULE_FIRMWARE(IWL6000_MODULE_FIRMWARE(IWL6000_UCODE_API_MAX));
diff --git a/drivers/net/wireless/iwlwifi/iwl-agn.c b/drivers/net/wireless/iwlwifi/iwl-agn.c
index bdff565..07a9a02 100644
--- a/drivers/net/wireless/iwlwifi/iwl-agn.c
+++ b/drivers/net/wireless/iwlwifi/iwl-agn.c
@@ -2106,6 +2106,13 @@ static void iwl_alive_start(struct iwl_priv *priv)
/* After the ALIVE response, we can send host commands to the uCode */
set_bit(STATUS_ALIVE, &priv->status);
+ if (priv->cfg->ops->lib->recover_from_tx_stall) {
+ /* Enable timer to monitor the driver queues */
+ mod_timer(&priv->monitor_recover,
+ jiffies +
+ msecs_to_jiffies(priv->cfg->monitor_recover_period));
+ }
+
if (iwl_is_rfkill(priv))
return;
@@ -3316,6 +3323,13 @@ static void iwl_setup_deferred_work(struct iwl_priv *priv)
priv->ucode_trace.data = (unsigned long)priv;
priv->ucode_trace.function = iwl_bg_ucode_trace;
+ if (priv->cfg->ops->lib->recover_from_tx_stall) {
+ init_timer(&priv->monitor_recover);
+ priv->monitor_recover.data = (unsigned long)priv;
+ priv->monitor_recover.function =
+ priv->cfg->ops->lib->recover_from_tx_stall;
+ }
+
if (!priv->cfg->use_isr_legacy)
tasklet_init(&priv->irq_tasklet, (void (*)(unsigned long))
iwl_irq_tasklet, (unsigned long)priv);
@@ -3336,6 +3350,8 @@ static void iwl_cancel_deferred_work(struct iwl_priv *priv)
cancel_work_sync(&priv->beacon_update);
del_timer_sync(&priv->statistics_periodic);
del_timer_sync(&priv->ucode_trace);
+ if (priv->cfg->ops->lib->recover_from_tx_stall)
+ del_timer_sync(&priv->monitor_recover);
}
static void iwl_init_hw_rates(struct iwl_priv *priv,
diff --git a/drivers/net/wireless/iwlwifi/iwl-core.c b/drivers/net/wireless/iwlwifi/iwl-core.c
index 049b652..a5a2de6 100644
--- a/drivers/net/wireless/iwlwifi/iwl-core.c
+++ b/drivers/net/wireless/iwlwifi/iwl-core.c
@@ -3403,6 +3403,99 @@ int iwl_force_reset(struct iwl_priv *priv, int mode)
}
return 0;
}
+EXPORT_SYMBOL(iwl_force_reset);
+
+/**
+ * iwl_bg_monitor_recover - Timer callback to check for stuck queue and recover
+ *
+ * During normal condition (no queue is stuck), the timer is continually set to
+ * execute every monitor_recover_period milliseconds after the last timer
+ * expired. When the queue read_ptr is at the same place, the timer is
+ * shorten to 100mSecs. This is
+ * 1) to reduce the chance that the read_ptr may wrap around (not stuck)
+ * 2) to detect the stuck queues quicker before the station and AP can
+ * disassociate each other.
+ *
+ * This function monitors all the tx queues and recover from it if any
+ * of the queues are stuck.
+ * 1. It first check the cmd queue for stuck conditions. If it is stuck,
+ * it will recover by resetting the firmware and return.
+ * 2. Then, it checks for station association. If it associates it will check
+ * other queues. If any queue is stuck, it will recover by resetting
+ * the firmware.
+ * Note: It the number of times the queue read_ptr to be at the same place to
+ * be MAX_REPEAT+1 in order to consider to be stuck.
+ */
+/*
+ * The maximum number of times the read pointer of the tx queue at the
+ * same place without considering to be stuck.
+ */
+#define MAX_REPEAT (2)
+static int iwl_check_stuck_queue(struct iwl_priv *priv, int cnt)
+{
+ struct iwl_tx_queue *txq;
+ struct iwl_queue *q;
+
+ txq = &priv->txq[cnt];
+ q = &txq->q;
+ /* queue is empty, skip */
+ if (q->read_ptr != q->write_ptr) {
+ if (q->read_ptr == q->last_read_ptr) {
+ /* a queue has not been read from last time */
+ if (q->repeat_same_read_ptr > MAX_REPEAT) {
+ IWL_ERR(priv,
+ "queue %d stuck %d time. Fw reload.\n",
+ q->id, q->repeat_same_read_ptr);
+ q->repeat_same_read_ptr = 0;
+ iwl_force_reset(priv, IWL_FW_RESET);
+ } else {
+ q->repeat_same_read_ptr++;
+ IWL_DEBUG_RADIO(priv,
+ "queue %d, not read %d time\n",
+ q->id,
+ q->repeat_same_read_ptr);
+ mod_timer(&priv->monitor_recover, jiffies +
+ msecs_to_jiffies(IWL_ONE_HUNDRED_MSECS));
+ }
+ return 1;
+ } else {
+ q->last_read_ptr = q->read_ptr;
+ q->repeat_same_read_ptr = 0;
+ }
+ }
+ return 0;
+}
+
+void iwl_bg_monitor_recover(unsigned long data)
+{
+ struct iwl_priv *priv = (struct iwl_priv *)data;
+ int cnt;
+
+ if (test_bit(STATUS_EXIT_PENDING, &priv->status))
+ return;
+
+ /* monitor and check for stuck cmd queue */
+ if (iwl_check_stuck_queue(priv, IWL_CMD_QUEUE_NUM))
+ return;
+
+ /* monitor and check for other stuck queues */
+ if (iwl_is_associated(priv)) {
+ for (cnt = 0; cnt < priv->hw_params.max_txq_num; cnt++) {
+ /* skip as we already checked the command queue */
+ if (cnt == IWL_CMD_QUEUE_NUM)
+ continue;
+ if (iwl_check_stuck_queue(priv, cnt))
+ return;
+ }
+ }
+ /*
+ * Reschedule the timer to occur in
+ * priv->cfg->monitor_recover_period
+ */
+ mod_timer(&priv->monitor_recover,
+ jiffies + msecs_to_jiffies(priv->cfg->monitor_recover_period));
+}
+EXPORT_SYMBOL(iwl_bg_monitor_recover);
#ifdef CONFIG_PM
diff --git a/drivers/net/wireless/iwlwifi/iwl-core.h b/drivers/net/wireless/iwlwifi/iwl-core.h
index 36940a9..9076576 100644
--- a/drivers/net/wireless/iwlwifi/iwl-core.h
+++ b/drivers/net/wireless/iwlwifi/iwl-core.h
@@ -191,6 +191,8 @@ struct iwl_lib_ops {
struct iwl_temp_ops temp_ops;
/* station management */
void (*add_bcast_station)(struct iwl_priv *priv);
+ /* recover from tx queue stall */
+ void (*recover_from_tx_stall)(unsigned long data);
};
struct iwl_led_ops {
@@ -295,6 +297,8 @@ struct iwl_cfg {
const bool support_wimax_coexist;
u8 plcp_delta_threshold;
s32 chain_noise_scale;
+ /* timer period for monitor the driver queues */
+ u32 monitor_recover_period;
};
/***************************
@@ -577,6 +581,9 @@ static inline u16 iwl_pcie_link_ctl(struct iwl_priv *priv)
pci_read_config_word(priv->pci_dev, pos + PCI_EXP_LNKCTL, &pci_lnk_ctl);
return pci_lnk_ctl;
}
+
+void iwl_bg_monitor_recover(unsigned long data);
+
#ifdef CONFIG_PM
int iwl_pci_suspend(struct pci_dev *pdev, pm_message_t state);
int iwl_pci_resume(struct pci_dev *pdev);
diff --git a/drivers/net/wireless/iwlwifi/iwl-dev.h b/drivers/net/wireless/iwlwifi/iwl-dev.h
index ef1720a..447e14b 100644
--- a/drivers/net/wireless/iwlwifi/iwl-dev.h
+++ b/drivers/net/wireless/iwlwifi/iwl-dev.h
@@ -183,6 +183,10 @@ struct iwl_queue {
int n_bd; /* number of BDs in this queue */
int write_ptr; /* 1-st empty entry (index) host_w*/
int read_ptr; /* last used entry (index) host_r*/
+ /* use for monitoring and recovering the stuck queue */
+ int last_read_ptr; /* storing the last read_ptr */
+ /* number of time read_ptr and last_read_ptr are the same */
+ u8 repeat_same_read_ptr;
dma_addr_t dma_addr; /* physical addr for BD's */
int n_window; /* safe queue window */
u32 id;
@@ -1039,6 +1043,11 @@ struct iwl_event_log {
#define IWL_DELAY_NEXT_FORCE_RF_RESET (HZ*3)
#define IWL_DELAY_NEXT_FORCE_FW_RELOAD (HZ*5)
+/* timer constants use to monitor and recover stuck tx queues in mSecs */
+#define IWL_MONITORING_PERIOD (1000)
+#define IWL_ONE_HUNDRED_MSECS (100)
+#define IWL_SIXTY_SECS (60000)
+
enum iwl_reset {
IWL_RF_RESET = 0,
IWL_FW_RESET,
@@ -1339,6 +1348,7 @@ struct iwl_priv {
struct work_struct run_time_calib_work;
struct timer_list statistics_periodic;
struct timer_list ucode_trace;
+ struct timer_list monitor_recover;
bool hw_ready;
/*For 3945*/
#define IWL_DEFAULT_TX_POWER 0x0F
diff --git a/drivers/net/wireless/iwlwifi/iwl-tx.c b/drivers/net/wireless/iwlwifi/iwl-tx.c
index 8dd0c03..6af23f2 100644
--- a/drivers/net/wireless/iwlwifi/iwl-tx.c
+++ b/drivers/net/wireless/iwlwifi/iwl-tx.c
@@ -310,6 +310,8 @@ static int iwl_queue_init(struct iwl_priv *priv, struct iwl_queue *q,
q->high_mark = 2;
q->write_ptr = q->read_ptr = 0;
+ q->last_read_ptr = 0;
+ q->repeat_same_read_ptr = 0;
return 0;
}
diff --git a/drivers/net/wireless/iwlwifi/iwl3945-base.c b/drivers/net/wireless/iwlwifi/iwl3945-base.c
index b74a56c..84c040e 100644
--- a/drivers/net/wireless/iwlwifi/iwl3945-base.c
+++ b/drivers/net/wireless/iwlwifi/iwl3945-base.c
@@ -2513,6 +2513,13 @@ static void iwl3945_alive_start(struct iwl_priv *priv)
/* After the ALIVE response, we can send commands to 3945 uCode */
set_bit(STATUS_ALIVE, &priv->status);
+ if (priv->cfg->ops->lib->recover_from_tx_stall) {
+ /* Enable timer to monitor the driver queues */
+ mod_timer(&priv->monitor_recover,
+ jiffies +
+ msecs_to_jiffies(priv->cfg->monitor_recover_period));
+ }
+
if (iwl_is_rfkill(priv))
return;
@@ -3783,6 +3790,13 @@ static void iwl3945_setup_deferred_work(struct iwl_priv *priv)
iwl3945_hw_setup_deferred_work(priv);
+ if (priv->cfg->ops->lib->recover_from_tx_stall) {
+ init_timer(&priv->monitor_recover);
+ priv->monitor_recover.data = (unsigned long)priv;
+ priv->monitor_recover.function =
+ priv->cfg->ops->lib->recover_from_tx_stall;
+ }
+
tasklet_init(&priv->irq_tasklet, (void (*)(unsigned long))
iwl3945_irq_tasklet, (unsigned long)priv);
}
@@ -3795,6 +3809,8 @@ static void iwl3945_cancel_deferred_work(struct iwl_priv *priv)
cancel_delayed_work(&priv->scan_check);
cancel_delayed_work(&priv->alive_start);
cancel_work_sync(&priv->beacon_update);
+ if (priv->cfg->ops->lib->recover_from_tx_stall)
+ del_timer_sync(&priv->monitor_recover);
}
static struct attribute *iwl3945_sysfs_entries[] = {
--
1.7.0.4
[-- Attachment #3: 0002-iwl3945-enable-stuck-queue-detection-on-3945.patch --]
[-- Type: text/x-patch, Size: 1167 bytes --]
>From 9e1c18e230bddad0ed7a8a8058d2dd8666f475f3 Mon Sep 17 00:00:00 2001
From: Reinette Chatre <reinette.chatre@intel.com>
Date: Thu, 20 May 2010 10:54:40 -0700
Subject: [PATCH 2/2] iwl3945: enable stuck queue detection on 3945
We learn from
http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=1834 and
https://bugzilla.redhat.com/show_bug.cgi?id=589777
that 3945 can also suffer from a stuck command queue. Enable stuck queue
detection for iwl3945 to enable recovery in this case.
Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
---
drivers/net/wireless/iwlwifi/iwl-3945.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-3945.c b/drivers/net/wireless/iwlwifi/iwl-3945.c
index caebec4..c92fbe4 100644
--- a/drivers/net/wireless/iwlwifi/iwl-3945.c
+++ b/drivers/net/wireless/iwlwifi/iwl-3945.c
@@ -2792,6 +2792,7 @@ static struct iwl_lib_ops iwl3945_lib = {
.isr = iwl_isr_legacy,
.config_ap = iwl3945_config_ap,
.add_bcast_station = iwl3945_add_bcast_station,
+ .recover_from_tx_stall = iwl_bg_monitor_recover,
};
static struct iwl_hcmd_utils_ops iwl3945_hcmd_utils = {
--
1.7.0.4
^ permalink raw reply related
* Is there a bug in 2.6.29-rc8 support of Ad-Hoc mode?
From: Charles Gordon @ 2010-05-26 0:00 UTC (permalink / raw)
To: linux-wireless
I am trying to get a driver I'm developing to work with Ad-Hoc mode on
Linux 2.6.29-rc8. I am running into a problem. I have traced it down
to the routine ieee80211_scan_work. I use the following commands to
start Ad-Hoc mode:
ifconfig wlan0 down
iwconfig wlan0 mode Ad-Hoc essid "AdHocID"
ifconfig wlan0 up
What happens is that the iwconfig command starts a scan for other PCs
using the AdHocID before the second ifconfig command is executed
(while the interface is still down). When ieee80211_scan_work is
executed, it bails out at this statement:
/*
* Avoid re-scheduling when the sdata is going away.
*/
if (!netif_running(sdata->dev))
return;
This aborts the scan, but leaves local->sw_scanning set. This
prevents future scans from running. When ieee80211_start_scan
executes it bails out at this statement:
if (local->sw_scanning || local->hw_scanning) {
if (local->scan_sdata == scan_sdata)
return 0;
return -EBUSY;
}
Can someone either confirm that this is a known problem with
2.6.28-rc8, or tell me what my driver could be doing to cause this
problem?
Thanks for any help you can provide.
^ permalink raw reply
* Compat-wireless tarballs with pending and crap patches
From: Luis R. Rodriguez @ 2010-05-26 0:41 UTC (permalink / raw)
To: linux-wireless, linux-bluetooth
Cc: linux-kernel, Ivan Seskar, Shridatt James Sugrim
Since I added a way for compat-wireless to have pending and crap
patches applied I figured I'd automate the creation of the same
tarballs. The tarballs are hosted on Orbit as well in the same
location as the regular tarballs. So we have for today for example:
compat-wireless-2010-05-25.tar.bz2 - The usual linux-next based
tarball for 802.11 and BT
compat-wireless-2010-05-25-p.tar.bz2 - The usual linux-next based
tarball + patches from linux-next-pending/
compat-wireless-2010-05-25-pc.tar.bz2 -
compat-wireless-2010-05-25-p.tar.bz2 + patches from crap/
Since we're in the merge window the pending stuff is a bit big and it
just includes stuff in Atheros' queue. Feel free to poke at me to
apply anything else, just e-mail me, hopefully in reply to the
upstream posted patch. If there's a better way to do this we will
figure it out I guess.
FWIW the new code metrics for the pc release is:
compat-wireless code metrics
491620 - Total upstream code being pulled
1393 - backport code changes
1163 - backport code additions
230 - backport code deletions
5679 - backport from compat module
7072 - total backport code
1.44 - % of code consists of backport work
7132 - Code changes posted but not yet merged
4449 - Code additions posted but not yet merged
2683 - Code deletions posted but not yet merged
1.45 - % of code not yet merged
1225 - Crap changes not yet posted
1181 - Crap additions not yet merged
44 - Crap deletions not yet posted
0.25 - % of crap code
Base tree: linux-next.git
Base tree version: next-20100525
compat-wireless release: compat-wireless-20100525
The backport metrics should now be a bit more correct, so I do guess
1.44% code for this release is backport work, this includes C code,
header files and the code changed by the patches. The pending code is
a bit high due to the merge window, and the crap stuff hasn't moved.
These stats will always be available on the code-metrics.txt file for
each tarball. For the "p" release you will not see the metrics for the
crap, and for the regular tarball you will not see the pending stats
nor the crap stats.
Luis
^ permalink raw reply
* AR9220 + compat-wireless 2010-05-25 + HT40 == death
From: Jeffrey Baker @ 2010-05-26 5:05 UTC (permalink / raw)
To: linux-wireless
On my AP I installed compat-wireless 2010-05-25, where I already had
hostapd 0.6.10 and kernel 2.6.30, with an AR9220 radio card. I was
using this config (irrelevant bits elided):
driver=nl80211
country_code=US
hw_mode=g
channel=11
beacon_int=100
dtim_period=2
max_num_sta=255
rts_threshold=2347
fragm_threshold=2346
ieee80211n=1
ht_capab=[HT40-][SHORT-GI-40]
After connecting with an Intel 6300 mobile station, I could pass
packets for perhaps one minute before the connection would stop
working. I never did get disassociation on the mobile station, and
there was nothing odd in the hostapd logs. It just stopped working.
An iperf run would kill it off immediately. On the mobile station, iw
dev wlan0 link indicated rates as high as 300mbps before it stopped
working.
Removing these two lines from my config make it work reliably:
ieee80211n=1
ht_capab=[HT40-][SHORT-GI-40]
In other words, disabling 802.11n makes it work OK. Unfortunately
with 11n disabled I get only about 8mbps from station to station,
which is pathetic.
Would be happy to send any logs needed to debug this. I don't see
anything in hostapd's output nor in dmesg that indicates any kind of
error.
-jwb
^ permalink raw reply
* Re: [PATCH] cfg80211: Fix user-space crda query stall
From: Juuso Oikarinen @ 2010-05-26 5:08 UTC (permalink / raw)
To: ext Luis R. Rodriguez
Cc: linville@tuxdriver.com, linux-wireless@vger.kernel.org
In-Reply-To: <AANLkTinMo6L_LuCgcu9izxUVsFbi7kamHD2F_xThwJ2R@mail.gmail.com>
On Tue, 2010-05-25 at 21:02 +0200, ext Luis R. Rodriguez wrote:
> On Mon, May 24, 2010 at 11:50 PM, Juuso Oikarinen
> <juuso.oikarinen@nokia.com> wrote:
> > The userspace crda utility can fail to respond to kernel requests in (at least)
> > two scenarios: it is not runnable for any reason, or it is invoked with a
> > country code not in its database.
> >
> > When the userspace crda utility fails to respond to kernel requests (i.e. it
> > does not use NL80211_CMD_SET_REG to provide the kernel regulatory information
> > for the requested country) the kernel crda subsystem will stall. It will
> > refuse to process any further regulatory hints. This is easiest demonstrated
> > by using for instance the "iw" tool:
> >
> > iw reg set EU
> > iw reg set US
> >
> > "EU" is not a country code present in the database, so user space crda will
> > not respond. Attempting to define US after that will be silently ignored
> > (internally, an -EAGAIN is the result, as the "EU" request is still
> > "being processed".)
> >
> > To fix this issue, this patch implements timeout protection for the userspace
> > crda invocation. If there is no response for five seconds, the crda code will
> > force itself to the world regulatory domain for maximum safety.
> >
> > Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
>
> This is a great idea, I really like it and appreciate you taking the
> time to work on this, however to do this it requires a little more
> work and will point out the notes below. So NACK for now but with some
> fixes I think this would be great.
>
> > ---
> > net/wireless/reg.c | 44 ++++++++++++++++++++++++++++++++++++++++++++
> > 1 files changed, 44 insertions(+), 0 deletions(-)
> >
> > diff --git a/net/wireless/reg.c b/net/wireless/reg.c
> > index 8f0d97d..6c945f0 100644
> > --- a/net/wireless/reg.c
> > +++ b/net/wireless/reg.c
> > @@ -385,6 +385,40 @@ static inline void reg_regdb_query(const char *alpha2) {}
> > #endif /* CONFIG_CFG80211_INTERNAL_REGDB */
> >
> > /*
> > + * This gets invoked if crda in userspace is not responding (it's not getting
> > + * executed or the country code in the hint is not in the database.
> > + */
> > +
> > +static void call_crda_timeout_work(struct work_struct *work)
> > +{
> > + if (!last_request)
> > + return;
> > +
> > + printk(KERN_INFO "cfg80211: crda request timed out, reverting to 00\n");
> > +
> > + mutex_lock(&cfg80211_mutex);
> > +
> > + /*
> > + * As we are not getting data for the current country, force us back
> > + * to the world regdomain.
> > + */
> > + last_request->alpha2[0] = '0';
> > + last_request->alpha2[1] = '0';
> > + set_regdom(cfg80211_world_regdom);
> > + mutex_unlock(&cfg80211_mutex);
> > +}
>
>
> Actually you may want to consider using restore_regulatory_settings()
> instead as that would:
>
> * set the world regdom
> * then set the first user specified regulatory domain if they had one picked
>
> This would mean we would go into a loop here though if the user had
> specified 'EU' though so this routine first needs to be fixed to
> annotate a regulatory domain as invalid. Note that a regulatory cannot
> be invalid if CRDA just times out -- CRDA could time out if it was not
> present. So this is a bit tricky and not sure how to resolve it. John
> recently added support for building the regulatory database as part of
> the kernel but at the same time support letting CRDA still update the
> same info if it is present. Then for those setup it could be possible
> 'DE' exists on the core kernel regulatory database but if CRDA is not
> installed then CRDA will time out.
>
> Maybe what we can do is if both the internal kernel regdb *and* CRDA
> times out then mark the user specified request as invalid and restore
> to using the world regdom. This would allow the user to later install
> a CRDA with some newer regdb in userspace, for example. This allows
> for upgrading the db itself from userspace without making kernel
> changes. It allows for countries to be created.
Sounds fair. Here's my initial thought:
I will look into adding validation of the country code with the kernel
internal database if the db is enabled in the config - in which case we
proceed as you describe. In case the internal db is disabled in the
config, we proceed as the patch currently does?
Would that sound like an acceptable approach?
-Juuso
>
> > +
> > +static DECLARE_WORK(crda_uevent_timeout_work, call_crda_timeout_work);
> > +
> > +#define CRDA_UEVENT_TIMEOUT 5000
> > +static void crda_uevent_timeout(unsigned long data)
> > +{
> > + schedule_work(&crda_uevent_timeout_work);
> > +}
> > +
> > +static DEFINE_TIMER(crda_uevent_timer, crda_uevent_timeout, 0, 0);
>
> I would prefer we use a completion here, seems a little cleaner. Check
> out ath9k/wmi.c for cmd_wait and its use with init_completion() and
> complete().
>
> > +/*
> > * This lets us keep regulatory code which is updated on a regulatory
> > * basis in userspace.
> > */
> > @@ -409,6 +443,10 @@ static int call_crda(const char *alpha2)
> > country_env[8] = alpha2[0];
> > country_env[9] = alpha2[1];
> >
> > + /* start timeout timer */
> > + mod_timer(&crda_uevent_timer,
> > + jiffies + msecs_to_jiffies(CRDA_UEVENT_TIMEOUT));
> > +
> > return kobject_uevent_env(®_pdev->dev.kobj, KOBJ_CHANGE, envp);
> > }
> >
> > @@ -2581,6 +2619,9 @@ int set_regdom(const struct ieee80211_regdomain *rd)
> >
> > assert_cfg80211_lock();
> >
> > + /* cancel timeout */
> > + del_timer(&crda_uevent_timer);
> > +
> > mutex_lock(®_mutex);
> >
> > /* Note that this doesn't update the wiphys, this is done below */
> > @@ -2683,6 +2724,9 @@ void regulatory_exit(void)
> >
> > cancel_work_sync(®_work);
> >
> > + del_timer_sync(&crda_uevent_timer);
> > + cancel_work_sync(&crda_uevent_timeout_work);
> > +
> > mutex_lock(&cfg80211_mutex);
> > mutex_lock(®_mutex);
>
> Thanks!!!
>
> Luis
^ permalink raw reply
* Re: wireless-regdb: A band is missing for IL
From: Emmanuel Grumbach @ 2010-05-26 6:25 UTC (permalink / raw)
To: David Quan
Cc: Luis R. Rodriguez, Michael Green, linville@tuxdriver.com,
linux-wireless@vger.kernel.org
In-Reply-To: <93781E992CBA7843962D8B0E7D683F3C11178EC0E4@SC1EXMB-MBCL.global.atheros.com>
I don't know exactly what Unii1 and Unii2 means but, this is the
latest regulatory authoritative document (in hebrew):
http://www.moc.gov.il/sip_storage/FILES/1/1061.pdf
In short:
1. 5150 - 5250
2. 5250 - 5350 DFS mandatory
3. outdoor is forbidden for both
4. 200mW maximum e.i.r.p.
5. 40 Mhz is allowed for all WiFi Alliance equipment in 5.2GHz
6. 40 Mhz is allowed for WiFi Alliance equipment that have "40 MHz
operation in 2.4 GHz, with coexistence mechanisms" only
I know how to enforce 1 - 4. But 5 and 6 is another story....
Anyway, I will send an RFC soon.
Emmanuel Grumbach
egrumbach@gmail.com
On Tue, May 25, 2010 at 23:39, David Quan <David.Quan@atheros.com> wrote:
> Israel follows ETSI3_WORLD,
> this means
>
> Unii1 + Unii2 is supported. Unii2 requires DFS for APs.
>
> 2ghz Ch1-13 supported.
>
>
> -----Original Message-----
> From: Luis R. Rodriguez [mailto:mcgrof@gmail.com]
> Sent: Tuesday, May 25, 2010 12:08 PM
> To: Emmanuel Grumbach; Michael Green; David Quan
> Cc: linville@tuxdriver.com; linux-wireless@vger.kernel.org
> Subject: Re: wireless-regdb: A band is missing for IL
>
> Michael, please review and let us know what you think.
>
> Luis
>
> On Tue, May 25, 2010 at 12:03 AM, Emmanuel Grumbach <egrumbach@gmail.com> wrote:
>> According to http://en.wikipedia.org/wiki/List_of_WLAN_channels#5.C2.A0GHz_.28802.11a.2Fh.2Fj.2Fn.29
>>
>> Channels 34 - 64 are allowed in 20 Mhz in Israel. This is not what is
>> written in db.txt:
>>
>> country IL:
>> (2402 - 2482 @ 40), (N/A, 20)
>>
>> This wikipedia page relies on an official page from the Israel
>> Ministry of the Communication.
>>
>> Emmanuel Grumbach
>> egrumbach@gmail.com
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
^ permalink raw reply
* [RFC] wireless-regdb: Add A band in IL
From: Emmanuel Grumbach @ 2010-05-26 6:49 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Emmanuel Grumbach, Michael Green, David Quan
A band in allowed in IL, according to official document issued by the Ministry
of Communications: http://www.moc.gov.il/sip_storage/FILES/1/1061.pdf.
5150 - 5250 200mW e.i.r.p. OUTDOOR forbidden
5250 - 5350 200mW e.i.r.p. OUTDOOR forbidden DFS mandatory
40Mhz is allowed in A band for every WiFi-Alliance certified equipment.
***************************************************************
Not to be merged for the moment
***************************************************************
CC: Michael Green <Michael.Green@atheros.com>
CC: David Quan <David.Quan@atheros.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
---
db.txt | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/db.txt b/db.txt
index e63a43e..d49c397 100644
--- a/db.txt
+++ b/db.txt
@@ -319,6 +319,8 @@ country IE:
country IL:
(2402 - 2482 @ 40), (N/A, 20)
+ (5150 - 5250 @ 40). (N/A, 200 mW), NO-OUTDOOR
+ (5250 - 5350 @ 40). (N/A, 200 mW), NO-OUTDOOR, DFS
country IN:
(2402 - 2482 @ 40), (N/A, 20)
--
1.6.4.2
---------------------------------------------------------------------
Intel Israel (74) Limited
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
^ permalink raw reply related
* Re: Path for fixed channel issue in aircrack-ng suite
From: Johannes Berg @ 2010-05-26 7:51 UTC (permalink / raw)
To: Gábor Stefanik; +Cc: Joker Joker, linux-wireless
In-Reply-To: <AANLkTilPIt59FhAuVlhisUR7QDabCtnZwahjxWbUysiG@mail.gmail.com>
On Wed, 2010-05-26 at 00:54 +0200, Gábor Stefanik wrote:
> >> - if (wdev)
> >> - wdev->channel = chan;
> >> + wdev = old_wdev;
> >> + wdev->channel = chan;
> >
> > NACK. That will crash when there really is no interface being passed in.
> >
> > johannes
> >
> > --
> > 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
> >
>
> Well, the original version already dereferences wdev in "if
> (wdev->iftype...", so the crash is nothing new if it exists.
It has also been fixed since.
johannes
^ permalink raw reply
* [PATCH] cfg80211: Removed warning from cfg80211_send_rx_auth
From: Teemu Paasikivi @ 2010-05-26 10:43 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Teemu Paasikivi
In cfg80211_send_rx_auth function there was a warning if bssid of the received
authentication message was not found from the authtry_bsses table.
During the beginning of the authentication there is a small time window, when
handling of the received deauthentication message can cause information
for the access point to be removed from the authtry_bsses table before
authentication response is received. This triggers the warning. This has
been seen happening with several access points occasionally. At least
one of those (Asus) has been seen to send spurious deauthentication
messages after deauthentication. Possibly this warning could be triggered also
by forged deauthentication messages sent at a correct time.
Signed-off-by: Teemu Paasikivi <ext-teemu.3.paasikivi@nokia.com>
---
net/wireless/mlme.c | 4 ----
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/net/wireless/mlme.c b/net/wireless/mlme.c
index 0855f0d..2565882 100644
--- a/net/wireless/mlme.c
+++ b/net/wireless/mlme.c
@@ -23,7 +23,6 @@ void cfg80211_send_rx_auth(struct net_device *dev, const u8 *buf, size_t len)
u8 *bssid = mgmt->bssid;
int i;
u16 status = le16_to_cpu(mgmt->u.auth.status_code);
- bool done = false;
wdev_lock(wdev);
@@ -38,13 +37,10 @@ void cfg80211_send_rx_auth(struct net_device *dev, const u8 *buf, size_t len)
cfg80211_put_bss(&wdev->authtry_bsses[i]->pub);
}
wdev->authtry_bsses[i] = NULL;
- done = true;
break;
}
}
- WARN_ON(!done);
-
nl80211_send_rx_auth(rdev, dev, buf, len, GFP_KERNEL);
cfg80211_sme_rx_auth(dev, buf, len);
--
1.5.6.3
^ permalink raw reply related
* Re: [RFC PATCH] mac80211: Add support for hardware ARP query filtering
From: Juuso Oikarinen @ 2010-05-26 11:14 UTC (permalink / raw)
To: ext Johannes Berg; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1274778802.3635.30.camel@jlt3.sipsolutions.net>
On Tue, 2010-05-25 at 11:13 +0200, ext Johannes Berg wrote:
> On Tue, 2010-05-25 at 10:48 +0300, Juuso Oikarinen wrote:
>
> You should get the right include too.
>
> > +static inline int drv_configure_ip_filter(struct ieee80211_hw *hw,
> > + struct in_ifaddr *ifa_list)
> > +{
> > + struct ieee80211_local *local = hw_to_local(hw);
> > + int ret = 0;
> > +
> > + if (local->ops->configure_ip_filter)
> > + ret = local->ops->configure_ip_filter(hw, ifa_list);
> > + return ret;
> > +}
>
> Tracing would be nice, you should even able able to trace all addresses
> in a variable-length array.
>
I looked into the tracing. I still prefer using the ifa_list directly as
argument to the driver, and not copy the addresses in it to another
array.
The ifa_list is a linked list, and does AFAIK does not directly fit into
the tracing infrasturcture.
Hence I added a trace for this op, but omitted tracing the IP addresses.
I will sent an RFC patch with this shortly.
-Juuso
> johannes
>
^ permalink raw reply
* Re: [RFC PATCH] mac80211: Add support for hardware ARP query filtering
From: Johannes Berg @ 2010-05-26 11:19 UTC (permalink / raw)
To: Juuso Oikarinen; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1274872467.5277.1783.camel@wimaxnb.nmp.nokia.com>
On Wed, 2010-05-26 at 14:14 +0300, Juuso Oikarinen wrote:
> > > +static inline int drv_configure_ip_filter(struct ieee80211_hw *hw,
> > > + struct in_ifaddr *ifa_list)
> > > +{
> > > + struct ieee80211_local *local = hw_to_local(hw);
> > > + int ret = 0;
> > > +
> > > + if (local->ops->configure_ip_filter)
> > > + ret = local->ops->configure_ip_filter(hw, ifa_list);
> > > + return ret;
> > > +}
> >
> > Tracing would be nice, you should even able able to trace all addresses
> > in a variable-length array.
> >
>
> I looked into the tracing. I still prefer using the ifa_list directly as
> argument to the driver, and not copy the addresses in it to another
> array.
>
> The ifa_list is a linked list, and does AFAIK does not directly fit into
> the tracing infrasturcture.
>
> Hence I added a trace for this op, but omitted tracing the IP addresses.
Yeah, that's fine ... it later occurred to me that I also left that out
for the multicast list for exactly this reason.
johannes
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox