2016 Touch Bar MBP draine la batterie en veille

14

Une batterie pleine se déchargera en environ 24 heures de couvercle fermé, sommeil complètement débranché. Parfois, lorsque je prends l'ordinateur pour l'utiliser, il fait chaud physiquement.

Voici ce que j'ai essayé:

Power Nap sur batterie est désactivé
iStat ne montre aucune application "utilisant une énergie importante" avant de fermer le couvercle.

En regardant dans la console, à system.log, pendant le temps que je sais que l'ordinateur dormait, et je vois deux choses qui me sautent immédiatement aux yeux. Je vais essayer de copier les sections pertinentes, mais je ne suis pas sûr de ce qui va vraiment être utile. La première section est répétée à l' infini :

05:49:47 WindowServer[121]: 8358864.989 [DFR] [deviceTerminate] 
05:49:47 WindowServer[121]: 8358865.001 [DFR] [_DFRDisplayDeviceRemoved] 
05:49:47 WindowServer[121]: 8358865.003 [DFR] [___DFRDisplayDeviceRemoved_block_invoke] calling client detach callback
05:49:47 WindowServer[121]: 8358865.004 [DFR] [_DFRDisplayClose] 
05:49:47 WindowServer[121]: 8358865.535 [DFR] [deviceMatch] 
05:49:47 WindowServer[121]: 8358865.535 [DFR] [_DFRDisplayDeviceAdded] 
05:49:47 WindowServer[121]: 8358865.537 [DFR] [_DFRDisplayUsbStart] 
05:49:47 WindowServer[121]: 8358865.537 [DFR] [_DFRDisplayOpen] 
05:49:47 WindowServer[121]: 8358865.540 [DFR] [_DFRDisplayOpen] sending GetInfo
05:49:47 WindowServer[121]: 8358865.541 [DFR] [_DFRDisplayHandleVendorPacket] kDFRDisplayCommandGetInfo ready: 0
05:49:47 WindowServer[121]: 8358865.541 [DFR] [_DFRDisplayHandleVendorPacket] calling client attach callback
05:49:47 WindowServer[121]: 8358865.554 [DFR] [_DFRDisplayHandleVendorPacket] kDFRDisplayCommandGetInfo ready: 1
06:01:51 WindowServer[121]: 8359589.038 [DFR] [deviceTerminate] 
06:01:51 WindowServer[121]: 8359589.041 [DFR] [_DFRDisplayDeviceRemoved] 
06:01:51 syslogd[37]: ASL Sender Statistics
06:01:51 WindowServer[121]: 8359589.044 [DFR] ERR [_DFRDisplaySendPacket] WritePipe failed 0xe00002c0
06:01:51 WindowServer[121]: 8359589.044 [DFR] [___DFRDisplayDeviceRemoved_block_invoke] calling client detach callback
06:01:51 WindowServer[121]: 8359589.044 [DFR] [_DFRDisplayClose] 
06:01:51 WindowServer[121]: 8359589.537 [DFR] [deviceMatch] 
06:01:51 WindowServer[121]: 8359589.537 [DFR] [_DFRDisplayDeviceAdded] 
06:01:51 WindowServer[121]: 8359589.540 [DFR] [_DFRDisplayUsbStart] 
06:01:51 WindowServer[121]: 8359589.540 [DFR] [_DFRDisplayOpen] 
06:01:51 WindowServer[121]: 8359589.589 [DFR] [_DFRDisplayOpen] sending GetInfo
06:01:51 WindowServer[121]: 8359589.590 [DFR] [_DFRDisplayHandleVendorPacket] kDFRDisplayCommandGetInfo ready: 0
06:01:51 WindowServer[121]: 8359589.590 [DFR] [_DFRDisplayHandleVendorPacket] calling client attach callback
06:01:51 WindowServer[121]: 8359589.591 [DFR] [_DFRDisplayHandleVendorPacket] kDFRDisplayCommandGetInfo ready: 1
06:08:40 WindowServer[121]: 8359998.006 [DFR] [deviceTerminate] 
06:08:40 WindowServer[121]: 8359998.007 [DFR] [_DFRDisplayDeviceRemoved] 
06:08:40 WindowServer[121]: 8359998.008 [DFR] [___DFRDisplayDeviceRemoved_block_invoke] calling client detach callback
06:08:40 WindowServer[121]: 8359998.008 [DFR] [_DFRDisplayClose] 
06:08:40 WindowServer[121]: 8359998.542 [DFR] [deviceMatch] 
06:08:40 WindowServer[121]: 8359998.542 [DFR] [_DFRDisplayDeviceAdded] 
06:08:40 WindowServer[121]: 8359998.543 [DFR] [_DFRDisplayUsbStart] 
06:08:40 WindowServer[121]: 8359998.543 [DFR] [_DFRDisplayOpen] 
06:08:40 WindowServer[121]: 8359998.568 [DFR] [_DFRDisplayOpen] sending GetInfo
06:08:40 WindowServer[121]: 8359998.580 [DFR] [_DFRDisplayHandleVendorPacket] kDFRDisplayCommandGetInfo ready: 0
06:08:40 WindowServer[121]: 8359998.580 [DFR] [_DFRDisplayHandleVendorPacket] calling client attach callback
06:08:40 WindowServer[121]: 8359998.581 [DFR] [_DFRDisplayHandleVendorPacket] kDFRDisplayCommandGetInfo ready: 1
06:15:27 WindowServer[121]: 8360404.994 [DFR] [deviceTerminate]

En cherchant ailleurs sur StackExchange des solutions, je suis tombé sur la pmset -gdemande:

System-wide power settings:
Currently in use:
 standbydelay         10800
 standby              1
 halfdim              1
 hibernatefile        /var/vm/sleepimage
 powernap             0
 gpuswitch            2
 disksleep            10
 sleep                1
 autopoweroffdelay    28800
 hibernatemode        3
 autopoweroff         1
 ttyskeepawake        1
 displaysleep         2
 acwake               0
 lidwake              1

Je suis intéressé à résoudre le problème, mais je suis également intéressé par toute connaissance de base menant à une solution. J'espère avoir fourni des informations pertinentes.

Mise à jour Edit : quelques jours se sont écoulés sans aucune discussion, et mon ordinateur portable s'est bien comporté pendant son sommeil. Ce matin, vers 4 heures du matin, j'ai débranché l'ordinateur portable avec une batterie à 100% et fermé le couvercle. Tout à l'heure, à 7h30, il faisait chaud et la batterie à 73%.

Le system.log en était plein:

07:08:02 com.apple.xpc.launchd[1] (com.apple.quicklook[19336]): Endpoint has been activated through legacy launch(3) APIs. Please switch to XPC or bootstrap_check_in(): com.apple.quicklook
07:08:35 diagnosticd[5296]: Streaming server Reconnected
07:08:47 GoogleSoftwareUpdateAgent[19340]: 2017-08-02 07:08:47.848 GoogleSoftwareUpdateAgent[19340/0x7fffde16f3c0] [lvl=2] -[KSAgentApp(PrivateMethods) setupLoggerOutput] Agent default/global settings: <KSAgentSettings:0x100302ee0 bundleID=com.google.Keystone.Agent lastCheck=2017-08-02 10:37:43 +0000 lastServerCheck=2017-08-02 10:37:41 +0000 lastCheckStart=2017-08-02 10:37:31 +0000 checkInterval=18000.000000 uiDisplayInterval=604800.000000 sleepInterval=1800.000000 jitterInterval=900 maxRunInterval=0.000000 isConsoleUser=1 ticketStorePath=/Users/robert/Library/Google/GoogleSoftwareUpdate/TicketStore/Keystone.ticketstore runMode=3 daemonUpdateEngineBrokerServiceName=com.google.Keystone.Daemon.UpdateEngine daemonAdministrationServiceName=com.google.Keystone.Daemon.Administration logEverything=0 logBufferSize=2048 alwaysPromptForUpdates=0 productIDToUpdate=(null) lastUIDisplayed=(null) alwaysShowStatusItem=0 updateCheckTag=(null) printResults=NO userInitiated=NO>
07:09:42 diagnosticd[5296]: Streaming server Reconnected
07:10:49 diagnosticd[5296]: Streaming server Reconnected
07:11:54 diagnosticd[5296]: Streaming server Reconnected
07:12:01 awdd[155]: Diagnostics Report
07:13:00 diagnosticd[5296]: Streaming server Reconnected
07:13:14 com.apple.xpc.launchd[1] (com.apple.quicklook[19365]): Endpoint has been activated through legacy launch(3) APIs. Please switch to XPC or bootstrap_check_in(): com.apple.quicklook
07:14:07 syslogd[37]: ASL Sender Statistics
07:14:07 diagnosticd[5296]: Streaming server Reconnected
07:15:12 diagnosticd[5296]: Streaming server Reconnected
07:16:18 diagnosticd[5296]: Streaming server Reconnected
07:17:24 diagnosticd[5296]: Streaming server Reconnected

La recherche sur "Streaming Server Reconnected" a produit un document de support Apple avec plusieurs personnes ayant des problèmes similaires

Mise à jour / Édition: Après quelques mois sans problèmes, j'ai commencé à remarquer mon réveil mac en veille, provoquant un réveil et une veille d'un écran externe. L'événement de réveil ne correspondait à aucune notification ni à aucun autre élément perceptible. J'ai parlé avec un Apple Genius aujourd'hui et il a commencé à supprimer l'image sleep, mais a trouvé beaucoup de problèmes de permission avec elle, tombant finalement en mode mono-utilisateur pour faire le travail. Lorsque j'ai expliqué tous les problèmes que j'ai rencontrés avec le sommeil, il a dit "cela pourrait provoquer cela", mais j'ai le sentiment que leur solution de niveau 1 pour les problèmes de sommeil / éveil supprime l'image de sommeil.

display battery sleep-wake

— voxobscuro
source

2

Je ne sais pas grand chose sur le déchiffrement des messages console.log mais si votre machine est physiquement chaude et perd autant de batterie, elle n'a pas vraiment dormi. Il est normal pour OS X de se réveiller toutes les quelques heures et d'effectuer certaines tâches en arrière-plan, mais dans des conditions normales d'utilisation, il devrait être de nouveau endormi en quelques minutes. Le vôtre fait certainement plus que la machine moyenne pendant son sommeil.

Je me demande quels seraient les résultats si vous créiez un nouvel utilisateur (complètement vide) dans Préférences Système> Utilisateurs et groupes, déconnecté du vôtre, connecté à cet utilisateur, puis mettez-le en veille pendant un autre jour environ. Si vous voyez que la machine ne se réveille plus et que, pour une raison quelconque, elle ne retourne pas en veille, vous pouvez être sûr que quelque chose est installé sur votre profil. Si cela continue, il est possible que le système d'exploitation rencontre un problème et qu'il doive être réinstallé ou qu'il y ait une sorte de problème matériel fou à l'origine de cela. C'est un long processus de dépannage, mais c'est le seul que je connaisse pour un problème comme celui-ci - veuillez mettre à jour ici et je peux vous aider davantage si vous décidez de suivre cette voie.

— petit homme minuscule
source

Vous avez absolument raison que la machine ne dort pas. La chose déroutante à ce sujet est que cela ne se produit pas à chaque fois. Aujourd'hui, il a dormi 10 heures et n'a rien perdu. Je pense que la création d'un nouvel utilisateur pourrait rendre un problème intermittent plus difficile à diagnostiquer.

— voxobscuro

Eh bien, cela ferait séparer un problème à l'échelle du système de celui situé dans votre profil - d'une manière ou d'une autre, vous devez faire cette distinction afin de diagnostiquer et éventuellement d'appliquer un correctif à ce qui se passe. Utilisez syslog |grep -i "Wake reason"au lieu d'espérer simplement l'attraper pendant qu'il est encore chaud

— petit petit homme

hm, syslog semble avoir été remplacé par une commande appelée logavec une fonctionnalité similaire, mais "Wake reason" apparaît fréquemment. La commande complète est log --since 1d | grep -i "Wake reason"et j'ai également vu des résultats intéressants aveclog --since 1d | grep -i "PowerChime"

— voxobscuro

Que dit-il provoque les réveils lorsque vous exécutez cette commande?

— petit homme minuscule

La plupart d'entre eux ont quelque chose à voir avec une déconnexion / reconnexion de l'affichage, ce qui ne s'est jamais produit.

— voxobscuro

1

J'ai le même problème et j'ai remarqué qu'il ne le fait que sur mon réseau Wi-Fi domestique. Lorsque je dors ailleurs (avec une connexion Wi-Fi connectée auparavant), cela ne déchargera pas la batterie pendant la nuit.

— narrowtux
source

Avez-vous une capsule temporelle ou un autre appareil Time Machine à la maison sur lequel votre ordinateur portable sauvegarde?

— voxobscuro

Non. Dans l'autre endroit où il ne vide pas sa batterie, j'ai mis en place un appareil Time Machine en réseau.

— narrowtux

C'est intéressant ... J'ai remarqué pour la première fois cette mort de sommeil quand j'étais loin de chez moi, où j'ai un appareil Time Machine en réseau. Depuis mon retour à la maison, je ne l'ai pas vu se produire. Je vais l'essayer aujourd'hui en prenant l'ordinateur portable loin de chez lui et en le faisant passer par un cycle de sommeil.

— voxobscuro

Vous pensez donc que c'est parce qu'il recherche le lecteur de sauvegarde et ne le trouve pas?

— narrowtux

1

J'ai eu le même problème pendant un moment. Un collègue m'a donné l'astuce pour supprimer toutes les connexions configurées dans les préférences réseau comme WiFi, Bluetooth, Ethernet, partage de connexion téléphonique USB, FireWire, Thunderbolt ceci, Thunderbolt cela etc (tout)! et postulez.

Configurez uniquement ce dont vous avez besoin maintenant. Dans mon cas, c'était uniquement le WiFi et le Bluetooth.

Cela a résolu mon problème et mon MacBook Pro avec Touch Bar dort comme un bébé chaque fois que je ferme le couvercle sans ce problème maintenant.

— 639d0991
source

C'est une bonne idée, je vais le nettoyer et voir si le problème revient.

— voxobscuro

0

J'ai essayé de désactiver le WiFi ce soir avant de fermer le couvercle et cela a bien fonctionné. Le système s'est réveillé plusieurs fois, mais il n'y a pas eu de décharge importante de la batterie.

Maintenant que ce n'est pas vraiment une solution pratique, j'ai écrit un script pour Hammerspoon qui désactive automatiquement le WiFi avant que le système ne se mette en veille. Il vérifie également si l'écran est réveillé, sinon il réveillerait la puce WiFi à chaque fois que le système se réveille lorsque le couvercle est fermé.

— narrowtux
source