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 dans le sommeil profond, mais plutôt dans un s2idlemode qui est simplement un type de suspension d'écran.

Diagnostic du problème

Pour vérifier si tel 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-suspendsur un terminal si vous avez pm-utilsinstallé votre logiciel , ou appuyez sur le Windowstype de clé suspendpuis sur la Entertouche).

Réveillez - vous de suspendre le mode et le type dans 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_sleeplequel 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, faites en echo deep > /sys/power/mem_sleeptant qu'utilisateur root. Vérifiez qu’il a réussi en regardant le résultat cat /sys/power/mem_sleepqui devrait être

s2idle [deep]

suspendre ensuite l'ordinateur portable et se réveiller. Si sudo journalctl | grep "PM: suspend" | tail -2revient

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 (run 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 aussi amélioré avec le /etc/systemd/logind.confchangement que j'ai fait 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 j’avais eu , de façon intermittente, auparavant.

La durée de vie de la batterie diminue quand elle est suspendue, probablement parce que la méthode de suspension en cours est tout simplement moins efficace que la méthode par défaut, idéale, qui apparemment ne fonctionne 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-utilset d'utiliser pm-suspendet cela semblait suspendre assez efficacement, alors je voulais voir si je pouvais faire systemd-suspendla même chose.

J'ai parcouru les scripts pm-utilspour comprendre ce qu'il faisait réellement, et il semble que dans cette situation, ça se passait echo -n "mem" > /sys/power/state. J'ai donc créé le /etc/systemd/sleep.conffichier comme indiqué ci-dessus pour le faire correspondre.

Le comportement par défaut n’est pas tout à fait clair. La page de manuel for systemd-sleep.confindique que la distribution devrait inclure /etc/systemd/sleep.confles 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 cat /sys/power/statevous obtenez:

freeze mem

Donc, je suppose que c'est ce qu'il fait par défaut. Je pense que freezepeut - être être accepté, en ce qu'elle ne jette pas une erreur, ce qui causeraient autrement systemd de passer à mem, mais ne peut - être pas réellement fonctionner correctement ou de manière fiable, pour des raisons complexes , nous semblent incapables de déterminer. Par conséquent, le simple fait d’envoyer à la memplace est un bon espoir d’éviter cela et de faire ce qu’il pm-suspendfait.

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 cat /sys/power/diskque ça vous amène:

[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, gracieusement fourni par cascagrossa dans la réponse à cette question: Ubuntu 18.04 se bloque lors de 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 avoir permis de résoudre le problème également.

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), alors pourquoi cette machine est-elle si dérangeante? est pas clair.

Je recommande à toute personne rencontrant ce type de problème de suivre ces étapes pour identifier le problème:

1. Avez-vous des graphiques nVidia? Si c'est le cas, essayez l' astuce nouveau.modeset = 0 grub.

2. Vérifiez que suspendre fonctionne du tout. Si vous fermez le couvercle, puis l'ouvrez plus tard et que vous ne vous réveillez pas, il peut sembler que le processus ne «reprend» pas.

   • 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 touche Super et taper en '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 passe , mais alors vous ne pouvez pas obtenir votre machine jusqu'à ce s'éveiller alors apparaître comme un problème « curriculum vitae » plutôt que comme un problème « suspendre ».

   • Mon problème est que ce n'est pas en fait d' entrer dans la suspension et Murray qui a demandé de vérifier, a réalisé le problème a été DÉCOULANT lors de la suspension manuellement trop la question initiale, lorsqu'on lui a demandé par collisionTwo.

   • Dans mon cas (sur l'ordinateur portable à un problème) , l'écran devient 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 n'était pas simplement noir), mais la musique s'est arrêtée et la machine s'est en quelque sorte saisie.

3. Essayez votre machine avec un Live USB de 18.04 et vérifiez si vous avez 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 qui aurait pu interférer de quelque façon avec le mode de suspension, mais le même comportement s’est produit avec un Live USB d’Ubuntu 18.04 et Kubuntu 18.04.

4. 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 la suspension et à fonctionner correctement le 18.04 et sont peut-être davantage liés au fait que la machine passe en mode veille plutôt qu’au mode veille (profond) d’une «suspension» habituelle.

5. Si aucune des solutions ne permet de résoudre vos problèmes de suspension le 18.04, essayez la réponse acceptée: Ubuntu 18.04 se bloque lors de la reprise de la suspension.

   • 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èmes n'avait pas de problèmes 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.

6. 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/ 1774950

   • 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 logiciel Bay Trail Atom Celeron / Pentium, mais d’autres ont signalé un problème similaire avec d’autres machines.

   • Si vous êtes en mesure de vérifier votre kern.log après l'échec de la suspension (c’est-à-dire une fois que vous avez dû éteindre votre ordinateur et le redémarrer), vous remarquerez peut-être qu’il indique PM: suspendre l’entrée (deep) et qu’il n’ya pas d’autres entrées à part. les nombreuses lignes de démarrage à nouveau.

   • Il existe actuellement un correctif qui semble 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 tentez é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 souhaite simplement ajouter une réponse aux utilisateurs du Thinkpad X1 Carbon 6e génération qui présente un symptôme similaire, à savoir une batterie épuisée en suspension, ce qui est également dû au fait que le mode veille profond n’est pas activé.

Ce problème est abordé sur ce fil de discussion sur le forum de Lenovo . En résumé, le X1C6 a choisi de prendre en charge Windows Modern Standby. Si vous lisez ce fil avec attention, vous constaterez que, même si le symptôme est 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_sleepsur le X1C6 [s2idle]n'indiquerait que l'absence de prise en charge du deepsommeil.

Les solutions proposées jusqu'à présent pour cette question ne concernent que le XPS 13 et non le X1C6. Autant que je sache, la meilleure solution au problème du mode suspension du X1C6 consiste à appliquer un DSDTcorrectif d'abord fourni par Delta Xi , puis mis à jour par PombeirP . Ce message vous explique comment appliquer le correctif, mais assurez-vous de lire le message et toutes ses mises à jour avant toute action.

J'ai rédigé un résumé décrivant les 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 a été d' installer UKUU et de mettre à niveau le noyau à la version 4.19.11-041911-generic.

Juste pour mettre fin à cette question (espérons-le ...), je viens de (juillet 2019) de faire une mise à jour de mon 18.04 LTS avec HWE qui prétend résoudre ce problème spécifiquement pour le Dell XPS 13 (notamment pour ne pas passer en mode s2idle .)

FWIW, je viens de remplacer la batterie de mon XPS 13 (9350) 2016 avec Ubuntu 16.04 et kernél 4.14.12-041412-generic (la machine a été configurée au début de 2016 avec 15.10 et un noyau personnalisé, puis mis à niveau vers 16.04). Avant le remplacement, le couvercle a mis Linux en mode suspension comme il se doit (cependant, si vous avez branché le bloc d'alimentation pendant la suspension ou l'avez branché, par exemple, en changeant l'état que Linux pensait avoir fonctionné, le processus serait extrêmement lent jusqu'au redémarrage) . Quoi qu’il en soit, après le remplacement (batterie gonflée), le portable devrait redémarrer à la vitesse maximale lorsque le couvercle est fermé.

Le réglage de la gestion de l'alimentation sur "Standard" (à partir de "Avancé") dans "Configuration de la batterie principale" dans le BIOS EFI de Dell / AMI (que vous pouvez afficher en maintenant Fn-F2 au démarrage) semble avoir résolu le problème.

Je suis passé par beaucoup de solutions énumérées et rien n'a fonctionné pour popOS sur xps 9560 :(

Jusqu'à ce que je voie cette solution hilarante sur le site Web de dell qui prenait un poste de LTT.

Donc, ma solution provisoire qui semble fonctionner jusqu’à présent est la suivante: activer et désactiver certains paramètres du BIOS. Je sais que cela semble carrément idiot, mais je jure que cela semblait fonctionner à partir de ce que j'ai testé jusqu'à présent.

Plus précisément, j'ai désactivé les paramètres et / ou sélectionné une option différente pour un paramètre, puis je l'ai appliqué, puis rétabli et appliqué. Les réglages que j'ai alternés étaient les suivants:

• Configuration du système> Écran tactile (Désactivé, puis réactivé)

• Gestion de l'alimentation> Heure de mise en marche automatique (changez l'option, puis retournez sur Désactivé)

• Gestion de l'alimentation> Réveil sur les stations d'accueil Dell USB-C (désactivé, puis activé)

Fonctionne très bien maintenant. . . .