Bug 27418 - dkms-rtl8192eu update for kernel 5.9
Summary: dkms-rtl8192eu update for kernel 5.9
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: 7
Hardware: All Linux
Priority: Normal normal
Target Milestone: ---
Assignee: QA Team
QA Contact:
URL:
Whiteboard: MGA7-64-OK
Keywords: advisory, validated_update
Depends on:
Blocks:
 
Reported: 2020-10-14 23:22 CEST by David Walser
Modified: 2020-10-29 23:26 CET (History)
5 users (show)

See Also:
Source RPM: dkms-rtl8192eu-4.4.1-1.20200620.1.mga7.src.rpm
CVE:
Status comment:


Attachments

Description David Walser 2020-10-14 23:22:24 CEST
Advisory:
----------------------------------------

The dkms-rtl8192eu package has been updated to the latest snapshot as of
October 4th, with full support for the 5.9 series Linux kernels, bug fixes, and
other enhancements. See the upstream commit log for details.

References:
https://github.com/Mange/rtl8192eu-linux-driver/commits/realtek-4.4.x
----------------------------------------

Updated packages in core/updates_testing:
----------------------------------------
dkms-rtl8192eu-4.4.1-1.20201004.1.mga7

from dkms-rtl8192eu-4.4.1-1.20201004.1.mga7.src.rpm
Comment 1 Herman Viaene 2020-10-19 14:34:25 CEST
MGA7-64 Plasma on Lenovo B50
No installation issues
Running kernel 5.7.19 at first glance does not affect my wifi connection (Intel 3160)
I have (temporarily) a D-Link N300 Nano USB adapter available. I have been succesfull in making that one work in MGA7 some time before with some fiddling.
Now plugging the device in causes big problems, but can someone confirm me that this should work with the current kernel, or only with the 5.9 ????

CC: (none) => herman.viaene

Comment 2 David Walser 2020-10-19 14:37:01 CEST
Should still work with the current kernel, that's what QA should be testing.
Comment 3 Herman Viaene 2020-10-19 14:55:40 CEST
Here we go:
After installation I plug in the device and check in MCC-Hardware: still using the old rtl8xxx driver which does not work for this device. That's OK as I suppose the driver is still to be build.
So, leaving the device plugged in, I reboot. After some messages (I don't use the quiet and splash options in the boot) the screen geos black and nothing happens anymore. Pulling out the device, gives to lines mentioning the remove of the USB device, nothing further. Plugging in again, similar.
CTRL-ALT-delete forces boot (device still plugged in) , that one goes on, builds the rtl8192eu driver with success, but a few seconds later, same problem: black screen, no further progress.
Removing the device allows a good boot.
Right now trying what happens with MGA8, will report on this in bug 22599
Comment 4 David Walser 2020-10-19 14:57:43 CEST
Booting with a USB device plugged in can cause a number of problems, so I would wait until the system is booted to plug it in.
Comment 5 Herman Viaene 2020-10-19 15:09:35 CEST
Right, that's a known issue. But the driver needs to build once to start. Would the first boot build it if the device is not plugged in???
Comment 6 David Walser 2020-10-19 15:11:59 CEST
Yes, dkms builds at boot, it doesn't care if the device is present.
Comment 7 Herman Viaene 2020-10-19 15:24:01 CEST
As a side remark: my previous old Dell 32-bit test laptop had no onboard wifi, so a USB wifi adapter was plugged in all the time, that never ever caused any problem booting. Booting with an USB flash or rust drive causes problems most of the time, that is true.
Comment 8 Herman Viaene 2020-10-19 16:03:44 CEST
I have to correct myself: booting with the device plugged in eventually comes to an end.
After  doing tests with M8 on this laptop, rebooted M7 with the device inserted and went on to play a card game on my desktop PC. The boot runs with success after xxx minutes. I didn't do anything on the laptop, just rebooted, and now there are still delays in the process, but not that bad anymore.
But in MCC-Hardware there is still the rtl8xxx driver shown, and from the CLI I get:
# journalctl -b | grep rtl8192
Oct 19 15:47:36 mach5.hviaene.thuis kernel: usb 2-2: rtl8192eu_parse_efuse: dumping efuse (0x200 bytes):
Oct 19 15:47:36 mach5.hviaene.thuis kernel: usb 2-2: rtl8xxxu: Loading firmware rtlwifi/rtl8192eu_nic.bin
Oct 19 15:47:43 mach5.hviaene.thuis dkms-autorebuild.sh[778]: rtl8192eu (4.3.1.1_11320.20140505-4.mga7): Installing module.
Oct 19 15:47:43 mach5.hviaene.thuis dkms-autorebuild.sh[778]: dkms build -m rtl8192eu -v 4.3.1.1_11320.20140505-4.mga7 -k 5.7.19-desktop-1.mga7 -a x86_64 -q --no-clean-kernel

And "connection failed"
Comment 9 David Walser 2020-10-19 17:21:22 CEST
I wonder if you have to put something in one of the modprobe configuration files to get it to use this module.
Comment 10 Thomas Andrews 2020-10-19 20:05:37 CEST
Be aware that all rtl8192xx devices are not created equal. The two-letter suffix makes a difference. I have an rtl8192cu usb device, and it does not use this driver. Instead, it requires firmware contained in (IIRC) kernal-firmware-nonfree, and I suppose uses an open-source driver. 

All I have to do is plug it in and it "just works." I don't know what might happen if I had dkms-rtl8192eu installed with my device - possibly a conflict.

BTW, I just tried booting my desktop (wired connection) with the 8192cu device inserted, and it failed to boot. It doesn't fail on other machines if there's no wired connection, however.

CC: (none) => andrewsfarm

Comment 11 Herman Viaene 2020-10-20 08:53:16 CEST
I remember that when I had to download the driver, I had to blacklist the rtl8xxx driver. I cann't remember about other modprobe manipulations. It was not on my own laptop, and I made a note on that machine, but I cann't get to that one shortly.
Comment 12 Dave Hodgins 2020-10-29 21:24:13 CET
It installs and compiles cleanly. Validating based on that.

CC: (none) => davidwhodgins, sysadmin-bugs
Whiteboard: (none) => MGA7-64-OK
Keywords: (none) => validated_update

Comment 13 Aurelien Oudelet 2020-10-29 21:31:49 CET
Advisory pushed to SVN.

Keywords: (none) => advisory
CC: (none) => ouaurelien

Comment 14 Mageia Robot 2020-10-29 23:26:18 CET
An update for this issue has been pushed to the Mageia Updates repository.

https://advisories.mageia.org/MGAA-2020-0221.html

Resolution: (none) => FIXED
Status: NEW => RESOLVED


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