* Re: Rtl8187se regression [was: rtl8187se - serious regressions since merge out of staging into 818x]
2014-09-12 7:47 ` Rtl8187se regression [was: rtl8187se - serious regressions since merge out of staging into 818x] Bernhard Schiffner
@ 2014-09-12 16:29 ` Andrea Merello
2014-09-12 16:52 ` Larry Finger
0 siblings, 1 reply; 3+ messages in thread
From: Andrea Merello @ 2014-09-12 16:29 UTC (permalink / raw)
To: Bernhard Schiffner
Cc: ralf, Xose Vazquez Perez, Larry Finger, Linux Wireless List,
John W. Linville
[-- Attachment #1: Type: text/plain, Size: 3419 bytes --]
> Because of the problems I'am going now to a special site, where I have a local
> networks (LAN/WLAN), good internet connection and root access to Linux
> machines.
> This should be a good thing to do real testing.
Excellent!
Thank you Bernhard!
> 1.) Andrea, can you resend me the latest patches (perhaps against 3.16)
> please?
> (only to confirm that we are in "synchronous" mode.)
Sure, I attach a cumulative patch, including all the changes I think
may matter (signal strength fix not included)
> 2.) Andrea, Larry, John are you interested to have root access to my laptop
> using the rtl8187se?
> (Perhaps it can stay there over the weekend too.)
Thank you for offering this :)
In case it turns out that you actually face performance regressions,
then it might help me to make some experiments using your machine.
I will do a register dump and I will try to tune some parameters in
the driver. This should NOT crash the machine, but if it is vital for
you that the machine remains alive, then maybe I will avoid at least
certain experiments..
Possibly tomorrow afternoon (Italian time) I will have some spare time
to work on this.
> 3.) My test for maximal troughput is to run a connection /dev/zero -> nc ->|->
> nc -> /dev/null.
> Any other ideas?
Usually I use two Linux hosts (the DUT and my production system) and I
use "iperf" program on both
On the production system (the iperf server) I run
iperf -s -u -b30M
On the DUT I run
iperf -c 192.168.1.2 -r -u -b30M
This will cause an UDP data exchange and will perform both downstream
and upstream throughput measurements.
I usually do this (at least) two times, and I discard results from the
first run, because rate selection algorithm might eventually need a
bit settle to a "good" rate.
> 4.) I think to have this setup ready about 11:30 UTC.
I was at my workplace, I really couldn't do quicker than this..
Sorry.. I hope we are still in time...
> I'am open to any suggestion from your side.
Tests that may also help are:
- test performance regression when you are both close to the AP and
enough far from it that performances significantly drops.
- check if the rtl818x_pci driver and the old driver settles at
(about) the same rates..
>
> Bernhard
Thank you really much Bernhard for you help.
I hope this can lead to solve issues, and anyway I appreciate it very much :)
Andrea
> Am Freitag, 12. September 2014, 02:18:03 schrieb Andrea Merello:
>> My aplogies for this quick and a bit messy reply: I m from mobile.
>>
>> @Xose
>> Thank you for forwarding me that. I wasn t aware of it.
>>
>> (BTW a couple of other people reported a similar issue)
>>
>> @Ralf
>> The driver still have some not implemented features, including signal
>> strenght measure, furthermore some fixes that might improve performances
>> should be on the way for 3.17.
>>
>> @Larry, Bernhard
>> I think those fixes was basically the same of some RFT patch I sent you
>> some time ago..
>> Have you had any occasion to test those patches?
>>
>> @Ralf, all..
>> I must say that I never been able to reproduce any severe performance
>> regression here, for this reason I'm asking people who reports this to make
>> some testing for me if possible..
>>
>> Here you can find a similar report and my answer where I asked for the
>> tests:
>> https://bugzilla.kernel.org/show_bug.cgi?id=83631
>>
>> If you could do some of those test for me, that would be great.
>>
>
[-- Attachment #2: 0001-rtl818x_pci-backport-rtl8187se-fixes-to-3.16.patch --]
[-- Type: text/x-patch, Size: 3552 bytes --]
From 345b4fc7f22c4a83e2a481b65a8489ea2a475e5a Mon Sep 17 00:00:00 2001
From: Andrea Merello <andrea.merello@gmail.com>
Date: Fri, 12 Sep 2014 17:34:04 +0200
Subject: [PATCH] rtl818x_pci: backport rtl8187se fixes to 3.16
- Fix for packet retries wrong count and broken rate scaling
- Added memory barriers to ensure packet correctness
- Fixed BSSID register write fails on certain ASICs (not sure if any rtl8187se may be affected)
Signed-off-by: Andrea Merello <andrea.merello@gmail.com>
---
drivers/net/wireless/rtl818x/rtl8180/dev.c | 24 +++++++++++++++---------
1 file changed, 15 insertions(+), 9 deletions(-)
diff --git a/drivers/net/wireless/rtl818x/rtl8180/dev.c b/drivers/net/wireless/rtl818x/rtl8180/dev.c
index 2c1c02b..1efefcb 100644
--- a/drivers/net/wireless/rtl818x/rtl8180/dev.c
+++ b/drivers/net/wireless/rtl818x/rtl8180/dev.c
@@ -222,12 +222,20 @@ static void rtl8180_handle_rx(struct ieee80211_hw *dev)
struct rtl8187se_rx_desc *desc = entry;
flags = le32_to_cpu(desc->flags);
+ /* if ownership flag is set, then we can trust the
+ * HW has written other fields. We must not trust
+ * other descriptor data read before we checked (read)
+ * the ownership flag
+ */
+ rmb();
flags2 = le32_to_cpu(desc->flags2);
tsft = le64_to_cpu(desc->tsft);
} else {
struct rtl8180_rx_desc *desc = entry;
flags = le32_to_cpu(desc->flags);
+ /* same as above */
+ rmb();
flags2 = le32_to_cpu(desc->flags2);
tsft = le64_to_cpu(desc->tsft);
}
@@ -336,7 +344,6 @@ static void rtl8180_handle_tx(struct ieee80211_hw *dev, unsigned int prio)
info->flags |= IEEE80211_TX_STAT_ACK;
info->status.rates[0].count = (flags & 0xFF) + 1;
- info->status.rates[1].idx = -1;
ieee80211_tx_status_irqsafe(dev, skb);
if (ring->entries - skb_queue_len(&ring->queue) == 2)
@@ -528,9 +535,7 @@ static void rtl8180_tx(struct ieee80211_hw *dev,
entry->plcp_len = cpu_to_le16(plcp_len);
entry->tx_buf = cpu_to_le32(mapping);
- entry->flags2 = info->control.rates[1].idx >= 0 ?
- ieee80211_get_alt_retry_rate(dev, info, 0)->bitrate << 4 : 0;
- entry->retry_limit = info->control.rates[0].count;
+ entry->retry_limit = info->control.rates[0].count - 1;
/* We must be sure that tx_flags is written last because the HW
* looks at it to check if the rest of data is valid or not
@@ -852,7 +857,7 @@ static int rtl8180_init_hw(struct ieee80211_hw *dev)
if (priv->chip_family != RTL818X_CHIP_FAMILY_RTL8180) {
rtl818x_iowrite8(priv, &priv->map->WPA_CONF, 0);
- rtl818x_iowrite8(priv, &priv->map->RATE_FALLBACK, 0x81);
+ rtl818x_iowrite8(priv, &priv->map->RATE_FALLBACK, 0);
} else {
rtl818x_iowrite8(priv, &priv->map->SECURITY, 0);
@@ -1450,9 +1455,10 @@ static void rtl8180_bss_info_changed(struct ieee80211_hw *dev,
vif_priv = (struct rtl8180_vif *)&vif->drv_priv;
if (changed & BSS_CHANGED_BSSID) {
- for (i = 0; i < ETH_ALEN; i++)
- rtl818x_iowrite8(priv, &priv->map->BSSID[i],
- info->bssid[i]);
+ rtl818x_iowrite16(priv, (__le16 __iomem *)&priv->map->BSSID[0],
+ le16_to_cpu(*(__le16 *)info->bssid));
+ rtl818x_iowrite32(priv, (__le32 __iomem *)&priv->map->BSSID[2],
+ le32_to_cpu(*(__le32 *)(info->bssid + 2)));
if (is_valid_ether_addr(info->bssid)) {
if (vif->type == NL80211_IFTYPE_ADHOC)
@@ -1723,7 +1729,7 @@ static int rtl8180_probe(struct pci_dev *pdev,
priv = dev->priv;
priv->pdev = pdev;
- dev->max_rates = 2;
+ dev->max_rates = 1;
SET_IEEE80211_DEV(dev, &pdev->dev);
pci_set_drvdata(pdev, dev);
--
1.9.1
^ permalink raw reply related [flat|nested] 3+ messages in thread