Description of problem: Wireless connections established with 3.15 kernels is extremely unstable, slow, unreliable. The connection is not "formally" lost, still, pinging any external server shows that more than 75% of the packets are lost. Using any web browser is extremely difficult. Version-Release number of selected component (if applicable): Currently testing with kernel-3.15.0-1.fc21.x86_64. kernel-3.15.0-0.rc0.git5.1 is the last working kernel. How reproducible: Just browse or try to ping an external server Steps to Reproduce: 1.Connect via wireless 2.Try to use the connection 3.Experience extremely slow network activity Actual results: Unbearable Expected results: Good network activity Additional info: Here's the output of 'lspci -nnk | grep -iA6 net' 08:00.0 Network controller [0280]: Realtek Semiconductor Co., Ltd. RTL8188EE Wireless Network Adapter [10ec:8179] (rev 01) Subsystem: Hewlett-Packard Company Device [103c:197d] Kernel driver in use: rtl8188ee Kernel modules: rtl8188ee 09:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8101E/RTL8102E PCI Express Fast Ethernet controller [10ec:8136] (rev 08) Subsystem: Hewlett-Packard Company Device [103c:2164] Kernel driver in use: r8169
I've attempted to use 3.15.3-200.fc20.x86_64 for F20, I've the same issues. The connection is not unstable as in rawhide, but it's unbearable anyway. Since F20 is going to receive 3.15 (currently it's an updates candidate), I'm considering moving this bug from rawhide to F20. I've tested 3.16.0-0.rc3.git1.1 as well in rawhide, the wi-fi issue is still there.
As you mention using git kernels, is it possible for you to bisect this issue?
Well, kernel-3.15.0-0.rc0.git5.1.fc21 is the last "good" one, as I've reported at comment #1 I've noticed this issue starting with kernel-3.15.0-0.rc0.git6.1.fc21 I've tried to compare the drivers/net/wireless/rtlwifi/rtl8188ee folders in both the linux tarballs within the .src.rpm of kernel-3.15.0-0.rc0.git5.1.fc21 and kernel-3.15.0-0.rc0.git6.1.fc21, but it seems the driver itself wasn't touch between these two git versions (as far as I can tell).
I know there are no differences in rtl8188ee in that range. You cannot do the bisection with a tarball - you need the git repo. As I cannot duplicate your result, there is nothing I can do unless you can point to a specific commit that causes the problem.
So, I did bisect the issue with the git repo. I just need to test the last test kernel, but I believe that the first bad commit is: ------------------------ commit 2a54eb5e1476426ee639bbfbe179b52342a0d82c Author: Adam Lee <adam.lee> Date: Fri Mar 28 11:36:19 2014 +0800 rtlwifi: rtl8188ee: enable MSI interrupts mode Some HP notebooks using this rtl8188ee hardware module can't get AP scan results with pin-based interrupts mode, enabling MSI interrupts mode could fix it. As RealTek's testing results, RTL8188EE works well with both MSI mode and pin-based mode fallback. Signed-off-by: Adam Lee <adam.lee> Signed-off-by: John W. Linville <linville> ------------------- I was wrong in idenifying the regression window: the first bad kernel was kernel-3.15.0-0.rc0.git8.1.fc21, not kernel-3.15.0-0.rc0.git6.1.fc21 . It took a while and ten kernels, hope it helps
I confirm that 2a54eb5e1476426ee639bbfbe179b52342a0d82c introduced this bug, and the previous commit 94010fa0dd07e8b904e7c6b6589f15573008ab15 was indeed revised ( http://patchwork.ozlabs.org/patch/342069/ ) Anyway, whilst bisecting, I've noticed something different. It's true that "RTL8188EE modules could not connect to any wireless network after the MSI mode was enabled"; in fact, I've been completely unable to connect when I've encountered a bad kernel in my bisection tests. "journalctl -f" whilst attempting to connect constantly showed kernel: wlo1: deauthenticating from $BSSID by local choice (Reason: 3=DEAUTH_LEAVING) and kernel: wlo1: authentication with $BSSID timed out Still, I have to note that later kernels (with, I suppose, 94010fa0dd07e8b904e7c6b6589f15573008ab15 reverted: I tested 3.16.0-0.rc3.git1.1) can connect _but_ have serious issues (75% of packets lost, as I've mentioned in the bug report).
Someone other than me or Realtek decided to use MSI interrupts for the RTL8188EE. It works for some motherboards, but obviously not yours. Other cases fail with pin-based interrupts and must use MSI. Commit 3513d00 made the selection be a module parameter and set the default to off. Thus, that problem is fixed in 3.16. As to the loss of packets, I cannot duplicate your result. For the past 24 hours, I have been running my RTL8188EE using kernel 3.16-rc3 from wireless testing. It has had no problems, even when I used the link to do text editing over an ssh link. My ping results are 100 packets transmitted, 95 received, 5% packet loss, time 99122ms rtt min/avg/max/mdev = 3.496/49.166/1003.763/109.197 ms, pipe 2 The 5% loss is higher than I would like, but the link is usable. The AP in question is a Netgear WNDR3400V2 with WPA2 encryption with the "iwlist scan" signal quality/strength given as "Quality=36/70 Signal level=-74 dBm". My antennas are placed in a less than optimal position. After moving the antennas, I got "Quality=54/70 Signal level=-56 dBm". The ping results were 100 packets transmitted, 96 received, 4% packet loss, time 99126ms rtt min/avg/max/mdev = 1.843/18.815/276.407/38.659 ms The losses are still too high; however, the average response went from 49 to 18 ms. Obviously, -74 dBm indicated is near the minimum, and the performance is a lot better at -56 dBm.
I've rebuilt the latest rawhide kernel (available so far) on F20 ( 3.16.0-0.rc3.git3.1 ) and I'm glad to say that it works as expected. Anyway, the latest F20 kernel available in updates testing (3.15.3-200.fc20) as well as the first 3.16 kernel I tested (but in rawhide) (3.16.0-0.rc3.git1.1) did have this issue. In F20, with 3.15.3-200.fc20, it's possible to use the wi-fi connection but the connection is extremely sluggish, and it gets stuck for a few seconds every now and then. With a connection quality of 40/70 the packet loss is ~75%. Only if I place the laptop within ~3 meters from the AP I get a connection quality of ~50/70, and I still experience a huge packet loss: the best results are --- 8.8.8.8 ping statistics --- 123 packets transmitted, 85 received, 30% packet loss, time 122086ms rtt min/avg/max/mdev = 27.596/1491.870/16800.730/3340.508 ms, pipe 17 I'm (slowly) trying to identify a reverse regression window in order to understand what to expect from future builds
I'm seeing the same problem with an HP Envy 15 (mobo1962) using 3.15.6-200.fc20.x86_64 . Various tests show network throughput under 1Mbps. Not excessive packet loss. [root@mycena boot]# lshw -C network *-network description: Wireless interface product: RTL8188EE Wireless Network Adapter vendor: Realtek Semiconductor Co., Ltd. physical id: 0 bus info: pci@0000:01:00.0 logical name: wlo1 version: 01 serial: 34:23:87:27:33:c9 width: 64 bits clock: 33MHz capabilities: pm msi pciexpress bus_master cap_list ethernet physical wireless configuration: broadcast=yes driver=rtl8188ee driverversion=3.15.6-200.fc20.x86_64 firmware=N/A ip=192.168.42.153 latency=0 link=yes multicast=yes wireless=IEEE 802.11bgn resources: irq:48 ioport:5000(size=256) memory:b2600000-b2603fff ... [root@mycena boot]# iwconfig wlo1 wlo1 IEEE 802.11bgn ESSID:"darthbobo" Mode:Managed Frequency:2.437 GHz Access Point: 60:A4:4C:F1:51:00 Bit Rate=150 Mb/s Tx-Power=20 dBm Retry short limit:7 RTS thr=2347 B Fragment thr:off Encryption key:off Power Management:off Link Quality=70/70 Signal level=-36 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:12 Missed beacon:0 [root@mycena boot]# ip -s link show dev wlo1 3: wlo1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DORMANT group default qlen 1000 link/ether 34:23:87:27:33:c9 brd ff:ff:ff:ff:ff:ff RX: bytes packets errors dropped overrun mcast 95552458 86788 0 0 0 0 TX: bytes packets errors dropped carrier collsns 9966507 62449 0 0 0 0
Kernel 3.16.0-0.rc6.git2.1.fc21.x86_64 also works as expected. Note that "modprobe -r rtl8188ee;modprobe rtl8188ee" leaves the device in a state where it fails to successfully associate. However suspend/resume and hibernate/reboot work as expected.
The latest version of the Realtek driver is at http://gitcub.com/lwfinger/rtlwifi_new.git. I will be merging that code into the kernel, but it may take a while. The code will build on any kernel version 3.0 or newer. The usage is: git clone http://gitcub.com/lwfinger/rtlwifi_new.git cd rtlwifi_new make sudo modprobe -rv rtl8188ee sudo make install sudo modprobe -v rtl8188ee
To correct Larry Finger's notice. It's "github" not "gitcub". As he meant to say .... The latest version of the Realtek driver is at http://github.com/lwfinger/rtlwifi_new.git. I will be merging that code into the kernel, but it may take a while. The code will build on any kernel version 3.0 or newer. The usage is: git clone http://github.com/lwfinger/rtlwifi_new.git cd rtlwifi_new make sudo modprobe -rv rtl8188ee sudo make install sudo modprobe -v rtl8188ee
I've tested this new Realtek driver, it works fine so far.
I can confirm this bug and it's awesome destructive power. I've attempted to install the newest driver, per Steve Alexander's comment, however after make I recieve: make -C /lib/modules/3.15.10-200.fc20.x86_64/build M=/home/jamespaulsandel/Downloads/rtlwifi_new modules make: *** /lib/modules/3.15.10-200.fc20.x86_64/build: No such file or directory. Stop. make: *** [all] Error 2 The path to build does exist, and build is a symbolic link. Any suggestions as to how to get around this?
Using Larry Finger's driver on 3.15.10-200.fc20.x86_64 I'm seeing more disassociations/disconnects than I did with a 3.16 koji kernel. With previous 3.15... f20 drivers I was seeing difficulty associating, not disconnects. I realize there may be a lot of factors involve. Also, oddly some nearby WAPs do not appear in the NetworkManager list of WAPs. These same WAPs do appear in the "iwlist scan" output.
It appears that the scan operation (as in iwlist scan) does not function well when the device is associated with a WAP, when using Larry Finger's driver. Only catches the SSID broadcasts occasionally. Manually dis-dissociating the driver allows scans to succeed normally.
With the help of Steve Alexander: You need ... yum install kernel-devel-3.15.10-200.fc20.x86_64 you might also need, yum groupinstall 'Development Tools' I've installed this driver and it has solved my problems. I'm getting great connection and no visible problems.
Hi, everyone. Your efforts to resolve this are greatly appreciated however I have not been able to install the new driver. When I run: sudo yum modeprobe -v rtl8188ee I receive the following: modprobe: ERROR: could not insert 'rtl8188ee': Required key not available Could you point me in the right direction please? Thanks, Peter
Might be the easy to just build the entire kernel with your module and then just run it. You have the tools already. Give that a good. Will at least fix the signing bugger.
Before you rebuild the entire kernel, you can just try running 'strip -g' on the .ko file. That will remove any signature attached and unless you are booted in Secure Boot mode it should still load.
Thanks for the replies. I've tried the 'strip -g' method but still get the same message. Not tempted by a full kernel build as I've never had any luck with it in the past.
For the record, I would just like to say that comment 12 resolved my issues! I was having issues with my NetworkManager dropping my WiFi connection, but after installing the drivers from GitHub, it seems my issue has cleared up.
This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle. Changing version to '22'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 22 kernel bugs. Fedora 22 has now been rebased to 4.2.3-200.fc22. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 23, and are still experiencing this issue, please change the version to Fedora 23. If you experience different issues, please open a new bug report for those.
*********** MASS BUG UPDATE ************** This bug is being closed with INSUFFICIENT_DATA as there has not been a response in over 4 weeks. If you are still experiencing this issue, please reopen and attach the relevant data from the latest kernel you are running and any data that might have been requested previously.
Still doesn't work on F26. @Steve, how can non-technical users help push your driver in kernel, so it works out of the box?
(In reply to Marius Andreiana from comment #26) > @Steve, how can non-technical users help push your driver in kernel, so it > works out of the box? 1/ It's NOT my driver, but Larry Finger's (see above). 2/ You can address the issue by either opening a new bug report, or try the kernel wifi support maillists. As you'll see below, Mr.Finger is the contact on the kernel driver. https://wireless.wiki.kernel.org/en/developers/mailinglists https://wireless.wiki.kernel.org/en/users/drivers/rtl819x 3/ I don't think anything here represents more than a dirty work-around. The device SHOULD be able to scan while maintaining a connection. Strictly as a matter of problem avoidance rather than resolution; support for & performance of Realtek parts has persistently been problematic, and I would change the realtek wifi card with a well supported replacement if you intend to use Linux. For example a high-end intel 2+2 + bluetooth card might cost you ~$25USD and avoids driver issues.
We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. The kernel moves very fast so bugs may get fixed as part of a kernel update. Due to this, we are doing a mass bug update across all of the Fedora 26 kernel bugs. Fedora 26 has now been rebased to 4.15.4-200.fc26. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 27, and are still experiencing this issue, please change the version to Fedora 27. If you experience different issues, please open a new bug report for those.
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There are a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 27 kernel bugs. Fedora 27 has now been rebased to 4.17.7-100.fc27. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 28, and are still experiencing this issue, please change the version to Fedora 28. If you experience different issues, please open a new bug report for those.
We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 28 kernel bugs. Fedora 28 has now been rebased to 4.18.10-300.fc28. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 29, and are still experiencing this issue, please change the version to Fedora 29. If you experience different issues, please open a new bug report for those.
We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 29 kernel bugs. Fedora 29 has now been rebased to 4.19.5-300.fc29. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you experience different issues, please open a new bug report for those.
*********** MASS BUG UPDATE ************** This bug is being closed with INSUFFICIENT_DATA as there has not been a response in 3 weeks. If you are still experiencing this issue, please reopen and attach the relevant data from the latest kernel you are running and any data that might have been requested previously.