[SOLVED] rtl8723be - weak signal on 4.16.x - fixed on 4.16.8-1

lo1 · 2018-04-21 20:20:15

FIXED in linux-4.16.8-1

Here's the commit: https://git.kernel.org/pub/scm/linux/ke … 0a87dc5081

You should set ant_sel parameter to 1 in order for the fix to be consistent.
----------------------------------------------------------------------------------------

Hi everyone,

as the subject states: experiencing poor throughput on linux 4.16.3-1 using an rtl8723be internal device.

I've read https://bbs.archlinux.org/viewtopic.php?id=236093 and I tried to troubleshoot this on my own by playing a bit with my modprobe parameters, but it didn't change a thing. The only helpful thing is downgrading to 4.15.x (yes, 4.16.x may have introduced some changes that doesn't play nicely with some wireless devices since I'm experiencing the same with 4.16.2-1).

With 4.15 I can get around 40MBps with no problems, while 4.16 caps me at 1~5 MBps in download.

How do you know it's the kernel?

As I said, downgrading to 4.15 is helpful, plus my other LAN devices are able to get the max available speed that my provider is allowing me to get.

What have you tried?

Changing ant_sel to anything between 0,1 and 2 with no effect, disabling and enabling msi, watchdog, powersaving features and such.

Why creating another thread?

I wasn't sure if it's better to make one big bug report (if this is a bug) complaining about every device which is affected or separating them by drivers (I prefer the last one indeed).

Let me know what else I can provide and thanks for reading this.

systool -avm rtl8723be
Module = "rtl8723be"

  Attributes:
    coresize            = "122880"
    initsize            = "0"
    initstate           = "live"
    refcnt              = "0"
    srcversion          = "562EA9BF76C2E3C14BFE74D"
    taint               = ""
    uevent              = <store method only>

  Parameters:
    ant_sel             = "2"
    aspm                = "0"
    debug_level         = "0"
    debug_mask          = "0"
    disable_watchdog    = "N"
    fwlps               = "N"
    ips                 = "N"
    msi                 = "N"
    swenc               = "N"
    swlps               = "N"

uname -a
Linux Arch 4.16.3-1-ARCH #1 SMP PREEMPT Thu Apr 19 09:17:56 UTC 2018 x86_64 GNU/Linux

sudo iw dev wlo1 station dump
Station bc:15:ac:e2:c3:ab (on wlo1)
	inactive time:	3066 ms
	rx bytes:	5959058
	rx packets:	20545
	tx bytes:	1072078
	tx packets:	3980
	tx retries:	0
	tx failed:	0
	beacon loss:	0
	rx drop misc:	815
	signal:  	-72 dBm
	signal avg:	-72 dBm
	tx bitrate:	72.2 MBit/s MCS 7 short GI
	rx bitrate:	1.0 MBit/s
	authorized:	yes
	authenticated:	yes
	associated:	yes
	preamble:	long
	WMM/WME:	yes
	MFP:		no
	TDLS peer:	no
	DTIM period:	3
	beacon interval:100
	short slot time:yes
	connected time:	918 seconds

sudo iw dev wlo1 info
Interface wlo1
	ifindex 3
	wdev 0x1
	addr 70:77:81:32:34:bf
	ssid Vodafone-47175426
	type managed
	wiphy 0
	channel 4 (2427 MHz), width: 20 MHz, center1: 2427 MHz
	txpower 20.00 dBm

dmesg: https://ptpb.pw/_044
journalctl -b: https://ptpb.pw/TiRt
lspci -k: https://ptpb.pw/TIhw
Please ignore the following, I was rushing:

[   14.002717] rtl8723be: unknown parameter 'msiN' ignored

Last edited by lo1 (2018-05-11 11:05:21)

loqs · 2018-04-21 21:16:26

4.15.14 did not have the issue? As that contains https://git.kernel.org/pub/scm/linux/ke … c134442514
Which is the only code change to the module from 4.15 to 4.16.3 https://git.kernel.org/pub/scm/linux/ke … ?h=v4.16.3
You could bisect between 4.15 and 4.16 and locate the cause that way.

lo1 · 2018-04-22 12:17:41

About bisecting, I'm not sure I would go that way: building on my hardware is not the most funny thing to do, sorry if I'm going lazy about it.

4.15.14 did not have the issue? As that contains https://git.kernel.org/pub/scm/linux/ke … c134442514

It doesn't make sense, but indeed this issue appears only on 4.16 and higher.

Anyway there's some news: If building the old dear https://github.com/lwfinger/rtlwifi_new (the master branch) and using them instead of the linux built-in, everything is back to normal.

Even more curious: it does contain the same commit https://github.com/lwfinger/rtlwifi_new … 09c66f8c35

But again, as I lack the will (and mostly the hardware) to make this bug chasing less painful, I'd stop here if this isn't enough to file a bug report.

Oh, and thank you again for your time.

EDIT: I was forgetting to post some code that proves the signal has come back to normal:

Linux Arch 4.16.3-1-ARCH #1 SMP PREEMPT Thu Apr 19 09:17:56 UTC 2018 x86_64 GNU/Linux

sudo iw dev wlo1 info
Interface wlo1
	ifindex 3
	wdev 0x1
	addr 70:77:81:32:34:bf
	ssid Vodafone-47175426
	type managed
	wiphy 0
	channel 4 (2427 MHz), width: 20 MHz, center1: 2427 MHz

sudo iw dev wlo1 station dump
Station bc:15:ac:e2:c3:ab (on wlo1)
	inactive time:	1860 ms
	rx bytes:	57804554
	rx packets:	55245
	tx bytes:	14576484
	tx packets:	33286
	tx retries:	0
	tx failed:	0
	beacon loss:	0
	rx drop misc:	102
	signal:  	-34 dBm      <<<<<<<<<<<<<
	signal avg:	-31 dBm     <<<<<<<<<<< notice that before they were both at -72dBm
	tx bitrate:	72.2 MBit/s MCS 7 short GI
	rx bitrate:	1.0 MBit/s
	authorized:	yes
	authenticated:	yes
	associated:	yes
	preamble:	long
	WMM/WME:	yes
	MFP:		no
	TDLS peer:	no
	DTIM period:	3
	beacon interval:100
	short slot time:yes
	connected time:	619 seconds

systool -avm rtl8723be
Module = "rtl8723be"

  Attributes:
    coresize            = "126976"
    initsize            = "0"
    initstate           = "live"
    refcnt              = "0"
    srcversion          = "1B45BB96576F0C4D6674527"
    taint               = "O"
    uevent              = <store method only>

  Parameters:
    ant_sel             = "2"
    debug               = "0"
    disable_watchdog    = "N"
    fwlps               = "N"
    ips                 = "N"
    msi                 = "N"
    swenc               = "N"
    swlps               = "N"

dmesg: https://ptpb.pw/r7ae
journalctl -b: https://ptpb.pw/lhNN

Last edited by lo1 (2018-04-22 12:24:06)

loqs · 2018-04-22 16:20:05

Try filing an issue on https://github.com/lwfinger/rtlwifi_new/ with what you have see if lwfinger responds.
Edit:
If you installed rtlwifi_new use sudo make install did it alter the firmware compared to that supplied by linux-firmware `pacman -Qkk linux-firmware`?

Last edited by loqs (2018-04-22 19:53:54)

lo1 · 2018-04-23 20:10:50

You mean like this? Yes, it did:

pacman -Qkk linux-firmware
warning: linux-firmware: /usr/lib/firmware/rtlwifi/rtl8188efw.bin (Modification time mismatch)
warning: linux-firmware: /usr/lib/firmware/rtlwifi/rtl8192cfw.bin (Modification time mismatch)
warning: linux-firmware: /usr/lib/firmware/rtlwifi/rtl8192cfwU.bin (Modification time mismatch)
warning: linux-firmware: /usr/lib/firmware/rtlwifi/rtl8192cfwU_B.bin (Modification time mismatch)
warning: linux-firmware: /usr/lib/firmware/rtlwifi/rtl8192defw.bin (Modification time mismatch)
warning: linux-firmware: /usr/lib/firmware/rtlwifi/rtl8192eefw.bin (Modification time mismatch)
warning: linux-firmware: /usr/lib/firmware/rtlwifi/rtl8192eefw.bin (Size mismatch)
warning: linux-firmware: /usr/lib/firmware/rtlwifi/rtl8192sefw.bin (Modification time mismatch)
warning: linux-firmware: /usr/lib/firmware/rtlwifi/rtl8723befw.bin (Modification time mismatch)
warning: linux-firmware: /usr/lib/firmware/rtlwifi/rtl8723befw.bin (Size mismatch)
warning: linux-firmware: /usr/lib/firmware/rtlwifi/rtl8723befw_36.bin (Modification time mismatch)
warning: linux-firmware: /usr/lib/firmware/rtlwifi/rtl8723fw.bin (Modification time mismatch)
warning: linux-firmware: /usr/lib/firmware/rtlwifi/rtl8723fw_B.bin (Modification time mismatch)
warning: linux-firmware: /usr/lib/firmware/rtlwifi/rtl8821aefw.bin (Modification time mismatch)
warning: linux-firmware: /usr/lib/firmware/rtlwifi/rtl8821aefw.bin (Size mismatch)
warning: linux-firmware: /usr/lib/firmware/rtlwifi/rtl8821aefw_29.bin (Modification time mismatch)
warning: linux-firmware: /usr/lib/firmware/rtlwifi/rtl8821aefw_wowlan.bin (Modification time mismatch)
linux-firmware: 1914 total files, 14 altered files

Should I just pacman -S linux-firmware (making sure I'm downloading it anew) or were you thinking about something else before?
Also, if you were wondering, here's my pacman log https://ptpb.pw/oLvV

loqs · 2018-04-23 20:28:20

It looks as though the firmware has been changed when you installed rtlwifi_new. If you reinstall linux-firmware does the rtlwifi_new driver then have the same speed issue as the kernel driver?

lo1 · 2018-04-23 20:53:37

loqs wrote:

It looks as though the firmware has been changed when you installed rtlwifi_new. If you reinstall linux-firmware does the rtlwifi_new driver then have the same speed issue as the kernel driver?

Well it seems so and nope, now the speed got restored. Thank you!

I'm still wondering how this could have happened, since I didn't mess with linux-firmware in any way (before installing rtl8723be from lwfinger). Also, can you explain what made you think that that was the issue?

loqs · 2018-04-23 21:11:26

As rtlwifi_new installs only two things the drivers and the firmware and the driver appeared to be the same I thought to examine the firmware instead.

lo1 · 2018-04-23 21:26:23

Mmh I see, anyway reinstalling linux-firmware solves this, but I just tried (redownloading) reinstalling again linux and linux-header (4.16.3-1) and the issue came back

Station bc:15:ac:e2:c3:ab (on wlo1)
	inactive time:	25053 ms
	rx bytes:	105652
	rx packets:	810
	tx bytes:	1073
	tx packets:	9
	tx retries:	0
	tx failed:	0
	beacon loss:	3
	rx drop misc:	0
	signal:  	-72 dBm
	signal avg:	-71 dBm
	tx bitrate:	7.2 MBit/s MCS 0 short GI
	rx bitrate:	1.0 MBit/s
	authorized:	yes
	authenticated:	yes
	associated:	yes
	preamble:	long
	WMM/WME:	yes
	MFP:		no
	TDLS peer:	no
	DTIM period:	3
	beacon interval:100
	short slot time:yes
	connected time:	55 seconds

So reinstalling linux-firmware made the warnings disappear, but reinstalling the kernel brings back (faulty?) drivers. I'm not sure what's the next step, for now I'll call it a day.

P.S. my current pacman mirror is http://archlinux.students.cs.unibo.it/$repo/os/$arch, it should be well trusted.

loqs · 2018-04-23 21:40:03

You could try https://aur.archlinux.org/packages/rtlwifi_new-dkms/ which will not overwrite linux-firmware and see if the out of tree driver then behaves the same as the in tree driver.

lo1 · 2018-04-26 11:31:33

loqs wrote:

You could try https://aur.archlinux.org/packages/rtlwifi_new-dkms/ which will not overwrite linux-firmware and see if the out of tree driver then behaves the same as the in tree driver.

It doesn't even seem to install correctly on 4.16.3-1: this is what I get when I issue `sudo modprobe rtl8723be_dkms` ( I tried both removing and leaving inserted the in-tree rtl8723be, the result is the same)

[   32.064611] rtl8723_common: Unknown symbol rtl_fw_page_write (err 0)
[   32.064654] rtl8723_common: disagrees about version of symbol _rtl_dbg_trace
[   32.064658] rtl8723_common: Unknown symbol _rtl_dbg_trace (err -22)
[   32.064744] rtl8723_common: Unknown symbol rtl_fill_dummy (err 0)

Out of curiosity, I tried to install it on linux 4.15.15 and it doesn't complain about those "unknown symbols".

I don't know if it's the correct behaviour but on 4.15.15 it lets me insert the dkms driver only on top of the in-tree rtl8723be (in short, I can't `modprobe rtl8723be_dkms` if I previously did `rmmod rtl8723be`).

For quick reference, my (default) kernel config is here

EDIT: issue persits on 4.16.4-1. Since no one else is experiencing the same problem, this has to do with my setup, and my gut's saying this has to do with antenna selection not being really selected with the in-tree firmware/module. I'm goint to troubleshoot this more on the weekend and come back to you with more details (and possibily, a solution).

Last edited by lo1 (2018-04-27 12:11:02)

wlo1 · 2018-04-29 18:00:00

lo1 wrote:

EDIT: issue persits on 4.16.4-1. Since no one else is experiencing the same problem, this has to do with my setup, and my gut's saying this has to do with antenna selection not being really selected with the in-tree firmware/module. I'm goint to troubleshoot this more on the weekend and come back to you with more details (and possibily, a solution).

I am also facing same issue since 4.16. Currently on 4.16.5-1-ARCH problem still exists.

emptyarray · 2018-05-02 03:14:57

I'm having the same issue. I'm going to attempt what was said above and report back.

wlo1 · 2018-05-02 19:06:03

emptyarray wrote:

I'm having the same issue. I'm going to attempt what was said above and report back.

Any Update?

For now I have downgraded to 4.15.15-1 Now WiFi is working perfectly.

lo1 · 2018-05-03 20:25:34

No update and yes, 4.15 works fine.

The right thing to do would be bisecting between 4.15 and 4.16 to find the problematic commit.

The not so right thing is to file a bug report anyway, but honestly I'm happy with the workaround I've found (which is, just install https://github.com/lwfinger/rtlwifi_new/ after every kernel update).

If you've got the right hardware to rebuild (several times) a linux kernel, go for it; last time it took ~12 hours to build on my laptop and I'm not going to do it again.

wlo1 · 2018-05-03 21:04:16

Have a look at this looks like this issue is know. https://bugzilla.kernel.org/show_bug.cgi?id=83641#c23

loqs · 2018-05-03 22:00:15

@wlo1 nice find https://git.kernel.org/pub/scm/linux/ke … 5fd2ca501a
from the net tree it should be picked up by mainline that will alow it to be backported to 4.16.y if 4.17 is not out by that time.
You could open a bug report asking for this patch to be applied to the arch kernel patch applies cleanly to 4.16.7.

lo1 · 2018-05-04 14:10:05

Really nice find wlo1, and thanks also to loqs for following this issue.

Anyway, I was reading our Reporting bug guidelines and I think that reporting a bug to patch the arch kernel may be seen as rude (such as "hurry up and fix this for me"), especially now that this has been officialy recognized and is going to be fixed upstream. I prefer to wait just a little bit for now until I can mark this thread as finally solved.

If this comes to nothing, then I'll file a bug report but feel free to disagree and do whatever you judge to be better.

Again, many thanks to everyone.

wlo1 · 2018-05-04 14:24:56

Ya, I also think it will be wise to wait until kernel is patched.

loqs · 2018-05-04 15:48:23

See https://git.archlinux.org/svntogit/pack … 72e69774c4 hetfig will apply patches from upstream before they make it through mainline and stable but can of course reject doing so.
It should appear in stable within the next few weeks / months if you choose to wait.

wlo1 · 2018-05-11 09:39:29

Update: Updating to 4.16.8-1-ARCH fixed the issue.
Also changed ant_sel value from 2 to 1. Now wifi is working perfectly.

loqs · 2018-05-11 09:51:43

https://git.kernel.org/pub/scm/linux/ke … 0a87dc5081

lo1 · 2018-05-11 11:02:38

Confirmed. Marking as definitely solved, adding the commit to the first post and changing the title of the thread so it's easier to find. Thanks again everyone!

notarobot · 2018-05-22 11:19:01

Hi. I have the same problem as you but it's not fixed with the new kernel (4.16.9-1-ARCH) or the ant_sel parameter (option 1 has weak signal, option 2 no signal at all). My wifi signal remains low and i'm facing frequent disconnects. Am i missing something?

Arch Linux

#1 2018-04-21 20:20:15

[SOLVED] rtl8723be - weak signal on 4.16.x - fixed on 4.16.8-1

#2 2018-04-21 21:16:26

Re: [SOLVED] rtl8723be - weak signal on 4.16.x - fixed on 4.16.8-1

#3 2018-04-22 12:17:41

Re: [SOLVED] rtl8723be - weak signal on 4.16.x - fixed on 4.16.8-1

#4 2018-04-22 16:20:05

Re: [SOLVED] rtl8723be - weak signal on 4.16.x - fixed on 4.16.8-1

#5 2018-04-23 20:10:50

Re: [SOLVED] rtl8723be - weak signal on 4.16.x - fixed on 4.16.8-1

#6 2018-04-23 20:28:20

Re: [SOLVED] rtl8723be - weak signal on 4.16.x - fixed on 4.16.8-1

#7 2018-04-23 20:53:37

Re: [SOLVED] rtl8723be - weak signal on 4.16.x - fixed on 4.16.8-1

#8 2018-04-23 21:11:26

Re: [SOLVED] rtl8723be - weak signal on 4.16.x - fixed on 4.16.8-1

#9 2018-04-23 21:26:23

Re: [SOLVED] rtl8723be - weak signal on 4.16.x - fixed on 4.16.8-1

#10 2018-04-23 21:40:03

Re: [SOLVED] rtl8723be - weak signal on 4.16.x - fixed on 4.16.8-1

#11 2018-04-26 11:31:33

Re: [SOLVED] rtl8723be - weak signal on 4.16.x - fixed on 4.16.8-1

#12 2018-04-29 18:00:00

Re: [SOLVED] rtl8723be - weak signal on 4.16.x - fixed on 4.16.8-1

#13 2018-05-02 03:14:57

Re: [SOLVED] rtl8723be - weak signal on 4.16.x - fixed on 4.16.8-1

#14 2018-05-02 19:06:03

Re: [SOLVED] rtl8723be - weak signal on 4.16.x - fixed on 4.16.8-1

#15 2018-05-03 20:25:34

Re: [SOLVED] rtl8723be - weak signal on 4.16.x - fixed on 4.16.8-1

#16 2018-05-03 21:04:16

Re: [SOLVED] rtl8723be - weak signal on 4.16.x - fixed on 4.16.8-1

#17 2018-05-03 22:00:15

Re: [SOLVED] rtl8723be - weak signal on 4.16.x - fixed on 4.16.8-1

#18 2018-05-04 14:10:05

Re: [SOLVED] rtl8723be - weak signal on 4.16.x - fixed on 4.16.8-1

#19 2018-05-04 14:24:56

Re: [SOLVED] rtl8723be - weak signal on 4.16.x - fixed on 4.16.8-1

#20 2018-05-04 15:48:23

Re: [SOLVED] rtl8723be - weak signal on 4.16.x - fixed on 4.16.8-1

#21 2018-05-11 09:39:29

Re: [SOLVED] rtl8723be - weak signal on 4.16.x - fixed on 4.16.8-1

#22 2018-05-11 09:51:43

Re: [SOLVED] rtl8723be - weak signal on 4.16.x - fixed on 4.16.8-1

#23 2018-05-11 11:02:38

Re: [SOLVED] rtl8723be - weak signal on 4.16.x - fixed on 4.16.8-1

#24 2018-05-22 11:19:01

Re: [SOLVED] rtl8723be - weak signal on 4.16.x - fixed on 4.16.8-1

Board footer