* WARNING at net/wireless/reg.c when wireless network is disconnected
From: Thomas Bächler @ 2010-08-04 11:36 UTC (permalink / raw)
To: linux-wireless; +Cc: linux-kernel, Johannes Berg, Luis R. Rodriguez
[-- Attachment #1: Type: text/plain, Size: 2288 bytes --]
Hello,
this warning has been around ever since I switched to 2.6.34, has
accompanied me through the 2.6.35-rc* phase and is still there with
2.6.35. I didn't bother to report it so far, as there seems to be no harm.
Whenever I disconnect/get disconnected from the wireless, I receive the
below warning:
------------[ cut here ]------------
WARNING: at net/wireless/reg.c:272
regulatory_hint_disconnect+0x1b3/0x230 [cfg80211]()
Hardware name: TECRA A11
Unexpected user alpha2: de
Modules linked in: hidp rfcomm sco bnep l2cap bridge stp llc microcode
cpufreq_ondemand tun btusb bluetooth uvcvideo videodev tpm_infineon
v4l2_compat_ioctl32 arc4 snd_seq_dummy snd_seq_oss ecb
snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss
snd_hda_codec_intelhdmi snd_mixer_oss snd_hda_codec_realtek
snd_hda_intel snd_hda_codec ath9k snd_hwdep kvm_intel ath9k_common kvm
snd_pcm ath9k_hw snd_timer snd tpm_tis ehci_hcd ath sdhci_pci
acpi_cpufreq sdhci soundcore mac80211 freq_table mmc_core tpm cfg80211
usbcore snd_page_alloc tpm_bios e1000e mperf led_class psmouse sr_mod
iTCO_wdt sg evdev toshiba_acpi toshiba_bluetooth cdrom battery ac
thermal processor rfkill nls_base rtc_cmos rtc_core rtc_lib fpu
aesni_intel cryptd aes_x86_64 aes_generic xts gf128mul dm_crypt dm_mod
sd_mod ahci libahci libata scsi_mod ext4 mbcache jbd2 crc16 i915
drm_kms_helper drm i2c_algo_bit cfbcopyarea video backlight output
cfbimgblt cfbfillrect intel_agp agpgart
Pid: 15, comm: events/0 Not tainted 2.6.35 #28
Call Trace:
[<ffffffff8103e98b>] ? warn_slowpath_common+0x7b/0xc0
[<ffffffffa0337760>] ? disconnect_work+0x0/0x30 [cfg80211]
[<ffffffff8103ea85>] ? warn_slowpath_fmt+0x45/0x50
[<ffffffffa0337760>] ? disconnect_work+0x0/0x30 [cfg80211]
[<ffffffffa0325163>] ? regulatory_hint_disconnect+0x1b3/0x230 [cfg80211]
[<ffffffffa0337760>] ? disconnect_work+0x0/0x30 [cfg80211]
[<ffffffff81052df8>] ? worker_thread+0x158/0x230
[<ffffffff810574d0>] ? autoremove_wake_function+0x0/0x30
[<ffffffff81052ca0>] ? worker_thread+0x0/0x230
[<ffffffff8105703e>] ? kthread+0x8e/0xa0
[<ffffffff810032d4>] ? kernel_thread_helper+0x4/0x10
[<ffffffff81056fb0>] ? kthread+0x0/0xa0
[<ffffffff810032d0>] ? kernel_thread_helper+0x0/0x10
---[ end trace cbb09501d5faaa20 ]---
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
^ permalink raw reply
* Re: [PATCH v2 03/20] mmc: support embedded data field in mmc_host
From: Russell King - ARM Linux @ 2010-08-04 11:41 UTC (permalink / raw)
To: Ohad Ben-Cohen
Cc: Vitaly Wool, Kalle Valo, Pandita Vikram, Nicolas Pitre,
Tony Lindgren, linux-wireless, Roger Quadros, linux-mmc,
San Mehat, Chikkature Rajashekar Madhusudhan, Luciano Coelho,
linux-omap, akpm, linux-arm-kernel
In-Reply-To: <AANLkTinu2S19r8fueM-jVkc35XL2G0Z16BddE92Ci9KB@mail.gmail.com>
On Wed, Aug 04, 2010 at 02:24:39PM +0300, Ohad Ben-Cohen wrote:
> Hi Vitaly,
>
> On Tue, Aug 3, 2010 at 5:17 PM, Vitaly Wool <vitalywool@gmail.com> wrote:
> > On Mon, Aug 2, 2010 at 11:35 PM, Ohad Ben-Cohen <ohad@wizery.com> wrote:
> >> I'm honestly trying to understand your concerns, but I'm afraid that
> >> just saying "it's a hack" is not too informative. Can you please
> >> explain what do you think is technically wrong with the proposed
> >> solution ? is it not general enough for other use cases ? will it
> >> break something ?
>
> > So if I'd like to set the *same* structure for the *same* WL1271
> > driver, provided that I'm working with the other platform, I'll need
> > to do the following:
> > - add the pointer to the board-specific header;
> > - add the structure to the board-specific C file and propagate its
> > pointer to the controller driver;
> > - add setting the pointer in the core structure into the controller driver.
> >
> > This is far from being intuitive. This means we need to hack,
> > generally speaking, all the MMC controller drivers to get it working
> > on all platforms. This is error prone.
>
> You make it sound really complex.
>
> Let's see what it means to add it to a totally different platform.
>
> As an example, let's take Google's ADP1 which is based on a different
> host controller (msm-sdcc), and add the required support (untested of
> course, just a quick sketch, patch is based on android's msm git):
What if some other driver gets attached and tries to use this
platform data? This whole idea sounds extremely silly, cumbersome,
error prone, and is inviting misuse by normal MMC sockets.
Why not arrange for a small piece of code to be built into the kernel
when this driver is selected as a module or built-in, which handles
the passing of platform data to the driver?
Something like:
wl12xx_platform_data.c:
#include <linux/module.h>
#include <whatever/required/for/wl12xx.h>
static struct wl12xx_platform_data *platform_data;
int __init wl12xx_set_platform_data(const struct wl12xx_platform_data *data)
{
if (platform_data)
return -EBUSY;
platform_data = kmemdup(data, sizeof(*data), GFP_KERNEL);
if (!platform_data)
return -ENOMEM;
return 0;
}
int wl12xx_get_platform_data(struct wl12xx_platform_data *data)
{
if (platform_data) {
memcpy(data, platform_data, sizeof(*data));
return 0;
}
return -ENODEV;
}
EXPORT_SYMBOL(wl12xx_get_platform_data);
And in the Kconfig, something like:
config WL12XX_PLATFORM_DATA
bool
depends on WL12XX != n
default y
This means there'll be no confusion over who owns the 'embedded data',
typechecking is preserved, and no possibility for the wrong driver to
pick up the data.
^ permalink raw reply
* Re: [PATCH v2 03/20] mmc: support embedded data field in mmc_host
From: Ohad Ben-Cohen @ 2010-08-04 12:42 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Vitaly Wool, Kalle Valo, Pandita Vikram, Nicolas Pitre,
Tony Lindgren, linux-wireless, Roger Quadros, linux-mmc,
San Mehat, Chikkature Rajashekar Madhusudhan, Luciano Coelho,
linux-omap, akpm, linux-arm-kernel
In-Reply-To: <20100804114147.GB6852@n2100.arm.linux.org.uk>
On Wed, Aug 4, 2010 at 2:41 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Wed, Aug 04, 2010 at 02:24:39PM +0300, Ohad Ben-Cohen wrote:
>> On Tue, Aug 3, 2010 at 5:17 PM, Vitaly Wool <vitalywool@gmail.com> wrote:
>> > On Mon, Aug 2, 2010 at 11:35 PM, Ohad Ben-Cohen <ohad@wizery.com> wrote:
>> >> I'm honestly trying to understand your concerns, but I'm afraid that
>> >> just saying "it's a hack" is not too informative. Can you please
>> >> explain what do you think is technically wrong with the proposed
>> >> solution ? is it not general enough for other use cases ? will it
>> >> break something ?
>>
>> > So if I'd like to set the *same* structure for the *same* WL1271
>> > driver, provided that I'm working with the other platform, I'll need
>> > to do the following:
>> > - add the pointer to the board-specific header;
>> > - add the structure to the board-specific C file and propagate its
>> > pointer to the controller driver;
>> > - add setting the pointer in the core structure into the controller driver.
>> >
>> > This is far from being intuitive. This means we need to hack,
>> > generally speaking, all the MMC controller drivers to get it working
>> > on all platforms. This is error prone.
>>
>> You make it sound really complex.
>>
>> Let's see what it means to add it to a totally different platform.
>>
>> As an example, let's take Google's ADP1 which is based on a different
>> host controller (msm-sdcc), and add the required support (untested of
>> course, just a quick sketch, patch is based on android's msm git):
>
> What if some other driver gets attached and tries to use this
> platform data? This whole idea sounds extremely silly, cumbersome,
> error prone, and is inviting misuse by normal MMC sockets.
>
> Why not arrange for a small piece of code to be built into the kernel
> when this driver is selected as a module or built-in, which handles
> the passing of platform data to the driver?
It's interesting.
The only drawback I can see is that it has an inherent limitation of
having only a single wl1271 device on board, but there are no such
boards outside development/testing labs.
Vitaly would that work for you too ?
Thanks,
Ohad.
>
> Something like:
>
> wl12xx_platform_data.c:
> #include <linux/module.h>
> #include <whatever/required/for/wl12xx.h>
>
> static struct wl12xx_platform_data *platform_data;
>
> int __init wl12xx_set_platform_data(const struct wl12xx_platform_data *data)
> {
> if (platform_data)
> return -EBUSY;
> platform_data = kmemdup(data, sizeof(*data), GFP_KERNEL);
> if (!platform_data)
> return -ENOMEM;
> return 0;
> }
>
> int wl12xx_get_platform_data(struct wl12xx_platform_data *data)
> {
> if (platform_data) {
> memcpy(data, platform_data, sizeof(*data));
> return 0;
> }
> return -ENODEV;
> }
> EXPORT_SYMBOL(wl12xx_get_platform_data);
>
> And in the Kconfig, something like:
>
> config WL12XX_PLATFORM_DATA
> bool
> depends on WL12XX != n
> default y
>
> This means there'll be no confusion over who owns the 'embedded data',
> typechecking is preserved, and no possibility for the wrong driver to
> pick up the data.
>
^ permalink raw reply
* Re: WARNING at net/wireless/reg.c when wireless network is disconnected
From: John W. Linville @ 2010-08-04 13:49 UTC (permalink / raw)
To: Thomas Bächler
Cc: linux-wireless, linux-kernel, Johannes Berg, Luis R. Rodriguez
In-Reply-To: <4C5950B7.4000802@archlinux.org>
On Wed, Aug 04, 2010 at 01:36:23PM +0200, Thomas Bächler wrote:
> Hello,
>
> this warning has been around ever since I switched to 2.6.34, has
> accompanied me through the 2.6.35-rc* phase and is still there with
> 2.6.35. I didn't bother to report it so far, as there seems to be no harm.
>
> Whenever I disconnect/get disconnected from the wireless, I receive the
> below warning:
>
> ------------[ cut here ]------------
> WARNING: at net/wireless/reg.c:272
> regulatory_hint_disconnect+0x1b3/0x230 [cfg80211]()
> Hardware name: TECRA A11
> Unexpected user alpha2: de
Perhaps you need to set the regdomain as "DE" rather than "de"?
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: [PATCH v2 03/20] mmc: support embedded data field in mmc_host
From: Vitaly Wool @ 2010-08-04 14:01 UTC (permalink / raw)
To: Ohad Ben-Cohen
Cc: Russell King - ARM Linux, Kalle Valo, Pandita Vikram,
Nicolas Pitre, Tony Lindgren, linux-wireless, Roger Quadros,
linux-mmc, San Mehat, Chikkature Rajashekar Madhusudhan,
Luciano Coelho, linux-omap, akpm, linux-arm-kernel
In-Reply-To: <AANLkTi=Dqs_qg=BsoNBTjvJbG+ub+zMv8ctbrJSGPJJJ@mail.gmail.com>
On Wed, Aug 4, 2010 at 2:42 PM, Ohad Ben-Cohen <ohad@wizery.com> wrote:
> On Wed, Aug 4, 2010 at 2:41 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
>> On Wed, Aug 04, 2010 at 02:24:39PM +0300, Ohad Ben-Cohen wrote:
>>> On Tue, Aug 3, 2010 at 5:17 PM, Vitaly Wool <vitalywool@gmail.com> wrote:
>>> > On Mon, Aug 2, 2010 at 11:35 PM, Ohad Ben-Cohen <ohad@wizery.com> wrote:
>>> >> I'm honestly trying to understand your concerns, but I'm afraid that
>>> >> just saying "it's a hack" is not too informative. Can you please
>>> >> explain what do you think is technically wrong with the proposed
>>> >> solution ? is it not general enough for other use cases ? will it
>>> >> break something ?
>>>
>>> > So if I'd like to set the *same* structure for the *same* WL1271
>>> > driver, provided that I'm working with the other platform, I'll need
>>> > to do the following:
>>> > - add the pointer to the board-specific header;
>>> > - add the structure to the board-specific C file and propagate its
>>> > pointer to the controller driver;
>>> > - add setting the pointer in the core structure into the controller driver.
>>> >
>>> > This is far from being intuitive. This means we need to hack,
>>> > generally speaking, all the MMC controller drivers to get it working
>>> > on all platforms. This is error prone.
>>>
>>> You make it sound really complex.
>>>
>>> Let's see what it means to add it to a totally different platform.
>>>
>>> As an example, let's take Google's ADP1 which is based on a different
>>> host controller (msm-sdcc), and add the required support (untested of
>>> course, just a quick sketch, patch is based on android's msm git):
>>
>> What if some other driver gets attached and tries to use this
>> platform data? This whole idea sounds extremely silly, cumbersome,
>> error prone, and is inviting misuse by normal MMC sockets.
>>
>> Why not arrange for a small piece of code to be built into the kernel
>> when this driver is selected as a module or built-in, which handles
>> the passing of platform data to the driver?
>
> It's interesting.
>
> The only drawback I can see is that it has an inherent limitation of
> having only a single wl1271 device on board, but there are no such
> boards outside development/testing labs.
>
> Vitaly would that work for you too ?
Works for me, but I've got a remark.
If we try to generalize that idea to handle multiple devices it will
be similar to the following:
static struct wl12xx_platform_data platform_data[MAX_WL12XX_DEVICES];
int __init wl12xx_set_platform_data(const struct wl12xx_platform_data
*data, int id);
int wl12xx_get_platform_data(struct wl12xx_platform_data *data, int id);
which will look pretty much like... yes, a simplified/customized
version board_info applied to a single driver.
But anyway I'm fine with that.
~Vitaly
^ permalink raw reply
* [PATCH] build fixes for compat-wireless due to PCMCIA changes
From: Kshitij Kulshreshtha @ 2010-08-04 14:18 UTC (permalink / raw)
To: Luis R. Rodriguez, Hauke Mehrtens; +Cc: linux-wireless
Hello,
here are two patches for compat and compat-wireless that fix build with
linux-next.git tag next-20100804 and kernel v2.6.34
The patch for compat-wireless is only
leftovers from Luis R. Rodriguez' commit dedb6981 in
drivers/net/wireless/orinoco/{orinoco,spectrum}_cs.c
The patch for compat backports the newly added pcmcia_{read,write}_config_byte()
functions in <pcmcia/ds.h>
Thanks and regards.
--
Kshitij Kulshreshtha
Institut für Mathematik,
Universität Paderborn,
Warburger Straße 100,
33098 Paderborn.
Büro: A3.319
^ permalink raw reply
* [PATCH] compat: backport pcmcia_{read,write}_config byte from v2.6.36
From: Kshitij Kulshreshtha @ 2010-08-04 14:18 UTC (permalink / raw)
To: Luis R. Rodriguez, Hauke Mehrtens; +Cc: linux-wireless, Kshitij Kulshreshtha
In-Reply-To: <1280931516-29665-1-git-send-email-kkhere.geo@gmail.com>
Signed-off-by: Kshitij Kulshreshtha <kkhere.geo@gmail.com>
---
include/pcmcia/ds.h | 36 ++++++++++++++++++++++++++++++++++++
1 files changed, 36 insertions(+), 0 deletions(-)
create mode 100644 include/pcmcia/ds.h
diff --git a/include/pcmcia/ds.h b/include/pcmcia/ds.h
new file mode 100644
index 0000000..fc43703
--- /dev/null
+++ b/include/pcmcia/ds.h
@@ -0,0 +1,36 @@
+#ifndef _COMPAT_PCMCIA_DS_H
+#define _COMPAT_PCMCIA_DS_H
+#include <linux/version.h>
+
+#include_next <pcmcia/ds.h>
+
+#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,36)
+/**
+ * pcmcia_read_config_byte() - read a byte from a card configuration register
+ *
+ * pcmcia_read_config_byte() reads a byte from a configuration register in
+ * attribute memory.
+ */
+static inline int pcmcia_read_config_byte(struct pcmcia_device *p_dev, off_t where, u8 *val)
+{
+ int ret;
+ conf_reg_t reg = { 0, CS_READ, where, 0 };
+ ret = pcmcia_access_configuration_register(p_dev, ®);
+ *val = reg.Value;
+ return ret;
+}
+
+/**
+ * pcmcia_write_config_byte() - write a byte to a card configuration register
+ *
+ * pcmcia_write_config_byte() writes a byte to a configuration register in
+ * attribute memory.
+ */
+static inline int pcmcia_write_config_byte(struct pcmcia_device *p_dev, off_t where, u8 val)
+{
+ conf_reg_t reg = { 0, CS_WRITE, where, val };
+ return pcmcia_access_configuration_register(p_dev, ®);
+}
+#endif /* LINUX_VERSION_CODE < KERNEL_VERSION(2,6,36) */
+
+#endif
--
1.7.1
^ permalink raw reply related
* [PATCH] compat-wireless: more PCMCIA backporting
From: Kshitij Kulshreshtha @ 2010-08-04 14:18 UTC (permalink / raw)
To: Luis R. Rodriguez, Hauke Mehrtens; +Cc: linux-wireless, Kshitij Kulshreshtha
In-Reply-To: <1280931516-29665-1-git-send-email-kkhere.geo@gmail.com>
to fix build, these changes are leftovers from commit
commit dedb69815e9608360249e62a794e3dea6a867ab8
Author: Luis R. Rodriguez <lrodriguez@atheros.com>
Date: Tue Aug 3 13:30:01 2010 -0700
compat-wireless: backport and fix new PCMCIA changes
Signed-off-by: Kshitij Kulshreshtha <kkhere.geo@gmail.com>
---
patches/24-pcmcia.patch | 131 +++++++++++++++++++++++++++++++++++++++++++++--
1 files changed, 126 insertions(+), 5 deletions(-)
diff --git a/patches/24-pcmcia.patch b/patches/24-pcmcia.patch
index 9fb0e77..b1d65bf 100644
--- a/patches/24-pcmcia.patch
+++ b/patches/24-pcmcia.patch
@@ -275,7 +275,56 @@
/* General socket configuration defaults can go here. In this
* client, we assume very little, and rely on the CIS for
* almost everything. In most clients, many details (i.e.,
-@@ -248,7 +258,11 @@ orinoco_cs_config(struct pcmcia_device *
+@@ -191,23 +201,48 @@ static int orinoco_cs_config_check(struc
+ p_dev->conf.Attributes |= CONF_ENABLE_IRQ;
+
+ /* IO window settings */
++#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,36)
+ p_dev->resource[0]->end = p_dev->resource[1]->end = 0;
++#else
++ p_dev->io.NumPorts1 = p_dev->io.NumPorts2 = 0;
++#endif
+ if ((cfg->io.nwin > 0) || (dflt->io.nwin > 0)) {
+ cistpl_io_t *io = (cfg->io.nwin) ? &cfg->io : &dflt->io;
++#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,36)
+ p_dev->io_lines = io->flags & CISTPL_IO_LINES_MASK;
+ p_dev->resource[0]->flags &= ~IO_DATA_PATH_WIDTH;
+ p_dev->resource[0]->flags |=
+ pcmcia_io_cfg_data_width(io->flags);
+ p_dev->resource[0]->start = io->win[0].base;
+ p_dev->resource[0]->end = io->win[0].len;
++#else
++ p_dev->io.Attributes1 = IO_DATA_PATH_WIDTH_AUTO;
++ if (!(io->flags & CISTPL_IO_8BIT))
++ p_dev->io.Attributes1 = IO_DATA_PATH_WIDTH_16;
++ if (!(io->flags & CISTPL_IO_16BIT))
++ p_dev->io.Attributes1 = IO_DATA_PATH_WIDTH_8;
++ p_dev->io.IOAddrLines = io->flags & CISTPL_IO_LINES_MASK;
++ p_dev->io.BasePort1 = io->win[0].base;
++ p_dev->io.NumPorts1 = io->win[0].len;
++#endif
+ if (io->nwin > 1) {
++#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,36)
+ p_dev->resource[1]->flags = p_dev->resource[0]->flags;
+ p_dev->resource[1]->start = io->win[1].base;
+ p_dev->resource[1]->end = io->win[1].len;
++#else
++ p_dev->io.Attributes2 = p_dev->io.Attributes1;
++ p_dev->io.BasePort2 = io->win[1].base;
++ p_dev->io.NumPorts2 = io->win[1].len;
++#endif
+ }
+
+ /* This reserves IO space but doesn't actually enable it */
++#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,36)
+ if (pcmcia_request_io(p_dev) != 0)
++#else
++ if (pcmcia_request_io(p_dev, &p_dev->io) != 0)
++#endif
+ goto next_entry;
+ }
+ return 0;
+@@ -248,15 +283,23 @@ orinoco_cs_config(struct pcmcia_device *
goto failed;
}
@@ -287,7 +336,19 @@
if (ret)
goto failed;
-@@ -278,8 +292,16 @@ orinoco_cs_config(struct pcmcia_device *
+ /* We initialize the hermes structure before completing PCMCIA
+ * configuration just in case the interrupt handler gets
+ * called. */
++#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,36)
+ mem = ioport_map(link->resource[0]->start,
+ resource_size(link->resource[0]));
++#else
++ mem = ioport_map(link->io.BasePort1, link->io.NumPorts1);
++#endif
+ if (!mem)
+ goto failed;
+
+@@ -278,8 +321,16 @@ orinoco_cs_config(struct pcmcia_device *
}
/* Register an interface with the stack */
@@ -319,7 +380,56 @@
/* General socket configuration defaults can go here. In this
* client, we assume very little, and rely on the CIS for
* almost everything. In most clients, many details (i.e.,
-@@ -310,7 +316,11 @@ spectrum_cs_config(struct pcmcia_device
+@@ -253,23 +259,48 @@ static int spectrum_cs_config_check(stru
+ p_dev->conf.Attributes |= CONF_ENABLE_IRQ;
+
+ /* IO window settings */
++#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,36)
+ p_dev->resource[0]->end = p_dev->resource[1]->end = 0;
++#else
++ p_dev->io.NumPorts1 = p_dev->io.NumPorts2 = 0;
++#endif
+ if ((cfg->io.nwin > 0) || (dflt->io.nwin > 0)) {
+ cistpl_io_t *io = (cfg->io.nwin) ? &cfg->io : &dflt->io;
++#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,36)
+ p_dev->io_lines = io->flags & CISTPL_IO_LINES_MASK;
+ p_dev->resource[0]->flags &= ~IO_DATA_PATH_WIDTH;
+ p_dev->resource[0]->flags |=
+ pcmcia_io_cfg_data_width(io->flags);
+ p_dev->resource[0]->start = io->win[0].base;
+ p_dev->resource[0]->end = io->win[0].len;
++#else
++ p_dev->io.Attributes1 = IO_DATA_PATH_WIDTH_AUTO;
++ if (!(io->flags & CISTPL_IO_8BIT))
++ p_dev->io.Attributes1 = IO_DATA_PATH_WIDTH_16;
++ if (!(io->flags & CISTPL_IO_16BIT))
++ p_dev->io.Attributes1 = IO_DATA_PATH_WIDTH_8;
++ p_dev->io.IOAddrLines = io->flags & CISTPL_IO_LINES_MASK;
++ p_dev->io.BasePort1 = io->win[0].base;
++ p_dev->io.NumPorts1 = io->win[0].len;
++#endif
+ if (io->nwin > 1) {
++#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,36)
+ p_dev->resource[1]->flags = p_dev->resource[0]->flags;
+ p_dev->resource[1]->start = io->win[1].base;
+ p_dev->resource[1]->end = io->win[1].len;
++#else
++ p_dev->io.Attributes2 = p_dev->io.Attributes1;
++ p_dev->io.BasePort2 = io->win[1].base;
++ p_dev->io.NumPorts2 = io->win[1].len;
++#endif
+ }
+
+ /* This reserves IO space but doesn't actually enable it */
++#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,36)
+ if (pcmcia_request_io(p_dev) != 0)
++#else
++ if (pcmcia_request_io(p_dev, &p_dev->io) != 0)
++#endif
+ goto next_entry;
+ }
+ return 0;
+@@ -310,15 +341,23 @@ spectrum_cs_config(struct pcmcia_device
goto failed;
}
@@ -331,7 +441,19 @@
if (ret)
goto failed;
-@@ -345,8 +355,17 @@ spectrum_cs_config(struct pcmcia_device
+ /* We initialize the hermes structure before completing PCMCIA
+ * configuration just in case the interrupt handler gets
+ * called. */
++#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,36)
+ mem = ioport_map(link->resource[0]->start,
+ resource_size(link->resource[0]));
++#else
++ mem = ioport_map(link->io.BasePort1, link->io.NumPorts1);
++#endif
+ if (!mem)
+ goto failed;
+
+@@ -345,8 +384,16 @@ spectrum_cs_config(struct pcmcia_device
}
/* Register an interface with the stack */
@@ -343,7 +465,6 @@
+ link->irq, NULL) != 0) {
+#else
+ if (orinoco_if_add(priv, link->io.BasePort1,
-+ link->irq, NULL) != 0) {
+ link->irq.AssignedIRQ, NULL) != 0) {
+#endif
printk(KERN_ERR PFX "orinoco_if_add() failed\n");
--
1.7.1
^ permalink raw reply related
* Re: WARNING at net/wireless/reg.c when wireless network is disconnected
From: Thomas Bächler @ 2010-08-04 14:28 UTC (permalink / raw)
To: John W. Linville
Cc: linux-wireless, linux-kernel, Johannes Berg, Luis R. Rodriguez
In-Reply-To: <20100804134908.GB17666@tuxdriver.com>
[-- Attachment #1: Type: text/plain, Size: 1873 bytes --]
Am 04.08.2010 15:49, schrieb John W. Linville:
> On Wed, Aug 04, 2010 at 01:36:23PM +0200, Thomas Bächler wrote:
>> Hello,
>>
>> this warning has been around ever since I switched to 2.6.34, has
>> accompanied me through the 2.6.35-rc* phase and is still there with
>> 2.6.35. I didn't bother to report it so far, as there seems to be no harm.
>>
>> Whenever I disconnect/get disconnected from the wireless, I receive the
>> below warning:
>>
>> ------------[ cut here ]------------
>> WARNING: at net/wireless/reg.c:272
>> regulatory_hint_disconnect+0x1b3/0x230 [cfg80211]()
>> Hardware name: TECRA A11
>> Unexpected user alpha2: de
>
> Perhaps you need to set the regdomain as "DE" rather than "de"?
>
> John
You are actually right. I did set it to "DE" with iw, but wpa_supplicant
had a setting country="de". I just fixed that and will soon see if the
problem disappears.
Still, the warning shouldn't look like a bad kernel bug, but rather an
advisory to the user to set something sane. What confuses me even more
is that this has been set to DE afterwards:
$ dmesg | grep cfg80211:\ Calling\ CRDA
cfg80211: Calling CRDA to update world regulatory domain
cfg80211: Calling CRDA for country: de
cfg80211: Calling CRDA for country: DE
cfg80211: Calling CRDA to update world regulatory domain
cfg80211: Calling CRDA for country: DE
cfg80211: Calling CRDA to update world regulatory domain
cfg80211: Calling CRDA for country: DE
cfg80211: Calling CRDA to update world regulatory domain
cfg80211: Calling CRDA for country: DE
cfg80211: Calling CRDA to update world regulatory domain
cfg80211: Calling CRDA for country: DE
cfg80211: Calling CRDA to update world regulatory domain
cfg80211: Calling CRDA for country: DE
The AP has been playing with the regdom as well, I lost track of what
has been set where in this mess.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
^ permalink raw reply
* Re: iwlwifi connection problems
From: Alex Romosan @ 2010-08-04 14:51 UTC (permalink / raw)
To: Johannes Berg; +Cc: Guy, Wey-Yi, linux-wireless@vger.kernel.org
In-Reply-To: <1280908365.3768.4.camel@jlt3.sipsolutions.net>
Johannes Berg <johannes@sipsolutions.net> writes:
> Could you rebuild your kernel with CONFIG_MAC80211_DRIVER_API_TRACER
> and CONFIG_IWLWIFI_DEVICE_TRACING, get trace-cmd from
> git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/trace-cmd.git
> and record traces for me? I'd like to have
> trace-cmd record -e iwlwifi -e mac80211
> for both the working and non-working case, preferably the same kernel
> with that single line of code changed. Please compress the output.
you can get both traces from
http://caliban.lbl.gov/iwlwifi/
for the not-working case i also tried to bring down the interface and
then bring it up again while recording the trace (don't know if it
matters).
the kernels are the same except with line 1327 of iwl-core.c commented
out for the working case. hope this helps.
--alex--
--
| I believe the moment is at hand when, by a paranoiac and active |
| advance of the mind, it will be possible (simultaneously with |
| automatism and other passive states) to systematize confusion |
| and thus to help to discredit completely the world of reality. |
^ permalink raw reply
* Re: WARNING at net/wireless/reg.c when wireless network is disconnected
From: John W. Linville @ 2010-08-04 14:52 UTC (permalink / raw)
To: Thomas Bächler
Cc: linux-wireless, linux-kernel, Johannes Berg, Luis R. Rodriguez
In-Reply-To: <4C59790C.4010809@archlinux.org>
On Wed, Aug 04, 2010 at 04:28:28PM +0200, Thomas Bächler wrote:
> Am 04.08.2010 15:49, schrieb John W. Linville:
> > On Wed, Aug 04, 2010 at 01:36:23PM +0200, Thomas Bächler wrote:
> >> Hello,
> >>
> >> this warning has been around ever since I switched to 2.6.34, has
> >> accompanied me through the 2.6.35-rc* phase and is still there with
> >> 2.6.35. I didn't bother to report it so far, as there seems to be no harm.
> >>
> >> Whenever I disconnect/get disconnected from the wireless, I receive the
> >> below warning:
> >>
> >> ------------[ cut here ]------------
> >> WARNING: at net/wireless/reg.c:272
> >> regulatory_hint_disconnect+0x1b3/0x230 [cfg80211]()
> >> Hardware name: TECRA A11
> >> Unexpected user alpha2: de
> >
> > Perhaps you need to set the regdomain as "DE" rather than "de"?
> >
> > John
>
> You are actually right. I did set it to "DE" with iw, but wpa_supplicant
> had a setting country="de". I just fixed that and will soon see if the
> problem disappears.
>
> Still, the warning shouldn't look like a bad kernel bug, but rather an
> advisory to the user to set something sane. What confuses me even more
> is that this has been set to DE afterwards:
Perhaps we should just upcase the alpha2 value? I'm not sure why we don't.
> $ dmesg | grep cfg80211:\ Calling\ CRDA
> cfg80211: Calling CRDA to update world regulatory domain
> cfg80211: Calling CRDA for country: de
> cfg80211: Calling CRDA for country: DE
> cfg80211: Calling CRDA to update world regulatory domain
> cfg80211: Calling CRDA for country: DE
> cfg80211: Calling CRDA to update world regulatory domain
> cfg80211: Calling CRDA for country: DE
> cfg80211: Calling CRDA to update world regulatory domain
> cfg80211: Calling CRDA for country: DE
> cfg80211: Calling CRDA to update world regulatory domain
> cfg80211: Calling CRDA for country: DE
> cfg80211: Calling CRDA to update world regulatory domain
> cfg80211: Calling CRDA for country: DE
>
> The AP has been playing with the regdom as well, I lost track of what
> has been set where in this mess.
The AP is probably sending a country IE that indicates "DE".
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: iwlwifi connection problems
From: Johannes Berg @ 2010-08-04 15:03 UTC (permalink / raw)
To: Alex Romosan; +Cc: Guy, Wey-Yi, linux-wireless@vger.kernel.org
In-Reply-To: <87aap28m8v.fsf@sycorax.lbl.gov>
On Wed, 2010-08-04 at 07:51 -0700, Alex Romosan wrote:
> Johannes Berg <johannes@sipsolutions.net> writes:
>
> > Could you rebuild your kernel with CONFIG_MAC80211_DRIVER_API_TRACER
> > and CONFIG_IWLWIFI_DEVICE_TRACING, get trace-cmd from
> > git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/trace-cmd.git
> > and record traces for me? I'd like to have
> > trace-cmd record -e iwlwifi -e mac80211
> > for both the working and non-working case, preferably the same kernel
> > with that single line of code changed. Please compress the output.
>
> you can get both traces from
>
> http://caliban.lbl.gov/iwlwifi/
>
> for the not-working case i also tried to bring down the interface and
> then bring it up again while recording the trace (don't know if it
> matters).
Thanks. The down/up is fine, I'll be able to identify that in the
traces. Except the "working" trace looks like it only starts after you
connected already?
johannes
^ permalink raw reply
* Re: iwlwifi connection problems
From: Alex Romosan @ 2010-08-04 15:08 UTC (permalink / raw)
To: Johannes Berg; +Cc: Guy, Wey-Yi, linux-wireless@vger.kernel.org
In-Reply-To: <1280934185.3768.8.camel@jlt3.sipsolutions.net>
Johannes Berg <johannes@sipsolutions.net> writes:
> On Wed, 2010-08-04 at 07:51 -0700, Alex Romosan wrote:
>> Johannes Berg <johannes@sipsolutions.net> writes:
>>
>> > Could you rebuild your kernel with CONFIG_MAC80211_DRIVER_API_TRACER
>> > and CONFIG_IWLWIFI_DEVICE_TRACING, get trace-cmd from
>> > git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/trace-cmd.git
>> > and record traces for me? I'd like to have
>> > trace-cmd record -e iwlwifi -e mac80211
>> > for both the working and non-working case, preferably the same kernel
>> > with that single line of code changed. Please compress the output.
>>
>> you can get both traces from
>>
>> http://caliban.lbl.gov/iwlwifi/
>>
>> for the not-working case i also tried to bring down the interface and
>> then bring it up again while recording the trace (don't know if it
>> matters).
>
> Thanks. The down/up is fine, I'll be able to identify that in the
> traces. Except the "working" trace looks like it only starts after you
> connected already?
the driver connects automatically on boot, so, yes, it was after i was
connected. i can bring down the interface and try again if you want.
--alex--
--
| I believe the moment is at hand when, by a paranoiac and active |
| advance of the mind, it will be possible (simultaneously with |
| automatism and other passive states) to systematize confusion |
| and thus to help to discredit completely the world of reality. |
^ permalink raw reply
* Re: iwlwifi connection problems
From: Johannes Berg @ 2010-08-04 15:11 UTC (permalink / raw)
To: Alex Romosan; +Cc: Guy, Wey-Yi, linux-wireless@vger.kernel.org
In-Reply-To: <8739uu8lg2.fsf@sycorax.lbl.gov>
On Wed, 2010-08-04 at 08:08 -0700, Alex Romosan wrote:
> > Thanks. The down/up is fine, I'll be able to identify that in the
> > traces. Except the "working" trace looks like it only starts after you
> > connected already?
>
> the driver connects automatically on boot, so, yes, it was after i was
> connected. i can bring down the interface and try again if you want.
Yes, please do that.
johannes
^ permalink raw reply
* Re: iwlwifi connection problems
From: Alex Romosan @ 2010-08-04 15:12 UTC (permalink / raw)
To: Johannes Berg; +Cc: Guy, Wey-Yi, linux-wireless@vger.kernel.org
In-Reply-To: <1280934689.17718.3.camel@jlt3.sipsolutions.net>
Johannes Berg <johannes@sipsolutions.net> writes:
> On Wed, 2010-08-04 at 08:08 -0700, Alex Romosan wrote:
>
>> > Thanks. The down/up is fine, I'll be able to identify that in the
>> > traces. Except the "working" trace looks like it only starts after you
>> > connected already?
>>
>> the driver connects automatically on boot, so, yes, it was after i was
>> connected. i can bring down the interface and try again if you want.
>
> Yes, please do that.
http://caliban.lbl.gov/iwlwifi/trace.dat-working.before.ifup.gz
--alex--
--
| I believe the moment is at hand when, by a paranoiac and active |
| advance of the mind, it will be possible (simultaneously with |
| automatism and other passive states) to systematize confusion |
| and thus to help to discredit completely the world of reality. |
^ permalink raw reply
* Re: iwlwifi connection problems
From: Johannes Berg @ 2010-08-04 15:23 UTC (permalink / raw)
To: Alex Romosan; +Cc: Guy, Wey-Yi, linux-wireless@vger.kernel.org
In-Reply-To: <8762zq76p3.fsf@sycorax.lbl.gov>
On Wed, 2010-08-04 at 08:12 -0700, Alex Romosan wrote:
> Johannes Berg <johannes@sipsolutions.net> writes:
>
> > On Wed, 2010-08-04 at 08:08 -0700, Alex Romosan wrote:
> >
> >> > Thanks. The down/up is fine, I'll be able to identify that in the
> >> > traces. Except the "working" trace looks like it only starts after you
> >> > connected already?
> >>
> >> the driver connects automatically on boot, so, yes, it was after i was
> >> connected. i can bring down the interface and try again if you want.
> >
> > Yes, please do that.
>
> http://caliban.lbl.gov/iwlwifi/trace.dat-working.before.ifup.gz
Thank you. I need to adjust my analysis tools because you're using 3945,
not sure if I can finish that today.
johannes
^ permalink raw reply
* [PATCH block#for-2.6.36] block_dev: always serialize exclusive open attempts
From: Tejun Heo @ 2010-08-04 15:40 UTC (permalink / raw)
To: Jens Axboe
Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Maciej Rutecki,
Andrew Morton, Kernel Testers List, Network Development,
Linux ACPI, Linux PM List, Linux SCSI List, Linux Wireless List,
DRI, Linus Torvalds, stable, Maciej Rutecki
In-Reply-To: <4C56F30D.3020304@kernel.org>
bd_prepare_to_claim() incorrectly allowed multiple attempts for
exclusive open to progress in parallel if the attempting holders are
identical. This triggered BUG_ON() as reported in the following bug.
https://bugzilla.kernel.org/show_bug.cgi?id=16393
__bd_abort_claiming() is used to finish claiming blocks and doesn't
work if multiple openers are inside a claiming block. Allowing
multiple parallel open attempts to continue doesn't gain anything as
those are serialized down in the call chain anyway. Fix it by always
allowing only single open attempt in a claiming block.
This problem can easily be reproduced by adding a delay after
bd_prepare_to_claim() and attempting to mount two partitions of a
disk.
stable: only applicable to v2.6.35
Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: Maciej Rutecki <maciej.rutecki@gmail.com>
Cc: stable@kernel.org
---
fs/block_dev.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/block_dev.c b/fs/block_dev.c
index 99d6af8..b3171fb 100644
--- a/fs/block_dev.c
+++ b/fs/block_dev.c
@@ -681,8 +681,8 @@ retry:
if (!bd_may_claim(bdev, whole, holder))
return -EBUSY;
- /* if someone else is claiming, wait for it to finish */
- if (whole->bd_claiming && whole->bd_claiming != holder) {
+ /* if claiming is already in progress, wait for it to finish */
+ if (whole->bd_claiming) {
wait_queue_head_t *wq = bit_waitqueue(&whole->bd_claiming, 0);
DEFINE_WAIT(wait);
^ permalink raw reply related
* Re: [PATCH 2.6.35] iwlagn: Improve aggregation failure error messages
From: Andrew Lutomirski @ 2010-08-04 15:54 UTC (permalink / raw)
To: Wey-Yi Guy, ilw, linux-wireless, linville; +Cc: Andy Lutomirski
In-Reply-To: <4f999350050decc0901e6f23ae3f06d35bc3fbc0.1280077759.git.luto@mit.edu>
On Sun, Jul 25, 2010 at 1:14 PM, Andy Lutomirski <luto@mit.edu> wrote:
> 82ca9341763107615a15da6e59b9535d49eb91c3 added scary looking
> but harmless error messages. Make them clearer and make the
> actual failure message show up with the same severity as the
> harmless one.
>
> Signed-off-by: Andy Lutomirski <luto@mit.edu>
> ---
>
> This is probably 2.6.35 material. There is no functional regression
> here, but 2.6.34 worked pretty well and 2.6.35 *looks* like it's not
> working if you read the logs.
>
> There is no functional change in this patch.
Well, 2.6.35 has come and gone. Want to take it for 2.6.36 (it was
submitted in time AFAICT)?
--Andy
>
> Thanks,
> Andy
>
> drivers/net/wireless/iwlwifi/iwl-agn-rs.c | 11 +++++++----
> 1 files changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/wireless/iwlwifi/iwl-agn-rs.c b/drivers/net/wireless/iwlwifi/iwl-agn-rs.c
> index cf4a95b..f38ee24 100644
> --- a/drivers/net/wireless/iwlwifi/iwl-agn-rs.c
> +++ b/drivers/net/wireless/iwlwifi/iwl-agn-rs.c
> @@ -300,8 +300,9 @@ static int rs_tl_turn_on_agg_for_tid(struct iwl_priv *priv,
> struct ieee80211_sta *sta)
> {
> int ret = -EAGAIN;
> + u32 load = rs_tl_get_load(lq_data, tid);
>
> - if (rs_tl_get_load(lq_data, tid) > IWL_AGG_LOAD_THRESHOLD) {
> + if (load > IWL_AGG_LOAD_THRESHOLD) {
> IWL_DEBUG_HT(priv, "Starting Tx agg: STA: %pM tid: %d\n",
> sta->addr, tid);
> ret = ieee80211_start_tx_ba_session(sta, tid);
> @@ -311,13 +312,15 @@ static int rs_tl_turn_on_agg_for_tid(struct iwl_priv *priv,
> * this might be cause by reloading firmware
> * stop the tx ba session here
> */
> - IWL_DEBUG_HT(priv, "Fail start Tx agg on tid: %d\n",
> + IWL_ERR(priv, "Fail start Tx agg on tid: %d\n",
> tid);
> ieee80211_stop_tx_ba_session(sta, tid,
> WLAN_BACK_INITIATOR);
> }
> - } else
> - IWL_ERR(priv, "Fail finding valid aggregation tid: %d\n", tid);
> + } else {
> + IWL_ERR(priv, "Aggregation not enabled for tid %d "
> + "because load = %u\n", tid, load);
> + }
> return ret;
> }
>
> --
> 1.7.1.1
>
>
^ permalink raw reply
* [PATCH RESEND block#for-2.6.36] block_dev: always serialize exclusive open attempts
From: Tejun Heo @ 2010-08-04 15:59 UTC (permalink / raw)
To: Jens Axboe
Cc: Rafael J. Wysocki, Linux Kernel Mailing List, Maciej Rutecki,
Andrew Morton, Kernel Testers List, Network Development,
Linux ACPI, Linux PM List, Linux SCSI List, Linux Wireless List,
DRI, Linus Torvalds, stable, Maciej Rutecki
In-Reply-To: <4C56F30D.3020304@kernel.org>
bd_prepare_to_claim() incorrectly allowed multiple attempts for
exclusive open to progress in parallel if the attempting holders are
identical. This triggered BUG_ON() as reported in the following bug.
https://bugzilla.kernel.org/show_bug.cgi?id=16393
__bd_abort_claiming() is used to finish claiming blocks and doesn't
work if multiple openers are inside a claiming block. Allowing
multiple parallel open attempts to continue doesn't gain anything as
those are serialized down in the call chain anyway. Fix it by always
allowing only single open attempt in a claiming block.
This problem can easily be reproduced by adding a delay after
bd_prepare_to_claim() and attempting to mount two partitions of a
disk.
stable: only applicable to v2.6.35
Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: Markus Trippelsdorf <markus@trippelsdorf.de>
Cc: stable@kernel.org
---
Oops, had the wrong reported-by credit. Updated.
Thanks.
fs/block_dev.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/block_dev.c b/fs/block_dev.c
index 99d6af8..b3171fb 100644
--- a/fs/block_dev.c
+++ b/fs/block_dev.c
@@ -681,8 +681,8 @@ retry:
if (!bd_may_claim(bdev, whole, holder))
return -EBUSY;
- /* if someone else is claiming, wait for it to finish */
- if (whole->bd_claiming && whole->bd_claiming != holder) {
+ /* if claiming is already in progress, wait for it to finish */
+ if (whole->bd_claiming) {
wait_queue_head_t *wq = bit_waitqueue(&whole->bd_claiming, 0);
DEFINE_WAIT(wait);
^ permalink raw reply related
* Re: [PATCH 2.6.35] iwlagn: Improve aggregation failure error messages
From: Guy, Wey-Yi @ 2010-08-04 16:05 UTC (permalink / raw)
To: Andrew Lutomirski
Cc: ilw@linux.intel.com, linux-wireless@vger.kernel.org,
linville@tuxdriver.com
In-Reply-To: <AANLkTik=s32LV5ZUpU5EUBCV6zKsuU5SHM+UD0iS1oyW@mail.gmail.com>
Hi Andy,
On Wed, 2010-08-04 at 08:54 -0700, Andrew Lutomirski wrote:
> On Sun, Jul 25, 2010 at 1:14 PM, Andy Lutomirski <luto@mit.edu> wrote:
> > 82ca9341763107615a15da6e59b9535d49eb91c3 added scary looking
> > but harmless error messages. Make them clearer and make the
> > actual failure message show up with the same severity as the
> > harmless one.
> >
> > Signed-off-by: Andy Lutomirski <luto@mit.edu>
> > ---
> >
> > This is probably 2.6.35 material. There is no functional regression
> > here, but 2.6.34 worked pretty well and 2.6.35 *looks* like it's not
> > working if you read the logs.
> >
> > There is no functional change in this patch.
>
> Well, 2.6.35 has come and gone. Want to take it for 2.6.36 (it was
> submitted in time AFAICT)?
>
Looks good to me.
Thanks
Wey
^ permalink raw reply
* Re: [BUG] after starting wimaxd at boot iwlagn module will crash for intel 6250 card
From: Inaky Perez-Gonzalez @ 2010-08-04 16:36 UTC (permalink / raw)
To: Alexey Shvetsov; +Cc: linux-wireless@vger.kernel.org, wimax@linuxwimax.org
In-Reply-To: <AANLkTimDoQmuJcsuXVPEWDSS-odw5Zt=kqdUiheuPEjH@mail.gmail.com>
On Fri, 2010-07-30 at 18:48 +0400, Alexey Shvetsov wrote:
> Update with debug info on this bug
> Log attached
This is now being tracked in bug #13.
Thank you!
^ permalink raw reply
* Re: wl1251 issues
From: Kalle Valo @ 2010-08-04 18:33 UTC (permalink / raw)
To: Denis 'GNUtoo' Carikli; +Cc: linux-wireless
In-Reply-To: <1280682326.3868.37.camel@gnutoo-laptop>
Denis 'GNUtoo' Carikli <GNUtoo@no-log.org> writes:
> Hi,
Hi Denis,
> Here's the issue(this first issue doesn't involve PSM yet):
> I connect trough wpa to the local access point at the wifi cafee(wrt54
> somrthing,running an old openwrt with a 2.4 kernel and the proprietary
> broadcom module)
>
> I use dhcp to get an ip
> The connection last for a while and then I've that:
> wlan0 IEEE 802.11bg ESSID:"essid_has_been_hidden_in_that_mail"
> Mode:Managed Frequency:2.432 GHz Access Point:
> 00:23:69:XX:XX:XX
> Bit Rate=1 Mb/s Tx-Power=20 dBm
> Retry long limit:7 RTS thr:off Fragment thr:off
> Encryption key:off
> Power Management:off
> Link Quality=43/70 Signal level=-67 dBm
> Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
> Tx excessive retries:0 Invalid misc:0 Missed beacon:0
> That seem connected.
>
> root@htcdream ~ # ping 192.168.2.1
> PING 192.168.2.1 (192.168.2.1): 56 data bytes
> ^C
> --- 192.168.2.1 ping statistics ---
> 22 packets transmitted, 0 packets received, 100% packet loss
So basically what happens is that you associate but no data is
transfered? Did you confirm that the dhcp client really gets the ip
address?
> here's the wpa connection script output:
> ot@htcdream ~ # sh wpa.sh
> CTRL-EVENT-SCAN-RESULTS
> Trying to associate with 00:23:69:xx:xx:xx
> (SSID='essid_has_been_hidden_in_that_mail' freq=2432 MHz)
> Associated with 00:23:69:xx:xx:xx
> WPA: Key negotiation completed with 00:23:69:xx:xx:xx [PTK=CCMP
> GTK=CCMP]
> CTRL-EVENT-CONNECTED - Connection to 00:23:69:xx:xx:xx completed (auth)
> [id=0 id_str=]
>
> the essid and mac address have been changed.
>
> a while true;do dmesg -c;done gave a still flowing flow of messages:
> here's a part of it:
I didn't immeadiately notice anything wrong from the logs. I would
like to know if the problem is related to power save mode or
encryption. Can you first test without encryption, ie. connect to an
open network and see if you still see the problem. If you still see
the problem, disable power save and connect to the same open AP again.
--
Kalle Valo
^ permalink raw reply
* Compat-wireless release for 2010-08-04 is baked
From: Compat-wireless cronjob account @ 2010-08-04 19:03 UTC (permalink / raw)
To: linux-wireless
>From git://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/compat-wireless-2.6
b3703a3..4b6128d master -> origin/master
c7ecb8a..55764c1 wl -> origin/wl
* [new tag] compat-wireless-2010-08-03 -> compat-wireless-2010-08-03
* [new tag] compat-wireless-master-2010-08-03 -> compat-wireless-master-2010-08-03
>From git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next
e67e41a..d9285f7 history -> origin/history
+ a74255d...262e79e master -> origin/master (forced update)
9fe6206..3a09b1b stable -> origin/stable
* [new tag] next-20100804 -> next-20100804
cat: /var/opt/compat/compat-wireless-2.6/compat_version: No such file or directory
cat: compat_base_tree: No such file or directory
cat: compat_base_tree_version: No such file or directory
cat: compat_version: No such file or directory
cat: /var/opt/compat/compat-wireless-2.6/compat_version: No such file or directory
scripts/Makefile.clean:17: /var/opt/compat/compat-wireless-2.6/drivers/net/wireless/hostap/Makefile: No such file or directory
make[4]: *** No rule to make target `/var/opt/compat/compat-wireless-2.6/drivers/net/wireless/hostap/Makefile'. Stop.
make[3]: *** [/var/opt/compat/compat-wireless-2.6/drivers/net/wireless/hostap] Error 2
make[2]: *** [/var/opt/compat/compat-wireless-2.6/drivers/net/wireless] Error 2
make[1]: *** [_clean_/var/opt/compat/compat-wireless-2.6] Error 2
make: *** [clean] Error 2
compat-wireless code metrics
494063 - Total upstream lines of code being pulled
1475 - backport code changes
1239 - backport code additions
236 - backport code deletions
5805 - backport from compat module
7280 - total backport code
1.4735 - % of code consists of backport work
1218 - Crap changes not yet posted
1179 - Crap additions not yet posted
39 - Crap deletions not yet posted
0.2465 - % of crap code
Base tree: linux-next.git
Base tree version: next-20100804
compat-wireless release: compat-wireless-2010-08-03
^ permalink raw reply
* Re: [wt PATCH 0/5] libertas: make association work again
From: Dan Williams @ 2010-08-04 19:15 UTC (permalink / raw)
To: Johannes Berg; +Cc: John W. Linville, linux-wireless
In-Reply-To: <1280907989.3768.0.camel@jlt3.sipsolutions.net>
On Wed, 2010-08-04 at 09:46 +0200, Johannes Berg wrote:
> On Wed, 2010-08-04 at 00:41 -0500, Dan Williams wrote:
> > On Fri, 2010-07-30 at 08:35 +0200, Johannes Berg wrote:
> > > On Thu, 2010-07-29 at 23:07 -0700, Dan Williams wrote:
> > > > This series makes libertas actually associate with APs after the
> > > > cfg80211 conversion. There was a pretty big TODO where if cfg80211
> > > > didn't pass in the BSSID of the AP to associate with, then libertas
> > > > would fail because the firmware really, really, really wants a BSSID.
> > > > So lets do a scan to find that BSSID. The other notable change is
> > > > a fix to make sure all supported rates are included in the firmware's
> > > > association request, lack of which caused some APs to deny the attempt.
> > >
> > > I'm a bit tempted to say we could use the connect logic in cfg80211 to
> > > provide this? cfg80211 _already_ provides this if the hardware wants
> > > auth()/assoc() rather than connect() calls, so it seems fairly simple to
> > > also (optionally) do it here?
> >
> > Yeah, I thought about that too. Do you want me to work on that now
> > instead of letting this patch through? I can revert the relevant bits
> > of this later if that's acceptable too.
>
> Either way works for me since I don't care about any cruft in
> libertas ;)
John, if you don't mind applying this patch I'll work on generic
scan-before-connect support in cfg80211 in a further patch series.
Dan
^ permalink raw reply
* Re: [PATCH 0/8] iwlwifi update for 2.6.36
From: John W. Linville @ 2010-08-04 19:03 UTC (permalink / raw)
To: Wey-Yi Guy; +Cc: linux-wireless, ipw3945-devel
In-Reply-To: <1280590452-10655-1-git-send-email-wey-yi.w.guy@intel.com>
On Sat, Jul 31, 2010 at 08:34:04AM -0700, Wey-Yi Guy wrote:
> We move "Thermal throttling" related functions out of power management
> into it own file.
> We also reduce the warning level for "BA scd_flow not match" to
> avoid flood the syslog when condition detected.
> We also track IBSS manager status with uCode beacon notification.
>
> Johannes Berg (2):
> iwlwifi: fix compile warning
>
> Wey-Yi Guy (6):
> iwlwifi: BA scd_flow not match condition detected
> iwlagn: fix typo in ucode_bt_stats_read debugfs
I'm applying these directly as fixes intended for 2.6.36. I will
apply the others to wireless-next-2.6 after the merge window closes
for 2.6.36.
Thanks,
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ 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