* Re: [PATCH 0/7] ath5k: few fixes for regressions
From: Luis R. Rodriguez @ 2009-10-07 20:23 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless
In-Reply-To: <20091007195321.GD22394@tuxdriver.com>
On Wed, Oct 7, 2009 at 3:53 PM, John W. Linville <linville@tuxdriver.com> wrote:
> On Tue, Oct 06, 2009 at 08:44:27PM -0400, Luis R. Rodriguez wrote:
>> I wasn't able to connect to some AP and it turned out the issue
>> was a few regressions introduced in my series. It was hard to note
>> as I was able to connect at work and at home, so I guess this would
>> only have been seen with some specific APs. This series fixed my
>> connection but since I introduced them I figured I'd throw in
>> an extra patch at the end for setting the association ID.
>>
>> Luis R. Rodriguez (7):
>> ath5k: fix regression on setting bssid mask on association
>> ath5k: use ath_hw_setbssidmask() for bssid mask setting upon assoc
>> ath5k: fix regression introduced upon the removal of AR5K_HIGH_ID()
>> ath5k: simplify passed params to ath5k_hw_set_associd()
>> ath5k: remove temporary low_id and high_id vars on
>> ath5k_hw_set_associd()
>> ath5k: fix regression which triggers an SME join upon assoc
>> ath5k: enable Power-Save Polls by setting the association ID
>>
>> drivers/net/wireless/ath/ath5k/ath5k.h | 2 +-
>> drivers/net/wireless/ath/ath5k/attach.c | 2 +-
>> drivers/net/wireless/ath/ath5k/base.c | 13 ++++++++++---
>> drivers/net/wireless/ath/ath5k/pcu.c | 30 +++++++++++++-----------------
>> drivers/net/wireless/ath/ath5k/reset.c | 5 ++---
>> 5 files changed, 27 insertions(+), 25 deletions(-)
>
> Actually, none of these seem to apply against 2.6.32...did you mean
> for them to go there?
>
> I'll queue them for -next for now...
Nope -- none of them are for 2.6.32 -- all of them are just for 2.6.33.
Luis
^ permalink raw reply
* Re: [PATCH 7/7] ath5k: enable Power-Save Polls by setting the association ID
From: Luis R. Rodriguez @ 2009-10-07 20:24 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless
In-Reply-To: <20091007194148.GC22394@tuxdriver.com>
On Wed, Oct 7, 2009 at 3:41 PM, John W. Linville <linville@tuxdriver.com> wrote:
> On Tue, Oct 06, 2009 at 08:44:34PM -0400, Luis R. Rodriguez wrote:
>> mac80211 has long provided us the association ID. This isn't useful except
>> for Power-Save polling which now gets enabled. We can now poll for our
>> pending frames on the AP during power save.
>>
>> You can review the details of Power-Save on the wireless wiki:
>>
>> http://wireless.kernel.org/en/developers/Documentation/ieee80211/power-savings
>>
>> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
>
> Nice try, but how is this a fix? :-)
It isn't -- by no means do I want this in for 2.6.32, sorry if I was
misleading. Its a regression as things *used* to work :) but yeah not
a regression for 2.6.32.
Luis
^ permalink raw reply
* Prism54/p54pci
From: James Grossmann @ 2009-10-07 21:00 UTC (permalink / raw)
To: linux-wireless
I have the gigafast WF728-AEX, which doesn't seem to work with the
p54pci drivers, I was previously using it with my Thinkpad T23 under
Gentoo (gentoo kernels 2.6.29 and 2.6.30), and could only use the
1.0.4.3 firmware, now, I am using it under Ubuntu 9.04
(2.6.28-15-generic kernel) on the same computer, and find that I have
to load the prism54 driver to make it work.
I noticed that you were considering this to be depricated, I hope that
you can help me to make p54pci work!
Thanks
James
^ permalink raw reply
* [PATCH] wireless: make WEXT_SPY and WEXT_PRIV select WEXT_CORE
From: John W. Linville @ 2009-10-07 21:07 UTC (permalink / raw)
To: linux-wireless
Cc: Randy Dunlap, Stephen Rothwell, linux-next, linux-kernel,
John W. Linville
In-Reply-To: <20091007105720.a2457e5b.randy.dunlap@oracle.com>
Should prevent this build error reported by Randy...
net/wireless/wext-priv.c:206: error: implicit declaration of function 'call_commit_handler'
make[3]: *** [net/wireless/wext-priv.o] Error 1
Reported-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
net/wireless/Kconfig | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/net/wireless/Kconfig b/net/wireless/Kconfig
index 614bdce..d3ecca3 100644
--- a/net/wireless/Kconfig
+++ b/net/wireless/Kconfig
@@ -12,9 +12,11 @@ config WEXT_PROC
config WEXT_SPY
bool
+ depends on WEXT_CORE
config WEXT_PRIV
bool
+ depends on WEXT_CORE
config CFG80211
tristate "cfg80211 - wireless configuration API"
--
1.6.2.5
^ permalink raw reply related
* [PATCH] orinoco: use cfg80211 ethtool ops
From: David Kilroy @ 2009-10-07 21:23 UTC (permalink / raw)
To: linux-wireless; +Cc: David Kilroy
Signed-off-by: David Kilroy <kilroyd@googlemail.com>
---
drivers/net/wireless/orinoco/hw.c | 33 +++++++++++++++++++++++--------
drivers/net/wireless/orinoco/hw.h | 3 +-
drivers/net/wireless/orinoco/main.c | 33 +++++--------------------------
drivers/net/wireless/orinoco/orinoco.h | 1 -
4 files changed, 32 insertions(+), 38 deletions(-)
diff --git a/drivers/net/wireless/orinoco/hw.c b/drivers/net/wireless/orinoco/hw.c
index 359652d..404830f 100644
--- a/drivers/net/wireless/orinoco/hw.c
+++ b/drivers/net/wireless/orinoco/hw.c
@@ -60,8 +60,15 @@ static inline fwtype_t determine_firmware_type(struct comp_id *nic_id)
/* Set priv->firmware type, determine firmware properties
* This function can be called before we have registerred with netdev,
* so all errors go out with dev_* rather than printk
+ *
+ * If non-NULL stores a firmware description in fw_name.
+ * If non-NULL stores a HW version in hw_ver
+ *
+ * These are output via generic cfg80211 ethtool support.
*/
-int determine_fw_capabilities(struct orinoco_private *priv)
+int determine_fw_capabilities(struct orinoco_private *priv,
+ char *fw_name, size_t fw_name_len,
+ u32 *hw_ver)
{
struct device *dev = priv->dev;
hermes_t *hw = &priv->hw;
@@ -85,6 +92,12 @@ int determine_fw_capabilities(struct orinoco_private *priv)
dev_info(dev, "Hardware identity %04x:%04x:%04x:%04x\n",
nic_id.id, nic_id.variant, nic_id.major, nic_id.minor);
+ if (hw_ver)
+ *hw_ver = (((nic_id.id & 0xff) << 24) |
+ ((nic_id.variant & 0xff) << 16) |
+ ((nic_id.major & 0xff) << 8) |
+ (nic_id.minor & 0xff));
+
priv->firmware_type = determine_firmware_type(&nic_id);
/* Get the firmware version */
@@ -135,8 +148,9 @@ int determine_fw_capabilities(struct orinoco_private *priv)
case FIRMWARE_TYPE_AGERE:
/* Lucent Wavelan IEEE, Lucent Orinoco, Cabletron RoamAbout,
ELSA, Melco, HP, IBM, Dell 1150, Compaq 110/210 */
- snprintf(priv->fw_name, sizeof(priv->fw_name) - 1,
- "Lucent/Agere %d.%02d", sta_id.major, sta_id.minor);
+ if (fw_name)
+ snprintf(fw_name, fw_name_len, "Lucent/Agere %d.%02d",
+ sta_id.major, sta_id.minor);
firmver = ((unsigned long)sta_id.major << 16) | sta_id.minor;
@@ -185,8 +199,8 @@ int determine_fw_capabilities(struct orinoco_private *priv)
tmp[SYMBOL_MAX_VER_LEN] = '\0';
}
- snprintf(priv->fw_name, sizeof(priv->fw_name) - 1,
- "Symbol %s", tmp);
+ if (fw_name)
+ snprintf(fw_name, fw_name_len, "Symbol %s", tmp);
priv->has_ibss = (firmver >= 0x20000);
priv->has_wep = (firmver >= 0x15012);
@@ -224,9 +238,9 @@ int determine_fw_capabilities(struct orinoco_private *priv)
* different and less well tested */
/* D-Link MAC : 00:40:05:* */
/* Addtron MAC : 00:90:D1:* */
- snprintf(priv->fw_name, sizeof(priv->fw_name) - 1,
- "Intersil %d.%d.%d", sta_id.major, sta_id.minor,
- sta_id.variant);
+ if (fw_name)
+ snprintf(fw_name, fw_name_len, "Intersil %d.%d.%d",
+ sta_id.major, sta_id.minor, sta_id.variant);
firmver = ((unsigned long)sta_id.major << 16) |
((unsigned long)sta_id.minor << 8) | sta_id.variant;
@@ -245,7 +259,8 @@ int determine_fw_capabilities(struct orinoco_private *priv)
}
break;
}
- dev_info(dev, "Firmware determined as %s\n", priv->fw_name);
+ if (fw_name)
+ dev_info(dev, "Firmware determined as %s\n", fw_name);
return 0;
}
diff --git a/drivers/net/wireless/orinoco/hw.h b/drivers/net/wireless/orinoco/hw.h
index 8df6e87..e2f7fdc 100644
--- a/drivers/net/wireless/orinoco/hw.h
+++ b/drivers/net/wireless/orinoco/hw.h
@@ -24,7 +24,8 @@
struct orinoco_private;
struct dev_addr_list;
-int determine_fw_capabilities(struct orinoco_private *priv);
+int determine_fw_capabilities(struct orinoco_private *priv, char *fw_name,
+ size_t fw_name_len, u32 *hw_ver);
int orinoco_hw_read_card_settings(struct orinoco_private *priv, u8 *dev_addr);
int orinoco_hw_allocate_fid(struct orinoco_private *priv);
int orinoco_get_bitratemode(int bitrate, int automatic);
diff --git a/drivers/net/wireless/orinoco/main.c b/drivers/net/wireless/orinoco/main.c
index 7a32bcb..c0c8ff6 100644
--- a/drivers/net/wireless/orinoco/main.c
+++ b/drivers/net/wireless/orinoco/main.c
@@ -83,7 +83,6 @@
#include <linux/device.h>
#include <linux/netdevice.h>
#include <linux/etherdevice.h>
-#include <linux/ethtool.h>
#include <linux/suspend.h>
#include <linux/if_arp.h>
#include <linux/wireless.h>
@@ -162,8 +161,6 @@ static const u8 encaps_hdr[] = {0xaa, 0xaa, 0x03, 0x00, 0x00, 0x00};
| HERMES_EV_WTERR | HERMES_EV_INFO \
| HERMES_EV_INFDROP)
-static const struct ethtool_ops orinoco_ethtool_ops;
-
/********************************************************************/
/* Data types */
/********************************************************************/
@@ -1994,7 +1991,9 @@ int orinoco_init(struct orinoco_private *priv)
goto out;
}
- err = determine_fw_capabilities(priv);
+ err = determine_fw_capabilities(priv, wiphy->fw_version,
+ sizeof(wiphy->fw_version),
+ &wiphy->hw_version);
if (err != 0) {
dev_err(dev, "Incompatible firmware, aborting\n");
goto out;
@@ -2010,7 +2009,9 @@ int orinoco_init(struct orinoco_private *priv)
priv->do_fw_download = 0;
/* Check firmware version again */
- err = determine_fw_capabilities(priv);
+ err = determine_fw_capabilities(priv, wiphy->fw_version,
+ sizeof(wiphy->fw_version),
+ &wiphy->hw_version);
if (err != 0) {
dev_err(dev, "Incompatible firmware, aborting\n");
goto out;
@@ -2212,7 +2213,6 @@ int orinoco_if_add(struct orinoco_private *priv,
dev->ieee80211_ptr = wdev;
dev->netdev_ops = &orinoco_netdev_ops;
dev->watchdog_timeo = HZ; /* 1 second timeout */
- dev->ethtool_ops = &orinoco_ethtool_ops;
dev->wireless_handlers = &orinoco_handler_def;
#ifdef WIRELESS_SPY
dev->wireless_data = &priv->wireless_data;
@@ -2348,27 +2348,6 @@ void orinoco_down(struct orinoco_private *priv)
}
EXPORT_SYMBOL(orinoco_down);
-static void orinoco_get_drvinfo(struct net_device *dev,
- struct ethtool_drvinfo *info)
-{
- struct orinoco_private *priv = ndev_priv(dev);
-
- strncpy(info->driver, DRIVER_NAME, sizeof(info->driver) - 1);
- strncpy(info->version, DRIVER_VERSION, sizeof(info->version) - 1);
- strncpy(info->fw_version, priv->fw_name, sizeof(info->fw_version) - 1);
- if (dev->dev.parent)
- strncpy(info->bus_info, dev_name(dev->dev.parent),
- sizeof(info->bus_info) - 1);
- else
- snprintf(info->bus_info, sizeof(info->bus_info) - 1,
- "PCMCIA %p", priv->hw.iobase);
-}
-
-static const struct ethtool_ops orinoco_ethtool_ops = {
- .get_drvinfo = orinoco_get_drvinfo,
- .get_link = ethtool_op_get_link,
-};
-
/********************************************************************/
/* Module initialization */
/********************************************************************/
diff --git a/drivers/net/wireless/orinoco/orinoco.h b/drivers/net/wireless/orinoco/orinoco.h
index 9ac6f1d..665ef56 100644
--- a/drivers/net/wireless/orinoco/orinoco.h
+++ b/drivers/net/wireless/orinoco/orinoco.h
@@ -93,7 +93,6 @@ struct orinoco_private {
/* Capabilities of the hardware/firmware */
fwtype_t firmware_type;
- char fw_name[32];
int ibss_port;
int nicbuf_size;
u16 channel_mask;
--
1.6.3.3
^ permalink raw reply related
* Re: [PATCH] wireless: make WEXT_SPY and WEXT_PRIV select WEXT_CORE
From: Randy Dunlap @ 2009-10-07 21:55 UTC (permalink / raw)
To: John W. Linville
Cc: linux-wireless, Stephen Rothwell, linux-next, linux-kernel
In-Reply-To: <1254949672-24022-1-git-send-email-linville@tuxdriver.com>
John W. Linville wrote:
> Should prevent this build error reported by Randy...
>
> net/wireless/wext-priv.c:206: error: implicit declaration of function 'call_commit_handler'
> make[3]: *** [net/wireless/wext-priv.o] Error 1
>
> Reported-by: Randy Dunlap <randy.dunlap@oracle.com>
> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Sorry, it did not work for me.
linux-next-20091007/net/wireless/wext-priv.c:206: error: implicit declaration of function 'call_commit_handler'
make[3]: *** [net/wireless/wext-priv.o] Error 1
Drivers like hostap and orinoco (hermes) select WEXT_PRIV regardless
of the setting of WEXT_CORE. oh, and staging/ drivers do that also.
> @@ -12,9 +12,11 @@ config WEXT_PROC
>
> config WEXT_SPY
> bool
> + depends on WEXT_CORE
>
> config WEXT_PRIV
> bool
> + depends on WEXT_CORE
>
> config CFG80211
> tristate "cfg80211 - wireless configuration API"
^ permalink raw reply
* Re: NULL pointer deref at wext ioctl (Re: [PATCH] compat-2.6: adding ethtool.h to compat-2.6.31.h)
From: Johannes Berg @ 2009-10-07 22:01 UTC (permalink / raw)
To: Hin-Tak Leung; +Cc: Luis R. Rodriguez, John W. Linville, linux-wireless
In-Reply-To: <3ace41890910071228i786d4097w69dc7a3dfeb64afe@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1777 bytes --]
On Wed, 2009-10-07 at 20:28 +0100, Hin-Tak Leung wrote:
> On Wed, Oct 7, 2009 at 8:16 PM, Hin-Tak Leung <hintak.leung@gmail.com> wrote:
>
> > It is probably just a transient problem with recent activities - I had
> > a NULL pointer deref from loading rtl8187 of compat-wireless
> > v2.6.32-rc3-39563-g98c2609 -
> >
> > BUG: unable to handle kernel NULL pointer dereference at 000000000000003d
> > IP: [<ffffffff8147822c>] wext_ioctl_dispatch+0xd9/0x180
> > PGD 61c2b067 PUD 6246f067 PMD 0
> > Oops: 0000 [#1] SMP
> > ...
> > Call Trace:
> > [<ffffffff814783f5>] wext_handle_ioctl+0x4d/0x98
> > [<ffffffff813e53a5>] dev_ioctl+0x625/0x662
> > [<ffffffff813cfa45>] sock_ioctl+0x225/0x248
> > [<ffffffff811237a3>] vfs_ioctl+0x31/0xaa
> > [<ffffffff811e1801>] ? security_d_instantiate+0x37/0x4d
> > [<ffffffff81123c88>] do_vfs_ioctl+0x46c/0x4c3
> > [<ffffffff81123d44>] sys_ioctl+0x65/0x9c
> > [<ffffffff81012082>] system_call_fastpath+0x16/0x1b
> >
> > I'm sure whatever changes made this happen will go away soon, so I'll
> > just re-try in a few days... but if anybody knows what commit causes
> > this (and what fixes it!), I'd like to know.
> >
>
> Hiya, It looks like I last used compat-wireless successfully was on
> 25th (I am not saying it breaks after - I just haven't tried until
> yesterday, possibly), and most of the recent changes are per-driver,
> but there is a big code drop from Johannes dated 27th on 'wext:
> refactor' . Changes from that or dependent changes?
Probably -- but I don't see this problem on stock kernel and I'm not
sure what could be causing it for compat-wireless.
This will be the old copy of wext_ioctl_dispatch. It'd certainly help to
get disassembly/the source line of the oops.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH] wireless: make WEXT_SPY and WEXT_PRIV select WEXT_CORE
From: Johannes Berg @ 2009-10-07 22:34 UTC (permalink / raw)
To: Randy Dunlap
Cc: John W. Linville, linux-wireless, Stephen Rothwell, linux-next,
linux-kernel
In-Reply-To: <4ACD0E5A.7060106@oracle.com>
[-- Attachment #1: Type: text/plain, Size: 905 bytes --]
On Wed, 2009-10-07 at 14:55 -0700, Randy Dunlap wrote:
> John W. Linville wrote:
> > Should prevent this build error reported by Randy...
> >
> > net/wireless/wext-priv.c:206: error: implicit declaration of function 'call_commit_handler'
> > make[3]: *** [net/wireless/wext-priv.o] Error 1
> >
> > Reported-by: Randy Dunlap <randy.dunlap@oracle.com>
> > Signed-off-by: John W. Linville <linville@tuxdriver.com>
>
> Sorry, it did not work for me.
> linux-next-20091007/net/wireless/wext-priv.c:206: error: implicit declaration of function 'call_commit_handler'
> make[3]: *** [net/wireless/wext-priv.o] Error 1
>
> Drivers like hostap and orinoco (hermes) select WEXT_PRIV regardless
> of the setting of WEXT_CORE. oh, and staging/ drivers do that also.
But they also select WIRELESS_EXT, which should cause WEXT_CORE to be
turned on. Is it possible that is failing?
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: linux-next: Tree for October 7 (libertas build failure)
From: Johannes Berg @ 2009-10-07 22:34 UTC (permalink / raw)
To: Dan Williams
Cc: Randy Dunlap, Stephen Rothwell, linux-wireless, linux-next, LKML,
libertas-dev, Holger Schurig
In-Reply-To: <1254939120.16001.45.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 690 bytes --]
On Wed, 2009-10-07 at 11:12 -0700, Dan Williams wrote:
> > drivers/built-in.o: In function `lbs_cfg_free':
> > (.text+0x3479e0): undefined reference to `wiphy_unregister'
> > drivers/built-in.o: In function `lbs_cfg_free':
> > (.text+0x3479e7): undefined reference to `wiphy_free'
> > drivers/built-in.o: In function `lbs_cfg_register':
> > (.text+0x347a52): undefined reference to `wiphy_register'
> > drivers/built-in.o: In function `lbs_cfg_alloc':
> > (.text+0x347acf): undefined reference to `wiphy_new'
>
> Holger, perhaps we need some Kconfig updates to select cfg80211?
Depend on, please -- cfg80211 has dependencies that would otherwise be
messed up.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH] b43: Fix locking problem when stopping rfkill polling
From: Johannes Berg @ 2009-10-07 22:36 UTC (permalink / raw)
To: Larry Finger; +Cc: John W. Linville, linux-wireless
In-Reply-To: <4ACCEBE8.8010803@lwfinger.net>
[-- Attachment #1: Type: text/plain, Size: 965 bytes --]
On Wed, 2009-10-07 at 14:28 -0500, Larry Finger wrote:
> > OK, but why do we start polling under the lock but stop polling without
> > the lock? Should we start polling without holding the lock too?
>
> I'll test that, but I suspect it doesn't matter. Of course, the reason
> I put the stop under the lock was for symmetry, but then I got the
> following when shutting down:
>
> b43-phy0 debug: Removing Interface type 2
>
> =======================================================
> [ INFO: possible circular locking dependency detected ]
> 2.6.32-rc3-wl #225
> -------------------------------------------------------
> modprobe/25391 is trying to acquire lock:
> (&(&rfkill->poll_work)->work){+.+...}, at: [<ffffffff81054a7f>]
> __cancel_work_timer+0xd9/0x224
This is because when stopping polling we need to cancel the work and
sync on it, but when starting it's completely async so starting can be
in any context.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH] b43: Fix locking problem when stopping rfkill polling
From: Larry Finger @ 2009-10-07 22:43 UTC (permalink / raw)
To: Johannes Berg; +Cc: John W. Linville, linux-wireless
In-Reply-To: <1254955015.3713.9.camel@johannes.local>
Johannes Berg wrote:
> This is because when stopping polling we need to cancel the work and
> sync on it, but when starting it's completely async so starting can be
> in any context.
Does that mean that start could be moved outside the mutex_lock so
that the start and stop would look symmetrical in b43?
Larry
^ permalink raw reply
* Re: [PATCH] wireless: make WEXT_SPY and WEXT_PRIV select WEXT_CORE
From: Randy Dunlap @ 2009-10-07 22:54 UTC (permalink / raw)
To: Johannes Berg
Cc: John W. Linville, linux-wireless, Stephen Rothwell, linux-next,
linux-kernel
In-Reply-To: <1254954842.3713.7.camel@johannes.local>
Johannes Berg wrote:
> On Wed, 2009-10-07 at 14:55 -0700, Randy Dunlap wrote:
>> John W. Linville wrote:
>>> Should prevent this build error reported by Randy...
>>>
>>> net/wireless/wext-priv.c:206: error: implicit declaration of function 'call_commit_handler'
>>> make[3]: *** [net/wireless/wext-priv.o] Error 1
>>>
>>> Reported-by: Randy Dunlap <randy.dunlap@oracle.com>
>>> Signed-off-by: John W. Linville <linville@tuxdriver.com>
>> Sorry, it did not work for me.
>
>> linux-next-20091007/net/wireless/wext-priv.c:206: error: implicit declaration of function 'call_commit_handler'
>> make[3]: *** [net/wireless/wext-priv.o] Error 1
>>
>> Drivers like hostap and orinoco (hermes) select WEXT_PRIV regardless
>> of the setting of WEXT_CORE. oh, and staging/ drivers do that also.
>
> But they also select WIRELESS_EXT, which should cause WEXT_CORE to be
> turned on. Is it possible that is failing?
# CONFIG_WIRELESS is not set
CONFIG_WIRELESS_EXT=y
CONFIG_WEXT_SPY=y
CONFIG_WEXT_PRIV=y
WEXT_CORE is not enabled. I haven't found the culprit, but I suspect "select".
but what in WIRELESS_EXT would also cause WEXT_CORE to be enabled?
~Randy
^ permalink raw reply
* Re: [PATCH] b43: Fix locking problem when stopping rfkill polling
From: Michael Buesch @ 2009-10-07 23:08 UTC (permalink / raw)
To: Larry Finger; +Cc: Johannes Berg, John W. Linville, linux-wireless
In-Reply-To: <4ACD1998.5020902@lwfinger.net>
On Thursday 08 October 2009 00:43:36 Larry Finger wrote:
> Johannes Berg wrote:
> > This is because when stopping polling we need to cancel the work and
> > sync on it, but when starting it's completely async so starting can be
> > in any context.
>
> Does that mean that start could be moved outside the mutex_lock so
> that the start and stop would look symmetrical in b43?
I think it's already complicated enough what's safe in b43 to do
outside of the locks. Let's not complicate it further. The simple rule is:
Do it locked. The only exception really are syncing functions which sync
for code holding the same lock.
--
Greetings, Michael.
^ permalink raw reply
* Re: [PATCH] wireless: make WEXT_SPY and WEXT_PRIV select WEXT_CORE
From: Johannes Berg @ 2009-10-07 23:14 UTC (permalink / raw)
To: Randy Dunlap
Cc: John W. Linville, linux-wireless, Stephen Rothwell, linux-next,
linux-kernel
In-Reply-To: <4ACD1C3D.3030506@oracle.com>
[-- Attachment #1: Type: text/plain, Size: 538 bytes --]
On Wed, 2009-10-07 at 15:54 -0700, Randy Dunlap wrote:
> > But they also select WIRELESS_EXT, which should cause WEXT_CORE to be
> > turned on. Is it possible that is failing?
>
> # CONFIG_WIRELESS is not set
> CONFIG_WIRELESS_EXT=y
> CONFIG_WEXT_SPY=y
> CONFIG_WEXT_PRIV=y
>
> WEXT_CORE is not enabled. I haven't found the culprit, but I suspect "select".
Interesting.
> but what in WIRELESS_EXT would also cause WEXT_CORE to be enabled?
Well, the way WEXT_CORE is defined as def_bool y ought to, no?
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH] wireless: make WEXT_SPY and WEXT_PRIV select WEXT_CORE
From: Randy Dunlap @ 2009-10-08 0:12 UTC (permalink / raw)
To: Johannes Berg
Cc: John W. Linville, linux-wireless, Stephen Rothwell, linux-next,
linux-kernel
In-Reply-To: <1254957256.3713.10.camel@johannes.local>
On Thu, 08 Oct 2009 01:14:16 +0200 Johannes Berg wrote:
> On Wed, 2009-10-07 at 15:54 -0700, Randy Dunlap wrote:
>
> > > But they also select WIRELESS_EXT, which should cause WEXT_CORE to be
> > > turned on. Is it possible that is failing?
> >
> > # CONFIG_WIRELESS is not set
> > CONFIG_WIRELESS_EXT=y
> > CONFIG_WEXT_SPY=y
> > CONFIG_WEXT_PRIV=y
> >
> > WEXT_CORE is not enabled. I haven't found the culprit, but I suspect "select".
>
> Interesting.
>
> > but what in WIRELESS_EXT would also cause WEXT_CORE to be enabled?
>
> Well, the way WEXT_CORE is defined as def_bool y ought to, no?
Ah, I see what you mean.
Here's what's happening:
net/wireless/Kconfig says:
config WEXT_CORE
def_bool y
depends on CFG80211_WEXT || WIRELESS_EXT
and net/Kconfig says:
if WIRELESS
source "net/wireless/Kconfig"
source "net/mac80211/Kconfig"
endif # WIRELESS
so WEXT_CORE actually depends on NET && WIRELESS && (CFG80211_WEXT || WIRELESS_EXT)
(that's what xconfig shows me).
But WIRELESS is not enabled. Pooh.
I was already toying with making CONFIG_WIRELESS a real/usable kconfig symbol.
That may have to be done unless someone else comes up with another solution.
---
~Randy
^ permalink raw reply
* Re: Disassociating atheros wlan with 2.6.31
From: Tim Walberg @ 2009-10-08 1:12 UTC (permalink / raw)
To: Kristoffer Ericson
Cc: Justin P. Mattock, Stefan Lippers-Hollmann, linux-wireless,
linux-kernel@vger.kernel.org
In-Reply-To: <20091004174535.777d233c.kristoffer.ericson@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 14417 bytes --]
Another confirmed instance of this on ath9k - on 2.6.31.2 and 2.6.31.3 - didn't
happen on 2.6.30.6 or 2.6.30.9. A couple other interesting facts:
- it seems to be related (at least in my case) to heavy transmit load -
I can download a kernel tarball without it failing, but if I try to
copy it to another system, it fails within 2 seconds reliably...
- running 'rmmod ath9k ath mac80211 cfg80211' followed by 'modprobe ath9k'
clears it up
No indication in dmesg except:
wlan<n>: no probe response from AP AA:BB:DD:EE:FF:GG - disassociating
and suddenly no packets going in either direction.
I'm in the process of moving back to 2.6.30.x for now...
On 10/04/2009 17:45 +0200, Kristoffer Ericson wrote:
>> Hi,
>>
>> Did a bisect or more exactly tried to do a bisect. Ive managed to bisect myself
>> into a deadend so far (must have marked good in wrong place). The disassociation happens
>> at seemingly regular intervalls but once I started bisecting it started
>> to be more irregular. Perhaps it was simply due to me not being able
>> to user internet (and share) since my 3G modem oopsed all the time.
>> Suspecting its load sensitive.
>>
>> Anyhow heres what I got so far. The bad versions should be correct
>> while the good versions might not be. Reason being that I didnt wait
>> long enough for the disassociation to appear and thus faulty marking
>> something as good.
>> Using the bad should however narrow it down somewhat. From what
>> I can see between my last good and bad is only non-related stuff,
>> so must be atleast one "good" mistake in there.
>>
>> git bisect start
>> # good: [07a2039b8eb0af4ff464efd3dfd95de5c02648c6] Linux 2.6.30
>> git bisect good 07a2039b8eb0af4ff464efd3dfd95de5c02648c6
>> # bad: [74fca6a42863ffacaf7ba6f1936a9f228950f657] Linux 2.6.31
>> git bisect bad 74fca6a42863ffacaf7ba6f1936a9f228950f657
>> # good: [925d74ae717c9a12d3618eb4b36b9fb632e2cef3] V4L/DVB (11736): videobuf: modify return value of VIDIOC_REQBUFS ioctl
>> git bisect good 925d74ae717c9a12d3618eb4b36b9fb632e2cef3
>> # bad: [a380137900fca5c79e6daa9500bdb6ea5649188e] ixgbe: Fix device capabilities of 82599 single speed fiber NICs.
>> git bisect bad a380137900fca5c79e6daa9500bdb6ea5649188e
>> # bad: [1dbb5765acc7a6fe4bc1957c001037cc9d02ae03] Staging: android: lowmemorykiller: fix up remaining checkpatch warnings
>> git bisect bad 1dbb5765acc7a6fe4bc1957c001037cc9d02ae03
>> # bad: [2b1b62e841867326fa260a581d97941c32abc35b] MIPS: Cavium-Octeon: Add more board type constants.
>> git bisect bad 2b1b62e841867326fa260a581d97941c32abc35b
>> # good: [517d08699b250021303f9a7cf0d758b6dc0748ed] Merge branch 'akpm'
>> git bisect good 517d08699b250021303f9a7cf0d758b6dc0748ed
>> # good: [5e2c217eee18a4627a32c49f57f47dbac67dcf23] V4L/DVB (11958): usbvision-core.c: vfree does its own NULL check
>> git bisect good 5e2c217eee18a4627a32c49f57f47dbac67dcf23
>> # bad: [a9349315f65cd6a16e8fab1f6cf0fd40f379c4db] V4L/DVB (11819): Siano: smscore - fix get_common_buffer bug
>> git bisect bad a9349315f65cd6a16e8fab1f6cf0fd40f379c4db
>> # good: [06f837cadbcdedb45f0702cb57c99c404ae921e6] V4L/DVB (11784): cx88: Fix race condition between cx8800 startup and hald
>> git bisect good 06f837cadbcdedb45f0702cb57c99c404ae921e6
>> # good: [1339f9108a84710969903e892dcf1849ae1215cf] V4L/DVB (11726): Modify the file license to match all other Siano's files
>> git bisect good 1339f9108a84710969903e892dcf1849ae1215cf
>>
>> Best wishes
>> Kristoffer Ericson
>>
>> On Thu, 24 Sep 2009 13:07:12 -0700
>> "Justin P. Mattock" <justinmattock@gmail.com> wrote:
>>
>> > Stefan Lippers-Hollmann wrote:
>> > > Hi
>> > >
>> > > CCing linux-wireless@vger.kernel.org, as it's not very likely to get
>> > > noticed here by wireless developers.
>> > >
>> > > On Thursday 24 September 2009, Justin P. Mattock wrote:
>> > >
>> > >> Kristoffer Ericson wrote:
>> > >>
>> > >>> Greetings,
>> > >>>
>> > >>> When moving from vanilla 2.6.30->2.6.31 I noticed that I get dissasociated from
>> > >>> my wlan hub with regular intervalls. This did not happen on 2.6.30.
>> > >>> I cant see any pattern aside from that it happens at regular intervalls
>> > >>> (around 10-15mins). It works again when I re-identifies myself.
>> > >>>
>> > >>> Got an Asus 1000HE with Atheros chipset.
>> > >>> Havent had time to bisect it, just wanted to check
>> > >>> if this is an known issue. Ive ruled out faulty wlan hub
>> > >>> since everything works fine when going back to 2.6.30.
>> > >>>
>> > >>> nothing much on dmesg:
>> > >>> uhci_hcd 0000:00:1d.1: UHCI Host Controller
>> > >>> uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 3
>> > >>> uhci_hcd 0000:00:1d.1: irq 19, io base 0x0000d480
>> > >>> usb usb3: configuration #1 chosen from 1 choice
>> > >>> hub 3-0:1.0: USB hub found
>> > >>> hub 3-0:1.0: 2 ports detected
>> > >>> uhci_hcd 0000:00:1d.2: PCI INT C -> GSI 18 (level, low) -> IRQ 18
>> > >>> uhci_hcd 0000:00:1d.2: setting latency timer to 64
>> > >>> uhci_hcd 0000:00:1d.2: UHCI Host Controller
>> > >>> uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 4
>> > >>> uhci_hcd 0000:00:1d.2: irq 18, io base 0x0000d800
>> > >>> usb usb4: configuration #1 chosen from 1 choice
>> > >>> hub 4-0:1.0: USB hub found
>> > >>> hub 4-0:1.0: 2 ports detected
>> > >>> uhci_hcd 0000:00:1d.3: PCI INT D -> GSI 16 (level, low) -> IRQ 16
>> > >>> uhci_hcd 0000:00:1d.3: setting latency timer to 64
>> > >>> uhci_hcd 0000:00:1d.3: UHCI Host Controller
>> > >>> uhci_hcd 0000:00:1d.3: new USB bus registered, assigned bus number 5
>> > >>> uhci_hcd 0000:00:1d.3: irq 16, io base 0x0000d880
>> > >>> usb usb5: configuration #1 chosen from 1 choice
>> > >>> hub 5-0:1.0: USB hub found
>> > >>> hub 5-0:1.0: 2 ports detected
>> > >>> input: ETPS/2 Elantech Touchpad as /devices/platform/i8042/serio1/input/input7
>> > >>> usb 1-4: new high speed USB device using ehci_hcd and address 3
>> > >>> usb 1-4: configuration #1 chosen from 1 choice
>> > >>> hub 1-4:1.0: USB hub found
>> > >>> hub 1-4:1.0: 4 ports detected
>> > >>> usb 1-5: new high speed USB device using ehci_hcd and address 4
>> > >>> usb 1-5: configuration #1 chosen from 1 choice
>> > >>> usb 1-8: new high speed USB device using ehci_hcd and address 6
>> > >>> usb 1-8: configuration #1 chosen from 1 choice
>> > >>> Initializing USB Mass Storage driver...
>> > >>> scsi4 : SCSI emulation for USB Mass Storage devices
>> > >>> usbcore: registered new interface driver usb-storage
>> > >>> USB Mass Storage support registered.
>> > >>> usb-storage: device found at 4
>> > >>> usb-storage: waiting for device to settle before scanning
>> > >>> HDA Intel 0000:00:1b.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
>> > >>> HDA Intel 0000:00:1b.0: setting latency timer to 64
>> > >>> usb 2-2: new full speed USB device using uhci_hcd and address 2
>> > >>> ath9k 0000:01:00.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19
>> > >>> ath9k 0000:01:00.0: setting latency timer to 64
>> > >>> usb 2-2: configuration #1 chosen from 1 choice
>> > >>> input: HDA Digital PCBeep as /devices/pci0000:00/0000:00:1b.0/input/input8
>> > >>> usbcore: registered new interface driver usbserial
>> > >>> USB Serial support registered for generic
>> > >>> usb 5-1: new full speed USB device using uhci_hcd and address 2
>> > >>> usb 5-1: configuration #1 chosen from 1 choice
>> > >>> usb 1-4.1: new full speed USB device using ehci_hcd and address 7
>> > >>> ath: EEPROM regdomain: 0x60
>> > >>> ath: EEPROM indicates we should expect a direct regpair map
>> > >>> ath: Country alpha2 being used: 00
>> > >>> ath: Regpair used: 0x60
>> > >>> Bluetooth: Core ver 2.15
>> > >>> NET: Registered protocol family 31
>> > >>> Bluetooth: HCI device and connection manager initialized
>> > >>> Bluetooth: HCI socket layer initialized
>> > >>> Bluetooth: Generic Bluetooth USB driver ver 0.5
>> > >>> usb 1-4.1: configuration #1 chosen from 1 choice
>> > >>> usb 1-4.2: new low speed USB device using ehci_hcd and address 8
>> > >>> usb 1-4.2: configuration #1 chosen from 1 choice
>> > >>> usb 1-4.4: new low speed USB device using ehci_hcd and address 9
>> > >>> usbcore: registered new interface driver hiddev
>> > >>> input: HID 04d9:1203 as /devices/pci0000:00/0000:00:1d.7/usb1/1-4/1-4.2/1-4.2:1.0/input/input9
>> > >>> generic-usb 0003:04D9:1203.0001: input,hidraw0: USB HID v1.11 Keyboard [HID 04d9:1203] on usb-0000:00:1d.7-4.2/input0
>> > >>> input: HID 04d9:1203 as /devices/pci0000:00/0000:00:1d.7/usb1/1-4/1-4.2/1-4.2:1.1/input/input10
>> > >>> generic-usb 0003:04D9:1203.0002: input,hidraw1: USB HID v1.11 Device [HID 04d9:1203] on usb-0000:00:1d.7-4.2/input1
>> > >>> usbcore: registered new interface driver usbhid
>> > >>> usbhid: v2.6:USB HID core driver
>> > >>> usb 1-4.4: configuration #1 chosen from 1 choice
>> > >>> input: B16_b_02 USB-PS/2 Optical Mouse as /devices/pci0000:00/0000:00:1d.7/usb1/1-4/1-4.4/1-4.4:1.0/input/input11
>> > >>> generic-usb 0003:046D:C025.0003: input,hidraw2: USB HID v1.10 Mouse [B16_b_02 USB-PS/2 Optical Mouse] on usb-0000:00:1d.7-4.4/input0
>> > >>> usbcore: registered new interface driver btusb
>> > >>> usbcore: registered new interface driver usbserial_generic
>> > >>> usbserial: USB Serial Driver core
>> > >>> USB Serial support registered for GSM modem (1-port)
>> > >>> option 2-2:1.0: GSM modem (1-port) converter detected
>> > >>> usb 2-2: GSM modem (1-port) converter now attached to ttyUSB0
>> > >>> option 2-2:1.1: GSM modem (1-port) converter detected
>> > >>> usb 2-2: GSM modem (1-port) converter now attached to ttyUSB1
>> > >>> usbcore: registered new interface driver option
>> > >>> option: v0.7.2:USB Driver for GSM modems
>> > >>> USB Serial support registered for pl2303
>> > >>> pl2303 1-4.1:1.0: pl2303 converter detected
>> > >>> usb 1-4.1: pl2303 converter now attached to ttyUSB2
>> > >>> usbcore: registered new interface driver pl2303
>> > >>> pl2303: Prolific PL2303 USB to serial adaptor driver
>> > >>> phy0: Selected rate control algorithm 'ath9k_rate_control'
>> > >>> Registered led device: ath9k-phy0::radio
>> > >>> Registered led device: ath9k-phy0::assoc
>> > >>> Registered led device: ath9k-phy0::tx
>> > >>> Registered led device: ath9k-phy0::rx
>> > >>> phy0: Atheros AR9280 MAC/BB Rev:2 AR5133 RF Rev:d0: mem=0xf8880000, irq=19
>> > >>> scsi 4:0:0:0: Direct-Access Single Flash Reader 1.00 PQ: 0 ANSI: 0
>> > >>> sd 4:0:0:0: Attached scsi generic sg1 type 0
>> > >>> sd 4:0:0:0: [sdb] 15954944 512-byte logical blocks: (8.16 GB/7.60 GiB)
>> > >>> usb-storage: device scan complete
>> > >>> sd 4:0:0:0: [sdb] Write Protect is off
>> > >>> sd 4:0:0:0: [sdb] Mode Sense: 03 00 00 00
>> > >>> sd 4:0:0:0: [sdb] Assuming drive cache: write through
>> > >>> sd 4:0:0:0: [sdb] Assuming drive cache: write through
>> > >>> sdb: sdb1
>> > >>> sd 4:0:0:0: [sdb] Assuming drive cache: write through
>> > >>> sd 4:0:0:0: [sdb] Attached SCSI removable disk
>> > >>> EXT3-fs warning: maximal mount count reached, running e2fsck is recommended
>> > >>> EXT3 FS on sda1, internal journal
>> > >>> Bluetooth: L2CAP ver 2.13
>> > >>> Bluetooth: L2CAP socket layer initialized
>> > >>> Bluetooth: SCO (Voice Link) ver 0.6
>> > >>> Bluetooth: SCO socket layer initialized
>> > >>> Bluetooth: BNEP (Ethernet Emulation) ver 1.3
>> > >>> Bridge firewalling registered
>> > >>> Bluetooth: RFCOMM TTY layer initialized
>> > >>> Bluetooth: RFCOMM socket layer initialized
>> > >>> Bluetooth: RFCOMM ver 1.11
>> > >>> ATL1E 0000:03:00.0: irq 27 for MSI/MSI-X
>> > >>> fuse init (API version 7.12)
>> > >>> ip_tables: (C) 2000-2006 Netfilter Core Team
>> > >>> nf_conntrack version 0.5.0 (16384 buckets, 65536 max)
>> > >>> CONFIG_NF_CT_ACCT is deprecated and will be removed soon. Please use
>> > >>> nf_conntrack.acct=1 kernel parameter, acct=1 nf_conntrack module option or
>> > >>> sysctl net.netfilter.nf_conntrack_acct=1 to enable it.
>> > >>> wlan0: authenticate with AP 00:14:7c:ae:d1:90
>> > >>> wlan0: authenticated
>> > >>> wlan0: associate with AP 00:14:7c:ae:d1:90
>> > >>> wlan0: RX AssocResp from 00:14:7c:ae:d1:90 (capab=0x431 status=0 aid=5)
>> > >>> wlan0: associated
>> > >>> PPP generic driver version 2.4.2
>> > >>> NET: Registered protocol family 10
>> > >>> lo: Disabled Privacy Extensions
>> > >>> ADDRCONF(NETDEV_UP): eth0: link is not ready
>> > >>> PPP BSD Compression module registered
>> > >>> PPP Deflate Compression module registered
>> > >>> wlan0: no IPv6 routers present
>> > >>> CE: hpet increasing min_delta_ns to 15000 nsec
>> > >>> wlan0: no probe response from AP 00:14:7c:ae:d1:90 - disassociating
>> > >>> wlan0: authenticate with AP 00:14:7c:ae:d1:90
>> > >>> wlan0: authenticated
>> > >>> wlan0: associate with AP 00:14:7c:ae:d1:90
>> > >>> wlan0: RX AssocResp from 00:14:7c:ae:d1:90 (capab=0x431 status=0 aid=5)
>> > >>> wlan0: associated
>> > >>> wlan0: authenticate with AP 00:14:7c:ae:d1:90
>> > >>> wlan0: authenticated
>> > >>> wlan0: associate with AP 00:14:7c:ae:d1:90
>> > >>> wlan0: RX AssocResp from 00:14:7c:ae:d1:90 (capab=0x431 status=0 aid=5)
>> > >>> wlan0: associated
>> > >>> [kristoffer@boggieman wine.git]$
>> > >>>
>> > >>>
>> > >>>
>> > >>>
>> > >> yeah I'm seeing this with my macbook pro(ath9k)
>> > >> while streaming music, all of a sudden things just crap out.
>> > >> (not sure if this is why, or something else).
>> > >>
>> > >> Justin P. Mattock
>> > >>
>> > >
>> > > I'm getting similar reports for iwl3945 and 2.6.31.[01], but can't confirm
>> > > this on my own (non-iwl{3945,agn}, non-ath9k) hardware yet.
>> > >
>> > > Regards
>> > > Stefan Lippers-Hollmann
>> > >
>> > >
>> > I don't mind doing a bisect from 30 - present, but first I need to
>> > do some other stuff.
>> >
>> > Justin P. Mattock
>>
>>
>> --
>> Kristoffer Ericson <kristoffer.ericson@gmail.com>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at http://www.tux.org/lkml/
End of included message
--
twalberg@comcast.net
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Disassociating atheros wlan with 2.6.31
From: Justin P. Mattock @ 2009-10-08 1:49 UTC (permalink / raw)
To: Tim Walberg, Kristoffer Ericson, Justin P. Mattock,
Stefan Lippers-Hollmann, linux-wireless,
linux-kernel@vger.kernel.org
In-Reply-To: <20091008011247.GC22458@comcast.net>
Tim Walberg wrote:
> Another confirmed instance of this on ath9k - on 2.6.31.2 and 2.6.31.3 - didn't
> happen on 2.6.30.6 or 2.6.30.9. A couple other interesting facts:
>
> - it seems to be related (at least in my case) to heavy transmit load -
> I can download a kernel tarball without it failing, but if I try to
> copy it to another system, it fails within 2 seconds reliably...
> - running 'rmmod ath9k ath mac80211 cfg80211' followed by 'modprobe ath9k'
> clears it up
>
> No indication in dmesg except:
>
> wlan<n>: no probe response from AP AA:BB:DD:EE:FF:GG - disassociating
>
> and suddenly no packets going in either direction.
>
> I'm in the process of moving back to 2.6.30.x for now...
>
>
>
>
>
> On 10/04/2009 17:45 +0200, Kristoffer Ericson wrote:
>
>
>
I get this reliably by simple running a radio station
through mplayer(probably around 5/10 min of running)
when I run this commit:
2.6.31-rc8-00039-g03c3bbc I don't have this at all.
(I might of changed my .config without realizing it)
After running a bisect from this commit to current
I came up with nothing, which led me to believe that I must have through
the confusion changed something in my .config, or messed up
with choosing good/bad with the bisect because I didn't wait long enough for
this to fire off.
In any case either/or I'm still going to give a go at the bisect again
but this time wait longer(10/20 min) to really make sure I don't miss
anything.
BTW: when this hits for you is it pretty bad(no connection) i.g when
this fires off over here
music still plays from mplayer, but did notice that mplayer player all
of a sudden would die out, but
easily connected again.
Justin P. Mattock
^ permalink raw reply
* Re: [.32-rc3] scheduler: iwlagn consistently high in "waiting for CPU"
From: Mike Galbraith @ 2009-10-08 4:05 UTC (permalink / raw)
To: Frans Pop
Cc: Arjan van de Ven, Linux Kernel Mailing List, Ingo Molnar,
Peter Zijlstra, linux-wireless
In-Reply-To: <200910072034.57511.elendil@planet.nl>
On Wed, 2009-10-07 at 20:34 +0200, Frans Pop wrote:
> On Wednesday 07 October 2009, Frans Pop wrote:
> > On Tuesday 06 October 2009, Frans Pop wrote:
> > > I've checked for 2.6.31.1 now and iwlagn is listed high there too when
> > > the system is idle, but with normal values of 60-100 ms. And phy0 has
> > > normal values of below 10 ms.
> > > I've now rebooted with today's mainline git; phy0 now frequently shows
> > > with values of around 100 ms too (i.e. higher than last time).
> >
> > Mike privately sent me a script to try to capture the latencies with
> > perf, but the perf output does not show any high latencies at all. It
> > looks as if we may have found a bug in latencytop here instead.
>
> Not sure if it's relevant nor what it means, but I frequently see two lines
> for iwlagn, e.g:
>
> Scheduler: waiting for cpu 102.4 msec 99.7 %
> . 3.3 msec 0.3 %
>
> I get the same results with both latencytop 0.4 and 0.5.
OK, I see latencytop spikes here on an idle box too, to the tune of up
to a _second_. Booting with nohz=off seems to have cured it.
I wanted to see if that's also the perf sched record -C N trouble I
warned you not to try when recording with script, but unfortunately,
after pulling this morning...
marge:/root/tmp # perf sched lat --sort=max
Segmentation fault
...perf sched got busted. Seems likely to be same thing for both
though, as magnitude/frequency of bogons is very similar.
-Mike
^ permalink raw reply
* Re: [PATCH 1/6] ath9k: move common->debug_mask setting to ath_init_softc()
From: Luis R. Rodriguez @ 2009-10-08 4:34 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linville, linux-wireless, vasanth, Sujith.Manoharan
In-Reply-To: <1254878351-32433-2-git-send-email-lrodriguez@atheros.com>
On Tue, Oct 06, 2009 at 09:19:06PM -0400, Luis R. Rodriguez wrote:
> What this means is we can enable now debug prints without
> requiring CONFIG_ATH9K_DEBUG.
>
> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
> +MODULE_PARM_DESC(ath9k_debug, "Debugging mask");
John, as sujith notes, this should be MODULE_PARM_DESC(debug ...
Thanks sujith.
so here's v2:
From: Luis R. Rodriguez <lrodriguez@atheros.com>
Subject: [PATCH v2 1/6] ath9k: move common->debug_mask setting to ath_init_softc()
What this means is we can enable now debug prints without
requiring CONFIG_ATH9K_DEBUG.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
drivers/net/wireless/ath/ath9k/debug.c | 5 -----
drivers/net/wireless/ath/ath9k/main.c | 5 +++++
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/debug.c b/drivers/net/wireless/ath/ath9k/debug.c
index 25ae88e..84f4426 100644
--- a/drivers/net/wireless/ath/ath9k/debug.c
+++ b/drivers/net/wireless/ath/ath9k/debug.c
@@ -23,9 +23,6 @@
#define REG_READ_D(_ah, _reg) \
ath9k_hw_common(_ah)->ops->read((_ah), (_reg))
-static unsigned int ath9k_debug = ATH_DBG_DEFAULT;
-module_param_named(debug, ath9k_debug, uint, 0);
-
static struct dentry *ath9k_debugfs_root;
static int ath9k_debugfs_open(struct inode *inode, struct file *file)
@@ -565,8 +562,6 @@ int ath9k_init_debug(struct ath_hw *ah)
struct ath_common *common = ath9k_hw_common(ah);
struct ath_softc *sc = (struct ath_softc *) common->priv;
- common->debug_mask = ath9k_debug;
-
if (!ath9k_debugfs_root)
return -ENOENT;
diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
index 86374ad..aeda541 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -29,6 +29,10 @@ static int modparam_nohwcrypt;
module_param_named(nohwcrypt, modparam_nohwcrypt, int, 0444);
MODULE_PARM_DESC(nohwcrypt, "Disable hardware encryption");
+static unsigned int ath9k_debug = ATH_DBG_DEFAULT;
+module_param_named(debug, ath9k_debug, uint, 0);
+MODULE_PARM_DESC(debug, "Debugging mask");
+
/* We use the hw_value as an index into our private channel structure */
#define CHAN2G(_freq, _idx) { \
@@ -1637,6 +1641,7 @@ static int ath_init_softc(u16 devid, struct ath_softc *sc, u16 subsysid,
common->ah = ah;
common->hw = sc->hw;
common->priv = sc;
+ common->debug_mask = ath9k_debug;
/*
* Cache line size is used to size and align various
--
1.6.0.4
^ permalink raw reply related
* Re: [PATCH 1/6] ath9k: move common->debug_mask setting to ath_init_softc()
From: Luis R. Rodriguez @ 2009-10-08 4:58 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linville, linux-wireless, vasanth, Sujith.Manoharan
In-Reply-To: <20091008043426.GA5760@bombadil.infradead.org>
On Thu, Oct 8, 2009 at 12:34 AM, Luis R. Rodriguez
<lrodriguez@atheros.com> wrote:
> On Tue, Oct 06, 2009 at 09:19:06PM -0400, Luis R. Rodriguez wrote:
>> What this means is we can enable now debug prints without
>> requiring CONFIG_ATH9K_DEBUG.
>>
>> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
>
>> +MODULE_PARM_DESC(ath9k_debug, "Debugging mask");
>
> John, as sujith notes, this should be MODULE_PARM_DESC(debug ...
>
> Thanks sujith.
>
> so here's v2:
Oh this is merged already -- either you can take this one or I'll send
a fix now.
Luis
^ permalink raw reply
* [PATCH] ath9k: use right parameter for MODULE_PARM_DESC() for debug
From: Luis R. Rodriguez @ 2009-10-08 5:00 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Luis R. Rodriguez
Reported-by: sujith.manoharan@atheros.com
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
drivers/net/wireless/ath/ath9k/main.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
index 36af6f3..69cf702 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -31,7 +31,7 @@ MODULE_PARM_DESC(nohwcrypt, "Disable hardware encryption");
static unsigned int ath9k_debug = ATH_DBG_DEFAULT;
module_param_named(debug, ath9k_debug, uint, 0);
-MODULE_PARM_DESC(ath9k_debug, "Debugging mask");
+MODULE_PARM_DESC(debug, "Debugging mask");
/* We use the hw_value as an index into our private channel structure */
--
1.6.0.4
^ permalink raw reply related
* Re: [.32-rc3] scheduler: iwlagn consistently high in "waiting for CPU"
From: Mike Galbraith @ 2009-10-08 6:23 UTC (permalink / raw)
To: Frans Pop
Cc: Arjan van de Ven, Linux Kernel Mailing List, Ingo Molnar,
Peter Zijlstra, linux-wireless
In-Reply-To: <1254974743.7797.21.camel@marge.simson.net>
On Thu, 2009-10-08 at 06:05 +0200, Mike Galbraith wrote:
> On Wed, 2009-10-07 at 20:34 +0200, Frans Pop wrote:
> > On Wednesday 07 October 2009, Frans Pop wrote:
> > > On Tuesday 06 October 2009, Frans Pop wrote:
> > > > I've checked for 2.6.31.1 now and iwlagn is listed high there too when
> > > > the system is idle, but with normal values of 60-100 ms. And phy0 has
> > > > normal values of below 10 ms.
> > > > I've now rebooted with today's mainline git; phy0 now frequently shows
> > > > with values of around 100 ms too (i.e. higher than last time).
> > >
> > > Mike privately sent me a script to try to capture the latencies with
> > > perf, but the perf output does not show any high latencies at all. It
> > > looks as if we may have found a bug in latencytop here instead.
> >
> > Not sure if it's relevant nor what it means, but I frequently see two lines
> > for iwlagn, e.g:
> >
> > Scheduler: waiting for cpu 102.4 msec 99.7 %
> > . 3.3 msec 0.3 %
> >
> > I get the same results with both latencytop 0.4 and 0.5.
>
> OK, I see latencytop spikes here on an idle box too, to the tune of up
> to a _second_. Booting with nohz=off seems to have cured it.
>
> I wanted to see if that's also the perf sched record -C N trouble I
> warned you not to try when recording with script, but unfortunately,
> after pulling this morning...
>
> marge:/root/tmp # perf sched lat --sort=max
> Segmentation fault
>
> ...perf sched got busted. Seems likely to be same thing for both
> though, as magnitude/frequency of bogons is very similar.
Reverting problematic commit showed that nohz isn't the source of perf
sched record -C N oddity.
However, aside from latencytop seemingly having trouble with nohz, there
appears to be a problem with perf sched record -a as well, the same one
Arjan just fixed for perf timechart.
In thread - [PATCH] perf timechart: Work around commit 42e59d7d19dc4b4,
Arjan said..
<quote>
Commit 42e59d7d19dc4b4 introduced a sample frequency framework..
.. however it unfortunately changed how perf events get recorded,..
</quote>
Monkey see monkey (eep) do, and record mostly idle box, only amarok
doing it's thing...
Before:
marge:/root/tmp # perf sched record sleep 1
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.279 MB perf.data (~12208 samples) ]
After:
marge:/root/tmp # perf sched record sleep 1
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.649 MB perf.data (~28349 samples) ]
perf_counter tools: make perf sched pass -F 0 to record
Commit 42e59d7d19dc4b4 introduced a sample frequency framework..
.. however it unfortunately changed how perf events get recorded,
and caused sched to miss events.
This patch causes the sched code to use -F 0 to not use the
new framework when recording sched data.
Signed-off-by: Mike Galbraith <efault@gmx.de>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
LKML-Reference: <new-submission>
---
tools/perf/builtin-sched.c | 1 +
1 file changed, 1 insertion(+)
Index: linux-2.6/tools/perf/builtin-sched.c
===================================================================
--- linux-2.6.orig/tools/perf/builtin-sched.c
+++ linux-2.6/tools/perf/builtin-sched.c
@@ -1902,6 +1902,7 @@ static const char *record_args[] = {
"-f",
"-m", "1024",
"-c", "1",
+ "-F", "0",
"-e", "sched:sched_switch:r",
"-e", "sched:sched_stat_wait:r",
"-e", "sched:sched_stat_sleep:r",
^ permalink raw reply
* Re: NULL pointer deref at wext ioctl (Re: [PATCH] compat-2.6: adding ethtool.h to compat-2.6.31.h)
From: Hin-Tak Leung @ 2009-10-08 6:28 UTC (permalink / raw)
To: Johannes Berg; +Cc: Luis R. Rodriguez, John W. Linville, linux-wireless
In-Reply-To: <1254952886.3713.4.camel@johannes.local>
[-- Attachment #1: Type: text/plain, Size: 2916 bytes --]
On Wed, Oct 7, 2009 at 11:01 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Wed, 2009-10-07 at 20:28 +0100, Hin-Tak Leung wrote:
>> On Wed, Oct 7, 2009 at 8:16 PM, Hin-Tak Leung <hintak.leung@gmail.com> wrote:
>>
>> > It is probably just a transient problem with recent activities - I had
>> > a NULL pointer deref from loading rtl8187 of compat-wireless
>> > v2.6.32-rc3-39563-g98c2609 -
>> >
>> > BUG: unable to handle kernel NULL pointer dereference at 000000000000003d
>> > IP: [<ffffffff8147822c>] wext_ioctl_dispatch+0xd9/0x180
>> > PGD 61c2b067 PUD 6246f067 PMD 0
>> > Oops: 0000 [#1] SMP
>> > ...
>> > Call Trace:
>> > [<ffffffff814783f5>] wext_handle_ioctl+0x4d/0x98
>> > [<ffffffff813e53a5>] dev_ioctl+0x625/0x662
>> > [<ffffffff813cfa45>] sock_ioctl+0x225/0x248
>> > [<ffffffff811237a3>] vfs_ioctl+0x31/0xaa
>> > [<ffffffff811e1801>] ? security_d_instantiate+0x37/0x4d
>> > [<ffffffff81123c88>] do_vfs_ioctl+0x46c/0x4c3
>> > [<ffffffff81123d44>] sys_ioctl+0x65/0x9c
>> > [<ffffffff81012082>] system_call_fastpath+0x16/0x1b
>> >
>> > I'm sure whatever changes made this happen will go away soon, so I'll
>> > just re-try in a few days... but if anybody knows what commit causes
>> > this (and what fixes it!), I'd like to know.
>> >
>>
>> Hiya, It looks like I last used compat-wireless successfully was on
>> 25th (I am not saying it breaks after - I just haven't tried until
>> yesterday, possibly), and most of the recent changes are per-driver,
>> but there is a big code drop from Johannes dated 27th on 'wext:
>> refactor' . Changes from that or dependent changes?
>
> Probably -- but I don't see this problem on stock kernel and I'm not
> sure what could be causing it for compat-wireless.
>
> This will be the old copy of wext_ioctl_dispatch. It'd certainly help to
> get disassembly/the source line of the oops.
>
> johannes
>
The crash came from the fedora koji kernel 2.6.30.8-67.fc11.x86_64 (+
bleed-edge compat-wireless), so John can probably correct me if I am
doing wrong or he can probably provide a better answer based on the
info.
I installed the debug packages kernel-debuginfo-2.6.30.8-67.fc11 ,
kernel-debuginfo-common-x86_64-2.6.30.8-67.fc11 , then dump the whole
thing to work out the address, before selecting the adress as:
objdump -l -d --start-address=0xffffffff81478153
--stop-address=0xffffffff81478440 -S
/usr/lib/debug/lib/modules/2.6.30.8-67.fc11.x86_64/vmlinux
It looks like it is the 2nd of thes two lines around
/usr/src/debug/kernel-2.6.30/linux-2.6.30.x86_64/net/wireless/wext.c:448
which resulted in the null pointer dereference:
if (index < dev->wireless_handlers->num_private)
return dev->wireless_handlers->private[index];
Is there a more clever way of working out the addresses? I guess I
should have just subtracted and added a few k off the crash message,
rather than dumping the whole kernel to work out the addresses...
[-- Attachment #2: kernel-objdump-withlines --]
[-- Type: application/octet-stream, Size: 27217 bytes --]
/usr/lib/debug/lib/modules/2.6.30.8-67.fc11.x86_64/vmlinux: file format elf64-x86-64
Disassembly of section .text:
ffffffff81478153 <wext_ioctl_dispatch>:
wext_ioctl_dispatch():
/usr/src/debug/kernel-2.6.30/linux-2.6.30.x86_64/net/wireless/wext.c:1087
/* entry point from dev ioctl */
static int wext_ioctl_dispatch(struct net *net, struct ifreq *ifr,
unsigned int cmd, struct iw_request_info *info,
wext_ioctl_func standard,
wext_ioctl_func private)
{
ffffffff81478153: 55 push %rbp
ffffffff81478154: 48 89 e5 mov %rsp,%rbp
ffffffff81478157: 41 56 push %r14
ffffffff81478159: 41 55 push %r13
ffffffff8147815b: 41 54 push %r12
ffffffff8147815d: 53 push %rbx
ffffffff8147815e: 48 83 ec 20 sub $0x20,%rsp
ffffffff81478162: e8 99 9c b9 ff callq ffffffff81011e00 <mcount>
ffffffff81478167: 65 48 8b 04 25 28 00 mov %gs:0x28,%rax
ffffffff8147816e: 00 00
ffffffff81478170: 48 89 45 d8 mov %rax,-0x28(%rbp)
ffffffff81478174: 31 c0 xor %eax,%eax
wext_permission_check():
/usr/src/debug/kernel-2.6.30/linux-2.6.30.x86_64/net/wireless/wext.c:1075
/* If command is `set a parameter', or `get the encoding parameters',
* check if the user has the right to do it.
*/
static int wext_permission_check(unsigned int cmd)
{
if ((IW_IS_SET(cmd) || cmd == SIOCGIWENCODE || cmd == SIOCGIWENCODEEXT)
ffffffff81478176: f6 c2 01 test $0x1,%dl
wext_ioctl_dispatch():
/usr/src/debug/kernel-2.6.30/linux-2.6.30.x86_64/net/wireless/wext.c:1087
/* entry point from dev ioctl */
static int wext_ioctl_dispatch(struct net *net, struct ifreq *ifr,
unsigned int cmd, struct iw_request_info *info,
wext_ioctl_func standard,
wext_ioctl_func private)
{
ffffffff81478179: 49 89 fd mov %rdi,%r13
ffffffff8147817c: 48 89 f3 mov %rsi,%rbx
ffffffff8147817f: 4d 89 c4 mov %r8,%r12
ffffffff81478182: 4d 89 ce mov %r9,%r14
wext_permission_check():
/usr/src/debug/kernel-2.6.30/linux-2.6.30.x86_64/net/wireless/wext.c:1075
/* If command is `set a parameter', or `get the encoding parameters',
* check if the user has the right to do it.
*/
static int wext_permission_check(unsigned int cmd)
{
if ((IW_IS_SET(cmd) || cmd == SIOCGIWENCODE || cmd == SIOCGIWENCODEEXT)
ffffffff81478185: 74 14 je ffffffff8147819b <wext_ioctl_dispatch+0x48>
ffffffff81478187: 81 fa 2b 8b 00 00 cmp $0x8b2b,%edx
ffffffff8147818d: 74 0c je ffffffff8147819b <wext_ioctl_dispatch+0x48>
ffffffff8147818f: 81 fa 35 8b 00 00 cmp $0x8b35,%edx
ffffffff81478195: 0f 85 ef 00 00 00 jne ffffffff8147828a <wext_ioctl_dispatch+0x137>
/usr/src/debug/kernel-2.6.30/linux-2.6.30.x86_64/net/wireless/wext.c:1076
&& !capable(CAP_NET_ADMIN))
ffffffff8147819b: bf 0c 00 00 00 mov $0xc,%edi
ffffffff814781a0: 89 55 c8 mov %edx,-0x38(%rbp)
ffffffff814781a3: 48 89 4d c0 mov %rcx,-0x40(%rbp)
ffffffff814781a7: e8 78 8c be ff callq ffffffff81060e24 <capable>
ffffffff814781ac: 89 c6 mov %eax,%esi
/usr/src/debug/kernel-2.6.30/linux-2.6.30.x86_64/net/wireless/wext.c:1075
/* If command is `set a parameter', or `get the encoding parameters',
* check if the user has the right to do it.
*/
static int wext_permission_check(unsigned int cmd)
{
if ((IW_IS_SET(cmd) || cmd == SIOCGIWENCODE || cmd == SIOCGIWENCODEEXT)
ffffffff814781ae: 83 c8 ff or $0xffffffffffffffff,%eax
ffffffff814781b1: 8b 55 c8 mov -0x38(%rbp),%edx
ffffffff814781b4: 85 f6 test %esi,%esi
ffffffff814781b6: 48 8b 4d c0 mov -0x40(%rbp),%rcx
ffffffff814781ba: 0f 84 b9 00 00 00 je ffffffff81478279 <wext_ioctl_dispatch+0x126>
ffffffff814781c0: e9 c5 00 00 00 jmpq ffffffff8147828a <wext_ioctl_dispatch+0x137>
wireless_process_ioctl():
/usr/src/debug/kernel-2.6.30/linux-2.6.30.x86_64/net/wireless/wext.c:1043
return -ENODEV;
/* A bunch of special cases, then the generic case...
* Note that 'cmd' is already filtered in dev_ioctl() with
* (cmd >= SIOCIWFIRST && cmd <= SIOCIWLAST) */
if (cmd == SIOCGIWSTATS)
ffffffff814781c5: 81 fa 0f 8b 00 00 cmp $0x8b0f,%edx
/usr/src/debug/kernel-2.6.30/linux-2.6.30.x86_64/net/wireless/wext.c:1044
return standard(dev, iwr, cmd, info,
ffffffff814781cb: 49 c7 c0 06 7c 47 81 mov $0xffffffff81477c06,%r8
/usr/src/debug/kernel-2.6.30/linux-2.6.30.x86_64/net/wireless/wext.c:1043
return -ENODEV;
/* A bunch of special cases, then the generic case...
* Note that 'cmd' is already filtered in dev_ioctl() with
* (cmd >= SIOCIWFIRST && cmd <= SIOCIWLAST) */
if (cmd == SIOCGIWSTATS)
ffffffff814781d2: 74 69 je ffffffff8147823d <wext_ioctl_dispatch+0xea>
/usr/src/debug/kernel-2.6.30/linux-2.6.30.x86_64/net/wireless/wext.c:1047
return standard(dev, iwr, cmd, info,
&iw_handler_get_iwstats);
if (cmd == SIOCGIWPRIV && dev->wireless_handlers)
ffffffff814781d4: 81 fa 0d 8b 00 00 cmp $0x8b0d,%edx
ffffffff814781da: 75 11 jne ffffffff814781ed <wext_ioctl_dispatch+0x9a>
ffffffff814781dc: 48 83 bf 38 01 00 00 cmpq $0x0,0x138(%rdi)
ffffffff814781e3: 00
/usr/src/debug/kernel-2.6.30/linux-2.6.30.x86_64/net/wireless/wext.c:1048
return standard(dev, iwr, cmd, info,
ffffffff814781e4: 49 c7 c0 86 7b 47 81 mov $0xffffffff81477b86,%r8
/usr/src/debug/kernel-2.6.30/linux-2.6.30.x86_64/net/wireless/wext.c:1047
* (cmd >= SIOCIWFIRST && cmd <= SIOCIWLAST) */
if (cmd == SIOCGIWSTATS)
return standard(dev, iwr, cmd, info,
&iw_handler_get_iwstats);
if (cmd == SIOCGIWPRIV && dev->wireless_handlers)
ffffffff814781eb: 75 50 jne ffffffff8147823d <wext_ioctl_dispatch+0xea>
/usr/src/debug/kernel-2.6.30/linux-2.6.30.x86_64/net/wireless/wext.c:1052
return standard(dev, iwr, cmd, info,
&iw_handler_get_private);
/* Basic check */
if (!netif_device_present(dev))
ffffffff814781ed: f6 47 48 02 testb $0x2,0x48(%rdi)
ffffffff814781f1: 74 76 je ffffffff81478269 <wext_ioctl_dispatch+0x116>
get_handler():
/usr/src/debug/kernel-2.6.30/linux-2.6.30.x86_64/net/wireless/wext.c:437
{
/* Don't "optimise" the following variable, it will crash */
unsigned int index; /* *MUST* be unsigned */
/* Check if we have some wireless handlers defined */
if (dev->wireless_handlers == NULL)
ffffffff814781f3: 48 8b 87 38 01 00 00 mov 0x138(%rdi),%rax
ffffffff814781fa: 48 85 c0 test %rax,%rax
ffffffff814781fd: 74 4e je ffffffff8147824d <wext_ioctl_dispatch+0xfa>
/usr/src/debug/kernel-2.6.30/linux-2.6.30.x86_64/net/wireless/wext.c:442
return NULL;
/* Try as a standard command */
index = cmd - SIOCIWFIRST;
if (index < dev->wireless_handlers->num_standard)
ffffffff814781ff: 44 0f b7 00 movzwl (%rax),%r8d
/usr/src/debug/kernel-2.6.30/linux-2.6.30.x86_64/net/wireless/wext.c:441
/* Check if we have some wireless handlers defined */
if (dev->wireless_handlers == NULL)
return NULL;
/* Try as a standard command */
index = cmd - SIOCIWFIRST;
ffffffff81478203: 8d b2 00 75 ff ff lea -0x8b00(%rdx),%esi
/usr/src/debug/kernel-2.6.30/linux-2.6.30.x86_64/net/wireless/wext.c:442
if (index < dev->wireless_handlers->num_standard)
ffffffff81478209: 44 39 c6 cmp %r8d,%esi
ffffffff8147820c: 73 08 jae ffffffff81478216 <wext_ioctl_dispatch+0xc3>
/usr/src/debug/kernel-2.6.30/linux-2.6.30.x86_64/net/wireless/wext.c:443
return dev->wireless_handlers->standard[index];
ffffffff8147820e: 89 f6 mov %esi,%esi
ffffffff81478210: 48 8b 40 08 mov 0x8(%rax),%rax
ffffffff81478214: eb 16 jmp ffffffff8147822c <wext_ioctl_dispatch+0xd9>
/usr/src/debug/kernel-2.6.30/linux-2.6.30.x86_64/net/wireless/wext.c:447
/* Try as a private command */
index = cmd - SIOCIWFIRSTPRIV;
if (index < dev->wireless_handlers->num_private)
ffffffff81478216: 44 0f b7 40 02 movzwl 0x2(%rax),%r8d
/usr/src/debug/kernel-2.6.30/linux-2.6.30.x86_64/net/wireless/wext.c:446
index = cmd - SIOCIWFIRST;
if (index < dev->wireless_handlers->num_standard)
return dev->wireless_handlers->standard[index];
/* Try as a private command */
index = cmd - SIOCIWFIRSTPRIV;
ffffffff8147821b: 8d b2 20 74 ff ff lea -0x8be0(%rdx),%esi
/usr/src/debug/kernel-2.6.30/linux-2.6.30.x86_64/net/wireless/wext.c:447
if (index < dev->wireless_handlers->num_private)
ffffffff81478221: 44 39 c6 cmp %r8d,%esi
ffffffff81478224: 73 27 jae ffffffff8147824d <wext_ioctl_dispatch+0xfa>
/usr/src/debug/kernel-2.6.30/linux-2.6.30.x86_64/net/wireless/wext.c:448
return dev->wireless_handlers->private[index];
ffffffff81478226: 48 8b 40 10 mov 0x10(%rax),%rax
ffffffff8147822a: 89 f6 mov %esi,%esi
ffffffff8147822c: 4c 8b 04 f0 mov (%rax,%rsi,8),%r8
wireless_process_ioctl():
/usr/src/debug/kernel-2.6.30/linux-2.6.30.x86_64/net/wireless/wext.c:1057
if (!netif_device_present(dev))
return -ENODEV;
/* New driver API : try to find the handler */
handler = get_handler(dev, cmd);
if (handler) {
ffffffff81478230: 4d 85 c0 test %r8,%r8
ffffffff81478233: 74 18 je ffffffff8147824d <wext_ioctl_dispatch+0xfa>
/usr/src/debug/kernel-2.6.30/linux-2.6.30.x86_64/net/wireless/wext.c:1059
/* Standard and private are not the same */
if (cmd < SIOCIWFIRSTPRIV)
ffffffff81478235: 81 fa df 8b 00 00 cmp $0x8bdf,%edx
ffffffff8147823b: 77 08 ja ffffffff81478245 <wext_ioctl_dispatch+0xf2>
/usr/src/debug/kernel-2.6.30/linux-2.6.30.x86_64/net/wireless/wext.c:1060
return standard(dev, iwr, cmd, info, handler);
ffffffff8147823d: 48 89 de mov %rbx,%rsi
ffffffff81478240: 41 ff d4 callq *%r12
ffffffff81478243: eb 29 jmp ffffffff8147826e <wext_ioctl_dispatch+0x11b>
/usr/src/debug/kernel-2.6.30/linux-2.6.30.x86_64/net/wireless/wext.c:1062
else
return private(dev, iwr, cmd, info, handler);
ffffffff81478245: 48 89 de mov %rbx,%rsi
ffffffff81478248: 41 ff d6 callq *%r14
ffffffff8147824b: eb 21 jmp ffffffff8147826e <wext_ioctl_dispatch+0x11b>
/usr/src/debug/kernel-2.6.30/linux-2.6.30.x86_64/net/wireless/wext.c:1065
}
/* Old driver API : call driver ioctl handler */
if (dev->netdev_ops->ndo_do_ioctl)
ffffffff8147824d: 48 8b 87 48 01 00 00 mov 0x148(%rdi),%rax
ffffffff81478254: 48 8b 48 58 mov 0x58(%rax),%rcx
ffffffff81478258: b8 a1 ff ff ff mov $0xffffffa1,%eax
ffffffff8147825d: 48 85 c9 test %rcx,%rcx
ffffffff81478260: 74 0c je ffffffff8147826e <wext_ioctl_dispatch+0x11b>
/usr/src/debug/kernel-2.6.30/linux-2.6.30.x86_64/net/wireless/wext.c:1066
return dev->netdev_ops->ndo_do_ioctl(dev, ifr, cmd);
ffffffff81478262: 48 89 de mov %rbx,%rsi
ffffffff81478265: ff d1 callq *%rcx
ffffffff81478267: eb 05 jmp ffffffff8147826e <wext_ioctl_dispatch+0x11b>
ffffffff81478269: b8 ed ff ff ff mov $0xffffffed,%eax
wext_ioctl_dispatch():
/usr/src/debug/kernel-2.6.30/linux-2.6.30.x86_64/net/wireless/wext.c:1096
return ret;
dev_load(net, ifr->ifr_name);
rtnl_lock();
ret = wireless_process_ioctl(net, ifr, cmd, info, standard, private);
rtnl_unlock();
ffffffff8147826e: 89 45 c8 mov %eax,-0x38(%rbp)
ffffffff81478271: e8 91 58 f7 ff callq ffffffff813edb07 <rtnl_unlock>
ffffffff81478276: 8b 45 c8 mov -0x38(%rbp),%eax
/usr/src/debug/kernel-2.6.30/linux-2.6.30.x86_64/net/wireless/wext.c:1099
return ret;
}
ffffffff81478279: 48 8b 55 d8 mov -0x28(%rbp),%rdx
ffffffff8147827d: 65 48 33 14 25 28 00 xor %gs:0x28,%rdx
ffffffff81478284: 00 00
ffffffff81478286: 74 3e je ffffffff814782c6 <wext_ioctl_dispatch+0x173>
ffffffff81478288: eb 37 jmp ffffffff814782c1 <wext_ioctl_dispatch+0x16e>
/usr/src/debug/kernel-2.6.30/linux-2.6.30.x86_64/net/wireless/wext.c:1093
int ret = wext_permission_check(cmd);
if (ret)
return ret;
dev_load(net, ifr->ifr_name);
ffffffff8147828a: 48 89 de mov %rbx,%rsi
ffffffff8147828d: 4c 89 ef mov %r13,%rdi
ffffffff81478290: 89 55 c8 mov %edx,-0x38(%rbp)
ffffffff81478293: 48 89 4d c0 mov %rcx,-0x40(%rbp)
ffffffff81478297: e8 df c0 f6 ff callq ffffffff813e437b <dev_load>
/usr/src/debug/kernel-2.6.30/linux-2.6.30.x86_64/net/wireless/wext.c:1094
rtnl_lock();
ffffffff8147829c: e8 db 58 f7 ff callq ffffffff813edb7c <rtnl_lock>
wireless_process_ioctl():
/usr/src/debug/kernel-2.6.30/linux-2.6.30.x86_64/net/wireless/wext.c:1037
/* Permissions are already checked in dev_ioctl() before calling us.
* The copy_to/from_user() of ifr is also dealt with in there */
/* Make sure the device exist */
if ((dev = __dev_get_by_name(net, ifr->ifr_name)) == NULL)
ffffffff814782a1: 4c 89 ef mov %r13,%rdi
ffffffff814782a4: 48 89 de mov %rbx,%rsi
ffffffff814782a7: e8 44 83 f6 ff callq ffffffff813e05f0 <__dev_get_by_name>
ffffffff814782ac: 48 85 c0 test %rax,%rax
ffffffff814782af: 48 89 c7 mov %rax,%rdi
ffffffff814782b2: 8b 55 c8 mov -0x38(%rbp),%edx
ffffffff814782b5: 48 8b 4d c0 mov -0x40(%rbp),%rcx
ffffffff814782b9: 0f 85 06 ff ff ff jne ffffffff814781c5 <wext_ioctl_dispatch+0x72>
ffffffff814782bf: eb a8 jmp ffffffff81478269 <wext_ioctl_dispatch+0x116>
wext_ioctl_dispatch():
/usr/src/debug/kernel-2.6.30/linux-2.6.30.x86_64/net/wireless/wext.c:1099
rtnl_lock();
ret = wireless_process_ioctl(net, ifr, cmd, info, standard, private);
rtnl_unlock();
return ret;
}
ffffffff814782c1: e8 c3 ef bd ff callq ffffffff81057289 <__stack_chk_fail>
ffffffff814782c6: 48 83 c4 20 add $0x20,%rsp
ffffffff814782ca: 5b pop %rbx
ffffffff814782cb: 41 5c pop %r12
ffffffff814782cd: 41 5d pop %r13
ffffffff814782cf: 41 5e pop %r14
ffffffff814782d1: c9 leaveq
ffffffff814782d2: c3 retq
ffffffff814782d3 <compat_wext_handle_ioctl>:
compat_wext_handle_ioctl():
/usr/src/debug/kernel-2.6.30/linux-2.6.30.x86_64/net/wireless/wext.c:1188
return ret;
}
int compat_wext_handle_ioctl(struct net *net, unsigned int cmd,
unsigned long arg)
{
ffffffff814782d3: 55 push %rbp
ffffffff814782d4: 48 89 e5 mov %rsp,%rbp
ffffffff814782d7: 41 56 push %r14
ffffffff814782d9: 41 55 push %r13
ffffffff814782db: 41 54 push %r12
ffffffff814782dd: 53 push %rbx
ffffffff814782de: 48 83 ec 40 sub $0x40,%rsp
ffffffff814782e2: e8 19 9b b9 ff callq ffffffff81011e00 <mcount>
/usr/src/debug/kernel-2.6.30/linux-2.6.30.x86_64/net/wireless/wext.c:1195
struct iw_request_info info;
struct iwreq iwr;
char *colon;
int ret;
if (copy_from_user(&iwr, argp, sizeof(struct iwreq)))
ffffffff814782e7: 4c 8d 65 b0 lea -0x50(%rbp),%r12
/usr/src/debug/kernel-2.6.30/linux-2.6.30.x86_64/net/wireless/wext.c:1188
return ret;
}
int compat_wext_handle_ioctl(struct net *net, unsigned int cmd,
unsigned long arg)
{
ffffffff814782eb: 49 89 d5 mov %rdx,%r13
ffffffff814782ee: 49 89 fe mov %rdi,%r14
ffffffff814782f1: 89 f3 mov %esi,%ebx
/usr/src/debug/kernel-2.6.30/linux-2.6.30.x86_64/net/wireless/wext.c:1195
struct iw_request_info info;
struct iwreq iwr;
char *colon;
int ret;
if (copy_from_user(&iwr, argp, sizeof(struct iwreq)))
ffffffff814782f3: ba 20 00 00 00 mov $0x20,%edx
ffffffff814782f8: 4c 89 ee mov %r13,%rsi
ffffffff814782fb: 4c 89 e7 mov %r12,%rdi
/usr/src/debug/kernel-2.6.30/linux-2.6.30.x86_64/net/wireless/wext.c:1188
return ret;
}
int compat_wext_handle_ioctl(struct net *net, unsigned int cmd,
unsigned long arg)
{
ffffffff814782fe: 65 48 8b 04 25 28 00 mov %gs:0x28,%rax
ffffffff81478305: 00 00
ffffffff81478307: 48 89 45 d8 mov %rax,-0x28(%rbp)
ffffffff8147830b: 31 c0 xor %eax,%eax
/usr/src/debug/kernel-2.6.30/linux-2.6.30.x86_64/net/wireless/wext.c:1195
struct iw_request_info info;
struct iwreq iwr;
char *colon;
int ret;
if (copy_from_user(&iwr, argp, sizeof(struct iwreq)))
ffffffff8147830d: e8 3e 51 db ff callq ffffffff8122d450 <copy_from_user>
ffffffff81478312: 48 85 c0 test %rax,%rax
ffffffff81478315: 75 67 jne ffffffff8147837e <compat_wext_handle_ioctl+0xab>
/usr/src/debug/kernel-2.6.30/linux-2.6.30.x86_64/net/wireless/wext.c:1199
return -EFAULT;
iwr.ifr_name[IFNAMSIZ-1] = 0;
colon = strchr(iwr.ifr_name, ':');
ffffffff81478317: be 3a 00 00 00 mov $0x3a,%esi
ffffffff8147831c: 4c 89 e7 mov %r12,%rdi
/usr/src/debug/kernel-2.6.30/linux-2.6.30.x86_64/net/wireless/wext.c:1198
int ret;
if (copy_from_user(&iwr, argp, sizeof(struct iwreq)))
return -EFAULT;
iwr.ifr_name[IFNAMSIZ-1] = 0;
ffffffff8147831f: c6 45 bf 00 movb $0x0,-0x41(%rbp)
/usr/src/debug/kernel-2.6.30/linux-2.6.30.x86_64/net/wireless/wext.c:1199
colon = strchr(iwr.ifr_name, ':');
ffffffff81478323: e8 d1 25 db ff callq ffffffff8122a8f9 <strchr>
/usr/src/debug/kernel-2.6.30/linux-2.6.30.x86_64/net/wireless/wext.c:1200
if (colon)
ffffffff81478328: 48 85 c0 test %rax,%rax
ffffffff8147832b: 74 03 je ffffffff81478330 <compat_wext_handle_ioctl+0x5d>
/usr/src/debug/kernel-2.6.30/linux-2.6.30.x86_64/net/wireless/wext.c:1201
*colon = 0;
ffffffff8147832d: c6 00 00 movb $0x0,(%rax)
/usr/src/debug/kernel-2.6.30/linux-2.6.30.x86_64/net/wireless/wext.c:1206
info.cmd = cmd;
info.flags = IW_REQUEST_FLAG_COMPAT;
ret = wext_ioctl_dispatch(net, (struct ifreq *) &iwr, cmd, &info,
ffffffff81478330: 4c 8d 65 b0 lea -0x50(%rbp),%r12
ffffffff81478334: 48 8d 4d a0 lea -0x60(%rbp),%rcx
ffffffff81478338: 4c 89 f7 mov %r14,%rdi
ffffffff8147833b: 49 c7 c1 dc 7f 47 81 mov $0xffffffff81477fdc,%r9
ffffffff81478342: 49 c7 c0 df 8d 47 81 mov $0xffffffff81478ddf,%r8
ffffffff81478349: 89 da mov %ebx,%edx
ffffffff8147834b: 4c 89 e6 mov %r12,%rsi
/usr/src/debug/kernel-2.6.30/linux-2.6.30.x86_64/net/wireless/wext.c:1203
iwr.ifr_name[IFNAMSIZ-1] = 0;
colon = strchr(iwr.ifr_name, ':');
if (colon)
*colon = 0;
info.cmd = cmd;
ffffffff8147834e: 66 89 5d a0 mov %bx,-0x60(%rbp)
/usr/src/debug/kernel-2.6.30/linux-2.6.30.x86_64/net/wireless/wext.c:1204
info.flags = IW_REQUEST_FLAG_COMPAT;
ffffffff81478352: 66 c7 45 a2 01 00 movw $0x1,-0x5e(%rbp)
/usr/src/debug/kernel-2.6.30/linux-2.6.30.x86_64/net/wireless/wext.c:1206
ret = wext_ioctl_dispatch(net, (struct ifreq *) &iwr, cmd, &info,
ffffffff81478358: e8 f6 fd ff ff callq ffffffff81478153 <wext_ioctl_dispatch>
/usr/src/debug/kernel-2.6.30/linux-2.6.30.x86_64/net/wireless/wext.c:1210
compat_standard_call,
compat_private_call);
if (ret >= 0 &&
ffffffff8147835d: 85 c0 test %eax,%eax
/usr/src/debug/kernel-2.6.30/linux-2.6.30.x86_64/net/wireless/wext.c:1206
*colon = 0;
info.cmd = cmd;
info.flags = IW_REQUEST_FLAG_COMPAT;
ret = wext_ioctl_dispatch(net, (struct ifreq *) &iwr, cmd, &info,
ffffffff8147835f: 41 89 c6 mov %eax,%r14d
/usr/src/debug/kernel-2.6.30/linux-2.6.30.x86_64/net/wireless/wext.c:1210
compat_standard_call,
compat_private_call);
if (ret >= 0 &&
ffffffff81478362: 78 20 js ffffffff81478384 <compat_wext_handle_ioctl+0xb1>
ffffffff81478364: 80 e3 01 and $0x1,%bl
ffffffff81478367: 74 1b je ffffffff81478384 <compat_wext_handle_ioctl+0xb1>
/usr/src/debug/kernel-2.6.30/linux-2.6.30.x86_64/net/wireless/wext.c:1212
IW_IS_GET(cmd) &&
copy_to_user(argp, &iwr, sizeof(struct iwreq)))
ffffffff81478369: ba 20 00 00 00 mov $0x20,%edx
ffffffff8147836e: 4c 89 e6 mov %r12,%rsi
ffffffff81478371: 4c 89 ef mov %r13,%rdi
ffffffff81478374: e8 a7 50 db ff callq ffffffff8122d420 <copy_to_user>
/usr/src/debug/kernel-2.6.30/linux-2.6.30.x86_64/net/wireless/wext.c:1210
ret = wext_ioctl_dispatch(net, (struct ifreq *) &iwr, cmd, &info,
compat_standard_call,
compat_private_call);
if (ret >= 0 &&
ffffffff81478379: 48 85 c0 test %rax,%rax
ffffffff8147837c: 74 06 je ffffffff81478384 <compat_wext_handle_ioctl+0xb1>
ffffffff8147837e: 41 be f2 ff ff ff mov $0xfffffff2,%r14d
/usr/src/debug/kernel-2.6.30/linux-2.6.30.x86_64/net/wireless/wext.c:1216
IW_IS_GET(cmd) &&
copy_to_user(argp, &iwr, sizeof(struct iwreq)))
return -EFAULT;
return ret;
}
ffffffff81478384: 48 8b 55 d8 mov -0x28(%rbp),%rdx
ffffffff81478388: 65 48 33 14 25 28 00 xor %gs:0x28,%rdx
ffffffff8147838f: 00 00
ffffffff81478391: 44 89 f0 mov %r14d,%eax
ffffffff81478394: 74 05 je ffffffff8147839b <compat_wext_handle_ioctl+0xc8>
ffffffff81478396: e8 ee ee bd ff callq ffffffff81057289 <__stack_chk_fail>
ffffffff8147839b: 48 83 c4 40 add $0x40,%rsp
ffffffff8147839f: 5b pop %rbx
ffffffff814783a0: 41 5c pop %r12
ffffffff814783a2: 41 5d pop %r13
ffffffff814783a4: 41 5e pop %r14
ffffffff814783a6: c9 leaveq
ffffffff814783a7: c3 retq
ffffffff814783a8 <wext_handle_ioctl>:
wext_handle_ioctl():
/usr/src/debug/kernel-2.6.30/linux-2.6.30.x86_64/net/wireless/wext.c:1103
return ret;
}
int wext_handle_ioctl(struct net *net, struct ifreq *ifr, unsigned int cmd,
void __user *arg)
{
ffffffff814783a8: 55 push %rbp
ffffffff814783a9: 48 89 e5 mov %rsp,%rbp
ffffffff814783ac: 41 56 push %r14
ffffffff814783ae: 41 55 push %r13
ffffffff814783b0: 41 54 push %r12
ffffffff814783b2: 53 push %rbx
ffffffff814783b3: 48 83 ec 10 sub $0x10,%rsp
ffffffff814783b7: e8 44 9a b9 ff callq ffffffff81011e00 <mcount>
/usr/src/debug/kernel-2.6.30/linux-2.6.30.x86_64/net/wireless/wext.c:1107
struct iw_request_info info = { .cmd = cmd, .flags = 0 };
int ret;
ret = wext_ioctl_dispatch(net, ifr, cmd, &info,
ffffffff814783bc: 49 c7 c1 b4 80 47 81 mov $0xffffffff814780b4,%r9
ffffffff814783c3: 49 c7 c0 10 8d 47 81 mov $0xffffffff81478d10,%r8
/usr/src/debug/kernel-2.6.30/linux-2.6.30.x86_64/net/wireless/wext.c:1103
return ret;
}
int wext_handle_ioctl(struct net *net, struct ifreq *ifr, unsigned int cmd,
void __user *arg)
{
ffffffff814783ca: 49 89 cd mov %rcx,%r13
/usr/src/debug/kernel-2.6.30/linux-2.6.30.x86_64/net/wireless/wext.c:1107
struct iw_request_info info = { .cmd = cmd, .flags = 0 };
int ret;
ret = wext_ioctl_dispatch(net, ifr, cmd, &info,
ffffffff814783cd: 48 8d 4d d0 lea -0x30(%rbp),%rcx
/usr/src/debug/kernel-2.6.30/linux-2.6.30.x86_64/net/wireless/wext.c:1103
return ret;
}
int wext_handle_ioctl(struct net *net, struct ifreq *ifr, unsigned int cmd,
void __user *arg)
{
ffffffff814783d1: 48 89 f3 mov %rsi,%rbx
ffffffff814783d4: 65 48 8b 04 25 28 00 mov %gs:0x28,%rax
ffffffff814783db: 00 00
ffffffff814783dd: 48 89 45 d8 mov %rax,-0x28(%rbp)
ffffffff814783e1: 31 c0 xor %eax,%eax
ffffffff814783e3: 41 89 d4 mov %edx,%r12d
/usr/src/debug/kernel-2.6.30/linux-2.6.30.x86_64/net/wireless/wext.c:1104
struct iw_request_info info = { .cmd = cmd, .flags = 0 };
ffffffff814783e6: 66 89 55 d0 mov %dx,-0x30(%rbp)
ffffffff814783ea: 66 c7 45 d2 00 00 movw $0x0,-0x2e(%rbp)
/usr/src/debug/kernel-2.6.30/linux-2.6.30.x86_64/net/wireless/wext.c:1107
int ret;
ret = wext_ioctl_dispatch(net, ifr, cmd, &info,
ffffffff814783f0: e8 5e fd ff ff callq ffffffff81478153 <wext_ioctl_dispatch>
/usr/src/debug/kernel-2.6.30/linux-2.6.30.x86_64/net/wireless/wext.c:1110
ioctl_standard_call,
ioctl_private_call);
if (ret >= 0 &&
ffffffff814783f5: 85 c0 test %eax,%eax
/usr/src/debug/kernel-2.6.30/linux-2.6.30.x86_64/net/wireless/wext.c:1107
void __user *arg)
{
struct iw_request_info info = { .cmd = cmd, .flags = 0 };
int ret;
ret = wext_ioctl_dispatch(net, ifr, cmd, &info,
ffffffff814783f7: 41 89 c6 mov %eax,%r14d
/usr/src/debug/kernel-2.6.30/linux-2.6.30.x86_64/net/wireless/wext.c:1110
ioctl_standard_call,
ioctl_private_call);
if (ret >= 0 &&
ffffffff814783fa: 78 22 js ffffffff8147841e <wext_handle_ioctl+0x76>
ffffffff814783fc: 41 80 e4 01 and $0x1,%r12b
ffffffff81478400: 74 1c je ffffffff8147841e <wext_handle_ioctl+0x76>
/usr/src/debug/kernel-2.6.30/linux-2.6.30.x86_64/net/wireless/wext.c:1112
IW_IS_GET(cmd) &&
copy_to_user(arg, ifr, sizeof(struct iwreq)))
ffffffff81478402: ba 20 00 00 00 mov $0x20,%edx
ffffffff81478407: 48 89 de mov %rbx,%rsi
ffffffff8147840a: 4c 89 ef mov %r13,%rdi
ffffffff8147840d: e8 0e 50 db ff callq ffffffff8122d420 <copy_to_user>
/usr/src/debug/kernel-2.6.30/linux-2.6.30.x86_64/net/wireless/wext.c:1110
int ret;
ret = wext_ioctl_dispatch(net, ifr, cmd, &info,
ioctl_standard_call,
ioctl_private_call);
if (ret >= 0 &&
ffffffff81478412: 48 85 c0 test %rax,%rax
ffffffff81478415: b8 f2 ff ff ff mov $0xfffffff2,%eax
ffffffff8147841a: 44 0f 45 f0 cmovne %eax,%r14d
/usr/src/debug/kernel-2.6.30/linux-2.6.30.x86_64/net/wireless/wext.c:1116
IW_IS_GET(cmd) &&
copy_to_user(arg, ifr, sizeof(struct iwreq)))
return -EFAULT;
return ret;
}
ffffffff8147841e: 48 8b 55 d8 mov -0x28(%rbp),%rdx
ffffffff81478422: 65 48 33 14 25 28 00 xor %gs:0x28,%rdx
ffffffff81478429: 00 00
ffffffff8147842b: 44 89 f0 mov %r14d,%eax
ffffffff8147842e: 74 05 je ffffffff81478435 <wext_handle_ioctl+0x8d>
ffffffff81478430: e8 54 ee bd ff callq ffffffff81057289 <__stack_chk_fail>
ffffffff81478435: 5b pop %rbx
ffffffff81478436: 5e pop %rsi
ffffffff81478437: 5b pop %rbx
ffffffff81478438: 41 5c pop %r12
ffffffff8147843a: 41 5d pop %r13
ffffffff8147843c: 41 5e pop %r14
ffffffff8147843e: c9 leaveq
ffffffff8147843f: c3 retq
^ permalink raw reply
* Re: [PATCH] wireless: make WEXT_SPY and WEXT_PRIV select WEXT_CORE
From: Johannes Berg @ 2009-10-08 9:48 UTC (permalink / raw)
To: Randy Dunlap
Cc: John W. Linville, linux-wireless, Stephen Rothwell, linux-next,
linux-kernel
In-Reply-To: <20091007171235.d40f0cc2.randy.dunlap@oracle.com>
[-- Attachment #1: Type: text/plain, Size: 1323 bytes --]
On Wed, 2009-10-07 at 17:12 -0700, Randy Dunlap wrote:
> > > # CONFIG_WIRELESS is not set
> > > CONFIG_WIRELESS_EXT=y
> > > CONFIG_WEXT_SPY=y
> > > CONFIG_WEXT_PRIV=y
> > >
> > > WEXT_CORE is not enabled. I haven't found the culprit, but I suspect "select".
> >
> > Interesting.
> >
> > > but what in WIRELESS_EXT would also cause WEXT_CORE to be enabled?
> >
> > Well, the way WEXT_CORE is defined as def_bool y ought to, no?
>
> Ah, I see what you mean.
>
> Here's what's happening:
>
> net/wireless/Kconfig says:
>
> config WEXT_CORE
> def_bool y
> depends on CFG80211_WEXT || WIRELESS_EXT
>
>
> and net/Kconfig says:
>
> if WIRELESS
>
> source "net/wireless/Kconfig"
> source "net/mac80211/Kconfig"
>
> endif # WIRELESS
>
>
> so WEXT_CORE actually depends on NET && WIRELESS && (CFG80211_WEXT || WIRELESS_EXT)
> (that's what xconfig shows me).
> But WIRELESS is not enabled. Pooh.
>
> I was already toying with making CONFIG_WIRELESS a real/usable kconfig symbol.
> That may have to be done unless someone else comes up with another solution.
Ah!
It's kinda strange though that you can select wireless drivers without
selecting WIRELESS. Maybe the solution is as simple as making WLAN
(drivers/net/wireless/Kconfig) depend on WIRELESS?
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: NULL pointer deref at wext ioctl (Re: [PATCH] compat-2.6: adding ethtool.h to compat-2.6.31.h)
From: Johannes Berg @ 2009-10-08 9:51 UTC (permalink / raw)
To: Hin-Tak Leung; +Cc: Luis R. Rodriguez, John W. Linville, linux-wireless
In-Reply-To: <3ace41890910072328n1460ee34v1fe7ca9b78eb646f@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1104 bytes --]
On Thu, 2009-10-08 at 07:28 +0100, Hin-Tak Leung wrote:
> It looks like it is the 2nd of thes two lines around
> /usr/src/debug/kernel-2.6.30/linux-2.6.30.x86_64/net/wireless/wext.c:448
> which resulted in the null pointer dereference:
>
> if (index < dev->wireless_handlers->num_private)
> return dev->wireless_handlers->private[index];
Ok, that's odd. Is it possible that somehow cfg80211 is picking up an
#ifdef'ed copy of "struct iw_handler_def", and thus the struct it is
defining is simply too small? You can figure that out with debug info,
presumably, but I'm not entirely sure how. Actually maybe nm would tell
you too, if you look for cfg80211_wext_handler.
What I mean is this -- cfg80211 defines cfg80211_wext_handler:
const struct iw_handler_def cfg80211_wext_handler
.num_standard
.standard
.get_wireless_stats
but the core expects
.num_standard
.standard
.num_private
.num_private_args
.private
.private_args
.get_wireless_stats
as such .num_private ends up non-zero because it's shadowed
by .get_wireles_stats.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox