* Re: USB wireless support for ARM device and old kernel version
From: Johannes Berg @ 2009-08-21 12:39 UTC (permalink / raw)
To: Miguel Garcia-Lopez; +Cc: linux-wireless
In-Reply-To: <55FEAD01-712B-4165-9F4D-260BDC3CA14A@envitel.com>
[-- Attachment #1: Type: text/plain, Size: 364 bytes --]
On Fri, 2009-08-21 at 14:12 +0200, Miguel Garcia-Lopez wrote:
> Any hints on what to try or driver sources distributions I could try
> to compile against my 2.6.10 kernel?
There are none. 2.6.10 basically has no wireless drivers. You can try to
backport compat-wireless, but you're on your own. Just upgrade your
kernel to 2.6.27 or later.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH] rtl8187: always set MSR_LINK_ENEDCA flag with RTL8187B
From: Larry Finger @ 2009-08-21 12:29 UTC (permalink / raw)
To: Hin-Tak Leung
Cc: Herton Ronaldo Krzesinski, linux-wireless, John W. Linville,
Hin-Tak Leung, Rafael J. Wysocki
In-Reply-To: <3ace41890908202054j62fda37ei64262890c6959f95@mail.gmail.com>
Hin-Tak Leung wrote:
>
> This seems to be related to a problem I reported a while back - see
> the "compat-wireless won't associate on 2nd load" thread, I wrote on
> May 31. Supposedly I had that problem about a week before that, the
> date on the patch from Johannes is May 14, but I just went back to
> look at the mailing list archive and it looks like there were some
> problem with applying and John did some fix on 20th. So it seems that
> it might be the source of my not being able to load compat-wireless a
> 2nd time; and the description of the problem sounds like it too.
>
> Sorry I haven't been doing much with compat-wireless lately, so I have
> no firm data whether I have the same problem or not since May - that
> problem only happens if I switch from one compat-wireless to another
> compat-wireless, without rebooting - while I have tried
> compat-wireless in the last two months, I don't think I have followed
> compat-wireless as closely as I should to have two successive
> compat-wireless. I probably should go and have a try now.
This problem was quite strange. My system would fail when the RTL8187B
was inserted when the system booted. Unloading the driver did not
help, but removing/reinstalling the card fixed the problem. As all my
testing had been to install the card after booting, I never saw the
failure.
Larry
^ permalink raw reply
* USB wireless support for ARM device and old kernel version
From: Miguel Garcia-Lopez @ 2009-08-21 12:12 UTC (permalink / raw)
To: linux-wireless
Dear all,
We are developing an embedded linux platform using an ARM-based micro
and other DSPs from Texas Instruments. Among other things, it supports
USB.
We now need to add a wifi interface to the device, so we're thinking
on using a USB wireless device. Now, the problem seems to be re are
running a 2.6.10 kernel and most of the suff/drivers I found require
much recent versions to work with.
I'm thinking on trying to compile the source code for some driver(s)
against our kernel sources, but could not really find any working
sources since most available driver code and wireless infraestructure
seems to either be already merged into more recent versions of the
kernel, or require it for compiling.
Any hints on what to try or driver sources distributions I could try
to compile against my 2.6.10 kernel?
Thanks in advance!
--
Miguel García López
Director Técnico
Technical Manager
.......................................................
E N V I T E L
Parque Científico de Madrid - Local 105
PTM - C/Santiago Grisolía, 2
28760 Tres Cantos - Madrid - Spain
T: +34 91 334 06 56
F: +34 91 358 52 36
M: +34 649 91 60 60
.......................................
mgarcia@envitel.com
www.envitel.com
^ permalink raw reply
* Re: Abour linux driver supports BCM4325
From: Larry Finger @ 2009-08-21 12:13 UTC (permalink / raw)
To: feng tian; +Cc: linux-wireless
In-Reply-To: <f42a38140908202319y5c352aa3s37fec67e5cb8d7a3@mail.gmail.com>
feng tian wrote:
> Dear All,
>
> We are working on a project which supports the BCM4325 linux wireless
> driver. The interface between the BCM chip and SOC(pxa310) is SDIO.
> I did some searches online and found that there is no available driver
> for this chip. Do I have to implement this myself? Is there anyone can
> provide us some related materials? Thanks very much.
The code for the LP PHY, which I believe is present in the 4325, is
just being written. At the moment, the chip is able to receive on some
channels, and may be able to transmit. These results are reported on
this mailing list, and the code is being applied to the wireless
testing git tree.
Larry
^ permalink raw reply
* [PATCH] cfg80211: clean up properly on interface type change
From: Johannes Berg @ 2009-08-21 10:39 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless
When the interface type changes while connected, and the
driver does not require the interface to be down for a
type change, it is currently possible to get very strange
results unless the driver takes special care, which it
shouldn't have to.
To fix this, take care to disconnect/leave IBSS when
changing the interface type -- even if the driver may fail
the call. Also process all events that may be pending to
avoid running into a situation where an event is reported
but only processed after the type has already changed,
which would lead to missing events and warnings.
A side effect of this is that you will have disconnected
or left the IBSS even if the mode change ultimately fails,
but since the intention was to change it and thus leave or
disconnect, this is not a problem.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
---
net/wireless/core.c | 53 ----------------------
net/wireless/core.h | 4 +
net/wireless/nl80211.c | 16 ------
net/wireless/util.c | 105 +++++++++++++++++++++++++++++++++++++++++++++
net/wireless/wext-compat.c | 16 +-----
5 files changed, 114 insertions(+), 80 deletions(-)
--- wireless-testing.orig/net/wireless/core.c 2009-08-21 12:12:03.000000000 +0200
+++ wireless-testing/net/wireless/core.c 2009-08-21 12:23:54.000000000 +0200
@@ -293,68 +293,17 @@ static void cfg80211_rfkill_sync_work(st
cfg80211_rfkill_set_block(rdev, rfkill_blocked(rdev->rfkill));
}
-static void cfg80211_process_events(struct wireless_dev *wdev)
-{
- struct cfg80211_event *ev;
- unsigned long flags;
-
- spin_lock_irqsave(&wdev->event_lock, flags);
- while (!list_empty(&wdev->event_list)) {
- ev = list_first_entry(&wdev->event_list,
- struct cfg80211_event, list);
- list_del(&ev->list);
- spin_unlock_irqrestore(&wdev->event_lock, flags);
-
- wdev_lock(wdev);
- switch (ev->type) {
- case EVENT_CONNECT_RESULT:
- __cfg80211_connect_result(
- wdev->netdev, ev->cr.bssid,
- ev->cr.req_ie, ev->cr.req_ie_len,
- ev->cr.resp_ie, ev->cr.resp_ie_len,
- ev->cr.status,
- ev->cr.status == WLAN_STATUS_SUCCESS,
- NULL);
- break;
- case EVENT_ROAMED:
- __cfg80211_roamed(wdev, ev->rm.bssid,
- ev->rm.req_ie, ev->rm.req_ie_len,
- ev->rm.resp_ie, ev->rm.resp_ie_len);
- break;
- case EVENT_DISCONNECTED:
- __cfg80211_disconnected(wdev->netdev,
- ev->dc.ie, ev->dc.ie_len,
- ev->dc.reason, true);
- break;
- case EVENT_IBSS_JOINED:
- __cfg80211_ibss_joined(wdev->netdev, ev->ij.bssid);
- break;
- }
- wdev_unlock(wdev);
-
- kfree(ev);
-
- spin_lock_irqsave(&wdev->event_lock, flags);
- }
- spin_unlock_irqrestore(&wdev->event_lock, flags);
-}
-
static void cfg80211_event_work(struct work_struct *work)
{
struct cfg80211_registered_device *rdev;
- struct wireless_dev *wdev;
rdev = container_of(work, struct cfg80211_registered_device,
event_work);
rtnl_lock();
cfg80211_lock_rdev(rdev);
- mutex_lock(&rdev->devlist_mtx);
- list_for_each_entry(wdev, &rdev->netdev_list, list)
- cfg80211_process_events(wdev);
-
- mutex_unlock(&rdev->devlist_mtx);
+ cfg80211_process_rdev_events(rdev);
cfg80211_unlock_rdev(rdev);
rtnl_unlock();
}
--- wireless-testing.orig/net/wireless/core.h 2009-08-21 12:17:02.000000000 +0200
+++ wireless-testing/net/wireless/core.h 2009-08-21 12:23:54.000000000 +0200
@@ -372,6 +372,10 @@ void cfg80211_sme_disassoc(struct net_de
void __cfg80211_scan_done(struct work_struct *wk);
void ___cfg80211_scan_done(struct cfg80211_registered_device *rdev, bool leak);
void cfg80211_upload_connect_keys(struct wireless_dev *wdev);
+int cfg80211_change_iface(struct cfg80211_registered_device *rdev,
+ struct net_device *dev, enum nl80211_iftype ntype,
+ u32 *flags, struct vif_params *params);
+void cfg80211_process_rdev_events(struct cfg80211_registered_device *rdev);
struct ieee80211_channel *
rdev_fixed_channel(struct cfg80211_registered_device *rdev,
--- wireless-testing.orig/net/wireless/nl80211.c 2009-08-21 12:12:03.000000000 +0200
+++ wireless-testing/net/wireless/nl80211.c 2009-08-21 12:23:54.000000000 +0200
@@ -977,12 +977,6 @@ static int nl80211_set_interface(struct
}
}
- if (!rdev->ops->change_virtual_intf ||
- !(rdev->wiphy.interface_modes & (1 << ntype))) {
- err = -EOPNOTSUPP;
- goto unlock;
- }
-
if (info->attrs[NL80211_ATTR_MESH_ID]) {
if (ntype != NL80211_IFTYPE_MESH_POINT) {
err = -EINVAL;
@@ -1008,18 +1002,10 @@ static int nl80211_set_interface(struct
}
if (change)
- err = rdev->ops->change_virtual_intf(&rdev->wiphy, dev,
- ntype, flags, ¶ms);
+ err = cfg80211_change_iface(rdev, dev, ntype, flags, ¶ms);
else
err = 0;
- WARN_ON(!err && dev->ieee80211_ptr->iftype != ntype);
-
- if (!err && (ntype != otype)) {
- if (otype == NL80211_IFTYPE_ADHOC)
- cfg80211_clear_ibss(dev, false);
- }
-
unlock:
dev_put(dev);
cfg80211_unlock_rdev(rdev);
--- wireless-testing.orig/net/wireless/util.c 2009-08-21 12:12:03.000000000 +0200
+++ wireless-testing/net/wireless/util.c 2009-08-21 12:23:54.000000000 +0200
@@ -574,3 +574,108 @@ void cfg80211_upload_connect_keys(struct
kfree(wdev->connect_keys);
wdev->connect_keys = NULL;
}
+
+static void cfg80211_process_wdev_events(struct wireless_dev *wdev)
+{
+ struct cfg80211_event *ev;
+ unsigned long flags;
+
+ spin_lock_irqsave(&wdev->event_lock, flags);
+ while (!list_empty(&wdev->event_list)) {
+ ev = list_first_entry(&wdev->event_list,
+ struct cfg80211_event, list);
+ list_del(&ev->list);
+ spin_unlock_irqrestore(&wdev->event_lock, flags);
+
+ wdev_lock(wdev);
+ switch (ev->type) {
+ case EVENT_CONNECT_RESULT:
+ __cfg80211_connect_result(
+ wdev->netdev, ev->cr.bssid,
+ ev->cr.req_ie, ev->cr.req_ie_len,
+ ev->cr.resp_ie, ev->cr.resp_ie_len,
+ ev->cr.status,
+ ev->cr.status == WLAN_STATUS_SUCCESS,
+ NULL);
+ break;
+ case EVENT_ROAMED:
+ __cfg80211_roamed(wdev, ev->rm.bssid,
+ ev->rm.req_ie, ev->rm.req_ie_len,
+ ev->rm.resp_ie, ev->rm.resp_ie_len);
+ break;
+ case EVENT_DISCONNECTED:
+ __cfg80211_disconnected(wdev->netdev,
+ ev->dc.ie, ev->dc.ie_len,
+ ev->dc.reason, true);
+ break;
+ case EVENT_IBSS_JOINED:
+ __cfg80211_ibss_joined(wdev->netdev, ev->ij.bssid);
+ break;
+ }
+ wdev_unlock(wdev);
+
+ kfree(ev);
+
+ spin_lock_irqsave(&wdev->event_lock, flags);
+ }
+ spin_unlock_irqrestore(&wdev->event_lock, flags);
+}
+
+void cfg80211_process_rdev_events(struct cfg80211_registered_device *rdev)
+{
+ struct wireless_dev *wdev;
+
+ ASSERT_RTNL();
+ ASSERT_RDEV_LOCK(rdev);
+
+ mutex_lock(&rdev->devlist_mtx);
+
+ list_for_each_entry(wdev, &rdev->netdev_list, list)
+ cfg80211_process_wdev_events(wdev);
+
+ mutex_unlock(&rdev->devlist_mtx);
+}
+
+int cfg80211_change_iface(struct cfg80211_registered_device *rdev,
+ struct net_device *dev, enum nl80211_iftype ntype,
+ u32 *flags, struct vif_params *params)
+{
+ int err;
+ enum nl80211_iftype otype = dev->ieee80211_ptr->iftype;
+
+ ASSERT_RDEV_LOCK(rdev);
+
+ /* don't support changing VLANs, you just re-create them */
+ if (otype == NL80211_IFTYPE_AP_VLAN)
+ return -EOPNOTSUPP;
+
+ if (!rdev->ops->change_virtual_intf ||
+ !(rdev->wiphy.interface_modes & (1 << ntype)))
+ return -EOPNOTSUPP;
+
+ if (ntype != otype) {
+ switch (otype) {
+ case NL80211_IFTYPE_ADHOC:
+ cfg80211_leave_ibss(rdev, dev, false);
+ break;
+ case NL80211_IFTYPE_STATION:
+ cfg80211_disconnect(rdev, dev,
+ WLAN_REASON_DEAUTH_LEAVING, true);
+ break;
+ case NL80211_IFTYPE_MESH_POINT:
+ /* mesh should be handled? */
+ break;
+ default:
+ break;
+ }
+
+ cfg80211_process_rdev_events(rdev);
+ }
+
+ err = rdev->ops->change_virtual_intf(&rdev->wiphy, dev,
+ ntype, flags, params);
+
+ WARN_ON(!err && dev->ieee80211_ptr->iftype != ntype);
+
+ return err;
+}
--- wireless-testing.orig/net/wireless/wext-compat.c 2009-08-21 12:12:03.000000000 +0200
+++ wireless-testing/net/wireless/wext-compat.c 2009-08-21 12:23:54.000000000 +0200
@@ -70,18 +70,8 @@ int cfg80211_wext_siwmode(struct net_dev
enum nl80211_iftype type;
int ret;
- if (!wdev)
- return -EOPNOTSUPP;
-
rdev = wiphy_to_dev(wdev->wiphy);
- if (!rdev->ops->change_virtual_intf)
- return -EOPNOTSUPP;
-
- /* don't support changing VLANs, you just re-create them */
- if (wdev->iftype == NL80211_IFTYPE_AP_VLAN)
- return -EOPNOTSUPP;
-
switch (*mode) {
case IW_MODE_INFRA:
type = NL80211_IFTYPE_STATION;
@@ -104,9 +94,9 @@ int cfg80211_wext_siwmode(struct net_dev
memset(&vifparams, 0, sizeof(vifparams));
- ret = rdev->ops->change_virtual_intf(wdev->wiphy, dev, type,
- NULL, &vifparams);
- WARN_ON(!ret && wdev->iftype != type);
+ cfg80211_lock_rdev(rdev);
+ ret = cfg80211_change_iface(rdev, dev, type, NULL, &vifparams);
+ cfg80211_unlock_rdev(rdev);
return ret;
}
^ permalink raw reply
* [PATCH] cfg80211: make spurious warnings less likely, configurable
From: Johannes Berg @ 2009-08-21 10:23 UTC (permalink / raw)
To: John Linville; +Cc: Bob Copeland, linux-wireless
Bob reported that he got warnings in IBSS mode about
the ssid_len being zero on a joined event, but only
when kmemcheck was enabled. This appears to be due
to a race condition between drivers and userspace,
when the driver reports joined but the user in the
meantime decided to leave the IBSS again, the warning
would trigger. This was made more likely by kmemcheck
delaying the code that does the check and sends the
event.
So first, make the warning trigger closer to the
driver, which means it's not locked, but since only
the warning depends on it that's ok.
And secondly, users will not want to have spurious
warnings at all, so make those that are known to be
racy in such a way configurable.
Reported-by: Bob Copeland <me@bobcopeland.com>
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
---
net/wireless/Kconfig | 17 +++++++++++++++++
net/wireless/core.h | 11 +++++++++++
net/wireless/ibss.c | 4 +++-
net/wireless/sme.c | 12 +++++++++---
4 files changed, 40 insertions(+), 4 deletions(-)
--- wireless-testing.orig/net/wireless/sme.c 2009-08-21 12:12:03.000000000 +0200
+++ wireless-testing/net/wireless/sme.c 2009-08-21 12:17:38.000000000 +0200
@@ -351,7 +351,7 @@ void __cfg80211_connect_result(struct ne
if (WARN_ON(wdev->iftype != NL80211_IFTYPE_STATION))
return;
- if (WARN_ON(wdev->sme_state != CFG80211_SME_CONNECTING))
+ if (wdev->sme_state != CFG80211_SME_CONNECTING)
return;
nl80211_send_connect_result(wiphy_to_dev(wdev->wiphy), dev,
@@ -443,6 +443,8 @@ void cfg80211_connect_result(struct net_
struct cfg80211_event *ev;
unsigned long flags;
+ CFG80211_DEV_WARN_ON(wdev->sme_state != CFG80211_SME_CONNECTING);
+
ev = kzalloc(sizeof(*ev) + req_ie_len + resp_ie_len, gfp);
if (!ev)
return;
@@ -478,7 +480,7 @@ void __cfg80211_roamed(struct wireless_d
if (WARN_ON(wdev->iftype != NL80211_IFTYPE_STATION))
return;
- if (WARN_ON(wdev->sme_state != CFG80211_SME_CONNECTED))
+ if (wdev->sme_state != CFG80211_SME_CONNECTED)
return;
/* internal error -- how did we get to CONNECTED w/o BSS? */
@@ -537,6 +539,8 @@ void cfg80211_roamed(struct net_device *
struct cfg80211_event *ev;
unsigned long flags;
+ CFG80211_DEV_WARN_ON(wdev->sme_state != CFG80211_SME_CONNECTED);
+
ev = kzalloc(sizeof(*ev) + req_ie_len + resp_ie_len, gfp);
if (!ev)
return;
@@ -572,7 +576,7 @@ void __cfg80211_disconnected(struct net_
if (WARN_ON(wdev->iftype != NL80211_IFTYPE_STATION))
return;
- if (WARN_ON(wdev->sme_state != CFG80211_SME_CONNECTED))
+ if (wdev->sme_state != CFG80211_SME_CONNECTED)
return;
if (wdev->current_bss) {
@@ -636,6 +640,8 @@ void cfg80211_disconnected(struct net_de
struct cfg80211_event *ev;
unsigned long flags;
+ CFG80211_DEV_WARN_ON(wdev->sme_state != CFG80211_SME_CONNECTED);
+
ev = kzalloc(sizeof(*ev) + ie_len, gfp);
if (!ev)
return;
--- wireless-testing.orig/net/wireless/ibss.c 2009-08-21 12:12:03.000000000 +0200
+++ wireless-testing/net/wireless/ibss.c 2009-08-21 12:17:30.000000000 +0200
@@ -22,7 +22,7 @@ void __cfg80211_ibss_joined(struct net_d
if (WARN_ON(wdev->iftype != NL80211_IFTYPE_ADHOC))
return;
- if (WARN_ON(!wdev->ssid_len))
+ if (!wdev->ssid_len)
return;
bss = cfg80211_get_bss(wdev->wiphy, NULL, bssid,
@@ -58,6 +58,8 @@ void cfg80211_ibss_joined(struct net_dev
struct cfg80211_event *ev;
unsigned long flags;
+ CFG80211_DEV_WARN_ON(!wdev->ssid_len);
+
ev = kzalloc(sizeof(*ev), gfp);
if (!ev)
return;
--- wireless-testing.orig/net/wireless/Kconfig 2009-08-21 12:12:19.000000000 +0200
+++ wireless-testing/net/wireless/Kconfig 2009-08-21 12:14:31.000000000 +0200
@@ -17,6 +17,23 @@ config NL80211_TESTMODE
Say N.
+config CFG80211_DEVELOPER_WARNINGS
+ bool "enable developer warnings"
+ depends on CFG80211
+ default n
+ help
+ This option enables some additional warnings that help
+ cfg80211 developers and driver developers, but that can
+ trigger due to races with userspace.
+
+ For example, when a driver reports that it was disconnected
+ from the AP, but the user disconnects manually at the same
+ time, the warning might trigger spuriously due to races.
+
+ Say Y only if you are developing cfg80211 or a driver based
+ on it (or mac80211).
+
+
config CFG80211_REG_DEBUG
bool "cfg80211 regulatory debugging"
depends on CFG80211
--- wireless-testing.orig/net/wireless/core.h 2009-08-21 12:14:41.000000000 +0200
+++ wireless-testing/net/wireless/core.h 2009-08-21 12:17:02.000000000 +0200
@@ -380,4 +380,15 @@ int rdev_set_freq(struct cfg80211_regist
struct wireless_dev *for_wdev,
int freq, enum nl80211_channel_type channel_type);
+#ifdef CONFIG_CFG80211_DEVELOPER_WARNINGS
+#define CFG80211_DEV_WARN_ON(cond) WARN_ON(cond)
+#else
+/*
+ * Trick to enable using it as a condition,
+ * and also not give a warning when it's
+ * not used that way.
+ */
+#define CFG80211_DEV_WARN_ON(cond) ({bool __r = (cond); __r; })
+#endif
+
#endif /* __NET_WIRELESS_CORE_H */
^ permalink raw reply
* ath5k: ath5k_pci_probe(): weirdo code
From: Andreas Mohr @ 2009-08-21 9:47 UTC (permalink / raw)
To: ath5k-devel; +Cc: linux-wireless, Bob Copeland, Johannes Stezenbach
Hello all,
that 2GHz/5GHz radio information code in ath5k_pci_probe() in 2.6.31-rc6 source
seems VERY weird.
ah_radio_5ghz_revision/ah_radio_2ghz_revision conditional evaluation seems
completely bonkered in several places, unless something is escaping on
me.
Then also at this place, why is there no
else
{
WARN_ONCE(...); // Huh. Unknown/unhandled/impossible revision combo
}
branch at the end? (or something less incinerating)
I've had my few lessons about defensive programming...
(and applying such stuff liberally in this entire driver wouldn't hurt either)
The
if (!sc->ah->ah_single_chip) {
/* Single chip radio (!RF5111) */
part seemed weird logic, too, but I then thought that this code section
is perhaps _intended_ to be skipped in this case, to simply not log anything
for single-chip radios
(but the comment above would be very insufficient/confusing if that is
the case, and if the entire weird section is _actually_ correct as it stands
then even lots more rectifying comments about this strange evaluation
being correct are missing).
Could anyone enlighten me?
So far it looks like a large part of this code is buggy, but I could be
wrong.
BTW, I'm currently on 2.6.31-rc6 on Aspire One, with even more ath5k problems
than before, connection is dying every couple minutes, extended to every
couple dozen minutes if I force rate 1M
(but it looks like "[Bug #13948] ath5k broken after suspend-to-ram"
http://lkml.org/lkml/2009/8/19/468 is hopefully covering these issues already).
And I do have CONFIG..._PS (powersave) enabled by default...
And I do make liberal use of suspend-to-ram, as should everyone.
Thanks,
Andreas Mohr
^ permalink raw reply
* Re: Few warnings from master-2009-08-17
From: Johannes Berg @ 2009-08-21 9:42 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless
In-Reply-To: <43e72e890908171804t2279c750j7baeaf37ad4ff205@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2766 bytes --]
On Mon, 2009-08-17 at 18:04 -0700, Luis R. Rodriguez wrote:
> Aug 17 17:45:06 tux kernel: [ 380.596120] usb 1-3: firmware:
> requesting ar9170.fw
it would help if you turned off linebreaks for messages just like for
patches :)
> Aug 17 17:45:50 tux kernel: [ 424.812910] ------------[ cut here ]------------
> Aug 17 17:45:50 tux kernel: [ 424.812928] WARNING: at
> net/wireless/sme.c:610 __cfg80211_disconnected+0x1fb/0x260
> [cfg80211]()
> Aug 17 17:45:50 tux kernel: [ 424.812931] Hardware name: 7660A14
> Aug 17 17:45:50 tux kernel: [ 424.812933] deauth failed: -67
what was before that?
> It seems I can get the second warning triggered when I disconnect due
> to no probe response from AP:
>
>
> [ 1060.261105] No probe response from AP <AP-MAC-ADDRESS>after 500ms,
> disconnecting.
> [ 1060.264257] phy1: device now idle
> [ 1060.268293] phy1: Removed STA <AP-MAC-ADDRESS>
> [ 1060.290788] phy1: Destroyed STA <AP-MAC-ADDRESS>
> [ 1060.290961] wlan6: deauthenticating by local choice (reason=3)
> [ 1060.291025] ------------[ cut here ]------------
> [ 1060.291057] WARNING: at net/wireless/sme.c:610
> __cfg80211_disconnected+0x1fb/0x260 [cfg80211]()
Hmm, I can't:
# ip link set wlan0 down # that's the AP
[ 311.040157] wlan1: detected beacon loss from AP - sending probe request
[ 311.540219] No probe response from AP 02:00:00:00:00:00 after 500ms, try 1
[ 312.040147] No probe response from AP 02:00:00:00:00:00 after 500ms, try 2
[ 312.540138] No probe response from AP 02:00:00:00:00:00 after 500ms, try 3
[ 313.040170] No probe response from AP 02:00:00:00:00:00 after 500ms, try 4
[ 313.540203] No probe response from AP 02:00:00:00:00:00 after 500ms, disconnecting.
[ 313.543275] phy1:mac80211_hwsim_conf_tx (queue=0 txop=47 cw_min=3 cw_max=7 aifs=2)
[ 313.546169] phy1:mac80211_hwsim_conf_tx (queue=1 txop=94 cw_min=7 cw_max=15 aifs=2)
[ 313.549090] phy1:mac80211_hwsim_conf_tx (queue=2 txop=0 cw_min=15 cw_max=1023 aifs=3)
[ 313.579536] phy1:mac80211_hwsim_conf_tx (queue=3 txop=0 cw_min=15 cw_max=1023 aifs=7)
[ 313.582070] phy1: device now idle
[ 313.583148] phy1:mac80211_hwsim_config (freq=2432 idle=1 ps=0)
[ 313.585026] phy1:mac80211_hwsim_bss_info_changed(changed=0x8f)
[ 313.586871] phy1:mac80211_hwsim_bss_info_changed: BSSID changed: 00:00:00:00:00:00
[ 313.589350] phy1: ASSOC: assoc=0 aid=1
[ 313.590685] phy1: ERP_CTS_PROT: 0
[ 313.591840] phy1: ERP_PREAMBLE: 0
[ 313.592979] phy1: ERP_SLOT: 0
[ 313.594020] phy1: Removed STA 02:00:00:00:00:00
[ 313.630576] phy1: Destroyed STA 02:00:00:00:00:00
[ 313.790503] phy1: device no longer idle - scanning
Ok, so this is hwsim, but shouldn't make a difference at this level.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Implementing wireless testbed on Linux
From: Jinsung Lee @ 2009-08-21 8:26 UTC (permalink / raw)
To: linux-wireless
Hello, everyone.
I'm a Ph.D. student and I'm going to implement wireless testebed consisting
of more than 20 nodes using WLAN device on Linux.
Actually, there are a lot of devices and drivers in the world. I can't
follow all information as you know, which is very difficult job.
So, I expect to borrow very valuable knowledge and experience from you.
Specifically, what I want to do is to set 802.11 MAC parameters such as
AIFS, CW, TxOp in per-packet basis in user-space.
In the case of using 802.11n chipset, which card and device driver should I
choose? At the same time, which version of Linux kernel should be
appropriate?
Is there any difference between pci and usb interfaces?
Definitely, all device and software should be stable and up-to-date.
Please let me know anything you know related to this issue.
I'm looking forward to your comments.
Thanks.
----
Jinsung Lee
^ permalink raw reply
* Re: [PATCH] iwlwifi: Make injection of non-broadcast frames work again
From: Johannes Berg @ 2009-08-21 8:21 UTC (permalink / raw)
To: Gábor Stefanik
Cc: John Linville, Reinette Chatre, Zhu Yi, Wey-Yi Guy, Rafael Laufer,
ipw3945-devel, linux-wireless
In-Reply-To: <4A8DC955.9060100@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 781 bytes --]
On Fri, 2009-08-21 at 00:08 +0200, Gábor Stefanik wrote:
> /* If this frame is broadcast or management, use broadcast station id */
> - if (!ieee80211_is_data(fc) || is_multicast_ether_addr(hdr->addr1))
> + if (!ieee80211_is_data(fc) || is_multicast_ether_addr(hdr->addr1) ||
> + iwl_is_monitor_mode(priv)) /* Injected frames need broadcast too */
> return priv->hw_params.bcast_sta_id;
Now you still can't transmit frames to another AP when connected to one,
which will, for example, be required for 11r. IMHO that code should, in
STATION mode, be checking the RA against the BSSID, and if they match
use the AP ID, otherwise the bcast ID. And remove the warning in the
default case, since that's what happens if in pure monitor mode afaict.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH] Implementation of the IEEE80211_RADIOTAP_RATE option
From: Johannes Berg @ 2009-08-21 8:18 UTC (permalink / raw)
To: Rafael Laufer; +Cc: linux-wireless
In-Reply-To: <4A8DED03.2050502@cs.ucla.edu>
[-- Attachment #1: Type: text/plain, Size: 1257 bytes --]
On Thu, 2009-08-20 at 17:40 -0700, Rafael Laufer wrote:
> This patch implements the IEEE80211_RADIOTAP_RATE
> option when parsing radiotap headers to allow rate
> selection on a per-packet basis.
>
>
> Signed-off-by: Rafael Laufer <rlaufer@cs.ucla.edu>
> ---
> Implementation of the IEEE80211_RADIOTAP_RATE
> option when parsing radiotap headers to allow
> rate selection on a per-packet basis.
>
> net/mac80211/tx.c | 18 +++++++++++++++++-
> 1 files changed, 17 insertions(+), 1 deletions(-)
>
> diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
> index 10a1099..41d636b 100644
> --- a/net/mac80211/tx.c
> +++ b/net/mac80211/tx.c
> @@ -549,7 +549,10 @@ ieee80211_tx_h_rate_ctrl(struct ieee80211_tx_data *tx)
> * If we're associated with the sta at this point we know we can at
> * least send the frame at the lowest bit rate.
> */
> - rate_control_get_rate(tx->sdata, tx->sta, &txrc);
> +
> + /* in monitor mode, we already have the rate from the radiotap header */
> + if (likely(!(info->flags & IEEE80211_TX_CTL_INJECTED)))
> + rate_control_get_rate(tx->sdata, tx->sta, &txrc);
NAK, the rate is optional in the radiotap header, and if not given then
regular rate control must be used.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* [PATCH] ath9k: Fix chainmask selection during scanning
From: Sujith @ 2009-08-21 6:30 UTC (permalink / raw)
To: linville; +Cc: linux-wireless
The TX/RX chainmasks were set to 1x1 during scanning.
Configure them properly with the values retrieved from
the EEPROM.
Also, this requires scan_start/scan_end callbacks to be
locked with sc->mutex.
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
---
drivers/net/wireless/ath/ath9k/main.c | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
index 9b9b4e8..eb8d673 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -439,7 +439,7 @@ static void ath_start_ani(struct ath_softc *sc)
*/
void ath_update_chainmask(struct ath_softc *sc, int is_ht)
{
- if (is_ht ||
+ if ((sc->sc_flags & SC_OP_SCANNING) || is_ht ||
(sc->sc_ah->caps.hw_caps & ATH9K_HW_CAP_BT_COEX)) {
sc->tx_chainmask = sc->sc_ah->caps.tx_chainmask;
sc->rx_chainmask = sc->sc_ah->caps.rx_chainmask;
@@ -2713,6 +2713,7 @@ static void ath9k_sw_scan_start(struct ieee80211_hw *hw)
struct ath_wiphy *aphy = hw->priv;
struct ath_softc *sc = aphy->sc;
+ mutex_lock(&sc->mutex);
if (ath9k_wiphy_scanning(sc)) {
printk(KERN_DEBUG "ath9k: Two wiphys trying to scan at the "
"same time\n");
@@ -2720,6 +2721,7 @@ static void ath9k_sw_scan_start(struct ieee80211_hw *hw)
* Do not allow the concurrent scanning state for now. This
* could be improved with scanning control moved into ath9k.
*/
+ mutex_unlock(&sc->mutex);
return;
}
@@ -2729,6 +2731,7 @@ static void ath9k_sw_scan_start(struct ieee80211_hw *hw)
spin_lock_bh(&sc->ani_lock);
sc->sc_flags |= SC_OP_SCANNING;
spin_unlock_bh(&sc->ani_lock);
+ mutex_unlock(&sc->mutex);
}
static void ath9k_sw_scan_complete(struct ieee80211_hw *hw)
@@ -2736,11 +2739,13 @@ static void ath9k_sw_scan_complete(struct ieee80211_hw *hw)
struct ath_wiphy *aphy = hw->priv;
struct ath_softc *sc = aphy->sc;
+ mutex_lock(&sc->mutex);
spin_lock_bh(&sc->ani_lock);
aphy->state = ATH_WIPHY_ACTIVE;
sc->sc_flags &= ~SC_OP_SCANNING;
sc->sc_flags |= SC_OP_FULL_RESET;
spin_unlock_bh(&sc->ani_lock);
+ mutex_unlock(&sc->mutex);
}
struct ieee80211_ops ath9k_ops = {
--
1.6.4
^ permalink raw reply related
* Abour linux driver supports BCM4325
From: feng tian @ 2009-08-21 6:19 UTC (permalink / raw)
To: linux-wireless
Dear All,
We are working on a project which supports the BCM4325 linux wireless
driver. The interface between the BCM chip and SOC(pxa310) is SDIO.
I did some searches online and found that there is no available driver
for this chip. Do I have to implement this myself? Is there anyone can
provide us some related materials? Thanks very much.
BR
Feng
^ permalink raw reply
* Re: [PATCH] rtl8187: always set MSR_LINK_ENEDCA flag with RTL8187B
From: Hin-Tak Leung @ 2009-08-21 3:54 UTC (permalink / raw)
To: Larry Finger
Cc: Herton Ronaldo Krzesinski, linux-wireless, John W. Linville,
Hin-Tak Leung, Rafael J. Wysocki
In-Reply-To: <4A8DF356.8000501@lwfinger.net>
On Fri, Aug 21, 2009 at 2:07 AM, Larry Finger<Larry.Finger@lwfinger.net> wrote:
> Herton Ronaldo Krzesinski wrote:
>> RTL8187B always needs MSR_LINK_ENEDCA flag to be set even when it is in
>> no link mode, otherwise it'll not be able to associate when this flag is
>> not set after the change "mac80211: fix managed mode BSSID handling"
>> (commit 9cef8737).
>>
>> By accident, setting BSSID of AP before association makes 8187B to
>> successfuly associate even when ENEDCA flag isn't set, which was the
>> case before the mac80211 change. But now the BSSID of AP we are trying
>> to associate is only available after association is successful, and
>> any attempt to associate without the needed flag doesn't work.
>>
>> Signed-off-by: Herton Ronaldo Krzesinski <herton@mandriva.com.br>
>> ---
>
> Tested-by: Larry Finger <Larry.Finger@lwfinger.net>
Acked-by: Hin-Tak Leung <htl10@users.sourceforge.net>
>
> I had just finished bisecting the problem reported in Bug #13960 when
> this patch from Herton appeared in my mailbox, and it fixed the problem.
>
> Larry
> --
> 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
>
This seems to be related to a problem I reported a while back - see
the "compat-wireless won't associate on 2nd load" thread, I wrote on
May 31. Supposedly I had that problem about a week before that, the
date on the patch from Johannes is May 14, but I just went back to
look at the mailing list archive and it looks like there were some
problem with applying and John did some fix on 20th. So it seems that
it might be the source of my not being able to load compat-wireless a
2nd time; and the description of the problem sounds like it too.
Sorry I haven't been doing much with compat-wireless lately, so I have
no firm data whether I have the same problem or not since May - that
problem only happens if I switch from one compat-wireless to another
compat-wireless, without rebooting - while I have tried
compat-wireless in the last two months, I don't think I have followed
compat-wireless as closely as I should to have two successive
compat-wireless. I probably should go and have a try now.
Thanks for hunting this down!
Hin-Tak
^ permalink raw reply
* [PATCH] ath9k: Add support FIF_OTHER_BSS filtering mode.
From: Javier Cardona @ 2009-08-21 2:12 UTC (permalink / raw)
To: linux-wireless
Cc: Javier Cardona, andrey, johannes, linville, devel, Luis.Rodriguez,
jouni.malinen
Support for FIF_OTHER_BSS was missing. This patch adds support for this
filtering mode which in turn resolves a problem where mesh interfaces would not
receive broadcast traffic.
Signed-off-by: Javier Cardona <javier@cozybit.com>
---
drivers/net/wireless/ath/ath9k/recv.c | 7 ++++---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/recv.c b/drivers/net/wireless/ath/ath9k/recv.c
index 7b62c22..52e62da 100644
--- a/drivers/net/wireless/ath/ath9k/recv.c
+++ b/drivers/net/wireless/ath/ath9k/recv.c
@@ -423,11 +423,12 @@ u32 ath_calcrxfilter(struct ath_softc *sc)
if (sc->rx.rxfilter & FIF_PSPOLL)
rfilt |= ATH9K_RX_FILTER_PSPOLL;
- if (sc->sec_wiphy) {
+ if (sc->sec_wiphy || (sc->rx.rxfilter & FIF_OTHER_BSS)) {
/* TODO: only needed if more than one BSSID is in use in
* station/adhoc mode */
- /* TODO: for older chips, may need to add ATH9K_RX_FILTER_PROM
- */
+ /* The following may also be needed for other older chips */
+ if (sc->sc_ah->hw_version.macVersion == AR_SREV_VERSION_9160)
+ rfilt |= ATH9K_RX_FILTER_PROM;
rfilt |= ATH9K_RX_FILTER_MCAST_BCAST_ALL;
}
--
1.5.4.3
^ permalink raw reply related
* Re: [PATCH] rtl8187: always set MSR_LINK_ENEDCA flag with RTL8187B
From: Larry Finger @ 2009-08-21 1:07 UTC (permalink / raw)
To: Herton Ronaldo Krzesinski
Cc: linux-wireless, John W. Linville, Hin-Tak Leung,
Rafael J. Wysocki
In-Reply-To: <200908202116.17847.herton@mandriva.com.br>
Herton Ronaldo Krzesinski wrote:
> RTL8187B always needs MSR_LINK_ENEDCA flag to be set even when it is in
> no link mode, otherwise it'll not be able to associate when this flag is
> not set after the change "mac80211: fix managed mode BSSID handling"
> (commit 9cef8737).
>
> By accident, setting BSSID of AP before association makes 8187B to
> successfuly associate even when ENEDCA flag isn't set, which was the
> case before the mac80211 change. But now the BSSID of AP we are trying
> to associate is only available after association is successful, and
> any attempt to associate without the needed flag doesn't work.
>
> Signed-off-by: Herton Ronaldo Krzesinski <herton@mandriva.com.br>
> ---
Tested-by: Larry Finger <Larry.Finger@lwfinger.net>
I had just finished bisecting the problem reported in Bug #13960 when
this patch from Herton appeared in my mailbox, and it fixed the problem.
Larry
^ permalink raw reply
* [PATCH] Implementation of the IEEE80211_RADIOTAP_RATE option
From: Rafael Laufer @ 2009-08-21 0:40 UTC (permalink / raw)
To: linux-wireless
This patch implements the IEEE80211_RADIOTAP_RATE
option when parsing radiotap headers to allow rate
selection on a per-packet basis.
Signed-off-by: Rafael Laufer <rlaufer@cs.ucla.edu>
---
Implementation of the IEEE80211_RADIOTAP_RATE
option when parsing radiotap headers to allow
rate selection on a per-packet basis.
net/mac80211/tx.c | 18 +++++++++++++++++-
1 files changed, 17 insertions(+), 1 deletions(-)
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index 10a1099..41d636b 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -549,7 +549,10 @@ ieee80211_tx_h_rate_ctrl(struct ieee80211_tx_data *tx)
* If we're associated with the sta at this point we know we can at
* least send the frame at the lowest bit rate.
*/
- rate_control_get_rate(tx->sdata, tx->sta, &txrc);
+
+ /* in monitor mode, we already have the rate from the radiotap header */
+ if (likely(!(info->flags & IEEE80211_TX_CTL_INJECTED)))
+ rate_control_get_rate(tx->sdata, tx->sta, &txrc);
if (unlikely(info->control.rates[0].idx < 0))
return TX_DROP;
@@ -972,6 +975,19 @@ static bool __ieee80211_parse_tx_radiotap(struct ieee80211_tx_data *tx,
tx->flags |= IEEE80211_TX_FRAGMENTED;
break;
+ /* Get the rate parameter from the radiotap header,
+ * allowing rate selection on a per-packet basis
+ */
+ case IEEE80211_RADIOTAP_RATE:
+ bitrate = (*iterator.this_arg) * 5;
+ for (i = 0; i < sband->n_bitrates; i++) {
+ if (sband->bitrates[i].bitrate == bitrate)
+ break;
+ }
+ if (i != sband->n_bitrates)
+ info->control.rates[0].idx = i;
+ break;
+
/*
* Please update the file
* Documentation/networking/mac80211-injection.txt
--
1.6.0.4
^ permalink raw reply related
* [PATCH] rtl8187: always set MSR_LINK_ENEDCA flag with RTL8187B
From: Herton Ronaldo Krzesinski @ 2009-08-21 0:16 UTC (permalink / raw)
To: linux-wireless; +Cc: John W. Linville, Larry Finger, Hin-Tak Leung
RTL8187B always needs MSR_LINK_ENEDCA flag to be set even when it is in
no link mode, otherwise it'll not be able to associate when this flag is
not set after the change "mac80211: fix managed mode BSSID handling"
(commit 9cef8737).
By accident, setting BSSID of AP before association makes 8187B to
successfuly associate even when ENEDCA flag isn't set, which was the
case before the mac80211 change. But now the BSSID of AP we are trying
to associate is only available after association is successful, and
any attempt to associate without the needed flag doesn't work.
Signed-off-by: Herton Ronaldo Krzesinski <herton@mandriva.com.br>
---
drivers/net/wireless/rtl818x/rtl8187_dev.c | 14 ++++++++++----
1 files changed, 10 insertions(+), 4 deletions(-)
This is a bug fix that should be sent too for 2.6.31-rcX
diff --git a/drivers/net/wireless/rtl818x/rtl8187_dev.c b/drivers/net/wireless/rtl818x/rtl8187_dev.c
index 90f3835..5830f6c 100644
--- a/drivers/net/wireless/rtl818x/rtl8187_dev.c
+++ b/drivers/net/wireless/rtl818x/rtl8187_dev.c
@@ -870,6 +870,9 @@ static int rtl8187b_init_hw(struct ieee80211_hw *dev)
priv->aifsn[3] = 3; /* AIFSN[AC_BE] */
rtl818x_iowrite8(priv, &priv->map->ACM_CONTROL, 0);
+ /* ENEDCA flag must always be set, transmit issues? */
+ rtl818x_iowrite8(priv, &priv->map->MSR, RTL818X_MSR_ENEDCA);
+
return 0;
}
@@ -1174,13 +1177,16 @@ static void rtl8187_bss_info_changed(struct ieee80211_hw *dev,
rtl818x_iowrite8(priv, &priv->map->BSSID[i],
info->bssid[i]);
+ if (priv->is_rtl8187b)
+ reg = RTL818X_MSR_ENEDCA;
+ else
+ reg = 0;
+
if (is_valid_ether_addr(info->bssid)) {
- reg = RTL818X_MSR_INFRA;
- if (priv->is_rtl8187b)
- reg |= RTL818X_MSR_ENEDCA;
+ reg |= RTL818X_MSR_INFRA;
rtl818x_iowrite8(priv, &priv->map->MSR, reg);
} else {
- reg = RTL818X_MSR_NO_LINK;
+ reg |= RTL818X_MSR_NO_LINK;
rtl818x_iowrite8(priv, &priv->map->MSR, reg);
}
--
1.6.4
^ permalink raw reply related
* [PATCH] iwlwifi: Make injection of non-broadcast frames work again
From: Gábor Stefanik @ 2009-08-20 22:08 UTC (permalink / raw)
To: John Linville, Reinette Chatre, Zhu Yi
Cc: Wey-Yi Guy, Rafael Laufer, ipw3945-devel, linux-wireless
Commit 1ccb84d87d04df3c76cd4352fe69786d8c7cf016 by Wey-Yi Guy
("iwlwifi: clean up unused NL80211_IFTYPE_MONITOR for Monitor mode")
broke injection of non-broadcast frames to unassociated stations
(causing a SYSASSERT for all such injected frames), due to injected
frames no longer automatically getting a broadcast station ID assigned,
and instead ending up with invalid station IDs.
This patch restores the old behavior, fixing the aforementioned
regression.
Signed-off-by: Gábor Stefanik <netrolller.3d@gmail.com>
---
This fixes a regression introduced between 2.6.30 and 2.6.31-rc1.
Please apply to 2.6.31.
drivers/net/wireless/iwlwifi/iwl-sta.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-sta.c b/drivers/net/wireless/iwlwifi/iwl-sta.c
index c6633fe..81a656f 100644
--- a/drivers/net/wireless/iwlwifi/iwl-sta.c
+++ b/drivers/net/wireless/iwlwifi/iwl-sta.c
@@ -1054,7 +1054,8 @@ int iwl_get_sta_id(struct iwl_priv *priv, struct ieee80211_hdr *hdr)
__le16 fc = hdr->frame_control;
/* If this frame is broadcast or management, use broadcast station id */
- if (!ieee80211_is_data(fc) || is_multicast_ether_addr(hdr->addr1))
+ if (!ieee80211_is_data(fc) || is_multicast_ether_addr(hdr->addr1) ||
+ iwl_is_monitor_mode(priv)) /* Injected frames need broadcast too */
return priv->hw_params.bcast_sta_id;
switch (priv->iw_mode) {
--
1.6.2.4
^ permalink raw reply related
* Re: 2.6.31-rc6-git5: Reported regressions from 2.6.30
From: Rafael J. Wysocki @ 2009-08-20 21:28 UTC (permalink / raw)
To: John Dykstra
Cc: Linux Kernel Mailing List, Adrian Bunk, Andrew Morton,
Linus Torvalds, Natalie Protasevich, Kernel Testers List,
Network Development, Linux ACPI, Linux PM List, Linux SCSI List,
Linux Wireless List, DRI
In-Reply-To: <1250801571.7176.10.camel@Maple>
On Thursday 20 August 2009, John Dykstra wrote:
> On Wed, 2009-08-19 at 22:20 +0200, Rafael J. Wysocki wrote:
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14002
> > Subject : WARNING: at net/ipv4/af_inet.c:154
> > inet_sock_destruct+0x164/0x1c0()
> > Submitter : Ralf Hildebrandt <ralf.hildebrandt@charite.de>
> > Date : 2009-08-18 12:37 (2 days old)
>
> That looks similar to the WARNING discussed in [1].
>
> There was no resolution to that thread. However, [2] points out
> possible other occurrences of the problem in 2.6.27, 28 and 29.
>
> -- John
>
> [1] http://www.spinics.net/lists/netdev/msg103267.html
> [2] http://www.spinics.net/lists/netdev/msg104120.html
Thanks for the information.
So I'll drop this from the list, since it most probably is not a recent thing.
Best,
Rafael
^ permalink raw reply
* Re: [PATCH] atheros: add ar9170.fw 1-stage firmware
From: Luis R. Rodriguez @ 2009-08-20 21:04 UTC (permalink / raw)
To: David Woodhouse; +Cc: linux-wireless, Stephen Chen
In-Reply-To: <1250796364.3311.0.camel@macbook.infradead.org>
On Thu, Aug 20, 2009 at 12:26 PM, David Woodhouse<dwmw2@infradead.org> wrote:
> On Thu, 2009-08-20 at 11:40 -0700, Luis R. Rodriguez wrote:
>>
>> Here is a resend, noticed today this wasn't yet in the tree.
>>
>> ar9170.fw | Bin 0 -> 15960 bytes
>> 1 files changed, 0 insertions(+), 0 deletions(-)
>> create mode 100644 ar9170.fw
>
> Needs patch to WHENCE file.
On second thought people already know where to find this file as
documented on the wiki, and since users are reporting some issues with
it we may as well wait for a release of the open fw which is based on
the same code as the 1 stage fw.
So if people can start testing that it would help.
Luis
^ permalink raw reply
* Re: 2.6.31-rc6-git5: Reported regressions from 2.6.30
From: John Dykstra @ 2009-08-20 20:52 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Adrian Bunk, Andrew Morton,
Linus Torvalds, Natalie Protasevich, Kernel Testers List,
Network Development, Linux ACPI, Linux PM List, Linux SCSI List,
Linux Wireless List, DRI
In-Reply-To: <jCYznkTxcLB.A.EPH.eNIjKB@chimera>
On Wed, 2009-08-19 at 22:20 +0200, Rafael J. Wysocki wrote:
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14002
> Subject : WARNING: at net/ipv4/af_inet.c:154
> inet_sock_destruct+0x164/0x1c0()
> Submitter : Ralf Hildebrandt <ralf.hildebrandt@charite.de>
> Date : 2009-08-18 12:37 (2 days old)
That looks similar to the WARNING discussed in [1].
There was no resolution to that thread. However, [2] points out
possible other occurrences of the problem in 2.6.27, 28 and 29.
-- John
[1] http://www.spinics.net/lists/netdev/msg103267.html
[2] http://www.spinics.net/lists/netdev/msg104120.html
^ permalink raw reply
* Re: Minstrel's definition of best throughput
From: Felix Fietkau @ 2009-08-20 20:45 UTC (permalink / raw)
To: Arnd Hannemann; +Cc: linux-wireless
In-Reply-To: <4A8D5A48.5070809@nets.rwth-aachen.de>
Arnd Hannemann wrote:
> Hi,
>
> while watching the rc_stats of minstrel, I noticed
> that minstrel does not choose the rate with best throughput.
> For example, I often see something like this:
>
> rate throughput ewma prob this prob this succ/attempt success attempts
> 1 0.8 89.1 100.0 0( 0) 1490 2257
> 2 1.8 95.3 100.0 0( 0) 13 15
> 5.5 4.8 95.5 100.0 0( 0) 17 22
> P 11 9.4 98.5 100.0 0( 0) 1532 2195
> 6 5.4 95.6 100.0 0( 0) 28 88
> 9 8.1 96.2 100.0 0( 0) 143 431
> 12 8.7 78.8 100.0 0( 0) 209 814
> 18 12.3 75.8 100.0 0( 0) 302 2416
> 24 18.3 86.2 100.0 0( 0) 5765 9196
> 36 2.6 85.2 100.0 0( 0) 736813 886517
> T 48 14.7 97.4 100.0 2( 2) 3433862 4411674
> t 54 8.5 73.3 100.0 0( 0) 1488241 2180261
>
>
> Why did minstrel chose the 48M rate, and not 24M for the best throughput rate?
The table looks weird. Maybe there's a race between the update of the
table and the display through debugfs. Either way, 48M is definitely the
best throughput rate based on the ewma prob, but the calculated
throughput value looks a bit off.
> Also "this prob" seems fishy to me, its always 100...
"this prob" refers to the current interval, not the value after EWMA, so
it's always calculated from this succ/attempt and 100.0 makes sense here.
> Another thing: I noticed that the througput field in minstrel_rate is never used?
> Should I send a patch, removing it? Or does anyone remember why it was there
> in the first place?
I think you can remove it. I think initially I planned on calculating
both the EWMA throughput and the one from the measurement interval, but
didn't do that, because it's not displayed anywhere and would serve no
other purpose.
- Felix
^ permalink raw reply
* [PATCH] mac80211: remove ieee80211_rx namespace hack
From: John W. Linville @ 2009-08-20 20:34 UTC (permalink / raw)
To: linux-wireless; +Cc: John W. Linville
With the libipw naming scheme change, it is no longer necessary for
mac80211 to avoid the ieee80211_rx name clash.
Reported-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
include/net/mac80211.h | 11 +----------
net/mac80211/rx.c | 4 ++--
2 files changed, 3 insertions(+), 12 deletions(-)
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index aac84d7..466859b 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -1657,12 +1657,6 @@ void ieee80211_free_hw(struct ieee80211_hw *hw);
*/
void ieee80211_restart_hw(struct ieee80211_hw *hw);
-/*
- * trick to avoid symbol clashes with the ieee80211 subsystem,
- * use the inline below instead
- */
-void __ieee80211_rx(struct ieee80211_hw *hw, struct sk_buff *skb);
-
/**
* ieee80211_rx - receive frame
*
@@ -1678,10 +1672,7 @@ void __ieee80211_rx(struct ieee80211_hw *hw, struct sk_buff *skb);
* @hw: the hardware this frame came in on
* @skb: the buffer to receive, owned by mac80211 after this call
*/
-static inline void ieee80211_rx(struct ieee80211_hw *hw, struct sk_buff *skb)
-{
- __ieee80211_rx(hw, skb);
-}
+void ieee80211_rx(struct ieee80211_hw *hw, struct sk_buff *skb);
/**
* ieee80211_rx_irqsafe - receive frame
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index 7065fd7..dff2239 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -2440,7 +2440,7 @@ static u8 ieee80211_rx_reorder_ampdu(struct ieee80211_local *local,
* This is the receive path handler. It is called by a low level driver when an
* 802.11 MPDU is received from the hardware.
*/
-void __ieee80211_rx(struct ieee80211_hw *hw, struct sk_buff *skb)
+void ieee80211_rx(struct ieee80211_hw *hw, struct sk_buff *skb)
{
struct ieee80211_local *local = hw_to_local(hw);
struct ieee80211_rate *rate = NULL;
@@ -2523,7 +2523,7 @@ void __ieee80211_rx(struct ieee80211_hw *hw, struct sk_buff *skb)
rcu_read_unlock();
}
-EXPORT_SYMBOL(__ieee80211_rx);
+EXPORT_SYMBOL(ieee80211_rx);
/* This is a version of the rx handler that can be called from hard irq
* context. Post the skb on the queue and schedule the tasklet */
--
1.6.2.5
^ permalink raw reply related
* Re: [PATCH] atheros: add ar9170.fw 1-stage firmware
From: Luis R. Rodriguez @ 2009-08-20 20:28 UTC (permalink / raw)
To: Richard Farina
Cc: Luis Rodriguez, dwmw2@infradead.org,
linux-wireless@vger.kernel.org
In-Reply-To: <4A8DAD1D.7090608@gmail.com>
On Thu, Aug 20, 2009 at 01:07:57PM -0700, Richard Farina wrote:
> Luis R. Rodriguez wrote:
> > This adds support for ar9170 for using a 1-stage firmware.
> > This means only 1 firmware file is required. AVM Fritz
> > devices require this.
> >
> > Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
> > ---
> >
> > Here is a resend, noticed today this wasn't yet in the tree.
> >
> >
> Last I tested this firmware it didn't seem to function nearly as well as
> the 2 stage firmware, and if present, the 1 stage overrides the 2
> stage.
Can you be more specific than that?
> Is this an improved version?
No, it is the same firmware.
> Does this work properly in your testing?
Works for me, and is also required for usage of AVM Fritz devices.
Luis
^ 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