* Re: [PATCH] libertas: Read buffer overflow
From: Dan Williams @ 2009-08-04 15:16 UTC (permalink / raw)
To: Roel Kluin; +Cc: linville, linux-wireless, Andrew Morton
In-Reply-To: <4A7543CC.2010206@gmail.com>
On Sun, 2009-08-02 at 09:44 +0200, Roel Kluin wrote:
> Check whether index is within bounds before testing the element.
>
> Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Acked-by: Dan Williams <dcbw@redhat.com>
> ---
> diff --git a/drivers/net/wireless/libertas/11d.c b/drivers/net/wireless/libertas/11d.c
> index 9a5408e..5c69681 100644
> --- a/drivers/net/wireless/libertas/11d.c
> +++ b/drivers/net/wireless/libertas/11d.c
> @@ -47,7 +47,7 @@ static u8 lbs_region_2_code(u8 *region)
> {
> u8 i;
>
> - for (i = 0; region[i] && i < COUNTRY_CODE_LEN; i++)
> + for (i = 0; i < COUNTRY_CODE_LEN && region[i]; i++)
> region[i] = toupper(region[i]);
>
> for (i = 0; i < ARRAY_SIZE(region_code_mapping); i++) {
> --
> 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] libertas: check valid bits in SPI bus mode reg
From: Dan Williams @ 2009-08-04 15:19 UTC (permalink / raw)
To: Andrey Yurovsky; +Cc: linux-wireless, tharvey
In-Reply-To: <1249065319-18643-1-git-send-email-andrey@cozybit.com>
On Fri, 2009-07-31 at 11:35 -0700, Andrey Yurovsky wrote:
> The SPI driver writes to the bus mode register and performs a sanity
> check by reading back what we wrote, however only the lower four bits of
> that register are defined. In some cases, the device side seems to set
> the higher bits, causing us to fail the sanity check unnecessarily.
> Check only the lower four bits instead.
>
> Thanks to John Goyette from Schick Technologies for pointing out the
> problem.
>
> Signed-off-by: Andrey Yurovsky <andrey@cozybit.com>
Acked-by: Dan Williams <dcbw@redhat.com>
> ---
> drivers/net/wireless/libertas/if_spi.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/wireless/libertas/if_spi.c b/drivers/net/wireless/libertas/if_spi.c
> index 6564282..86263a9 100644
> --- a/drivers/net/wireless/libertas/if_spi.c
> +++ b/drivers/net/wireless/libertas/if_spi.c
> @@ -376,7 +376,7 @@ static int spu_set_bus_mode(struct if_spi_card *card, u16 mode)
> err = spu_read_u16(card, IF_SPI_SPU_BUS_MODE_REG, &rval);
> if (err)
> return err;
> - if (rval != mode) {
> + if ((rval & 0xF) != mode) {
> lbs_pr_err("Can't read bus mode register.\n");
> return -EIO;
> }
^ permalink raw reply
* Re: [PATCH] remove wrong probe_resp_plcp write
From: John W. Linville @ 2009-08-04 16:05 UTC (permalink / raw)
To: Michael Buesch; +Cc: gregor kowski, bcm43xx-dev, linux-wireless
In-Reply-To: <200907312238.15705.mb@bu3sch.de>
On Fri, Jul 31, 2009 at 10:38:14PM +0200, Michael Buesch wrote:
> On Friday 31 July 2009 22:35:49 gregor kowski wrote:
> > The tkip hw support uncovered a bug in b43_write_probe_resp_template : it is
> > writing at the wrong shm offset, it is in the B43_SHM_SH_TKIPTSCTTAK zone. This
> > patch comments these writes.
> >
> > Signed-off-by: Gregor Kowski <gregor.kowski@gmail.com>
>
> Signed-off-by: Michael Buesch <mb@bu3sch.de>
CC [M] drivers/net/wireless/b43/main.o
drivers/net/wireless/b43/main.c:1432: warning: ‘b43_write_probe_resp_plcp’ defined but not used
Comment it out too? Or are you going to fix the block that has been
commented-out here?
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
¡Viva Honduras Libre!
^ permalink raw reply
* Re: [Bug #13846] Possible regression in rt61pci driver
From: Chris Clayton @ 2009-08-04 16:04 UTC (permalink / raw)
To: Ivo van Doorn
Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List,
linux-wireless
In-Reply-To: <200908032217.19947.IvDoorn@gmail.com>
Thanks Ivo,
2009/8/3 Ivo van Doorn <ivdoorn@gmail.com>:
> Hi,
>
>> On Sunday 02 August 2009, Rafael J. Wysocki wrote:
>> > This message has been generated automatically as a part of a report
>> > of recent regressions.
>> >
>> > The following bug entry is on the current list of known regressions
>> > from 2.6.30. Please verify if it still should be listed and let me know
>> > (either way).
>> >
>>
>> The folks on the wireless project have concluded that the problem I reported is down to a hardware
>> problem when power saving is switched on on for my Belkin cardbus wireless adapter, so now I simply
>> turn power-saving off when wlan0 comes up. I did, however, ask whether anyone was going to fix the
>> fact that once power-saving turns the LEDs off, they never come back on again, but I haven't had an
>> answer. Is that a regression? I guess the answer is no, because power saving in the rt61pci driver
>> is feature that is new to 2.6.31. Should it be fixed? I think the answer is yes, but being unable
>> to do it myself, I probably don't have a vote :-)
>
> Can't recall this issue was ever reported, but that might just be me having overlooked some emails
> or have completely forgotten all about it. But here is a test patch to see if this helps in the issue,
> it is not really correct for upstream, but if it works I can see if there is a better solution.
>
> Thanks,
>
I've tried the patch without success. The card doesn't seem to wake up
again when I attempt network activity after PS has activated.
(Actually, There are two assumptions I should check out here. Firstly,
the LEDS going out is a sign that PS has activated and secondly, that
the card should "wake up" if I attempt network activity after PS has
activated).
A cut and paste from the console window:
[chris:~]$ iwconfig
lo no wireless extensions.
wmaster0 no wireless extensions.
wlan0 IEEE 802.11bg ESSID:"SKY28767"
Mode:Managed Frequency:2.412 GHz Access Point: 00:1F:33:80:09:44
Bit Rate=1 Mb/s Tx-Power=10 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Power Management:on
Link Quality=50/70 Signal level=-60 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
[chris:~]$ echo "waiting for leds to go out"
waiting for leds to go out
[chris:~]$ ping router
PING router.local.lan (192.168.0.1) from 192.168.0.30 : 56(84) bytes of data.
>From laptop.local.lan (192.168.0.30): Destination Host Unreachable
>From laptop.local.lan (192.168.0.30): Destination Host Unreachable
>From laptop.local.lan (192.168.0.30): Destination Host Unreachable
>From laptop.local.lan (192.168.0.30): Destination Host Unreachable
>From laptop.local.lan (192.168.0.30): Destination Host Unreachable
>From laptop.local.lan (192.168.0.30): Destination Host Unreachable
>From laptop.local.lan (192.168.0.30): Destination Host Unreachable
>From laptop.local.lan (192.168.0.30): Destination Host Unreachable
>From laptop.local.lan (192.168.0.30): Destination Host Unreachable
^C
--- router.local.lan ping statistics ---
11 packets transmitted, 0 packets received, +9 errors, 100% packet loss
[chris:~]$
To get the card going again I had to physically remove and reinsert it.
Chris
> Ivo
> ---
> diff --git a/drivers/net/wireless/rt2x00/rt2x00config.c b/drivers/net/wireless/rt2x00/rt2x00config.c
> index 3845316..6fe70b1 100644
> --- a/drivers/net/wireless/rt2x00/rt2x00config.c
> +++ b/drivers/net/wireless/rt2x00/rt2x00config.c
> @@ -196,6 +196,12 @@ void rt2x00lib_config(struct rt2x00_dev *rt2x00dev,
> */
> rt2x00dev->ops->lib->config(rt2x00dev, &libconf, ieee80211_flags);
>
> + if (ieee80211_flags & IEEE80211_CONF_CHANGE_PS) {
> + rt2x00led_led_activity(rt2x00dev, !(conf->flags & IEEE80211_CONF_PS));
> + rt2x00leds_led_assoc(rt2x00dev, !(conf->flags & IEEE80211_CONF_PS));
> + rt2x00leds_led_radio(rt2x00dev, !(conf->flags & IEEE80211_CONF_PS));
> + }
> +
> /*
> * Some configuration changes affect the link quality
> * which means we need to reset the link tuner.
>
--
No, Sir; there is nothing which has yet been contrived by man, by which
so much happiness is produced as by a good tavern or inn - Doctor Samuel
Johnson
^ permalink raw reply
* Re: [PATCH] libertas: Fix WEP association failure with open source wpa_supplicant 0.5.10
From: Dan Williams @ 2009-08-04 14:54 UTC (permalink / raw)
To: Bing Zhao; +Cc: libertas-dev, linux-wireless, Maithili Hinge
In-Reply-To: <1249095739-7908-1-git-send-email-bzhao@marvell.com>
On Fri, 2009-07-31 at 20:02 -0700, Bing Zhao wrote:
> From: Maithili Hinge <maithili@marvell.com>
>
> From: Maithili Hinge <maithili@marvell.com>
>
> Add code to handle IW_AUTH_PRIVACY_INVOKED and IW_AUTH_RX_UNENCRYPTED_EAPOL
> cases in lbs_set_auth() function in libertas code.
>
> Signed-off-by: Maithili Hinge <maithili@marvell.com>
> Signed-off-by: Bing Zhao <bzhao@marvell.com>
Acked-by: Dan Williams <dcbw@redhat.com>
> ---
> drivers/net/wireless/libertas/wext.c | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/wireless/libertas/wext.c b/drivers/net/wireless/libertas/wext.c
> index e96451c..be837a0 100644
> --- a/drivers/net/wireless/libertas/wext.c
> +++ b/drivers/net/wireless/libertas/wext.c
> @@ -1728,6 +1728,8 @@ static int lbs_set_auth(struct net_device *dev,
> }
>
> switch (dwrq->flags & IW_AUTH_INDEX) {
> + case IW_AUTH_PRIVACY_INVOKED:
> + case IW_AUTH_RX_UNENCRYPTED_EAPOL:
> case IW_AUTH_TKIP_COUNTERMEASURES:
> case IW_AUTH_CIPHER_PAIRWISE:
> case IW_AUTH_CIPHER_GROUP:
^ permalink raw reply
* Re: [PATCH v2] ath5k: fix missing output in monitor mode after ifconfig up
From: John W. Linville @ 2009-08-04 15:41 UTC (permalink / raw)
To: Joerg Albert
Cc: Bob Copeland, ath5k-devel, Luis R. Rodriguez,
linux-wireless@vger.kernel.org
In-Reply-To: <4A754562.8000107@gmx.de>
On Sun, Aug 02, 2009 at 09:50:58AM +0200, Joerg Albert wrote:
> Let ath5k_chan_set() always call ath5k_reset().
> This fixes the bug that we don't
> get any packets in monitor mode after:
>
> ifconfig wlan0 down
> iwconfig wlan0 mode monitor channel 1
> ifconfig wlan0 up
>
> but they arrive after
>
> iwconfig wlan0 channel 2
>
> Signed-off-by: Joerg Albert <jal2@gmx.de>
patching file drivers/net/wireless/ath/ath5k/base.c
Hunk #1 FAILED at 1071.
Hunk #2 FAILED at 1083.
Hunk #3 FAILED at 2804.
3 out of 3 hunks FAILED -- saving rejects to file drivers/net/wireless/ath/ath5k/base.c.rej
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
¡Viva Honduras Libre!
^ permalink raw reply
* Re: [DISCUSS] Implement non standard channel widths
From: Luis R. Rodriguez @ 2009-08-04 15:43 UTC (permalink / raw)
To: Pat Erley, Felix Fietkau; +Cc: Richard Farina, Johannes Berg, linux-wireless
In-Reply-To: <4A7855B3.1040007@erley.org>
On Tue, Aug 4, 2009 at 8:37 AM, Pat Erley<pat-lkml@erley.org> wrote:
> Richard Farina wrote:
>> Johannes Berg wrote:
>>> Then, finally, I'd add a new channel type, NL80211_CHANNEL_TYPE_5MHZ.
>>> Document it to imply that HT is being turned off, of course. Now this
>>> bit should be really simple.
>>>
>>>
>> But why? There is no reason mcs rates can't be used on 5/10 Mhz channels
>> as far as I know. Bad enough these channels are running at half and
>> quarter rates, if you can use mcs why not?
>>
>> Just my 0.02
>>
>> thanks,
>> Rick Farina
>
> My thought on this topic is: design everything so these COULD be supported,
> but wait until someone tests/implements this functionality with a driver
> and needs support for them. If I understood Johannes' description of things
> correctly, if it was found that a driver could do mcs rates in other channel
> widths, it'd be as simple as adding the values to the bitfields and that
> driver testing/implementing that functionality.
>
> What I guess it's come around to is:
>
> 1. Change the way the current functionality is implemented
> 2. Add additional values as it's added.
>
> What I believe johannes was saying is, during the implementation of 5/10mhz
> channels, disable ht/mcs modes up front, until someone shows/implements it.
You won't get support from vendors if the feature used is non-standard
though. Just keep that in mind. In fact I'm not sure its a good idea
to simply enable this off hand. We may want to consider a way to
annotate unsupported features if they are in fact very easy to
implement. So far we have simply opted to not support non-standard
features. I don't think we should strive away from that as I think it
has helped keep our code base clean and simple.
Luis
^ permalink raw reply
* Re: [DISCUSS] Implement non standard channel widths
From: Pat Erley @ 2009-08-04 15:37 UTC (permalink / raw)
To: Richard Farina; +Cc: Johannes Berg, linux-wireless
In-Reply-To: <4A77AA0A.2030205@gmail.com>
Richard Farina wrote:
> Johannes Berg wrote:
>> Then, finally, I'd add a new channel type, NL80211_CHANNEL_TYPE_5MHZ.
>> Document it to imply that HT is being turned off, of course. Now this
>> bit should be really simple.
>>
>>
> But why? There is no reason mcs rates can't be used on 5/10 Mhz channels
> as far as I know. Bad enough these channels are running at half and
> quarter rates, if you can use mcs why not?
>
> Just my 0.02
>
> thanks,
> Rick Farina
My thought on this topic is: design everything so these COULD be supported,
but wait until someone tests/implements this functionality with a driver
and needs support for them. If I understood Johannes' description of things
correctly, if it was found that a driver could do mcs rates in other channel
widths, it'd be as simple as adding the values to the bitfields and that
driver testing/implementing that functionality.
What I guess it's come around to is:
1. Change the way the current functionality is implemented
2. Add additional values as it's added.
What I believe johannes was saying is, during the implementation of 5/10mhz
channels, disable ht/mcs modes up front, until someone shows/implements it.
Pat
^ permalink raw reply
* Re: [ath5k-devel] [PATCH 2/4] ath5k: Linear PCDAC code fixes
From: Bob Copeland @ 2009-08-04 15:25 UTC (permalink / raw)
To: ath5k-devel, linux-wireless, linville, jirislaby, me, mcgrof, nbd
In-Reply-To: <20090731183132.GG7963@makis>
On Fri, Jul 31, 2009 at 2:31 PM, Nick
Kossifidis<mick@madwifi-project.org> wrote:
> * Set correct xpd curve indices for high/low gain curves during
> rfbuffer setup on RF5112B with both calibration curves available.
>
> * Don't return zero min power when we have the same pcdac value
> twice because it breaks interpolation. Instead return the right
> x barrier as we do when we have equal power levels for 2 different
> pcdac values.
>
> Signed-off-by: Nick Kossifidis <mickflemm@gmail.com>
Acked-by: Bob Copeland <me@bobcopeland.com>
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* Re: [ath5k-devel] [PATCH 1/4]: Check EEPROM before tweaking SERDES
From: Bob Copeland @ 2009-08-04 15:18 UTC (permalink / raw)
To: ath5k-devel, linux-wireless, linville, jirislaby, me, mcgrof, nbd
In-Reply-To: <20090731180238.GA7963@makis>
On Fri, Jul 31, 2009 at 2:02 PM, Nick
Kossifidis<mick@madwifi-project.org> wrote:
> + /* Check if PCIE_OFFSET points to PCIE_SERDES_SECTION
> + * and enable serdes programming if needed.
> + *
> + * XXX: Serdes values seem to be fixed so
> + * no need to read them here, we write them
> + * during ath5k_hw_attach */
> + AR5K_EEPROM_READ(AR5K_EEPROM_PCIE_OFFSET, val);
> + ee->ee_serdes = (val == AR5K_EEPROM_PCIE_SERDES_SECTION) ?
> + true : false;
Minor nit, can just be:
> + ee->ee_serdes = (val == AR5K_EEPROM_PCIE_SERDES_SECTION);
Just a matter of taste though, so:
Acked-by: Bob Copeland <me@bobcopeland.com>
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* Re: [PATCH v2] ath5k: fix missing output in monitor mode after ifconfig up
From: Bob Copeland @ 2009-08-04 15:13 UTC (permalink / raw)
To: Joerg Albert
Cc: John W. Linville, ath5k-devel, Luis R. Rodriguez,
linux-wireless@vger.kernel.org
In-Reply-To: <4A754562.8000107@gmx.de>
On Sun, Aug 2, 2009 at 3:50 AM, Joerg Albert<jal2@gmx.de> wrote:
> Let ath5k_chan_set() always call ath5k_reset().
> This fixes the bug that we don't
> get any packets in monitor mode after:
Thanks! Looks good.
Acked-by: Bob Copeland <me@bobcopeland.com>
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* Re: regression IWl3945 - doesn't work with recent 2.6.30-rcX
From: Zdenek Kabelac @ 2009-08-04 15:07 UTC (permalink / raw)
To: reinette chatre
Cc: John W. Linville, Linux Kernel Mailing List,
linux-wireless@vger.kernel.org
In-Reply-To: <1240959723.1207.104.camel@rc-desk>
2009/4/29 reinette chatre <reinette.chatre@intel.com>:
> On Mon, 2009-04-27 at 00:59 -0700, Zdenek Kabelac wrote:
>> 2009/4/24 Zdenek Kabelac <zdenek.kabelac@gmail.com>:
>> > 2009/4/22 John W. Linville <linville@tuxdriver.com>:
>> >> On Wed, Apr 22, 2009 at 12:33:03PM +0200, Zdenek Kabelac wrote:
>> >>> Hi
>> >>>
>> >>> I'm checking whether -rcX kernel could be usable on my
>> >>> T61/4GB/C2D/x86_64 - but wireless seems to be still out of
>> >>> functionality:
>> >>> I'm getting lots of weird trace-back messages and it looks like
>> >>> iwl3945 is not working at all.
>> >>> (attached messages from fresh build of -rc3 - but it never worked even in -rc1)
>> >>
>> >> Looks like this one did _not_ make -rc3:
>> >>
>> >> commit df833b1d73680f9f9dc72cbc3215edbbc6ab740d
>> >> Author: Reinette Chatre <reinette.chatre@intel.com>
>> >> Date: Tue Apr 21 10:55:48 2009 -0700
>> >>
>> >> iwlwifi: DMA fixes
>> >>
>> >> A few issues wrt DMA were uncovered when using the driver with swiotlb.
>> >> ...
>> >>
>> >> It is in wireless-2.6 and should be in net-2.6 -- please try one of those kernels.
>> >
>> >
>> > I can confirm that current upstream linux commit
>> > 9f5a691253924fd033a58c6b1fed57bb0a4eccf4 works again with iwlwifi.
>> > and it already contains the patch you suggested to check.
>> >
>>
>>
>> While Wifi seems to be working well - I've noticed once attached long
>> INFO message during suspend.
>>
>> Zdenek
>>
>> -----------
>>
>> Linux version 2.6.30-rc3-00324-g8087eae (gcc version 4.4.0 20090414
>> (Red Hat 4.4.0-0.34) (GCC) ) #55 SMP Fri Apr 24 20:22:26 CEST 2009
>> Command line: ro root=/dev/sda5 selinux=0 no_console_suspend
>> ...
>> ADDRCONF(NETDEV_UP): wlan0: link is not ready
>> virbr0: no IPv6 routers present
>> wlan0: authenticate with AP 00:11:d8:da:65:40
>> wlan0: authenticated
>> wlan0: associate with AP 00:11:d8:da:65:40
>> wlan0: RX AssocResp from 00:11:d8:da:65:40 (capab=0x401 status=0 aid=4)
>> wlan0: associated
>> ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
>> wlan0: disassociating by local choice (reason=3)
>> audit(1240599276.009:18266): audit_enabled=0 old=1 auid=4294967295
>> ses=4294967295 res=1
>> wlan0: no IPv6 routers present
>> fuse init (API version 7.11)
>> wlan0: authenticate with AP 00:11:d8:da:65:40
>> wlan0: authenticated
>> wlan0: associate with AP 00:11:d8:da:65:40
>> wlan0: RX AssocResp from 00:11:d8:da:65:40 (capab=0x401 status=0 aid=4)
>> wlan0: associated
>> wlan0: no probe response from AP 00:11:d8:da:65:40 - disassociating
>> wlan0: deauthenticated (Reason: 7)
>> wlan0: authenticate with AP 00:11:d8:da:65:40
>> wlan0: authenticate with AP 00:11:d8:da:65:40
>> wlan0: authenticate with AP 00:11:d8:da:65:40
>> wlan0: authenticated
>> wlan0: associate with AP 00:11:d8:da:65:40
>> wlan0: RX ReassocResp from 00:11:d8:da:65:40 (capab=0x401 status=0 aid=4)
>> wlan0: associated
>>
>> ..........
>>
>> =========================================================
>> [ INFO: possible irq lock inversion dependency detected ]
>> 2.6.30-rc3-00324-g8087eae #55
>> ---------------------------------------------------------
>> swapper/0 just changed the state of lock:
>> (&(&priv->scan_check)->timer){+.-...}, at: [<ffffffff80250d90>]
>> run_timer_softirq+0x120/0x2e0
>> but this lock was taken by another, HARDIRQ-safe lock in the past:
>> (&priv->lock){-.-...}
>>
>> and interrupts could create inverse lock ordering between them.
>>
>>
>
> The locking used to protect scan_check is not consistent and is so
> because we overusing the priv->lock spinlock. scan_check is used in
> three places (iwl_rx_scan_complete_notif, iwl3945_bg_request_scan, and
> iwl3945_set_mode). In iwl_rx_scan_complete_notif the access is protected
> with priv->lock, while the other two use priv->mutex. The protection in
> iwl_rx_scan_complete_notif with priv->lock is not necessary ... but a
> significant effort is required to change this. We are starting to move
> in this direction. A workaround will be to acquire priv->lock in
> iwl3945_bg_request_scan and iwl3945_set_mode, but that will be ugly.
>
> We can leave this code as is in 2.6.30 because inverse lock ordering is
> not possible here as priv->mutex cannot be obtained in
> iwl_rx_scan_complete_notif path as it (the mutex) sleeps and this code
> path doesn't (it is run in a tasklet).
>
Hi
I'm not sure how it's related together - but this message I've got
today with 2.6.31-rc5.
Should I create a new report - or is it still the same not yet fixed issue ?
iwl3945 0000:03:00.0: Error sending REPLY_RXON: time out after 500ms.
iwl3945 0000:03:00.0: Error setting new configuration (-110).
iwl3945 0000:03:00.0: Error sending REPLY_SCAN_CMD: time out after 500ms.
iwl3945 0000:03:00.0: Error sending REPLY_RXON: time out after 500ms.
iwl3945 0000:03:00.0: Error setting new configuration (-110).
iwl3945 0000:03:00.0: Error sending REPLY_RXON: time out after 500ms.
iwl3945 0000:03:00.0: Error setting new configuration (-110).
iwl3945 0000:03:00.0: Error sending REPLY_TX_PWR_TABLE_CMD: time out
after 500ms.
------------[ cut here ]------------
WARNING: at net/mac80211/scan.c:281
ieee80211_scan_completed+0xf1/0x4d0 [mac80211]()
Hardware name: 6464CTO
Modules linked in: oprofile fuse ipt_MASQUERADE iptable_nat nf_nat
nf_conntrack_ipv4 nf_defrag_ipv4 xt_state ipt_REJECT xt_tcpudp
iptable_filter ip_tables x_tables bridge stp llc sunrpc autofs4 ipv6
nf_conntrack_ftp nf_conntrack binfmt_misc dm_mirror dm_region_hash
dm_log dm_mod kvm_intel kvm i915 drm i2c_algo_bit uinput
snd_hda_codec_analog arc4 ecb dvb_core cryptomgr videodev aead
v4l1_compat v4l2_compat_ioctl32 snd_hda_intel snd_hda_codec
snd_seq_oss pcompress crypto_blkcipher crypto_hash crypto_algapi btusb
snd_seq_midi_event snd_seq iwl3945 sdhci_pci iwlcore snd_seq_device
sdhci bluetooth mac80211 snd_pcm_oss mmc_core cfg80211 snd_mixer_oss
snd_pcm snd_timer i2c_i801 snd sr_mod i2c_core psmouse iTCO_wdt video
cdrom soundcore usbhid hid evdev thinkpad_acpi led_class serio_raw
iTCO_vendor_support intel_agp snd_page_alloc rtc_cmos rtc_core rtc_lib
rfkill e1000e backlight output nvram battery button ac uhci_hcd
ohci_hcd ehci_hcd usbcore [last unloaded: microcode]
Pid: 1007, comm: iwl3945 Tainted: G W 2.6.31-rc5-00002-g43e068f #79
Call Trace:
[<ffffffff8104c4eb>] warn_slowpath_common+0x7b/0xc0
[<ffffffffa0232040>] ? iwl_bg_scan_completed+0x0/0x100 [iwlcore]
[<ffffffff8104c544>] warn_slowpath_null+0x14/0x20
[<ffffffffa01c88f1>] ieee80211_scan_completed+0xf1/0x4d0 [mac80211]
[<ffffffff8105904a>] ? del_timer_sync+0x7a/0xa0
[<ffffffff81058fd0>] ? del_timer_sync+0x0/0xa0
[<ffffffffa0232040>] ? iwl_bg_scan_completed+0x0/0x100 [iwlcore]
[<ffffffffa023208f>] iwl_bg_scan_completed+0x4f/0x100 [iwlcore]
[<ffffffff810613d8>] worker_thread+0x1e8/0x3a0
[<ffffffff81061386>] ? worker_thread+0x196/0x3a0
[<ffffffff8137c11b>] ? thread_return+0x3e/0x703
[<ffffffff81066d60>] ? autoremove_wake_function+0x0/0x40
[<ffffffff810611f0>] ? worker_thread+0x0/0x3a0
[<ffffffff8106697e>] kthread+0x9e/0xb0
[<ffffffff8100d1da>] child_rip+0xa/0x20
[<ffffffff8100cb7c>] ? restore_args+0x0/0x30
[<ffffffff810668e0>] ? kthread+0x0/0xb0
[<ffffffff8100d1d0>] ? child_rip+0x0/0x20
---[ end trace 6ac8f069d92dd485 ]---
Zdenek
^ permalink raw reply
* Re: Ath5k/mac80211 triggers WARN_ON in kernel/softirq.c
From: John W. Linville @ 2009-08-04 14:55 UTC (permalink / raw)
To: Johannes Berg
Cc: Bob Copeland, Michael Buesch, jirislaby, mickflemm, lrodriguez,
wireless
In-Reply-To: <1248968229.16129.9.camel@johannes.local>
On Thu, Jul 30, 2009 at 05:37:09PM +0200, Johannes Berg wrote:
> On Thu, 2009-07-30 at 10:45 -0400, Bob Copeland wrote:
> > On Thu, Jul 30, 2009 at 10:31 AM, Michael Buesch<mb@bu3sch.de> wrote:
> > > Ath5k from today's compat-wireless triggers the following WARNing
> > > on hostapd startup.
> > > [ 1669.799870] ------------[ cut here ]------------
> > > [ 1669.799934] WARNING: at kernel/softirq.c:141 local_bh_enable_ip+0x8b/0xb0()
> >
> > because ath5k calls ieee80211_beacon_get inside a spin_lock_irqsave()
> > and this is WARN_ON_ONCE(in_irq() || irqs_disabled).
>
> > > [ 1669.800493] [<ffffffff807e0fef>] _spin_unlock_bh+0xf/0x20
> > > [ 1669.800564] [<ffffffffa0040b92>] ieee80211_beacon_get+0x2c2/0x2d0 [mac80211]
> >
> > I guess this is the first victim of spin_lock_bh conversion?
>
> Indeed. I think this means we need to convert the local->sta_lock back
> to _irqsave/restore.
>
> John, can you revert the BH patch ("mac80211: do not use irq locks where
> not necessary") and I'll send a new one with those changes removed?
OK, will be gone today...
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
¡Viva Honduras Libre!
^ permalink raw reply
* Re: [PATCH 2.6.30] iwl3945: fix rfkill switch
From: John W. Linville @ 2009-08-04 12:49 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: linux-wireless, Zhu Yi, Reinette Chatre, stable
In-Reply-To: <1249389350-4158-1-git-send-email-sgruszka@redhat.com>
On Tue, Aug 04, 2009 at 02:35:50PM +0200, Stanislaw Gruszka wrote:
> Due to rfkill and iwlwifi mishmash of SW / HW killswitch representation,
> we have race conditions which make unable turn wifi radio on, after enable
> and disable again killswitch. I can observe this problem on my laptop
> with iwl3945 device.
>
> In rfkill core HW switch and SW switch are separate 'states'. Device can
> be only in one of 3 states: RFKILL_STATE_SOFT_BLOCKED, RFKILL_STATE_UNBLOCKED,
> RFKILL_STATE_HARD_BLOCKED. Whereas in iwlwifi driver we have separate bits
> STATUS_RF_KILL_HW and STATUS_RF_KILL_SW for HW and SW switches - radio can be
> turned on, only if both bits are cleared.
>
> In this particular race conditions, radio can not be turned on if in driver
> STATUS_RF_KILL_SW bit is set, and rfkill core is in state
> RFKILL_STATE_HARD_BLOCKED, because rfkill core is unable to call
> rfkill->toggle_radio(). This situation can be entered in case:
>
> - killswitch is turned on
> - rfkill core 'see' button change first and move to RFKILL_STATE_SOFT_BLOCKED
> also call ->toggle_radio() and STATE_RF_KILL_SW in driver is set
> - iwl3945 get info about button from hardware to set STATUS_RF_KILL_HW bit and
> force rfkill to move to RFKILL_STATE_HARD_BLOCKED
> - killsiwtch is turend off
> - driver clear STATUS_RF_KILL_HW
> - rfkill core is unable to clear STATUS_RF_KILL_SW in driver
>
> Additionally call to rfkill_epo() when STATUS_RF_KILL_HW in driver is set
> cause move to the same situation.
>
> In 2.6.31 this problem is fixed due to _total_ rewrite of rfkill subsystem.
> This is a quite small fix for 2.6.30.x in iwl3945 driver. We disable
> STATUS_RF_KILL_SW bit regardless of HW bit state. Also report to rfkill
> subsystem SW switch bit before HW switch bit to move rfkill subsystem
> to SOFT_BLOCK rather than HARD_BLOCK.
>
> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
> ---
> I'm not sure if this is good candidate for stable as this is not backport
> of upstream commit. Also I did not test this patch with other iwlwifi devices,
> only with iwl3945.
stable is about the only place it can go, since it fixes a problem
that doesn't exist in 2.6.31...
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
¡Viva Honduras Libre!
^ permalink raw reply
* [PATCH] mac80211: FIF_PSPOLL filter flag
From: Igor Perminov @ 2009-08-04 12:48 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless, Johannes Berg
When an interface is configured in the AP mode, the mac80211
implementation doesn't inform the driver to receive PS Poll frames.
It leads to inability to communicate with power-saving stations
reliably.
The FIF_CONTROL flag isn't passed by mac80211 to
ieee80211_ops.configure_filter when an interface is in the AP mode.
And it's ok, because we don't want to receive ACK frames and other
control ones, but only PS Poll ones.
This patch introduces the FIF_PSPOLL filter flag in addition to
FIF_CONTROL, which means for the driver "pass PS Poll frames".
This flag is passed to the driver:
A) When an interface is configured in the AP mode.
B) In all cases, when the FIF_CONTROL flag was passed earlier (in
addition to it).
Signed-off-by: Igor Perminov <igor.perminov@inbox.ru>
---
include/net/mac80211.h | 8 ++++++--
net/mac80211/ieee80211_i.h | 2 +-
net/mac80211/iface.c | 18 ++++++++++++++++--
net/mac80211/main.c | 3 +++
4 files changed, 26 insertions(+), 5 deletions(-)
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index d4e09a0..5113bba 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -1236,10 +1236,13 @@ ieee80211_get_alt_retry_rate(const struct ieee80211_hw *hw,
* mac80211 needs to do and the amount of CPU wakeups, so you should
* honour this flag if possible.
*
- * @FIF_CONTROL: pass control frames, if PROMISC_IN_BSS is not set then
- * only those addressed to this station
+ * @FIF_CONTROL: pass control frames (except for PS Poll), if PROMISC_IN_BSS
+ * is not set then only those addressed to this station.
*
* @FIF_OTHER_BSS: pass frames destined to other BSSes
+ *
+ * @FIF_PSPOLL: pass PS Poll frames, if PROMISC_IN_BSS is not set then only
+ * those addressed to this station.
*/
enum ieee80211_filter_flags {
FIF_PROMISC_IN_BSS = 1<<0,
@@ -1249,6 +1252,7 @@ enum ieee80211_filter_flags {
FIF_BCN_PRBRESP_PROMISC = 1<<4,
FIF_CONTROL = 1<<5,
FIF_OTHER_BSS = 1<<6,
+ FIF_PSPOLL = 1<<7,
};
/**
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index aec6853..ab6003d 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -621,7 +621,7 @@ struct ieee80211_local {
int open_count;
int monitors, cooked_mntrs;
/* number of interfaces with corresponding FIF_ flags */
- int fif_fcsfail, fif_plcpfail, fif_control, fif_other_bss;
+ int fif_fcsfail, fif_plcpfail, fif_control, fif_other_bss, fif_pspoll;
unsigned int filter_flags; /* FIF_* */
struct iw_statistics wstats;
diff --git a/net/mac80211/iface.c b/net/mac80211/iface.c
index a83087f..c5f4559 100644
--- a/net/mac80211/iface.c
+++ b/net/mac80211/iface.c
@@ -220,8 +220,10 @@ static int ieee80211_open(struct net_device *dev)
local->fif_fcsfail++;
if (sdata->u.mntr_flags & MONITOR_FLAG_PLCPFAIL)
local->fif_plcpfail++;
- if (sdata->u.mntr_flags & MONITOR_FLAG_CONTROL)
+ if (sdata->u.mntr_flags & MONITOR_FLAG_CONTROL) {
local->fif_control++;
+ local->fif_pspoll++;
+ }
if (sdata->u.mntr_flags & MONITOR_FLAG_OTHER_BSS)
local->fif_other_bss++;
@@ -244,7 +246,14 @@ static int ieee80211_open(struct net_device *dev)
spin_unlock_bh(&local->filter_lock);
ieee80211_start_mesh(sdata);
+ } else if (sdata->vif.type == NL80211_IFTYPE_AP) {
+ local->fif_pspoll++;
+
+ spin_lock_bh(&local->filter_lock);
+ ieee80211_configure_filter(local);
+ spin_unlock_bh(&local->filter_lock);
}
+
changed |= ieee80211_reset_erp_info(sdata);
ieee80211_bss_info_change_notify(sdata, changed);
ieee80211_enable_keys(sdata);
@@ -388,6 +397,9 @@ static int ieee80211_stop(struct net_device *dev)
if (sdata->flags & IEEE80211_SDATA_PROMISC)
atomic_dec(&local->iff_promiscs);
+ if (sdata->vif.type == NL80211_IFTYPE_AP)
+ local->fif_pspoll--;
+
netif_addr_lock_bh(dev);
spin_lock_bh(&local->filter_lock);
__dev_addr_unsync(&local->mc_list, &local->mc_count,
@@ -439,8 +451,10 @@ static int ieee80211_stop(struct net_device *dev)
local->fif_fcsfail--;
if (sdata->u.mntr_flags & MONITOR_FLAG_PLCPFAIL)
local->fif_plcpfail--;
- if (sdata->u.mntr_flags & MONITOR_FLAG_CONTROL)
+ if (sdata->u.mntr_flags & MONITOR_FLAG_CONTROL) {
+ local->fif_pspoll--;
local->fif_control--;
+ }
if (sdata->u.mntr_flags & MONITOR_FLAG_OTHER_BSS)
local->fif_other_bss--;
diff --git a/net/mac80211/main.c b/net/mac80211/main.c
index 5e76dd1..c330235 100644
--- a/net/mac80211/main.c
+++ b/net/mac80211/main.c
@@ -77,6 +77,9 @@ void ieee80211_configure_filter(struct ieee80211_local *local)
if (local->fif_other_bss)
new_flags |= FIF_OTHER_BSS;
+ if (local->fif_pspoll)
+ new_flags |= FIF_PSPOLL;
+
changed_flags = local->filter_flags ^ new_flags;
/* be a bit nasty */
^ permalink raw reply related
* [PATCH 2.6.30] iwl3945: fix rfkill switch
From: Stanislaw Gruszka @ 2009-08-04 12:35 UTC (permalink / raw)
To: linux-wireless
Cc: Zhu Yi, Reinette Chatre, John W. Linville, Stanislaw Gruszka,
stable
Due to rfkill and iwlwifi mishmash of SW / HW killswitch representation,
we have race conditions which make unable turn wifi radio on, after enable
and disable again killswitch. I can observe this problem on my laptop
with iwl3945 device.
In rfkill core HW switch and SW switch are separate 'states'. Device can
be only in one of 3 states: RFKILL_STATE_SOFT_BLOCKED, RFKILL_STATE_UNBLOCKED,
RFKILL_STATE_HARD_BLOCKED. Whereas in iwlwifi driver we have separate bits
STATUS_RF_KILL_HW and STATUS_RF_KILL_SW for HW and SW switches - radio can be
turned on, only if both bits are cleared.
In this particular race conditions, radio can not be turned on if in driver
STATUS_RF_KILL_SW bit is set, and rfkill core is in state
RFKILL_STATE_HARD_BLOCKED, because rfkill core is unable to call
rfkill->toggle_radio(). This situation can be entered in case:
- killswitch is turned on
- rfkill core 'see' button change first and move to RFKILL_STATE_SOFT_BLOCKED
also call ->toggle_radio() and STATE_RF_KILL_SW in driver is set
- iwl3945 get info about button from hardware to set STATUS_RF_KILL_HW bit and
force rfkill to move to RFKILL_STATE_HARD_BLOCKED
- killsiwtch is turend off
- driver clear STATUS_RF_KILL_HW
- rfkill core is unable to clear STATUS_RF_KILL_SW in driver
Additionally call to rfkill_epo() when STATUS_RF_KILL_HW in driver is set
cause move to the same situation.
In 2.6.31 this problem is fixed due to _total_ rewrite of rfkill subsystem.
This is a quite small fix for 2.6.30.x in iwl3945 driver. We disable
STATUS_RF_KILL_SW bit regardless of HW bit state. Also report to rfkill
subsystem SW switch bit before HW switch bit to move rfkill subsystem
to SOFT_BLOCK rather than HARD_BLOCK.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
---
I'm not sure if this is good candidate for stable as this is not backport
of upstream commit. Also I did not test this patch with other iwlwifi devices,
only with iwl3945.
drivers/net/wireless/iwlwifi/iwl-rfkill.c | 24 ++++++++++++++----------
1 files changed, 14 insertions(+), 10 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-rfkill.c b/drivers/net/wireless/iwlwifi/iwl-rfkill.c
index 2ad9faf..d6b6098 100644
--- a/drivers/net/wireless/iwlwifi/iwl-rfkill.c
+++ b/drivers/net/wireless/iwlwifi/iwl-rfkill.c
@@ -54,21 +54,28 @@ static int iwl_rfkill_soft_rf_kill(void *data, enum rfkill_state state)
case RFKILL_STATE_UNBLOCKED:
if (iwl_is_rfkill_hw(priv)) {
err = -EBUSY;
- goto out_unlock;
+ /* pass error to rfkill core to make it state HARD
+ * BLOCKED and disable software kill switch */
}
iwl_radio_kill_sw_enable_radio(priv);
break;
case RFKILL_STATE_SOFT_BLOCKED:
iwl_radio_kill_sw_disable_radio(priv);
+ /* rfkill->mutex lock is taken */
+ if (priv->rfkill->state == RFKILL_STATE_HARD_BLOCKED) {
+ /* force rfkill core state to be SOFT BLOCKED,
+ * otherwise core will be unable to disable software
+ * kill switch */
+ priv->rfkill->state = RFKILL_STATE_SOFT_BLOCKED;
+ }
break;
default:
IWL_WARN(priv, "we received unexpected RFKILL state %d\n",
state);
break;
}
-out_unlock:
- mutex_unlock(&priv->mutex);
+ mutex_unlock(&priv->mutex);
return err;
}
@@ -132,14 +139,11 @@ void iwl_rfkill_set_hw_state(struct iwl_priv *priv)
if (!priv->rfkill)
return;
- if (iwl_is_rfkill_hw(priv)) {
+ if (iwl_is_rfkill_sw(priv))
+ rfkill_force_state(priv->rfkill, RFKILL_STATE_SOFT_BLOCKED);
+ else if (iwl_is_rfkill_hw(priv))
rfkill_force_state(priv->rfkill, RFKILL_STATE_HARD_BLOCKED);
- return;
- }
-
- if (!iwl_is_rfkill_sw(priv))
- rfkill_force_state(priv->rfkill, RFKILL_STATE_UNBLOCKED);
else
- rfkill_force_state(priv->rfkill, RFKILL_STATE_SOFT_BLOCKED);
+ rfkill_force_state(priv->rfkill, RFKILL_STATE_UNBLOCKED);
}
EXPORT_SYMBOL(iwl_rfkill_set_hw_state);
--
1.6.2.5
^ permalink raw reply related
* Re: Multiple rfkill knobs for the same hardware interface
From: Matthew Garrett @ 2009-08-04 12:43 UTC (permalink / raw)
To: Andrey Borzenkov; +Cc: linux-wireless
In-Reply-To: <200908041630.00533.arvidjaar@mail.ru>
On Tue, Aug 04, 2009 at 04:29:56PM +0400, Andrey Borzenkov wrote:
> So dell-laptop actually lies claiming that both radios are enabled. Even
> if this is a bug that can be fixed, having two knobs for exactly the
> same piece of hardware is confusing at the very least.
I've sent a fix for this bug. However, the functionality isn't entirely
redundant. Control over the platform interface allows overriding of BIOS
settings.
--
Matthew Garrett | mjg59@srcf.ucam.org
^ permalink raw reply
* support for pmkid candidate list and roaming
From: sawant paresh @ 2009-08-04 12:38 UTC (permalink / raw)
To: linux-wireless
Hi,
I want to know if mac80211 subsystem supports following -
1.
Given that the user space station application is connected to some AP
with SSID, and there is another AP with same SSID around in the radio
range, then does mac80211 subsystem be able to send an event
notification to user space?
2. Can mac80211 subsystem perform dissociate with current AP due to
weak signal and connect to another with same SSID and better signal
strength, and let the user space know about the new association?
Thanks
- Paresh
_________________________________________________________________
One stop at MSN India to catch up with what’s hot in the world around you today
http://in.msn.com
^ permalink raw reply
* Multiple rfkill knobs for the same hardware interface
From: Andrey Borzenkov @ 2009-08-04 12:29 UTC (permalink / raw)
To: mjg59; +Cc: linux-wireless
[-- Attachment #1: Type: Text/Plain, Size: 1019 bytes --]
This is mostly the same situation as ACPI vs. platform backlight
control. Here on Dell XPS M1330:
{pts/1}% rfkill list
0: dell-wifi: Wireless LAN
Soft blocked: no
Hard blocked: no
1: dell-bluetooth: Bluetooth
Soft blocked: no
Hard blocked: no
2: phy0: Wireless LAN
Soft blocked: no
Hard blocked: no
4: hci0: Bluetooth
Soft blocked: no
Hard blocked: no
Arguably, either one in the pair is redundant. Moreover, hard disabling
wireless (using slider on notebook side):
{pts/1}% rfkill list
0: dell-wifi: Wireless LAN
Soft blocked: no
Hard blocked: no
1: dell-bluetooth: Bluetooth
Soft blocked: no
Hard blocked: no
2: phy0: Wireless LAN
Soft blocked: no
Hard blocked: yes
So dell-laptop actually lies claiming that both radios are enabled. Even
if this is a bug that can be fixed, having two knobs for exactly the
same piece of hardware is confusing at the very least.
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] cfg80211: clear SSID on disconnect
From: Johannes Berg @ 2009-08-04 12:26 UTC (permalink / raw)
To: Joerg Albert; +Cc: linux-wireless
In-Reply-To: <loom.20090804T082338-799@post.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 479 bytes --]
On Tue, 2009-08-04 at 08:24 +0000, Joerg Albert wrote:
> Johannes Berg <johannes@...> writes:
>
>
>
> > Aha. yes, the same assignment is _also_ missing in
> > __cfg80211_connect_result(), can you add it there manually (in the
> > status != WLAN_STATUS_SUCCESS block at the end) and see what happens?
>
> Yes, that helped in my case.
The v2 patch I posted to this thread should fix the issue then, and also
fix two more places where it could occur.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH] wl12xx: make irq handling interface specific
From: Bob Copeland @ 2009-08-04 12:22 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless
In-Reply-To: <87hbwoniog.fsf@litku.valot.fi>
On Tue, Aug 04, 2009 at 10:26:39AM +0300, Kalle Valo wrote:
> So this patch is only needed on top of the rebased sdio patchset I sent
> few weeks ago to get sdio working? Or did I miss any patches? I'm just
> being careful here because I want to get sdio support to 2.6.32 (if it's
> ok for John) and there isn't that much time for that.
Hi Kalle,
Yes, the only other patch I have is for the platform gpios for the MSM
kernel (msm_wifi.ko module for HTC Dream) which doesn't touch this at all
and is platform specific. The plan was to turn that into a platform
rfkill driver, though it can probably go to staging in its present form
with the other Dream stuff.
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* Re: [PATCH] cfg80211: clear SSID on disconnect
From: Joerg Albert @ 2009-08-04 8:24 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <1249370029.9415.1.camel@johannes.local>
Johannes Berg <johannes@...> writes:
> Aha. yes, the same assignment is _also_ missing in
> __cfg80211_connect_result(), can you add it there manually (in the
> status != WLAN_STATUS_SUCCESS block at the end) and see what happens?
Yes, that helped in my case.
Thanks,
Jörg.
^ permalink raw reply
* [PATCH v2] cfg80211: clear SSID on disconnect/no connection
From: Johannes Berg @ 2009-08-04 7:32 UTC (permalink / raw)
To: John Linville; +Cc: Joerg Albert, linux-wireless
In-Reply-To: <1249311832.4561.2.camel@johannes.local>
The SME state machine in cfg80211 uses the SSID stored
in struct wireless_dev internally, but fails to clear
it in multiple places (when giving up on a connection
attempt and when disconnecting). This doesn't matter to
the SME state machine, but does matter for IBSS. Thus,
in those cases, clear the SSID to avoid messing up the
IBSS state machine.
Reported-by: Joerg Albert <jal2@gmx.de>
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
---
net/wireless/sme.c | 4 ++++
1 file changed, 4 insertions(+)
--- wireless-testing.orig/net/wireless/sme.c 2009-08-03 23:12:36.000000000 +0200
+++ wireless-testing/net/wireless/sme.c 2009-08-04 09:28:16.000000000 +0200
@@ -383,6 +383,7 @@ void __cfg80211_connect_result(struct ne
wdev->conn = NULL;
kfree(wdev->connect_keys);
wdev->connect_keys = NULL;
+ wdev->ssid_len = 0;
return;
}
@@ -550,6 +551,7 @@ void __cfg80211_disconnected(struct net_
wdev->current_bss = NULL;
wdev->sme_state = CFG80211_SME_IDLE;
+ wdev->ssid_len = 0;
if (wdev->conn) {
kfree(wdev->conn->ie);
@@ -705,6 +707,7 @@ int __cfg80211_connect(struct cfg80211_r
wdev->conn = NULL;
wdev->sme_state = CFG80211_SME_IDLE;
wdev->connect_keys = NULL;
+ wdev->ssid_len = 0;
}
return err;
@@ -769,6 +772,7 @@ int __cfg80211_disconnect(struct cfg8021
wdev->sme_state = CFG80211_SME_IDLE;
kfree(wdev->conn);
wdev->conn = NULL;
+ wdev->ssid_len = 0;
return 0;
}
^ permalink raw reply
* Re: [PATCH] wl12xx: make irq handling interface specific
From: Kalle Valo @ 2009-08-04 7:26 UTC (permalink / raw)
To: Bob Copeland; +Cc: linux-wireless
In-Reply-To: <20090804033908.GA1903@hash.localnet>
Bob Copeland <me@bobcopeland.com> writes:
> Hi Kalle,
Hi Bob,
> In addition to the warning below this patch also fixes oopses
> on rmmod due to active irqs after free. Please consider
> including it with the original sdio series.
Thanks, this looks good and I'll take it.
> With this wl1251 is stable, scans, and sends probe requests;
Excellent.
> association probably needs resolution of the issue you already
> identified with spi.
I'm now back from my vacation and I'll start looking at spi part again.
I'll also take a look at the association problem and will fix it.
So this patch is only needed on top of the rebased sdio patchset I sent
few weeks ago to get sdio working? Or did I miss any patches? I'm just
being careful here because I want to get sdio support to 2.6.32 (if it's
ok for John) and there isn't that much time for that.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH] cfg80211: clear SSID on disconnect
From: Johannes Berg @ 2009-08-04 7:13 UTC (permalink / raw)
To: Joerg Albert; +Cc: linux-wireless
In-Reply-To: <loom.20090804T064513-963@post.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 596 bytes --]
On Tue, 2009-08-04 at 06:55 +0000, Joerg Albert wrote:
> Sorry, but this didn't help with the ar9170 problem. I still get a call
> to ar9170_op_bss_info_changed() after ifconfig wlan1 down.
> I put a printk at your change in sme.c and it's not called.
>
> Please be aware that in managed mode my adapter stays in state SCANNING, 'cause
> there is not AP around with essid huhu_m:
Aha. yes, the same assignment is _also_ missing in
__cfg80211_connect_result(), can you add it there manually (in the
status != WLAN_STATUS_SUCCESS block at the end) and see what happens?
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox