Fedora-Fr

Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

Mise en veille régulièrement buguée (FEDORA 43 KDE)

OnTheRoadAgain

Hello, j’utilise Fedora 43 KDE depuis 2 semaines, et comme sur pas mal de distros Linux lorsque je mets mon PC en veille, parfois ça plante (les écrans s’éteignent mais les ventilos continuent de tourner, et je dois hard shutdown/restart pour relancer la machine).

La commande journalctl -b -p err ne me répond aucun résultat, même après une veille plantée.

À priori, je n’ai rien dans SELinux Troubleshooter par rapport à ma dernière veille plantée de hier soir.

Que faire dans ces cas-là, comment résoudre la panne ? Si jamais vous avez une piste je suis preneur.

Merci !

VINDICATORs

OnTheRoadAgain

On peut en savoir plus sur le matériel?

Tu parle de la mise en veille sur disque (hibernation) ou en RAM?

Perso je test sur différents matériels de différentes type/marque (cartes mère, processeurs, fixe ou pc portables) sans jamais avoir eu ce genre de soucis.

OnTheRoadAgain

VINDICATORs

Système d’exploitation : Fedora Linux 43

Version de KDE Plasma : 6.6.1

Version de KDE Frameworks : 6.23.0

Version de Qt : 6.10.2

Version de noyau : 6.18.16-200.fc43.x86_64 (64-bit)

Plate-forme graphique : Wayland

Processeurs : 12 × Intel® Core™ i7-8700K CPU @ 3.70GHz

Mémoire : 32 Gio de mémoire vive (31,1 Gio de RAM utilisable)

Processeur graphique : AMD Radeon RX 6600

Fabricant : Micro-Star International Co., Ltd.

Nom du produit : MS-7B48

Version du système : 1.0

—

Pour la mise en veille, soit je passe par le menu Démarrer > Veille, ou j’appuie sur le bouton d’alimentation (Mettre en sommeil). Je ne sais pas s’il y a une différence ?

fgland

J’avais ce problème très souvent avec le pilote proprio de Nvidia, rarement depuis que je suis repassé sur nouveau.
Quelle carte graphique ?
Ma solution qui ne vaut que si on a plusieurs postes, était de me connecter en ssh car en fait il n’était pas en veille et soit un systemctl restart ssd ou carrément reboot. Évidemment ce qui n’était pas enregistré était perdu.

OnTheRoadAgain

fgland

Salut, Carte Graphique AMD RX 6600 (j’ai partagé des détails sur ma config dans une autre réponse).

Ah ouais en ssh carrément. Mais c’est assez courant, avant de passer sur Fedora j’ai testé quelques distros en dur (Ubuntu, Kubuntu, LMDE 6…) et ce problème revenait ponctuellement. C’est vraiment gênant

Nicosss

OnTheRoadAgain Ton bios de carte mère est à jour https://www.msi.com/Motherboard/Z370-A-PRO/support ?

Que retourne, en utilisant le bloc de code
$ hostnamectl

VINDICATORs

OnTheRoadAgain

Bon… Du coup en dehors de soucis de RAM ou de réglage de bios, je ne vois pas où peut être le problème.

Bon après je fais plus dans le Intel donc je peux pas dire de ce coté…

La mise en veille en RAM s’appelle “sommeil” donc aucune différence, le bouton d’alimentation est configuré comme un raccourci.

OnTheRoadAgain

Nicosss

Oui le BIOS est à jour, j’ai encore vérifié il y a moins d’un mois

$ hostnamectl 
 Transient hostname: fedora
     Static hostname: (unset)                                      
          Icon name: computer-desktop
            Chassis: desktop 🖥
         Machine ID: 34057ff39fcd4645a7f9c5461654f7ea
            Boot ID: 66ffbf2d45d040c58c0ec21d602dfa25
   Operating System: Fedora Linux 43 (KDE Plasma Desktop Edition)
        CPE OS Name: cpe:/o:fedoraproject:fedora:43
     OS Support End: Wed 2026-12-02
OS Support Remaining: 8month 3w 2d 
             Kernel: Linux 6.18.16-200.fc43.x86_64
       Architecture: x86-64
    Hardware Vendor: Micro-Star International Co., Ltd.
     Hardware Model: MS-7B48
   Hardware Version: 1.0
   Firmware Version: 2.D0
      Firmware Date: Sat 2024-07-06
        Firmware Age: 1y 8month 3d

PS: la commande journalctl -b -p err | grep -i suspend ne me renvoie aucun résultat

Edit Nicosss : Correction balises Markdown -> Voir FAQ .

Nicosss

OnTheRoadAgain PS: la commande journalctl -b -p err | grep -i suspend ne me renvoie aucun résultat

Si c’est après un redémarrage c’est normal car tu cherches dans le démarrage en cours, il faut mettre l’option -b -1
$ sudo journalctl -b -1 -p err | grep -i suspend

OnTheRoadAgain

Nicosss

Ah ok !! Donc ça me donne ça:

journalctl -b -1 -p err | grep -i suspend
mars 09 07:11:40 fedora kernel: xhci_hcd 0000:00:14.0: PM: pci_pm_suspend(): hcd_pci_suspend returns -16
mars 09 07:11:40 fedora kernel: xhci_hcd 0000:00:14.0: PM: dpm_run_callback(): pci_pm_suspend returns -16
mars 09 07:11:40 fedora kernel: xhci_hcd 0000:00:14.0: PM: failed to suspend async: error -16
mars 09 07:11:40 fedora kernel: PM: Some devices failed to suspend, or early wake event detected

fgland

intéressant !
si tu fais une recherche avec fedora kernel: PM: Some devices failed to suspend, or early wake event detected
Je fais mes recherches avec Brave et il faut reconnaître que son IA résume bien les différents cas rencontrés.
Dans les solutions proposées il y a :

Check the current sleep mode:
cat /sys/power/mem_sleep
If s2idle is in brackets, try switching to deep via kernel parameter mem_sleep_default=deep.

Avant de le mettre en dur dans la config, essai en ajoutant mem_sleep_default=deep à la fin de la ligne de boot au démarrage, si c’est bon il faudra l’inclure dans /etc/default/grub.

OnTheRoadAgain

fgland Salut !

cat /sys/power/mem_sleep
> s2idle [deep]

Je suis bien en deep. J’ai fait quelques recherches aussi et j’ai vu que ça pouvait venir du BIOS. Il est pourtant à jour, je suis quand même rentré dedans pour mettre l’option WHQL en UEFI et en étant sûr que le fast boot est bien désactivé.

fgland essai en ajoutant mem_sleep_default=deep à la fin de la ligne de boot au démarrage

De quel fichier à modifier tu parles ?
Merci

fgland

au démarrage, quand on a la liste des noyaux disponibles, appuyer sur la touche e pour éditer la ligne de boot.
Se déplacer avec le flèches de direction devant la ligne commençant pas linux , se mettre à la fin de cette ligne et y ajouter mem_sleep_default=deep
Pour la saisie on est en clavier anglais
Ctrl+x pour lancer le démarrage (c’est indiquer en bas de la fenêtre)
Cette modification ne vaut que pour la session en cours, donc sans dommage si on fait une erreur

fgland

Il est préférable de tester en modifiant la ligne de boot au démarrage avant de l’inclure dans le fichier de configuration comme je l’indiquais au fgland

OnTheRoadAgain

salut @fgland

If s2idle is in brackets, try switching to deep via kernel parameter mem_sleep_default=deep.

Mais la réponse de commande est s2idle [deep], c’est “deep” qui est entre “brackets” donc à priori c’est ok.

En revanche, la veille vient à nouveau de planter, avec ma carte graphique qui s’est mise à turbiner à fond. Au reboot, quand je lance sudo journalctl -b -1 -p err | grep -i suspend ça me répond ça, ce qui me fait penser que c’est la CG qui est en cause (AMD RX 6600): (GPU en fin de vie ?)

mars 15 15:32:01 fedora kernel: xhci_hcd 0000:00:14.0: PM: pci_pm_suspend(): hcd_pci_suspend returns -16
mars 15 15:32:01 fedora kernel: xhci_hcd 0000:00:14.0: PM: dpm_run_callback(): pci_pm_suspend returns -16
mars 15 15:32:01 fedora kernel: xhci_hcd 0000:00:14.0: PM: failed to suspend async: error -16
mars 15 15:32:01 fedora kernel: PM: Some devices failed to suspend, or early wake event detected
mars 15 15:32:13 fedora kernel: amdgpu 0000:03:00.0: amdgpu: suspend of IP block <smu> failed -22
mars 15 15:32:13 fedora systemd[1]: Failed to start systemd-suspend.service - System Suspend.
mars 15 15:32:13 fedora kernel: amdgpu 0000:03:00.0: PM: pci_pm_suspend(): amdgpu_pmops_suspend [amdgpu] returns -22
mars 15 15:32:13 fedora kernel: amdgpu 0000:03:00.0: PM: dpm_run_callback(): pci_pm_suspend returns -22
mars 15 15:32:13 fedora kernel: amdgpu 0000:03:00.0: PM: failed to suspend async: error -22
mars 15 15:32:13 fedora kernel: PM: Some devices failed to suspend, or early wake event detected
mars 15 15:32:15 fedora kernel: amdgpu 0000:03:00.0: amdgpu: suspend of IP block <smu> failed -22

VINDICATORs

OnTheRoadAgain

GPU en fin de vie? euh… Marche très bien le RX 6600. Après à voir la marque (les composants ont plus de chance de lâcher que le gpu…).

Perso je dirais plus un souci coté carte mère. A voir si il y a des rapports de bogue à ce sujet.

Il semble qu’il y ai des souci coté USB… : L'erreurxhci_hcd 0000:00:14.0: PM: failed to suspend async: error -16indique un problème de suspension du contrôleur USB xHCI, souvent lié à un périphérique USB ou à un pilote défectueux.

Et :

L'erreursuspend of IP block <smu> failed -22 indique un problème lors de la suspension du bloc IP <smu>du GPU AMD, ce qui peut entraîner des problèmes de mise en veille ou de redémarrage.

Il semble qu’il faille mettre l’option : amdgpu.dpm=0

Dans le grub. A tester temporairement en éditant au boot [CTRL]+[E] (clavier QWERTY!) ou en rajoutant l’option dans le fichier de grub : /etc/default/grub

https://doc.fedora-fr.org/wiki/RUB2_:_Les_bases_pour_Fedora#Personnalisation_facile_de_la_configuration_de_GRUB2

à la ligne : GRUB_CMDLINE_LINUX=". . . . . ."

OnTheRoadAgain

VINDICATORs

Salut, sachant que dans /etc/default/grub j’ai cette ligne GRUB_CMDLINE_LINUX="rhgb quiet"
je rajoute donc l’option à la suite comme ceci: GRUB_CMDLINE_LINUX="rhgb quiet amdgpu.dpm=0" ?

Juste pour être sûr du bon nommage et pas tout faire planter. Merci

OnTheRoadAgain

Nicosss C’est ok, merci pour la doc FR ! Ça va bien me dépanner 🤝

Bon par contre en ajoutant l’option dans /etc/default/grub puis après la validation, au reboot j’ai eu un écran noir (sur mes nuits blanches) et j’ai du reboot > CTRL E > enlever l'option

Donc à priori c’est pas ça la solution.

VINDICATORs Il semble qu’il y ai des souci coté USB… : L’erreurxhci_hcd 0000:00:14.0: PM: failed to suspend async: error -16indique un problème de suspension du contrôleur USB xHCI, souvent lié à un périphérique USB ou à un pilote défectueux.

Oui, peut-être un problème de périphérique USB (ou même de carte mère). Le PC est de 2018, Carte Mère MSI Z370 A PRO

Je vais continuer de chercher de mon côté, si jamais quelqu’un a d’autres pistes n’hésitez pas 🙂

VINDICATORs

OnTheRoadAgain

Oui 😃

OnTheRoadAgain

VINDICATORs Dernière question car je trouve pas la réponse malgré les docs lues: suite à la modif de /etc/default/grub, dois-je taper une dernière commande telle qu’update-grub ou autres afin de valider la modification avant de reboot ?

Merci 🤖

Nicosss

OnTheRoadAgain Je te propose de bien relire https://doc.fedora-fr.org/wiki/GRUB2_:_Les_bases_pour_Fedora#Personnalisation_facile_de_la_configuration_de_GRUB2 .

Page suivante »