Description of problem: Wifi does not work with kernels 4.9.13 using RTL8192CE chip set based wireless card Version-Release number of selected component (if applicable): kernel-4.9.13-200.fc25.x86_64 kernel-4.9.13-201.fc25.x86_64 How reproducible: 100% Steps to Reproduce: 1. boot one of the two kernels listed above 2. try to connect to wireless network Actual results: - sometimes no wifi connection is established - sometimes link comes up but no internet connection can be established (large packet loss) Expected results: regular network connection over wifi Additional info: Latest 4.8.6 kernel (4.8.6-300.fc25.x86_64) works like a charm. "lsmod | grep -i rtl" rtl8192ce 57344 0 rtl_pci 28672 1 rtl8192ce rtl8192c_common 49152 1 rtl8192ce rtlwifi 73728 3 rtl_pci,rtl8192ce,rtl8192c_common mac80211 724992 3 rtl_pci,rtl8192ce,rtlwifi cfg80211 573440 2 mac80211,rtlwifi "lspci | grep -i Wireless" 04:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8192CE PCIe Wireless Network Adapter (rev 01)
Please compare the file name of the firmware being loaded for kernels that work and those that fail. There was a problem that was fixed, but I have no idea if the fix made it into Fedora kernels.
Larry, I think fix you reference is already included in 4.9.13: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/drivers/net/wireless/realtek/rtlwifi?h=linux-4.9.y&id=d2485c03ce8db7246e2b00cb8d9af82cea32ab60
Yes, that is the one I meant. I still need the OP to tell me which firmware versions are loaded by kernel 4.9.13 and 4.8.6. In addition, please post the output of "lspci -nn | grep -i Wireless" to identify exactly which RTL8192CE card is in play.
(In reply to Larry Finger from comment #3) > Yes, that is the one I meant. > > I still need the OP to tell me which firmware versions are loaded by kernel > 4.9.13 and 4.8.6. In addition, please post the output of "lspci -nn | grep > -i Wireless" to identify exactly which RTL8192CE card is in play. Here you are: 04:00.0 Network controller [0280]: Realtek Semiconductor Co., Ltd. RTL8192CE PCIe Wireless Network Adapter [10ec:8178] (rev 01)
You only provided part of what I needed.
What I sent you is the output of the command "lspci -nn | grep -i Wireless". What else do you need? Please let me know.
You need to provide what firmware file is loaded, this information is in dmesg. Just attach dmesg command output from working and non working kernel as text/plain attachment.
Created attachment 1265444 [details] dmesg_4.8.6-300
Created attachment 1265458 [details] dmesg_4.9.14-200
Thank you for posting the info that I requested. Both kernel versions are using the same firmware, thus that is not the problem. I just reviewed every change in rtlwifi and rtl8192ce between v4.8 and v4.11-rc3. Other that the firmware selection bug noted above, I can see no differences that could be causing the problem. I am now checking to see if I have any 10ec:8178 cards using firmware rtlwifi/rtl8192cfw.bin. To do that I have to reboot, but will update later.
Although I have 6 different chips that use this driver, none of them are the model of the OP's. As a result, I will not be able to debug this issue here. @Stanislaw: What options do we have to bisect this issue?
This depend where regression happen. If it happens between 4.8 and 4.9, it will require installing kernel from git source. If problem start to happen between 4.9 and 4.9.13 it will be enough to test builds from fedora koji and find two consecutive kernel versions to narrow regression. pjhavariotis, please check kernel from https://koji.fedoraproject.org/koji/buildinfo?buildID=824906 Download kernel kernel-core kernel-modules packages from above page and install via: rpm -ivh --force --nodeps kernel-4.9.0-1.fc26.x86_64.rpm kernel-modules-4.9.0-1.fc26.x86_64.rpm kernel-core-4.9.0-1.fc26.x86_64.rpm Then boot this kernel and check if it works.
Hello. I used branch general-4.9.x of https://github.com/FreedomBen/rtl8188ce-linux-driver.git with kernel 4.9.14 on Fedora. The described problems disappeared. The wifi link got never down for hours. Now I tried to use branch general-4.10.x on 4.10.5 kernel. Problems reappear also with the patched/altered driver. This is what I tried now (with both the Fedora provided and the other driver): modprobe rtl8192ce swenc=1 swlps=1 fwlps=0 debug=5 but modinfo afterwards says this: parm: fwlps:Set to 1 to use FW control power save (default 1) not so dmesg: [ 2392.078105] rtlwifi: rtlwifi: wireless switch is on [ 2392.084507] rtl8192ce 0000:25:00.0 wlo1: renamed from wlan0 [ 2392.109614] IPv6: ADDRCONF(NETDEV_UP): wlo1: link is not ready [ 2769.929952] rtl8192ce: rtl8192ce: Power Save off (module option) [ 2769.929953] rtl8192ce: rtl8192ce: FW Power Save off (module option) [ 2769.929970] rtl8192ce: Using firmware rtlwifi/rtl8192cfw.bin [ 2769.931095] ieee80211 phy0: Selected rate control algorithm 'rtl_rc' rtlwifi/rtl8192cfwU_B.bin is different from the Fedora provided kernel driver. I will try to get some more information later with the older kernel.
The only difference I can see with kernel 4.9.14 is the firmware used by the patched/altered driver: rtl8192ce: Using firmware rtlwifi/rtl8192cfwU.bin
Your module parameters are not wisely chosen. For example swenc=1 should only be used if you think that hardware encryption is broken. We see no indication of that. As for power save, using ips=0 to turn off ps might be instructive; however, switching from firmware to software ps using fwlps and swlps does not help. Using debug=5 will overwhelm you with output. Does the firmware version change between a kernel that works, and one that fails? This is a critical question!
The FreedomBen driver uses rtlwifi/rtl8192cfwU.bin only on 4.9.14 according to dmesg. I compared the firmware files with diff and found that rtlwifi/rtl8192cfwU_B.bin is different.
By the way I notice that another problem related to the driver has gone: stuttering audio. This is persistent on 4.10 kernel. It was caused definitly by wifi claiming cpu-time.
swenc=0 makes no difference on 4.10.5 and 4.10.6 with both drivers. "ips=0" and "swenc=1" was set as defaults in modprobe.d by the FreedomBen driver.
Ok. Sometimes things overlap. I now noticed that I always have a connection to the local side of the socket on kernel 4.10.x which was not the case in 4.9 when the connections dropped. I now think that the actual issues are more related to my environment after using the default kernel driver with standard settings for half an hour.
What does "a connection to the local side of the socket" mean? Does that mean you can ping the router? If so, that is all you can ask of the wireless driver.
Means I can ping my own ip on wlo1 but not the router. This was not possible on 4.9 and made me join this discussion after playing around with increased power from my router.
I again tested with kernel 4.10.11 which definitly shows the bad behaviour mentioned above of lost connectivity after a short period of time. There are no issues now with later kernel versions beginning from 4.11 onwards.
This message is a reminder that Fedora 25 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 25. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '25'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 25 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
The described problems disappeared.
Fedora 25 changed to end-of-life (EOL) status on 2017-12-12. Fedora 25 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.