Bonjour,
Je n'arrive pas à charger correctement le firmware Realtek rtw88 pour la carte M.2 AzureWave RTL8822CE sur mon Nanopi R5C.
Voici la sortie de lspci -k
:
root@nanopi:~# lspci -k
0000:00:00.0 PCI bridge: Rockchip Electronics Co., Ltd RK3568 Remote Signal Processor (rev 01)
Kernel driver in use: pcieport
0000:01:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8822CE 802.11ac PCIe Wireless Network Adapter
Subsystem: AzureWave RTL8822CE 802.11ac PCIe Wireless Network Adapter
Kernel modules: rtw88_8822ce
0001:00:00.0 PCI bridge: Rockchip Electronics Co., Ltd RK3568 Remote Signal Processor (rev 01)
Kernel driver in use: pcieport
0001:01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8125 2.5GbE Controller (rev 05)
Subsystem: Realtek Semiconductor Co., Ltd. RTL8125 2.5GbE Controller
Kernel driver in use: r8169
Kernel modules: r8169, r8125
0002:00:00.0 PCI bridge: Rockchip Electronics Co., Ltd RK3568 Remote Signal Processor (rev 01)
Kernel driver in use: pcieport
0002:01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8125 2.5GbE Controller (rev 05)
Subsystem: Realtek Semiconductor Co., Ltd. RTL8125 2.5GbE Controller
Kernel driver in use: r8169
Kernel modules: r8169, r8125
On voit que pour le bus PCI 0000:01:00.0, le module rtw88_88ce a bien été identifié, mais n'est pas utilisé (il manque la ligne "Kernel driver in use" comme les deux ports ethernet).
La sortie de journalctl
donne :
kernel: pcieport 0000:00:00.0: bridge configuration invalid ([bus 00-00]), reconfiguring
kernel: pci 0000:01:00.0: [10ec:c822] type 00 class 0x028000
kernel: pci 0000:01:00.0: reg 0x10: [io 0x1000-0x10ff]
kernel: pci 0000:01:00.0: reg 0x18: [mem 0xf4300000-0xf430ffff 64bit]
kernel: pci 0000:01:00.0: supports D1 D2
kernel: pci 0000:01:00.0: PME# supported from D0 D1 D2 D3hot D3cold
kernel: pci_bus 0000:01: busn_res: [bus 01-ff] end is updated to 01
kernel: pcieport 0000:00:00.0: BAR 14: assigned [mem 0xf4300000-0xf43fffff]
kernel: pcieport 0000:00:00.0: BAR 13: assigned [io 0x1000-0x1fff]
kernel: pci 0000:01:00.0: BAR 0: assigned [io 0x1000-0x10ff]
kernel: rtw_8822ce 0000:01:00.0: enabling device (0000 -> 0003)
kernel: rtw_8822ce 0000:01:00.0: firmware: direct-loading firmware rtw88/rtw8822c_wow_fw.bin
kernel: rtw_8822ce 0000:01:00.0: WOW Firmware version 9.9.4, H2C version 15
kernel: rtw_8822ce 0000:01:00.0: firmware: direct-loading firmware rtw88/rtw8822c_fw.bin
kernel: rtw_8822ce 0000:01:00.0: Firmware version 9.9.15, H2C version 15
kernel: rtw_8822ce 0000:01:00.0: error beacon valid
kernel: rtw_8822ce 0000:01:00.0: failed to download rsvd page
kernel: rtw_8822ce 0000:01:00.0: failed to download firmware
kernel: rtw_8822ce 0000:01:00.0: failed to setup chip efuse info
kernel: rtw_8822ce 0000:01:00.0: failed to setup chip information
kernel: rtw_8822ce: probe of 0000:01:00.0 failed with error -16
J’ai une erreur : « error beacon valid », mais impossible de trouver de l’information là dessus.
Pouvez-vous m'aider à comprendre pourquoi ce firmware ne se charge pas correctement ?
Je ne sais pas comment avoir plus d'informations lors de la génération des logs. Peut-être est-il possible d'avoir un mode "debug" ?
# plutôt le firmware
Posté par BAud (site web personnel) . Évalué à 4.
c'est plutôt cette ligne qui est problématique
les commandes de déchargement / chargement du module1, avec une fenêtre terminal en parallèle avec un
journalctl -f
te permettront de voir les résultats en direct.te reste à trouver à quel endroit placer le
firmware^W micrologiciel pour qu'il soit chargé.ce qui est bizarre c'est que juste au-dessus, tu as les 3 lignes
peut-être y-a-t'il une version plus récente du module/micro-logiciel ? tu l'as installé comment ? un
modinfo rtw_8822ce
te donnera peut-être plus d'infos ? (et il manque ununame -a
pour avérer la version du noyau que tu utilises.c'est
modprobe -r rtw_8822ce
pour l'enlever aveclsmod |grep -iE "rtw|mac|80211"
pour le vérifier etmodprobe -i rtw_8822ce
pour le remettre ↩[^] # Re: plutôt le firmware
Posté par libresurf (site web personnel, Mastodon) . Évalué à 1.
Merci @Baud pour ton retour.
Voici la sortie de la commande
uname -a
:Voici la sortie de la commande
journalctl -f
suite à l'activation de la commandemodprobe -r rtw88_8822ce
:La commande
modprobe -r rtw88_8822ce
n'a pas retournée de message d'erreur.Voici la sortie de la commande
lsmod |grep -iE "rtw|mac|80211"
:Je recharge ensuite le module avec la commande
modprobe -i rtw88_8822ce
qui ne renvoie pas de message d'erreur et voici la sortie de la commandejournalctl -f
:Merde ! Ça a fonctionné !!!
Mais pourquoi, ça n'a pas marché du premier coup ???
Voici la commande
lspci -k -s 0000:01:00.0
qui montre que le firmware a bien été chargé et est utilisé par le kernel :Et pour aller jusqu'au bout, voici la sortie de la commande
modinfo rtw88_8822ce
:La question maintenant est de savoir pourquoi ça ne fonctionne pas du premier coup ???
Cela peut-il être dû à une mauvaise configuration de l'initramfs ?
[^] # Re: plutôt le firmware
Posté par libresurf (site web personnel, Mastodon) . Évalué à 1.
ARG ! Au secours !
J'ai redémarré le Nanopi R5C et recommencé la procédure, mais ça ne fonctionne plus !
Lorsque je supprime le module par la commande
modprobe -r rtw88_8822ce
, je n'ai plus les logs indiquant la désactivation de RFKILL.C'est peut-être là le problème… RFKILL ne se charge peut-être pas correctement et empêche l'activation du driver rtw_8822ce ???
Lorsque je recharge le module par la commande
modprobe -i rtw88_8822ce
, j'ai de nouveau les messages d'erreurs de chargement du module :et depuis impossible de recharger correctement le firmware…
[^] # Re: plutôt le firmware
Posté par BAud (site web personnel) . Évalué à 2.
tu as un module
rtw88_core
qui n'aurait pas dû rester après avoir enlevé le module wifi.le module
rfkill
est là pour activer / désactiver le wifi selon l'état d'un éventuel bouton pour gérer physiquement le wifi… la commanderfkill list
t'affiche sa stratégiele chargement des modules ne se fait peut-être pas dans l'ordre ou le rfkill désactive inopinément le wifi :/
tu peux essayer
modprobe -r rtw_8822ce rtw88_core mac80211 cfg80211
pour repartir d'une conf' sans prise en compte du wifi, puismodprobe -i rtw_8822ce
avec lelsmod
idoine lancé avant et après chaque action pour voir ce qui est chargé et dans quel ordre (ça devrait aussi apparaître dans lejournalctl -f
au fur et à mesure).note : tu avais écrit dans ton post
rtw88_8822ce
et nonrtw_8822ce
, pb de copier/coller ? c'est quoi la différence entre les deux ?cf. les lignes du
lspci
:Si ça a fonctionné au moins une fois, c'est que le firmware est bon a priori (et ton installation), mais pas forcément chargé au moment opportun et je ne vois pas trop pourquoi il charge 2 versions différentes (entre le 9.9.4 et le 9.9.15, tu noteras que ça fonctionne mieux quand il charge en premier le 15 puis le 4 o_O). Il faudra peut-être blacklister un module ou l'autre.
Ça devient de plus en plus compliqué à diagnostiquer les pb de modules noyaux entre
systemd
et les différentes dépendances entre modules :/[^] # Re: plutôt le firmware
Posté par BAud (site web personnel) . Évalué à 2. Dernière modification le 14 janvier 2024 à 19:07.
et la commande
lspci -knn
sera plus précise concernant ton matériel : cela indique vid:pid (vendor_id et product_id) qui servent pour identifier le module à blacklister…note : c'est un
modinfo rtw_8822ce
que j'avais demandé, ce n'est pas forcément le même quertw88_8822ce
:-)donc, bon, ça ressemble à 2 modules qui se battent pour prendre le contrôle du matériel, forcément ça se marche dessus :p
[^] # Re: plutôt le firmware
Posté par libresurf (site web personnel, Mastodon) . Évalué à 1.
Je vais essayer de prendre dans l'ordre…
La sortie de la commande
lspci -k -nn
:La sortie de la commande
rfkill list
:La sortie de la commande
modinfo rtw_8822ce
renvoie un message d'erreur :Je te donne le résultat d'une recherche générale sur le motif "rtw" :
rtw_8822ce est le nom d'un driver qui pour moi provient de /usr/lib/firmware/rtw88/rtw8822c_fw.bin
[^] # Re: plutôt le firmware
Posté par libresurf (site web personnel, Mastodon) . Évalué à 1. Dernière modification le 14 janvier 2024 à 22:08.
Voici la sortie de la commande
lsmod
avant la désinstallation des modules :Je désinstalle les modules :
Je réadapte la commande :
qui ne génère pas d'erreur.
journalctl -f
ne renvoie rien non plus.Je refais un
lsmod
:Je recharge le module :
Je réadapte la commande :
qui ne génère pas d'erreur.
La sortie de
journalctl -f
donne :Le firmware refuse encore une fois de se charger.
Je redonne la sortie de la commande
lsmod
:# lspci ne détecte pas la carte Wifi sans forcer un rescan
Posté par libresurf (site web personnel, Mastodon) . Évalué à 1.
Fait certainement non anodin,
lspci
ne détecte pas la carte Wifi sans forcer un rescan du bus.Après un reboot, voici ce que donne la commande
lspci -knn
:Il faut alors entrer la commande suivante pour forcer un nouveau scan du bus PCI :
La sortie de
journalctl -f
affiche le message d'erreur :Mais la commande
lspci -knn
donne maintenant :et on voit apparaître le carte Wifi, mais le driver n'est pas en cours d'utilisation par le noyau (il manque le ligne "Kernel driver in use" pour la carte AzureWave).
[^] # Re: lspci ne détecte pas la carte Wifi sans forcer un rescan
Posté par BAud (site web personnel) . Évalué à 2.
la commande
dmesg | grep -iE "wire|wifi|rtw|azure|rtl|net|c822|1a3b
devrait te donner des infos sur ce qui se passe au boot concernant ta carte wifi (globalement, essaie de filtrer tes sorties avecgrep
avant de les copier/coller sur le forum, c'est plus lisible, même s'il peut y avoir des infos autour :p).garde bien le
journalctl -f
dans une fenêtre terminal à côté : cela te permettra de mieux comprendre l'ordre des événements.[^] # Re: lspci ne détecte pas la carte Wifi sans forcer un rescan
Posté par libresurf (site web personnel, Mastodon) . Évalué à 1.
@BAud, voici la sortie de la commande demandée :
et après entré manuellement
echo 1 > /sys/bus/pci/rescan
:Avant le forçage du rescan du bus PCI, je ne vois rien qui puisse concerner la carte Wifi…
Par contre, je vois qu'il y a du NetworkManager, et ça ce n'est pas normal car je ne l'ai pas volontairement installé et mes paramètres réseaux sont configurés avec Systemd-networkd.
[^] # Re: lspci ne détecte pas la carte Wifi sans forcer un rescan
Posté par libresurf (site web personnel, Mastodon) . Évalué à 1.
Après vérification, NetworkManager n'est pas installé :
aptitude search '~i network'
ne renvoie rien./usr/lib/NetworkManager/ n'existe pas :
Le fichier de configuration en question est /etc/apparmor.d/sbin.dhclient qui vient du paquet isc-dhcp-client.
-> Fausse alerte…
[^] # Re: lspci ne détecte pas la carte Wifi sans forcer un rescan
Posté par libresurf (site web personnel, Mastodon) . Évalué à 1.
[on a le droit aux grossièretés sur ce forum, car là ça me démange grâve !
Bon, je vais rester poli…]
"Oh miracle !"
Comme j'utilise le service DHCP client fourni par Systemd, j'ai désinstallé le paquet isc-dhcp-client…
Je reboote et là : "Oh miracle !"
La carte Wifi est directement reconnue sans avoir à forcer un rescan du bus PCI et le firmware rtw_8822ce est correctement chargé !!!
C'était le service isc-dhcp-client qui posait problème !!!
[^] # Re: lspci ne détecte pas la carte Wifi sans forcer un rescan
Posté par libresurf (site web personnel, Mastodon) . Évalué à 1.
Je me fais des fausses joies.
En fait, la détection de la carte Wifi est totalement aléatoire et n'est pas assurée à chaque redémarrage du serveur NanoPi R5C.
[^] # Re: lspci ne détecte pas la carte Wifi sans forcer un rescan
Posté par libresurf (site web personnel, Mastodon) . Évalué à 1.
La suppression du paquet
isc-dhcp-client
a pour une raison inconnue chahuté la nomination des interfaces réseaux.J'ai réglé ça en forçant le nommage des interfaces par des fichiers .link dans /etc/systemd/network/.
Le système est maintenant stable et je confirme que c'était bien le paquet isc-dhcp-client qui posait problème.
Dans mon cas, ce dernier est automatiquement installé par debootstrap.
Lors de la création du debootstrap, il faut passer l'option "--exclude isc-dhcp-client".
[^] # Re: lspci ne détecte pas la carte Wifi sans forcer un rescan
Posté par BAud (site web personnel) . Évalué à 2.
bah
systemd
,dbus
et les dépendances, c'est une échelle posée sur un escabeau pour aller plus haut (ya un site d'images whatcouldgowrong là-dessus :p)tu peux détailler ?
moui le chargement des modules à la volée et de leur firmware complique le diagnostic de ce qui se passe…
ce serait bien d'avoir un schéma du déroulement de quand ça va bien et quand ça ne va pas bien pour fiabiliser définitivement quitte à mettre le nez dans le code :D
bah, t'es bon pour faire un nourjal sur ce que tu vas faire avec ta nanopi maintenant :p
[^] # Re: lspci ne détecte pas la carte Wifi sans forcer un rescan
Posté par libresurf (site web personnel, Mastodon) . Évalué à 1.
Bonjour @BAud,
C'est vrai que c'est très hasardeux et j'ai du mal à comprendre les interactions entre ces différents éléments.
Oui, voilà les différents fichiers pour les deux ports Ethernet et le wifi :
Liste des fichiers dans /etc/systemd/network/ :
10-ethernet_WAN.link
11-ethernet_LAN.link
13-WIFI.link
20-ethernet_WAN.network
21-ethernet_LAN.network
23-WIFI.network
Dans les fichiers .link, les balises Path correspondent ici au matériel du Nanopi R5C.
Le Nanopi R5C sert de routeur en deuxième front de ma box internet avec une délégation d'adresse IPv6 de ::/56.
Contenu du fichier /etc/systemd/network/10-ethernet_WAN.link :
Contenu du fichier _/etc/systemd/network/11-ethernet_LAN.link :
Contenu du fichier _/etc/systemd/network/13-WIFI.link :
Contenu du fichier _/etc/systemd/network/20-ethernet_WAN.network :
Contenu du fichier _/etc/systemd/network/21-ethernet_LAN.network :
Contenu du fichier _/etc/systemd/network/23-WIFI.network :
Cela est complété par démon d'annonce de routeurs (radvd), un serveur DHCP4 et DHCP6 (la suite kea) et un serveur de nom (named) qui sert de proxy vers le serveur DNS de la box internet.
Voici ce que donne la sortie de la commande
ip a
:Pour le moment, je n'ai rien branché côté LAN, d'où une interface pas complètement configurée.
Mais on voit bien les noms des différentes interfaces qui sont bien wan0, lan0 et wifi0.
Ce serait avec plaisir, mais je ne sais pas comment faire.
En tout cas, ça me permettrait de mieux comprendre le phénomène…
[^] # Re: lspci ne détecte pas la carte Wifi sans forcer un rescan
Posté par BAud (site web personnel) . Évalué à 2. Dernière modification le 17 janvier 2024 à 22:05.
bin le code est à disposition
https://github.com/lwfinger/rtw88
moui, c'est en anglais
[^] # Re: lspci ne détecte pas la carte Wifi sans forcer un rescan
Posté par libresurf (site web personnel, Mastodon) . Évalué à 1.
Merci @BAud, mais cela dépasse malheureusement mes compétences.
# ERRATUM : Complément à la solution
Posté par libresurf (site web personnel, Mastodon) . Évalué à 1.
ERRATUM : Complément à la solution
En refaisant des tests, je me suis aperçu que j'ai omis de préciser une étape capitale pour que la carte Wifi soit correctement reconnue.
En plus de supprimer le paquet isc-dhcp-client, il faut également supprimer le paquet isc-dhcp-common qui lui aussi est installé automatiquement par debootstrap !
Et plus important encore, il faut préciser à Systemd de continuer l'amorçage du système sans attendre que toutes les interfaces soient configurée !
Pour cela, il faut créer le fichier /etc/systemd/system/systemd-networkd-wait-online.service.d/wait-for-only-one-interface.conf
On commence par créer le répertoire ad-hoc :
et on crée dedans le fichier wait-for-only-one-interface.conf :
Le paramètre important ici est "--any" !
Et on redémarre le système !
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.