* Re: [PATCH] ar9170usb: add mode-switching for AVM Fritz!WLAN USB N devices in cdrom mode
From: Matthew Dharm @ 2009-11-01 18:35 UTC (permalink / raw)
To: Josua Dietze
Cc: Frank Schaefer, linux-wireless, linux-usb, johannes, chunkeey
In-Reply-To: <4AEDD380.40408@draisberghof.de>
[-- Attachment #1: Type: text/plain, Size: 1254 bytes --]
On Sun, Nov 01, 2009 at 07:29:20PM +0100, Josua Dietze wrote:
> Frank Schaefer schrieb:
>
> >I really think the mode-switching should be done in the kernel and not
> >in user-space for reasons of usability.
>
> What is wrong with an udev rule entry? By the way, did the "eject"
> command line tool work as well?
And I think it should be done in userspace for issues of maintainability
and useability. It is much easier for users to upgrade their udev then
their kernel.
> >Another benfit is that it binds the mode-switching to the driver. If the
> >driver is blacklisted/not used, there will be no mode-switching.
>
>
> But how would you access the storage part of the device then?
And doing the switch in userspace would solve this problem also.
Finally, if we do this in userspace, device vendors might actually get a
clue and start providing a small linux app or script to do the mode switch
on their virtual storage device, just like they do for windows.
Matt
--
Matthew Dharm Home: mdharm-usb@one-eyed-alien.net
Maintainer, Linux USB Mass Storage Driver
C: They kicked your ass, didn't they?
S: They were cheating!
-- The Chief and Stef
User Friendly, 11/19/1997
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2009-10-28
From: Bartlomiej Zolnierkiewicz @ 2009-11-01 19:04 UTC (permalink / raw)
To: John W. Linville
Cc: Jarek Poplawski, Johannes Berg, Pekka Enberg, David Miller,
linux-wireless, netdev, linux-kernel
In-Reply-To: <20091030150223.GA2586@tuxdriver.com>
On Friday 30 October 2009 16:02:24 John W. Linville wrote:
> Ever since Bartlomiej decided to tear himself away from
> drivers/staging, he has been nothing but negative -- petty, whining,
I think that you should ping Greg about this since somebody impersonating
for me is sending him patches. Last week alone over 20 such patches were
merged -- who knows what this person might be planning.. ;)
Probably the following patch was the source of confusion:
http://patchwork.kernel.org/patch/55076/
It just aligns my personal interests w/ ongoing work done by other people,
hch is working on mac80211 via driver and Greg has announced some time ago
that he was going to work on proper rtl819x support.
--
Bartlomiej Zolnierkiewicz
^ permalink raw reply
* Re: [PATCH] ar9170usb: add mode-switching for AVM Fritz!WLAN USB N devices in cdrom mode
From: Josua Dietze @ 2009-11-01 18:29 UTC (permalink / raw)
To: Frank Schaefer; +Cc: linux-wireless, linux-usb, johannes, chunkeey
In-Reply-To: <4AEDCCA0.8050709@gmx.net>
Frank Schaefer schrieb:
> I really think the mode-switching should be done in the kernel and not
> in user-space for reasons of usability.
What is wrong with an udev rule entry? By the way, did the "eject"
command line tool work as well?
> It also doesn't "pollute" the driver with much code (adds a single
> usb_bulk_msg()).
That may be true for a single device but there are around 30+ others
which are switched outside the kernel, some inside usb-storage, and
this would add even more places where mode switching happened.
> Another benfit is that it binds the mode-switching to the driver. If the
> driver is blacklisted/not used, there will be no mode-switching.
But how would you access the storage part of the device then?
Josua
--
Man is the only creature on earth enabled to take a
warm meal while flying! Loriot
^ permalink raw reply
* Re: [PATCH] ar9170usb: add mode-switching for AVM Fritz!WLAN USB N devices in cdrom mode
From: Johannes Berg @ 2009-11-01 18:27 UTC (permalink / raw)
To: Frank Schaefer; +Cc: linux-wireless, linux-usb, chunkeey
In-Reply-To: <4AEDCCA0.8050709@gmx.net>
[-- Attachment #1: Type: text/plain, Size: 366 bytes --]
On Sun, 2009-11-01 at 19:00 +0100, Frank Schaefer wrote:
> The attached patch adds the mode-switching-procedure to the WLAN-driver
> (ar9170usb) and disables the storage device in the usb-storage-driver.
This patch looks weird. Have you looked at zd1211rw, which also does
this? I think it just adds something to usb-storage for the device IDs?
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* [PATCH] mac80211: check interface is down before type change
From: Johannes Berg @ 2009-11-01 18:25 UTC (permalink / raw)
To: John Linville; +Cc: Arjan van de Ven, linux-wireless
For some strange reason the netif_running() check
ended up after the actual type change instead of
before, potentially causing all kinds of problems
if the interface is up while changing the type;
one of the problems manifests itself as a warning:
WARNING: at net/mac80211/iface.c:651 ieee80211_teardown_sdata+0xda/0x1a0 [mac80211]()
Hardware name: Aspire one
Pid: 2596, comm: wpa_supplicant Tainted: G W 2.6.31-10-generic #32-Ubuntu
Call Trace:
[] warn_slowpath_common+0x6d/0xa0
[] warn_slowpath_null+0x15/0x20
[] ieee80211_teardown_sdata+0xda/0x1a0 [mac80211]
[] ieee80211_if_change_type+0x4a/0xc0 [mac80211]
[] ieee80211_change_iface+0x61/0xa0 [mac80211]
[] cfg80211_wext_siwmode+0xc7/0x120 [cfg80211]
[] ioctl_standard_call+0x58/0xf0
(http://www.kerneloops.org/searchweek.php?search=ieee80211_teardown_sdata)
Cc: Arjan van de Ven <arjan@infradead.org>
Cc: stable@kernel.org
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
---
net/mac80211/cfg.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- wireless-testing.orig/net/mac80211/cfg.c 2009-11-01 19:19:16.000000000 +0100
+++ wireless-testing/net/mac80211/cfg.c 2009-11-01 19:20:49.000000000 +0100
@@ -72,6 +72,9 @@ static int ieee80211_change_iface(struct
struct ieee80211_sub_if_data *sdata;
int ret;
+ if (netif_running(dev))
+ return -EBUSY;
+
if (!nl80211_type_check(type))
return -EINVAL;
@@ -81,9 +84,6 @@ static int ieee80211_change_iface(struct
if (ret)
return ret;
- if (netif_running(sdata->dev))
- return -EBUSY;
-
if (ieee80211_vif_is_mesh(&sdata->vif) && params->mesh_id_len)
ieee80211_sdata_set_mesh_id(sdata,
params->mesh_id_len,
^ permalink raw reply
* [PATCH] ar9170usb: add mode-switching for AVM Fritz!WLAN USB N devices in cdrom mode
From: Frank Schaefer @ 2009-11-01 18:00 UTC (permalink / raw)
To: linux-wireless; +Cc: linux-usb, johannes, chunkeey
In-Reply-To: <4ADC3657.6080906@gmx.net>
[-- Attachment #1: Type: text/plain, Size: 2604 bytes --]
Frank Schaefer schrieb:
> Matthew Dharm schrieb:
>
>> On Sat, Oct 17, 2009 at 11:34:07AM -0400, Alan Stern wrote:
>>
>>
>>> On Sat, 17 Oct 2009, Oliver Neukum wrote:
>>>
>>>
>>>
>>>> Am Samstag, 17. Oktober 2009 15:14:28 schrieb Frank Schaefer:
>>>>
>>>>
>>>>> I can think of multiple solutions for this, my first questions are:
>>>>> Is there already a common solution for these devices in the kernel ?
>>>>> How widespread is this bad habit of device-design ? So far, the only
>>>>> devices I know are
>>>>>
>>>>>
>>>> This is usually handled by the modeswitch tool outside the kernel.
>>>>
>>>>
>>> Alternatively, you may be able to force the device to switch modes by
>>> running the "eject" program on it.
>>>
>>> There is mode-switching code in the kernel for a few devices. The
>>> current trend is to move this out of the kernel and let user programs
>>> be responsible for it.
>>>
>>>
>> If you go with the current trend, then you probably will want to write some
>> UDEV rules to recognize these devices and issue the mode-changing command
>> (either modeswitch or eject).
>>
>> Matt
>>
>>
> Thanks for your replies, I really didn't know that there are so many
> devices showing this behavior.
>
> On Windows, AVM does the fast-eject for its devices with a small
> filter-driver avmeject.sys.
> I will try to find out the "magic sequence" needed for the mode-switch
> with a USB-logger.
>
> Regards,
> Frank
>
I finally found the "magic" sequence.
In the meantime I've been thinking a lot (too much ?) about HOW and
WHERE to do the mode-switching.
The mailing-list-archieves were really inspiring, maybe you remember the
discussion about Tejun Heos' patches in april 2008.
The conclusion was that there is no clearly preferable way to do this
and that compromises are inevitable.
The attached patch adds the mode-switching-procedure to the WLAN-driver
(ar9170usb) and disables the storage device in the usb-storage-driver.
I really think the mode-switching should be done in the kernel and not
in user-space for reasons of usability.
Doing it in the driver means putting the code for these device together
in a single place.
It also doesn't "pollute" the driver with much code (adds a single
usb_bulk_msg()).
Another benfit is that it binds the mode-switching to the driver. If the
driver is blacklisted/not used, there will be no mode-switching.
If there would be a way to keep the usb-storage-driver enabled as
"fallback-driver" it would be an almost perfect solution...
Regards,
Frank
[-- Attachment #2: 0001-ar9170usb-add-mode-switching-for-AVM-Fritz-WLAN-USB.patch --]
[-- Type: application/mbox, Size: 4522 bytes --]
^ permalink raw reply
* Re: b43 with 14e4 gives DMA error
From: Gábor Stefanik @ 2009-11-01 15:30 UTC (permalink / raw)
To: Thomas Wiecki; +Cc: linux-wireless
In-Reply-To: <4888b8cb0911010451w3e824921ob5ee6b7aae5b728b@mail.gmail.com>
On Sun, Nov 1, 2009 at 1:51 PM, Thomas Wiecki
<thomas.wiecki@googlemail.com> wrote:
> 0c:00.0 Network controller [0280]: Broadcom Corporation BCM4312
> 802.11b/g [14e4:4315] (rev 01)
> Subsystem: Dell Device [1028:000c]
> Flags: bus master, fast devsel, latency 0, IRQ 17
> Memory at f1ffc000 (64-bit, non-prefetchable) [size=16K]
> Capabilities: <access denied>
> Kernel driver in use: wl
> Kernel modules: wl, ssb
>
> A variable delay after loading the most recent b43 driver I get a lot
> of (I hope last nights patches would have fixed the problems, but they
> didn't):
> [ 6895.111946] b43-phy0 ERROR: Fatal DMA error: 0x00000800,
> 0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000
> [ 6895.111955] b43-phy0: Controller RESET (DMA error) ...
> [ 6895.336490] b43-phy0: Loading firmware version 478.104 (2008-07-01 00:50:23)
> [ 6900.841372] b43-phy0: Controller restarted
>
> After installing the driver for the first time, I have a few minutes I
> can use the wifi card, after that the DMA errors start to occur. Once
> they occured after the first loading, they appear immediatly after
> each loading.
>
> Ubuntu 9.04 (most recent) with kernel 2.6.31-14-generic
>
> Laptop is Dell E6500.
> --
> 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
>
Does noacpi/noapic or blacklisting module "processor" have any effect on this?
Also, is this on PhoenixBIOS?
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
^ permalink raw reply
* Re: 2.6.32-rc5-git3: Reported regressions from 2.6.31
From: Michael Buesch @ 2009-11-01 15:28 UTC (permalink / raw)
To: Christian Casteyde; +Cc: John W. Linville, linux-wireless, Johannes Berg
In-Reply-To: <200910282138.37401.casteyde.christian@free.fr>
On Wednesday 28 October 2009 21:38:37 Christian Casteyde wrote:
> I've just tested the patch posted in bugzilla: it works.
> That is, I do not manage to get the warning anymore in 3 boots in a row.
Can you try this patch (on top of the previous one), please?
It should fix the issue correctly by removing the skb copying.
While testing make sure the debugging message
"Allocated bounce buffer"
shows up in the kernel log.
Index: wireless-testing/drivers/net/wireless/b43/dma.c
===================================================================
--- wireless-testing.orig/drivers/net/wireless/b43/dma.c 2009-11-01 15:10:48.000000000 +0100
+++ wireless-testing/drivers/net/wireless/b43/dma.c 2009-11-01 16:26:00.000000000 +0100
@@ -1157,18 +1157,17 @@ struct b43_dmaring *parse_cookie(struct
}
static int dma_tx_fragment(struct b43_dmaring *ring,
- struct sk_buff **in_skb)
+ struct sk_buff *skb)
{
- struct sk_buff *skb = *in_skb;
const struct b43_dma_ops *ops = ring->ops;
struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
+ struct b43_private_tx_info *priv_info = b43_get_priv_tx_info(info);
u8 *header;
int slot, old_top_slot, old_used_slots;
int err;
struct b43_dmadesc_generic *desc;
struct b43_dmadesc_meta *meta;
struct b43_dmadesc_meta *meta_hdr;
- struct sk_buff *bounce_skb;
u16 cookie;
size_t hdrsize = b43_txhdr_size(ring->dev);
@@ -1212,34 +1211,34 @@ static int dma_tx_fragment(struct b43_dm
meta->skb = skb;
meta->is_last_fragment = 1;
+ priv_info->bouncebuffer = NULL;
meta->dmaaddr = map_descbuffer(ring, skb->data, skb->len, 1);
/* create a bounce buffer in zone_dma on mapping failure. */
if (b43_dma_mapping_error(ring, meta->dmaaddr, skb->len, 1)) {
- bounce_skb = __dev_alloc_skb(skb->len, GFP_ATOMIC | GFP_DMA);
- if (!bounce_skb) {
+
+{
+static unsigned int count;
+if (count++ < 10)
+ printk(KERN_DEBUG "Allocated bounce buffer\n");
+}
+ priv_info->bouncebuffer = kmalloc(skb->len, GFP_ATOMIC | GFP_DMA);
+ if (!priv_info->bouncebuffer) {
ring->current_slot = old_top_slot;
ring->used_slots = old_used_slots;
err = -ENOMEM;
goto out_unmap_hdr;
}
+ memcpy(priv_info->bouncebuffer, skb->data, skb->len);
- memcpy(skb_put(bounce_skb, skb->len), skb->data, skb->len);
- memcpy(bounce_skb->cb, skb->cb, sizeof(skb->cb));
- bounce_skb->dev = skb->dev;
- skb_set_queue_mapping(bounce_skb, skb_get_queue_mapping(skb));
- info = IEEE80211_SKB_CB(bounce_skb);
-
- dev_kfree_skb_any(skb);
- skb = bounce_skb;
- *in_skb = bounce_skb;
- meta->skb = skb;
- meta->dmaaddr = map_descbuffer(ring, skb->data, skb->len, 1);
+ meta->dmaaddr = map_descbuffer(ring, priv_info->bouncebuffer, skb->len, 1);
if (b43_dma_mapping_error(ring, meta->dmaaddr, skb->len, 1)) {
+ kfree(priv_info->bouncebuffer);
+ priv_info->bouncebuffer = NULL;
ring->current_slot = old_top_slot;
ring->used_slots = old_used_slots;
err = -EIO;
- goto out_free_bounce;
+ goto out_unmap_hdr;
}
}
@@ -1256,8 +1255,6 @@ static int dma_tx_fragment(struct b43_dm
ops->poke_tx(ring, next_slot(ring, slot));
return 0;
-out_free_bounce:
- dev_kfree_skb_any(skb);
out_unmap_hdr:
unmap_descbuffer(ring, meta_hdr->dmaaddr,
hdrsize, 1);
@@ -1362,11 +1359,7 @@ int b43_dma_tx(struct b43_wldev *dev, st
* static, so we don't need to store it per frame. */
ring->queue_prio = skb_get_queue_mapping(skb);
- /* dma_tx_fragment might reallocate the skb, so invalidate pointers pointing
- * into the skb data or cb now. */
- hdr = NULL;
- info = NULL;
- err = dma_tx_fragment(ring, &skb);
+ err = dma_tx_fragment(ring, skb);
if (unlikely(err == -ENOKEY)) {
/* Drop this packet, as we don't have the encryption key
* anymore and must not transmit it unencrypted. */
@@ -1413,12 +1406,17 @@ void b43_dma_handle_txstatus(struct b43_
B43_WARN_ON(!(slot >= 0 && slot < ring->nr_slots));
desc = ops->idx2desc(ring, slot, &meta);
- if (meta->skb)
- unmap_descbuffer(ring, meta->dmaaddr, meta->skb->len,
- 1);
- else
+ if (meta->skb) {
+ struct b43_private_tx_info *priv_info =
+ b43_get_priv_tx_info(IEEE80211_SKB_CB(meta->skb));
+
+ unmap_descbuffer(ring, meta->dmaaddr, meta->skb->len, 1);
+ kfree(priv_info->bouncebuffer);
+ priv_info->bouncebuffer = NULL;
+ } else {
unmap_descbuffer(ring, meta->dmaaddr,
b43_txhdr_size(dev), 1);
+ }
if (meta->is_last_fragment) {
struct ieee80211_tx_info *info;
Index: wireless-testing/drivers/net/wireless/b43/xmit.h
===================================================================
--- wireless-testing.orig/drivers/net/wireless/b43/xmit.h 2009-10-09 19:50:15.000000000 +0200
+++ wireless-testing/drivers/net/wireless/b43/xmit.h 2009-11-01 16:05:46.000000000 +0100
@@ -2,6 +2,8 @@
#define B43_XMIT_H_
#include "main.h"
+#include <net/mac80211.h>
+
#define _b43_declare_plcp_hdr(size) \
struct b43_plcp_hdr##size { \
@@ -332,4 +334,21 @@ static inline u8 b43_kidx_to_raw(struct
return raw_kidx;
}
+/* struct b43_private_tx_info - TX info private to b43.
+ * The structure is placed in (struct ieee80211_tx_info *)->rate_driver_data
+ *
+ * @bouncebuffer: DMA Bouncebuffer (if used)
+ */
+struct b43_private_tx_info {
+ void *bouncebuffer;
+};
+
+static inline struct b43_private_tx_info *
+b43_get_priv_tx_info(struct ieee80211_tx_info *info)
+{
+ BUILD_BUG_ON(sizeof(struct b43_private_tx_info) >
+ sizeof(info->rate_driver_data));
+ return (struct b43_private_tx_info *)info->rate_driver_data;
+}
+
#endif /* B43_XMIT_H_ */
--
Greetings, Michael.
^ permalink raw reply
* Re: ath5k AP issues
From: Bob Copeland @ 2009-11-01 14:44 UTC (permalink / raw)
To: Nick Kossifidis
Cc: Michael Buesch, Johannes Berg, linux-wireless, Luis Rodriguez,
ath9k-devel
In-Reply-To: <40f31dec0911010541l650513fg31ffcadd12698f0@mail.gmail.com>
On Sun, Nov 01, 2009 at 03:41:49PM +0200, Nick Kossifidis wrote:
> So beacon-sent gated option doesn't work ?
> Did you try also AR5K_DCU_MISC_ARBLOCK_IGNORE ?
No, but I'll try that today.
> Also according to docs Beacon frames should use queue 9 and CAB should
> use queue 8 (don't know why but docs say that these are the
> appropriate DCUs), beacon-gated triggering might only work if we use
> DCU 9 for beacons (now we are using queue 7 for beacons and queue 6
> for cab).
Yeah, I read the same thing. The docs say 8 and 9 are highest priority
queues, it also says they both need to be DBA gated, but then on the
other hand it describes beacon-sent gated as precisely what we want,
and that queue 8 is "typically associated with beacon-gated frames."
I originally assumed the queue with AR5K_DCU_MISC_BCN_ENABLE is used
for triggering beacon sent but I'll try renumbering the queues and
see what happens.
Just copying ath9k list in case anyone with the inside scoop from Atheros
wants to chime in. :) The issue is queue settings for the CAB queue.
Beacon sent gating seems like a better option than using time throttled
DBA gating (with ready time for the next beacon interval). Ath9k is using
the latter, the former seems not to work at least in ath5k, or we're doing
it wrong.
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* Re: ath5k AP issues
From: Nick Kossifidis @ 2009-11-01 13:41 UTC (permalink / raw)
To: Bob Copeland
Cc: Michael Buesch, Johannes Berg, linux-wireless, Luis Rodriguez
In-Reply-To: <20091101131652.GA30381@hash.localnet>
2009/11/1 Bob Copeland <me@bobcopeland.com>:
> On Sun, Nov 01, 2009 at 08:53:44AM +0200, Nick Kossifidis wrote:
>> 2009/10/31 Bob Copeland <me@bobcopeland.com>:
>> notice the AR5K_QCU_RDYTIMECFG_ENABLE. So it's probable that the queue
>> starts on time and we miss sync because we wait an extra ready-time
>> period.
>
> Yeah, I know -- I turned it off before running tests. I don't
> think it ever ran the queue, or if it did it was very late.
>
So beacon-sent gated option doesn't work ?
Did you try also AR5K_DCU_MISC_ARBLOCK_IGNORE ?
Also according to docs Beacon frames should use queue 9 and CAB should
use queue 8 (don't know why but docs say that these are the
appropriate DCUs), beacon-gated triggering might only work if we use
DCU 9 for beacons (now we are using queue 7 for beacons and queue 6
for cab).
--
GPG ID: 0xD21DB2DB
As you read this post global entropy rises. Have Fun ;-)
Nick
^ permalink raw reply
* Re: ath5k AP issues
From: Bob Copeland @ 2009-11-01 13:16 UTC (permalink / raw)
To: Nick Kossifidis
Cc: Michael Buesch, Johannes Berg, linux-wireless, Luis Rodriguez
In-Reply-To: <40f31dec0910312353w32aede90ib5e71545ca744389@mail.gmail.com>
On Sun, Nov 01, 2009 at 08:53:44AM +0200, Nick Kossifidis wrote:
> 2009/10/31 Bob Copeland <me@bobcopeland.com>:
> notice the AR5K_QCU_RDYTIMECFG_ENABLE. So it's probable that the queue
> starts on time and we miss sync because we wait an extra ready-time
> period.
Yeah, I know -- I turned it off before running tests. I don't
think it ever ran the queue, or if it did it was very late.
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* b43 with 14e4 gives DMA error
From: Thomas Wiecki @ 2009-11-01 12:51 UTC (permalink / raw)
To: linux-wireless
0c:00.0 Network controller [0280]: Broadcom Corporation BCM4312
802.11b/g [14e4:4315] (rev 01)
Subsystem: Dell Device [1028:000c]
Flags: bus master, fast devsel, latency 0, IRQ 17
Memory at f1ffc000 (64-bit, non-prefetchable) [size=16K]
Capabilities: <access denied>
Kernel driver in use: wl
Kernel modules: wl, ssb
A variable delay after loading the most recent b43 driver I get a lot
of (I hope last nights patches would have fixed the problems, but they
didn't):
[ 6895.111946] b43-phy0 ERROR: Fatal DMA error: 0x00000800,
0x00000000, 0x00000000, 0x00000000, 0x00000000, 0x00000000
[ 6895.111955] b43-phy0: Controller RESET (DMA error) ...
[ 6895.336490] b43-phy0: Loading firmware version 478.104 (2008-07-01 00:50:23)
[ 6900.841372] b43-phy0: Controller restarted
After installing the driver for the first time, I have a few minutes I
can use the wifi card, after that the DMA errors start to occur. Once
they occured after the first loading, they appear immediatly after
each loading.
Ubuntu 9.04 (most recent) with kernel 2.6.31-14-generic
Laptop is Dell E6500.
^ permalink raw reply
* Re: ath5k AP issues
From: Michael Buesch @ 2009-11-01 10:34 UTC (permalink / raw)
To: Bob Copeland; +Cc: Johannes Berg, linux-wireless, Luis Rodriguez
In-Reply-To: <20091031202156.GA29825@hash.localnet>
On Saturday 31 October 2009 21:21:56 Bob Copeland wrote:
> On Thu, Oct 29, 2009 at 02:31:46PM +0100, Michael Buesch wrote:
> > Ok, to sum up some discussion from IRC:
> >
> > The initial packets that fail are not pings, but ARPs. Which are broadcast
> > frames. The access point simply fails to notify the station via DTIM for the
> > pending multicast frames, so it stays in PS. Unicast and the corresponding
> > TIM bitmap works properly, which also explains why it works once we got a
> > successful ARP (and it didn't expire, yet).
>
> I don't think this fixes everything (I'm still seeing some mishandled
> PS-poll frames) but this seemed to help pinging the PS client from the AP
> side.
Yeah this helps it a little bit.
It's able to get an ARP out and it's able to receive _some_ pongs now.
mb@homer:~$ ping 192.168.2.12 # ping the PS device
PING 192.168.2.12 (192.168.2.12) 56(84) bytes of data.
64 bytes from 192.168.2.12: icmp_seq=1 ttl=64 time=86.8 ms
64 bytes from 192.168.2.12: icmp_seq=2 ttl=64 time=4090 ms
64 bytes from 192.168.2.12: icmp_seq=3 ttl=64 time=3092 ms
64 bytes from 192.168.2.12: icmp_seq=4 ttl=64 time=2094 ms
64 bytes from 192.168.2.12: icmp_seq=5 ttl=64 time=1100 ms
64 bytes from 192.168.2.12: icmp_seq=6 ttl=64 time=101 ms
^C
--- 192.168.2.12 ping statistics ---
30 packets transmitted, 6 received, 80% packet loss, time 29002ms
rtt min/avg/max/mdev = 86.898/1760.979/4090.333/1489.080 ms, pipe 5
--
Greetings, Michael.
^ permalink raw reply
* [PATCH] mac80211_hwsim: Send ACK frames on the hwsim0 interface
From: Jouni Malinen @ 2009-11-01 9:31 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless
Report successful transmissions (receiver awake and on the same
channel) by generating ACK frames on the hwsim0 interface. This makes
it easier to figure out from packet capture logs whether frames were
delivered or not.
Signed-off-by: Jouni Malinen <j@w1.fi>
---
drivers/net/wireless/mac80211_hwsim.c | 47 ++++++++++++++++++++++++++++++++++
1 file changed, 47 insertions(+)
--- uml.orig/drivers/net/wireless/mac80211_hwsim.c 2009-10-01 17:22:15.000000000 +0300
+++ uml/drivers/net/wireless/mac80211_hwsim.c 2009-10-01 17:25:34.000000000 +0300
@@ -365,6 +365,49 @@ static void mac80211_hwsim_monitor_rx(st
}
+static void mac80211_hwsim_monitor_ack(struct ieee80211_hw *hw, const u8 *addr)
+{
+ struct mac80211_hwsim_data *data = hw->priv;
+ struct sk_buff *skb;
+ struct hwsim_radiotap_hdr *hdr;
+ u16 flags;
+ struct ieee80211_hdr *hdr11;
+
+ if (!netif_running(hwsim_mon))
+ return;
+
+ skb = dev_alloc_skb(100);
+ if (skb == NULL)
+ return;
+
+ hdr = (struct hwsim_radiotap_hdr *) skb_put(skb, sizeof(*hdr));
+ hdr->hdr.it_version = PKTHDR_RADIOTAP_VERSION;
+ hdr->hdr.it_pad = 0;
+ hdr->hdr.it_len = cpu_to_le16(sizeof(*hdr));
+ hdr->hdr.it_present = cpu_to_le32((1 << IEEE80211_RADIOTAP_FLAGS) |
+ (1 << IEEE80211_RADIOTAP_CHANNEL));
+ hdr->rt_flags = 0;
+ hdr->rt_rate = 0;
+ hdr->rt_channel = cpu_to_le16(data->channel->center_freq);
+ flags = IEEE80211_CHAN_2GHZ;
+ hdr->rt_chbitmask = cpu_to_le16(flags);
+
+ hdr11 = (struct ieee80211_hdr *) skb_put(skb, 10);
+ hdr11->frame_control = cpu_to_le16(IEEE80211_FTYPE_CTL |
+ IEEE80211_STYPE_ACK);
+ hdr11->duration_id = cpu_to_le16(0);
+ memcpy(hdr11->addr1, addr, ETH_ALEN);
+
+ skb->dev = hwsim_mon;
+ skb_set_mac_header(skb, 0);
+ skb->ip_summed = CHECKSUM_UNNECESSARY;
+ skb->pkt_type = PACKET_OTHERHOST;
+ skb->protocol = htons(ETH_P_802_2);
+ memset(skb->cb, 0, sizeof(skb->cb));
+ netif_rx(skb);
+}
+
+
static bool hwsim_ps_rx_ok(struct mac80211_hwsim_data *data,
struct sk_buff *skb)
{
@@ -471,6 +514,10 @@ static int mac80211_hwsim_tx(struct ieee
}
ack = mac80211_hwsim_tx_frame(hw, skb);
+ if (ack && skb->len >= 16) {
+ struct ieee80211_hdr *hdr = (struct ieee80211_hdr *) skb->data;
+ mac80211_hwsim_monitor_ack(hw, hdr->addr2);
+ }
txi = IEEE80211_SKB_CB(skb);
--
Jouni Malinen PGP id EFC895FA
^ permalink raw reply
* [PATCH] mac80211_hwsim: Check idle state on TX
From: Jouni Malinen @ 2009-11-01 9:30 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless
Track the idle state for hwsim radios and reject TX if mac80211 is
trying to transmit something when the radio is supposed to be idle. In
addition, do not deliver frames if the receiving radio is in the idle
state.
Signed-off-by: Jouni Malinen <j@w1.fi>
---
drivers/net/wireless/mac80211_hwsim.c | 13 +++++++++++--
1 file changed, 11 insertions(+), 2 deletions(-)
--- uml.orig/drivers/net/wireless/mac80211_hwsim.c 2009-10-01 17:06:49.000000000 +0300
+++ uml/drivers/net/wireless/mac80211_hwsim.c 2009-10-01 17:22:15.000000000 +0300
@@ -284,7 +284,7 @@ struct mac80211_hwsim_data {
struct ieee80211_channel *channel;
unsigned long beacon_int; /* in jiffies unit */
unsigned int rx_filter;
- int started;
+ bool started, idle;
struct timer_list beacon_timer;
enum ps_mode {
PS_DISABLED, PS_ENABLED, PS_AUTO_POLL, PS_MANUAL_POLL
@@ -402,6 +402,12 @@ static bool mac80211_hwsim_tx_frame(stru
struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
struct ieee80211_rx_status rx_status;
+ if (data->idle) {
+ printk(KERN_DEBUG "%s: Trying to TX when idle - reject\n",
+ wiphy_name(hw->wiphy));
+ return false;
+ }
+
memset(&rx_status, 0, sizeof(rx_status));
/* TODO: set mactime */
rx_status.freq = data->channel->center_freq;
@@ -428,7 +434,8 @@ static bool mac80211_hwsim_tx_frame(stru
if (data == data2)
continue;
- if (!data2->started || !hwsim_ps_rx_ok(data2, skb) ||
+ if (data2->idle || !data2->started ||
+ !hwsim_ps_rx_ok(data2, skb) ||
!data->channel || !data2->channel ||
data->channel->center_freq != data2->channel->center_freq ||
!(data->group & data2->group))
@@ -571,6 +578,8 @@ static int mac80211_hwsim_config(struct
!!(conf->flags & IEEE80211_CONF_IDLE),
!!(conf->flags & IEEE80211_CONF_PS));
+ data->idle = !!(conf->flags & IEEE80211_CONF_IDLE);
+
data->channel = conf->channel;
if (!data->started || !data->beacon_int)
del_timer(&data->beacon_timer);
--
Jouni Malinen PGP id EFC895FA
^ permalink raw reply
* [PATCH] cfg80211: Fix WEXT compat siwauth wpa and group cipher
From: Jouni Malinen @ 2009-11-01 9:18 UTC (permalink / raw)
To: John W. Linville, Johannes Berg; +Cc: linux-wireless
Neither of these commands should clear the current configuration value
if they return error. Furthermore, cfg80211_set_cipher_group() should
be able to handle IW_AUTH_CIPHER_NONE without reporting error.
Signed-off-by: Jouni Malinen <j@w1.fi>
---
net/wireless/wext-compat.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
--- uml.orig/net/wireless/wext-compat.c 2009-11-01 10:54:56.000000000 +0200
+++ uml/net/wireless/wext-compat.c 2009-11-01 10:58:45.000000000 +0200
@@ -904,8 +904,6 @@ static int cfg80211_set_auth_alg(struct
static int cfg80211_set_wpa_version(struct wireless_dev *wdev, u32 wpa_versions)
{
- wdev->wext.connect.crypto.wpa_versions = 0;
-
if (wpa_versions & ~(IW_AUTH_WPA_VERSION_WPA |
IW_AUTH_WPA_VERSION_WPA2|
IW_AUTH_WPA_VERSION_DISABLED))
@@ -933,8 +931,6 @@ static int cfg80211_set_wpa_version(stru
static int cfg80211_set_cipher_group(struct wireless_dev *wdev, u32 cipher)
{
- wdev->wext.connect.crypto.cipher_group = 0;
-
if (cipher & IW_AUTH_CIPHER_WEP40)
wdev->wext.connect.crypto.cipher_group =
WLAN_CIPHER_SUITE_WEP40;
@@ -950,6 +946,8 @@ static int cfg80211_set_cipher_group(str
else if (cipher & IW_AUTH_CIPHER_AES_CMAC)
wdev->wext.connect.crypto.cipher_group =
WLAN_CIPHER_SUITE_AES_CMAC;
+ else if (cipher & IW_AUTH_CIPHER_NONE)
+ wdev->wext.connect.crypto.cipher_group = 0;
else
return -EINVAL;
--
Jouni Malinen PGP id EFC895FA
^ permalink raw reply
* Re: ath5k AP issues
From: Nick Kossifidis @ 2009-11-01 6:56 UTC (permalink / raw)
To: Bob Copeland
Cc: Michael Buesch, Johannes Berg, linux-wireless, Luis Rodriguez
In-Reply-To: <40f31dec0910312353w32aede90ib5e71545ca744389@mail.gmail.com>
2009/11/1 Nick Kossifidis <mickflemm@gmail.com>:
> 2009/10/31 Bob Copeland <me@bobcopeland.com>:
>> On Thu, Oct 29, 2009 at 02:31:46PM +0100, Michael Buesch wrote:
>>> Ok, to sum up some discussion from IRC:
>>>
>>> The initial packets that fail are not pings, but ARPs. Which are broadcast
>>> frames. The access point simply fails to notify the station via DTIM for the
>>> pending multicast frames, so it stays in PS. Unicast and the corresponding
>>> TIM bitmap works properly, which also explains why it works once we got a
>>> successful ARP (and it didn't expire, yet).
>>
>> I don't think this fixes everything (I'm still seeing some mishandled
>> PS-poll frames) but this seemed to help pinging the PS client from the AP
>> side.
>>
>> [Although we agreed beacon-sent-gated without a ready time component
>> is the right way to go on the queue configuration, it seems badly
>> broken in practice unless I'm missing some enable bit somewhere. So
>> this is what ath9k does.]
>>
>
> Well ready time is not disabled right now !
>
> 416 ath5k_hw_reg_write(ah, ((AR5K_TUNE_BEACON_INTERVAL -
> 417 (AR5K_TUNE_SW_BEACON_RESP -
> 418 AR5K_TUNE_DMA_BEACON_RESP) -
> 419 AR5K_TUNE_ADDITIONAL_SWBA_BACKOFF) * 1024) |
> 420 AR5K_QCU_RDYTIMECFG_ENABLE,
> 421 AR5K_QUEUE_RDYTIMECFG(queue));
>
> notice the AR5K_QCU_RDYTIMECFG_ENABLE. So it's probable that the queue
> starts on time and we miss sync because we wait an extra ready-time
> period.
>
Also i think we must use AR5K_DCU_MISC_ARBLOCK_IGNORE as we do for
beacon frames so that CAB queue gets on top no matter what queues are
pending (it already has the AR5K_DCU_MISC_ARBLOCK_CTL_GLOBAL).
--
GPG ID: 0xD21DB2DB
As you read this post global entropy rises. Have Fun ;-)
Nick
^ permalink raw reply
* Re: ath5k AP issues
From: Nick Kossifidis @ 2009-11-01 6:53 UTC (permalink / raw)
To: Bob Copeland
Cc: Michael Buesch, Johannes Berg, linux-wireless, Luis Rodriguez
In-Reply-To: <20091031202156.GA29825@hash.localnet>
2009/10/31 Bob Copeland <me@bobcopeland.com>:
> On Thu, Oct 29, 2009 at 02:31:46PM +0100, Michael Buesch wrote:
>> Ok, to sum up some discussion from IRC:
>>
>> The initial packets that fail are not pings, but ARPs. Which are broadcast
>> frames. The access point simply fails to notify the station via DTIM for the
>> pending multicast frames, so it stays in PS. Unicast and the corresponding
>> TIM bitmap works properly, which also explains why it works once we got a
>> successful ARP (and it didn't expire, yet).
>
> I don't think this fixes everything (I'm still seeing some mishandled
> PS-poll frames) but this seemed to help pinging the PS client from the AP
> side.
>
> [Although we agreed beacon-sent-gated without a ready time component
> is the right way to go on the queue configuration, it seems badly
> broken in practice unless I'm missing some enable bit somewhere. So
> this is what ath9k does.]
>
Well ready time is not disabled right now !
416 ath5k_hw_reg_write(ah, ((AR5K_TUNE_BEACON_INTERVAL -
417 (AR5K_TUNE_SW_BEACON_RESP -
418 AR5K_TUNE_DMA_BEACON_RESP) -
419 AR5K_TUNE_ADDITIONAL_SWBA_BACKOFF) * 1024) |
420 AR5K_QCU_RDYTIMECFG_ENABLE,
421 AR5K_QUEUE_RDYTIMECFG(queue));
notice the AR5K_QCU_RDYTIMECFG_ENABLE. So it's probable that the queue
starts on time and we miss sync because we wait an extra ready-time
period.
--
GPG ID: 0xD21DB2DB
As you read this post global entropy rises. Have Fun ;-)
Nick
^ permalink raw reply
* [PATCH] p54: disable channels with incomplete calibration data sets
From: Christian Lamparter @ 2009-10-31 21:59 UTC (permalink / raw)
To: linux-wireless; +Cc: linville, James Grossmann, Larry Finger
James Grossmann [1] reported that p54 spews out confusing
messages instead of preventing the mayhem from happening.
the reason is that "p54: generate channel list dynamically"
is not perfect. It didn't discard incomplete channel data
sets and therefore p54 advertised to support them as well.
[1]: http://marc.info/?l=linux-wireless&m=125699830215890
Cc: Larry Finger <Larry.Finger@lwfinger.net>
Reported-by: James Grossmann <cctsurf@gmail.com>
Signed-off-by: Christian Lamparter <chunkeey@web.de>
---
this patch just removes the pointless verboseness.
I'm afraid, it doesn't fix any regressions,
include workarounds for damaged hardware, add support
for an unknown, unsupported eeprom layout or do
any other magic stuff.
---
diff --git a/drivers/net/wireless/p54/eeprom.c b/drivers/net/wireless/p54/eeprom.c
index 0efe67d..8e3818f 100644
--- a/drivers/net/wireless/p54/eeprom.c
+++ b/drivers/net/wireless/p54/eeprom.c
@@ -126,7 +126,7 @@ static int p54_generate_band(struct ieee80211_hw *dev,
int ret = -ENOMEM;
if ((!list->entries) || (!list->band_channel_num[band]))
- return 0;
+ return -EINVAL;
tmp = kzalloc(sizeof(*tmp), GFP_KERNEL);
if (!tmp)
@@ -158,6 +158,7 @@ static int p54_generate_band(struct ieee80211_hw *dev,
(list->channels[i].data & CHAN_HAS_CURVE ? "" :
" [curve data]"),
list->channels[i].index, list->channels[i].freq);
+ continue;
}
tmp->channels[j].band = list->channels[i].band;
@@ -165,7 +166,16 @@ static int p54_generate_band(struct ieee80211_hw *dev,
j++;
}
- tmp->n_channels = list->band_channel_num[band];
+ if (j == 0) {
+ printk(KERN_ERR "%s: Disabling totally damaged %s band.\n",
+ wiphy_name(dev->wiphy), (band == IEEE80211_BAND_2GHZ) ?
+ "2 GHz" : "5 GHz");
+
+ ret = -ENODATA;
+ goto err_out;
+ }
+
+ tmp->n_channels = j;
old = priv->band_table[band];
priv->band_table[band] = tmp;
if (old) {
@@ -228,13 +238,13 @@ static int p54_generate_channel_lists(struct ieee80211_hw *dev)
struct p54_common *priv = dev->priv;
struct p54_channel_list *list;
unsigned int i, j, max_channel_num;
- int ret = -ENOMEM;
+ int ret = 0;
u16 freq;
if ((priv->iq_autocal_len != priv->curve_data->entries) ||
(priv->iq_autocal_len != priv->output_limit->entries))
- printk(KERN_ERR "%s: EEPROM is damaged... you may not be able"
- "to use all channels with this device.\n",
+ printk(KERN_ERR "%s: Unsupported or damaged EEPROM detected. "
+ "You may not be able to use all channels.\n",
wiphy_name(dev->wiphy));
max_channel_num = max_t(unsigned int, priv->output_limit->entries,
@@ -243,8 +253,10 @@ static int p54_generate_channel_lists(struct ieee80211_hw *dev)
priv->curve_data->entries);
list = kzalloc(sizeof(*list), GFP_KERNEL);
- if (!list)
+ if (!list) {
+ ret = -ENOMEM;
goto free;
+ }
list->max_entries = max_channel_num;
list->channels = kzalloc(sizeof(struct p54_channel_entry) *
@@ -282,13 +294,8 @@ static int p54_generate_channel_lists(struct ieee80211_hw *dev)
p54_compare_channels, NULL);
for (i = 0, j = 0; i < IEEE80211_NUM_BANDS; i++) {
- if (list->band_channel_num[i]) {
- ret = p54_generate_band(dev, list, i);
- if (ret)
- goto free;
-
+ if (p54_generate_band(dev, list, i) == 0)
j++;
- }
}
if (j == 0) {
/* no useable band available. */
^ permalink raw reply related
* Re: Prism54/p54pci
From: Christian Lamparter @ 2009-10-31 21:24 UTC (permalink / raw)
To: James Grossmann
Cc: Luis R. Rodriguez, linux-wireless, John W. Linville, Larry Finger,
Christian Lamparter
In-Reply-To: <167ae39b0910310711r1552b82ej81f894e5a565f3cc@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3950 bytes --]
On Saturday 31 October 2009 15:11:37 James Grossmann wrote:
> [ 4200.794299] cfg80211: Calling CRDA to update world regulatory
> domain
> [ 4200.857330] p54pci 0000:03:00.0: PCI INT A -> Link[LNKA] -> GSI 11
> (level, low) -> IRQ 11
> [ 4200.857408] p54pci 0000:03:00.0: firmware: requesting isl3886pci
> [ 4201.432596] phy0: p54 detected a LM86 firmware
> [ 4201.432604] p54: rx_mtu reduced from 3240 to 2376
> [ 4201.432610] phy0: FW rev 2.13.12.0 - Softmac protocol 5.9
> [ 4201.432616] phy0: cryptographic accelerator WEP:YES, TKIP:YES,
> CCMP:YES
> [ 4202.293254] phy0: EEPROM is damaged... you may not be able to use
> all channels with this device.
^^^ = that's the culprit.
do you think, you can get this EEPROM dump?
Just move the attach _patch_ into your compat-wireless' main directory.
Afterward, you have to execute:
patch -p1 < p54-dump-eeprom-to-dmesg.diff
and rebuild & reload the driver and retrieve the data
from dmesg.
> [ 4202.293286] phy0: [iqauto calibration data] is/are missing for
> channel:2 [2417 MHz].
> [ 4202.293293] phy0: [iqauto calibration data] is/are missing for
> channel:3 [2422 MHz].
> [ 4202.293300] phy0: [iqauto calibration data] is/are missing for
> channel:4 [2427 MHz].
> [ 4202.293306] phy0: [iqauto calibration data] is/are missing for
> channel:5 [2432 MHz].
> [ 4202.293313] phy0: [iqauto calibration data] is/are missing for
> channel:6 [2437 MHz].
> [ 4202.293320] phy0: [iqauto calibration data] is/are missing for
> channel:8 [2447 MHz].
> [ 4202.293326] phy0: [iqauto calibration data] is/are missing for
> channel:9 [2452 MHz].
> [ 4202.293333] phy0: [iqauto calibration data] is/are missing for
> channel:10 [2457 MHz].
> [ 4202.293340] phy0: [iqauto calibration data] is/are missing for
> channel:11 [2462 MHz].
> [ 4202.293346] phy0: [iqauto calibration data] is/are missing for
> channel:12 [2467 MHz].
> [ 4202.293356] phy0: hwaddr 00:xx:xx:xx:xx:xx, MAC:isl3880 RF:Frisbee
> [ 4202.293787] phy0: Selected rate control algorithm 'minstrel'
> [ 4202.295616] Registered led device: p54-phy0::assoc
> [ 4202.295657] Registered led device: p54-phy0::tx
> [ 4202.295703] Registered led device: p54-phy0::rx
> [ 4202.295744] Registered led device: p54-phy0::radio
> [ 4202.295758] p54pci 0000:03:00.0: is registered as 'phy0'
> [ 4202.378618] udev: renamed network interface wlan0 to wlan1
> [ 4202.509483] ADDRCONF(NETDEV_UP): wlan1: link is not ready
> [ 4202.724125] phy0: frequency change to channel 2 failed.
> [ 4202.724138] phy0: frequency change to channel 3 failed.
> [ 4202.724145] phy0: frequency change to channel 4 failed.
> [ 4202.724151] phy0: frequency change to channel 5 failed.
> [ 4202.724157] phy0: frequency change to channel 6 failed.
> [ 4202.780179] phy0: frequency change to channel 8 failed.
> [ 4202.780193] phy0: frequency change to channel 9 failed.
> [ 4202.780199] phy0: frequency change to channel 10 failed.
> [ 4202.780206] phy0: frequency change to channel 11 failed.
> [ 4202.780212] phy0: frequency change to channel 12 failed.
> [ 4208.212168] phy0: frequency change to channel 2 failed.
> [ 4208.212180] phy0: frequency change to channel 3 failed.
> [ 4208.212187] phy0: frequency change to channel 4 failed.
> [ 4208.212193] phy0: frequency change to channel 5 failed.
> [ 4208.212199] phy0: frequency change to channel 6 failed.
> [ 4208.276097] phy0: frequency change to channel 8 failed.
> [ 4208.276112] phy0: frequency change to channel 9 failed.
> [ 4208.276119] phy0: frequency change to channel 10 failed.
> [ 4208.276125] phy0: frequency change to channel 11 failed.
> [ 4208.276132] phy0: frequency change to channel 12 failed.
> [ 4208.524788] phy0: frequency change to channel 6 failed.
> [ 4208.524949] wlan1: deauthenticating from 00:xx:xx:xx:xx:xx by local
> choice (reason=3)
> [ 4208.525084] wlan1: direct probe to AP 00:xx:xx:xx:xx:xx (try 1)
> [ 4208.724191] wlan1: direct probe to AP 00:xx:xx:xx:xx:xx (try 2)
[...]
Regards,
Chr
[-- Attachment #2: p54-dump-eeprom-to-dmesg.diff --]
[-- Type: text/x-patch, Size: 598 bytes --]
diff --git a/drivers/net/wireless/p54/eeprom.c b/drivers/net/wireless/p54/eeprom.c
index 8dfe815..7504588 100644
--- a/drivers/net/wireless/p54/eeprom.c
+++ b/drivers/net/wireless/p54/eeprom.c
@@ -540,6 +540,8 @@ int p54_parse_eeprom(struct ieee80211_hw *dev, void *eeprom, int len)
wrap = (struct eeprom_pda_wrap *) eeprom;
entry = (void *)wrap->data + le16_to_cpu(wrap->len);
+ print_hex_dump_bytes("EEPROM:", DUMP_PREFIX_OFFSET, eeprom, len);
+
/* verify that at least the entry length/code fits */
while ((u8 *)entry <= end - sizeof(*entry)) {
entry_len = le16_to_cpu(entry->len);
^ permalink raw reply related
* Re: ath5k AP issues
From: Bob Copeland @ 2009-10-31 20:21 UTC (permalink / raw)
To: Michael Buesch; +Cc: Johannes Berg, linux-wireless, Luis Rodriguez
In-Reply-To: <200910291431.48388.mb@bu3sch.de>
On Thu, Oct 29, 2009 at 02:31:46PM +0100, Michael Buesch wrote:
> Ok, to sum up some discussion from IRC:
>
> The initial packets that fail are not pings, but ARPs. Which are broadcast
> frames. The access point simply fails to notify the station via DTIM for the
> pending multicast frames, so it stays in PS. Unicast and the corresponding
> TIM bitmap works properly, which also explains why it works once we got a
> successful ARP (and it didn't expire, yet).
I don't think this fixes everything (I'm still seeing some mishandled
PS-poll frames) but this seemed to help pinging the PS client from the AP
side.
[Although we agreed beacon-sent-gated without a ready time component
is the right way to go on the queue configuration, it seems badly
broken in practice unless I'm missing some enable bit somewhere. So
this is what ath9k does.]
diff --git a/drivers/net/wireless/ath/ath5k/ath5k.h b/drivers/net/wireless/ath/ath5k/ath5k.h
index 1c90d6b..6c167c2 100644
--- a/drivers/net/wireless/ath/ath5k/ath5k.h
+++ b/drivers/net/wireless/ath/ath5k/ath5k.h
@@ -541,7 +541,7 @@ struct ath5k_txq_info {
u32 tqi_cbr_period; /* Constant bit rate period */
u32 tqi_cbr_overflow_limit;
u32 tqi_burst_time;
- u32 tqi_ready_time; /* Not used */
+ u32 tqi_ready_time; /* Time queue waits after an event */
};
/*
diff --git a/drivers/net/wireless/ath/ath5k/base.c b/drivers/net/wireless/ath/ath5k/base.c
index 9c6ab53..01b6fc3 100644
--- a/drivers/net/wireless/ath/ath5k/base.c
+++ b/drivers/net/wireless/ath/ath5k/base.c
@@ -1488,7 +1488,8 @@ ath5k_beaconq_config(struct ath5k_softc *sc)
ret = ath5k_hw_get_tx_queueprops(ah, sc->bhalq, &qi);
if (ret)
- return ret;
+ goto err;
+
if (sc->opmode == NL80211_IFTYPE_AP ||
sc->opmode == NL80211_IFTYPE_MESH_POINT) {
/*
@@ -1515,10 +1516,28 @@ ath5k_beaconq_config(struct ath5k_softc *sc)
if (ret) {
ATH5K_ERR(sc, "%s: unable to update parameters for beacon "
"hardware queue!\n", __func__);
- return ret;
+ goto err;
}
+ ret = ath5k_hw_reset_tx_queue(ah, sc->bhalq); /* push to h/w */
+ if (ret)
+ goto err;
- return ath5k_hw_reset_tx_queue(ah, sc->bhalq); /* push to h/w */;
+ /* reconfigure cabq with ready time to 80% of beacon_interval */
+ ret = ath5k_hw_get_tx_queueprops(ah, AR5K_TX_QUEUE_ID_CAB, &qi);
+ if (ret)
+ goto err;
+
+ qi.tqi_aifs = 0;
+ qi.tqi_cw_min = 0;
+ qi.tqi_cw_max = 0;
+ qi.tqi_ready_time = (sc->bintval * 80) / 100;
+ ret = ath5k_hw_set_tx_queueprops(ah, AR5K_TX_QUEUE_ID_CAB, &qi);
+ if (ret)
+ goto err;
+
+ ret = ath5k_hw_reset_tx_queue(ah, AR5K_TX_QUEUE_ID_CAB);
+err:
+ return ret;
}
static void
diff --git a/drivers/net/wireless/ath/ath5k/qcu.c b/drivers/net/wireless/ath/ath5k/qcu.c
index eeebb9a..31a4241 100644
--- a/drivers/net/wireless/ath/ath5k/qcu.c
+++ b/drivers/net/wireless/ath/ath5k/qcu.c
@@ -409,11 +409,11 @@ int ath5k_hw_reset_tx_queue(struct ath5k_hw *ah, unsigned int queue)
case AR5K_TX_QUEUE_CAB:
AR5K_REG_ENABLE_BITS(ah, AR5K_QUEUE_MISC(queue),
- AR5K_QCU_MISC_FRSHED_BCN_SENT_GT |
+ AR5K_QCU_MISC_FRSHED_DBA_GT |
AR5K_QCU_MISC_CBREXP_DIS |
AR5K_QCU_MISC_CBREXP_BCN_DIS);
- ath5k_hw_reg_write(ah, ((AR5K_TUNE_BEACON_INTERVAL -
+ ath5k_hw_reg_write(ah, ((tq->tqi_ready_time -
(AR5K_TUNE_SW_BEACON_RESP -
AR5K_TUNE_DMA_BEACON_RESP) -
AR5K_TUNE_ADDITIONAL_SWBA_BACKOFF) * 1024) |
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply related
* Re: [PATCH 14/15] iwlwifi: add SM PS support for 6x50 series
From: Johannes Berg @ 2009-10-31 19:23 UTC (permalink / raw)
To: Guy, Wey-Yi
Cc: Chatre, Reinette, linville@tuxdriver.com,
linux-wireless@vger.kernel.org,
ipw3945-devel@lists.sourceforge.net
In-Reply-To: <1257011058.8387.14.camel@wwguy-ubuntu>
[-- Attachment #1: Type: text/plain, Size: 1279 bytes --]
On Sat, 2009-10-31 at 10:44 -0700, Guy, Wey-Yi wrote:
> > > ht_info->cap |= IEEE80211_HT_CAP_SGI_20;
> > > - ht_info->cap |= (IEEE80211_HT_CAP_SM_PS &
> > > - (WLAN_HT_CAP_SM_PS_DISABLED << 2));
> > > + if (priv->cfg->support_sm_ps)
> > > + ht_info->cap |= (IEEE80211_HT_CAP_SM_PS &
> > > + (WLAN_HT_CAP_SM_PS_DYNAMIC << 2));
> > > + else
> > > + ht_info->cap |= (IEEE80211_HT_CAP_SM_PS &
> > > + (WLAN_HT_CAP_SM_PS_DISABLED << 2));
> >
> > here we always and unconditionally advertise dynamic SM-PS mode?
>
> I am confuse, it is based on "priv->cfg->support_sm_ps", so it is not
> always dynamic SM-PS mode.
Right, sorry -- but here it _only_ depends on "support_sm_ps", whereas
> > > + if (priv->cfg->support_sm_ps) {
> > > + /* # Rx chains when idling and maybe trying to save power */
> > > + switch (priv->current_ht_config.sm_ps) {
Here it also depends on current_ht_config.sm_ps, which is not very
useful. Using the AP setting is wrong, and above, assuming
"support_sm_ps" [1] is true, this should just always fall into the
dynamic case so the value "current_ht_config.sm_ps" isn't useful and can
imho be removed.
johannes
[1] which btw I'd have called "use_sm_ps" since all hardware supports it
afaik
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* ath9k based AP stops responding after half a day or so
From: Rob Browning @ 2009-10-31 18:40 UTC (permalink / raw)
To: linux-wireless
I have an machine that's running a recent compat-wireless (2009-10-17),
kernel 2.6.30-2-686 (Debian), and a build of hostapd as of 2009-10-17
(08d38568). The machine also has an AR5008 (ath9k) based PCI card.
After the machine reboots, wireless clients can connect to the AP
normally for a half day or so. Then, at some point, all connections
fail, and clients cannot even see the network until the machine is
rebooted. Reloading the wireless modules, and restarting hostapd
doesn't help.
Once the network has disappeared, if I restart hostapd with -dd, it gets
to this point:
WPA: group state machine entering state GTK_INIT (VLAN-ID 0)
GMK - hexdump(len=32): [REMOVED]
GTK - hexdump(len=32): [REMOVED]
WPA: group state machine entering state SETKEYSDONE (VLAN-ID 0)
nl_set_encr: ifindex=5 alg=2 addr=(nil) key_idx=1 set_tx=1 seq_len=0 key_len=32
nl80211: Set beacon (beacon_set=0)
wlan0: Setup of interface done.
MGMT (TX callback) ACK
and then pauses for a long time. Eventually it prints this:
wlan0: WPA rekeying GTK
WPA: group state machine entering state SETKEYS (VLAN-ID 0)
GMK - hexdump(len=32): [REMOVED]
GTK - hexdump(len=32): [REMOVED]
wpa_group_setkeys: GKeyDoneStations=0
WPA: group state machine entering state SETKEYSDONE (VLAN-ID 0)
nl_set_encr: ifindex=5 alg=2 addr=(nil) key_idx=2 set_tx=1 seq_len=0 key_len=32
wlan0: WPA rekeying GTK
but clients still won't be able to connect until I reboot the machine.
If it helps, once the AP stopped responding, I reloaded the ath9k
modules with debugging enabled (modprobe ath9k debug=0xffffffff) and
found that while the machine in this state it prints something like this
to the log repeatedly:
10:50:06 kernel: [230631.480019] ath: Writing ofdmbase=12582412 cckbase=12582712
10:50:07 kernel: [230632.080018] ath: Writing ofdmbase=12582412 cckbase=12582712
10:50:08 kernel: [230632.680020] ath: ANI parameters:
10:50:08 kernel: [230632.680024] ath: noiseImmunityLevel=0, spurImmunityLevel=1, ofdmWeakSigDetectOff=1
10:50:08 kernel: [230632.680029] ath: cckWeakSigThreshold=0, firstepLevel=0, listenTime=551
10:50:08 kernel: [230632.680032] ath: cycleCount=-1758147678, ofdmPhyErrCount=99, cckPhyErrCount=1
10:50:08 kernel: [230632.680035]
10:50:08 kernel: [230632.680037] ath: Writing ofdmbase=12582412 cckbase=12582712
10:50:08 kernel: [230632.880017] ath: invalid cmd 2
10:50:08 kernel: [230632.880023] ath: ANI parameters:
10:50:08 kernel: [230632.880025] ath: noiseImmunityLevel=0, spurImmunityLevel=2, ofdmWeakSigDetectOff=1
10:50:08 kernel: [230632.880029] ath: cckWeakSigThreshold=0, firstepLevel=0, listenTime=188
10:50:08 kernel: [230632.880032] ath: cycleCount=-1749347644, ofdmPhyErrCount=107, cckPhyErrCount=0
10:50:08 kernel: [230632.880035]
10:50:08 kernel: [230632.880037] ath: Writing ofdmbase=12582412 cckbase=12582712
10:50:08 kernel: [230633.480017] ath: Writing ofdmbase=12582412 cckbase=12582712
10:50:09 kernel: [230634.080018] ath: Writing ofdmbase=12582412 cckbase=12582712
Assuming this isn't a local configuration problem, I'd like to help fix
it if I can. In case it matters, the machine in question is running a
firewall (shorewall).
Please let me know if I can provide further information.
Thanks
--
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
^ permalink raw reply
* Re: [PATCH 14/15] iwlwifi: add SM PS support for 6x50 series
From: Guy, Wey-Yi @ 2009-10-31 17:44 UTC (permalink / raw)
To: Johannes Berg
Cc: Chatre, Reinette, linville@tuxdriver.com,
linux-wireless@vger.kernel.org,
ipw3945-devel@lists.sourceforge.net
In-Reply-To: <1256968411.3555.77.camel@johannes.local>
On Fri, 2009-10-30 at 22:53 -0700, Johannes Berg wrote:
> Hi,
>
> > @@ -3012,6 +3012,10 @@ static int iwl_init_drv(struct iwl_priv *priv)
> > priv->band = IEEE80211_BAND_2GHZ;
> >
> > priv->iw_mode = NL80211_IFTYPE_STATION;
> > + if (priv->cfg->support_sm_ps)
> > + priv->current_ht_config.sm_ps = WLAN_HT_CAP_SM_PS_DYNAMIC;
> > + else
> > + priv->current_ht_config.sm_ps = WLAN_HT_CAP_SM_PS_DISABLED;
>
> Why bother with current_ht_config.sm_ps when ...
This is for keep the ht configuration in single place.
>
> > ht_info->cap |= IEEE80211_HT_CAP_SGI_20;
> > - ht_info->cap |= (IEEE80211_HT_CAP_SM_PS &
> > - (WLAN_HT_CAP_SM_PS_DISABLED << 2));
> > + if (priv->cfg->support_sm_ps)
> > + ht_info->cap |= (IEEE80211_HT_CAP_SM_PS &
> > + (WLAN_HT_CAP_SM_PS_DYNAMIC << 2));
> > + else
> > + ht_info->cap |= (IEEE80211_HT_CAP_SM_PS &
> > + (WLAN_HT_CAP_SM_PS_DISABLED << 2));
>
> here we always and unconditionally advertise dynamic SM-PS mode?
I am confuse, it is based on "priv->cfg->support_sm_ps", so it is not
always dynamic SM-PS mode.
>
> > + if (priv->cfg->support_sm_ps) {
> > + /* # Rx chains when idling and maybe trying to save power */
> > + switch (priv->current_ht_config.sm_ps) {
> > + case WLAN_HT_CAP_SM_PS_STATIC:
> > + case WLAN_HT_CAP_SM_PS_DYNAMIC:
> > + idle_cnt = (is_cam) ? IWL_NUM_IDLE_CHAINS_DUAL :
> > + IWL_NUM_IDLE_CHAINS_SINGLE;
> > + break;
> > + case WLAN_HT_CAP_SM_PS_DISABLED:
> > + idle_cnt = (is_cam) ? active_cnt :
> > + IWL_NUM_IDLE_CHAINS_SINGLE;
> > + break;
> > + case WLAN_HT_CAP_SM_PS_INVALID:
> > + default:
> > + IWL_ERR(priv, "invalid sm_ps mode %d\n",
> > + priv->current_ht_config.sm_ps);
> > + WARN_ON(1);
> > + break;
> > + }
> > + }
>
> This _should_ always hit the dynamic case since we've always advertised
> that, were it not for a bug below. And even when powersave is turned off
> the AP will have to do CTS/RTS handshake so we do not gain anything by
> turning on all chains in that case.
>
We only hit the dynamic sm-ps mode if "priv->cfg->support_sm_ps == ture"
case. correct?
> I think the whole ht_config.sm_ps should be removed, and here we should
> always and unconditionally use _SINGLE as that matches what we've
> advertised to the AP via the HT capabilities.
>
> > /* up to 4 chains */
> > @@ -2258,6 +2280,12 @@ static void iwl_ht_conf(struct iwl_priv *priv,
> > >> IEEE80211_HT_MCS_TX_MAX_STREAMS_SHIFT;
> > maxstreams += 1;
> >
> > + ht_conf->sm_ps =
> > + (u8)((ht_cap->cap & IEEE80211_HT_CAP_SM_PS)
> > + >> 2);
> > + IWL_DEBUG_MAC80211(priv, "sm_ps: 0x%x\n",
> > + ht_conf->sm_ps);
> > +
>
> This is wrong; we cannot use the peer's SM_PS setting for our own SM_PS
> setting, we've advertised dynamic SM PS so we better stick with it. The
> peer's setting has no value for us, it means whether the peer will turn
> off _its_ chains or not.
I agree should not modify the SM_PS setting based on AP
I will submit another patch to remove using AP setting.
>
> johannes
^ permalink raw reply
* Re[4]: ieee80211_tx_status: headroom too small
From: Nikolai ZHUBR @ 2009-10-31 17:42 UTC (permalink / raw)
To: Johannes Berg; +Cc: Ivo van Doorn, linux-wireless
In-Reply-To: <1257003344.3555.136.camel@johannes.local>
Saturday, October 31, 2009, 6:35:44 PM, Johannes Berg wrote:
>> net/mac80211/main.c:
>> local->tx_headroom = max_t(unsigned int , local->hw.extra_tx_headroom,
>> sizeof(struct ieee80211_tx_status_rtap_hdr));
>>
>> drivers/net/wireless/rt*pci.c:
>> rt2x00dev->hw->extra_tx_headroom = 0;
>>
>> So, as a quick-and-dirty fix, should I replace "max_t(..." by "4 + max_t(...."
>> or "= 0" by "= 4" ?
> 4 + max ... should work if it's what we think it is. Let us know.
Yes, it removed those messages.
The actual speed is still not very high (like at 10Mbit maybe,
though 54Mbit is shown and the distance from the AP is very small,
so signal quality should be good I suppose) but it is ok for me.
Thank you!
Nikolai ZHUBR
> 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