Bug 1108801 - rtl8188ee, wireless connection highly unstable starting from kernel 3.15
Summary: rtl8188ee, wireless connection highly unstable starting from kernel 3.15
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 29
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: fedora-kernel-wireless-realtek
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-06-12 15:14 UTC by mfs-it2
Modified: 2019-10-24 02:46 UTC (History)
15 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1409631 (view as bug list)
Environment:
Last Closed: 2019-09-17 20:06:03 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description mfs-it2 2014-06-12 15:14:28 UTC
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

Comment 1 mfs-it2 2014-07-02 19:08:15 UTC
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.

Comment 2 Larry Finger 2014-07-02 21:03:49 UTC
As you mention using git kernels, is it possible for you to bisect this issue?

Comment 3 mfs-it2 2014-07-02 22:20:33 UTC
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).

Comment 4 Larry Finger 2014-07-02 23:30:00 UTC
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.

Comment 5 mfs-it2 2014-07-05 19:44:09 UTC
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

Comment 6 mfs-it2 2014-07-05 20:22:00 UTC
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).

Comment 7 Larry Finger 2014-07-06 01:08:31 UTC
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.

Comment 8 mfs-it2 2014-07-07 13:18:02 UTC
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

Comment 9 Stephen J Alexander 2014-07-25 19:27:16 UTC
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

Comment 10 Stephen J Alexander 2014-07-26 06:45:10 UTC
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.

Comment 11 Larry Finger 2014-08-07 19:02:56 UTC
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

Comment 12 Stephen J Alexander 2014-08-10 21:40:03 UTC
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

Comment 13 mfs-it2 2014-08-14 19:47:52 UTC
I've tested this new Realtek driver, it works fine so far.

Comment 14 Paul Sandel 2014-08-21 13:09:52 UTC
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?

Comment 15 Stephen J Alexander 2014-08-22 07:02:47 UTC
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.

Comment 16 Stephen J Alexander 2014-08-22 07:36:59 UTC
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.

Comment 17 Paul Sandel 2014-08-22 14:59:25 UTC
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.

Comment 18 Peter 2014-08-28 19:45:14 UTC
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

Comment 19 John Greene 2014-08-29 13:11:56 UTC
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.

Comment 20 Josh Boyer 2014-08-29 13:14:30 UTC
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.

Comment 21 Peter 2014-09-02 19:14:56 UTC
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.

Comment 22 Justin W. Flory (Fedora) 2014-09-04 21:25:46 UTC
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.

Comment 23 Jaroslav Reznik 2015-03-03 16:01:37 UTC
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

Comment 24 Justin M. Forbes 2015-10-20 19:27:38 UTC
*********** 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.

Comment 25 Fedora Kernel Team 2015-11-23 17:15:40 UTC
*********** 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.

Comment 26 Marius Andreiana 2017-07-12 09:42:33 UTC
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?

Comment 27 Stephen J Alexander 2017-07-14 02:43:45 UTC
(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.

Comment 28 Laura Abbott 2018-02-28 03:47:26 UTC
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.

Comment 29 Justin M. Forbes 2018-07-23 15:11:56 UTC
*********** 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.

Comment 30 Laura Abbott 2018-10-01 21:21:16 UTC
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.

Comment 31 Jeremy Cline 2018-12-03 17:34:19 UTC
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.

Comment 32 Justin M. Forbes 2019-09-17 20:06:03 UTC
*********** 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.


Note You need to log in before you can comment on or make changes to this bug.