Updated: June 13, 2018
The reasons why we have gathered here are many. A few weeks ago, my CentOS distro went dead. With the new kernel containing Spectre patches, it refused to load the Realtek Wireless drivers into memory. Moreover, patches also prevent manual compilation. This makes the distro useless, as it has no network connection. Then, in my CentOS 7.4 upgrade article - which was flawless, including the network piece, go figure - I wondered about the use of new, modern 4.x kernels in CentOS. Sounds like we have a real incentive here.
In this tutorial, I will attempt to install and use the latest mainline kernel (4.16 when I typed this). The benefits should be many. I've seen improved performance, responsiveness and battery life in newer kernels compared to the 3.x branch. The Realtek Wireless woes of the disconnect kind (like a Spielberg movie) were also fixed in kernel 4.8.7 onwards, so that's another thing. Lastly, this would make CentOS a lean, mean and modern beast. Bravely onwards!
Install new kernel
There are several ways to do this. You can install and enable the elrepo repo, or you can install it and keep it disabled, but then only use it selectively to install the mainline kernel, like Fedora 28 does with third-party software. The packages, be they the kernel, the headers and the source are identifiable by the meta string ml-kernel*. A few commands, for your pleasure:
rpm --import https://www.elrepo.org/RPM-GPG-KEY-elrepo.org
rpm -Uvh http://www.elrepo.org/elrepo-release-7.0-3.el7.elrepo.noarch.rpm
yum --enablerepo=elrepo-kernel install kernel-ml
After the kernel package was installed, I rebooted into the main distro controlling the eight-boot sequence on the Lenovo G50 laptop (happened to be Xubuntu 17.10 right then), updated GRUB, and only then booted into CentOS 7.4, with the new kernel 4.16 in place. It worked.
Wireless issues are resolved
This is the first and most important finding. The Realtek RTL8723BE driver loads just fine. Whatever is in kernel 3.10.0-693 that prevents the module from loading and/or the compilation from source is not there in the mainline kernel 4.16, and we have a liftoff! This also means no more intermittent network disconnects under heavy load, as I used to report in pretty much any distro review until about kernel 4.8.7 or so. That's great.
Compilation
Just to feel complete, I decided to manually compile the Realtek driver from sources, to see that it's all as it should be. This did not seem to work at first.
make all
make -C /lib/modules/4.16.0-1.el7.elrepo.x86_64/build
M=/home/roger/Downloads/rtlwifi_new-master/rtl8723be modules
make: *** /lib/modules/4.16.0-1.el7.elrepo.x86_64/build: No such file or directory.
Stop.
yum --enablerepo=elrepo-kernel install kernel-ml-devel kernel-ml-headers
--> Processing Conflict: kernel-ml-headers-4.16.0-1.el7.elrepo.x86_64 conflicts
kernel-headers < 4.16.0-1.el7.elrepo
--> Finished Dependency Resolution
Error: kernel-ml-headers conflicts with kernel-headers-3.10.0-693.21.1.el7.x86_64
For some reason, the headers package conflicts with the 3.10 family, but then, you have the devel package, which still provides you with the necessary build environment for the compilation. We may discuss separately. What matters is the compilation. And then (with my own Makefile):
make
make -C /lib/modules/4.16.0-1.el7.elrepo.x86_64/build
M=/home/roger/Downloads/rtlwifi_new-master/rtl8723be modules
make[1]: Entering directory `/usr/src/kernels/4.16.0-1.el7.elrepo.x86_64'
Makefile:976: "Cannot use CONFIG_STACK_VALIDATION=y, please install libelf-dev, libelf-devel or
elfutils-libelf-devel"
CC [M] /home/roger/Downloads/rtlwifi_new-master/rtl8723be/dm.o
CC [M] /home/roger/Downloads/rtlwifi_new-master/rtl8723be/fw.o
CC [M] /home/roger/Downloads/rtlwifi_new-master/rtl8723be/hw.o
CC [M] /home/roger/Downloads/rtlwifi_new-master/rtl8723be/led.o
CC [M] /home/roger/Downloads/rtlwifi_new-master/rtl8723be/phy.o
CC [M] /home/roger/Downloads/rtlwifi_new-master/rtl8723be/pwrseq.o
CC [M] /home/roger/Downloads/rtlwifi_new-master/rtl8723be/pwrseqcmd.o
CC [M] /home/roger/Downloads/rtlwifi_new-master/rtl8723be/rf.o
CC [M] /home/roger/Downloads/rtlwifi_new-master/rtl8723be/sw.o
CC [M] /home/roger/Downloads/rtlwifi_new-master/rtl8723be/table.o
CC [M] /home/roger/Downloads/rtlwifi_new-master/rtl8723be/trx.o
LD [M] /home/roger/Downloads/rtlwifi_new-master/rtl8723be/rtl8723be.o
Building modules, stage 2.
MODPOST 1 modules
CC /home/roger/Downloads/rtlwifi_new-master/rtl8723be/rtl8723be.mod.o
LD [M] /home/roger/Downloads/rtlwifi_new-master/rtl8723be/rtl8723be.ko
make[1]: Leaving directory `/usr/src/kernels/4.16.0-1.el7.elrepo.x86_64'
So ... another problem fixed with the kernel update.
Performance
My next step was to test the system performance with kernel 4.16. Without looking at the system monitor, the desktop (Gnome in this case) does feel a little more responsive than before. Numbers wise, with the old 3.10 kernel, roughly two years ago, we had about 650 MB RAM usage on idle plus 3% CPU fidgetness. With kernel 4.16, the numbers are surprisingly different. About 1.1 GB on idle, and CPU using 10-12%. This could partially be attributed to the different themes that I'm using in Gnome, but I doubt it, given what I've seen with a range of recent Gnome desktops.
I decided to troubleshoot this some more. Most of it comes from X server process, which constantly eats cycles without doing anything. I even install xrestop, which is a small top-like utility to examine the X resource usage, but it did not show anything special. It's just what it is. Perhaps I could optimize this, but then, on one hand, the values are higher, on the other, the responsiveness is also better. So the penalty is only numerical.
Battery life
This is another interesting one. In the original review, we had roughly 2.5 hours, with a fresh battery that has not deteriorated. At that time, I tested with 100% brightness. Normally, going down to 50% brightness seems to add about 30-40 min life, from what I've seen in different tests.
Here, we have about 2.25 hours with a battery that has deteriorated to about 75% of its chemical capacity, which means, brand new, this battery and this kernel would probably amount to about 3-3.5 hours of juice, with 50% brightness and light desktop load. So despite the increase in memory usage and higher CPU activity, kernel 4.16 does not negatively impact the usage at the worst, and it even gives an extra half an hour in the best case. So the numbers aren't everything, and the end results are quite promising.
Other stuff
The system behavior was peachy. Everything worked. All the peripherals, sensors, suspend & resume. All the applications run just fine. There were no errors or crashes. Another thing that's worth mentioning is that an ancient Intel GPU issue also seems to be gone. It used to occasionally pop, but it's no more:
WARNING: at drivers/gpu/drm/i915/intel_display.c:10098 intel_check_page_flip+0xd8/0xf0 [i915]()
So, kernel 4.16, it's good for you, and you know it!
Conclusion
Now, I can breathe with relief, as I've delivered on my promise, and I gave you a full solution to the CentOS 7.4 Realtek issues post upgrade. I do not like to end articles on a cliffhanger, and definitely not carry the solution over to a follow-up article, but in this rare case, it was necessary. The mainline kernel upgrade is a topic of its own.
The kernel installation worked fine, and thereafter, we seem to have gained on many fronts. The network issues are fully resolved, we can compile again, the performance seems improved despite worse figures in the system monitor, battery life and stability are not impaired in any way, and the CentOS box has fresh new life, wrapped in modern features and latest software. And none of this was meant to be in the first place, because CentOS is a server distro. Well, I hope you are happy. The one outstanding mission - Plasma 5. Once we have that, we can proudly claim to have created the ultimate Linux distro hybrid monster. Take care.
Cheers.