Assigning.

CC: (none) => ouaurelien
Assignee: bugsquad => kernel
Source RPM: (none) => kernel-5.10.30-1.mga8.src.rpm
Target Milestone: --- => Mageia 9

https://github.com/Mange/rtl8192eu-linux-driver is actually using a newer version (5.6.4) and was also patched for 5.12 (https://github.com/Mange/rtl8192eu-linux-driver/pull/233) and dkms-rtl8192eu was already updated in Cauldron after that was committed

CC: (none) => pterjan

(In reply to Pascal Terjan from comment #2)
> https://github.com/Mange/rtl8192eu-linux-driver is actually using a newer
> version (5.6.4) and was also patched for 5.12
> (https://github.com/Mange/rtl8192eu-linux-driver/pull/233) and
> dkms-rtl8192eu was already updated in Cauldron after that was committed

Thank you for that information. But...

Changing this bug to Mageia 8 in light of Bug 28889, backporting the 5.12 series kernel to Mageia 8.

I have tested the first offering from that bug, and our current Mageia 8 dkms-rtl8192eu does not build successfully. I believe the Mageia 8 version of that driver should be updated to the same one as in Cauldron, assuming, of course, that it also works with the 5.10 series kernels currently in use.

I realize that backports do not carry the same guarantee that they will not break a system as ordinary updates do, but it seems to me we should not ignore known problems if there is a viable solution available. In addition, in this case I look at this update as simple insurance against breakage for the time when we may move beyond the 5.10 series kernel in Mageia 8. 

We COULD offer this as another backport, but I believe an update makes more sense.

Version: Cauldron => 8
Source RPM: kernel-5.10.30-1.mga8.src.rpm => dkms-rtl8192eu
Target Milestone: Mageia 9 => Mageia 8

What is the current status of this driver in MGA8? I need this driver update too and it looks like it is not even in testing yet (neither updates nor backports)...

CC: (none) => olelukoie

I've pushed  dkms-rtl8192eu-4.4.1-1.20210403.1.mga8 (the same as in cauldron) to mga8 updates_testing

please test it when it's available....

Updated my test system to kernel 5.10.37 and this driver in one operation. This system normally connects via Ethernet cable, so it took a bit of finagling, but once started the driver works Ok with the 5.10 series kernel.

Activated backports, and installed the 5.12.4 kernel and associated packages. After a reboot, the wifi connection came up and is working with no problems. Using it to write this comment.

Looks OK to me.

Confirming the new driver version works with both 5.10.37 & 5.12.4 kernels. Probably it needs a couple of days for more thorough testing on large downloads and uploads before promoting to updates...

I haven't found any problems with this version of driver so far and I think it can be promoted to updates.

(In reply to Thomas Backlund from comment #5)
> I've pushed  dkms-rtl8192eu-4.4.1-1.20210403.1.mga8 (the same as in
> cauldron) to mga8 updates_testing
> 
> please test it when it's available....

Did you forgot to assign to QA?

dkms-rtl8192eu-4.4.1-1.20210403.1.mga8 is still in updates_testing and here two persons tested it to be OK

CC: (none) => marja11, tmb

This driver will not work unless the rtl8xxxu module is blacklisted. Currently, the user has to do that manually. There is a lot of confusion about this, and users often believe the driver doesn't work because they miss this step. See bug 28404.

Before we pass this update on, is there some way we could take care of that automatically for the user? It seems to me like an excellent opportunity.

Please add the output of "lspcidrake -v|grep -i network".

CC: (none) => davidwhodgins

$ lsusb | grep Realtek
Bus 003 Device 002: ID 2357:0109 TP-Link TL-WN823N v2/v3 [Realtek RTL8192EU]

$ lspcidrake -v | grep Realtek
r8169           : Realtek Semiconductor Co., Ltd.|RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [NETWORK_ETHERNET] (vendor:10ec device:8168 subv:1458 subd:e000) (rev: 06)
rtl8192eu       : Realtek |802.11n NIC  (vendor:2357 device:0109)

Created attachment 12927 [details]
udev rule for dkms 8192eu usb wireless adaptor

Please remove or comment out the blacklisting.
Save the attached file as /etc/udev/rules.d/00-dkms-rtl8192eu.rules
and reboot.

Check lsmod to see if the rtl8xxxu module has been removed and the 8192eu
module loaded when the device is plugged in.

If that works, the file should be added to the package in the /usr/lib/udev/rules.d/ directory.

(In reply to Dave Hodgins from comment #14)

> Please remove or comment out the blacklisting.
> Save the attached file as /etc/udev/rules.d/00-dkms-rtl8192eu.rules
> and reboot.
> 
> Check lsmod to see if the rtl8xxxu module has been removed and the 8192eu
> module loaded when the device is plugged in.

Should it work at boot time too? I have this dongle connected permanently as it is connected to my desktop PC without built-in wifi adapter and I need it to connect to my home wifi network and Internet.

I think so.

hm,
udev should be able to load module on its own without extra rules for usb and pci devices as long as the driver exposes correct ids...

note that if you add a config file with

blacklist rtl8xxxu

you need to recreate the initrd after that so it gets added in early system loading

also, we need to test if this driver also builds with kernel 5.14 series as that is now in kernel and a first build is in backports_testing

I have a 64-bit Plasma system that has not used the rtl8192eu device before. I am trying to simulate an uninformed user trying to install this device. I already have it working on another install on this hardware, so I know it CAN work.

When I plug the device in, it wants to use the rtl8xxxu driver, which only partially works. A modified version of Dave's command gives me this:

$ lspcidrake -v|grep -i Realtek
r8169           : Realtek Semiconductor Co., Ltd.|RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [NETWORK_ETHERNET] (vendor:10ec device:8168 subv:1849 subd:8168) (rev: 03)
rtl8xxxu        : Realtek|802.11n NIC (vendor:0bda device:818b)

The first part IDs the Ethernet controller, so the last line is the applicable one. (Note that it is differenet from Oleg's output, even though the two devices are supposed to be using the same chip.)

I have already established that simply installing dkms-rtl8192eu will not work unless I manually blacklist the rtl8xxxu module.

Am I correct in thinking that if I install this rtl8192eu driver from updates_testing, and follow Dave's instructions from Comment 14, that it should then start to work? And that if it does, that would be the best way to automate the process?

(In reply to Thomas Backlund from comment #18)
> note that if you add a config file with
> 
> blacklist rtl8xxxu
> 
> you need to recreate the initrd after that so it gets added in early system
> loading
> 
Ah, I had forgotten that step.

> also, we need to test if this driver also builds with kernel 5.14 series as
> that is now in kernel and a first build is in backports_testing
I will see if I can try it out using another install where it is already working with the 5.10 series kernel.

Attempting to install any version of dkms-rtl8192eu on a system that does not already have a kernel-devel package installed brings you right up against Bug 29148. 
The driver pulls in the kernel-devel-latest packages from Backports instead of the ones from Core_updates as it is supposed to.

I don't think we can really push this update along, even if it is ready otherwise, until that bug is fixed.

Yes it is irritating, but most users do not have backports configured at all, so will not be affected.

CC: (none) => fri

I must disagree, Morgan. 

When users first install Mageia, at the step where the online repositories are configured, if they use our GUI tool all of the mirror's hdlists are downloaded. Backports, testing, debug, all are there, even if they have never been activated. 

If they installed Mageia at release time, there was nothing in Backports, and if they never activate backports they never update that and they don't run into the bug. But if they install now, or use the gui to switch to a different mirror, new hdlists are downloaded, and now backports are no longer empty. And that means that even if they never did anything with backports, they run into the bug if they install almost anything that involves a "latest" package. 

The system from Comment 21 was, until about a month ago, an old Mageia 7 test system. I made a new, clean install of Mageia 8 for testing purposes, clean rather than upgrade because I wanted to clear out all residue of old tests. 

Consequently, when I used the MCC tool to set up my mirror, the situation I described occurred. I have never done anything with backports on that system, other than set up the mirror with the gui. Many, if not most of our users are doing just that. They are not using the command line when one of our well-advertised Mageia tools is there.

Keep in mind that mgaapplet and urpmi.update -a will not update the lists for
disabled media, so if the mirror list was set up during install shortly after
Mageia 8 was released, the list of packages available in the backports repos
would be empty.

It's only if the repos are deleted (urpmi.removemedia -a) and re-added now that
the list of packages in the backports repos will be available for urpmi to
consider. Alternatively the disabled media may be updated using "urpmi.update e"
which works because all of or media (Core, Nonfree, and Tainted) contain the
letter e in as least one of the words it the repo's name.

(In reply to Thomas Andrews from comment #20)
> (In reply to Thomas Backlund from comment #18)
> 
> > also, we need to test if this driver also builds with kernel 5.14 series as
> > that is now in kernel and a first build is in backports_testing
> I will see if I can try it out using another install where it is already
> working with the 5.10 series kernel.

Sorry this took so long, but I finally decided to ignore bug 29148, and move on.

This driver/device DOES work with kernel-desktop 5.14.10 which is in core_backports now, as well as the 5.10.70 kernel. It seems to be necessary to boot with the device inserted. Hotplugging the device in a running system will not work. 

This system is one that was already working with 5.10 series kernel, by manually blacklisting the rtl8xxxu module. Also, I'm using Network Manager, as it handles multiple devices and connections better for me than our Network Center does.

As this one got stuck in limbo, I've updated it again for kernel 5.15 series, so the package to test is:

dkms-rtl8192eu-4.4.1-1.20211023.1.mga8.noarch.rpm


and really assigning to QA this time :)

Assignee: kernel => qa-bugs

First attempt at a test was to see if the driver would build and work with the 5.10.78 kernel. It failed.

I chose a 64-bit server kernel that already had a functioning dkms-rtl8192eu, whichever version that was designed with 5.10 series support. Using qarepo, I obtained the update package, and installed with MCC. It took a while to install, I assume because it was building the module, but it was eventually successful. Or so it appeared.

I tried booting with the device plugged in, using the esc key so I could see messages. It seemed to hang up with 2 "start jobs" for 5 minutes. Both jobs had to do with bringing up the network. It timed out, with a message to see "systemctl status network,service for details." I was unable to do this because a few seconds later it got to the "Terminate Plymouth boot screen" message, and it hung up there.

A boot with the device not plugged in was more successful. There was no long delay as it tried to bring up the network, but there was a message that it had failed. Systemctl status network gave me this:

● network.service - LSB: Bring up/down networking
     Loaded: loaded (/etc/rc.d/init.d/network; generated)
     Active: failed (Result: exit-code) since Sun 2021-11-14 15:51:10 EST; 1min 15s ago
       Docs: man:systemd-sysv-generator(8)
    Process: 1314 ExecStart=/etc/rc.d/init.d/network start (code=exited, status=1/FAILURE)
        CPU: 2.389s

Nov 14 15:51:10 localhost systemd-sysctl[1783]: Not setting net/ipv4/conf/all/rp_filter (explicit setting exists).
Nov 14 15:51:10 localhost systemd-sysctl[1783]: Not setting net/ipv4/conf/default/rp_filter (explicit setting exists).
Nov 14 15:51:10 localhost systemd-sysctl[1783]: Not setting net/ipv4/conf/all/accept_source_route (explicit setting exists).
Nov 14 15:51:10 localhost systemd-sysctl[1783]: Not setting net/ipv4/conf/default/accept_source_route (explicit setting exists).
Nov 14 15:51:10 localhost systemd-sysctl[1783]: Not setting net/ipv4/conf/all/promote_secondaries (explicit setting exists).
Nov 14 15:51:10 localhost systemd-sysctl[1783]: Not setting net/ipv4/conf/default/promote_secondaries (explicit setting exists).
Nov 14 15:51:10 localhost systemd[1]: network.service: Control process exited, code=exited, status=1/FAILURE
Nov 14 15:51:10 localhost systemd[1]: network.service: Failed with result 'exit-code'.
Nov 14 15:51:10 localhost systemd[1]: Failed to start LSB: Bring up/down networking.
Nov 14 15:51:10 localhost systemd[1]: network.service: Consumed 2.389s CPU time.

With the old driver, if I then plugged in the device I could use the net_applet to at least see that it was there, and usually connect. With this driver, if I hotplug the device there is essentially no response to clicking on the net_applet icon at all.

I have not yet tried the 5.15 kernel...

Another test, different hardware. This one is an AMD-based desktop, 64-bit Plasma, with an internal wifi card and using Network Manager. At the beginning of the test it was already using the dkms-rtl8192eu driver from Comment 5 with the 5,14.17 desktop kernel. Network Manager was successfully allowing the user to connect to the Internet with either the internal wifi card on both possible frequencies, or the usb dongle using the 2.6GHz frequency.

The first step this time was to use MCC to update to the 5.15.2 kernel in backports_testing. MCC had been run from a terminal so I could watch it happen. Everything went well, except that the rtl8192eu module did not build. Not unexpected, but I had to try, anyway.

Before rebooting, I used qarepo to get the dkms-rtl8192eu-4.4.1-1.20211023.1.mga8.noarch.rpm and updated. The terminal indicated that kernel modules were built for the 5.14.17 kernel, but nothing about the 5.15.2 kernel. I rebooted without plugging in the device, disabling "splash quiet." The kernel module for 5.15.2 was built and installed during the boot , or so the text told me. The system booted to a working desktop with a working Internet connection using the internal wifi card.

I plugged in the device, but unlike normal, Network Manager didn't seem to know it was there. I rebooted, this time with the device plugged in. While NM showed it as there this time, and allowed me to disconnect from the internal card and appeared to make a connection using the device, the connection wasn't functional.

A boot into the 5.14.17 kernel showed the same symptoms.

ok, looks like I need to rollback to the older version and patch it for 5.15 support then...

There is now a:
dkms-rtl8192eu-4.4.1-1.20210403.2.mga8

mirroring out...

with the following changes:
- roll back to working 20210403 snapshot
- add fixes for kernel 5.15 series
- add blacklisting of conflicting in-tree rtl8xxxu


now if you have installed the: dkms-rtl8192eu-4.4.1-1.20211023.1.mga8.noarch.rpm from testing you must manually un-install that as I rolled back the snapshot to earlier version

Since this version includes blacklisting the rtl8xxxu, what should I do with the blacklisting file I added myself to make earlier versions work? Does it need to be removed as well, or should things work anyway even if rtl8xxxu is blacklisted twice?

(In reply to Thomas Andrews from comment #31)
> Since this version includes blacklisting the rtl8xxxu, what should I do with
> the blacklisting file I added myself to make earlier versions work? Does it
> need to be removed as well, or should things work anyway even if rtl8xxxu is
> blacklisted twice?

Blacklisting twice will not cause a problem. However, to ensure it does not
interfere with possible future changes, and to ensure the contents of the
file from the package are correct, I'd remove the file from the earlier
testing, assuming it wasn't in a file called
/etc/modprobe.d/rtl8192eu-blacklist.conf

If that is the name previously used, best to uninstall it, delete the previous
file if not removed by uninstalling, and then re-install to ensure testing with
just the version from the package.

Testing on the same hardware as Comment 28. Removed dkms-rtl8192eu-4.4.1-1.20211023.1.mga8.noarch.rpm and removed the blacklist file I had added manually.

Installed dkms-rtl8192eu-4.4.1-1.20210403.2.mga8. Reports in the terminal indicated the module had been built and installed. Checked /etc/modprope.d and saw that the new blacklist file was there.

Rebooted to see Network Manager connect using the internal wifi card. Plugged in the device, and it was detected. Disconnected the internal wifi and told NM to connect using the usb dongle. NM reported it was connected, but Firefox could not connect to any sites. NM graph indicated no information was being transferred in either direction.

This is essentially the same behavior that was observed with dkms-rtl8192eu-4.4.1-1.20211023.1.mga8.noarch.rpm in Comment 28.

well, in comment 25 you wrote:

"It seems to be necessary to boot with the device inserted. Hotplugging the device in a running system will not work."

so does that work ?

Nope. That brings the system up with NM telling me that both devices are connected - internal and usb. Disconnecting the internal device shows the usb device as still connected, but not actually working, just like with Comment 33.

I even tried running "dracut -f" to rebuild the initrd, just in case. No joy there, either.

The internal device, Atheros-based, works normally.

so how come it worked in comment 25 then ?

It's now the exact same driver, and the code changes for 5.15 only takes effect if you build and use it with a 5.15 series kernel

oh, and for "no traffic passing"... are you sure the firewall allows traffic through the interface

oh, and are you testing with 5.10 or 5.15 series kernel ?

(In reply to Thomas Backlund from comment #38)
> oh, and are you testing with 5.10 or 5.15 series kernel ?

So far, just the 5.15 series. Will try with the 5.10 series in a bit.


"oh, and for "no traffic passing"... are you sure the firewall allows traffic through the interface"

No, and how to check is beyond my skill set. I just fumble along, but I assumed that because the internal wifi device is working normally, that things other than the rtl8192 driver were working. Of course, I DO know what is said about the word "assume..."



"so how come it worked in comment 25 then ?

It's now the exact same driver, and the code changes for 5.15 only takes effect if you build and use it with a 5.15 series kernel"

I dunno. Maybe because the kernel I used in Comment 25 was a 5.14 series kernel?

ok, so there might be some issue with 5.15 series as comment 25 references both 5.14.10 and 5.10.70...

can you confirm it works properly with latest 5.10 and 5.14 to confirm that ?

and provide dmesg from both working 5.10 / 5.14 and non-working 5.15 ...

It might be this one trips over some of the timing fixes that are queued for 5.15.3...

I'm going to find a nice wall to bang my head against. It started working, with all three kernels.

I did have to install kernel 5.10.78 to test that, but that shouldn't have made any difference. Only thing that I can think of was that because it was taking so much time to build, and I don't use it anyway, I removed openafs and dkms-libafs, leftover from a previous QA test. Could there be a conflict between the two modules? (BTW, the libafs module built without incident.)

If there could be a conflict, I'd be useless to try to find it, as I don't know anything about using openafs beyond a clean install.

Anyway, I will upload the three dmesg files, even though all three kernels are working now.

Created attachment 12988 [details]
dmesg from kernel-desktop 5.15.2

Created attachment 12989 [details]
dmesg from kernel-desktop 5.14.17

Created attachment 12990 [details]
dmesg from kernel-desktop 5.10.78

(In reply to Thomas Andrews from comment #41)

> I did have to install kernel 5.10.78 to test that, but that shouldn't have
> made any difference. Only thing that I can think of was that because it was
> taking so much time to build, and I don't use it anyway, I removed openafs
> and dkms-libafs, leftover from a previous QA test. Could there be a conflict
> between the two modules? (BTW, the libafs module built without incident.)
> 
Just to clarify, dkms-libafs was NOT installed when I wrote Comment 25.

Went back to the hardware/system from Comment 27 - i5-2500, Intel graphics, 5.10.78 server kernel, 64-bit Plasma, normally connected to the Internet via Ethernet cable. Dkms-libafs has never been installed on this system.

Removed the failed dkms-rtl8192eu from Comment 27, and re-installed the one that was designed for the 5.10 series kernel. Rebooted, and set things up to connect using the usb device. This system uses the net_applet, so some finagling is required, but it was successful.

Updated to dkms-rtl8192eu-4.4.1-1.20210403.2.mga8 without removing the blacklist file I created manually, and rebooted with the device inserted. The first connection attempt with the new driver said it was connected, but Firefox did not bring up the home page. Disconnecting and making a second attempt was fully successful. After that, the connection came up fully at boot for two more tries. Yet another boot, this time hot-plugging the device after the boot was finished, was also successful.

Rebooted once more, this time into the 5.10.70 server kernel. I saw a notice during the boot that the rtl8192eu driver was being built, and when it was finished the device worked with that kernel, as well.

Yet another test, this time on a "neglected" Xfce system that already has dkms-rtl8192eu installed, but has never had dkms-libafs. Same hardware as Comment 46, so the normal connection is via Ethernet.

Used qarepo to get the new dkms-rtl8192eu, and then proceeded to get updates for the system - 188 packages. That all installed successfully. A reboot into the new kernel showed the driver was again built successfully.

Enabled Backports_testing, and updated to the 5.15.2 kernel found there. The net_applet showed only the wired connection. After the usb device was hotplugged, it appeared as an option in the net_applet. I was able to successfully connect using the usb device, though it took two tries before it "took." (I'm thinking perhaps I didn't give it enough time to fully initialize before attempting to use it.)

More than enough testing. 

While there does seem to be an issue if both dkms-rtl8192eu and dkms-libafs are installed, the combination seems to be the only time the rtl driver fails. I would speculate that it more likely could be because dkms-libafs needs to be redone for the 5.15 series kernel, or because of the timing issues mentioned in Comment 40, than that dkms-rtl8192eu is at fault.

I'm going to OK this, and validate. Looks like the advisory information is in Comment 30.

CC: (none) => sysadmin-bugs
Keywords: (none) => validated_update
Whiteboard: (none) => MGA8-64-OK

An update for this issue has been pushed to the Mageia Updates repository.

https://advisories.mageia.org/MGAA-2021-0213.html

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