Bonjour à toute la communauté,
Je me permets de solliciter votre expertise pour un problème d’instabilité sur mon ordinateur portable Asus Zenbook Duo (UX481FA) qui me laisse perplexe après de très nombreuses tentatives de résolution.
Voici un résumé du problème :
Mon système Fedora Linux devient instable uniquement après une sortie de veille. L’extinction ou le redémarrage échoue systématiquement, me forçant à forcé l’arrêt avec un appui long sur lo bouton « power ». Le problème persiste malgré le remplacement du SSD par un neuf, un test de RAM complet (0 erreur), une réinstallation propre de l’OS et une réinstallation de la dernière version du BIOS fourni par Asus. Le système fonctionne parfaitement sous Windows et depuis une clé USB Live Linux, ce qui me fait fortement penser à un bug du firmware BIOS/UEFI dans son interaction avec le noyau Linux. Je cherche maintenant des pistes pour contourner ce bug, ou un moyen de changer complètement le BIOS pour un Open Source si c’est possible.
Par étape :
Je mets l’ordinateur en veille (“suspend”).
À la sortie de veille, la session semble se restaurer, mais elle est instable : des applications se bloquent, le terminal peut mettre du temps à répondre, de nouvelles applications refusent de se lancer.
Si j’essaie d’éteindre ou de redémarrer l’ordinateur via l’interface graphique ou la ligne de commande, le processus échoue. L’écran affiche une cascade de messages d’erreur [FAILED], notamment :
[FAILED] Failed to start plymouth-reboot.service
[FAILED] Failed unmounting /home.mount
[FAILED] Failed unmounting /boot/efi.mount
[FAILED] Failed deactivating swap dev-zram0.swap
Et enfin, le message critique : [!!!!!!] Failed to execute shutdown binary.
À ce stade, le système est complètement bloqué et je dois forcer l’extinction en maintenant le bouton d’alimentation (power) enfoncé.
Voici les test que j’ai fait :
J’ai essayé d’isoler le problème de la façon suivante :
1. Tests Matériels :
SSD : J’ai d’abord suspecté le SSD d’origine (SK Hynix). Je l’ai remplacé par un Samsung 990 EVO 1To entièrement neuf. Le problème persiste de manière identique. Le SSD n’est donc pas la cause.
RAM : J’ai créé une clé USB bootable avec MemTest86. Le test a tourné pendant plusieurs heures et a effectué plusieurs passes complètes avec 0 erreur. La RAM est donc considérée comme saine.
2. Actions Logicielles et Firmware :
Système d’exploitation : J’ai effectué une réinstallation complète et propre de Fedora sur le nouveau SSD. Le problème est réapparu immédiatement.
BIOS/UEFI : J’ai reflashé la dernière version du BIOS (307) disponible sur le site d’Asus. Cela a été fait pour s’assurer que le firmware était “propre” et pour réinitialiser les configurations internes (NVRAM/CMOS). Le problème persiste.
Paramètres noyau : J’ai déjà testé sans succès le paramètre pcie_aspm=off.
Il y a rois éléments me font penser que le problème est un bug du BIOS :
Le système fonctionne parfaitement sous Windows : J’ai installé Windows 10 et 11 temporairement. La mise en veille, la sortie de veille, l’extinction et le redémarrage fonctionnent sans aucune erreur.
Le système fonctionne parfaitement en Live USB : Quand je démarre Fedora depuis une clé USB, la mise en veille et la reprise fonctionnent sans problème. Le bug ne se manifeste que lorsque le système tourne sur le SSD interne.
Le noyau Linux rapporte explicitement un bug du BIOS : Au démarrage (même depuis la clé USB), j’obtiens des erreurs ACPI claires. En voici un extrait :
ACPI BIOS Error (bug): Failure creating named object [\_SB.PCIO.XHC.RHUB.SS04._PLD], AE_ALREADY_EXISTS (20240827/dswload2-326)
ACPI Error: AE_ALREADY_EXISTS, During name lookup/catalog (20240827/psobject-220)
Ces erreurs indiquent que les tables ACPI du BIOS contiennent des définitions en double pour les ports USB 3.0, ce qui selon moi est un signe de firmware peut-être mal codé (sans vouloir offensé personne).
Mon hypothèse c’est que la cause racine est un bug dans le firmware BIOS/UEFI de l’Asus UX481FA. Ce bug, probablement lié à la gestion de l’alimentation (ACPI), ne se manifeste que lors de l’interaction avec le noyau Linux, tandis que Windows le tolère ou le contourne quand je change le mode de donné de AHCI au mode propriétaire « Intel RST Premium With Intel Optane System Acceleration ». L’instabilité après la mise en veille et l’échec de l’extinction sont les conséquences de ce bug.
Mes Questions à la Communauté
Après ce long parcours, je suis à la recherche de nouvelles pistes et j’aimerais savoir si :
Mon analyse et mon hypothèse vous semblent-elles correctes ?
Certains d’entre vous ont-ils déjà rencontré des problèmes similaires sur des ordinateurs portables Asus (en particulier les Zenbook) ?
Compte tenu des erreurs ACPI, quels paramètres de noyau (kernel parameters) me recommanderiez-vous de tester pour tenter de contourner ce bug ? Je pense notamment aux options reboot=… ou acpi_osi=…, mais votre expertise serait précieuse.
Voyez-vous une autre piste de diagnostic que j’aurais pu manquer ?
Ce qui suit est la configuration matérielle et logicielle que j’ai actuellement
Ordinateur : Asus Zenbook Duo UX481FA
SSD : Samsung 990 EVO 1To (neuf, récemment installé pour remplacer un SK Hynix qui présentait les mêmes symptômes).
Mémoire RAM : 16 Go (testée avec succès).
Système d’exploitation : Installation fraîche de Fedora 42 Workstation (le problème a aussi été observé sur d’autres distributions comme Ubuntu).
BIOS/UEFI : Version 307 (la dernière disponible sur le site d’Asus), qui a été réinstallée (“reflashée”).
Paramètres BIOS actuels :
Mode de stockage : AHCI
Fast Boot : Désactivé
Secure Boot : Désactivé
Merci d’avance pour votre temps et pour toute l’aide que vous pourrez m’apporter (et désolé pour ce roman) !
