You are not logged in.
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)
Offline
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.
Offline
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)
Offline
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)
Offline
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
Offline
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?
Offline
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?
Offline
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.
Offline
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.
Offline
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.
Offline
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)
Offline
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.
Offline
I'm having the same issue. I'm going to attempt what was said above and report back.
Offline
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.
Offline
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.
Offline
Have a look at this looks like this issue is know. https://bugzilla.kernel.org/show_bug.cgi?id=83641#c23
Offline
@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.
Offline
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.
Offline
Ya, I also think it will be wise to wait until kernel is patched.
Offline
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.
Offline
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.
Offline
Offline
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!
Offline
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?
Offline