Errors after installing rtl8821ce drivers

Ask Fedora
1

Hello! I am using Fedora 38 on my laptop. After installing the drivers on the Wi Fi network card, I get the following errors:

A kernel problem occurred, but your kernel has been tainted (flags:PWOE). Explanation:
P - Proprietary module has been loaded.
W - Taint on warning.
O - Out-of-tree module has been loaded.
E - Unsigned module has been loaded.
Kernel maintainers are unable to diagnose tainted reports. Tainted modules: nvidia_drm,nvidia_modeset,nvidia_uvm,nvidia,8821ce

The drivers were installed from here - GitHub - tomaspinho/rtl8821ce
Those that come with the kernel work very poorly and lose the signal, which is why I disabled them by adding the module at the kernel level to the blacklist.
Secure boot is disabled. Kernel version - Linux fedora 6.2.15-300.fc38.x86_64 #1 SMP PREEMPT_DYNAMIC Thu May 11 17:37:39 UTC 2023 x86_64 GNU/Linux
Is it really possible to fix it?
I also attach this - https://paste.centos.org/view/2011707d

I’m sorry for my poor knowledge of English. I’m not very good at writing on it

2

Found another similar thread from 2020, this post was marked as the solution - Install Realtek RTL8821CE WiFi Driver - #6 by vgaetera.

3

Hmm, now I get this error:

The backtrace does not contain enough meaningful function frames to be reported. It is annoying but it does not necessarily indicate a problem with your computer. ABRT will not allow you to create a report in a bug tracking system but you can contact kernel maintainers via e-mail.

I also attach this - UNTITLED - Pastebin Service, [ 0.000000] microcode: microcode updated early to revision 0xf2, date = 2022- - Pastebin.com

4

Check - have you rebooted your computer after driver installation?

5

Yes. These errors appear every time after the device is rebooted

6

As I have no such chipset, I cannot help much, but I found one more thread on the same topic - Fedora 37 - Can't have wifi properly working - Realtek 8821CE - #2 by glb

7

Alas, the error persists…

8

You can suppress the error:

echo "OnlyFatalMCE = yes
DropNotReportableOopses = yes" | sudo tee /etc/abrt/plugins/oops.conf

This should do.

9

Regardless of errors, does your WiFi works ? Can you connect AP, access LAN, internet resources ? Sometimes you get errors to logs but component is basically functional.

10

Yes, Wi-Fi, bluetooth, etc. works fine. Annoying errors that I get at startup

11

Will this affect other more important warnings and errors in the future?

12

Some of errors are normal, especially in relation to radio (WiFi, BT) as there is interference, channel congestion, etc. Communication protocols normally are resilient to some types/degree of errors and have corrective mechanisms (e.g., re-transmission), but they will still report errors in case user/admin will need to debug specific situations.
Initialization of HW sometimes also throw errors, e.g., firmware/driver could not initialize in most optimal way, but in many of such cases there is a fallback mode, with less optimal initialization, and HW still does its job.
Summarizing the above:

  • It is good practice to check logs for errors and look for solutions
  • Not all errors are critical, some are more like “complains”, and if your components are working as expected - there is noting to worry about
13

Hmm, do you think it’s easier not to pay attention to the error?

14

Which one ? I found only these two in the log you provided to pastebin:

  1. [ 0.007216] [Firmware Bug]: TSC ADJUST differs within socket(s), fixing all errors
  2. [ 1.246748] RAS: Correctable Errors collector initialized.

For the first one there is no more/additional information on what errors were fixed. Internet search gave me couple results where there was more info on what was fixed, e.g., 199583 – [Firmware Bug]: TSC ADJUST differs within socket(s), fixing all errors & ACPI Error[SDS0]. That’s not the case in your case.

For the second one I found this - Reddit - Dive into anything, I see nothing critical/dangerous.

You will have to make the decision whether to ignore those errors or not yourself, but if that was my case and if my machine was working normally (no crashes, strange behavior, etc.) - I’d ignore it.

15

It should drop the errors that cannot be reported, and only include Fatal (as in serious) MCEs.
From the manpage of abrt-oops.conf

DESCRIPTION
       The configuration file consists of items in the format "Option = Value". The following items are recognized:

       DropNotReportableOopses = yes/no
           If enabled, ABRT will preserve only reportable oopses.

           Default is no, keep all oopses.

       OnlyFatalMCE = yes/no
           Many Machine Check Exceptions can be corrected and are thus not interesting to users. Moreover, some hardware may produce plenty of MCEs by design. Enabling this option will
           configure ABRT to detect only the fatal MCEs.

           Default is no, detect all MCEs.

There is no way I know of to fix the error, reporting to the devs may help.