* Re: [PATCH] compat: fix uevent_suppress on 2.6.29 or older kernels
From: Grazvydas Ignotas @ 2010-04-22 20:47 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: Pavel Roskin, linux-wireless
In-Reply-To: <x2l43e72e891004221333he942ee92u3ef4c6994d769694@mail.gmail.com>
On Thu, Apr 22, 2010 at 11:33 PM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
> On Thu, Apr 22, 2010 at 9:42 AM, Pavel Roskin <proski@gnu.org> wrote:
>> On Thu, 2010-04-22 at 09:33 -0700, Luis R. Rodriguez wrote:
>>
>>> How was this compiling for older kernels before then?
>>
>> Compiling was fine, but loading the firmware was failing sometimes. I'm
>> glad somebody figured it out. Thank you, Grazvydas!
>
> OK Applied. I'm still puzzled, if it compiled, then that means
> dev_set_uevent_suppress() was being defined somehow for older kernels.
there was already ifdef, old code:
#if (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,30))
dev_set_uevent_suppress(f_dev, 1);
#endif
new code:
#if (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,30))
dev_set_uevent_suppress(f_dev, 1);
#else
f_dev->uevent_suppress = 1;
#endif
>> I would prefer to have replacement functions in compat-2.6.30.h rather
>> than ifdefs in the code. We might want to resync compat_firmware with
>> the kernel one day, and ifdefs would stand in the way.
>
> Good point, I merged the patch for now given that that file does't
> change that often upstream.
>
> Luis
>
^ permalink raw reply
* Re: RTL 8187b - naughty behaviour
From: Rogerio Luz Coelho @ 2010-04-22 20:45 UTC (permalink / raw)
To: Gábor Stefanik
Cc: Larry Finger, linux-wireless, Herton Ronaldo Krzesinski
In-Reply-To: <q2k69e28c911004110635nac8100f6pe014361ed0a516a5@mail.gmail.com>
2010/4/11 Gábor Stefanik <netrolller.3d@gmail.com>:
> 2010/4/10 Rogerio Luz Coelho <rogluz.news@gmail.com>:
>> 2010/4/10 Gábor Stefanik <netrolller.3d@gmail.com>:
>>> On Sat, Apr 10, 2010 at 2:07 PM, Rogerio Luz Coelho
>>> <rogluz.news@gmail.com> wrote:
>>>> 2010/4/3 Rogerio Luz Coelho <rogluz.news@gmail.com>:
>>>>> 2010/4/3 Larry Finger <Larry.Finger@lwfinger.net>:
>>>>>> On 04/03/2010 11:49 AM, Rogerio Luz Coelho wrote:
>>>>>>>
>>>>>>> I have a MS-Win7 instalation on this Laptop and it works 100% even at
>>>>>>> longer distances than you report,even with walls in between.
>>>>>>>
>>>>>>> Will do the tcpperf test as soon as I get home. There are other with
>>>>>>> the same problem with my exact chip here in Brasil , that is because
>>>>>>> one of our leading Laptop vendors uses this config.
>>>>>>
>>>>>> What is the exact make and model of the device? It might be difficult
>>>>>> for me to get one in the US, but one of the rtl8187 developers lives in
>>>>>> Brazil. He should be able to find one.
>>>>>>
>>>>>
>>>>> It愀 a POSITIVO R430L - Core 2 Duo 4GB RAM
>>>>>
>>>>>
>>>>>>> Does it matter that the USB port used in this setting is a connected
>>>>>>> to a USB HUB and then to the mother board?
>>>>>>
>>>>>> Is the hub passive, or is it powered? If the hub is good and not
>>>>>> underpowered, it should be OK.
>>>>>>
>>>>>>> More details and tests will come your way in a day or two ... will
>>>>>>> reinstall Mandriva 2010 and do some tests with older kernels.
>>>>>>
>>>>>> If you can download an openSUSE 11.2 Live CD and burn it, you would not
>>>>>> even have to do an installation. That one has a 2.6.31 kernel.
>>>>>>
>>>>>> Larry
>>>>
>>>>
>>>> Downloaded and installed:
>>>>
>>>> OpenSuse 11.2 - LiveCD result: Gnome Network-Manager tells me there
>>>> is connection but no ping resposes, Firefox complains about conections
>>>> errors.
>>>>
>>>> Mandriva 2010.0 (kernel 2.6.31-12) result: concection comes and goes
>>>> ... generally the first boot of the day connects, but it lasts less
>>>> than 5min. The error code is the "deauthentication by local reason
>>>> (reason=3) again.
>>>>
>>>> MS-Win7 : connects and is as fast as ever.
>>>>
>>>> -- Any other suggestions?
>>>>
>>>> Rogerio
>>>>
>>>> PS: Will give OpenSuse a HD install atempt and will try to debug the
>>>> Mandriva for some time, future tries involve Debian Stable (old
>>>> kernel) and some Fedora (any suggestions?) and the NDISwrapper drive
>>>> in a Debian Testing (the Distro I need working)
>>>
>>> Hi,
>>>
>>> Please also test Realtek's official r8187b driver. If possible, please
>>> do an mmiotrace on that driver.
>>
>> Ok ... The official Realtek is only for 32bits systems right ? ( At
>> least the guys at Realtek support told me so... ) and this mmiotrace
>> can be accomplished how? Is it a program, a command, a debug message
>> in some form? Sorry, as I said earlier I am NOT a kernel programer.
>>
>> Rogerio
>>
>
> You need to enable MMIO tracing support in your kernel config, and
> recompile your kernel (assuming it is not enabled already - distros
> usually disable the entire tracing framework by default). Then:
> -Mount debugfs to /debug. (Usually it is mounted by default, but some
> distros like to mount it @ /sys/kernel/debug instead - remount it to
> /debug.)
> -"echo mmiotrace > /debug/tracing/current_tracer"
> -"cat /debug/tracing/trace_pipe > trace.txt &" - at this point, tracing begins.
> -Load r8187b and connect.
> -"echo "Driver loaded!" > /debug/tracing/trace_marker"
> -"echo nop > /debug/tracing/current_tracer" - tracing ends here.
>
> Do this for rtl8187 as well.
> After each trace, check if "grep -i lost trace.txt" returns anything.
> If it does, enlarge the trace buffer and retry:
> -"cat /debug/tracing/trace_buffer_kb"
> -"echo [BUFSIZE] > /debug/tracing/trace_buffer_kb", where [BUFSIZE] is
> recommended to be about twice the number returned by the previous
> command.
I installed a vanilla kernel 2.6.32.11 , config to rum mmio , but my
rtl818x modules are loaded by default and the modprobe -r command
doesn't seem to change this ... any ideas ?
Rogerio
>
> Repeat these steps until the "lost events" warning disappears. Once
> you find the right BUFSIZE for one driver, you can use the same size
> for the other one too.
>
> Hth,
> Gábor
>
> --
> Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
>
^ permalink raw reply
* Re: [PATCH] compat: fix uevent_suppress on 2.6.29 or older kernels
From: Luis R. Rodriguez @ 2010-04-22 20:33 UTC (permalink / raw)
To: Pavel Roskin; +Cc: Grazvydas Ignotas, linux-wireless
In-Reply-To: <1271954537.8469.15.camel@mj>
On Thu, Apr 22, 2010 at 9:42 AM, Pavel Roskin <proski@gnu.org> wrote:
> On Thu, 2010-04-22 at 09:33 -0700, Luis R. Rodriguez wrote:
>
>> How was this compiling for older kernels before then?
>
> Compiling was fine, but loading the firmware was failing sometimes. I'm
> glad somebody figured it out. Thank you, Grazvydas!
OK Applied. I'm still puzzled, if it compiled, then that means
dev_set_uevent_suppress() was being defined somehow for older kernels.
> I would prefer to have replacement functions in compat-2.6.30.h rather
> than ifdefs in the code. We might want to resync compat_firmware with
> the kernel one day, and ifdefs would stand in the way.
Good point, I merged the patch for now given that that file does't
change that often upstream.
Luis
^ permalink raw reply
* Re: Problem with AR5001 on eeepc900A after disable with RFKILL switch
From: Bob Copeland @ 2010-04-22 19:52 UTC (permalink / raw)
To: Larry Finger; +Cc: wireless, Bernhard M. Wiedemann
In-Reply-To: <4BCDEC94.2080202@lwfinger.net>
On Tue, Apr 20, 2010 at 2:04 PM, Larry Finger <Larry.Finger@lwfinger.net> wrote:
> This problem is reported at
> https://bugzilla.novell.com/show_bug.cgi?id=595586.
>
> Although not mentioned in the bug report, the kernel is 2.6.33.
>
> The initial part of the report is as follows:
>
> ======================================================================
>
> After disabling WLAN on Asus eeepc 900A using rfkill button (Fn+F2) it
> does not get back into a working state without a reboot.
>
> Reproducible: Always
>
> Steps to Reproduce:
> 1. boot up eeepc900A with WLAN enabled
> 2. press Fn+F2 (rfkill button) to disable WLAN
> 3. press Fn+F2 again to enable WLAN
> Actual Results:
>
> -----
> 1. lspci before rfkill
> 01:00.0 Ethernet controller: Atheros Communications AR8121/AR8113/AR8114
> Gigabit or Fast Ethernet (rev b0)
> 02:00.0 Ethernet controller: Atheros Communications Inc. AR5001 Wireless
> Network Adapter (rev 01)
> -----
> 2. lspci after rfkill
> 01:00.0 Ethernet controller: Attansic Technology Corp. Atheros
> AR8121/AR8113/AR8114 PCI-E Ethernet Controller (rev b0)
> 02:00.0 Ethernet controller: Atheros Communications Inc. AR5001 Wireless
> Network Adapter (rev ff)
Weird..
So it says 'Attansic' on the ethernet only after rfkill is
re-enabled? The 0xff revision on wifi makes slightly
more sense, if it's some issue like broken PCI config space
reads.
IIRC rfkill switch on those platforms cuts the bus power; I don't
think ath5k participates specifically. I assume the
eepc-laptop driver is loaded?
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* [PATCH 2/2] p54pci: fix regression from prevent stuck rx-ring on slow system
From: Christian Lamparter @ 2010-04-22 17:52 UTC (permalink / raw)
To: linux-wireless; +Cc: linville, hdegoede
From: Hans de Goede <hdegoede@redhat.com>
This patch fixes a recently introduced use-after-free regression
from "p54pci: prevent stuck rx-ring on slow system".
Hans de Goede reported a use-after-free regression:
>BUG: unable to handle kernel paging request at 6b6b6b6b
>IP: [<e122284a>] p54p_check_tx_ring+0x84/0xb1 [p54pci]
>*pde = 00000000
>Oops: 0000 [#1] SMP
>EIP: 0060:[<e122284a>] EFLAGS: 00010286 CPU: 0
>EIP is at p54p_check_tx_ring+0x84/0xb1 [p54pci]
>EAX: 6b6b6b6b EBX: df10b170 ECX: 00000003 EDX: 00000001
>ESI: dc471500 EDI: d8acaeb0 EBP: c098be9c ESP: c098be84
> DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
>Process swapper (pid: 0, ti=c098a000 task=c09ccfe0 task.ti=c098a000)
>Call Trace:
> [<e1222b02>] ? p54p_tasklet+0xaa/0xb5 [p54pci]
> [<c0440568>] ? tasklet_action+0x78/0xcb
> [<c0440ed3>] ? __do_softirq+0xbc/0x173
Quote from comment #17:
"The problem is the innocent looking moving of the tx processing to
after the rx processing in the tasklet. Quoting from the changelog:
This patch does it the same way, except that it also prioritize
rx data processing, simply because tx routines *can* wait.
This is causing an issue with us referencing already freed memory,
because some skb's we transmit, we immediately receive back, such
as those for reading the eeprom (*) and getting stats.
What can happen because of the moving of the tx processing to after
the rx processing is that when the tasklet first runs after doing a
special skb tx (such as eeprom) we've already received the answer
to it.
Then the rx processing ends up calling p54_find_and_unlink_skb to
find the matching tx skb for the just received special rx skb and
frees the tx skb.
Then after the processing of the rx skb answer, and thus freeing
the tx skb, we go process the completed tx ring entires, and then
dereference the free-ed skb, to see if it should free free-ed by
p54p_check_tx_ring()."
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=583623
Bug-Identified-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
---
diff --git a/drivers/net/wireless/p54/p54pci.c b/drivers/net/wireless/p54/p54pci.c
index ca42ccb..07c4528 100644
--- a/drivers/net/wireless/p54/p54pci.c
+++ b/drivers/net/wireless/p54/p54pci.c
@@ -277,6 +277,14 @@ static void p54p_tasklet(unsigned long dev_id)
struct p54p_priv *priv = dev->priv;
struct p54p_ring_control *ring_control = priv->ring_control;
+ p54p_check_tx_ring(dev, &priv->tx_idx_mgmt, 3, ring_control->tx_mgmt,
+ ARRAY_SIZE(ring_control->tx_mgmt),
+ priv->tx_buf_mgmt);
+
+ p54p_check_tx_ring(dev, &priv->tx_idx_data, 1, ring_control->tx_data,
+ ARRAY_SIZE(ring_control->tx_data),
+ priv->tx_buf_data);
+
p54p_check_rx_ring(dev, &priv->rx_idx_mgmt, 2, ring_control->rx_mgmt,
ARRAY_SIZE(ring_control->rx_mgmt), priv->rx_buf_mgmt);
@@ -285,14 +293,6 @@ static void p54p_tasklet(unsigned long dev_id)
wmb();
P54P_WRITE(dev_int, cpu_to_le32(ISL38XX_DEV_INT_UPDATE));
-
- p54p_check_tx_ring(dev, &priv->tx_idx_mgmt, 3, ring_control->tx_mgmt,
- ARRAY_SIZE(ring_control->tx_mgmt),
- priv->tx_buf_mgmt);
-
- p54p_check_tx_ring(dev, &priv->tx_idx_data, 1, ring_control->tx_data,
- ARRAY_SIZE(ring_control->tx_data),
- priv->tx_buf_data);
}
static irqreturn_t p54p_interrupt(int irq, void *dev_id)
^ permalink raw reply related
* [PATCH 1/2] p54pci: fix bugs in p54p_check_tx_ring
From: Christian Lamparter @ 2010-04-22 17:52 UTC (permalink / raw)
To: linux-wireless; +Cc: linville, hdegoede
From: Hans de Goede <hdegoede@redhat.com>
Hans de Goede identified a bug in p54p_check_tx_ring:
there are two ring indices. 1 => tx data and 3 => tx management.
But the old code had a constant "1" and this resulted in spurious
dma unmapping failures.
Cc: stable@kernel.org
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=583623
Bug-Identified-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
---
diff --git a/drivers/net/wireless/p54/p54pci.c b/drivers/net/wireless/p54/p54pci.c
index 679da7e..cffe2f2 100644
--- a/drivers/net/wireless/p54/p54pci.c
+++ b/drivers/net/wireless/p54/p54pci.c
@@ -246,7 +246,7 @@ static void p54p_check_tx_ring(struct ieee80211_hw *dev, u32 *index,
u32 idx, i;
i = (*index) % ring_limit;
- (*index) = idx = le32_to_cpu(ring_control->device_idx[1]);
+ (*index) = idx = le32_to_cpu(ring_control->device_idx[ring_index]);
idx %= ring_limit;
while (i != idx) {
^ permalink raw reply related
* Re: [PATCH] compat: fix uevent_suppress on 2.6.29 or older kernels
From: Pavel Roskin @ 2010-04-22 16:42 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: Grazvydas Ignotas, linux-wireless
In-Reply-To: <g2o43e72e891004220933i5faec995qae1b358ce66ed2d@mail.gmail.com>
On Thu, 2010-04-22 at 09:33 -0700, Luis R. Rodriguez wrote:
> How was this compiling for older kernels before then?
Compiling was fine, but loading the firmware was failing sometimes. I'm
glad somebody figured it out. Thank you, Grazvydas!
I would prefer to have replacement functions in compat-2.6.30.h rather
than ifdefs in the code. We might want to resync compat_firmware with
the kernel one day, and ifdefs would stand in the way.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: [PATCH] mac80211: Fix sta->last_tx_rate setting with no-op rate control devices
From: Luis R. Rodriguez @ 2010-04-22 16:28 UTC (permalink / raw)
To: Juuso Oikarinen; +Cc: linville, linux-wireless
In-Reply-To: <1271921268-7512-1-git-send-email-juuso.oikarinen@nokia.com>
On Thu, Apr 22, 2010 at 12:27 AM, Juuso Oikarinen
<juuso.oikarinen@nokia.com> wrote:
> The sta->last_tx_rate is traditionally updated just before transmitting a
> frame based on information from the rate control algorithm. However, for
> hardware drivers with IEEE80211_HW_HAS_RATE_CONTROL this is not performed,
> as the rate control algorithm is not executed, and because the used rate is
> not known before the frame has actually been transmitted.
>
> This causes atleast a fixed 1Mb/s to be reported to user space. A few other
> instances of code also rely on this information.
>
> Fix this by setting the sta->last_tx_rate in tx_status handling. There, look
> for last rates entry set by the driver, and use that as value for
> sta->last_tx_rate.
>
> Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
But the actual rate used is not known, or is it? In those cases would
it not be better to inform userspace that the information is not
available?
Luis
^ permalink raw reply
* Re: [PATCH] compat: fix uevent_suppress on 2.6.29 or older kernels
From: Luis R. Rodriguez @ 2010-04-22 16:33 UTC (permalink / raw)
To: Grazvydas Ignotas; +Cc: linux-wireless
In-Reply-To: <1271944442-9214-1-git-send-email-notasas@gmail.com>
On Thu, Apr 22, 2010 at 6:54 AM, Grazvydas Ignotas <notasas@gmail.com> wrote:
> Missing uevent_suppress is causing two uevents instead of one, which is
> confusing udev and sometimes causing firmware load to fail due to race
> condition, so let's add it.
>
> Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
> ---
> compat/compat_firmware_class.c | 6 +++++-
> 1 files changed, 5 insertions(+), 1 deletions(-)
>
> diff --git a/compat/compat_firmware_class.c b/compat/compat_firmware_class.c
> index ce937a3..54ee8b9 100644
> --- a/compat/compat_firmware_class.c
> +++ b/compat/compat_firmware_class.c
> @@ -432,6 +432,8 @@ static int fw_register_device(struct device **dev_p, const char *fw_name,
> dev_set_drvdata(f_dev, fw_priv);
> #if (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,30))
> dev_set_uevent_suppress(f_dev, 1);
> +#else
> + f_dev->uevent_suppress = 1;
> #endif
How was this compiling for older kernels before then?
Luis
^ permalink raw reply
* Re: [PATCH] compat: fix uevent_suppress on 2.6.29 or older kernels
From: Walter Goldens @ 2010-04-22 15:17 UTC (permalink / raw)
To: Grazvydas Ignotas; +Cc: linux-wireless
In-Reply-To: <1271944442-9214-1-git-send-email-notasas@gmail.com>
I reported this nearly a month ago here: http://comments.gmane.org/gmane.linux.kernel.wireless.general/48401
Had a chance to test your patch and everything's fine now. This bug has been existent since January. Great job!
Walter.
--- On Thu, 4/22/10, Grazvydas Ignotas <notasas@gmail.com> wrote:
> From: Grazvydas Ignotas <notasas@gmail.com>
> Subject: [PATCH] compat: fix uevent_suppress on 2.6.29 or older kernels
> To: "Luis R. Rodriguez" <mcgrof@gmail.com>
> Cc: linux-wireless@vger.kernel.org, "Grazvydas Ignotas" <notasas@gmail.com>
> Date: Thursday, April 22, 2010, 9:54 AM
> Missing uevent_suppress is causing
> two uevents instead of one, which is
> confusing udev and sometimes causing firmware load to fail
> due to race
> condition, so let's add it.
>
> Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
> ---
> compat/compat_firmware_class.c | 6 +++++-
> 1 files changed, 5 insertions(+), 1 deletions(-)
>
> diff --git a/compat/compat_firmware_class.c
> b/compat/compat_firmware_class.c
> index ce937a3..54ee8b9 100644
> --- a/compat/compat_firmware_class.c
> +++ b/compat/compat_firmware_class.c
> @@ -432,6 +432,8 @@ static int fw_register_device(struct
> device **dev_p, const char *fw_name,
> dev_set_drvdata(f_dev, fw_priv);
> #if (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,30))
> dev_set_uevent_suppress(f_dev, 1);
> +#else
> + f_dev->uevent_suppress = 1;
> #endif
> retval = device_register(f_dev);
> if (retval) {
> @@ -479,9 +481,11 @@ static int fw_setup_device(struct
> firmware *fw, struct device **dev_p,
> goto error_unreg;
> }
>
> -#if (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,30))
> if (uevent)
> +#if (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,30))
>
> dev_set_uevent_suppress(f_dev, 0);
> +#else
> +
> f_dev->uevent_suppress = 0;
> #endif
> *dev_p = f_dev;
> goto out;
> --
> 1.7.0.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe
> linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH 7/9] ath9k_htc: Use USB reboot
From: Ming Lei @ 2010-04-22 14:21 UTC (permalink / raw)
To: Sujith; +Cc: linville, linux-wireless
In-Reply-To: <19407.50660.739033.942199@gargle.gargle.HOWL>
2010/4/22 Sujith <Sujith.Manoharan@atheros.com>:
> So, apparently there is a USB reboot command
> that the target accepts. Using this instead of
> usb_reset_device() fixes the issue of "descriptor read error"
> that pops up on repeated load/unload.
>
> Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
> ---
> drivers/net/wireless/ath/ath9k/hif_usb.c | 13 ++++++++++++-
> 1 files changed, 12 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath9k/hif_usb.c b/drivers/net/wireless/ath/ath9k/hif_usb.c
> index cee5feb..ce13e08 100644
> --- a/drivers/net/wireless/ath/ath9k/hif_usb.c
> +++ b/drivers/net/wireless/ath/ath9k/hif_usb.c
> @@ -889,6 +889,17 @@ err_alloc:
> return ret;
> }
>
> +static void ath9k_hif_usb_reboot(struct usb_device *udev)
> +{
> + u32 cmd = 0xffffffff;
> + int ret;
> +
> + ret = usb_bulk_msg(udev, usb_sndbulkpipe(udev, USB_REG_OUT_PIPE),
> + &cmd, sizeof(cmd), NULL, HZ);
The buffer passed to usb hcd should not be allocated from stack since
it will be DMAed to usb host controller. The 'cmd' should be allocated by
kmalloc even though it is only 4byte.
--
Lei Ming
^ permalink raw reply
* Re: [PATCH 2/9] ath9k_htc: Handle device unplug properly
From: Ming Lei @ 2010-04-22 14:16 UTC (permalink / raw)
To: Sujith; +Cc: linville, linux-wireless
In-Reply-To: <19407.50651.473633.812258@gargle.gargle.HOWL>
2010/4/22 Sujith <Sujith.Manoharan@atheros.com>:
> When the USB device has been unplugged, there is
> no point in trying to send commands to the target.
> Fix this by denying all WMI commands in such a case.
>
> Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
Tested-by: Ming Lei <tom.leiming@gmail.com>
--
Lei Ming
^ permalink raw reply
* [PATCH] compat: fix uevent_suppress on 2.6.29 or older kernels
From: Grazvydas Ignotas @ 2010-04-22 13:54 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless, Grazvydas Ignotas
Missing uevent_suppress is causing two uevents instead of one, which is
confusing udev and sometimes causing firmware load to fail due to race
condition, so let's add it.
Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
---
compat/compat_firmware_class.c | 6 +++++-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/compat/compat_firmware_class.c b/compat/compat_firmware_class.c
index ce937a3..54ee8b9 100644
--- a/compat/compat_firmware_class.c
+++ b/compat/compat_firmware_class.c
@@ -432,6 +432,8 @@ static int fw_register_device(struct device **dev_p, const char *fw_name,
dev_set_drvdata(f_dev, fw_priv);
#if (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,30))
dev_set_uevent_suppress(f_dev, 1);
+#else
+ f_dev->uevent_suppress = 1;
#endif
retval = device_register(f_dev);
if (retval) {
@@ -479,9 +481,11 @@ static int fw_setup_device(struct firmware *fw, struct device **dev_p,
goto error_unreg;
}
-#if (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,30))
if (uevent)
+#if (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,30))
dev_set_uevent_suppress(f_dev, 0);
+#else
+ f_dev->uevent_suppress = 0;
#endif
*dev_p = f_dev;
goto out;
--
1.7.0.2
^ permalink raw reply related
* p54usb - AP degenerates (Kernel 2.6.31.13)
From: Antonio Weber @ 2010-04-22 11:39 UTC (permalink / raw)
To: linux-wireless
Hi List,
I try to set up a Accesspoint with a Netgear WG111v2 USB Stick which is
supported by the p54 driver.
I'm working on a small evaluation board with a i.mx27 ARM cpu which is
currently not supported via the mainline kernel. For that the vendor provides
a kernel patch to support it. I allready tried to port it to the 2.6.33 Kernel
- it compiles without bigger troubles but the Kernel was unable to boot (gets
not even uncompressed - litte bit strange - so what... :) - have to stay at
2.6.31 line)
The startup with hostapd works fine. At the moment i have encryption disabled
so it is easy to connect because it is only for demostration purpose (even a
handy or ipod should be able to connect) and works in a closed environment for
max. an hour or so.
Some debug output here
---------
usb 1-1: new high speed USB device using mxc-ehci and address 2
usb 1-1: New USB device found, idVendor=0846, idProduct=4240
usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-1: Product: NETGEAR WG111
usb 1-1: Manufacturer: GlobespanVirata
usb 1-1: SerialNumber: 3887-0000
usb 1-1: configuration #1 chosen from 1 choice
cfg80211: Calling CRDA to update world regulatory domain
usb 1-1: firmware: requesting isl3887usb
phy0: p54 detected a LM87 firmware
p54: rx_mtu reduced from 3240 to 2384
phy0: FW rev 2.13.24.0 - Softmac protocol 5.9
phy0: cryptographic accelerator WEP:YES, TKIP:YES, CCMP:YES
phy0: hwaddr 00:0f:b5:02:2e:64, MAC:isl3887 RF:Frisbee
phy0: Selected rate control algorithm 'minstrel'
usb 1-1: is registered as 'phy0'
usbcore: registered new interface driver p54usb
eth0: config: auto-negotiation on, 100FDX, 100HDX, 10FDX, 10HDX.
phy0: device now idle
in p54_set_ps: 2
phy0: device no longer idle - in use
in p54_set_ps: 2
cfg80211: Calling CRDA for country: DE
phy0: Allocated STA f8:1e:df:d1:df:8e
phy0: Inserted STA f8:1e:df:d1:df:8e
----------
up to here - everything works fine. A device gets an IP address via dhcp after
connecting, can ping etc.
after some minutes lots of that messages apear
-----------
wlan0: STA f8:1e:df:d1:df:8e aid 1 enters power save mode
wlan0: STA f8:1e:df:d1:df:8e aid 1 exits power save mode
wlan0: STA f8:1e:df:d1:df:8e aid 1 sending 0 filtered/0 PS frames since STA
not sleeping anymore
wlan0: STA f8:1e:df:d1:df:8e aid 1 enters power save mode
STA f8:1e:df:d1:df:8e aid 1: PS buffer (entries before 0)
STA f8:1e:df:d1:df:8e aid 1: PS buffer (entries before 1)
wlan0: STA f8:1e:df:d1:df:8e aid 1 exits power save mode
wlan0: STA f8:1e:df:d1:df:8e aid 1 sending 0 filtered/2 PS frames since STA
not sleeping anymore
wlan0: STA f8:1e:df:d1:df:8e aid 1 enters power save mode
wlan0: STA f8:1e:df:d1:df:8e aid 1 exits power save mode
wlan0: STA f8:1e:df:d1:df:8e aid 1 sending 0 filtered/0 PS frames since STA
not sleeping anymore
wlan0: STA f8:1e:df:d1:df:8e aid 1 enters power save mode
wlan0: STA f8:1e:df:d1:df:8e aid 1 exits power save mode
wlan0: STA f8:1e:df:d1:df:8e aid 1 sending 0 filtered/0 PS frames since STA
not sleeping anymore
.....
------------
(btw weird mac address, isn't it?)
and then it refuses to work. No futher devices can connect. Even the connected
devices can not be ping anymore because ARP packets are no longer answered.
On my laptop I get that kernel-messages when trying to connect to the ap
------------
wlan0: deauthenticating from 00:0f:b5:02:2e:64 by local choice (reason=3)
wlan0: direct probe to AP 00:0f:b5:02:2e:64 (try 1)
wlan0: direct probe to AP 00:0f:b5:02:2e:64 (try 2)
wlan0: direct probe to AP 00:0f:b5:02:2e:64 (try 3)
wlan0: direct probe to AP 00:0f:b5:02:2e:64 timed out
wlan0: direct probe to AP 00:0f:b5:02:2e:64 (try 1)
wlan0: direct probe to AP 00:0f:b5:02:2e:64 (try 2)
wlan0: direct probe to AP 00:0f:b5:02:2e:64 (try 3)
wlan0: direct probe to AP 00:0f:b5:02:2e:64 timed out
--------------
Its probably a problem with the power management in station mode (which seems
to be an issue to more drivers as I found out reading some entries on this
list).
So my questions are:
Is it perhaps possible to disable that powersave mode for AP completly in an
'easy' way? (btw. 'enable powersave by default' is disabled in kernel config
but thats only for managed mode right?).
If not - could it be allready fixed in a newer version of the kernel? If so it
would be great if someone out there could give me some pointer where to look
at in special - so I can try to fix it myself (somehow :) )
Thanks in advance
greetings,
Antonio
^ permalink raw reply
* bug report: potential ERR_PTR dereference in iwm_debugfs_init()
From: Dan Carpenter @ 2010-04-22 9:59 UTC (permalink / raw)
To: Zhu Yi; +Cc: Intel Linux Wireless, linux-wireless
Hi Zhu Yi,
This is a Smatch bug that has me a little puzzled.
drivers/net/wireless/iwmc3200wifi/debugfs.c +447 iwm_debugfs_init(26)
warn: 'iwm->dbg.devdir' dereferencing possible ERR_PTR()
440 iwm->dbg.devdir = debugfs_create_dir(devdir, iwm->dbg.rootdir);
441 result = PTR_ERR(iwm->dbg.devdir);
442 if (IS_ERR(iwm->dbg.devdir) && (result != -ENODEV)) {
443 IWM_ERR(iwm, "Couldn't create devdir: %d\n", result);
444 goto error;
445 }
446
447 iwm->dbg.dbgdir = debugfs_create_dir("debug", iwm->dbg.devdir);
It looks like "iwm->dbg.devdir" could be ERR_PTR(-ENODEV) on line 447 and
that would cause a problem inside debugfs_create_dir(). But at the same
time -ENODEV was deliberately singled out as OK from other possible errors
that debugfs_create_dir() can return.
I'm confused.
regards,
dan carpenter
^ permalink raw reply
* Re: [RFC PATCHv3 1/2] mac80211: Determine dynamic PS timeout based on ps-qos network latency
From: Juuso Oikarinen @ 2010-04-22 9:29 UTC (permalink / raw)
To: ext Johannes Berg; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1271927257.3605.18.camel@jlt3.sipsolutions.net>
On Thu, 2010-04-22 at 11:07 +0200, ext Johannes Berg wrote:
> On Thu, 2010-04-22 at 11:55 +0300, Juuso Oikarinen wrote:
>
> > > > Well you have to see where I'm coming from - I must come up with a way
> > > > to tune the dynamic ps timeout value from user-space in a way that is
> > > > agreeable with others, and that is somewhat future-proof.
> > >
> > > Well I personally think that's your first mistake ;)
> > >
> > > Why does userspace care about the dynamic PS timeout value to start
> > > with? All it should care about is the latency with which it can react to
> > > network packets, no?
> > >
> > > > That said, obviously the network latency should be tuned as, well, the
> > > > expected network latency. In this phase though, there are no other
> > > > parameters affected by the network latency, so the result is quite
> > > > obvious - your fear will realise itself ;)
> > >
> > > But there are, like the max sleep period in # of beacons.
> >
> > Yeah, okay there is. You probably noticed I posted a version of the
> > patches with "saner" latency-values for this reason.
>
> Still I think you should say why you need to actually tune the PS
> timeout value directly? I can't see how your high-level design says "set
> dynamic PS timeout to 100ms" rather than "make sure that while the user
> is operating the device, there's no delay of more than 50ms" or
> something like that?
You're partly right asking this. The high-level design obviously does
not know about dynamic PS timeouts. It seems you're mainly looking at
this from the angle of the network latency itself - i.e. network
performance. My primary angle currently is power consumption.
IMHO both angles are correct. The if the user sets a tight
network-latency requirement, the value can be used to tune things so
that the requirement can be met. If they set a loose requirement, it can
be used as a signal to do more aggressive power saving, which often
means reduced latency.
While the mechanism I'm proposing here is rather crude, it does save
power when the user-space loosens their latency requirement. The values
chosen for the dynamic ps-timeout bear no direct relation to user space
requirements. They are simply values that we have found to give decent
results in typical AP configurations.
The ps_timeout could be calculated based on the latency too, I guess.
I'm just not aware of any simple formula to do this.
-Juuso
> johannes
>
^ permalink raw reply
* [PATCH 2/2] ath9k_htc: Really fix device hotunplug
From: Sujith @ 2010-04-22 9:30 UTC (permalink / raw)
To: linville; +Cc: linux-wireless
All commands to the target are disabled when the device
is unplugged, but a normal module unload has to be
differentiated from this case, as we could still receive
data in the RX endpoint. Fix this by checking if the
device is attached or not.
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
---
drivers/net/wireless/ath/ath9k/hif_usb.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/hif_usb.c b/drivers/net/wireless/ath/ath9k/hif_usb.c
index 6e34852..ea92758 100644
--- a/drivers/net/wireless/ath/ath9k/hif_usb.c
+++ b/drivers/net/wireless/ath/ath9k/hif_usb.c
@@ -913,7 +913,8 @@ static void ath9k_hif_usb_disconnect(struct usb_interface *interface)
(struct hif_device_usb *) usb_get_intfdata(interface);
if (hif_dev) {
- ath9k_htc_hw_deinit(hif_dev->htc_handle, true);
+ ath9k_htc_hw_deinit(hif_dev->htc_handle,
+ (udev->state == USB_STATE_NOTATTACHED) ? true : false);
ath9k_htc_hw_free(hif_dev->htc_handle);
ath9k_hif_usb_dev_deinit(hif_dev);
usb_set_intfdata(interface, NULL);
--
1.7.0.5
^ permalink raw reply related
* [PATCH 1/2] ath9k_htc: Fix WMI command race
From: Sujith @ 2010-04-22 9:28 UTC (permalink / raw)
To: linville; +Cc: linux-wireless
My patch "ath9k_htc: Handle WMI timeouts properly" introduced
a race condition in WMI command processing. The last issued command
should be stored _before_ issuing a WMI command. Not doing this
would result in the WMI event IRQ dropping correct command responses
as invalid.
Fix this race by storing the command id correctly.
Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
---
drivers/net/wireless/ath/ath9k/wmi.c | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/wmi.c b/drivers/net/wireless/ath/ath9k/wmi.c
index c688545..e23172c 100644
--- a/drivers/net/wireless/ath/ath9k/wmi.c
+++ b/drivers/net/wireless/ath/ath9k/wmi.c
@@ -305,14 +305,14 @@ int ath9k_wmi_cmd(struct wmi *wmi, enum wmi_cmd_id cmd_id,
wmi->cmd_rsp_buf = rsp_buf;
wmi->cmd_rsp_len = rsp_len;
- ret = ath9k_wmi_cmd_issue(wmi, skb, cmd_id, cmd_len);
- if (ret)
- goto out;
-
spin_lock_irqsave(&wmi->wmi_lock, flags);
wmi->last_cmd_id = cmd_id;
spin_unlock_irqrestore(&wmi->wmi_lock, flags);
+ ret = ath9k_wmi_cmd_issue(wmi, skb, cmd_id, cmd_len);
+ if (ret)
+ goto out;
+
time_left = wait_for_completion_timeout(&wmi->cmd_wait, timeout);
if (!time_left) {
ath_print(common, ATH_DBG_WMI,
--
1.7.0.5
^ permalink raw reply related
* Re: [RFC PATCHv3 1/2] mac80211: Determine dynamic PS timeout based on ps-qos network latency
From: Johannes Berg @ 2010-04-22 9:07 UTC (permalink / raw)
To: Juuso Oikarinen; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1271926547.6205.8870.camel@wimaxnb.nmp.nokia.com>
On Thu, 2010-04-22 at 11:55 +0300, Juuso Oikarinen wrote:
> > > Well you have to see where I'm coming from - I must come up with a way
> > > to tune the dynamic ps timeout value from user-space in a way that is
> > > agreeable with others, and that is somewhat future-proof.
> >
> > Well I personally think that's your first mistake ;)
> >
> > Why does userspace care about the dynamic PS timeout value to start
> > with? All it should care about is the latency with which it can react to
> > network packets, no?
> >
> > > That said, obviously the network latency should be tuned as, well, the
> > > expected network latency. In this phase though, there are no other
> > > parameters affected by the network latency, so the result is quite
> > > obvious - your fear will realise itself ;)
> >
> > But there are, like the max sleep period in # of beacons.
>
> Yeah, okay there is. You probably noticed I posted a version of the
> patches with "saner" latency-values for this reason.
Still I think you should say why you need to actually tune the PS
timeout value directly? I can't see how your high-level design says "set
dynamic PS timeout to 100ms" rather than "make sure that while the user
is operating the device, there's no delay of more than 50ms" or
something like that?
johannes
^ permalink raw reply
* Re: [RFC PATCHv3 1/2] mac80211: Determine dynamic PS timeout based on ps-qos network latency
From: Johannes Berg @ 2010-04-22 9:05 UTC (permalink / raw)
To: Juuso Oikarinen; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1271926547.6205.8870.camel@wimaxnb.nmp.nokia.com>
On Thu, 2010-04-22 at 11:55 +0300, Juuso Oikarinen wrote:
> > > Well you have to see where I'm coming from - I must come up with a way
> > > to tune the dynamic ps timeout value from user-space in a way that is
> > > agreeable with others, and that is somewhat future-proof.
> >
> > Well I personally think that's your first mistake ;)
> >
> > Why does userspace care about the dynamic PS timeout value to start
> > with? All it should care about is the latency with which it can react to
> > network packets, no?
> >
> > > That said, obviously the network latency should be tuned as, well, the
> > > expected network latency. In this phase though, there are no other
> > > parameters affected by the network latency, so the result is quite
> > > obvious - your fear will realise itself ;)
> >
> > But there are, like the max sleep period in # of beacons.
>
> Yeah, okay there is. You probably noticed I posted a version of the
> patches with "saner" latency-values for this reason.
Right.
> I think there is something fishy in the max-sleep-period implementation.
> I don't yet understand it fully, but it seems to me the host is trying
> to set up it's own dtim interval, regardless of what the AP is
> configured with. It seems to me that this could lead to loss of
> broadcast/multicast frames, if the sta is not waking up a AP dtim
> beacons, but instead has its own cycle. But I have to look into this
> deeper at some point, so let's not get caught in this now.
Ah, I guess you can't just use the value we calculate as the real
period, it's just the max. This depends on the device implementation
though. If your device needs to have a value "wake up ever N beacons"
then in fact you cannot use the value but have to use gcd(value, dtim).
But if the device can e.g. "wake up after N, N, N, M beacons" then you
can set N=value, M=dtim_period-3*value or something like that ...
johannes
^ permalink raw reply
* Re: [rt2x00] rt3070 fails to initialize with rt2800usb
From: Walter Goldens @ 2010-04-22 9:05 UTC (permalink / raw)
To: Gertjan van Wingerde; +Cc: Ivo van Doorn, linux-wireless, users
In-Reply-To: <4BCF69BC.9040800@gmail.com>
> > I think I spoke too early. Must have been a snarl up
> at my end, because even removing the "#" comment sign before
> "CONFIG_RT2800USB_RT30XX=y" in config.mk doesn't solve the
> detection problem.
> >
> > I just concluded a test with today's compat-wireless
> /April 20/, enabled "CONFIG_RT2800USB_RT30XX=y" in
> config.mk, but rt2800usb doesn't detect the VIDs and
> subsequently fails to initialize the device. Adding, however
> the card's VIDs in the upper portion of code appears to
> solve the case. I welcome you to test yourself.
> >
> > The good news is, once we get past the detection
> debacle the device seems to finally show some life.
> >
>
> I just checked with the compat-wireless of April 18, and
> with me removing the '#' sign in config.mk does the trick.
> I can't explain why it doesn't work for you, but I cannot
> see anything wrong with compat-wireless or with rt2x00
> inside compat-wireless.
>
> --
> Gertjan.
The problem remains. I have two cards: rt3070 and rt3071, their respective VIDs are 148f:3070 and 148f:3071. They are both undetected. Just tried "compat-wireless-2010-04-21.tar.bz2" with enabled "CONFIG_RT2800PCI_RT30XX=y" in config.mk - no go.
The rt2800usb does not pick the VIDs, here is the log from modinfo rt2800usb:
filename: /lib/modules/2.6.31-20-generic/updates/drivers/net/wireless/rt2x00/rt2800usb.ko
license: GPL
firmware: rt2870.bin
description: Ralink RT2800 USB Wireless LAN driver.
version: 2.3.0
author: http://rt2x00.serialmonkey.com
srcversion: 89BFEC74F4AE6DC8C4BA0E8
alias: usb:v0586p3416d*dc*dsc*dp*ic*isc*ip*
alias: usb:v5A57p0282d*dc*dsc*dp*ic*isc*ip*
alias: usb:v5A57p0280d*dc*dsc*dp*ic*isc*ip*
alias: usb:v0CDEp0025d*dc*dsc*dp*ic*isc*ip*
alias: usb:v0CDEp0022d*dc*dsc*dp*ic*isc*ip*
alias: usb:v157Ep300Ed*dc*dsc*dp*ic*isc*ip*
alias: usb:v177Fp0302d*dc*dsc*dp*ic*isc*ip*
alias: usb:v15A9p0006d*dc*dsc*dp*ic*isc*ip*
alias: usb:v083ApB522d*dc*dsc*dp*ic*isc*ip*
alias: usb:v083ApA618d*dc*dsc*dp*ic*isc*ip*
alias: usb:v083Ap8522d*dc*dsc*dp*ic*isc*ip*
alias: usb:v083Ap7522d*dc*dsc*dp*ic*isc*ip*
alias: usb:v083Ap7512d*dc*dsc*dp*ic*isc*ip*
alias: usb:v083Ap6618d*dc*dsc*dp*ic*isc*ip*
alias: usb:v0DF6p003Fd*dc*dsc*dp*ic*isc*ip*
alias: usb:v0DF6p003Dd*dc*dsc*dp*ic*isc*ip*
alias: usb:v0DF6p003Bd*dc*dsc*dp*ic*isc*ip*
alias: usb:v0DF6p0039d*dc*dsc*dp*ic*isc*ip*
alias: usb:v0DF6p002Dd*dc*dsc*dp*ic*isc*ip*
alias: usb:v0DF6p002Cd*dc*dsc*dp*ic*isc*ip*
alias: usb:v0DF6p002Bd*dc*dsc*dp*ic*isc*ip*
alias: usb:v0DF6p0017d*dc*dsc*dp*ic*isc*ip*
alias: usb:v129Bp1828d*dc*dsc*dp*ic*isc*ip*
alias: usb:v04E8p2018d*dc*dsc*dp*ic*isc*ip*
alias: usb:v148Fp2870d*dc*dsc*dp*ic*isc*ip*
alias: usb:v148Fp2770d*dc*dsc*dp*ic*isc*ip*
alias: usb:v2019pED06d*dc*dsc*dp*ic*isc*ip*
alias: usb:v0471p200Fd*dc*dsc*dp*ic*isc*ip*
alias: usb:v0DB0p6899d*dc*dsc*dp*ic*isc*ip*
alias: usb:v100Dp9031d*dc*dsc*dp*ic*isc*ip*
alias: usb:v0789p0164d*dc*dsc*dp*ic*isc*ip*
alias: usb:v0789p0163d*dc*dsc*dp*ic*isc*ip*
alias: usb:v0789p0162d*dc*dsc*dp*ic*isc*ip*
alias: usb:v1737p0071d*dc*dsc*dp*ic*isc*ip*
alias: usb:v1737p0070d*dc*dsc*dp*ic*isc*ip*
alias: usb:v0E66p0003d*dc*dsc*dp*ic*isc*ip*
alias: usb:v0E66p0001d*dc*dsc*dp*ic*isc*ip*
alias: usb:v1044p800Bd*dc*dsc*dp*ic*isc*ip*
alias: usb:v1740p9702d*dc*dsc*dp*ic*isc*ip*
alias: usb:v1740p9701d*dc*dsc*dp*ic*isc*ip*
alias: usb:v7392p7718d*dc*dsc*dp*ic*isc*ip*
alias: usb:v7392p7717d*dc*dsc*dp*ic*isc*ip*
alias: usb:v07D1p3C11d*dc*dsc*dp*ic*isc*ip*
alias: usb:v07D1p3C09d*dc*dsc*dp*ic*isc*ip*
alias: usb:v07AAp003Fd*dc*dsc*dp*ic*isc*ip*
alias: usb:v07AAp003Cd*dc*dsc*dp*ic*isc*ip*
alias: usb:v07AAp002Fd*dc*dsc*dp*ic*isc*ip*
alias: usb:v14B2p3C28d*dc*dsc*dp*ic*isc*ip*
alias: usb:v14B2p3C27d*dc*dsc*dp*ic*isc*ip*
alias: usb:v14B2p3C25d*dc*dsc*dp*ic*isc*ip*
alias: usb:v14B2p3C23d*dc*dsc*dp*ic*isc*ip*
alias: usb:v14B2p3C09d*dc*dsc*dp*ic*isc*ip*
alias: usb:v14B2p3C07d*dc*dsc*dp*ic*isc*ip*
alias: usb:v14B2p3C06d*dc*dsc*dp*ic*isc*ip*
alias: usb:v0411p00E8d*dc*dsc*dp*ic*isc*ip*
alias: usb:v050Dp815Cd*dc*dsc*dp*ic*isc*ip*
alias: usb:v050Dp805Cd*dc*dsc*dp*ic*isc*ip*
alias: usb:v050Dp8053d*dc*dsc*dp*ic*isc*ip*
alias: usb:v13D3p3247d*dc*dsc*dp*ic*isc*ip*
alias: usb:v0B05p1742d*dc*dsc*dp*ic*isc*ip*
alias: usb:v0B05p1732d*dc*dsc*dp*ic*isc*ip*
alias: usb:v0B05p1731d*dc*dsc*dp*ic*isc*ip*
alias: usb:v1690p0740d*dc*dsc*dp*ic*isc*ip*
alias: usb:v15C5p0008d*dc*dsc*dp*ic*isc*ip*
alias: usb:v1482p3C09d*dc*dsc*dp*ic*isc*ip*
alias: usb:v07B8p2770d*dc*dsc*dp*ic*isc*ip*
alias: usb:v07B8p2870d*dc*dsc*dp*ic*isc*ip*
no "3070" or "3071" at all.
The closest to my VIDs are these here:
alias: usb:v148Fp2870d*dc*dsc*dp*ic*isc*ip*
alias: usb:v148Fp2770d*dc*dsc*dp*ic*isc*ip*
So basically the driver only works if I manually add them to code above. Config.mk doesn't seem to change anything.
The problem as I recall first occurred in late January or some time in February when someone decided to remove large portion of the VIDs from the code because of driver collisions and I suppose the purpose of it was to reshuffle VID tables and insert some sort of order. Since then, compat-wireless does not automatically provide drivers for the rt307x via rt2800usb. To this point, only manual modification and inserting of the VIDs above solves the problem.
I'm a 100% certain of this. Even if your cards have different VIDs /not 148f:3070/, just install compat-wireless with enabled rt307X support and see if "modinfo rt2800usb |grep 3070" returns something. Then you'll be able to verify my reports.
Walter.
^ permalink raw reply
* Re: [RFC PATCHv3 1/2] mac80211: Determine dynamic PS timeout based on ps-qos network latency
From: Juuso Oikarinen @ 2010-04-22 8:55 UTC (permalink / raw)
To: ext Johannes Berg; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1271925939.3605.7.camel@jlt3.sipsolutions.net>
On Thu, 2010-04-22 at 10:45 +0200, ext Johannes Berg wrote:
> On Tue, 2010-04-20 at 08:08 +0300, Juuso Oikarinen wrote:
> > On Mon, 2010-04-19 at 16:42 +0200, ext Johannes Berg wrote:
> > > On Fri, 2010-04-16 at 12:14 +0300, Juuso Oikarinen wrote:
> > > > Determine the dynamic PS timeout based on the configured ps-qos network
> > > > latency. For backwards wext compatibility, allow the dynamic PS timeout
> > > > configured by the cfg80211 to overrule the automatically determined value.
> > >
> > > This seems OK, but I fear that you'll write applications setting the
> > > pm_qos network latency just to affect this parameter?
> > >
> >
> > Well you have to see where I'm coming from - I must come up with a way
> > to tune the dynamic ps timeout value from user-space in a way that is
> > agreeable with others, and that is somewhat future-proof.
>
> Well I personally think that's your first mistake ;)
>
> Why does userspace care about the dynamic PS timeout value to start
> with? All it should care about is the latency with which it can react to
> network packets, no?
>
> > That said, obviously the network latency should be tuned as, well, the
> > expected network latency. In this phase though, there are no other
> > parameters affected by the network latency, so the result is quite
> > obvious - your fear will realise itself ;)
>
> But there are, like the max sleep period in # of beacons.
Yeah, okay there is. You probably noticed I posted a version of the
patches with "saner" latency-values for this reason.
I think there is something fishy in the max-sleep-period implementation.
I don't yet understand it fully, but it seems to me the host is trying
to set up it's own dtim interval, regardless of what the AP is
configured with. It seems to me that this could lead to loss of
broadcast/multicast frames, if the sta is not waking up a AP dtim
beacons, but instead has its own cycle. But I have to look into this
deeper at some point, so let's not get caught in this now.
-Juuso
> johannes
>
^ permalink raw reply
* Re: mac80211 and asymmetric 802.11n TX/RX
From: Johannes Berg @ 2010-04-22 8:50 UTC (permalink / raw)
To: Daniel Halperin; +Cc: linux-wireless
In-Reply-To: <6D966E94-4FD1-4675-B39B-296B4D82D2AB@cs.washington.edu>
Dan,
> > I'm not sure. Reading 7.3.2.56.4 seems to imply that, but I'm not sure
> > about the "Rx Highest Supported Data Rate" field. Seems like maybe you
> > could set the "RX MCS bitmask" to more than is supported, limit it by
> > the highest supported data rate, and then use the bitmask for TX?
>
> First, did you mean 7.3.2.57.4? (I'm using IEEE P802.11n/D7.0, but I
> assume the section numbers haven't changed). For me that section
> represents the "Supported MCS Set field".
I guess they did change then :)
> (An aside: I don't actually *have* 7.3.2.56. I'm using IEEE
> 802.11-2007 [has up to 7.3.2.35] and IEEE P802.11n/D7.0 [has 7.3.2.57
> and beyond] --- In which document are the missing sections?)
I am looking at 802.11n final.
> Can you point me at which text in the section you think implies this
> requirement?
It has a lot of tables .. not easily copied.
> In any case, maybe this discussion is silly: I don't know of any
> devices with this strange configuration. Typically clients assume
> downlink-heavy and might support a 1x2 connection but 2x1, i.e.
> designed for uplink, seems unlikely.
And APs would typically be symmetric, countering Gabor's argument :)
But I don't really understand the standard text here, we'll have to find
somebody more familiar with 11n details.
> >> A second question: my understanding is that if I am a 2x2 node and I
> >> associate to a 3x3 AP, the same code will mask out the fact that the
> >> AP can receive 3 streams since I can't transmit 3 streams. Is there a
> >> way to access this info from the driver if I want it?
> >
> > Unfortunately not, at this point. We could keep track of it, what would
> > you need it for?
>
> Okay, that's what I figured; I can hack around it locally. I'm working
> on an alternative rate selection algorithm that at one point tries to
> take into account how much receive diversity the other endpoint has.
> The intuition is that how well (e.g.) 2-stream rates work is going to
> depend not just on the channel, but also on how many excess antennas
> the receiver has. I would benefit from knowing whether they have 2 or
> 3 antennas even if I can only send them at most 2 streams.
Ah. That makes some sense. So far nothing has needed it, but it _could_
also be useful for debugging, so I wouldn't necessarily mind tracking it
in mac80211.
johannes
^ permalink raw reply
* Re: [RFC PATCHv3 2/2] cfg80211: Remove default dynamic PS timeout value
From: Johannes Berg @ 2010-04-22 8:46 UTC (permalink / raw)
To: Juuso Oikarinen; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1271739508.6205.5712.camel@wimaxnb.nmp.nokia.com>
On Tue, 2010-04-20 at 07:58 +0300, Juuso Oikarinen wrote:
> > Or actually, wouldn't it make sense to move the pm_qos logic here (into
> > cfg80211)?
>
> I thought about that but then I realised that would contradict with one
> of the arguments presented against the dynamic ps API I proposed
> earlier. The argument specifically stated we don't want the API as in
> the future there will be some uber-cool psm implementations in some
> (full-mac?) chipsets that don't even use a value like this.
>
> Therefore I opted to leave the implementation in mac80211, thinking that
> the entire configuration option will be removed from the cfg80211 once
> the wext is gone.
Fair enough. I just thought that IFF the device wants to use a similar
algorithm, it should use the exact same one. But we can cross that
bridge when we have a device.
johannes
^ permalink raw reply
* Re: [RFC PATCHv3 1/2] mac80211: Determine dynamic PS timeout based on ps-qos network latency
From: Johannes Berg @ 2010-04-22 8:45 UTC (permalink / raw)
To: Juuso Oikarinen; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1271740120.6205.5733.camel@wimaxnb.nmp.nokia.com>
On Tue, 2010-04-20 at 08:08 +0300, Juuso Oikarinen wrote:
> On Mon, 2010-04-19 at 16:42 +0200, ext Johannes Berg wrote:
> > On Fri, 2010-04-16 at 12:14 +0300, Juuso Oikarinen wrote:
> > > Determine the dynamic PS timeout based on the configured ps-qos network
> > > latency. For backwards wext compatibility, allow the dynamic PS timeout
> > > configured by the cfg80211 to overrule the automatically determined value.
> >
> > This seems OK, but I fear that you'll write applications setting the
> > pm_qos network latency just to affect this parameter?
> >
>
> Well you have to see where I'm coming from - I must come up with a way
> to tune the dynamic ps timeout value from user-space in a way that is
> agreeable with others, and that is somewhat future-proof.
Well I personally think that's your first mistake ;)
Why does userspace care about the dynamic PS timeout value to start
with? All it should care about is the latency with which it can react to
network packets, no?
> That said, obviously the network latency should be tuned as, well, the
> expected network latency. In this phase though, there are no other
> parameters affected by the network latency, so the result is quite
> obvious - your fear will realise itself ;)
But there are, like the max sleep period in # of beacons.
johannes
^ 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