* Re: PCI express card that does AP mode? (abit wlp-01?)
From: Johannes Berg @ 2009-07-24 15:59 UTC (permalink / raw)
To: Pavel Roskin; +Cc: Jon Fairbairn, linux-wireless
In-Reply-To: <1248450733.21715.26.camel@mj>
[-- Attachment #1: Type: text/plain, Size: 639 bytes --]
On Fri, 2009-07-24 at 11:52 -0400, Pavel Roskin wrote:
> On Fri, 2009-07-24 at 17:29 +0200, Johannes Berg wrote:
>
> > > From the
> > > users' perspective, PCI and PCI Express are different busses and should
> > > be listed separately.
> >
> > I'm not sure. The ID spaces are the same really, and users really don't
> > distinguish that much, for them PCI-E is just the new PCI technology
> > with a different form factor. Kinda like mini-pci vs. pci.
>
> We can have "form factors": PCI, CardBus, MiniPCI, PCIe and PCI
> ExpressCard.
I've done that and adjusted a few of the b43 entries, go check it out :)
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: WPA2, compat-wireless-2.6.31-rc3, kernel 2.6.28 - rtl8187 - association works but no ping
From: Ivan Kuten @ 2009-07-24 15:52 UTC (permalink / raw)
To: linux-wireless; +Cc: Luis R. Rodriguez
In-Reply-To: <43e72e890907240824n5bcff378m1278eb948055a9a5@mail.gmail.com>
>> ifconfig:
>>
>> eth0 Link encap:Ethernet HWaddr 02:80:AD:20:31:EB
>> inet addr:192.168.5.1 Bcast:192.168.5.255 Mask:255.255.255.0
>> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
>> RX packets:40 errors:0 dropped:0 overruns:0 frame:0
>> TX packets:188 errors:0 dropped:0 overruns:0 carrier:0
>> collisions:0 txqueuelen:1000
>> RX bytes:4077 (3.9 KiB) TX bytes:17012 (16.6 KiB)
>
> Note an IP address on eth0, most likely you have a default route using
> eht0 as well. Check with 'ip route'.
>
No default route. eth0 only for netconsole.
I'm doing udhcpc on wlan0.
Another thing is that WPA-TKIP is working. The problem only with CCMP.
I posted also in wpa_supplicant list with detailed wpa_supplicant log:
http://lists.shmoo.com/pipermail/hostap/2009-July/020026.html
>> wlan0 Link encap:Ethernet HWaddr 00:12:0E:98:67:FC
>> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
>> RX packets:2 errors:0 dropped:0 overruns:0 frame:0
>> TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
>> collisions:0 txqueuelen:1000
>> RX bytes:304 (304.0 B) TX bytes:3932 (3.8 KiB)
>>
>> wmaster0 Link encap:UNSPEC HWaddr 00-12-0E-98-67-FC-00-00-00-00-00-00-00-00-00-00
>> UP RUNNING MTU:0 Metric:1
>> RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>> TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
>> collisions:0 txqueuelen:1000
>> RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
>>
>> Neither dhcp nor setting static IP for wlan0 - no ping.
>
> Do you have Network Manager on? Please read:
>
No Network Manager.
Just:
wpa_supplicant -Dwext -iwlan0 -c /home/ACORP.conf -dd &
/sbin/udhcpc -n -q -i wlan0 -s /bin/default.script
> http://wireless.kernel.org/en/users/Documentation/Reporting_bugs
>
> Specifically the section that describes getting 'iw event -t' log and
> Network Manager.
>
I'll try with iw event -t.
Is it possible to check via debugfs something like number of received unencrypted packets?
Regards,
Ivan
^ permalink raw reply
* Re: PCI express card that does AP mode? (abit wlp-01?)
From: Pavel Roskin @ 2009-07-24 15:52 UTC (permalink / raw)
To: Johannes Berg; +Cc: Jon Fairbairn, linux-wireless
In-Reply-To: <1248449371.32151.23.camel@johannes.local>
On Fri, 2009-07-24 at 17:29 +0200, Johannes Berg wrote:
> > From the
> > users' perspective, PCI and PCI Express are different busses and should
> > be listed separately.
>
> I'm not sure. The ID spaces are the same really, and users really don't
> distinguish that much, for them PCI-E is just the new PCI technology
> with a different form factor. Kinda like mini-pci vs. pci.
We can have "form factors": PCI, CardBus, MiniPCI, PCIe and PCI
ExpressCard.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: PCI express card that does AP mode? (abit wlp-01?)
From: Johannes Berg @ 2009-07-24 15:47 UTC (permalink / raw)
To: Jon Fairbairn; +Cc: linux-wireless
In-Reply-To: <wfr5w66q8u.fsf@calligramme.charmers>
[-- Attachment #1: Type: text/plain, Size: 687 bytes --]
On Fri, 2009-07-24 at 16:43 +0100, Jon Fairbairn wrote:
> Speaking as a user, I do want to distinguish them: PCIe fits into a
> physically different slot from PCI, so having only PCIe slots free, I
> really did want to select by socket type. Similarly someone with a PCI
> only motherboard would be looking for PCI and not PCIe.
Right, but that just means we should have a 'form factor' part of the
listing. I don't think a PCI-E listing would have helped you if it also
listed mini-pci-e or expresscard.
I think it would be smarter to group them all under PCI, but have a
form-factor there. While not exactly correct technically, it would be
easier to use.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: PCI express card that does AP mode? (abit wlp-01?)
From: Jon Fairbairn @ 2009-07-24 15:43 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <1248449371.32151.23.camel@johannes.local>
Johannes Berg <johannes@sipsolutions.net> writes:
> On Fri, 2009-07-24 at 11:23 -0400, Pavel Roskin wrote:
>
>> I tried to add a link for PCI Express devices, but I don't have
>> permissions to reorganize the Wiki to have a separate table.
>
>> From the users' perspective, PCI and PCI Express are different busses
>> and should be listed separately.
>
> I'm not sure. The ID spaces are the same really, and users really don't
> distinguish that much, for them PCI-E is just the new PCI technology
> with a different form factor. Kinda like mini-pci vs. pci.
Speaking as a user, I do want to distinguish them: PCIe fits into a
physically different slot from PCI, so having only PCIe slots free, I
really did want to select by socket type. Similarly someone with a PCI
only motherboard would be looking for PCI and not PCIe.
--
Jón Fairbairn Jon.Fairbairn@cl.cam.ac.uk
^ permalink raw reply
* Re: PCI express card that does AP mode? (abit wlp-01?)
From: Jon Fairbairn @ 2009-07-24 15:40 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <1248449030.21715.23.camel@mj>
Pavel Roskin <proski@gnu.org> writes:
> I assume the subvendor/subsystem ID is 147b:1033, as reported elsewhere
> and as "lspci -vnn" would show.
Ah, sorry, yes:
lspci -vnn -s 04:00.0
04:00.0 Ethernet controller [0200]: \
Atheros Communications Inc. AR242x \
802.11abg Wireless PCI Express Adapter [168c:001c] (rev 01)
Subsystem: ABIT Computer Corp. AirPace Wi-Fi [147b:1033]
Flags: bus master, fast devsel, latency 0, IRQ 17
Memory at fbff0000 (64-bit, non-prefetchable) [size=64K]
Capabilities: <access denied>
Kernel driver in use: ath5k
Kernel modules: ath5k
--
Jón Fairbairn Jon.Fairbairn@cl.cam.ac.uk
^ permalink raw reply
* Re: PCI express card that does AP mode? (abit wlp-01?)
From: Johannes Berg @ 2009-07-24 15:29 UTC (permalink / raw)
To: Pavel Roskin; +Cc: Jon Fairbairn, linux-wireless
In-Reply-To: <1248449030.21715.23.camel@mj>
[-- Attachment #1: Type: text/plain, Size: 608 bytes --]
[ah, sorry about the private mail, only saw this now]
On Fri, 2009-07-24 at 11:23 -0400, Pavel Roskin wrote:
> I tried to add a link for PCI Express devices, but I don't have
> permissions to reorganize the Wiki to have a separate table.
It needs some extra code.
> From the
> users' perspective, PCI and PCI Express are different busses and should
> be listed separately.
I'm not sure. The ID spaces are the same really, and users really don't
distinguish that much, for them PCI-E is just the new PCI technology
with a different form factor. Kinda like mini-pci vs. pci.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* [PATCH 2/2] ath9k: get rid of unnecessary setpower calls
From: Gabor Juhos @ 2009-07-24 15:27 UTC (permalink / raw)
To: John Linville
Cc: Luis R. Rodriguez, Jouni Malinen, ath9k-devel@lists.ath9k.org,
linux-wireless@vger.kernel.org, Vasanthakumar Thiagarajan,
Gabor Juhos
In-Reply-To: <1248449242-27629-1-git-send-email-juhosg@openwrt.org>
We are using setpower routines regardless of the current power mode.
Don't bother the hardware, if it is not necessary.
Changes-licensed-under: ISC
Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
---
drivers/net/wireless/ath/ath9k/hw.c | 8 ++++++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/hw.c b/drivers/net/wireless/ath/ath9k/hw.c
index f80b8ff..20a2807 100644
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -475,6 +475,8 @@ static struct ath_hw *ath9k_hw_newstate(u16 devid, struct ath_softc *sc,
ah->gbeacon_rate = 0;
+ ah->power_mode = ATH9K_PM_UNDEFINED;
+
return ah;
}
@@ -2739,6 +2741,9 @@ static bool ath9k_hw_setpower_nolock(struct ath_hw *ah,
"UNDEFINED"
};
+ if (ah->power_mode == mode)
+ return status;
+
DPRINTF(ah->ah_sc, ATH_DBG_RESET, "%s -> %s\n",
modes[ah->power_mode], modes[mode]);
@@ -2783,8 +2788,7 @@ void ath9k_ps_wakeup(struct ath_softc *sc)
if (++sc->ps_usecount != 1)
goto unlock;
- if (sc->sc_ah->power_mode != ATH9K_PM_AWAKE)
- ath9k_hw_setpower_nolock(sc->sc_ah, ATH9K_PM_AWAKE);
+ ath9k_hw_setpower_nolock(sc->sc_ah, ATH9K_PM_AWAKE);
unlock:
spin_unlock_irqrestore(&sc->sc_pm_lock, flags);
--
1.5.3.2
^ permalink raw reply related
* [PATCH 1/2] ath9k: fix race with IEEE80211_CONF_PS checks
From: Gabor Juhos @ 2009-07-24 15:27 UTC (permalink / raw)
To: John Linville
Cc: Luis R. Rodriguez, Jouni Malinen, ath9k-devel@lists.ath9k.org,
linux-wireless@vger.kernel.org, Vasanthakumar Thiagarajan,
Gabor Juhos
There is a small window where the mac80211 changes the IEEE80211_CONF_PS
flag, and then informs the driver about the change. We have a race
condition if we are checking the flag in the same time. Avoid it by
introducing a local variable, and using that instead of checking the
IEEE80211_CONF_PS flag directly.
This fix the problem reported by Luis:
http://article.gmane.org/gmane.linux.kernel.wireless.general/34363
Changes-licensed-under: ISC
Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
---
drivers/net/wireless/ath/ath9k/ath9k.h | 1 +
drivers/net/wireless/ath/ath9k/hw.c | 17 +++++++----------
drivers/net/wireless/ath/ath9k/hw.h | 1 -
drivers/net/wireless/ath/ath9k/main.c | 8 ++++----
4 files changed, 12 insertions(+), 15 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ath9k.h b/drivers/net/wireless/ath/ath9k/ath9k.h
index 751885a..9fe0ee3 100644
--- a/drivers/net/wireless/ath/ath9k/ath9k.h
+++ b/drivers/net/wireless/ath/ath9k/ath9k.h
@@ -576,6 +576,7 @@ struct ath_softc {
u32 keymax;
DECLARE_BITMAP(keymap, ATH_KEYMAX);
u8 splitmic;
+ bool ps_enabled;
unsigned long ps_usecount;
enum ath9k_int imask;
enum ath9k_ht_extprotspacing ht_extprotspacing;
diff --git a/drivers/net/wireless/ath/ath9k/hw.c b/drivers/net/wireless/ath/ath9k/hw.c
index 605803a..f80b8ff 100644
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -2783,10 +2783,8 @@ void ath9k_ps_wakeup(struct ath_softc *sc)
if (++sc->ps_usecount != 1)
goto unlock;
- if (sc->sc_ah->power_mode != ATH9K_PM_AWAKE) {
- sc->sc_ah->restore_mode = sc->sc_ah->power_mode;
+ if (sc->sc_ah->power_mode != ATH9K_PM_AWAKE)
ath9k_hw_setpower_nolock(sc->sc_ah, ATH9K_PM_AWAKE);
- }
unlock:
spin_unlock_irqrestore(&sc->sc_pm_lock, flags);
@@ -2800,13 +2798,12 @@ void ath9k_ps_restore(struct ath_softc *sc)
if (--sc->ps_usecount != 0)
goto unlock;
- if ((sc->hw->conf.flags & IEEE80211_CONF_PS) &&
- !(sc->sc_flags & (SC_OP_WAIT_FOR_BEACON |
- SC_OP_WAIT_FOR_CAB |
- SC_OP_WAIT_FOR_PSPOLL_DATA |
- SC_OP_WAIT_FOR_TX_ACK)))
- ath9k_hw_setpower_nolock(sc->sc_ah,
- sc->sc_ah->restore_mode);
+ if (sc->ps_enabled &&
+ !(sc->sc_flags & (SC_OP_WAIT_FOR_BEACON |
+ SC_OP_WAIT_FOR_CAB |
+ SC_OP_WAIT_FOR_PSPOLL_DATA |
+ SC_OP_WAIT_FOR_TX_ACK)))
+ ath9k_hw_setpower_nolock(sc->sc_ah, ATH9K_PM_NETWORK_SLEEP);
unlock:
spin_unlock_irqrestore(&sc->sc_pm_lock, flags);
diff --git a/drivers/net/wireless/ath/ath9k/hw.h b/drivers/net/wireless/ath/ath9k/hw.h
index 28bffdb..82e646c 100644
--- a/drivers/net/wireless/ath/ath9k/hw.h
+++ b/drivers/net/wireless/ath/ath9k/hw.h
@@ -417,7 +417,6 @@ struct ath_hw {
enum nl80211_iftype opmode;
enum ath9k_power_mode power_mode;
- enum ath9k_power_mode restore_mode;
struct ath9k_nfcal_hist nfCalHist[NUM_NF_READINGS];
struct ar5416Stats stats;
diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
index 3436295..d0b1e60 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -499,8 +499,7 @@ static void ath9k_tasklet(unsigned long data)
if (status & ATH9K_INT_TX)
ath_tx_tasklet(sc);
- if ((status & ATH9K_INT_TSFOOR) &&
- (sc->hw->conf.flags & IEEE80211_CONF_PS)) {
+ if ((status & ATH9K_INT_TSFOOR) && sc->ps_enabled) {
/*
* TSF sync does not look correct; remain awake to sync with
* the next Beacon.
@@ -2003,7 +2002,7 @@ static int ath9k_tx(struct ieee80211_hw *hw,
goto exit;
}
- if (sc->hw->conf.flags & IEEE80211_CONF_PS) {
+ if (sc->ps_enabled) {
struct ieee80211_hdr *hdr = (struct ieee80211_hdr *) skb->data;
/*
* mac80211 does not set PM field for normal data frames, so we
@@ -2291,8 +2290,9 @@ static int ath9k_config(struct ieee80211_hw *hw, u32 changed)
}
ath9k_hw_setrxabort(sc->sc_ah, 1);
}
- ath9k_hw_setpower(sc->sc_ah, ATH9K_PM_NETWORK_SLEEP);
+ sc->ps_enabled = true;
} else {
+ sc->ps_enabled = false;
ath9k_hw_setpower(sc->sc_ah, ATH9K_PM_AWAKE);
if (!(ah->caps.hw_caps &
ATH9K_HW_CAP_AUTOSLEEP)) {
--
1.5.3.2
^ permalink raw reply related
* Re: Generic events for wake up from S1-S4
From: Luis R. Rodriguez @ 2009-07-24 15:25 UTC (permalink / raw)
To: Henrique de Moraes Holschuh
Cc: ykzhao, Rafael J. Wysocki, Pavel Machek,
linux-kernel@vger.kernel.org, Johannes Berg, John W. Linville,
Jouni Malinen, linux-wireless, Stephen Chen,
ACPI Devel Maling List, pm list
In-Reply-To: <20090724133903.GA18827@khazad-dum.debian.net>
On Fri, Jul 24, 2009 at 6:39 AM, Henrique de Moraes
Holschuh<hmh@hmh.eng.br> wrote:
> On Fri, 24 Jul 2009, ykzhao wrote:
>> > > Well, we *already* deliver "lid opened" when the lid is opened, regardless
>> > > of it waking up the computer or not. But we are missing a way to deliver
>> > > other classes of wakeup events.
>> > >
>> > > I know of at least these (incomplete list):
>> > >
>> > > 1. network-initiated wakeup
>> > > a. wired
>> > > b. wireless
>> > > c. long-range wireless
>> > >
>> > > 2. platform health/condition alarms
>> > > a. battery alarm (two levels, warning and emergency)
>> > > b. thermal alarm (two levels, warning and emergency)
>> > > (we need these as generic alarms, not just reason-for-wakeup)
>> > >
>> > > 3. device (or device tree) hotplug/hotunplug
>> > > a. hotunplug request or notification
>> > > (we deliver the request/notification, but we don't know we should
>> > > go back to sleep, so all we are missing is the reason-for-wakeup
>> > > event)
>> > >
>> > > 4. management
>> > > a. wake-up/power on clock
>> > > b. remote management command (IMPI, etc)
>> > > c. intrusion alarm
>> > > d. theft alarm
>> > >
>> > > None of those have a standard interface to notify userspace of the reason of
>> > > the wake up AFAIK. Many of these want a generic event interface to be
>> > > delivered not just as reason-for-wakeup, but also as runtime events.
>> > >
>> > > And I guess we should also tell userspace what state we are waking up from
>> > > (S5 clean state, S5/S4 hibernation, S3), sometimes it matters.
>> >
>> > Agreed, and same for the above.
>> >
>> > So, what in your opinion would be the best way to expose this information?
>
> Frankly? It needs to be an easy-to-extend ABI, and the only one that cames
> to mind right now are uevents.
That sounds like a great idea.
Luis
^ permalink raw reply
* Re: WPA2, compat-wireless-2.6.31-rc3, kernel 2.6.28 - rtl8187 - association works but no ping
From: Luis R. Rodriguez @ 2009-07-24 15:24 UTC (permalink / raw)
To: ivan.kuten; +Cc: linux-wireless
In-Reply-To: <4A696D33.8050606@promwad.com>
On Fri, Jul 24, 2009 at 1:13 AM, Ivan Kuten<ivan.kuten@promwad.com> wrote:
>> On Thu, Jul 23, 2009 at 2:22 AM, Ivan Kuten<ivan.kuten@promwad.com> wrote:
>>> compat-wireless-2.6.31-rc3
>>
>> compat-wireless-2.6.31-rc4 is out, please try that.
>>
>> Luis
>>
>
> Here is what I get for compat-wireless-2.6.31-rc4:
>
>
> <6>cfg80211: Using static regulatory domain info
> <6>cfg80211: Regulatory domain: US
> <6> (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
> <6> (2402000 KHz - 2472000 KHz @ 40000 KHz), (600 mBi, 2700 mBm)
> <6> (5170000 KHz - 5190000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
> <6> (5190000 KHz - 5210000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
> <6> (5210000 KHz - 5230000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
> <6> (5230000 KHz - 5330000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
> <6> (5735000 KHz - 5835000 KHz @ 40000 KHz), (600 mBi, 3000 mBm)
> <6>usb 1-1: new high speed USB device using isp1761 and address 2
> <6>cfg80211: Calling CRDA for country: US
> <6>usbcore: registered new interface driver rtl8187
> <6>usb 1-1: configuration #1 chosen from 1 choice
> <6>hub 1-1:1.0: USB hub found
> <6>hub 1-1:1.0: 3 ports detected
> <6>usb 1-1.1: new high speed USB device using isp1761 and address 3
> <6>usb 1-1.1: configuration #1 chosen from 1 choice
> <7>phy0: Selected rate control algorithm 'minstrel'
> <6>phy0: hwaddr 00277080, RTL8187vB (default) V1 + rtl8225z2
> <7>phy0: device now idle
> <7>phy0: device no longer idle - scanning
> <7>phy0: device now idle
> <7>phy0: device no longer idle - in use
> <7>wlan0: authenticate with AP 01a4b568
> <7>wlan0: authenticated
> <7>wlan0: associate with AP 01a4b568
> <7>wlan0: RX AssocResp from 003e101a (capab=0x411 status=0 aid=2)
> <7>wlan0: associated
> <7>phy0: Allocated STA 002fbfc4
> <7>phy0: Inserted STA 002fbfc4
> <7>wlan0: switched to short slot time (BSSID=01a4b568)
This looks peachy.
> iwconfig output:
>
> lo no wireless extensions.
>
> eth0 no wireless extensions.
>
> wmaster0 no wireless extensions.
>
> wlan0 IEEE 802.11bg ESSID:"ACORP"
> Mode:Managed Frequency:2.462 GHz Access Point: 00:02:72:74:AC:85
> Bit Rate=1 Mb/s Tx-Power=27 dBm
> Retry long limit:7 RTS thr:off Fragment thr:off
> Encryption key:2BAC-63B9-5D99-CF9A-4D39-079F-BB55-5D39 [2]
> Power Management:off
> Link Quality=61/70 Signal level=-49 dBm
> Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
> Tx excessive retries:0 Invalid misc:0 Missed beacon:0
>
>
> ifconfig:
>
> eth0 Link encap:Ethernet HWaddr 02:80:AD:20:31:EB
> inet addr:192.168.5.1 Bcast:192.168.5.255 Mask:255.255.255.0
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:40 errors:0 dropped:0 overruns:0 frame:0
> TX packets:188 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:4077 (3.9 KiB) TX bytes:17012 (16.6 KiB)
Note an IP address on eth0, most likely you have a default route using
eht0 as well. Check with 'ip route'.
> wlan0 Link encap:Ethernet HWaddr 00:12:0E:98:67:FC
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:2 errors:0 dropped:0 overruns:0 frame:0
> TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:304 (304.0 B) TX bytes:3932 (3.8 KiB)
>
> wmaster0 Link encap:UNSPEC HWaddr 00-12-0E-98-67-FC-00-00-00-00-00-00-00-00-00-00
> UP RUNNING MTU:0 Metric:1
> RX packets:0 errors:0 dropped:0 overruns:0 frame:0
> TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
>
> Neither dhcp nor setting static IP for wlan0 - no ping.
Do you have Network Manager on? Please read:
http://wireless.kernel.org/en/users/Documentation/Reporting_bugs
Specifically the section that describes getting 'iw event -t' log and
Network Manager.
Luis
^ permalink raw reply
* Re: PCI express card that does AP mode? (abit wlp-01?)
From: Pavel Roskin @ 2009-07-24 15:23 UTC (permalink / raw)
To: Jon Fairbairn; +Cc: linux-wireless
In-Reply-To: <wfzlau7co1.fsf@calligramme.charmers>
On Fri, 2009-07-24 at 08:39 +0100, Jon Fairbairn wrote:
> lspci -nn says
> 04:00.0 Ethernet controller [0200]: Atheros Communications Inc. AR242x
> 802.11abg Wireless PCI Express Adapter [168c:001c] (rev 01)
Great!
> Does that want to go on the wiki? (I can't access it right now:
> http://wireless.kernel.org/en/users/Devices * Connection to 83.246.72.84
> Failed )
Yes, it was down, but now it's working. I've added your device:
http://wireless.kernel.org/en/users/Devices/PCI
I assume the subvendor/subsystem ID is 147b:1033, as reported elsewhere
and as "lspci -vnn" would show.
I tried to add a link for PCI Express devices, but I don't have
permissions to reorganize the Wiki to have a separate table. From the
users' perspective, PCI and PCI Express are different busses and should
be listed separately.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: Generic events for wake up from S1-S4
From: Johannes Berg @ 2009-07-24 14:49 UTC (permalink / raw)
To: Henrique de Moraes Holschuh
Cc: ykzhao, Rafael J. Wysocki, Pavel Machek, Luis R. Rodriguez,
linux-kernel@vger.kernel.org, John W. Linville, Jouni Malinen,
linux-wireless, Stephen Chen, ACPI Devel Maling List, pm list
In-Reply-To: <20090724133903.GA18827@khazad-dum.debian.net>
[-- Attachment #1: Type: text/plain, Size: 305 bytes --]
On Fri, 2009-07-24 at 10:39 -0300, Henrique de Moraes Holschuh wrote:
> ACPI notifications are hard to extend, I think. Please correct me if I am
> wrong.
ACPI is the wrong place anyway, since it's fundamentally platform
dependent. Unlike the rest of suspend and wake functionality.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: Using compat-wireless w/ 2.6.27.26
From: Bob Copeland @ 2009-07-24 13:58 UTC (permalink / raw)
To: Philip A. Prindeville; +Cc: Luis R. Rodriguez, linux-wireless
In-Reply-To: <4A68E80C.808@redfish-solutions.com>
On Thu, Jul 23, 2009 at 6:45 PM, Philip A.
Prindeville<philipp_subx@redfish-solutions.com> wrote:
> Bob Copeland wrote:
>> On Thu, Jul 23, 2009 at 5:53 PM, Philip A.
>> Prindeville<philipp_subx@redfish-solutions.com> wrote:
>>>> Getting closer :-)
>>>>
>>>> ath5k_tx_processq(sc, &sc->txqs[i]);
>>>>
>>> Didn't work with rc4:
>>
>> What did you apply against? It's supposed to be against
>> wireless-testing (or, at worst, latest compat-wireless).
>>
>>> BUG: unable to handle kernel NULL pointer dereference at 00000000
>>> IP: [<d0935658>] :ath5k:ath5k_tasklet_tx+0x5e/0x27b
>>
> This was against compat-wireless-2.6.31-rc4.
>
> Alas, I already blew away the build directory...
I think you need to use the unstable compat-wireless snapshots;
I have a feeling that the above doesn't have all of the tx queues.
Check out ath5k.h, the txq array in struct ath5k_softc should have
NUM_TX_QUEUES entries, an earlier version only had 2.
Although your compiler generates rather different code from mine
(different config or whatever), it looks like the oops happened
in the list_for_each_entry(... txq->q ...) -- but I don't see how
that can happen in my copy, since txq[i].q is initialized at the
same time as txq[i].setup.
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* Re: Generic events for wake up from S1-S4
From: Henrique de Moraes Holschuh @ 2009-07-24 13:39 UTC (permalink / raw)
To: ykzhao
Cc: Rafael J. Wysocki, Pavel Machek, Luis R. Rodriguez,
linux-kernel@vger.kernel.org, Johannes Berg, John W. Linville,
Jouni Malinen, linux-wireless, Stephen Chen,
ACPI Devel Maling List, pm list
In-Reply-To: <1248396826.3556.26.camel@localhost.localdomain>
On Fri, 24 Jul 2009, ykzhao wrote:
> > > Well, we *already* deliver "lid opened" when the lid is opened, regardless
> > > of it waking up the computer or not. But we are missing a way to deliver
> > > other classes of wakeup events.
> > >
> > > I know of at least these (incomplete list):
> > >
> > > 1. network-initiated wakeup
> > > a. wired
> > > b. wireless
> > > c. long-range wireless
> > >
> > > 2. platform health/condition alarms
> > > a. battery alarm (two levels, warning and emergency)
> > > b. thermal alarm (two levels, warning and emergency)
> > > (we need these as generic alarms, not just reason-for-wakeup)
> > >
> > > 3. device (or device tree) hotplug/hotunplug
> > > a. hotunplug request or notification
> > > (we deliver the request/notification, but we don't know we should
> > > go back to sleep, so all we are missing is the reason-for-wakeup
> > > event)
> > >
> > > 4. management
> > > a. wake-up/power on clock
> > > b. remote management command (IMPI, etc)
> > > c. intrusion alarm
> > > d. theft alarm
> > >
> > > None of those have a standard interface to notify userspace of the reason of
> > > the wake up AFAIK. Many of these want a generic event interface to be
> > > delivered not just as reason-for-wakeup, but also as runtime events.
> > >
> > > And I guess we should also tell userspace what state we are waking up from
> > > (S5 clean state, S5/S4 hibernation, S3), sometimes it matters.
> >
> > Agreed, and same for the above.
> >
> > So, what in your opinion would be the best way to expose this information?
Frankly? It needs to be an easy-to-extend ABI, and the only one that cames
to mind right now are uevents.
> Maybe we should firstly define what event should be delivered to user
> space when it is resumed from S1--S4.
Why not a change uevent (although we could always come up with a new uevent
type for this, and that might be a good idea)?
> And another issue who is in charge of sending the event? By the specific
> device or ACPI notification?
ACPI notifications are hard to extend, I think. Please correct me if I am
wrong.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
^ permalink raw reply
* [PATCH] mac80211: fix PS-poll response, race
From: Johannes Berg @ 2009-07-24 11:23 UTC (permalink / raw)
To: John Linville; +Cc: Bob Copeland, Christian Lamparter, linux-wireless
When a station queries us for a PS-poll response, we wrongly
queue the frame on the virtual interface's queue rather than
the pending queue.
Additionally, fix a race condition where we could potentially
send multiple frames to the sleeping station due to using a
station flag rather than a packet flag. When converting to a
packet flag, we can also convert p54 and remove the filter
clearing we added for it.
(Also remove a now dead function)
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Reported-by: Bob Copeland <me@bobcopeland.com>
Tested-by: Bob Copeland <me@bobcopeland.com>
Cc: Christian Lamparter <chunkeey@web.de>
---
This seems to be fallout from the master netdev removal. Whichever tree
that is in now...
drivers/net/wireless/p54/txrx.c | 2 +-
include/net/mac80211.h | 4 ++++
net/mac80211/rx.c | 11 ++++++-----
net/mac80211/sta_info.h | 13 -------------
net/mac80211/tx.c | 19 +------------------
5 files changed, 12 insertions(+), 37 deletions(-)
--- wireless-testing.orig/net/mac80211/rx.c 2009-07-24 10:58:24.000000000 +0200
+++ wireless-testing/net/mac80211/rx.c 2009-07-24 10:58:59.000000000 +0200
@@ -782,7 +782,7 @@ static void ap_sta_ps_start(struct sta_i
struct ieee80211_local *local = sdata->local;
atomic_inc(&sdata->bss->num_sta_ps);
- set_and_clear_sta_flags(sta, WLAN_STA_PS, WLAN_STA_PSPOLL);
+ set_sta_flags(sta, WLAN_STA_PS);
drv_sta_notify(local, &sdata->vif, STA_NOTIFY_SLEEP, &sta->sta);
#ifdef CONFIG_MAC80211_VERBOSE_PS_DEBUG
printk(KERN_DEBUG "%s: STA %pM aid %d enters power save mode\n",
@@ -798,7 +798,7 @@ static int ap_sta_ps_end(struct sta_info
atomic_dec(&sdata->bss->num_sta_ps);
- clear_sta_flags(sta, WLAN_STA_PS | WLAN_STA_PSPOLL);
+ clear_sta_flags(sta, WLAN_STA_PS);
drv_sta_notify(local, &sdata->vif, STA_NOTIFY_AWAKE, &sta->sta);
if (!skb_queue_empty(&sta->ps_tx_buf))
@@ -1116,14 +1116,15 @@ ieee80211_rx_h_ps_poll(struct ieee80211_
skb_queue_empty(&rx->sta->ps_tx_buf);
if (skb) {
+ struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
struct ieee80211_hdr *hdr =
(struct ieee80211_hdr *) skb->data;
/*
- * Tell TX path to send one frame even though the STA may
+ * Tell TX path to send this frame even though the STA may
* still remain is PS mode after this frame exchange.
*/
- set_sta_flags(rx->sta, WLAN_STA_PSPOLL);
+ info->flags |= IEEE80211_TX_CTL_PSPOLL_RESPONSE;
#ifdef CONFIG_MAC80211_VERBOSE_PS_DEBUG
printk(KERN_DEBUG "STA %pM aid %d: PS Poll (entries after %d)\n",
@@ -1138,7 +1139,7 @@ ieee80211_rx_h_ps_poll(struct ieee80211_
else
hdr->frame_control |= cpu_to_le16(IEEE80211_FCTL_MOREDATA);
- dev_queue_xmit(skb);
+ ieee80211_add_pending_skb(rx->local, skb);
if (no_pending_pkts)
sta_info_clear_tim_bit(rx->sta);
--- wireless-testing.orig/net/mac80211/sta_info.h 2009-07-24 10:58:04.000000000 +0200
+++ wireless-testing/net/mac80211/sta_info.h 2009-07-24 10:59:28.000000000 +0200
@@ -30,7 +30,6 @@
* @WLAN_STA_ASSOC_AP: We're associated to that station, it is an AP.
* @WLAN_STA_WME: Station is a QoS-STA.
* @WLAN_STA_WDS: Station is one of our WDS peers.
- * @WLAN_STA_PSPOLL: Station has just PS-polled us.
* @WLAN_STA_CLEAR_PS_FILT: Clear PS filter in hardware (using the
* IEEE80211_TX_CTL_CLEAR_PS_FILT control flag) when the next
* frame to this station is transmitted.
@@ -47,7 +46,6 @@ enum ieee80211_sta_info_flags {
WLAN_STA_ASSOC_AP = 1<<5,
WLAN_STA_WME = 1<<6,
WLAN_STA_WDS = 1<<7,
- WLAN_STA_PSPOLL = 1<<8,
WLAN_STA_CLEAR_PS_FILT = 1<<9,
WLAN_STA_MFP = 1<<10,
WLAN_STA_SUSPEND = 1<<11
@@ -359,17 +357,6 @@ static inline void clear_sta_flags(struc
spin_unlock_irqrestore(&sta->flaglock, irqfl);
}
-static inline void set_and_clear_sta_flags(struct sta_info *sta,
- const u32 set, const u32 clear)
-{
- unsigned long irqfl;
-
- spin_lock_irqsave(&sta->flaglock, irqfl);
- sta->flags |= set;
- sta->flags &= ~clear;
- spin_unlock_irqrestore(&sta->flaglock, irqfl);
-}
-
static inline u32 test_sta_flags(struct sta_info *sta, const u32 flags)
{
u32 ret;
--- wireless-testing.orig/include/net/mac80211.h 2009-07-24 10:57:53.000000000 +0200
+++ wireless-testing/include/net/mac80211.h 2009-07-24 10:58:59.000000000 +0200
@@ -243,6 +243,9 @@ struct ieee80211_bss_conf {
* used to indicate that a frame was already retried due to PS
* @IEEE80211_TX_INTFL_DONT_ENCRYPT: completely internal to mac80211,
* used to indicate frame should not be encrypted
+ * @IEEE80211_TX_CTL_PSPOLL_RESPONSE: (internal?)
+ * This frame is a response to a PS-poll frame and should be sent
+ * although the station is in powersave mode.
*/
enum mac80211_tx_control_flags {
IEEE80211_TX_CTL_REQ_TX_STATUS = BIT(0),
@@ -262,6 +265,7 @@ enum mac80211_tx_control_flags {
IEEE80211_TX_INTFL_NEED_TXPROCESSING = BIT(14),
IEEE80211_TX_INTFL_RETRIED = BIT(15),
IEEE80211_TX_INTFL_DONT_ENCRYPT = BIT(16),
+ IEEE80211_TX_CTL_PSPOLL_RESPONSE = BIT(17),
};
/**
--- wireless-testing.orig/net/mac80211/tx.c 2009-07-24 10:58:24.000000000 +0200
+++ wireless-testing/net/mac80211/tx.c 2009-07-24 11:05:23.000000000 +0200
@@ -373,7 +373,7 @@ ieee80211_tx_h_unicast_ps_buf(struct iee
staflags = get_sta_flags(sta);
if (unlikely((staflags & WLAN_STA_PS) &&
- !(staflags & WLAN_STA_PSPOLL))) {
+ !(info->flags & IEEE80211_TX_CTL_PSPOLL_RESPONSE))) {
#ifdef CONFIG_MAC80211_VERBOSE_PS_DEBUG
printk(KERN_DEBUG "STA %pM aid %d: PS buffer (entries "
"before %d)\n",
@@ -412,24 +412,7 @@ ieee80211_tx_h_unicast_ps_buf(struct iee
sta->sta.addr);
}
#endif /* CONFIG_MAC80211_VERBOSE_PS_DEBUG */
- if (test_and_clear_sta_flags(sta, WLAN_STA_PSPOLL)) {
- /*
- * The sleeping station with pending data is now snoozing.
- * It queried us for its buffered frames and will go back
- * to deep sleep once it got everything.
- *
- * inform the driver, in case the hardware does powersave
- * frame filtering and keeps a station blacklist on its own
- * (e.g: p54), so that frames can be delivered unimpeded.
- *
- * Note: It should be safe to disable the filter now.
- * As, it is really unlikely that we still have any pending
- * frame for this station in the hw's buffers/fifos left,
- * that is not rejected with a unsuccessful tx_status yet.
- */
- info->flags |= IEEE80211_TX_CTL_CLEAR_PS_FILT;
- }
return TX_CONTINUE;
}
--- wireless-testing.orig/drivers/net/wireless/p54/txrx.c 2009-07-24 11:05:09.000000000 +0200
+++ wireless-testing/drivers/net/wireless/p54/txrx.c 2009-07-24 11:05:17.000000000 +0200
@@ -614,7 +614,7 @@ static void p54_tx_80211_header(struct p
if (info->flags & IEEE80211_TX_CTL_ASSIGN_SEQ)
*flags |= P54_HDR_FLAG_DATA_OUT_SEQNR;
- if (info->flags & IEEE80211_TX_CTL_CLEAR_PS_FILT)
+ if (info->flags & IEEE80211_TX_CTL_PSPOLL_RESPONSE)
*flags |= P54_HDR_FLAG_DATA_OUT_NOCANCEL;
*queue = skb_get_queue_mapping(skb) + P54_QUEUE_DATA;
^ permalink raw reply
* Re: [PATCH 3/3] MAINTAINERS: add wl1251 wireless driver
From: Luciano Coelho @ 2009-07-24 10:45 UTC (permalink / raw)
To: ext Kalle Valo
Cc: Joe Perches, linville@tuxdriver.com,
linux-wireless@vger.kernel.org, jirislaby@gmail.com
In-Reply-To: <878wiesaip.fsf@litku.valot.fi>
ext Kalle Valo wrote:
> Luciano Coelho <luciano.coelho@nokia.com> writes:
>
>
>> I think we have to choose one maintainer for the shared files (= you!
>> ;). So we could have something like this for your part:
>>
>> F: drivers/net/wireless/wl12xx/*
>> X: drivers/net/wireless/wl12xx/wl1271*
>>
>> Of course this doesn't apply yet, because there is no wl1271* at the
>> moment (hopefully there will be very soon). So, for now I think you
>> could have just the F line. And when I add my maintainer's block
>> there, I can add the X line to your part at the same time... How does
>> that sound?
>>
>
> Sounds good to me. I'm too lazy to send a new patch right now, but can
> you change the entry accordingly when you submit 1271 code?
>
Yeps, I can do that. I'm soooo close to getting the wl1271 driver to
work... (famous last words ;)
--
Cheers,
Luca.
^ permalink raw reply
* Re: wireless-testing regression: iwl3945 scan fails
From: Kalle Valo @ 2009-07-24 9:28 UTC (permalink / raw)
To: reinette chatre; +Cc: linux-wireless@vger.kernel.org, Johannes Berg
In-Reply-To: <1248278121.17896.2728.camel@rc-desk>
reinette chatre <reinette.chatre@intel.com> writes:
> Hi Kalle,
Hi Reinette,
>> I have looked at this now a bit and I don't think this is an iwl3945
>> problem. Scanning seems to stall in some situations and iwl3945 doesn't
>> even receive the scan command.
>
> The patches we sent recently did undergo testing under various scenarios
> using wpa_supplicant. We have not done this testing after the
> 2.6.31-rc3-wl merge (yesterday) though. I just did a quick test on my
> 3945 using iwconfig to associate and it was able to do so on A and G
> bands. Looks like I need to do some wpa_supplicant testing.
This odd problem might happen only in my setup.
>> Also I have been able to reproduce the problem once with iw. For some
>> strange reason I have had to reboot my laptop to reproduce this,
>> unloading all wireless related modules (expect rfkill which I can't
>> unload due to dependencies) is not enough.
>
> Are you saying that this problem occurs always with wpa_supplicant and
> sometimes with iw?
I did some more testing and I can now reproduce this with iw as well. I
just need to reboot my laptop to reproduce it. I'll debug this more on a
rainy day.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH 3/3] MAINTAINERS: add wl1251 wireless driver
From: Kalle Valo @ 2009-07-24 9:19 UTC (permalink / raw)
To: Luciano Coelho
Cc: Joe Perches, linville@tuxdriver.com,
linux-wireless@vger.kernel.org, jirislaby@gmail.com
In-Reply-To: <4A661C4B.5070803@nokia.com>
Luciano Coelho <luciano.coelho@nokia.com> writes:
> I think we have to choose one maintainer for the shared files (= you!
> ;). So we could have something like this for your part:
>
> F: drivers/net/wireless/wl12xx/*
> X: drivers/net/wireless/wl12xx/wl1271*
>
> Of course this doesn't apply yet, because there is no wl1271* at the
> moment (hopefully there will be very soon). So, for now I think you
> could have just the F line. And when I add my maintainer's block
> there, I can add the X line to your part at the same time... How does
> that sound?
Sounds good to me. I'm too lazy to send a new patch right now, but can
you change the entry accordingly when you submit 1271 code?
--
Kalle Valo
^ permalink raw reply
* Re: WPA2, compat-wireless-2.6.31-rc3, kernel 2.6.28 - rtl8187 - association works but no ping
From: Ivan Kuten @ 2009-07-24 8:13 UTC (permalink / raw)
To: linux-wireless; +Cc: Luis R. Rodriguez
In-Reply-To: <43e72e890907230917w226c4697v41f907623e5f7d8@mail.gmail.com>
> On Thu, Jul 23, 2009 at 2:22 AM, Ivan Kuten<ivan.kuten@promwad.com> wrote:
>> compat-wireless-2.6.31-rc3
>
> compat-wireless-2.6.31-rc4 is out, please try that.
>
> Luis
>
Here is what I get for compat-wireless-2.6.31-rc4:
<6>cfg80211: Using static regulatory domain info
<6>cfg80211: Regulatory domain: US
<6> (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
<6> (2402000 KHz - 2472000 KHz @ 40000 KHz), (600 mBi, 2700 mBm)
<6> (5170000 KHz - 5190000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
<6> (5190000 KHz - 5210000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
<6> (5210000 KHz - 5230000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
<6> (5230000 KHz - 5330000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
<6> (5735000 KHz - 5835000 KHz @ 40000 KHz), (600 mBi, 3000 mBm)
<6>usb 1-1: new high speed USB device using isp1761 and address 2
<6>cfg80211: Calling CRDA for country: US
<6>usbcore: registered new interface driver rtl8187
<6>usb 1-1: configuration #1 chosen from 1 choice
<6>hub 1-1:1.0: USB hub found
<6>hub 1-1:1.0: 3 ports detected
<6>usb 1-1.1: new high speed USB device using isp1761 and address 3
<6>usb 1-1.1: configuration #1 chosen from 1 choice
<7>phy0: Selected rate control algorithm 'minstrel'
<6>phy0: hwaddr 00277080, RTL8187vB (default) V1 + rtl8225z2
<7>phy0: device now idle
<7>phy0: device no longer idle - scanning
<7>phy0: device now idle
<7>phy0: device no longer idle - in use
<7>wlan0: authenticate with AP 01a4b568
<7>wlan0: authenticated
<7>wlan0: associate with AP 01a4b568
<7>wlan0: RX AssocResp from 003e101a (capab=0x411 status=0 aid=2)
<7>wlan0: associated
<7>phy0: Allocated STA 002fbfc4
<7>phy0: Inserted STA 002fbfc4
<7>wlan0: switched to short slot time (BSSID=01a4b568)
iwconfig output:
lo no wireless extensions.
eth0 no wireless extensions.
wmaster0 no wireless extensions.
wlan0 IEEE 802.11bg ESSID:"ACORP"
Mode:Managed Frequency:2.462 GHz Access Point: 00:02:72:74:AC:85
Bit Rate=1 Mb/s Tx-Power=27 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Encryption key:2BAC-63B9-5D99-CF9A-4D39-079F-BB55-5D39 [2]
Power Management:off
Link Quality=61/70 Signal level=-49 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
ifconfig:
eth0 Link encap:Ethernet HWaddr 02:80:AD:20:31:EB
inet addr:192.168.5.1 Bcast:192.168.5.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:40 errors:0 dropped:0 overruns:0 frame:0
TX packets:188 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:4077 (3.9 KiB) TX bytes:17012 (16.6 KiB)
wlan0 Link encap:Ethernet HWaddr 00:12:0E:98:67:FC
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:2 errors:0 dropped:0 overruns:0 frame:0
TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:304 (304.0 B) TX bytes:3932 (3.8 KiB)
wmaster0 Link encap:UNSPEC HWaddr 00-12-0E-98-67-FC-00-00-00-00-00-00-00-00-00-00
UP RUNNING MTU:0 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Neither dhcp nor setting static IP for wlan0 - no ping.
Regards,
Ivan
^ permalink raw reply
* [PATCH] ar9170: fix build error when !CONFIG_AR9170_LEDS
From: Alexander Beregalov @ 2009-07-24 7:55 UTC (permalink / raw)
To: linux-next, chunkeey, linville, linux-wireless; +Cc: Alexander Beregalov
Fix this build error when CONFIG_AR9170_LEDS is not set
drivers/net/wireless/ath/ar9170/main.c:1296: error: 'struct ar9170' has
no member named 'led_work'
Signed-off-by: Alexander Beregalov <a.beregalov@gmail.com>
---
drivers/net/wireless/ath/ar9170/main.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/ath/ar9170/main.c b/drivers/net/wireless/ath/ar9170/main.c
index c7287a8..85a1452 100644
--- a/drivers/net/wireless/ath/ar9170/main.c
+++ b/drivers/net/wireless/ath/ar9170/main.c
@@ -1293,7 +1293,9 @@ static void ar9170_op_stop(struct ieee80211_hw *hw)
flush_workqueue(ar->hw->workqueue);
cancel_delayed_work_sync(&ar->tx_janitor);
+#ifdef CONFIG_AR9170_LEDS
cancel_delayed_work_sync(&ar->led_work);
+#endif
cancel_work_sync(&ar->filter_config_work);
cancel_work_sync(&ar->beacon_work);
mutex_lock(&ar->mutex);
--
1.6.3.3
^ permalink raw reply related
* Re: PCI express card that does AP mode? (abit wlp-01?)
From: Jon Fairbairn @ 2009-07-24 7:39 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <1247775641.6841.16.camel@mj>
Pavel Roskin <proski@gnu.org> writes:
> On Thu, 2009-07-16 at 18:01 +0100, Jon Fairbairn wrote:
>> The distro I'm using (fedora 11) has 2.6.29 -- will the relevant modules
>> build for that, or would I have to build a whole 2.6.31?
>
> You can build compat-wireless, which includes the latest ath5k driver
> backported from the wireless-testing kernel. Alternatively, you can
> build madwifi (be sure to use the trunk snapshot).
OK! I bought one and with compat-wireless-2009-07-20 + hostapd 0.6.9 it
seems to work. I haven't done much testing yet, but I can certainly
connect to it from an eee pc 901 and from a Macbook Air (and from my IBM
X30 so long as I don't use WPA).
For reference: The box says "abit airpace wifi", "pci-e wi-fi card",
"WLP01WCG121095 V0.0B" (on a sticker; this is the only place on the
outside of the box that mentions WPL01), "EAN 4 710933 354359", "UPC 8
43323 00028 5"
lspci -nn says
04:00.0 Ethernet controller [0200]: Atheros Communications Inc. AR242x
802.11abg Wireless PCI Express Adapter [168c:001c] (rev 01)
Does that want to go on the wiki? (I can't access it right now:
http://wireless.kernel.org/en/users/Devices * Connection to 83.246.72.84
Failed )
--
Jón Fairbairn Jon.Fairbairn@cl.cam.ac.uk
^ permalink raw reply
* [RFC] mac80211: add helper to add to the mac80211 workqueue
From: Luis R. Rodriguez @ 2009-07-24 0:59 UTC (permalink / raw)
To: linux-wireless; +Cc: johannes, Luis R. Rodriguez
We add a mac80211 helper for adding work onto the mac80211
workqueue. We then add a warning if we are suspended. At that
point drivers nor mac80211 should have queued work, drivers
and mac80211 should ensure the workqueue will remain clair
until resume.
We don't migrate drivers yet, those can be done on a case by
case basis, but once all drivers are moved we could just make
the workqueue private to prevent future drivers from accessing
it directly.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
include/net/mac80211.h | 12 ++++++++++++
net/mac80211/ibss.c | 6 +++---
net/mac80211/iface.c | 2 +-
net/mac80211/mesh.c | 10 +++++-----
net/mac80211/mesh_hwmp.c | 4 ++--
net/mac80211/mlme.c | 42 +++++++++++++++++++-----------------------
net/mac80211/tx.c | 2 +-
net/mac80211/util.c | 20 ++++++++++++++++++++
8 files changed, 63 insertions(+), 35 deletions(-)
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index 7dd67a1..5804a32 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -1924,6 +1924,18 @@ void ieee80211_iterate_active_interfaces_atomic(struct ieee80211_hw *hw,
void *data);
/**
+ * ieee80211_queue_work - add work onto the mac80211 workqueue
+ *
+ * Drivers and mac80211 should use this to add work onto the mac80211
+ * workqueue instead of adding work directly through queue_work(). This
+ * helper ensures drivers are not queueing work when they should not be.
+ *
+ * @hw: the hardware struct for the interface we are adding work for
+ * @work: the work we want to add onto the mac80211 workqueue
+ */
+int ieee80211_queue_work(struct ieee80211_hw *hw, struct work_struct *work);
+
+/**
* ieee80211_start_tx_ba_session - Start a tx Block Ack session.
* @hw: pointer as obtained from ieee80211_alloc_hw().
* @ra: receiver address of the BA session recipient
diff --git a/net/mac80211/ibss.c b/net/mac80211/ibss.c
index 8e22200..f0573c5 100644
--- a/net/mac80211/ibss.c
+++ b/net/mac80211/ibss.c
@@ -781,7 +781,7 @@ static void ieee80211_ibss_timer(unsigned long data)
}
set_bit(IEEE80211_IBSS_REQ_RUN, &ifibss->request);
- queue_work(local->hw.workqueue, &ifibss->work);
+ ieee80211_queue_work(&local->hw, &ifibss->work);
}
#ifdef CONFIG_PM
@@ -853,7 +853,7 @@ ieee80211_ibss_rx_mgmt(struct ieee80211_sub_if_data *sdata, struct sk_buff *skb)
case IEEE80211_STYPE_PROBE_REQ:
case IEEE80211_STYPE_AUTH:
skb_queue_tail(&sdata->u.ibss.skb_queue, skb);
- queue_work(local->hw.workqueue, &sdata->u.ibss.work);
+ ieee80211_queue_work(&local->hw, &sdata->u.ibss.work);
return RX_QUEUED;
}
@@ -912,7 +912,7 @@ int ieee80211_ibss_join(struct ieee80211_sub_if_data *sdata,
ieee80211_recalc_idle(sdata->local);
set_bit(IEEE80211_IBSS_REQ_RUN, &sdata->u.ibss.request);
- queue_work(sdata->local->hw.workqueue, &sdata->u.ibss.work);
+ ieee80211_queue_work(&sdata->local->hw, &sdata->u.ibss.work);
return 0;
}
diff --git a/net/mac80211/iface.c b/net/mac80211/iface.c
index 2f797a8..9b9b3d4 100644
--- a/net/mac80211/iface.c
+++ b/net/mac80211/iface.c
@@ -312,7 +312,7 @@ static int ieee80211_open(struct net_device *dev)
* to fix this.
*/
if (sdata->vif.type == NL80211_IFTYPE_STATION)
- queue_work(local->hw.workqueue, &sdata->u.mgd.work);
+ ieee80211_queue_work(&local->hw, &sdata->u.mgd.work);
netif_tx_start_all_queues(dev);
diff --git a/net/mac80211/mesh.c b/net/mac80211/mesh.c
index 8a97b14..84546b2 100644
--- a/net/mac80211/mesh.c
+++ b/net/mac80211/mesh.c
@@ -54,7 +54,7 @@ static void ieee80211_mesh_housekeeping_timer(unsigned long data)
return;
}
- queue_work(local->hw.workqueue, &ifmsh->work);
+ ieee80211_queue_work(local->hw.workqueue, &ifmsh->work);
}
/**
@@ -357,7 +357,7 @@ static void ieee80211_mesh_path_timer(unsigned long data)
return;
}
- queue_work(local->hw.workqueue, &ifmsh->work);
+ ieee80211_queue_work(local->hw.workqueue, &ifmsh->work);
}
struct mesh_table *mesh_table_grow(struct mesh_table *tbl)
@@ -471,7 +471,7 @@ void ieee80211_start_mesh(struct ieee80211_sub_if_data *sdata)
struct ieee80211_local *local = sdata->local;
ifmsh->housekeeping = true;
- queue_work(local->hw.workqueue, &ifmsh->work);
+ ieee80211_queue_work(local->hw.workqueue, &ifmsh->work);
ieee80211_bss_info_change_notify(sdata, BSS_CHANGED_BEACON |
BSS_CHANGED_BEACON_ENABLED);
}
@@ -619,7 +619,7 @@ void ieee80211_mesh_notify_scan_completed(struct ieee80211_local *local)
rcu_read_lock();
list_for_each_entry_rcu(sdata, &local->interfaces, list)
if (ieee80211_vif_is_mesh(&sdata->vif))
- queue_work(local->hw.workqueue, &sdata->u.mesh.work);
+ ieee80211_queue_work(local->hw.workqueue, &sdata->u.mesh.work);
rcu_read_unlock();
}
@@ -692,7 +692,7 @@ ieee80211_mesh_rx_mgmt(struct ieee80211_sub_if_data *sdata, struct sk_buff *skb)
case IEEE80211_STYPE_PROBE_RESP:
case IEEE80211_STYPE_BEACON:
skb_queue_tail(&ifmsh->skb_queue, skb);
- queue_work(local->hw.workqueue, &ifmsh->work);
+ ieee80211_queue_work(local->hw.workqueue, &ifmsh->work);
return RX_QUEUED;
}
diff --git a/net/mac80211/mesh_hwmp.c b/net/mac80211/mesh_hwmp.c
index e93c37e..11ab71a 100644
--- a/net/mac80211/mesh_hwmp.c
+++ b/net/mac80211/mesh_hwmp.c
@@ -660,14 +660,14 @@ static void mesh_queue_preq(struct mesh_path *mpath, u8 flags)
spin_unlock(&ifmsh->mesh_preq_queue_lock);
if (time_after(jiffies, ifmsh->last_preq + min_preq_int_jiff(sdata)))
- queue_work(sdata->local->hw.workqueue, &ifmsh->work);
+ ieee80211_queue_work(sdata->local->hw.workqueue, &ifmsh->work);
else if (time_before(jiffies, ifmsh->last_preq)) {
/* avoid long wait if did not send preqs for a long time
* and jiffies wrapped around
*/
ifmsh->last_preq = jiffies - min_preq_int_jiff(sdata) - 1;
- queue_work(sdata->local->hw.workqueue, &ifmsh->work);
+ ieee80211_queue_work(sdata->local->hw.workqueue, &ifmsh->work);
} else
mod_timer(&ifmsh->mesh_path_timer, ifmsh->last_preq +
min_preq_int_jiff(sdata));
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index db0b4b2..3da36d2 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -565,7 +565,7 @@ static void ieee80211_chswitch_timer(unsigned long data)
return;
}
- queue_work(sdata->local->hw.workqueue, &ifmgd->chswitch_work);
+ ieee80211_queue_work(&sdata->local->hw, &ifmgd->chswitch_work);
}
void ieee80211_sta_process_chanswitch(struct ieee80211_sub_if_data *sdata,
@@ -597,7 +597,7 @@ void ieee80211_sta_process_chanswitch(struct ieee80211_sub_if_data *sdata,
sdata->local->csa_channel = new_ch;
if (sw_elem->count <= 1) {
- queue_work(sdata->local->hw.workqueue, &ifmgd->chswitch_work);
+ ieee80211_queue_work(&sdata->local->hw, &ifmgd->chswitch_work);
} else {
ieee80211_stop_queues_by_reason(&sdata->local->hw,
IEEE80211_QUEUE_STOP_REASON_CSA);
@@ -763,7 +763,7 @@ void ieee80211_dynamic_ps_timer(unsigned long data)
if (local->quiescing)
return;
- queue_work(local->hw.workqueue, &local->dynamic_ps_enable_work);
+ ieee80211_queue_work(&local->hw, &local->dynamic_ps_enable_work);
}
/* MLME */
@@ -950,7 +950,7 @@ ieee80211_direct_probe(struct ieee80211_sub_if_data *sdata,
* due to work needing to be done. Hence, queue the STAs work
* again for that.
*/
- queue_work(local->hw.workqueue, &ifmgd->work);
+ ieee80211_queue_work(&local->hw, &ifmgd->work);
return RX_MGMT_CFG80211_AUTH_TO;
}
@@ -995,7 +995,7 @@ ieee80211_authenticate(struct ieee80211_sub_if_data *sdata,
* due to work needing to be done. Hence, queue the STAs work
* again for that.
*/
- queue_work(local->hw.workqueue, &ifmgd->work);
+ ieee80211_queue_work(&local->hw, &ifmgd->work);
return RX_MGMT_CFG80211_AUTH_TO;
}
@@ -1124,7 +1124,7 @@ ieee80211_associate(struct ieee80211_sub_if_data *sdata,
* due to work needing to be done. Hence, queue the STAs work
* again for that.
*/
- queue_work(local->hw.workqueue, &ifmgd->work);
+ ieee80211_queue_work(&local->hw, &ifmgd->work);
return RX_MGMT_CFG80211_ASSOC_TO;
}
@@ -1232,8 +1232,7 @@ void ieee80211_beacon_loss(struct ieee80211_vif *vif)
{
struct ieee80211_sub_if_data *sdata = vif_to_sdata(vif);
- queue_work(sdata->local->hw.workqueue,
- &sdata->u.mgd.beacon_loss_work);
+ ieee80211_queue_work(&sdata->local->hw, &sdata->u.mgd.beacon_loss_work);
}
EXPORT_SYMBOL(ieee80211_beacon_loss);
@@ -1888,7 +1887,7 @@ ieee80211_rx_result ieee80211_sta_rx_mgmt(struct ieee80211_sub_if_data *sdata,
case IEEE80211_STYPE_DISASSOC:
case IEEE80211_STYPE_ACTION:
skb_queue_tail(&sdata->u.mgd.skb_queue, skb);
- queue_work(local->hw.workqueue, &sdata->u.mgd.work);
+ ieee80211_queue_work(&local->hw, &sdata->u.mgd.work);
return RX_QUEUED;
}
@@ -2023,7 +2022,7 @@ static void ieee80211_sta_timer(unsigned long data)
return;
}
- queue_work(local->hw.workqueue, &ifmgd->work);
+ ieee80211_queue_work(&local->hw, &ifmgd->work);
}
static void ieee80211_sta_work(struct work_struct *work)
@@ -2048,13 +2047,11 @@ static void ieee80211_sta_work(struct work_struct *work)
return;
/*
- * Nothing should have been stuffed into the workqueue during
- * the suspend->resume cycle. If this WARN is seen then there
- * is a bug with either the driver suspend or something in
- * mac80211 stuffing into the workqueue which we haven't yet
- * cleared during mac80211's suspend cycle.
+ * ieee80211_queue_work() should have picked up most cases,
+ * here we'll pick the the rest.
*/
- if (WARN_ON(local->suspended))
+ if (WARN(local->suspended, "STA MLME work scheduled while "
+ "going to suspend\n"))
return;
ifmgd = &sdata->u.mgd;
@@ -2193,8 +2190,7 @@ static void ieee80211_sta_bcn_mon_timer(unsigned long data)
if (local->quiescing)
return;
- queue_work(sdata->local->hw.workqueue,
- &sdata->u.mgd.beacon_loss_work);
+ ieee80211_queue_work(&sdata->local->hw, &sdata->u.mgd.beacon_loss_work);
}
static void ieee80211_sta_conn_mon_timer(unsigned long data)
@@ -2207,7 +2203,7 @@ static void ieee80211_sta_conn_mon_timer(unsigned long data)
if (local->quiescing)
return;
- queue_work(local->hw.workqueue, &ifmgd->monitor_work);
+ ieee80211_queue_work(&local->hw, &ifmgd->monitor_work);
}
static void ieee80211_sta_monitor_work(struct work_struct *work)
@@ -2226,10 +2222,10 @@ static void ieee80211_restart_sta_timer(struct ieee80211_sub_if_data *sdata)
IEEE80211_STA_CONNECTION_POLL);
/* let's probe the connection once */
- queue_work(sdata->local->hw.workqueue,
+ ieee80211_queue_work(&sdata->local->hw,
&sdata->u.mgd.monitor_work);
/* and do all the other regular work too */
- queue_work(sdata->local->hw.workqueue,
+ ieee80211_queue_work(&sdata->local->hw,
&sdata->u.mgd.work);
}
}
@@ -2389,7 +2385,7 @@ int ieee80211_mgd_auth(struct ieee80211_sub_if_data *sdata,
list_add(&wk->list, &sdata->u.mgd.work_list);
mutex_unlock(&ifmgd->mtx);
- queue_work(sdata->local->hw.workqueue, &sdata->u.mgd.work);
+ ieee80211_queue_work(&sdata->local->hw, &sdata->u.mgd.work);
return 0;
}
@@ -2462,7 +2458,7 @@ int ieee80211_mgd_assoc(struct ieee80211_sub_if_data *sdata,
else
ifmgd->flags &= ~IEEE80211_STA_CONTROL_PORT;
- queue_work(sdata->local->hw.workqueue, &sdata->u.mgd.work);
+ ieee80211_queue_work(&sdata->local->hw, &sdata->u.mgd.work);
err = 0;
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index c11cbbd..8369fe2 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -1400,7 +1400,7 @@ static void ieee80211_xmit(struct ieee80211_sub_if_data *sdata,
if (local->hw.conf.flags & IEEE80211_CONF_PS) {
ieee80211_stop_queues_by_reason(&local->hw,
IEEE80211_QUEUE_STOP_REASON_PS);
- queue_work(local->hw.workqueue,
+ ieee80211_queue_work(&local->hw,
&local->dynamic_ps_disable_work);
}
diff --git a/net/mac80211/util.c b/net/mac80211/util.c
index 7fc5584..1375511 100644
--- a/net/mac80211/util.c
+++ b/net/mac80211/util.c
@@ -498,6 +498,25 @@ void ieee80211_iterate_active_interfaces_atomic(
}
EXPORT_SYMBOL_GPL(ieee80211_iterate_active_interfaces_atomic);
+int ieee80211_queue_work(struct ieee80211_hw *hw, struct work_struct *work)
+{
+ struct ieee80211_local *local = hw_to_local(hw);
+
+ /*
+ * Nothing should have been stuffed into the workqueue during
+ * the suspend->resume cycle. If this WARN is seen then there
+ * is a bug with either the driver suspend or something in
+ * mac80211 stuffing into the workqueue which we haven't yet
+ * cleared during mac80211's suspend cycle.
+ */
+ if (WARN(local->suspended, "queueing ieee80211 work while "
+ "going to suspend\n"))
+ return -EINVAL;
+
+ return queue_work(hw->workqueue, work);
+}
+EXPORT_SYMBOL_GPL(ieee80211_queue_work);
+
void ieee802_11_parse_elems(u8 *start, size_t len,
struct ieee802_11_elems *elems)
{
@@ -1101,3 +1120,4 @@ int ieee80211_reconfig(struct ieee80211_local *local)
#endif
return 0;
}
+
--
1.6.3.3
^ permalink raw reply related
* Re: Generic events for wake up from S1-S4
From: ykzhao @ 2009-07-24 0:53 UTC (permalink / raw)
To: Rafael J. Wysocki, Henrique de Moraes Holschuh
Cc: Henrique de Moraes Holschuh, Pavel Machek, Luis R. Rodriguez,
linux-kernel@vger.kernel.org, Johannes Berg, John W. Linville,
Jouni Malinen, linux-wireless, Stephen Chen,
ACPI Devel Maling List, pm list
In-Reply-To: <200907232328.03566.rjw@sisk.pl>
On Fri, 2009-07-24 at 05:27 +0800, Rafael J. Wysocki wrote:
> On Thursday 23 July 2009, Henrique de Moraes Holschuh wrote:
> > On Thu, 23 Jul 2009, Pavel Machek wrote:
> > > On Thu 2009-07-23 16:45:22, Henrique de Moraes Holschuh wrote:
> > > > On Thu, 23 Jul 2009, Pavel Machek wrote:
> > > > > > > Note that the "why" is unreliable by design. Network driver will
> > > > > > > ignore WoL during run-time, right?
> > > > > >
> > > > > > "Why" is unrealible? I don't follow your reasoning. It should be as
> > > > > > reliable as "who"...
> > > > >
> > > > > See above. The wakeup events race with each other.
> > > >
> > > > We deliver them all. It is that simple. The rest is up to userspace.
> > >
> > > Ok, but then we should not be talking about wake up events,
> > > but... events.
> > >
> > > Like "lid opened", "wake packet came", ... . And deliver them even
> > > when they happen during run-time. That's okay with me.
> >
> > Well, we *already* deliver "lid opened" when the lid is opened, regardless
> > of it waking up the computer or not. But we are missing a way to deliver
> > other classes of wakeup events.
> >
> > I know of at least these (incomplete list):
> >
> > 1. network-initiated wakeup
> > a. wired
> > b. wireless
> > c. long-range wireless
> >
> > 2. platform health/condition alarms
> > a. battery alarm (two levels, warning and emergency)
> > b. thermal alarm (two levels, warning and emergency)
> > (we need these as generic alarms, not just reason-for-wakeup)
> >
> > 3. device (or device tree) hotplug/hotunplug
> > a. hotunplug request or notification
> > (we deliver the request/notification, but we don't know we should
> > go back to sleep, so all we are missing is the reason-for-wakeup
> > event)
> >
> > 4. management
> > a. wake-up/power on clock
> > b. remote management command (IMPI, etc)
> > c. intrusion alarm
> > d. theft alarm
> >
> > None of those have a standard interface to notify userspace of the reason of
> > the wake up AFAIK. Many of these want a generic event interface to be
> > delivered not just as reason-for-wakeup, but also as runtime events.
> >
> > And I guess we should also tell userspace what state we are waking up from
> > (S5 clean state, S5/S4 hibernation, S3), sometimes it matters.
>
> Agreed, and same for the above.
>
> So, what in your opinion would be the best way to expose this information?
Maybe we should firstly define what event should be delivered to user
space when it is resumed from S1--S4.
And another issue who is in charge of sending the event? By the specific
device or ACPI notification?
Thanks.
>
> Rafael
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" 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
* [PATCH] mac80211: fix MLME issuing of probe requests while scanning
From: Luis R. Rodriguez @ 2009-07-23 23:37 UTC (permalink / raw)
To: johannes, linville
Cc: linux-wireless, rossi.f, Luis R. Rodriguez, Christian Lamparter,
Larry Finger
We were issuing probe requests to the associated AP on the wrong
band by having our beacon timer loss trigger while we are scanning.
When we would scan the timer could hit and force us to send a
probe request to the AP but with a chance we'd be on the wrong band.
This leads to finding no usable bitrate but we should not get so
far on the xmit path. We should not be trying to send these probe
request frames so prevent ieee80211_mgd_probe_ap() from sending
these.
As it turns out all callers of ieee80211_mgd_probe_ap() need this
check so we just move the scan check there. This means we can remove
the recenlty added check during ieee80211_sta_monitor_work().
Additionally we now fix a race condition added by the patch
"mac80211: do not monitor the connection while scanning" which
had the same check in ieee80211_sta_conn_mon_timer(). The race
happens because the timer routine *does* a valid check for
scanning but after it queues work into the mac80211 workqueue
the work callback can kick off with scanning enabled and cause
the same issue we were trying to avoid.
The more appropriate solution would be to disable the respective
timers during scan and re-enable them after scan but requires more
complex code and testing.
Cc: Christian Lamparter <chunkeey@web.de>
Cc: Larry Finger <Larry.Finger@lwfinger.net>
Reported-by: Fabio Rossi <rossi.f@inwind.it>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
net/mac80211/mlme.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 523c0d9..db0b4b2 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -1166,6 +1166,9 @@ static void ieee80211_mgd_probe_ap(struct ieee80211_sub_if_data *sdata,
if (!netif_running(sdata->dev))
return;
+ if (sdata->local->sw_scanning || sdata->local->hw_scanning)
+ return;
+
mutex_lock(&ifmgd->mtx);
if (!ifmgd->associated)
@@ -2213,9 +2216,6 @@ static void ieee80211_sta_monitor_work(struct work_struct *work)
container_of(work, struct ieee80211_sub_if_data,
u.mgd.monitor_work);
- if (sdata->local->sw_scanning || sdata->local->hw_scanning)
- return;
-
ieee80211_mgd_probe_ap(sdata, false);
}
--
1.6.3.3
^ permalink raw reply related
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