* Re: [PATCH v2 4/4] ath10k: fix issues on non-preemptible systems
From: Kalle Valo @ 2013-08-28 4:02 UTC (permalink / raw)
To: Michal Kazior; +Cc: ath10k, linux-wireless
In-Reply-To: <CA+BoTQ=ycKd0Z60wHTWHoq7hBz1W2iW+ahjVmc_nFLQmU7-1Bg@mail.gmail.com>
Michal Kazior <michal.kazior@tieto.com> writes:
> On 27 August 2013 09:06, Kalle Valo <kvalo@qca.qualcomm.com> wrote:
>
>> I consider this more as a workaround as a real fix. Would NAPI be a
>> proper fix for issues like this?
>>
>> NAPI support was removed from mac80211 six months ago, but I guess we
>> could try to get it back if we have a good reason:
>>
>> http://marc.info/?l=linux-wireless&m=136204135907491
>
> Hmm. From what I understand NAPI is used for RX polling. My patch
> addresses mainly WMI/HTT TX starvation.
I thought I saw something related to NAPI on TX as well, but I can't
find it anymore.
> There's another solution that I had in mind. Instead of:
>
> for (;;) { dequeue(z); process; }
>
> I did:
>
> q = dequeue_all(z); for (;;) { dequeue(q); process; }
>
> I.e. move all queued stuff at the worker entry and move it out of the
> global queue, that can, and will be, having more stuff queued while
> the worker does its job).
>
> This way workers would exit/restart more often, but from what I tested
> it didn't really solve the problem. Given enough traffic HTC worker
> responsible for HTT TX gets overwhelmed eventually. You could try
> limit how many frames a worker can process during one execution, but
> how do you guess that? This starvation depends on how fast your CPU
> is.
I think we should come up with better ways to handle this. To have a
quota (like you mention above) would be one option. Other option would
be to have multiple queues and some sort of priorisation or fair
queueing.
And most importantly of all, we should minimise the lenght of queue we
have inside ath10k. I'm worried that we queue way too many packets
within ath10k right now.
> Thus I opted for sole cond_resched().
Yeah, this is a good workaround for the problem. But it would be good to
get bottom of this as well.
>>> +#ifndef CONFIG_PREEMPT
>>> + cond_resched();
>>> +#endif
>>
>> Why the #ifndef? Why should we not call cond_resched() when PREEMPT is
>> enabled? Does something negative happen then?
>
> I think it should be okay. I saw the #ifndef thing in b43legacy and
> thought it simply makes sense (although it's unsightly).
For various reasons I would prefer to have cond_resched() without the
#ifndef, if possible.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH v2 0/4] ath10k: fixes
From: Kalle Valo @ 2013-08-28 3:53 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless, Michal Kazior, ath10k
In-Reply-To: <20130827080144.GB29102@pogo>
"Luis R. Rodriguez" <rodrigue@qca.qualcomm.com> writes:
>> I disagree. The point of linux-stable is _not_ that we send all possible
>> fixes to stable. Instead we should send fixes only which really matter
>> to users and for which we have received bug reports. I haven't yet seen
>> any fix for ath10k which should be a candidate for stable releases.
>
> You don't need to wait for an issue to happen to consider it serious,
> the description of the symptoms seem pretty bad to me, but its your
> call in the end.
>
>> If we start sending all ath10k fixes to stable it's just extra churn for
>> both Greg and people working on ath10k.
>
> I'm not asking for anything that has the word "fix" to be sent, I'm
> asking them to be reviewed for stable consideration.
I think a good rule is that we should send fixes to stable only if a
user (!= developer) has reported the problem.
--
Kalle Valo
^ permalink raw reply
* Re: [E1000-devel] [PATCH net-next] drivers:net: Convert dma_alloc_coherent(...__GFP_ZERO) to dma_zalloc_coherent
From: Jeff Kirsher @ 2013-08-28 1:44 UTC (permalink / raw)
To: Joe Perches
Cc: netdev, e1000-devel, users, linux-wireless, linux-kernel, b43-dev
In-Reply-To: <1377582323.2658.10.camel@joe-AO722>
[-- Attachment #1: Type: text/plain, Size: 617 bytes --]
On Mon, 2013-08-26 at 22:45 -0700, Joe Perches wrote:
> __GFP_ZERO is an uncommon flag and perhaps is better
> not used. static inline dma_zalloc_coherent exists
> so convert the uses of dma_alloc_coherent with __GFP_ZERO
> to the more common kernel style with zalloc.
>
> Remove memset from the static inline dma_zalloc_coherent
> and add just one use of __GFP_ZERO instead.
>
> Trivially reduces the size of the existing uses of
> dma_zalloc_coherent.
>
> Realign arguments as appropriate.
>
> Signed-off-by: Joe Perches <joe@perches.com>
Acked-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* [PATCH 2/2] cw1200: Prevent a lock-related hang in the cw1200_spi driver
From: Solomon Peachy @ 2013-08-28 0:29 UTC (permalink / raw)
To: linux-wireless; +Cc: Solomon Peachy
In-Reply-To: <1377649787-2817-1-git-send-email-pizza@shaftnet.org>
The cw1200_spi driver tries to mirror the cw1200_sdio driver's lock
API, which relies on sdio_claim_host/sdio_release_host to serialize
hardware operations across multiple threads.
Unfortunately the implementation was flawed, as it lacked a way to wake
up the lock requestor when there was contention, often resulting in a
hang.
This problem was uncovered while trying to fix the
spi-transfers-in-interrupt-context BUG() corrected in the previous
patch. Many thanks to Dave Sizeburns for his assistance in fixing this.
Signed-off-by: Solomon Peachy <pizza@shaftnet.org>
---
Please consider this for 3.11-rc; without this patch SPI users are all
but guaranteed to deadlock while running this driver.
drivers/net/wireless/cw1200/cw1200_spi.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/net/wireless/cw1200/cw1200_spi.c b/drivers/net/wireless/cw1200/cw1200_spi.c
index c31580b..f5e6b48 100644
--- a/drivers/net/wireless/cw1200/cw1200_spi.c
+++ b/drivers/net/wireless/cw1200/cw1200_spi.c
@@ -40,6 +40,7 @@ struct hwbus_priv {
struct cw1200_common *core;
const struct cw1200_platform_data_spi *pdata;
spinlock_t lock; /* Serialize all bus operations */
+ wait_queue_head_t wq;
int claimed;
int irq_disabled;
};
@@ -198,8 +199,11 @@ static void cw1200_spi_lock(struct hwbus_priv *self)
{
unsigned long flags;
+ DECLARE_WAITQUEUE(wait, current);
+
might_sleep();
+ add_wait_queue(&self->wq, &wait);
spin_lock_irqsave(&self->lock, flags);
while (1) {
set_current_state(TASK_UNINTERRUPTIBLE);
@@ -212,6 +216,7 @@ static void cw1200_spi_lock(struct hwbus_priv *self)
set_current_state(TASK_RUNNING);
self->claimed = 1;
spin_unlock_irqrestore(&self->lock, flags);
+ remove_wait_queue(&self->wq, &wait);
return;
}
@@ -223,6 +228,8 @@ static void cw1200_spi_unlock(struct hwbus_priv *self)
spin_lock_irqsave(&self->lock, flags);
self->claimed = 0;
spin_unlock_irqrestore(&self->lock, flags);
+ wake_up(&self->wq);
+
return;
}
@@ -413,6 +420,8 @@ static int cw1200_spi_probe(struct spi_device *func)
spi_set_drvdata(func, self);
+ init_waitqueue_head(&self->wq);
+
status = cw1200_spi_irq_subscribe(self);
status = cw1200_core_probe(&cw1200_spi_hwbus_ops,
--
1.8.3.1
^ permalink raw reply related
* [PATCH 1/2] cw1200: Don't perform SPI transfers in interrupt context
From: Solomon Peachy @ 2013-08-28 0:29 UTC (permalink / raw)
To: linux-wireless; +Cc: Solomon Peachy
When we get an interrupt from the hardware, the first thing the driver does
is tell the device to mask off the interrupt line. Unfortunately this
involves a SPI transaction in interrupt context. Some (most?) SPI
controllers perform the transfer asynchronously and try to sleep.
This is bad, and triggers a BUG().
So, work around this by using adding a hwbus hook for the cw1200 driver
core to call. The cw1200_spi driver translates this into
irq_disable()/irq_enable() calls instead, which can safely be called in
interrupt context.
Apparently the platforms I used to develop the cw1200_spi driver used
synchronous spi_sync() implementations, which is why this didn't surface
until now.
Many thanks to Dave Sizeburns for the inital bug report and his services
as a tester.
Signed-off-by: Solomon Peachy <pizza@shaftnet.org>
---
Please consider this for 3.11-rc; without this patch many SPI users
will immediately trigger a BUG().
drivers/net/wireless/cw1200/cw1200_spi.c | 19 ++++++++++++++++---
drivers/net/wireless/cw1200/fwio.c | 2 +-
drivers/net/wireless/cw1200/hwbus.h | 1 +
drivers/net/wireless/cw1200/hwio.c | 15 +++++++++++++++
4 files changed, 33 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/cw1200/cw1200_spi.c b/drivers/net/wireless/cw1200/cw1200_spi.c
index d063760..c31580b 100644
--- a/drivers/net/wireless/cw1200/cw1200_spi.c
+++ b/drivers/net/wireless/cw1200/cw1200_spi.c
@@ -41,6 +41,7 @@ struct hwbus_priv {
const struct cw1200_platform_data_spi *pdata;
spinlock_t lock; /* Serialize all bus operations */
int claimed;
+ int irq_disabled;
};
#define SDIO_TO_SPI_ADDR(addr) ((addr & 0x1f)>>2)
@@ -230,6 +231,8 @@ static irqreturn_t cw1200_spi_irq_handler(int irq, void *dev_id)
struct hwbus_priv *self = dev_id;
if (self->core) {
+ disable_irq_nosync(self->func->irq);
+ self->irq_disabled = 1;
cw1200_irq_handler(self->core);
return IRQ_HANDLED;
} else {
@@ -263,13 +266,22 @@ exit:
static int cw1200_spi_irq_unsubscribe(struct hwbus_priv *self)
{
- int ret = 0;
-
pr_debug("SW IRQ unsubscribe\n");
disable_irq_wake(self->func->irq);
free_irq(self->func->irq, self);
- return ret;
+ return 0;
+}
+
+static int cw1200_spi_irq_enable(struct hwbus_priv *self, int enable)
+{
+ /* Disables are handled by the interrupt handler */
+ if (enable && self->irq_disabled) {
+ enable_irq(self->func->irq);
+ self->irq_disabled = 0;
+ }
+
+ return 0;
}
static int cw1200_spi_off(const struct cw1200_platform_data_spi *pdata)
@@ -349,6 +361,7 @@ static struct hwbus_ops cw1200_spi_hwbus_ops = {
.unlock = cw1200_spi_unlock,
.align_size = cw1200_spi_align_size,
.power_mgmt = cw1200_spi_pm,
+ .irq_enable = cw1200_spi_irq_enable,
};
/* Probe Function to be called by SPI stack when device is discovered */
diff --git a/drivers/net/wireless/cw1200/fwio.c b/drivers/net/wireless/cw1200/fwio.c
index acdff0f..0b2061b 100644
--- a/drivers/net/wireless/cw1200/fwio.c
+++ b/drivers/net/wireless/cw1200/fwio.c
@@ -485,7 +485,7 @@ int cw1200_load_firmware(struct cw1200_common *priv)
/* Enable interrupt signalling */
priv->hwbus_ops->lock(priv->hwbus_priv);
- ret = __cw1200_irq_enable(priv, 1);
+ ret = __cw1200_irq_enable(priv, 2);
priv->hwbus_ops->unlock(priv->hwbus_priv);
if (ret < 0)
goto unsubscribe;
diff --git a/drivers/net/wireless/cw1200/hwbus.h b/drivers/net/wireless/cw1200/hwbus.h
index 8b2fc83..51dfb3a 100644
--- a/drivers/net/wireless/cw1200/hwbus.h
+++ b/drivers/net/wireless/cw1200/hwbus.h
@@ -28,6 +28,7 @@ struct hwbus_ops {
void (*unlock)(struct hwbus_priv *self);
size_t (*align_size)(struct hwbus_priv *self, size_t size);
int (*power_mgmt)(struct hwbus_priv *self, bool suspend);
+ int (*irq_enable)(struct hwbus_priv *self, int enable);
};
#endif /* CW1200_HWBUS_H */
diff --git a/drivers/net/wireless/cw1200/hwio.c b/drivers/net/wireless/cw1200/hwio.c
index ff230b7..41bd761 100644
--- a/drivers/net/wireless/cw1200/hwio.c
+++ b/drivers/net/wireless/cw1200/hwio.c
@@ -273,6 +273,21 @@ int __cw1200_irq_enable(struct cw1200_common *priv, int enable)
u16 val16;
int ret;
+ /* We need to do this hack because the SPI layer can sleep on I/O
+ and the general path involves I/O to the device in interrupt
+ context.
+
+ However, the initial enable call needs to go to the hardware.
+
+ We don't worry about shutdown because we do a full reset which
+ clears the interrupt enabled bits.
+ */
+ if (priv->hwbus_ops->irq_enable) {
+ ret = priv->hwbus_ops->irq_enable(priv->hwbus_priv, enable);
+ if (ret || enable < 2)
+ return ret;
+ }
+
if (HIF_8601_SILICON == priv->hw_type) {
ret = __cw1200_reg_read_32(priv, ST90TDS_CONFIG_REG_ID, &val32);
if (ret < 0) {
--
1.8.3.1
^ permalink raw reply related
* [PATCH 2/2] cw1200: When debug is enabled, display all wakeup conditions for the wait_event_interruptible_timeout() call.
From: Solomon Peachy @ 2013-08-28 0:17 UTC (permalink / raw)
To: linux-wireless; +Cc: Solomon Peachy
In-Reply-To: <1377649033-2091-1-git-send-email-pizza@shaftnet.org>
When trying to debug an interrupt delivery problem I noticed that not
all of the wakeup conditions on the worker thread were included in the
debug message. This patch rectifies that.
Signed-off-by: Solomon Peachy <pizza@shaftnet.org>
---
drivers/net/wireless/cw1200/bh.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/cw1200/bh.c b/drivers/net/wireless/cw1200/bh.c
index c1ec2a4..92d299a 100644
--- a/drivers/net/wireless/cw1200/bh.c
+++ b/drivers/net/wireless/cw1200/bh.c
@@ -465,8 +465,8 @@ static int cw1200_bh(void *arg)
(rx || tx || term || suspend || priv->bh_error);
}), status);
- pr_debug("[BH] - rx: %d, tx: %d, term: %d, suspend: %d, status: %ld\n",
- rx, tx, term, suspend, status);
+ pr_debug("[BH] - rx: %d, tx: %d, term: %d, bh_err: %d, suspend: %d, status: %ld\n",
+ rx, tx, term, suspend, priv->bh_error, status);
/* Did an error occur? */
if ((status < 0 && status != -ERESTARTSYS) ||
--
1.8.3.1
^ permalink raw reply related
* [PATCH 1/2] cw1200: Display the correct default reference clock.
From: Solomon Peachy @ 2013-08-28 0:17 UTC (permalink / raw)
To: linux-wireless; +Cc: Solomon Peachy
This is purely a cosmetic bug.
Signed-off-by: Solomon Peachy <pizza@shaftnet.org>
---
drivers/net/wireless/cw1200/main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/cw1200/main.c b/drivers/net/wireless/cw1200/main.c
index 3724e73..090f015 100644
--- a/drivers/net/wireless/cw1200/main.c
+++ b/drivers/net/wireless/cw1200/main.c
@@ -507,7 +507,7 @@ u32 cw1200_dpll_from_clk(u16 clk_khz)
case 0xCB20: /* 52000 KHz */
return 0x07627091;
default:
- pr_err("Unknown Refclk freq (0x%04x), using 2600KHz\n",
+ pr_err("Unknown Refclk freq (0x%04x), using 26000KHz\n",
clk_khz);
return 0x0EC4F121;
}
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH 2/2] staging: vt6656: device.h Replace typedef struct _RCB
From: Greg KH @ 2013-08-27 23:57 UTC (permalink / raw)
To: Malcolm Priestley; +Cc: linux-wireless
In-Reply-To: <1377603883.3320.93.camel@canaries32-MCP7A>
On Tue, Aug 27, 2013 at 12:44:43PM +0100, Malcolm Priestley wrote:
> Replace with struct vnt_rcb
>
> Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
> ---
> drivers/staging/vt6656/device.h | 20 +++++++++-----------
> drivers/staging/vt6656/dpc.c | 10 +++++-----
> drivers/staging/vt6656/dpc.h | 4 ++--
> drivers/staging/vt6656/main_usb.c | 14 ++++++++------
> drivers/staging/vt6656/usbpipe.c | 4 ++--
> drivers/staging/vt6656/usbpipe.h | 2 +-
> 6 files changed, 27 insertions(+), 27 deletions(-)
This patch only applies with fuzz, which means we are starting to get
out of sync. Can you refresh this one against my staging-next tree,
which I've applied all of your other patches to, and resend it?
thanks,
greg k-h
^ permalink raw reply
* RE: sd8787 (mwifiex) on big endian system
From: Bing Zhao @ 2013-08-27 23:42 UTC (permalink / raw)
To: Tobias Waldekranz; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <20130827061745.GA19431@gmail.com>
Hi Tobias,
> Hi Bing,
>
> Here is the log output without the added udelay. It is always the 0xd9
> command that fails, but not always with these sdio_ireg/wr_bitmask
> values. I have seen these combinations:
>
> - sdio_ireg incorrect(2), wr_bitmask incorrect(fffe)
> - sdio_ireg correct(3), wr_bitmask incorrect(fffe)
> - sdio_ireg incorrect(2), wr_bitmask correct(ffff)
>
> Waiting 50 us before reading the mp_regs always returns the correct
> response.
Thanks for the logs.
Could you try the following change to bypass 0xd9 command?
diff --git a/drivers/net/wireless/mwifiex/sta_cmd.c b/drivers/net/wireless/mwifi
index c0268b5..3cecc86 100644
--- a/drivers/net/wireless/mwifiex/sta_cmd.c
+++ b/drivers/net/wireless/mwifiex/sta_cmd.c
@@ -1541,6 +1541,7 @@ int mwifiex_sta_init_cmd(struct mwifiex_private *priv, u8
if (ret)
return -1;
+#if 0
/* Reconfigure tx buf size */
ret = mwifiex_send_cmd_sync(priv,
HostCmd_CMD_RECONFIGURE_TX_BUFF,
@@ -1548,6 +1549,7 @@ int mwifiex_sta_init_cmd(struct mwifiex_private *priv, u8
&priv->adapter->tx_buf_size);
if (ret)
return -1;
+#endif
if (priv->bss_type != MWIFIEX_BSS_TYPE_UAP) {
/* Enable IEEE PS by default */
Thanks,
Bing
^ permalink raw reply related
* Re: issues with RTL8188CE device and rtl8192ce driver
From: Larry Finger @ 2013-08-27 23:17 UTC (permalink / raw)
To: Colleen Josephson; +Cc: linux-wireless
In-Reply-To: <CAN3-2D6Cf6Ew2Ar5ZD5ZCamhKF92wnKjgP=dEk15UF1YDXJS5g@mail.gmail.com>
On 08/27/2013 06:09 PM, Colleen Josephson wrote:
> Any updates? Or addition information that would be useful? I will be
> relocating to the other side of the US next week, so I will be unable
> to collect more information or traces on this specific network after
> then.
I have been busy getting a new driver into the kernel before 3.12 comes out. I
am now looking into both rtl8192ce and rtl8192cu. I think I have what I need
from you.
Larry
^ permalink raw reply
* Re: issues with RTL8188CE device and rtl8192ce driver
From: Colleen Josephson @ 2013-08-27 23:09 UTC (permalink / raw)
To: Larry Finger; +Cc: linux-wireless
In-Reply-To: <CAN3-2D5+tvQyZKBP3vUwGWdctCcfCeBxAhPsZs+DCLDdr4dyCw@mail.gmail.com>
Any updates? Or addition information that would be useful? I will be
relocating to the other side of the US next week, so I will be unable
to collect more information or traces on this specific network after
then.
^ permalink raw reply
* Re: Problems associating to AP with rtl8192cu driver
From: Mark Cave-Ayland @ 2013-08-27 22:05 UTC (permalink / raw)
To: Larry Finger; +Cc: linux-wireless
In-Reply-To: <521D17C7.2070105@lwfinger.net>
On 27/08/13 22:19, Larry Finger wrote:
Hi Larry,
>> The rtl8192cu firmware is that supplied with Debian Wheezy, while the AP
>> firmware should also be reasonably up-to-date. Access to all APs is
>> fine using
>> an Android phone, the zd1211rw desktop PC and a laptop with an iwlwifi
>> driver.
>> The APs are set to advertise both WPA and WPA2 encryption.
>
> The accepted firmware has an md5sum of 943e9b714a926e630b8152d7aad91d2e
> for /lib/firmware/rtlwifi/rtl8192cufw.bin.
Yes - that agrees with what I have here:
mca@kentang:~$ md5sum /lib/firmware/rtlwifi/rtl8192cufw.bin
943e9b714a926e630b8152d7aad91d2e /lib/firmware/rtlwifi/rtl8192cufw.bin
>>> Do you still have the wireshark file from the failed attempt? If so,
>>> could you filter out the traffic from APs and stations other than the
>>> units trying to make the connection, and send me (privately) the trimmed
>>> file?
>>
>> Yes - I'm not sure if it's exactly that attempt, but I do have a
>> representative
>> wireshark trace of this which I will send to you privately.
>>
>>> For completeness, I have tested WPA2 with Netgear WNDR3300 and WNDR3400
>>> running standard firmware, WPA1 with a Linksys WRT54GL running openWRT
>>> Kamikaze fw, and WEP with a Linksys WRT54G V5 running standard fw.
>>
>> Okay. So perhaps there is something slightly different about this
>> particular
>> WiFi dongle...
>
> Neither rtl8192cu nor 8192cu (the vendor driver) work with the 2x2
> configuration such as found in a TP-Link TL-WN8200ND V1.0. That was
> reported to Realtek, but I have had no response from them.
Understood. All of the O2 wireless box, desktop PC and Netgear AP I used
in my tests here are b/g only, so I'm guessing that shouldn't be an issue?
ATB,
Mark.
^ permalink raw reply
* Re: Problems associating to AP with rtl8192cu driver
From: Larry Finger @ 2013-08-27 21:19 UTC (permalink / raw)
To: Mark Cave-Ayland; +Cc: linux-wireless
In-Reply-To: <521D0EA2.2070105@ilande.co.uk>
On 08/27/2013 03:40 PM, Mark Cave-Ayland wrote:
> On 27/08/13 17:23, Larry Finger wrote:
>
> Hi Larry,
>
>> I just retested and this message was posted from what lsusb says is a
>> "Bus 001 Device 007: ID 7392:7811 Edimax Technology Co., Ltd EW-7811Un
>> 802.11n Wireless Adapter [Realtek RTL8188CUS]" connected to an AP using
>> WPA(1).
>
> I'm actually testing a dongle from a Raspberry Pi that I've been experiencing
> issues with under load with the Realtek-written 8192cu driver. My understanding
> is that it is an OEM RTL8188CUS adapter from here:
> http://thepihut.com/products/usb-wifi-adapter-for-the-raspberry-pi.
>
>> My kernel is 3.11.0-rc6-wl+ from the wireless-testing tree. I have built
>> 3.11-rc7-wl+, but not yet rebooted. Before I boot into that kernel, I
>> will build and test the mainline kernel, but it should not make a
>> difference as the only code differences between wireless-testing and the
>> mainline trees deal with cleaning up some sparse endian issues.
>>
>> What is the make/model of the AP that fails? Is its firmware the latest
>> available? Just to confirm, you are running WPA1 encryption.
>
> It seems to be all of the ones I'm testing :/ Currently that's an old Netgear
> DG834G, a desktop PC running Debian Wheezy/hostapd using a zd1211rw-based WiFi
> dongle, and an O2 Wireless box (rebadged Thomson). The problem seems to be that
> association is difficult, and even when it does associate then the AP appears to
> drop out every minute or so.
>
> The rtl8192cu firmware is that supplied with Debian Wheezy, while the AP
> firmware should also be reasonably up-to-date. Access to all APs is fine using
> an Android phone, the zd1211rw desktop PC and a laptop with an iwlwifi driver.
> The APs are set to advertise both WPA and WPA2 encryption.
The accepted firmware has an md5sum of 943e9b714a926e630b8152d7aad91d2e for
/lib/firmware/rtlwifi/rtl8192cufw.bin.
>> Do you still have the wireshark file from the failed attempt? If so,
>> could you filter out the traffic from APs and stations other than the
>> units trying to make the connection, and send me (privately) the trimmed
>> file?
>
> Yes - I'm not sure if it's exactly that attempt, but I do have a representative
> wireshark trace of this which I will send to you privately.
>
>> For completeness, I have tested WPA2 with Netgear WNDR3300 and WNDR3400
>> running standard firmware, WPA1 with a Linksys WRT54GL running openWRT
>> Kamikaze fw, and WEP with a Linksys WRT54G V5 running standard fw.
>
> Okay. So perhaps there is something slightly different about this particular
> WiFi dongle...
Neither rtl8192cu nor 8192cu (the vendor driver) work with the 2x2 configuration
such as found in a TP-Link TL-WN8200ND V1.0. That was reported to Realtek, but I
have had no response from them.
Larry
^ permalink raw reply
* Re: Problems associating to AP with rtl8192cu driver
From: Mark Cave-Ayland @ 2013-08-27 20:40 UTC (permalink / raw)
To: Larry Finger; +Cc: linux-wireless
In-Reply-To: <521CD266.5010801@lwfinger.net>
On 27/08/13 17:23, Larry Finger wrote:
Hi Larry,
> I just retested and this message was posted from what lsusb says is a
> "Bus 001 Device 007: ID 7392:7811 Edimax Technology Co., Ltd EW-7811Un
> 802.11n Wireless Adapter [Realtek RTL8188CUS]" connected to an AP using
> WPA(1).
I'm actually testing a dongle from a Raspberry Pi that I've been
experiencing issues with under load with the Realtek-written 8192cu
driver. My understanding is that it is an OEM RTL8188CUS adapter from
here: http://thepihut.com/products/usb-wifi-adapter-for-the-raspberry-pi.
> My kernel is 3.11.0-rc6-wl+ from the wireless-testing tree. I have built
> 3.11-rc7-wl+, but not yet rebooted. Before I boot into that kernel, I
> will build and test the mainline kernel, but it should not make a
> difference as the only code differences between wireless-testing and the
> mainline trees deal with cleaning up some sparse endian issues.
>
> What is the make/model of the AP that fails? Is its firmware the latest
> available? Just to confirm, you are running WPA1 encryption.
It seems to be all of the ones I'm testing :/ Currently that's an old
Netgear DG834G, a desktop PC running Debian Wheezy/hostapd using a
zd1211rw-based WiFi dongle, and an O2 Wireless box (rebadged Thomson).
The problem seems to be that association is difficult, and even when it
does associate then the AP appears to drop out every minute or so.
The rtl8192cu firmware is that supplied with Debian Wheezy, while the AP
firmware should also be reasonably up-to-date. Access to all APs is fine
using an Android phone, the zd1211rw desktop PC and a laptop with an
iwlwifi driver. The APs are set to advertise both WPA and WPA2 encryption.
> Do you still have the wireshark file from the failed attempt? If so,
> could you filter out the traffic from APs and stations other than the
> units trying to make the connection, and send me (privately) the trimmed
> file?
Yes - I'm not sure if it's exactly that attempt, but I do have a
representative wireshark trace of this which I will send to you privately.
> For completeness, I have tested WPA2 with Netgear WNDR3300 and WNDR3400
> running standard firmware, WPA1 with a Linksys WRT54GL running openWRT
> Kamikaze fw, and WEP with a Linksys WRT54G V5 running standard fw.
Okay. So perhaps there is something slightly different about this
particular WiFi dongle...
Many thanks,
Mark.
^ permalink raw reply
* Re: pull request: wireless 2013-08-23
From: David Miller @ 2013-08-27 19:55 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20130823162044.GD15114@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Fri, 23 Aug 2013 12:20:44 -0400
> This is one more set of fixes intended for the 3.11 stream...
>
> For the mac80211 bits, Johannes says:
>
> "I have three more patches for the 3.11 stream: Felix's fix for the
> fairly visible brcmsmac crash, a fix from Simon for an IBSS join bug I
> found and a fix for a channel context bug in IBSS I'd introduced."
>
> Along with those...
>
> Sujith Manoharan makes a minor change to not use a PLL hang workaroun
> for AR9550. This one-liner fixes a couple of bugs reported in the Red Hat
> bugzilla.
>
> Helmut Schaa addresses an ath9k_htc bug that mangles frame headers
> during Tx. This fix is small, tested by the bug reported and isolated
> to ath9k_htc.
>
> Stanislaw Gruszka reverts a recent iwl4965 change that broke rfkill
> notification to user space.
>
> Please let me know if there are problems!
Pulled, thanks John.
^ permalink raw reply
* Re: [PATCH net-next] drivers:net: Convert dma_alloc_coherent(...__GFP_ZERO) to dma_zalloc_coherent
From: Jesse Brandeburg @ 2013-08-27 19:34 UTC (permalink / raw)
To: Joe Perches
Cc: netdev, linux-kernel, e1000-devel, linux-wireless, b43-dev, users,
jesse.brandeburg
In-Reply-To: <1377582323.2658.10.camel@joe-AO722>
On Mon, 26 Aug 2013 22:45:23 -0700
Joe Perches <joe@perches.com> wrote:
> __GFP_ZERO is an uncommon flag and perhaps is better
> not used. static inline dma_zalloc_coherent exists
> so convert the uses of dma_alloc_coherent with __GFP_ZERO
> to the more common kernel style with zalloc.
>
> Remove memset from the static inline dma_zalloc_coherent
> and add just one use of __GFP_ZERO instead.
>
> Trivially reduces the size of the existing uses of
> dma_zalloc_coherent.
>
> Realign arguments as appropriate.
>
> Signed-off-by: Joe Perches <joe@perches.com>
e1000 and ixgb bits:
Acked-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
^ permalink raw reply
* [PATCH] iw: Print out HotSpot2 IE information.
From: greearb @ 2013-08-27 19:27 UTC (permalink / raw)
To: linux-wireless; +Cc: Ben Greear
From: Ben Greear <greearb@candelatech.com>
Example:
HotSpot 2.0 Indication:
DGAF: 0
Signed-off-by: Ben Greear <greearb@candelatech.com>
---
:100644 100644 1a48509... c20c386... M scan.c
scan.c | 13 +++++++++++++
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/scan.c b/scan.c
index 1a48509..c20c386 100644
--- a/scan.c
+++ b/scan.c
@@ -1388,8 +1388,21 @@ static inline void print_p2p(const uint8_t type, uint8_t len, const uint8_t *dat
}
}
+static inline void print_hs20_ind(const uint8_t type, uint8_t len, const uint8_t *data)
+{
+ /* I can't find the spec for this...just going off what wireshark uses. */
+ printf("\n");
+ if (len > 0) {
+ printf("\t\tDGAF: %i\n", (int)(data[0] & 0x1));
+ }
+ else {
+ printf("\t\tUnexpected length: %i\n", len);
+ }
+}
+
static const struct ie_print wfa_printers[] = {
[9] = { "P2P", print_p2p, 2, 255, BIT(PRINT_SCAN), },
+ [16] = { "HotSpot 2.0 Indication", print_hs20_ind, 1, 255, BIT(PRINT_SCAN), },
};
static void print_vendor(unsigned char len, unsigned char *data,
--
1.7.3.4
^ permalink raw reply related
* [PATCH] iw: Print 802.11u roaming consortium IE in scan results.
From: greearb @ 2013-08-27 17:26 UTC (permalink / raw)
To: linux-wireless; +Cc: Ben Greear
From: Ben Greear <greearb@candelatech.com>
Example output:
802.11u Roaming Consortium:
ANQP OIs: 0
OI 1: 01010101
Signed-off-by: Ben Greear <greearb@candelatech.com>
---
:100644 100644 b1917b0... 1a48509... M scan.c
scan.c | 53 +++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 53 insertions(+), 0 deletions(-)
diff --git a/scan.c b/scan.c
index b1917b0..1a48509 100644
--- a/scan.c
+++ b/scan.c
@@ -709,6 +709,58 @@ static void print_11u_advert(const uint8_t type, uint8_t len, const uint8_t *dat
}
}
+static void print_11u_rcon(const uint8_t type, uint8_t len, const uint8_t *data)
+{
+ /* See Section 7.3.2.96 in the 802.11u spec. */
+ int idx = 0;
+ int ln0 = data[1] & 0xf;
+ int ln1 = ((data[1] & 0xf0) >> 4);
+ int ln2 = 0;
+ printf("\n");
+
+ if (ln1) {
+ ln2 = len - 2 - ln0 - ln1;
+ }
+ printf("\t\tANQP OIs: %i\n", data[0]);
+
+ if (ln0 > 0) {
+ printf("\t\tOI 1: ");
+ if (2 + ln0 > len) {
+ printf("Invalid IE length.\n");
+ }
+ else {
+ for (idx = 0; idx < ln0; idx++) {
+ printf("%02hx", data[2 + idx]);
+ }
+ printf("\n");
+ }
+ }
+ if (ln1 > 0) {
+ printf("\t\tOI 2: ");
+ if (2 + ln0 + ln1 > len) {
+ printf("Invalid IE length.\n");
+ }
+ else {
+ for (idx = 0; idx < ln1; idx++) {
+ printf("%02hx", data[2 + ln0 + idx]);
+ }
+ printf("\n");
+ }
+ }
+ if (ln2 > 0) {
+ printf("\t\tOI 3: ");
+ if (2 + ln0 + ln1 + ln2 > len) {
+ printf("Invalid IE length.\n");
+ }
+ else {
+ for (idx = 0; idx < ln2; idx++) {
+ printf("%02hx", data[2 + ln0 + ln1 + idx]);
+ }
+ printf("\n");
+ }
+ }
+}
+
static const char *ht_secondary_offset[4] = {
"no secondary",
"above",
@@ -988,6 +1040,7 @@ static const struct ie_print ieprinters[] = {
[127] = { "Extended capabilities", print_capabilities, 0, 255, BIT(PRINT_SCAN), },
[107] = { "802.11u Interworking", print_interworking, 0, 255, BIT(PRINT_SCAN), },
[108] = { "802.11u Advertisement", print_11u_advert, 0, 255, BIT(PRINT_SCAN), },
+ [111] = { "802.11u Roaming Consortium", print_11u_rcon, 0, 255, BIT(PRINT_SCAN), },
};
static void print_wifi_wpa(const uint8_t type, uint8_t len, const uint8_t *data)
--
1.7.3.4
^ permalink raw reply related
* [PATCH] iw: Print 802.11u Advertisement IE info in scan results.
From: greearb @ 2013-08-27 16:50 UTC (permalink / raw)
To: linux-wireless; +Cc: Ben Greear
From: Ben Greear <greearb@candelatech.com>
Sample output looks like:
802.11u Advertisement:
Query Response Info: 0x7f
Query Response Length Limit: 127
ANQP
Signed-off-by: Ben Greear <greearb@candelatech.com>
---
:100644 100644 1894769... b1917b0... M scan.c
scan.c | 33 +++++++++++++++++++++++++++++++++
1 files changed, 33 insertions(+), 0 deletions(-)
diff --git a/scan.c b/scan.c
index 1894769..b1917b0 100644
--- a/scan.c
+++ b/scan.c
@@ -677,6 +677,38 @@ static void print_interworking(const uint8_t type, uint8_t len, const uint8_t *d
data[1], data[2], data[3], data[4], data[5], data[6]);
}
+static void print_11u_advert(const uint8_t type, uint8_t len, const uint8_t *data)
+{
+ /* See Section 7.3.2.93 in the 802.11u spec. */
+ /* TODO: This code below does not decode private protocol IDs */
+ int idx = 0;
+ printf("\n");
+ while (idx < (len - 1)) {
+ uint8_t qri = data[idx];
+ uint8_t proto_id = data[idx + 1];
+ printf("\t\tQuery Response Info: 0x%hx\n", (unsigned short)(qri));
+ printf("\t\t\tQuery Response Length Limit: %i\n",
+ (qri & 0x7f));
+ if (qri & (1<<7))
+ printf("\t\t\tPAME-BI\n");
+ switch(proto_id) {
+ case 0:
+ printf("\t\t\tANQP\n"); break;
+ case 1:
+ printf("\t\t\tMIH Information Service\n"); break;
+ case 2:
+ printf("\t\t\tMIH Command and Event Services Capability Discovery\n"); break;
+ case 3:
+ printf("\t\t\tEmergency Alert System (EAS)\n"); break;
+ case 221:
+ printf("\t\t\tVendor Specific\n"); break;
+ default:
+ printf("\t\t\tReserved: %i\n", proto_id); break;
+ }
+ idx += 2;
+ }
+}
+
static const char *ht_secondary_offset[4] = {
"no secondary",
"above",
@@ -955,6 +987,7 @@ static const struct ie_print ieprinters[] = {
[114] = { "MESH ID", print_ssid, 0, 32, BIT(PRINT_SCAN) | BIT(PRINT_LINK), },
[127] = { "Extended capabilities", print_capabilities, 0, 255, BIT(PRINT_SCAN), },
[107] = { "802.11u Interworking", print_interworking, 0, 255, BIT(PRINT_SCAN), },
+ [108] = { "802.11u Advertisement", print_11u_advert, 0, 255, BIT(PRINT_SCAN), },
};
static void print_wifi_wpa(const uint8_t type, uint8_t len, const uint8_t *data)
--
1.7.3.4
^ permalink raw reply related
* Re: Problems associating to AP with rtl8192cu driver
From: Larry Finger @ 2013-08-27 16:23 UTC (permalink / raw)
To: Mark Cave-Ayland; +Cc: linux-wireless
In-Reply-To: <521B9A74.60603@ilande.co.uk>
On 08/26/2013 01:12 PM, Mark Cave-Ayland wrote:
> On 23/08/13 19:55, Mark Cave-Ayland wrote:
>
>> Can anyone provide any hints to debugging the issue? I've just updated
>> to Linus' latest git master from earlier today and the issue still
>> appears :(
>
> I spent some more time today trying to debug what was happening, and ended up
> setting up a temporary hostapd access point so that I could get logs from both
> the AP and my laptop workstation.
>
> The bug I'm chasing seems to be related to the EAPOL handshake between my laptop
> and the AP. A session with Wireshark shows something like this:
>
> AP -> Laptop : EAPOL 1/4
> Laptop -> AP : EAPOL 2/4
>
> (pause - EAPOL timeout of several seconds)
>
> AP -> Laptop : EAPOL 1/4
> Laptop -> AP : EAPOL 2/4
>
> This pattern is repeated throughout the connection attempts. Comparing
> wpa_supplicant logs from a workstation with an Intel iwlwifi card shows that the
> AP never sends the EAPOL 3/4 packet, suggesting that something in the EAPOL 2/4
> packet was invalid causing the authentication attempt to be dropped.
>
> Interestingly enough if I leave the wpa_supplicant running for a minute or two,
> then sometimes the laptop will authenticate successfully with the AP - this
> suggests that perhaps it may be an initialisation bug of some description?
>
> Can anyone suggest any reasons why the AP never responds with the EAPOL 3/4
> packet as part of the 4-way handshake? To get more information, I set up a fake
> AP using hostapd with logging enabled and recorded the authentication attempts
> on both the AP and the laptop (note that remarkably the laptop managed to
> associate to the AP on the second attempt in this particular session):
>
> AP hostapd log:
> http://www.ilande.co.uk/tmp/hostapd-rtl8192cu-connect.txt
>
> Laptop workstation log:
> http://www.ilande.co.uk/tmp/wpasupplicant-rtl8192cu-connect.txt
>
> Also just to confirm that all testing was done against commit
> 6a7492a4b2e05051a44458d7187023e22d580666 and therefore should contain the WPA
> association fix "rtlwifi: rtl8192cu: Fix problem in connecting to WEP or WPA(1)
> networks" from commit 5b8df24e22e0b00b599cb9ae63dbb96e1959be30.
I just retested and this message was posted from what lsusb says is a "Bus 001
Device 007: ID 7392:7811 Edimax Technology Co., Ltd EW-7811Un 802.11n Wireless
Adapter [Realtek RTL8188CUS]" connected to an AP using WPA(1).
My kernel is 3.11.0-rc6-wl+ from the wireless-testing tree. I have built
3.11-rc7-wl+, but not yet rebooted. Before I boot into that kernel, I will build
and test the mainline kernel, but it should not make a difference as the only
code differences between wireless-testing and the mainline trees deal with
cleaning up some sparse endian issues.
What is the make/model of the AP that fails? Is its firmware the latest
available? Just to confirm, you are running WPA1 encryption.
Do you still have the wireshark file from the failed attempt? If so, could you
filter out the traffic from APs and stations other than the units trying to make
the connection, and send me (privately) the trimmed file?
For completeness, I have tested WPA2 with Netgear WNDR3300 and WNDR3400 running
standard firmware, WPA1 with a Linksys WRT54GL running openWRT Kamikaze fw, and
WEP with a Linksys WRT54G V5 running standard fw.
Larry
^ permalink raw reply
* [PATCH] iw: Print Interworking IE details in scan results.
From: greearb @ 2013-08-27 16:07 UTC (permalink / raw)
To: linux-wireless; +Cc: Ben Greear
From: Ben Greear <greearb@candelatech.com>
Output looks like:
802.11u Interworking:
Network Options: 0xf1
Network Type: 1 (Private with Guest)
Internet
ASRA
ESR
UESA
Venu Group: 2 (Business)
Venu Type: 1
HESSID: 00:00:00:00:00:01
Signed-off-by: Ben Greear <greearb@candelatech.com>
---
:100644 100644 af21cbc... 1894769... M scan.c
scan.c | 64 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 64 insertions(+), 0 deletions(-)
diff --git a/scan.c b/scan.c
index af21cbc..1894769 100644
--- a/scan.c
+++ b/scan.c
@@ -614,6 +614,69 @@ static void print_ht_capa(const uint8_t type, uint8_t len, const uint8_t *data)
print_ht_mcs(data + 3);
}
+static const char* ntype_11u(uint8_t t) {
+ switch (t) {
+ case 0: return "Private";
+ case 1: return "Private with Guest";
+ case 2: return "Chargeable Public";
+ case 3: return "Free Public";
+ case 4: return "Personal Device";
+ case 5: return "Emergency Services Only";
+ case 14: return "Test or Experimental";
+ case 15: return "Wildcard";
+ default: return "Reserved";
+ }
+}
+
+static const char* vgroup_11u(uint8_t t) {
+ switch (t) {
+ case 0: return "Unspecified";
+ case 1: return "Assembly";
+ case 2: return "Business";
+ case 3: return "Educational";
+ case 4: return "Factory and Industrial";
+ case 5: return "Institutional";
+ case 6: return "Mercantile";
+ case 7: return "Residential";
+ case 8: return "Storage";
+ case 9: return "Utility and Miscellaneous";
+ case 10: return "Vehicular";
+ case 11: return "Outdoor";
+ default: return "Reserved";
+ }
+}
+
+static void print_interworking(const uint8_t type, uint8_t len, const uint8_t *data)
+{
+ /* See Section 7.3.2.92 in the 802.11u spec. */
+ printf("\n");
+ if (len >= 1) {
+ uint8_t ano = data[0];
+ printf("\t\tNetwork Options: 0x%hx\n", (unsigned short)(ano));
+ printf("\t\t\tNetwork Type: %i (%s)\n",
+ (int)(ano & 0xf), ntype_11u(ano & 0xf));
+ if (ano & (1<<4))
+ printf("\t\t\tInternet\n");
+ if (ano & (1<<5))
+ printf("\t\t\tASRA\n");
+ if (ano & (1<<6))
+ printf("\t\t\tESR\n");
+ if (ano & (1<<7))
+ printf("\t\t\tUESA\n");
+ }
+ if ((len == 3) || (len == 9)) {
+ printf("\t\tVenue Group: %i (%s)\n",
+ (int)(data[1]), vgroup_11u(data[1]));
+ printf("\t\tVenue Type: %i\n", (int)(data[2]));
+ }
+ if (len == 9)
+ printf("\t\tHESSID: %02hx:%02hx:%02hx:%02hx:%02hx:%02hx\n",
+ data[3], data[4], data[5], data[6], data[7], data[8]);
+ else if (len == 7)
+ printf("\t\tHESSID: %02hx:%02hx:%02hx:%02hx:%02hx:%02hx\n",
+ data[1], data[2], data[3], data[4], data[5], data[6]);
+}
+
static const char *ht_secondary_offset[4] = {
"no secondary",
"above",
@@ -891,6 +954,7 @@ static const struct ie_print ieprinters[] = {
[113] = { "MESH Configuration", print_mesh_conf, 7, 7, BIT(PRINT_SCAN), },
[114] = { "MESH ID", print_ssid, 0, 32, BIT(PRINT_SCAN) | BIT(PRINT_LINK), },
[127] = { "Extended capabilities", print_capabilities, 0, 255, BIT(PRINT_SCAN), },
+ [107] = { "802.11u Interworking", print_interworking, 0, 255, BIT(PRINT_SCAN), },
};
static void print_wifi_wpa(const uint8_t type, uint8_t len, const uint8_t *data)
--
1.7.3.4
^ permalink raw reply related
* [PATCH] Add WLI-UC-G300HP's Product ID.
From: Masami Ichikawa @ 2013-08-27 15:37 UTC (permalink / raw)
To: IvDoorn, gwingerde, helmut.schaa, linville
Cc: Masami Ichikawa, linux-wireless, users, netdev, linux-kernel
Support Bufallo WLI-UC-G300HP.
Signed-off-by: Masami Ichikawa <masami256@gmail.com>
---
drivers/net/wireless/rt2x00/rt2800usb.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/wireless/rt2x00/rt2800usb.c b/drivers/net/wireless/rt2x00/rt2800usb.c
index 840833b..518277d 100644
--- a/drivers/net/wireless/rt2x00/rt2800usb.c
+++ b/drivers/net/wireless/rt2x00/rt2800usb.c
@@ -977,6 +977,7 @@ static struct usb_device_id rt2800usb_device_table[] = {
{ USB_DEVICE(0x0411, 0x016f) },
{ USB_DEVICE(0x0411, 0x01a2) },
{ USB_DEVICE(0x0411, 0x01ee) },
+ { USB_DEVICE(0x0411, 0x01a8) },
/* Corega */
{ USB_DEVICE(0x07aa, 0x002f) },
{ USB_DEVICE(0x07aa, 0x003c) },
--
1.8.3.1
^ permalink raw reply related
* [PATCH 2/2] mac80211: do not override fixed_rate_idx in minstrel_ht_update_stats
From: Lorenzo Bianconi @ 2013-08-27 14:59 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, nbd, johannes
In-Reply-To: <1377615587-6015-1-git-send-email-lorenzo.bianconi83@gmail.com>
Do not override max_tp_rate, max_tp_rate2 and max_prob_rate configured
according to fixed_rate in minstrel_ht_update_stats throughput computation
Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi83@gmail.com>
---
net/mac80211/rc80211_minstrel_ht.c | 23 +++++++++++++----------
1 file changed, 13 insertions(+), 10 deletions(-)
diff --git a/net/mac80211/rc80211_minstrel_ht.c b/net/mac80211/rc80211_minstrel_ht.c
index 339a6b8..597e09a 100644
--- a/net/mac80211/rc80211_minstrel_ht.c
+++ b/net/mac80211/rc80211_minstrel_ht.c
@@ -365,6 +365,14 @@ minstrel_ht_update_stats(struct minstrel_priv *mp, struct minstrel_ht_sta *mi)
}
}
+#ifdef CONFIG_MAC80211_DEBUGFS
+ /* use fixed index if set */
+ if (mp->fixed_rate_idx != -1) {
+ mi->max_tp_rate = mp->fixed_rate_idx;
+ mi->max_tp_rate2 = mp->fixed_rate_idx;
+ mi->max_prob_rate = mp->fixed_rate_idx;
+ }
+#endif
mi->stats_update = jiffies;
}
@@ -775,6 +783,11 @@ minstrel_ht_get_rate(void *priv, struct ieee80211_sta *sta, void *priv_sta,
info->flags |= mi->tx_flags;
minstrel_ht_check_cck_shortpreamble(mp, mi, txrc->short_preamble);
+#ifdef CONFIG_MAC80211_DEBUGFS
+ if (mp->fixed_rate_idx != -1)
+ return;
+#endif
+
/* Don't use EAPOL frames for sampling on non-mrr hw */
if (mp->hw->max_rates == 1 &&
(info->control.flags & IEEE80211_TX_CTRL_PORT_CTRL_PROTO))
@@ -782,16 +795,6 @@ minstrel_ht_get_rate(void *priv, struct ieee80211_sta *sta, void *priv_sta,
else
sample_idx = minstrel_get_sample_rate(mp, mi);
-#ifdef CONFIG_MAC80211_DEBUGFS
- /* use fixed index if set */
- if (mp->fixed_rate_idx != -1) {
- mi->max_tp_rate = mp->fixed_rate_idx;
- mi->max_tp_rate2 = mp->fixed_rate_idx;
- mi->max_prob_rate = mp->fixed_rate_idx;
- sample_idx = -1;
- }
-#endif
-
mi->total_packets++;
/* wraparound */
--
1.8.1.2
^ permalink raw reply related
* [PATCH 1/2] mac80211: add fixed_rate management to minstrel rc
From: Lorenzo Bianconi @ 2013-08-27 14:59 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, nbd, johannes
In-Reply-To: <1377615587-6015-1-git-send-email-lorenzo.bianconi83@gmail.com>
Add the capability to use a fixed modulation rate to minstrel rate controller
Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi83@gmail.com>
---
net/mac80211/rc80211_minstrel.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/net/mac80211/rc80211_minstrel.c b/net/mac80211/rc80211_minstrel.c
index 8b5f7ef..7fa1b36 100644
--- a/net/mac80211/rc80211_minstrel.c
+++ b/net/mac80211/rc80211_minstrel.c
@@ -203,6 +203,15 @@ minstrel_update_stats(struct minstrel_priv *mp, struct minstrel_sta_info *mi)
memcpy(mi->max_tp_rate, tmp_tp_rate, sizeof(mi->max_tp_rate));
mi->max_prob_rate = tmp_prob_rate;
+#ifdef CONFIG_MAC80211_DEBUGFS
+ /* use fixed index if set */
+ if (mp->fixed_rate_idx != -1) {
+ mi->max_tp_rate[0] = mp->fixed_rate_idx;
+ mi->max_tp_rate[1] = mp->fixed_rate_idx;
+ mi->max_prob_rate = mp->fixed_rate_idx;
+ }
+#endif
+
/* Reset update timer */
mi->stats_update = jiffies;
@@ -310,6 +319,11 @@ minstrel_get_rate(void *priv, struct ieee80211_sta *sta,
/* increase sum packet counter */
mi->packet_count++;
+#ifdef CONFIG_MAC80211_DEBUGFS
+ if (mp->fixed_rate_idx != -1)
+ return;
+#endif
+
delta = (mi->packet_count * sampling_ratio / 100) -
(mi->sample_count + mi->sample_deferred / 2);
--
1.8.1.2
^ permalink raw reply related
* [PATCH 0/2] mac80211: fix minstrel fixed_rate management
From: Lorenzo Bianconi @ 2013-08-27 14:59 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, nbd, johannes
This couple of patches add/fix fixed_rate management of minstrel/minstrel_ht
rate controller. In particular:
*[PATCH 1/2]: add the capability to use a particular rate to minstrel rate
controller
*[PATCH 2/2]: restore the mcs index configured according to fixed_rate value
since it has been overridden in minstrel_ht_update_stats throughput computation
Regards,
Lorenzo
Lorenzo Bianconi (2):
mac80211: add fixed_rate management to minstrel rc
mac80211: do not override fixed_rate_idx in minstrel_ht_update_stats
net/mac80211/rc80211_minstrel.c | 14 ++++++++++++++
net/mac80211/rc80211_minstrel_ht.c | 23 +++++++++++++----------
2 files changed, 27 insertions(+), 10 deletions(-)
--
1.8.1.2
^ 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