Forum

Bonjour,
Je suis en Mageia 6.
Suis très embêté : depuis l'upgrade récent du kernel 4.9.56-desktop-1.mga6 vers le kernel 4.14.13-desk le pilote (rtl8812au) de ma clé USB Wifi NetGear AC600 (puce RealTek) n'est plus installé. En choisissant de revenir, au démarrage, au kernel 4.9.56-desktop-1.mga6, la clé est à nouveau opérationnelle, le retour au 4.14.13 la fait re-disparaître et ainsi de suite. Voici les traces que j'ai pu relever qui me paraissent importantes :

[root@localhost /]# lsusb
Bus 001 Device 004: ID 0846:9052 NetGear, Inc. A6100 AC600 DB Wireless Adapter [Realtek RTL8811AU]

[root@localhost /]# lspcidrake -v | grep -i real
r8169 : Realtek Semiconductor Co., Ltd.|RTL810xE PCI Express Fast Ethernet controller [NETWORK_ETHERNET] (vendor:10ec device:8136 subv:1462 subd:7529) (rev: 02)
unknown : Realtek |802.11ac WLAN Adapter (vendor:0846 device:9052)
[root@localhost /]#
===> le chip est repéré mais « unknown » (le premier interface est celui de mon câble ethernet) …..

[root@localhost ~]# iwconfig
enp3s0 no wireless extensions.
lo no wireless extensions.
[root@localhost ~]#

La trace dans /var/log/messages lors de l'insertion de la clé sous 4.9.56 ( --> clé opérationnelle) :

Jan 24 11:08:53 localhost kernel: [ 99.904017] usb 1-5: new high-speed USB device number 4 using ehci-pci
Jan 24 11:08:53 localhost kernel: [ 100.022415] usb 1-5: New USB device found, idVendor=0846, idProduct=9052
Jan 24 11:08:53 localhost kernel: [ 100.022417] usb 1-5: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Jan 24 11:08:53 localhost kernel: [ 100.022419] usb 1-5: Product: 802.11ac WLAN Adapter
Jan 24 11:08:53 localhost kernel: [ 100.022421] usb 1-5: Manufacturer: Realtek
Jan 24 11:08:53 localhost kernel: [ 100.022423] usb 1-5: SerialNumber: 00e04c000001
Jan 24 11:08:53 localhost mtp-probe: checking bus 1, device 4: "/sys/devices/pci0000:00/0000:00:1d.7/usb1/1-5"
Jan 24 11:08:53 localhost mtp-probe: bus: 1, device: 4 was not an MTP device
Jan 24 11:08:53 localhost systemd[1]: Listening on Load/Save RF Kill Switch Status /dev/rfkill Watch.
Jan 24 11:08:53 localhost kernel: [ 100.140291] RTL871X: module init start
Jan 24 11:08:53 localhost kernel: [ 100.140293] RTL871X: rtl8812au v4.3.20_16317.20160108
Jan 24 11:08:53 localhost kernel: [ 100.140294] RTL871X: build time: Oct 12 2017 22:22:54
Jan 24 11:08:53 localhost kernel: [ 100.188791] RTL871X: rtw_ndev_init(wlan0) if1 mac_addr=b0:39:56:6e:32:8c
Jan 24 11:08:53 localhost systemd[1]: Starting Load/Save RF Kill Switch Status...
Jan 24 11:08:53 localhost kernel: [ 100.189195] usbcore: registered new interface driver rtl8812au
Jan 24 11:08:53 localhost kernel: [ 100.189196] RTL871X: module init ret=0
Jan 24 11:08:53 localhost kernel: [ 100.209131] rtl8812au 1-5:1.0 wlp0s29f7u5: renamed from wlan0
Jan 24 11:08:53 localhost systemd-networkd[1026]: wlan0: Renamed to wlp0s29f7u5
Jan 24 11:08:53 localhost /usr/libexec/gdm-x-session[3370]: got connection status event: add wlp0s29f7u5
Jan 24 11:08:53 localhost systemd[1]: Started Load/Save RF Kill Switch Status.
Jan 24 11:08:53 localhost /usr/libexec/gdm-x-session[3370]: Use of uninitialized value in subroutine entry at /usr/lib/perl5/vendor_perl/5.22.2/x86_64-linux-thread-multi/Net/DBus/Binding/Connection.pm line 257.
Jan 24 11:08:53 localhost kernel: [ 100.522688] IPv6: ADDRCONF(NETDEV_UP): wlp0s29f7u5: link is not ready
Jan 24 11:08:53 localhost systemd-timesyncd[719]: Network configuration changed, trying to establish connection.
Jan 24 11:08:53 localhost kernel: [ 100.529271] IPv6: ADDRCONF(NETDEV_UP): wlp0s29f7u5: link is not ready
Jan 24 11:08:53 localhost kernel: [ 100.534712] RTL871X: set ssid [LOANE] fw_state=0x00000008
Jan 24 11:08:53 localhost ifplugd(wlp0s29f7u5)[4892]: ifplugd 0.28 initializing.
Jan 24 11:08:53 localhost ifplugd(wlp0s29f7u5)[4892]: Using interface wlp0s29f7u5/B0:39:56:6E:32:8C with driver <rtl8812au> (version: )
Jan 24 11:08:53 localhost ifplugd(wlp0s29f7u5)[4892]: Using detection mode: wireless extension
Jan 24 11:08:53 localhost ifplugd(wlp0s29f7u5)[4892]: Initialization complete, link beat not detected.

La trace dans /var/log/messages lors de l'insertion de la clé sous 4.14.13 ( --> clé non opérationnelle) :

Jan 22 11:22:24 localhost kernel: [ 1163.488181] usb 1-5: new high-speed USB device number 4 using ehci-pci
Jan 22 11:22:25 localhost kernel: [ 1163.616565] usb 1-5: New USB device found, idVendor=0846, idProduct=9052
Jan 22 11:22:25 localhost kernel: [ 1163.616567] usb 1-5: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Jan 22 11:22:25 localhost kernel: [ 1163.616569] usb 1-5: Product: 802.11ac WLAN Adapter
Jan 22 11:22:25 localhost kernel: [ 1163.616571] usb 1-5: Manufacturer: Realtek
Jan 22 11:22:25 localhost kernel: [ 1163.616572] usb 1-5: SerialNumber: 00e04c000001
Jan 22 11:22:25 localhost mtp-probe: checking bus 1, device 4: "/sys/devices/pci0000:00/0000:00:1d.7/usb1/1-5"
Jan 22 11:22:25 localhost mtp-probe: bus: 1, device: 4 was not an MTP device

Une idée ?
Merci pour votre aide

Bonjour,
Le système a perdu les références de ton matériel avec le nouveau noyau.
Il faut signaler ton problème avec un rapport dans le bugzilla. Les éléments que tu as fournis me semblent bien.
Comme rustine temporaire, tu peux regarder avec le noyau qui marche quel est le module qui fonctionne avec ta carte, à la place du "unknown", puis avec le nouveau noyau, charger le module de manière manuelle, en root :
modprobe <module>

Bonjour, et merci Yves pour cette explication. Je viens d'ailleurs de découvrir que ce problème a déjà sévi lors de l'upgrade du kernel 4.4.68 vers 4.4.xx et qu'il a été répertorié comme BUG-21043 ici : https://bugs.mageia.org/show_bug.cgi?id=21043
Je vais le re-signaler dans bugzilla et vais tenter la parade que tu suggères.
Cdlt,
Bret44

Re-bonjour,
Le chargement en mode manuel échoue :
[root@localhost ~]# modprobe 8812au
modprobe: FATAL: Module 8812au not found in directory /lib/modules/4.14.13-desktop-1.mga6
[root@localhost ~]#
Je n'insiste pas, j'attendrai la correction dans un prochain noyau, je vais faire le signalement dans bugzilla.
En attendant je peux rester sur le 4.9.56.
Cdlt,
Bret44

Re-bonjour,
J'ai initié le bug 22524 dans BugZilla : https://bugs.mageia.org/show_bug.cgi?id=22524
Cdlt,
Bret44

Bonjour,
Je pense que tu peux ajouter au rapport le fait que dans un cas, le module 8812au est chargé, et que dans l'autre cas, il ne l'est pas.
Le module est censé être dans :
/usr/lib/modules/<version du noyau>/kernel/drivers/net/wireless/realtek/rtlwifi/
Vérifie si tu le trouves dans les deux versions de noyau.

Bonsoir,
Non, rien ne concernant "8812au" dans le chemin /usr/lib/modules/<version du noyau>/kernel/drivers/net/wireless/ , dont voici le contenu dans les deux cas :
[root@localhost ~]# cd /lib/modules/4.14.16-desktop-1.mga6/kernel/net/wireless/ ; ls -al
total 224
drwxr-xr-x 2 root root 4096 févr. 6 10:33 ./
drwxr-xr-x 57 root root 4096 févr. 6 10:33 ../
-rw-r--r-- 1 root root 196856 janv. 31 21:51 cfg80211.ko.xz
-rw-r--r-- 1 root root 3960 janv. 31 21:51 lib80211_crypt_ccmp.ko.xz
-rw-r--r-- 1 root root 6552 janv. 31 21:51 lib80211_crypt_tkip.ko.xz
-rw-r--r-- 1 root root 3000 janv. 31 21:51 lib80211_crypt_wep.ko.xz
-rw-r--r-- 1 root root 2800 janv. 31 21:51 lib80211.ko.xz
[root@localhost wireless]# cd /lib/modules/4.9.56-desktop-1.mga6/kernel/net/wireless/ ; ls -al
total 196
drwxr-xr-x 2 root root 4096 nov. 18 15:59 ./
drwxr-xr-x 53 root root 4096 nov. 18 15:59 ../
-rw-r--r-- 1 root root 171920 oct. 13 01:05 cfg80211.ko.xz
-rw-r--r-- 1 root root 3664 oct. 13 01:05 lib80211_crypt_ccmp.ko.xz
-rw-r--r-- 1 root root 6148 oct. 13 01:05 lib80211_crypt_tkip.ko.xz
-rw-r--r-- 1 root root 2744 oct. 13 01:05 lib80211_crypt_wep.ko.xz
-rw-r--r-- 1 root root 2552 oct. 13 01:05 lib80211.ko.xz
[root@localhost wireless]#

Par contre, voici où on trouve "8812au" dans chacun des cas :

[root@localhost ~]# uname -a
Linux localhost 4.9.56-desktop-1.mga6 #1 SMP Thu Oct 12 22:55:31 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
[root@localhost /]# find / -name "*8812au*" | more
/sys/bus/usb/drivers/rtl8812au
/sys/module/8812au/drivers/usb:rtl8812au
/sys/module/usbcore/holders/8812au
/sys/module/cfg80211/holders/8812au
/usr/src/kernel-4.14.16-desktop-1.mga6/3rdparty/rtl8812au
/usr/src/kernel-4.14.13-desktop-1.mga6/3rdparty/rtl8812au
/usr/lib/modules/4.9.56-desktop-1.mga6/kernel/3rdparty/rtl8812au
/usr/lib/modules/4.9.56-desktop-1.mga6/kernel/3rdparty/rtl8812au/8812au.ko.xz

[root@localhost ~]# uname -a
Linux localhost 4.14.16-desktop-1.mga6 #1 SMP Wed Jan 31 20:50:08 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
[root@localhost ~]# find / -name "*8812au*" | more
/usr/src/kernel-4.14.16-desktop-1.mga6/3rdparty/rtl8812au
/usr/src/kernel-4.14.13-desktop-1.mga6/3rdparty/rtl8812au
/usr/lib/modules/4.9.56-desktop-1.mga6/kernel/3rdparty/rtl8812au
/usr/lib/modules/4.9.56-desktop-1.mga6/kernel/3rdparty/rtl8812au/8812au.ko.xz
[root@localhost ~]#

La différence est donc celle-ci ( i.e. cas 4.9.56 seulement ) :

/sys/bus/usb/drivers/rtl8812au
/sys/module/8812au/drivers/usb:rtl8812au
/sys/module/usbcore/holders/8812au
/sys/module/cfg80211/holders/8812au

Cdlt,
Bret44

Le dépôt core/updates_testing , par exemple celui-ci :
http://ftp-stud.hs-esslingen.de/pub/Mirrors/Mageia/distrib/6/x86_64/media/core/updates_testing

propose le noyau 4.14.18-desktop-1.mga6 (et les variantes server, ...). Dans l'arborescence,le pilote pour circuit 8812au est sur le même principe, en thirdparty, que le (fonctionnel) 4.9.56.

Il faudra (pour les noyaux suivants) espérer que les futures versions du noyau disposent du script de sélection modifié, autrement l'inconvénient se manifestera de nouveau.

Une fois la version 4.14.18 installée, il sera bon de désactiver le dépôt core/updates_testing, pour capter de nouveau les mises à jours (forcément supérieures le jour où elles y seront) validées traditionnelles de core/updates

Édité par alp1 Le 09/02/2018 à 10h39

Merci Alp1 pour ces précisions (que je ne suis pas capable d'appréhender complètement car je ne sais pas grand'chose de l'arborescence ou organisation du noyau).
Puisque je dispose d'une parade provisoire (le noyau 4.9.56) j'attendrai patiemment la mise à disposition officielle du 4.14.18.
Cordialement,
Bret44

Le kernel 4.14.18 disponible ce matin corrige le bug 22524, voir ici :
https://advisories.mageia.org/MGASA-2018-0125.html
Testé OK.
Merci à tous,
Bret44

Et merci à toi d'avoir pris la peine de créer un rapport de bogue.