Lorsque je reconditionne du matériel ou que je dépanne des systèmes pour le collectif Emmabuntüs, je rencontre souvent un problème récurrent : le refus d’un ordinateur portable de passer en mode Veille (Suspension à la RAM, S3) ou en Hibernation (S4).
Ce phénomène touche particulièrement les machines équipées d’une Carte Graphique Discrète (dGPU), qu’elle soit NVIDIA ou AMD. Le cœur du problème réside dans la gestion de l’ACPI (Advanced Configuration and Power Interface) par le noyau Linux, qui doit ordonner à tous les périphériques d’entrer en mode basse consommation.
Je partage ici ma méthodologie de diagnostic et mes solutions éprouvées sur des bases Debian (Debian, Ubuntu, Mint, etc.).
Si mon système ne parvient pas à dormir ou s’il s’éteint mais ne reprend pas, le coupable est presque toujours un composant qui refuse de se conformer à l’ordre S3. Le suspect principal reste le GPU discret ou son pilote.
Sur les systèmes hybrides (Intel/AMD + NVIDIA/AMD), la dGPU est le point de friction.
nvidia-prime ou d’autres gestionnaires de puissance) pour basculer temporairement sur la Carte Intégrée (iGPU) ou le mode « Power Saving ».nvidia-driver sous Debian/Ubuntu, par exemple).Parfois, le système utilise par défaut un mode de veille moins stable (comme le « Modern Standby »). Je préfère forcer l’utilisation du mode S3 (Deep).
J’édite le fichier de configuration de GRUB :
sudo nano /etc/default/grub
J’ajoute le paramètre mem_sleep_default=deep dans GRUB_CMDLINE_LINUX_DEFAULT.
Exemple :
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash mem_sleep_default=deep"
J’actualise GRUB et redémarre pour appliquer la modification :
sudo update-grub
reboot
journalctlLa méthode la plus fiable pour identifier le périphérique bloquant est d’examiner les logs du noyau après un échec.
journalctl -b -1 | grep -i suspend
device) ou d’un module (module). Cela me pointe directement le pilote ou le composant responsable (ex : xhci_hcd pour l’USB, un module réseau, etc.).Si je veux que mon laptop puisse hiberner (enregistrer l’état de la RAM sur le disque dur), je dois m’assurer que l’espace de Swap est suffisant et correctement référencé par le noyau.
Pour l’Hibernation (S4), je m’assure que l’espace de Swap (partition ou fichier) est au moins égal à la quantité de RAM.
free -h
sudo blkid).findmnt -no SOURCE -T /swapfilesudo filefrag -v /swapfile | awk '$1=="0:" {print substr($4, 1, length($4)-2)}'
L’Hibernation ne fonctionne que si le noyau sait où chercher l’état sauvegardé au démarrage.
J’édite de nouveau /etc/default/grub.
J’ajoute les paramètres resume=UUID=... (pour une partition) ou resume=PARTITION et resume_offset=OFFSET (pour un fichier Swap) à la ligne GRUB_CMDLINE_LINUX_DEFAULT.
Exemple (pour un Fichier Swap) :
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash mem_sleep_default=deep resume=/dev/nvme0n1p2 resume_offset=65536"
J’actualise GRUB et je redémarre.
Même si le GPU est souvent la cause, les périphériques USB peuvent empêcher le système de s’endormir.
cat /proc/acpi/wakeup
XHC pour le contrôleur USB), j’utilise : echo XHC > /proc/acpi/wakeup.En suivant cette méthodologie, je parviens presque systématiquement à diagnostiquer et à résoudre les problèmes de veille sur la grande majorité des ordinateurs portables sous Linux.