Re: Rtl8187se regression [was: rtl8187se - serious regressions since merge out of staging into 818x]

Re: Rtl8187se regression [was: rtl8187se - serious regressions since merge out of staging into 818x]

[Bernhard Schiffner]

Hi Anrea, Larry,

I used the new driver (still without the latest patches) only in hotels slow 
DSL/Wireless environment and there I noted no regression.

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.

1.) Andrea, can you resend me the latest patches (perhaps against 3.16) 
please?
(only to confirm that we are in "synchronous" mode.)

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.)

3.) My test for maximal troughput is to run a connection /dev/zero -> nc ->|-> 
nc -> /dev/null.
Any other ideas?

4.) I think to have this setup ready about 11:30 UTC.

I'am open to any suggestion from your side.


Bernhard

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.
> 

Re: Rtl8187se regression [was: rtl8187se - serious regressions since merge out of staging into 818x]

[Andrea Merello]

[-- 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

Re: Rtl8187se regression [was: rtl8187se - serious regressions since merge out of staging into 818x]

[Larry Finger]

On 09/12/2014 11:29 AM, Andrea Merello wrote:
>> 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..

Hi,

I currently have a deadline to get some changes in rtlwifi into kernel 3.16, 
thus I have no time for testing the RTL8187SE. I do know that the whole issue of 
signal strength reporting for these chips is a problem.

Larry