* Re: 2.6.35-rc3: Reported regressions 2.6.33 -> 2.6.34
From: Luis R. Rodriguez @ 2010-06-21 18:32 UTC (permalink / raw)
To: linux-wireless, linux-bluetooth
Cc: Rafael J. Wysocki, reinette chatre, j, adobriyan, tj,
Satish Eerpini, Petr Pisar, Pavel Machek
In-Reply-To: <g77CuMUl7QI.A.qMH.4ZpHMB@chimera>
On Sun, Jun 20, 2010 at 3:32 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> This message contains a list of some post-2.6.33 regressions introduced before
> 2.6.34, for which there are no fixes in the mainline known to the tracking team.
> If any of them have been fixed already, please let us know.
>
> If you know of any other unresolved post-2.6.33 regressions, please let us know
> either and we'll add them to the list. Also, please let us know if any
> of the entries below are invalid.
>
> Each entry from the list will be sent additionally in an automatic reply to
> this message with CCs to the people involved in reporting and handling the
> issue.
>
>
> Listed regressions statistics:
>
> Date Total Pending Unresolved
> ----------------------------------------
> 2010-06-21 114 36 28
> 2010-06-13 111 40 34
> 2010-05-09 80 27 24
> 2010-05-04 76 26 22
> 2010-04-20 64 35 34
> 2010-04-07 48 35 33
> 2010-03-21 15 13 10
I'm going to just leave in the 802.11, Bluetooth and PCMCIA ones below:
> Unresolved regressions
> ----------------------
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16111
> Subject : hostap_pci: infinite registered netdevice wifi0
> Submitter : Petr Pisar <petr.pisar@atlas.cz>
> Date : 2010-06-02 20:55 (19 days old)
The last entry on this one says we are not sure how to fix this...
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16084
> Subject : iwl3945 bug in 2.6.34
> Submitter : Satish Eerpini <eerpini@gmail.com>
> Date : 2010-05-23 6:37 (29 days old)
> Message-ID : <AANLkTik_7rxDBc0TKlAfoYyM5S6Cf_Hyxbr4W5ORnTsq@mail.gmail.com>
> References : http://marc.info/?l=linux-kernel&m=127459596015626&w=2
This is getting some love by Reinette.
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15717
> Subject : bluetooth oops
> Submitter : Pavel Machek <pavel@ucw.cz>
> Date : 2010-03-14 20:14 (99 days old)
> Message-ID : <20100314201434.GE22059@elf.ucw.cz>
> References : http://marc.info/?l=linux-kernel&m=126859771528426&w=4
> Handled-By : Marcel Holtmann <marcel@holtmann.org>
Pavel, is this still happening or was just spurious on 2.6.34-rc1?
> Regressions with patches
> ------------------------
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16138
> Subject : PCMCIA regression
> Submitter : Mikulas Patocka <mpatocka@redhat.com>
> Date : 2010-05-25 20:25 (27 days old)
> Message-ID : <Pine.LNX.4.64.1005251619020.12278@hs20-bc2-1.build.redhat.com>
> References : http://marc.info/?l=linux-kernel&m=127481913909672&w=2
> Handled-By : Dominik Brodowski <linux@brodo.de>
> Patch : https://bugzilla.kernel.org/attachment.cgi?id=26685
Linville, are you to get PCMCIA stuff now? Anyway Rafael, please
remove this, this is fixed.
> For details, please visit the bug entries and follow the links given in
> references.
>
> As you can see, there is a Bugzilla entry for each of the listed regressions.
> There also is a Bugzilla entry used for tracking the regressions introduced
> between 2.6.33 and 2.6.34, unresolved as well as resolved, at:
>
> http://bugzilla.kernel.org/show_bug.cgi?id=15310
>
> Please let the tracking teak know if there are any Bugzilla entries that
> should be added to the list in there.
>
> Thanks!
>
> --
> 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: [PATCH] mac80211: allow selection of minstrel_ht as default rc algo
From: Luis R. Rodriguez @ 2010-06-21 18:37 UTC (permalink / raw)
To: Helmut Schaa; +Cc: John Linville, linux-wireless, Johannes Berg, Felix Fietkau
In-Reply-To: <201006211059.58879.helmut.schaa@googlemail.com>
On Mon, Jun 21, 2010 at 1:59 AM, Helmut Schaa
<helmut.schaa@googlemail.com> wrote:
> Allow selection of minstrel_ht as default rate control algorithm. At the
> moment minstrel_ht can only be requested by the driver code but not selected
> as default in make menuconfig.
>
> Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
Shouldn't this just be enabled when you enable minstrel? I don't get
why we would split up the two.
Luis
^ permalink raw reply
* Re: [PATCH 2/2] wl1251: fix ELP_CTRL register reads
From: Denis 'GNUtoo' Carikli @ 2010-06-21 18:45 UTC (permalink / raw)
To: Bob Copeland
Cc: Kalle Valo, Grazvydas Ignotas, John W.Linville, linux-wireless
In-Reply-To: <AANLkTimLKDqDn_97BbOYr1cdxbFdPvyTz_lxJ59LVJ1b@mail.gmail.com>
On Mon, 2010-06-21 at 13:54 -0400, Bob Copeland wrote:
> On Mon, Jun 21, 2010 at 8:46 AM, Denis 'GNUtoo' Carikli
> <GNUtoo@no-log.org> wrote:
>
> > Hi, me and some other people are trying to run standard GNU/Linux (not
> > android ) on the htcdream.
>
> > [ 1556.425354] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
> > [ 1556.734130] mmc0: Command timeout
>
> In this case it was only up for 1/3 second before it quit
> responding to reads. With power saving disabled it works?
In this case I think only some command timeout(If I remember well it
worked for a bit and then stopped working)
But I'm sure that you can ping with the command timeout and have some
transfers etc...
With power saving disabled it works fine,until the battery goes out.
Disabling power saving also stop the flow of timeout messages...
> Probably not relevant to power saving, but:
>
> Are you using the dedicated irq line or sdio interrupt?
> It makes a big difference in overall throughput to use
> the former.
I don't know. what should I grep for?
> > + /*
> > + * FIXME: scanning while associated causes lockups,
> > + * so we don't allow that
> > + */
> > + if (wl->associated)
> > + return -EBUSY;
>
> Any idea why? Could you turn on lockdep?
No I just used the patches that weren't mine
I took them from openpandora wireless repository,looked if they were
already included,and include the one that weren't.
Denis.
^ permalink raw reply
* Re: 2.6.35-rc3: Reported regressions from 2.6.34
From: Luis R. Rodriguez @ 2010-06-21 18:49 UTC (permalink / raw)
To: linux-wireless, linux-bluetooth; +Cc: Rafael J. Wysocki, reinette chatre
In-Reply-To: <lc60d4toGTL.A.QzD._LpHMB@chimera>
On Sun, Jun 20, 2010 at 3:11 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> This message contains a list of some regressions from 2.6.34,
> for which there are no fixes in the mainline known to the tracking team.
> If any of them have been fixed already, please let us know.
>
> If you know of any other unresolved regressions from 2.6.34, please let us
> know either and we'll add them to the list. Also, please let us know
> if any of the entries below are invalid.
>
> Each entry from the list will be sent additionally in an automatic reply
> to this message with CCs to the people involved in reporting and handling
> the issue.
>
>
> Listed regressions statistics:
>
> Date Total Pending Unresolved
> ----------------------------------------
> 2010-06-21 46 37 26
> 2010-06-09 15 13 10
Leaving only the 802.11, and Bluetooth (none) ones:
> Unresolved regressions
> ----------------------
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16235
> Subject : [REGRESSION] [IWL3945] Broadcast is broken?
> Submitter : Maciej Rutecki <maciej.rutecki@gmail.com>
> Date : 2010-06-14 17:24 (7 days old)
> Message-ID : <201006141924.24061.maciej.rutecki@gmail.com>
> References : http://marc.info/?l=linux-kernel&m=127653628301300&w=2
As noted by Maxim, the fix is in some Intel tree, but not upstream yet
(if so why ?)
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16232
> Subject : 2.6.35-rc3 - WARNING:iwl_set_dynamic_key
> Submitter : Mario Guenterberg <mario.guenterberg@googlemail.com>
> Date : 2010-06-14 11:55 (7 days old)
> Message-ID : <20100614115510.GA7904@guenti-laptop>
> References : http://marc.info/?l=linux-kernel&m=127651695627147&w=2
Rafael, this one actually has a supplied patch by Reinette and she's
waiting on the user.
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16201
> Subject : SIOCGIWFREQ ioctl fails to get frequency info
> Submitter : nuh <nuh@mailinator.net>
> Date : 2010-06-14 10:45 (7 days old)
John is waiting on some user sample code to reproduce.
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16176
> Subject : Microcode errors with iwl3945
> Submitter : Steinar H. Gunderson <sgunderson@bigfoot.com>
> Date : 2010-06-10 19:28 (11 days old)
One issue replaced with another, but the microcode issues seems to be
fixed now on rc3.
> Regressions with patches
> ------------------------
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16196
> Subject : 2.6.35-rc2-git1 - WARNING: at net/wireless/mlme.c:341 cfg80211_send_assoc_timeout+0x107/0x11e [cfg80211]()
> Submitter : Miles Lane <miles.lane@gmail.com>
> Date : 2010-06-07 19:06 (14 days old)
> Message-ID : <AANLkTinmZh9GnrZLzOGi5Q_xHbky8cKdHAkOnsIA6_dZ@mail.gmail.com>
> References : http://marc.info/?l=linux-kernel&m=127593758817428&w=2
> Handled-By : Johannes Berg <johannes.berg@intel.com>
> Patch : http://marc.info/?l=linux-wireless&m=127608099427316&w=2
Patch confirmed to work.
> For details, please visit the bug entries and follow the links given in
> references.
>
> As you can see, there is a Bugzilla entry for each of the listed regressions.
> There also is a Bugzilla entry used for tracking the regressions from 2.6.34,
> unresolved as well as resolved, at:
>
> http://bugzilla.kernel.org/show_bug.cgi?id=16055
>
> Please let the tracking team know if there are any Bugzilla entries that
> should be added to the list in there.
>
> Thanks!
>
> --
> 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: 2.6.35-rc3: Reported regressions from 2.6.34
From: Rafael J. Wysocki @ 2010-06-21 18:54 UTC (permalink / raw)
To: Maxim Levitsky
Cc: Linux Kernel Mailing List, Maciej Rutecki, Andrew Morton,
Linus Torvalds, Kernel Testers List, Network Development,
Linux ACPI, Linux PM List, Linux SCSI List, Linux Wireless List,
DRI
In-Reply-To: <1277074706.21312.8.camel@maxim-laptop>
On Monday, June 21, 2010, Maxim Levitsky wrote:
> On Mon, 2010-06-21 at 00:11 +0200, Rafael J. Wysocki wrote:
> > This message contains a list of some regressions from 2.6.34,
> > for which there are no fixes in the mainline known to the tracking team.
> > If any of them have been fixed already, please let us know.
> >
> > If you know of any other unresolved regressions from 2.6.34, please let us
> > know either and we'll add them to the list. Also, please let us know
> > if any of the entries below are invalid.
> >
> > Each entry from the list will be sent additionally in an automatic reply
> > to this message with CCs to the people involved in reporting and handling
> > the issue.
> >
> >
> > Listed regressions statistics:
> >
> > Date Total Pending Unresolved
> > ----------------------------------------
> > 2010-06-21 46 37 26
> > 2010-06-09 15 13 10
> >
> >
> > Unresolved regressions
> > ----------------------
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16255
> > Subject : 2.6.35-rc3 deadlocks on semaphore operations
> > Submitter : Christoph Lameter <cl@linux-foundation.org>
> > Date : 2010-06-18 14:49 (3 days old)
> > Message-ID : <alpine.DEB.2.00.1006180940140.11575@router.home>
> > References : http://marc.info/?l=linux-kernel&m=127687262727707&w=2
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16248
> > Subject : inconsistent lock state
> > Submitter : Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
> > Date : 2010-06-15 11:24 (6 days old)
> > Message-ID : <20100615112434.GA3967@swordfish.minsk.epam.com>
> > References : http://marc.info/?l=linux-kernel&m=127660087625903&w=2
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16247
> > Subject : drm/i915 BUG with 2.6.35-rc
> > Submitter : Benny Halevy <bhalevy@panasas.com>
> > Date : 2010-06-14 22:38 (7 days old)
> > Message-ID : <4C16AF56.1040002@panasas.com>
> > References : http://marc.info/?l=linux-kernel&m=127655510531367&w=2
>
>
> Don't have time to test, but I confirm that running compiz without
> mode-setting (ubuntu 8.10) hangs the system. (device is i945)
> It might be related to few intel regressions on this list.
>
>
>
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16235
> > Subject : [REGRESSION] [IWL3945] Broadcast is broken?
> > Submitter : Maciej Rutecki <maciej.rutecki@gmail.com>
> > Date : 2010-06-14 17:24 (7 days old)
> > Message-ID : <201006141924.24061.maciej.rutecki@gmail.com>
> > References : http://marc.info/?l=linux-kernel&m=127653628301300&w=2
> I was hit by this bug. Fix is now present in iwlwifi tree.
> http://git.kernel.org/?p=linux/kernel/git/iwlwifi/iwlwifi-2.6.git;a=commit;h=4d23e4e5eb50431426facf192354ad2506e2dd40
>
>
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16234
> > Subject : [2.6.35-rc3] reboot mutex 'bug'...
> > Submitter : Daniel J Blueman <daniel.blueman@gmail.com>
> > Date : 2010-06-14 15:16 (7 days old)
> > Message-ID : <AANLkTimDcTnyEPmt2ZcCM1UWtn4AYKotiqyjobJApkO7@mail.gmail.com>
> > References : http://marc.info/?l=linux-kernel&m=127652861118933&w=2
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16232
> > Subject : 2.6.35-rc3 - WARNING:iwl_set_dynamic_key
> > Submitter : Mario Guenterberg <mario.guenterberg@googlemail.com>
> > Date : 2010-06-14 11:55 (7 days old)
> > Message-ID : <20100614115510.GA7904@guenti-laptop>
> > References : http://marc.info/?l=linux-kernel&m=127651695627147&w=2
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16230
> > Subject : inconsistent IN-HARDIRQ-W -> HARDIRQ-ON-W usage: fasync, 2.6.35-rc3
> > Submitter : Dominik Brodowski <linux@dominikbrodowski.net>
> > Date : 2010-06-13 9:53 (8 days old)
> > Message-ID : <20100613095305.GA13231@comet.dominikbrodowski.net>
> > References : http://marc.info/?l=linux-kernel&m=127642282208277&w=2
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16228
> > Subject : BUG/boot failure on Dell Precision T3500 (pci/ahci_stop_engine)
> > Submitter : Brian Bloniarz <phunge0@hotmail.com>
> > Date : 2010-06-16 17:57 (5 days old)
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16222
> > Subject : 2.6.35-rc{12} regression: inactive console corrupted
> > Submitter : Pavel Machek <pavel@ucw.cz>
> > Date : 2010-06-12 10:33 (9 days old)
> > Message-ID : <20100612103321.GA1458@ucw.cz>
> > References : http://marc.info/?l=linux-kernel&m=127633882614501&w=2
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16221
> > Subject : 2.6.35-rc2-git5 -- [drm:drm_mode_getfb] *ERROR* invalid framebuffer id
> > Submitter : Miles Lane <miles.lane@gmail.com>
> > Date : 2010-06-11 20:31 (10 days old)
> > Message-ID : <AANLkTim0jVRyqkwlGOcrg_XTvUQwcBYfWJX-aRzkkrLG@mail.gmail.com>
> > References : http://marc.info/?l=linux-kernel&m=127628828119623&w=2
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16205
> > Subject : acpi: freeing invalid memtype bf799000-bf79a000
> > Submitter : Marcin Slusarz <marcin.slusarz@gmail.com>
> > Date : 2010-06-09 20:09 (12 days old)
> > Message-ID : <20100609200910.GA2876@joi.lan>
> > References : http://marc.info/?l=linux-kernel&m=127611427029914&w=2
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16201
> > Subject : SIOCGIWFREQ ioctl fails to get frequency info
> > Submitter : nuh <nuh@mailinator.net>
> > Date : 2010-06-14 10:45 (7 days old)
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16199
> > Subject : 2.6.35-rc2-git1 - include/linux/cgroup.h:534 invoked rcu_dereference_check() without protection!
> > Submitter : Miles Lane <miles.lane@gmail.com>
> > Date : 2010-06-07 18:14 (14 days old)
> > Message-ID : <AANLkTin2pPqOUx--9fIX3BH3e-cU6oCRufijcx_4ozx5@mail.gmail.com>
> > References : http://marc.info/?l=linux-kernel&m=127593447812015&w=2
> >
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16198
> > Subject : Running make install over sshfs is painful now
> > Submitter : Dmitry Torokhov <dmitry.torokhov@gmail.com>
> > Date : 2010-06-07 6:53 (14 days old)
> > Message-ID : <20100607065324.GA25590@core.coreip.homeip.net>
> > References : http://marc.info/?l=linux-kernel&m=127589362011138&w=2
> I confirm this.
> Its direct result of adding '+' to kernel version.
> This just causes only troubles.
> I suggest to have a config option for it.
Thanks for the updates.
Rafael
^ permalink raw reply
* Re: 2.6.35-rc3: Reported regressions from 2.6.34
From: Rafael J. Wysocki @ 2010-06-21 18:56 UTC (permalink / raw)
To: Nick Bowler
Cc: Linux Kernel Mailing List, Maciej Rutecki, Andrew Morton,
Linus Torvalds, Kernel Testers List, Network Development,
Linux ACPI, Linux PM List, Linux SCSI List, Linux Wireless List,
DRI
In-Reply-To: <20100621135857.GA21159@elliptictech.com>
On Monday, June 21, 2010, Nick Bowler wrote:
> On 00:11 Mon 21 Jun , Rafael J. Wysocki wrote:
> > If you know of any other unresolved regressions from 2.6.34, please let us
> > know either and we'll add them to the list. Also, please let us know
> > if any of the entries below are invalid.
>
> Didn't see this one in the list:
>
> Why is kslowd accumulating so much CPU time?
> http://thread.gmane.org/gmane.linux.kernel/996907
Thanks, I'm going to add it to the list.
Rafael
^ permalink raw reply
* Re: [PATCH] compat-wireless: fix compilation for 2.6.32
From: Luis R. Rodriguez @ 2010-06-21 19:01 UTC (permalink / raw)
To: Paul Fertser; +Cc: Luis R. Rodriguez, linux-wireless
In-Reply-To: <1277027097-3222-1-git-send-email-fercerpav@gmail.com>
On Sun, Jun 20, 2010 at 2:44 AM, Paul Fertser <fercerpav@gmail.com> wrote:
> 2.6.32 was the latest version using CONFIG_WIRELESS_EXT. Without this patch
> compilation produced
>
> net/wireless/wext-compat.c:443: error: ‘struct wireless_dev’ has no member named ‘wext’
>
> since config.mk defined CONFIG_CFG80211_WEXT but autoconf.sh didn't.
>
> Signed-off-by: Paul Fertser <fercerpav@gmail.com>
Awesome thanks, applied and I propagated this to the linux-2.6.35.y branch too.
Luis
^ permalink raw reply
* Compat-wireless release for 2010-06-21 is baked
From: Compat-wireless cronjob account @ 2010-06-21 19:03 UTC (permalink / raw)
To: linux-wireless, linux-bluetooth
>From git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next
49bc196..fd729ff history -> origin/history
+ d568ec36...13f4704 master -> origin/master (forced update)
* [new tag] next-20100621 -> next-20100621
compat-wireless code metrics
498479 - Total upstream lines of code being pulled
1410 - backport code changes
1177 - backport code additions
233 - backport code deletions
5748 - backport from compat module
7158 - total backport code
1.4360 - % of code consists of backport work
1218 - Crap changes not yet posted
1179 - Crap additions not yet merged
39 - Crap deletions not yet posted
0.2443 - % of crap code
Base tree: linux-next.git
Base tree version: next-20100621
compat-wireless release: compat-wireless-2010-06-17-1-g75bb510
^ permalink raw reply
* Re: wireless-regdb: Add A band in IL - And general point regarding tx power limits in the dbase
From: Johannes Berg @ 2010-06-21 19:15 UTC (permalink / raw)
To: Michael Green
Cc: John W. Linville, linux-wireless@vger.kernel.org, David Quan,
Emmanuel Grumbach
In-Reply-To: <93781E992CBA7843962D8B0E7D683F3C1172BD0B6D@SC1EXMB-MBCL.global.atheros.com>
On Mon, 2010-06-21 at 07:51 -0700, Michael Green wrote:
> b) I think all entries in the dbase should be in dBm (not mW). dBm
> vs. mW are absolutely equivalent. No reason to retain "mW" unit from
> the source docs. I think this was agreed by all before, but wanted to
> reiterate.
Why? The tools automatically convert one into the other as required, so
if the source documents state mW it is _much_ easier to retain it for
future review. Hence I think it should be retained. As you say, it's
absolutely equivalent, so there's no reason _not_ to retain it as in the
source.
johannes
^ permalink raw reply
* Re: [PATCH] mac80211: allow selection of minstrel_ht as default rc algo
From: Helmut Schaa @ 2010-06-21 19:18 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: John Linville, linux-wireless, Johannes Berg, Felix Fietkau
In-Reply-To: <AANLkTinj36oA6QpEiYywGGkRqCmNRHSeR643HpiUsXC-@mail.gmail.com>
Am Montag 21 Juni 2010 schrieb Luis R. Rodriguez:
> On Mon, Jun 21, 2010 at 1:59 AM, Helmut Schaa
> <helmut.schaa@googlemail.com> wrote:
> > Allow selection of minstrel_ht as default rate control algorithm. At the
> > moment minstrel_ht can only be requested by the driver code but not selected
> > as default in make menuconfig.
> >
> > Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
>
> Shouldn't this just be enabled when you enable minstrel? I don't get
> why we would split up the two.
Would be fine for me as well. But I'm not sure if we want minstrel_ht already
as default and we want definitely keep the possibility to only select minstrel
(if compiling on an embedded system with just bg wifi for example).
Felix, any objections against selecting minstrel_ht as default if minstrel
was selected as default rc algo and minstrel_ht is compiled in?
In case of an embedded system without minstrel_ht minstrel would stay as default.
diff --git a/net/mac80211/Kconfig b/net/mac80211/Kconfig
index 83eec7a..4d6f865 100644
--- a/net/mac80211/Kconfig
+++ b/net/mac80211/Kconfig
@@ -69,6 +69,7 @@ endchoice
config MAC80211_RC_DEFAULT
string
+ default "minstrel_ht" if MAC80211_RC_DEFAULT_MINSTREL && MAC80211_RC_MINSTREL_HT
default "minstrel" if MAC80211_RC_DEFAULT_MINSTREL
default "pid" if MAC80211_RC_DEFAULT_PID
default ""
Thanks,
Helmut
^ permalink raw reply related
* Re: ATH5k - Signal measurement reports wrong values
From: Jaroslav Fojtik @ 2010-06-21 19:28 UTC (permalink / raw)
To: linux-wireless; +Cc: Bruno Randolf
In-Reply-To: <201006211650.50766.br1@einfach.org>
Dear Bruno,
> that would make more sense. there are changes in noise floor calibration and
> in antenna diversity setup between these two (2010-05-30 and 2010-06-18).
> either one may be the reason...
good
> > The directory /sys/kernel/debug is empty.
> > It looks that I have to recompile kernel. Or do you know any option to
> > pass to kernel to allow this feature?
>
> maybe you need to:
> mount -t debugfs debugfs /sys/kernel/debug
> ?
>
> also you need to compile ath5k with debugging enabled.
I will do this.
> can you tell us which chipset you are using (output of dmesg |grep
> "ath5.*chip")?
root@dvouramenna:~# dmesg |grep "ath5.*chip"
[ 6.632843] ath5k phy0: Atheros AR2413 chip found (MAC: 0x78, PHY: 0x45)
[ 7.101528] ath5k phy1: Atheros AR5213A chip found (MAC: 0x59, PHY: 0x43)
Both chipsets suffer with a same problem.
> also it would be interesting to know how you generate your graphs?
RODGASIGNAL=`iwconfig wlan0 | grep "Signal level" | sed -e 's/.*Signal level=\([0123456789-]*\)[ \/].*/\1/'`
if [[ $RODGASIGNAL == "" ]]; then
RODGASIGNAL="U"
else
if [[ $RODGASIGNAL > "0" ]]; then
RODGASIGNAL=-95
fi
fi
/usr/sbin/rrdupdate /var/rrd/rodgarssi.rrd N:$RODGASIGNAL
When rrd is feed, the chart could be rendered:
LABEL=`/usr/bin/date "+Rodga signal strength %d.%m.%Y"`
/usr/sbin/rrdtool graph /tmp/www/rodga-day.png --start -86400 \
-t "$LABEL" --vertical-label "Signal Strength [dBi]" -w 650 -h 95 \
DEF:rodga=/var/rrd/rodgarssi.rrd:rssi:AVERAGE \
DEF:bullet=/var/rrd/bulletrssi.rrd:rssi:AVERAGE \
LINE1:rodga#FF00FF:"rodga->dvrmn" \
LINE1:bullet#00FF00:"dvrmn->rodga" >/dev/null
regards
Jara
PS: I have replaced MAC address by 0:
/usr/sbin/iw wlan1 station dump | sed -n -e '/Station/p' -e '/signal/p' >/tmp/sta.txt
MARTIN=`grep "00:00:00:00:00:00" -A 1 -i /tmp/sta.txt | grep "signal" | sed -e 's/.*\(-[0123456789]*\) .*/\1/'`
if [[ $MARTIN == "" ]]
then
MARTIN="U"
fi
RACEK=`grep "00:00:00:00:00:00" -A 1 -i /tmp/sta.txt | grep "signal" | sed -e 's/.*\(-[0123456789]*\) .*/\1/'`
if [[ $RACEK == "" ]]
then
RACEK="U"
fi
/usr/sbin/rrdupdate /var/rrd/klienti.rrd N:$MARTIN:$RACEK
^ permalink raw reply
* Re: [PATCH] mac80211: allow selection of minstrel_ht as default rc algo
From: Felix Fietkau @ 2010-06-21 19:26 UTC (permalink / raw)
To: Helmut Schaa
Cc: Luis R. Rodriguez, John Linville, linux-wireless, Johannes Berg
In-Reply-To: <201006212118.06767.helmut.schaa@googlemail.com>
On 2010-06-21 9:18 PM, Helmut Schaa wrote:
> Am Montag 21 Juni 2010 schrieb Luis R. Rodriguez:
>> On Mon, Jun 21, 2010 at 1:59 AM, Helmut Schaa
>> <helmut.schaa@googlemail.com> wrote:
>> > Allow selection of minstrel_ht as default rate control algorithm. At the
>> > moment minstrel_ht can only be requested by the driver code but not selected
>> > as default in make menuconfig.
>> >
>> > Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
>>
>> Shouldn't this just be enabled when you enable minstrel? I don't get
>> why we would split up the two.
>
> Would be fine for me as well. But I'm not sure if we want minstrel_ht already
> as default and we want definitely keep the possibility to only select minstrel
> (if compiling on an embedded system with just bg wifi for example).
>
> Felix, any objections against selecting minstrel_ht as default if minstrel
> was selected as default rc algo and minstrel_ht is compiled in?
>
> In case of an embedded system without minstrel_ht minstrel would stay as default.
>
> diff --git a/net/mac80211/Kconfig b/net/mac80211/Kconfig
> index 83eec7a..4d6f865 100644
> --- a/net/mac80211/Kconfig
> +++ b/net/mac80211/Kconfig
> @@ -69,6 +69,7 @@ endchoice
>
> config MAC80211_RC_DEFAULT
> string
> + default "minstrel_ht" if MAC80211_RC_DEFAULT_MINSTREL && MAC80211_RC_MINSTREL_HT
> default "minstrel" if MAC80211_RC_DEFAULT_MINSTREL
> default "pid" if MAC80211_RC_DEFAULT_PID
> default ""
Looks good, I think we should do it this way.
- Felix
^ permalink raw reply
* Re: [RFC PATCHv2 1/2] cfg80211/mac80211: Update set_tx_power to use mBm instead of dBm units
From: Jussi Kivilinna @ 2010-06-21 19:31 UTC (permalink / raw)
To: Juuso Oikarinen; +Cc: linux-wireless, Samuel Ortiz
In-Reply-To: <1277116766-4764-1-git-send-email-juuso.oikarinen@nokia.com>
Quoting "Juuso Oikarinen" <juuso.oikarinen@nokia.com>:
> In preparation for a TX power setting interface in the nl80211, change the
> .set_tx_power function to use mBm units instead of dBm for greater
> accuracy and
> smaller power levels.
>
> Also, already in advance move the tx_power_setting enumeration to nl80211.
>
> This change affects the .tx_set_power function prototype. As a result, the
> corresponding changes are needed to modules using it. These are mac80211,
> iwmc3200wifi and rndis_wlan.
rndis_wlan part:
Acked-by: Jussi Kivilinna <jussi.kivilinna@mbnet.fi>
-Jussi
^ permalink raw reply
* Re: wireless-regdb: Add A band in IL - And general point regarding tx power limits in the dbase
From: Luis R. Rodriguez @ 2010-06-21 19:40 UTC (permalink / raw)
To: Johannes Berg
Cc: Michael Green, John W. Linville, linux-wireless@vger.kernel.org,
David Quan, Emmanuel Grumbach
In-Reply-To: <1277147731.3635.12.camel@jlt3.sipsolutions.net>
On Mon, Jun 21, 2010 at 12:15 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Mon, 2010-06-21 at 07:51 -0700, Michael Green wrote:
>
>> b) I think all entries in the dbase should be in dBm (not mW). dBm
>> vs. mW are absolutely equivalent. No reason to retain "mW" unit from
>> the source docs. I think this was agreed by all before, but wanted to
>> reiterate.
>
> Why? The tools automatically convert one into the other as required, so
> if the source documents state mW it is _much_ easier to retain it for
> future review. Hence I think it should be retained. As you say, it's
> absolutely equivalent, so there's no reason _not_ to retain it as in the
> source.
I think the concern is not that but the other way around -- checking
db.txt against some internal docs which already have stuff in dBm. So
how about a simple solution: we write a script which parses db.txt and
gives you all entries in either format?
Luis
^ permalink raw reply
* Re: [ath5k-devel] [PATCH v2] ath5k: disable ASPM
From: Jussi Kivilinna @ 2010-06-21 20:01 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Maxim Levitsky, David Quan, Bob Copeland, Luis R. Rodriguez,
ath5k-devel, linux-wireless, linux-kernel
In-Reply-To: <AANLkTim8iZmm8pEERJUsrQWOiLSjPUfCN-TFFzZZQWx2@mail.gmail.com>
Quoting "Luis R. Rodriguez" <mcgrof@gmail.com>:
>> Also Jussi Kivilinna said that he found that in windows .inf file there
>> are some instructions to enable L1 but not L0s.
>
> For which chipsets?
I uploaded windows driver I have to:
http://www.student.oulu.fi/~jukivili/ath5k/XP32_XP64_WHQL_Dri-7-6-1-149_ACU-7-0-2-48_LEAP_Acer_81024
In inf, all ASPM entries are either ASPM off or ASPM L0s:off/L1:on.
There is also user option for changing ASPM setting with options
L0s:off/L1:off and L0s:off/L1:on.
-Jussi
^ permalink raw reply
* Re: [ath5k-devel] [PATCH v2] ath5k: disable ASPM
From: Maxim Levitsky @ 2010-06-21 20:16 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: David Quan, Bob Copeland, Luis R. Rodriguez, Jussi Kivilinna,
ath5k-devel, linux-wireless, linux-kernel
In-Reply-To: <AANLkTim8iZmm8pEERJUsrQWOiLSjPUfCN-TFFzZZQWx2@mail.gmail.com>
Luis, let me explain again, exactly the situation:
First of all AR5001 and AR5001X devices (former was usualy listed as
AR2425, and I have it, later I don't know about much), don't work well
with ASPM L0s enabled.
I told that many times, but I tell again.
As soon as card it put on medium to high transmit load
(for example even if transmission consists mostly of TCP ACK packets),
it dies.
Usualy it will stop transmitting, and then after few seconds it will
send RXORN intrrupt to the host, even though the channel was idle.
(Tested by sending a stream of UDP packets on channel that is neighbor
free).
I didn't see it, but some users reported seeing jumbo frames at this
time as well.
Overall it doesn't matter because card just goes south.
A reset sometimes brings card to life, sometimes causes another storm of
RXORN and sometimes just results in quiet dead card.
A next reset might bring it to life, or not.
Card (at least mine) advertises its as a 'pre pci 1.1 device'.
Therefore if I enable CONFIG_PCIEASPM, the pci core will automaticly
disable ASPM (both L0s and L1) on this card.
I won't be surprised that windows does the same.
Therefore the patch I sent it useless because it only works when
CONFIG_PCIEASPM is enabled.
In addition to that using the original version of this patch from Jussi
Kivilinna contains code that disables ASPM (I modified it to disable
only L0s) with or without CONFIG_PCIEASPM.
But without CONFIG_PCIEASPM it uses open coded function that should
belong to pci core.
And it is also copied from e1000 which shouldn't do that too.
Best regards,
Maxim Levitsky
^ permalink raw reply
* Re: [ath5k-devel] [PATCH v2] ath5k: disable ASPM
From: Jussi Kivilinna @ 2010-06-21 20:33 UTC (permalink / raw)
To: Maxim Levitsky
Cc: Luis R. Rodriguez, David Quan, Bob Copeland, Luis R. Rodriguez,
ath5k-devel, linux-wireless, linux-kernel
In-Reply-To: <1277151410.5409.33.camel@maxim-laptop>
Quoting "Maxim Levitsky" <maximlevitsky@gmail.com>:
> Card (at least mine) advertises its as a 'pre pci 1.1 device'.
> Therefore if I enable CONFIG_PCIEASPM, the pci core will automaticly
> disable ASPM (both L0s and L1) on this card.
> I won't be surprised that windows does the same.
>
Even if CONFIG_PCIEASPM compiled in, ASPM code can be disabled by user
with pcie_aspm=off option, leaving BIOS-enabled L0s on.
-Jussi
^ permalink raw reply
* Re: [ath5k-devel] [PATCH v2] ath5k: disable ASPM
From: Luis R. Rodriguez @ 2010-06-21 20:37 UTC (permalink / raw)
To: Maxim Levitsky
Cc: David Quan, Bob Copeland, Luis R. Rodriguez, Jussi Kivilinna,
ath5k-devel, linux-wireless, linux-kernel, Jonathan May
In-Reply-To: <1277151410.5409.33.camel@maxim-laptop>
On Mon, Jun 21, 2010 at 1:16 PM, Maxim Levitsky <maximlevitsky@gmail.com> wrote:
> Luis, let me explain again, exactly the situation:
>
> First of all AR5001 and AR5001X devices (former was usualy listed as
> AR2425, and I have it, later I don't know about much), don't work well
> with ASPM L0s enabled.
Thanks for the clarification. David, do you see this as well on your end?
> I told that many times, but I tell again.
> As soon as card it put on medium to high transmit load
> (for example even if transmission consists mostly of TCP ACK packets),
> it dies.
>
> Usualy it will stop transmitting, and then after few seconds it will
> send RXORN intrrupt to the host, even though the channel was idle.
> (Tested by sending a stream of UDP packets on channel that is neighbor
> free).
>
> I didn't see it, but some users reported seeing jumbo frames at this
> time as well.
> Overall it doesn't matter because card just goes south.
>
> A reset sometimes brings card to life, sometimes causes another storm of
> RXORN and sometimes just results in quiet dead card.
> A next reset might bring it to life, or not.
>
> Card (at least mine) advertises its as a 'pre pci 1.1 device'.
> Therefore if I enable CONFIG_PCIEASPM, the pci core will automaticly
> disable ASPM (both L0s and L1) on this card.
> I won't be surprised that windows does the same.
I am not sure when L0s was enabled as per the spec as mandatory, I
thought it was optional. Interesting to hear this behavior on Linux
with CONFIG_PCIEASPM. That Kconfig description and code really need
some spit shining.
> Therefore the patch I sent it useless because it only works when
> CONFIG_PCIEASPM is enabled.
How so ? Your patch disables L0s, I can use ASPM with L0s and L1 with
or without CONFIG_PCIEASPM. If I added your calls to ath9k I would
disable L0s.
Luis
^ permalink raw reply
* Re: [ath5k-devel] [PATCH v2] ath5k: disable ASPM
From: Luis R. Rodriguez @ 2010-06-21 20:39 UTC (permalink / raw)
To: Jussi Kivilinna
Cc: Maxim Levitsky, David Quan, Bob Copeland, Luis R. Rodriguez,
ath5k-devel, linux-wireless, linux-kernel
In-Reply-To: <20100621233333.21262abjfxl8j1xc@hayate.sektori.org>
On Mon, Jun 21, 2010 at 1:33 PM, Jussi Kivilinna
<jussi.kivilinna@mbnet.fi> wrote:
> Quoting "Maxim Levitsky" <maximlevitsky@gmail.com>:
>
>> Card (at least mine) advertises its as a 'pre pci 1.1 device'.
>> Therefore if I enable CONFIG_PCIEASPM, the pci core will automaticly
>> disable ASPM (both L0s and L1) on this card.
>> I won't be surprised that windows does the same.
>>
>
> Even if CONFIG_PCIEASPM compiled in, ASPM code can be disabled by user with
> pcie_aspm=off option, leaving BIOS-enabled L0s on.
Last I reviewed CONFIG_PCIEASPM won't buy you *anything* other than
debugging knobs. With it you can force all devices to enable ASPM
completely on or disable it. Both of which I think are not really
useful and instead should be done in userspace given that if you are
testing ASPM you likely want to test only one one device and its
respective root complex, not all at the same time.
Luis
^ permalink raw reply
* [PATCH] mac80211: avoid scheduling while atomic in mesh_rx_plink_frame
From: John W. Linville @ 2010-06-21 21:09 UTC (permalink / raw)
To: linux-wireless
Cc: Javier Cardona, Andrey Yurovsky, Gertjan van Wingerde,
Ivo van Doorn, John W. Linville
While mesh_rx_plink_frame holds sta->lock...
mesh_rx_plink_frame ->
mesh_plink_inc_estab_count ->
ieee80211_bss_info_change_notify
...but ieee80211_bss_info_change_notify is allowed to sleep. A driver
taking advantage of that allowance can cause a scheduling while
atomic bug. Similar paths exist for mesh_plink_dec_estab_count,
so work around those as well.
http://bugzilla.kernel.org/show_bug.cgi?id=16099
Also, correct a minor kerneldoc comment error (mismatched function names).
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
net/mac80211/mesh_plink.c | 39 +++++++++++++++++++++++++++++----------
1 files changed, 29 insertions(+), 10 deletions(-)
diff --git a/net/mac80211/mesh_plink.c b/net/mac80211/mesh_plink.c
index 3cd5f7b..350f9a8 100644
--- a/net/mac80211/mesh_plink.c
+++ b/net/mac80211/mesh_plink.c
@@ -73,7 +73,6 @@ void mesh_plink_dec_estab_count(struct ieee80211_sub_if_data *sdata)
{
atomic_dec(&sdata->u.mesh.mshstats.estab_plinks);
mesh_accept_plinks_update(sdata);
- ieee80211_bss_info_change_notify(sdata, BSS_CHANGED_BEACON);
}
/**
@@ -115,7 +114,7 @@ static struct sta_info *mesh_plink_alloc(struct ieee80211_sub_if_data *sdata,
}
/**
- * mesh_plink_deactivate - deactivate mesh peer link
+ * __mesh_plink_deactivate - deactivate mesh peer link
*
* @sta: mesh peer link to deactivate
*
@@ -123,18 +122,23 @@ static struct sta_info *mesh_plink_alloc(struct ieee80211_sub_if_data *sdata,
*
* Locking: the caller must hold sta->lock
*/
-static void __mesh_plink_deactivate(struct sta_info *sta)
+static bool __mesh_plink_deactivate(struct sta_info *sta)
{
struct ieee80211_sub_if_data *sdata = sta->sdata;
+ bool deactivated = false;
- if (sta->plink_state == PLINK_ESTAB)
+ if (sta->plink_state == PLINK_ESTAB) {
mesh_plink_dec_estab_count(sdata);
+ deactivated = true;
+ }
sta->plink_state = PLINK_BLOCKED;
mesh_path_flush_by_nexthop(sta);
+
+ return deactivated;
}
/**
- * __mesh_plink_deactivate - deactivate mesh peer link
+ * mesh_plink_deactivate - deactivate mesh peer link
*
* @sta: mesh peer link to deactivate
*
@@ -142,9 +146,15 @@ static void __mesh_plink_deactivate(struct sta_info *sta)
*/
void mesh_plink_deactivate(struct sta_info *sta)
{
+ struct ieee80211_sub_if_data *sdata = sta->sdata;
+ bool deactivated;
+
spin_lock_bh(&sta->lock);
- __mesh_plink_deactivate(sta);
+ deactivated = __mesh_plink_deactivate(sta);
spin_unlock_bh(&sta->lock);
+
+ if (deactivated)
+ ieee80211_bss_info_change_notify(sdata, BSS_CHANGED_BEACON);
}
static int mesh_plink_frame_tx(struct ieee80211_sub_if_data *sdata,
@@ -381,10 +391,16 @@ int mesh_plink_open(struct sta_info *sta)
void mesh_plink_block(struct sta_info *sta)
{
+ struct ieee80211_sub_if_data *sdata = sta->sdata;
+ bool deactivated;
+
spin_lock_bh(&sta->lock);
- __mesh_plink_deactivate(sta);
+ deactivated = __mesh_plink_deactivate(sta);
sta->plink_state = PLINK_BLOCKED;
spin_unlock_bh(&sta->lock);
+
+ if (deactivated)
+ ieee80211_bss_info_change_notify(sdata, BSS_CHANGED_BEACON);
}
@@ -397,6 +413,7 @@ void mesh_rx_plink_frame(struct ieee80211_sub_if_data *sdata, struct ieee80211_m
enum plink_event event;
enum plink_frame_type ftype;
size_t baselen;
+ bool deactivated;
u8 ie_len;
u8 *baseaddr;
__le16 plid, llid, reason;
@@ -651,8 +668,8 @@ void mesh_rx_plink_frame(struct ieee80211_sub_if_data *sdata, struct ieee80211_m
case CNF_ACPT:
del_timer(&sta->plink_timer);
sta->plink_state = PLINK_ESTAB;
- mesh_plink_inc_estab_count(sdata);
spin_unlock_bh(&sta->lock);
+ mesh_plink_inc_estab_count(sdata);
mpl_dbg("Mesh plink with %pM ESTABLISHED\n",
sta->sta.addr);
break;
@@ -684,8 +701,8 @@ void mesh_rx_plink_frame(struct ieee80211_sub_if_data *sdata, struct ieee80211_m
case OPN_ACPT:
del_timer(&sta->plink_timer);
sta->plink_state = PLINK_ESTAB;
- mesh_plink_inc_estab_count(sdata);
spin_unlock_bh(&sta->lock);
+ mesh_plink_inc_estab_count(sdata);
mpl_dbg("Mesh plink with %pM ESTABLISHED\n",
sta->sta.addr);
mesh_plink_frame_tx(sdata, PLINK_CONFIRM, sta->sta.addr, llid,
@@ -702,11 +719,13 @@ void mesh_rx_plink_frame(struct ieee80211_sub_if_data *sdata, struct ieee80211_m
case CLS_ACPT:
reason = cpu_to_le16(MESH_CLOSE_RCVD);
sta->reason = reason;
- __mesh_plink_deactivate(sta);
+ deactivated = __mesh_plink_deactivate(sta);
sta->plink_state = PLINK_HOLDING;
llid = sta->llid;
mod_plink_timer(sta, dot11MeshHoldingTimeout(sdata));
spin_unlock_bh(&sta->lock);
+ if (deactivated)
+ ieee80211_bss_info_change_notify(sdata, BSS_CHANGED_BEACON);
mesh_plink_frame_tx(sdata, PLINK_CLOSE, sta->sta.addr, llid,
plid, reason);
break;
--
1.7.0.1
^ permalink raw reply related
* [PATCH v2] mac80211: avoid scheduling while atomic in mesh_rx_plink_frame
From: John W. Linville @ 2010-06-21 21:14 UTC (permalink / raw)
To: linux-wireless
Cc: Javier Cardona, Andrey Yurovsky, Gertjan van Wingerde,
Ivo van Doorn, John W. Linville
In-Reply-To: <1277154547-5851-1-git-send-email-linville@tuxdriver.com>
While mesh_rx_plink_frame holds sta->lock...
mesh_rx_plink_frame ->
mesh_plink_inc_estab_count ->
ieee80211_bss_info_change_notify
...but ieee80211_bss_info_change_notify is allowed to sleep. A driver
taking advantage of that allowance can cause a scheduling while
atomic bug. Similar paths exist for mesh_plink_dec_estab_count,
so work around those as well.
http://bugzilla.kernel.org/show_bug.cgi?id=16099
Also, correct a minor kerneldoc comment error (mismatched function names).
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
v2 -> move ieee80211_bss_info_change_notify call outside of
mesh_plink_inc_estab_count to balance the API with the modifications
to mesh_plink_dec_estab_count.
net/mac80211/mesh_plink.c | 42 +++++++++++++++++++++++++++++++-----------
1 files changed, 31 insertions(+), 11 deletions(-)
diff --git a/net/mac80211/mesh_plink.c b/net/mac80211/mesh_plink.c
index 3cd5f7b..ea13a80 100644
--- a/net/mac80211/mesh_plink.c
+++ b/net/mac80211/mesh_plink.c
@@ -65,7 +65,6 @@ void mesh_plink_inc_estab_count(struct ieee80211_sub_if_data *sdata)
{
atomic_inc(&sdata->u.mesh.mshstats.estab_plinks);
mesh_accept_plinks_update(sdata);
- ieee80211_bss_info_change_notify(sdata, BSS_CHANGED_BEACON);
}
static inline
@@ -73,7 +72,6 @@ void mesh_plink_dec_estab_count(struct ieee80211_sub_if_data *sdata)
{
atomic_dec(&sdata->u.mesh.mshstats.estab_plinks);
mesh_accept_plinks_update(sdata);
- ieee80211_bss_info_change_notify(sdata, BSS_CHANGED_BEACON);
}
/**
@@ -115,7 +113,7 @@ static struct sta_info *mesh_plink_alloc(struct ieee80211_sub_if_data *sdata,
}
/**
- * mesh_plink_deactivate - deactivate mesh peer link
+ * __mesh_plink_deactivate - deactivate mesh peer link
*
* @sta: mesh peer link to deactivate
*
@@ -123,18 +121,23 @@ static struct sta_info *mesh_plink_alloc(struct ieee80211_sub_if_data *sdata,
*
* Locking: the caller must hold sta->lock
*/
-static void __mesh_plink_deactivate(struct sta_info *sta)
+static bool __mesh_plink_deactivate(struct sta_info *sta)
{
struct ieee80211_sub_if_data *sdata = sta->sdata;
+ bool deactivated = false;
- if (sta->plink_state == PLINK_ESTAB)
+ if (sta->plink_state == PLINK_ESTAB) {
mesh_plink_dec_estab_count(sdata);
+ deactivated = true;
+ }
sta->plink_state = PLINK_BLOCKED;
mesh_path_flush_by_nexthop(sta);
+
+ return deactivated;
}
/**
- * __mesh_plink_deactivate - deactivate mesh peer link
+ * mesh_plink_deactivate - deactivate mesh peer link
*
* @sta: mesh peer link to deactivate
*
@@ -142,9 +145,15 @@ static void __mesh_plink_deactivate(struct sta_info *sta)
*/
void mesh_plink_deactivate(struct sta_info *sta)
{
+ struct ieee80211_sub_if_data *sdata = sta->sdata;
+ bool deactivated;
+
spin_lock_bh(&sta->lock);
- __mesh_plink_deactivate(sta);
+ deactivated = __mesh_plink_deactivate(sta);
spin_unlock_bh(&sta->lock);
+
+ if (deactivated)
+ ieee80211_bss_info_change_notify(sdata, BSS_CHANGED_BEACON);
}
static int mesh_plink_frame_tx(struct ieee80211_sub_if_data *sdata,
@@ -381,10 +390,16 @@ int mesh_plink_open(struct sta_info *sta)
void mesh_plink_block(struct sta_info *sta)
{
+ struct ieee80211_sub_if_data *sdata = sta->sdata;
+ bool deactivated;
+
spin_lock_bh(&sta->lock);
- __mesh_plink_deactivate(sta);
+ deactivated = __mesh_plink_deactivate(sta);
sta->plink_state = PLINK_BLOCKED;
spin_unlock_bh(&sta->lock);
+
+ if (deactivated)
+ ieee80211_bss_info_change_notify(sdata, BSS_CHANGED_BEACON);
}
@@ -397,6 +412,7 @@ void mesh_rx_plink_frame(struct ieee80211_sub_if_data *sdata, struct ieee80211_m
enum plink_event event;
enum plink_frame_type ftype;
size_t baselen;
+ bool deactivated;
u8 ie_len;
u8 *baseaddr;
__le16 plid, llid, reason;
@@ -651,8 +667,9 @@ void mesh_rx_plink_frame(struct ieee80211_sub_if_data *sdata, struct ieee80211_m
case CNF_ACPT:
del_timer(&sta->plink_timer);
sta->plink_state = PLINK_ESTAB;
- mesh_plink_inc_estab_count(sdata);
spin_unlock_bh(&sta->lock);
+ mesh_plink_inc_estab_count(sdata);
+ ieee80211_bss_info_change_notify(sdata, BSS_CHANGED_BEACON);
mpl_dbg("Mesh plink with %pM ESTABLISHED\n",
sta->sta.addr);
break;
@@ -684,8 +701,9 @@ void mesh_rx_plink_frame(struct ieee80211_sub_if_data *sdata, struct ieee80211_m
case OPN_ACPT:
del_timer(&sta->plink_timer);
sta->plink_state = PLINK_ESTAB;
- mesh_plink_inc_estab_count(sdata);
spin_unlock_bh(&sta->lock);
+ mesh_plink_inc_estab_count(sdata);
+ ieee80211_bss_info_change_notify(sdata, BSS_CHANGED_BEACON);
mpl_dbg("Mesh plink with %pM ESTABLISHED\n",
sta->sta.addr);
mesh_plink_frame_tx(sdata, PLINK_CONFIRM, sta->sta.addr, llid,
@@ -702,11 +720,13 @@ void mesh_rx_plink_frame(struct ieee80211_sub_if_data *sdata, struct ieee80211_m
case CLS_ACPT:
reason = cpu_to_le16(MESH_CLOSE_RCVD);
sta->reason = reason;
- __mesh_plink_deactivate(sta);
+ deactivated = __mesh_plink_deactivate(sta);
sta->plink_state = PLINK_HOLDING;
llid = sta->llid;
mod_plink_timer(sta, dot11MeshHoldingTimeout(sdata));
spin_unlock_bh(&sta->lock);
+ if (deactivated)
+ ieee80211_bss_info_change_notify(sdata, BSS_CHANGED_BEACON);
mesh_plink_frame_tx(sdata, PLINK_CLOSE, sta->sta.addr, llid,
plid, reason);
break;
--
1.7.0.1
^ permalink raw reply related
* Re: 2.6.35-rc3: Reported regressions 2.6.33 -> 2.6.34
From: Pavel Roskin @ 2010-06-21 22:01 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless, Rafael J. Wysocki, j, Tim Gardner
In-Reply-To: <AANLkTinRKbRPPzEqhdcexISRJKViBldG01cj9aF0wPx-@mail.gmail.com>
On Mon, 2010-06-21 at 11:32 -0700, Luis R. Rodriguez wrote:
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16111
> > Subject : hostap_pci: infinite registered netdevice wifi0
> > Submitter : Petr Pisar <petr.pisar@atlas.cz>
> > Date : 2010-06-02 20:55 (19 days old)
>
> The last entry on this one says we are not sure how to fix this...
That was a patch posted for that by Tim Gardner:
https://patchwork.kernel.org/patch/105008/
The patch is applied to wireless-testing
(d6a574ff6bfb842bdb98065da053881ff527be46)
$ git describe d6a574ff6bfb842bdb98065da053881ff527be46
v2.6.34-4694-gd6a574f
I understand it was applied after 2.6.34, so it should be backported to
2.6.34 and whatever older kernels are affected.
--
Regards,
Pavel Roskin
^ permalink raw reply
* [PATCH 1/5 v2]wireless:hostap_main.c warning: variable 'iface' set but not used
From: Justin P. Mattock @ 2010-06-21 22:02 UTC (permalink / raw)
To: linux-wireless; +Cc: netdev, linux-kernel, Justin P. Mattock
This is a resend from version one due to trying a different approach
than the original(probably important to leave netdev_priv() in).
In any case have a look, if there's another approach let me know
and ill test it out. The below patch fixes a warning im seeing
when compiling with gcc 4.6.0
CC [M] drivers/net/wireless/hostap/hostap_main.o
drivers/net/wireless/hostap/hostap_main.c: In function 'hostap_set_multicast_list_queue':
drivers/net/wireless/hostap/hostap_main.c:744:27: warning: variable 'iface' set but not used
Signed-off-by: Justin P. Mattock <justinmattock@gmail.com>
---
drivers/net/wireless/hostap/hostap_main.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/hostap/hostap_main.c b/drivers/net/wireless/hostap/hostap_main.c
index eb57d1e..a866e7a 100644
--- a/drivers/net/wireless/hostap/hostap_main.c
+++ b/drivers/net/wireless/hostap/hostap_main.c
@@ -741,9 +741,8 @@ void hostap_set_multicast_list_queue(struct work_struct *work)
local_info_t *local =
container_of(work, local_info_t, set_multicast_list_queue);
struct net_device *dev = local->dev;
- struct hostap_interface *iface;
- iface = netdev_priv(dev);
+ netdev_priv(dev);
if (hostap_set_word(dev, HFA384X_RID_PROMISCUOUSMODE,
local->is_promisc)) {
printk(KERN_INFO "%s: %sabling promiscuous mode failed\n",
--
1.7.1.rc1.21.gf3bd6
^ permalink raw reply related
* Re: 2.6.35-rc3: Reported regressions from 2.6.34
From: reinette chatre @ 2010-06-21 22:07 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless, linux-bluetooth, Rafael J. Wysocki
In-Reply-To: <AANLkTikVpTyNyYWf5xIO_3ok4OwbhxoiD40G3PAK8zp8@mail.gmail.com>
On Mon, 2010-06-21 at 11:49 -0700, Luis R. Rodriguez wrote:
> On Sun, Jun 20, 2010 at 3:11 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16235
> > Subject : [REGRESSION] [IWL3945] Broadcast is broken?
> > Submitter : Maciej Rutecki <maciej.rutecki@gmail.com>
> > Date : 2010-06-14 17:24 (7 days old)
> > Message-ID : <201006141924.24061.maciej.rutecki@gmail.com>
> > References : http://marc.info/?l=linux-kernel&m=127653628301300&w=2
>
> As noted by Maxim, the fix is in some Intel tree, but not upstream yet
> (if so why ?)
The patch was merged into our tree a few days ago. It will be sent
upstream after our validation passes, which should be by the end of this
week. The repo in which it was merged is accessible to all if the patch
is needed sooner - a link is now included in that bug report.
Reinette
^ permalink raw reply
* Re: 2.6.35-rc3: Reported regressions 2.6.33 -> 2.6.34
From: Luis R. Rodriguez @ 2010-06-21 22:18 UTC (permalink / raw)
To: Pavel Roskin; +Cc: linux-wireless, Rafael J. Wysocki, j, Tim Gardner
In-Reply-To: <1277157673.24550.5.camel@mj>
On Mon, Jun 21, 2010 at 3:01 PM, Pavel Roskin <proski@gnu.org> wrote:
> On Mon, 2010-06-21 at 11:32 -0700, Luis R. Rodriguez wrote:
>
>> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16111
>> > Subject : hostap_pci: infinite registered netdevice wifi0
>> > Submitter : Petr Pisar <petr.pisar@atlas.cz>
>> > Date : 2010-06-02 20:55 (19 days old)
>>
>> The last entry on this one says we are not sure how to fix this...
>
> That was a patch posted for that by Tim Gardner:
> https://patchwork.kernel.org/patch/105008/
>
> The patch is applied to wireless-testing
> (d6a574ff6bfb842bdb98065da053881ff527be46)
>
> $ git describe d6a574ff6bfb842bdb98065da053881ff527be46
> v2.6.34-4694-gd6a574f
>
> I understand it was applied after 2.6.34, so it should be backported to
> 2.6.34 and whatever older kernels are affected.
Tim can this be sent for stable?
Luis, a stable whore
^ 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