Différences
Ci-dessous, les différences entre deux révisions de la page.
Les deux révisions précédentes Révision précédente Prochaine révision | Révision précédente Prochaine révision Les deux révisions suivantes | ||
veille_et_hibernation [Le 27/07/2020, 22:25] 77.197.94.158 correction de la 404 |
veille_et_hibernation [Le 15/12/2020, 23:54] sangorys [Mise en veille] |
||
---|---|---|---|
Ligne 131: | Ligne 131: | ||
Démarrez, si ça démarre ouvrez une console et éditez le fichier grub pour remettre la ligne comme avant:" GRUB_CMDLINE_LINUX="" " et faites un "sudo update-grub" pour enregistrer la modification. | Démarrez, si ça démarre ouvrez une console et éditez le fichier grub pour remettre la ligne comme avant:" GRUB_CMDLINE_LINUX="" " et faites un "sudo update-grub" pour enregistrer la modification. | ||
- | === Mise en veille qui ne met pas en veille (2) === | + | === Mise en veille qui met veille puis se reveille automatiquement au bout d'un petit laps de temps === |
- | La solution précédente ne fonctionne pas systématiquement... Ça peut venir des ports USB qui bloquent la mise en veille ou l’interrompent immédiatement. Il faut dans ce cas désactiver les ports fautifs. Voici [[https://askubuntu.com/questions/73365/shutdown-suspend-hibernate-not-working-correctly|un article]] (en anglais) qui propose une solution qui semble marcher pour beaucoup de configuration (c'est très simple, un script à copier dans un nouveau fichier dont le chemin est indiqué, une ligne de commande, un redémarrage et c'est tout). | + | Parfois, un périphérique envoi des signaux de reveil sans qu'on le souhaite. Il arrive parfois que cela vienne des ports USB ou du de l'écran des ordinateurs portables (le LID en anglais). |
+ | |||
+ | La solution serait la résolution de ces bugs dans les drivers ou le noyaux... | ||
+ | |||
+ | En solution de contournement, on peut désactivé le réveil de ces périphériques. Une fois désactivé, le réveil se fera avec les autres solutions de réveil (au pire le bouton marche / arrêt). La solution détaillée est expliquée [[https://joshtronic.com/2017/03/13/getting-suspend-in-linux-working-on-a-macbook-pro/|ici]] (en Anglais). | ||
+ | |||
+ | Le principe : | ||
+ | == 1. Lister ce qui peut sortir de veille. avec :== | ||
+ | cat /proc/acpi/wakeup | ||
+ | |||
+ | C'est tout ce qui est marqué ***enabled**. Pour les causes les plus rependues : | ||
+ | * XHC1 = Les ports USB | ||
+ | * LID0 = l'écran des ordinateurs portables | ||
+ | |||
+ | ==2. Faire des essais en désactivant les périphériques jusqu'à trouver le bon. Il faut replacer LID0 par le périphérique a désactiver== | ||
+ | sudo su | ||
+ | echo LID0 > /proc/acpi/wakeup | ||
+ | |||
+ | ==3. Tester en déclenchant la veille== | ||
+ | systemctl suspend | ||
+ | |||
+ | |||
+ | Si le système reste en veille, vous avez trouvé le périphérique qui pose problème. La configuration sera réinitialisée au prochain redémarrage de la machine | ||
+ | |||
+ | ==4. Désactiver le périphérique problématique à chaque démarrage. Pour cela, il faut ajouter la commande qui a marché au fichier /etc/rc.local en mode administrateur== | ||
+ | |||
+ | |||
+ | Une autre solution est celle-ci : [[https://askubuntu.com/questions/73365/shutdown-suspend-hibernate-not-working-correctly|article en anglais]] qui propose une solution qui semble marcher pour beaucoup de configuration (c'est très simple, un script à copier dans un nouveau fichier dont le chemin est indiqué, une ligne de commande, un redémarrage et c'est tout). | ||
=== Mise en veille qui ne met pas en veille (3) === | === Mise en veille qui ne met pas en veille (3) === |