Ubuntu 18.04 - Dell XPS13 9370 ne se suspend plus à la fermeture du couvercle
Cela fonctionnait parfaitement le 17.10, mais après la mise à niveau vers 18.04 hier, lorsque le couvercle est fermé, l’écran s’éteint mais ne se suspend pas correctement.
Je voyage beaucoup et j'ai immédiatement remarqué la chaleur (et la batterie s'épuiser) lorsque je la retirais de la housse de voyage.
J'ai essayé de supprimer les commentaires de ces lignes dans /etc/systemd/logind.conf
HandleLidSwitch=suspend
HandleLidSwitchDocked=suspend
et redémarré mais ne fait aucune différence.
Je pense que j'ai réussi à comprendre ce qui se passait, grâce à ces deux sources: Notes d'installation de Dell XPS 13 (9370) ArchLinux et Arch Linux Forum .
Pour une raison quelconque, l'ordinateur portable n'entre plus en sommeil profond, mais plutôt en mode s2idle, qui est simplement un type de suspension de l'écran.
Diagnostic du problème
Pour confirmer si cela est le cas pour votre système, suspendez l'ordinateur portable à l'aide de votre méthode préférée (fermez le couvercle, appuyez sur Fn + End, écrivez pm-suspend dans un terminal si vous avez installé pm-utils ou appuyez sur la touche Windows, tapez suspend, puis sur Enter. clé).
Sortez du mode veille et entrez un terminal: Sudo journalctl | grep "PM: suspend" | tail -2. Si la sortie est
May 13 18:41:00 mex kernel: PM: suspend entry (s2idle)
May 13 20:52:36 mex kernel: PM: suspend exit
Ensuite, vous n'entrez pas dans un sommeil profond. Vous pouvez également vérifier cat /sys/power/mem_sleep qui devrait retourner
[s2idle] deep
qui confirme que le mode de suspension par défaut est s2idle (car il est mis en évidence entre crochets).
Solution temporaire
Pour essayer un correctif temporaire, utilisez echo deep > /sys/power/mem_sleep en tant qu'utilisateur root. Vérifiez qu’il a réussi en examinant le résultat de cat /sys/power/mem_sleep qui devrait être
s2idle [deep]
suspendre ensuite l'ordinateur portable et se réveiller. Si Sudo journalctl | grep "PM: suspend" | tail -2 retourne
May 13 18:41:00 mex kernel: PM: suspend entry (deep)
May 13 20:52:36 mex kernel: PM: suspend exit
alors le problème devrait être résolu. Vous pouvez mettre votre ordinateur en veille pendant quelques heures et vérifier si la charge de la batterie s’est améliorée.
Solution permanente
Pour le rendre permanent, vous devez éditer votre cmdline de chargeur de démarrage. Pour ce faire, éditez en tant qu'utilisateur root le fichier/etc/default/grub, en exécutant par exemple Sudo -H gedit /etc/default/grub. Remplace la ligne
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
avec
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash mem_sleep_default=deep"
et régénérez votre configuration grub (exécutez Sudo grub-mkconfig -o /boot/grub/grub.cfg).
Essayez de créer /etc/systemd/sleep.conf:
[Sleep]
SuspendMode=
SuspendState=mem
Et redémarrez. Cela semble fonctionner pour moi, bien que je ne sois pas sûr de ne pas avoir également eu d'amélioration avec le changement /etc/systemd/logind.conf que j'ai effectué en premier. Dans tous les cas, aucun bruit de chaleur ou de ventilateur n’est observé pendant la suspension avec le couvercle fermé, et il ne répond pas non plus au ping sur wifi, ce que je avais reçu, de manière intermittente, auparavant.
La durée de vie de la batterie est toujours suspendue, probablement parce que la méthode de suspension en cours d’utilisation est tout simplement moins efficace que la méthode par défaut, idéale, qui ne fonctionne apparemment pas correctement, mais elle semble meilleure que le comportement par défaut.
Essayé sur mon XPS 13 9370, je ne connais pas les modèles plus anciens, même s’il semble probable qu’ils seront similaires.
J'avais essayé d'installer pm-utils et d'utiliser pm-suspend et que cela semblait suspendre assez efficacement. Je voulais donc voir si je pouvais faire en sorte que systemd-suspend fasse la même chose.
J'ai parcouru les scripts de pm-utils pour comprendre ce qu'il faisait réellement, et il semble que dans cette situation, il faisait echo -n "mem" > /sys/power/state. J'ai donc créé le fichier /etc/systemd/sleep.conf comme indiqué ci-dessus pour le faire correspondre.
Le comportement par défaut n’est pas tout à fait clair. La page de manuel de systemd-sleep.conf indique que la distribution doit inclure /etc/systemd/sleep.conf avec les valeurs par défaut compilées et commentées afin que vous puissiez voir cette information, mais ce fichier est manquant dans Ubuntu. J'ai remarqué cependant que si vous cat /sys/power/state vous obtenez:
freeze mem
Donc, je devinant que c'est ce que cela fait par défaut. Mon hypothèse est que freeze peut être accepté, en ce sens qu'il ne renvoie pas d'erreur, ce qui aurait pour effet de faire passer Systemd à mem, mais peut-être pas réellement travail correctement ou de manière fiable, pour des raisons complexes, nous semblons incapables de déterminer. Donc, envoyer mem à la place est un bon espoir d'éviter cela et de faire ce que pm-suspend fait.
Je soupçonne que le paramètre SuspendMode est en réalité superflu et ne fait rien de toute façon. Je le soupçonne, parce que cat /sys/power/disk vous donne simplement:
[disabled]
Suis nouvel utilisateur, donc incapable de commenter avec une observation, obligé de la présenter comme une réponse, comme si j'étais super confiant en elle! Mais je pense que ça marche.
Les autres réponses ici sont excellentes, détaillées et bien documentées.
Malheureusement, ils ne fonctionnaient pas pour ma machine particulière :(
Si vous avez des graphiques nVidia, il semble y avoir un correctif qui fonctionne pour un bon nombre de personnes, aidé de manière utile par cascagrossa dans la réponse à cette question. : buntu 18.04 plante à la reprise de la suspension
Il est suspecté d'être un pilote buggy nouveau et peut résoudre les problèmes de suspension en ajoutant nouveau.modeset = 0 à grub et a été confirmé dans les commentaires pour aider à résoudre le problème pour les autres aussi.
J'ai des graphiques Intel sur ma machine à problèmes et, curieusement, je n'ai eu aucun problème de suspension avec Ubuntu ou Kubuntu 18.04 sur au moins 3 autres machines (celles de mon ami et celles de la mienne). est pas clair.
Je recommande à toute personne rencontrant ce type de problème de suivre ces étapes pour identifier le problème:
Avez-vous des graphiques nVidia? Si tel est le cas, essayez l’astuce nouveau.modeset = 0 .
Vérifiez que la suspension fonctionne du tout. Si vous fermez le couvercle puis ouvrez-le plus tard et que cela ne se réveille pas, cela peut sembler manquer à 'reprendre'.
Vous devriez pouvoir sélectionner manuellement suspendre sur n'importe quel bureau, mais il est légèrement caché dans Gnome Shell - , vous pouvez appuyer longuement sur le bouton d'alimentation dans le menu en haut à droite de l'écran, ou cliquer sur ce bouton tout en maintenant Alt ou appuyer sur la clé Super et tapez 'suspendre'
En sélectionnant suspendre, vous pouvez vérifier que l'écran est éteint , le voyant d'alimentation clignote comme il se doit et vous vous attendez à ce que tout ventilateur en marche s'arrête également . Si tout cela se produit mais alors vous ne pouvez pas réveiller votre machine, il semblerait alors qu'il s'agisse d'un problème de "reprise" plutôt que d'un problème de "suspension".
Mon problème a été que ce n’est pas réellement en suspension, et Murray qui a posé la question initiale, lorsque CollisionTwo l’a demandé, a réalisé que le problème se posait également lors de la suspension manuelle.
Dans mon cas (sur l'ordinateur portable à un problème) , l'écran est vide, mais le voyant d'alimentation reste allumé et, si le ventilateur fonctionne, il continue de fonctionner. La machine ne répond pas aux pressions sur les touches, aux mouvements du pavé tactile, aux clics ou aux pressions du bouton d'alimentation. La seule chose à faire est de le fermer.
J'ai essayé de jouer de la musique pendant la suspension (pour vérifier que l'écran ne devient pas blanc uniquement), mais la musique s'arrête et la machine est pratiquement bloquée.
Essayez votre machine avec une clé Live USB de 18.04 et vérifiez si vous rencontrez des problèmes de suspension similaires.
Cela ne fera que confirmer que les problèmes de suspension ne concernent pas les programmes supplémentaires que vous avez installés.
Dans mon cas, je soupçonnais que c’était parce que j’avais installé tlp , ce qui aurait pu interférer avec le mode suspension, mais le même comportement s'est produite avec un Live USB d'Ubuntu 18.04 et Kubuntu 18.04
Essayez les deux autres solutions bien étudiées fournies ici par monty47 et StrangeNoises et voyez si vous obtenez de bons résultats.
- Ils semblent avoir aidé un certain nombre de personnes à retrouver leur suspension le 18.04 et ils fonctionnaient correctement. Ils sont peut-être davantage liés au fait que la machine passe dans un état s2idle plutôt que . mode sommeil (profond) d'un "suspendre" habituel.
Si aucune des solutions ne résout vos problèmes de suspension le 18.04, essayez la réponse acceptée: buntu 18.04 se bloque lors de la reprise de suspendre
La solution fournie par Matalak (qui a également posé la question) consistait à utiliser UKUU pour essayer un noyau 4.14 plus ancien.
Ma machine à problème n’avait aucun problème de suspension avec Ubuntu 17.10 et Kubuntu 17.10, il est donc logique que 17.10 utilise le noyau 4.14. Il suspend maintenant correctement dans Ubuntu 18.04 et Kubuntu 18.04 en utilisant le noyau 4.14.
Si vous avez essayé les autres solutions et que vous ne pouviez résoudre vos problèmes de suspension qu'en retournant à un noyau 4.14, le rapport de bogue pourrait vous intéresser: - https://bugs.launchpad.net/ubuntu/+source/linux/+bug/177495
Il semble n’affecter que quelques machines avec une combinaison spécifique de matériel et peut être difficile à identifier parmi d’autres problèmes liés à nouveau ou s2idle.
Cela semble être plus courant chez ceux qui utilisent un Bay Trail Atom Celeron/Pentium, mais d’autres ont signalé un problème similaire avec d’autres machines.
Si vous êtes capable de vérifier votre kern.log après cette suspension échouée (c’est-à-dire une fois que vous avez dû éteindre votre ordinateur et le redémarrer) , vous remarquerez peut-être qu’il est écrit PM: suspendez l’entrée (deep) et vous n’avez plus d’entrées à part les nombreuses lignes de redémarrage.
Un correctif semble actuellement résoudre le problème.
Si vous souhaitez ajouter votre voix au rapport de bogue, il serait intéressant de voir quelles machines sont affectées (et de vérifier que le correctif corrige le problème pour tout le monde).
Vous essayez également de regrouper les "questions en suspens dans la version 18.04" dans ce fil de discussion: https://ubuntuforums.org/showthread.php?t=2395562&p=13780724#post13780724
Je crois que ce bug du noyau est lié:
https://bugzilla.kernel.org/show_bug.cgi?id=199689
Voir le commentaire n ° 3 en particulier:
[…] Il est en fait intentionnel d'utiliser s2idle sur cette machine avec le dernier noyau en amont.
Je veux juste ajouter une réponse aux utilisateurs de Thinkpad X1 Carbon 6e génération qui a un symptôme similaire , c’est-à-dire que la batterie est déchargée en étant suspendue, ce qui est causé aussi par l’absence de saisie mode veille profond .
Ce problème est discuté sur ce fil sur le forum de Lenovo , bref, le X1C6 a choisi de prendre en charge Windows Modern Standby. Si vous lisez ce fil attentivement, vous constaterez que bien que le symptôme soit partagé, les causes premières varient considérablement entre le XPS 13 9370 et le X1C6 . par exemple. La sortie de cat /sys/power/mem_sleep sur le X1C6 ne serait que [s2idle], ce qui indique l'absence de prise en charge pour deep sleep.
Les solutions proposées jusqu'à présent pour cette question ne s'appliquent qu'au XPS 13, et non au X1C6. Autant que je sache, la meilleure solution au problème du mode de suspension du X1C6 consiste à appliquer un correctif DSDT d'abord donné par Delta Xi , puis mis à jour par PombeirP . This post explique comment appliquer le correctif, mais assurez-vous de lire le post et toutes ses mises à jour avant toute action.
J'ai écrit n Gist documenter des problèmes liés à l'installation d'Ubuntu 18.04 sur le Thinkpad X1 Carbon 6e génération, y compris les solutions que j'ai trouvées à propos du problème de démarrage lent causé par LVM ainsi que ce problème de sommeil profond .
J'utilise un Lenovo ThinkPad Edge E531 et j'ai rencontré un problème similaire qui empêchait l'ordinateur d'entrer en veille profonde. Le comportement était intermittent et, à la reprise, le pavé tactile cessait parfois de fonctionner en wifi pour se déconnecter.
J'ai essayé une dizaine de corrections suggérées en ligne, mais la seule solution qui a fonctionné pour moi était installation de UK et la mise à niveau du noyau à la version 4.19.11-041911-generic.