<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
  <title>Artisan Numérique</title>
  <link rel="alternate" type="text/html" href="http://artisan.karma-lab.net/node/1588"/>
  <link rel="self" type="application/atom+xml" href="http://artisan.karma-lab.net/node/1588/atom/feed"/>
  <id>http://artisan.karma-lab.net/node/1588/atom/feed</id>
  <updated>2008-09-29T11:25:22+02:00</updated>
  <entry>
    <title>Hibernatus!!</title>
    <link rel="alternate" type="text/html" href="http://artisan.karma-lab.net/node/1588" />
    <id>http://artisan.karma-lab.net/node/1588</id>
    <published>2008-07-12T15:34:03+02:00</published>
    <updated>2008-09-29T11:25:22+02:00</updated>
    <author>
      <name>Ulhume</name>
    </author>
    <category term="Green Computing" />
    <category term="mandriva" />
    <category term="OK" />
    <category term="Planet Libre" />
    <category term="Tutoriel" />
    <summary type="html"><![CDATA[<p>
   Je rassure les hostiles, le clin d'oeil à Mr Potter s'arrêtera là <img src="http://artisan.karma-lab.net/sites/all/modules/contrib/smileys/packs/crystal/smile.gif" title="Smiling" alt="Smiling" class="smiley-content"/> A l'origine j'avais écrit ce tutoriel pour le <a class='external' target='_blank' href='/node/1587' >lifebook U810</a>. Mais comme ce chapitre est devenu un véritable parcours du combattant, et comme j'avais aussi envie de bénéficier de l'hibernation sur mon ordinateur de bureau, je me suis dit qu'il ne serait sans doute pas trop crétin d'en faire un tutoriel à part entière. Alors pour mettre une sa Mandriva (ou tout autre GNU/Linux en adaptant le tutoriel) dans la glace, voilà la marche à suivre...
</p>
    ]]></summary>
    <content type="html"><![CDATA[<p>
   Je rassure les hostiles, le clin d'oeil à Mr Potter s'arrêtera là <img src="http://artisan.karma-lab.net/sites/all/modules/contrib/smileys/packs/crystal/smile.gif" title="Smiling" alt="Smiling" class="smiley-content"/> A l'origine j'avais écrit ce tutoriel pour le <a class='external' target='_blank' href='/node/1587' >lifebook U810</a>. Mais comme ce chapitre est devenu un véritable parcours du combattant, et comme j'avais aussi envie de bénéficier de l'hibernation sur mon ordinateur de bureau, je me suis dit qu'il ne serait sans doute pas trop crétin d'en faire un tutoriel à part entière. Alors pour mettre une sa Mandriva (ou tout autre GNU/Linux en adaptant le tutoriel) dans la glace, voilà la marche à suivre...
</p>
<!--break-->
<div class='inline-box note'>
   Les sources correspondant à l'U810 sont disponibles <a class='external' target='_blank' href='/node/1658' >ici</a>.
</div>

	<a name='chapter_1'></a>
  <h2>Introduction</h2>
	
<p>
  Il y a trois types d'extinction disponibles sous Linux. L'extinction complète via la commande <kbd>shutdown</kbd>. L'<kbd>hibernation</kbd> qui fonctionne comme l'extinction complète mais qui va préalablement sauvegarder l'état de la mémoire et des périphériques et restaurer la mémoire après démarrage du kernel. Et enfin il y a la <kbd>mise en veille</kbd> qui consiste à tout éteindre sauf la mémoire et un boût du northbridge qui la rafraîchit.
</p>
<p>
 D'un point de vue énergétique, le mode <kbd>hibernation</kbd> est le meilleur car la machine peut être physiquement éteinte. En mode <kbd>mise en veille</kbd>, la mémoire et le northbridge continuent de pomper du courant, ainsi que la carte mère elle-même.  Une batterie de portable ne tiendra donc pas éternellement sur ce mode, contrairement à l'hibernation.  
</p>
<p>
  Pour gérer ces mises en sommeil, nous utilisons ... <kbd>hibernate</kbd> qui est n'est autre que le projet <a class='external' target='_blank' href='http://www.tuxonice.net/' >Tux On Ice</a>. Contrairement à ce que son nom indique, la commande <kbd>hibernate</kbd> que ce paquet met à disposition, permet aussi bien d'effectuer une hibernation qu'une mise en veille en utilisant respectivement <kbd>s2disk</kbd> du paquet <kbd>suspend</kbd> et <kbd>s2ram</kbd> du paquet <kbd>suspend-s2ram</kbd>.
</p>
<p>
  Techniquement <kbd>s2disk</kbd> et <kbd>s2ram</kbd> sont autonomes et seraient utilisables "tout crus". Mais <kbd>hibernate</kbd> enrobe le tout dans une série de scripts paramétrables permettant de gérer les différentes étapes préalables à l'extinction et à la finalisation du réveil, notamment l'épineux problèmes des modules qui ne savent pas sauvegarder leur état proprement.
</p>
<p>
Pour installer tout cela, il suffit de lancer un <kbd>urpmi hibernate suspend suspend-s2ram</kbd> et les commandes seront :
  
  <div class='code-block code-block-fragment'>
  <div class='container'>
  <span class="co0"># hibernation</span><br />
hibernate<br />
<br />
<span class="co0"># mise en veille</span><br />
hibernate --config-<span class="re2">file=</span><span class="sy0">/</span>etc<span class="sy0">/</span>hibernate<span class="sy0">/</span>ram.conf
  </div>
  
  </div> 
</p>

<p>
  Comme vous le voyez, l'hibernation est le comportement par défaut. Pour une mise en veille, il faut fournir en plus un fichier de paramétrage spécifique.
</p>


	<a name='chapter_2'></a>
  <h2>Machine inconnue</h2>
	
<p>
   Si vous faites un <kbd>s2ram -n</kbd>, il y a de forte chances que cela vous renvoie un <kbd>Machine is unknown</kbd> qui bloquera la suite du processus. Pour forcer malgré tout la mise en veille, il nous faut donc contourner cette protection en modifiant <kbd>/etc/hibernate/ususpend-ram.conf</kbd> pour décommenter la ligne <kbd>USuspendRamForce yes</kbd>. 
</p>
<div class='inline-box attention'>
Forcer la mise en veille n'est pas sans risque. L'option n'est pas là pour rien et vous pouvez éventuellement corrompre vos données. A vos risques et périls...</div>


	<a name='chapter_3'></a>
  <h2>Des modules pas très green</h2>
	
<p>
  La première raison qui empêche une mise en veille ou hibernation, ce donc sont les modules qui ne savent pas correctement causer "énergie" (ou alors le matériel sous-jacent). Ces modules sans espoir devront donc  être déchargés avant extinction et recharger au réveil. Leur état interne sera donc perdu mais ce n'est généralement pas bien grave.   
 </p>
 <p>
    Pour trouver ces modules, je n'ai rien trouvé de mieux que de faire d'un côté <kbd>tail -f /var/log/messages</kbd> et de l'autre, de lancer <kbd>hibernate --config-file=/etc/hibernate/ram.conf --verbosity=3</kbd> pour qu'il m'indique les problèmes rencontrés.  Par exemple pour le lifebook U810, cela me donne :

  <div class='code-block code-block-fragment'>
  <div class='container'>
  ...<br />
Jul &nbsp;<span class="nu0">8</span> <span class="nu0">09</span>:<span class="nu0">52</span>:<span class="nu0">40</span> horus kernel: aes2501 <span class="nu0">2</span><span class="nu0">-2</span>:<span class="nu0">1.0</span>: no <span class="kw3">suspend</span> <span class="kw1">for</span> driver aes2501?<br />
Jul &nbsp;<span class="nu0">8</span> <span class="nu0">09</span>:<span class="nu0">52</span>:<span class="nu0">40</span> horus kernel: uvcvideo <span class="nu0">1</span><span class="nu0">-5</span>:<span class="nu0">1.1</span>: <span class="kw3">suspend</span> error <span class="nu0">-22</span><br />
...
  </div>
  
  </div>
</p>

<p>
  Dés que l'on détecte un module fautif, nous devons le "blacklisté" en ajoutant son nom dans la liste <kbd>/etc/hibernate/blacklisted-modules</kbd>. 
</p>
<p>
  Si vous obtenez une erreur du genre  :
  
  <div class='code-block code-block-fragment'>
  <div class='container'>
  Some modules failed to unload: nvidia<br />
hibernate: Aborting <span class="kw3">suspend</span> due to errors <span class="kw1">in</span> ModulesUnloadBlacklist <span class="br0">&#40;</span>use --force to override<span class="br0">&#41;</span>.
  </div>
  
  </div>
</p>
<p>
  Il va falloir aussi forcer hibernate. Pour cela, modifiez <kbd>/etc/hibernate/common.conf</kbd> et décommentez <kbd>AlwaysForce yes</kbd>. 
</p>
<p>
   Relancez la mise en veille autant de fois qu'il est nécessaire en répétant ces opérations de blacklistages jusqu'à ce que la machine s'éteigne. Une fois que c'est fait, une simple pression sur le bouton d'allumage devrait la faire revenir à la vie. 
</p>
<p>
  Si elle ne revient pas la pauvrette, un coupable possible est 
  <a target='_blank' href='http://fr.wikipedia.org/wiki/APIC'>
  APIC
  </a>. C'est le cas de l'U810. Tentez donc de le désactiver en modifiant  <kbd>/boot/grub/menu.lst</kbd>, pour ajouter à ma fin de la bonne ligne <kbd>kernel<Kbd>, le paramètre  <kbd>noapic</kbd>. Redémarrez et re-tentez l'expérience. 
</p> 
<p>
  Si au retour de la mise en veille vous obtenez, et c'est le cas pour l'U810, un écran tout vilain, pas de panique. Pressez CAPS-LOCK pour vérifier que a diode de votre clavier s'allume et donc que la machine n'est pas plantée. Puis alternez les <kbd>CTRL-ALT-F1</kbd> et <kbd>CTRL-ALT-F7</kbd>, l'affichage devrait revenir. Ensuite, allez dans <kbd>/etc/hibernate/ususpend-ram.conf</kbd> et décommentez la ligne <kbd>USuspendRamVbeSave yes</kbd> pour sauvegarder l'état vidéo avant mise en veille et le restaurer au réveil. 
</p>
<p>
  Sur l'U810,  la mise en veille s'effectue en <b>8 s</b> à l'allée et <b>6 s</b> au retour. Sur ma machine de bureau c'est simplement instantané. Vu le gain d'énergie que cela représente, on aurait tord de s'en priver à chaque pause café...
</p>
<p>
  Toujours concernant l'U810, le contrôleur vidéo semble avoir du mal à revenir de sa veille lorsque metacity est me mode composite (fenêtres ombrées et transparence). Pour régler cela, il faut ajouter dans <kbd>/etc/hibernate/ram.conf</kbd> le paramétre <kbd>SwitchToTextModeOnResume yes</kbd>.
</p>


	<a name='chapter_4'></a>
  <h2>Hibernation</h2>
	
<p>
  A ce stade la mise en veille devrait fonctionner et du coup l'hibernation aussi. La seule chose à faire avant est de définir l'endroit "physique" où <kbd>s2disk</kbd> va sauver l'état de la machine. Le plus simple pour cela est d'utiliser la partition de SWAP qui ne servira pas à grand chose une fois la machine éteinte. Normalement vous devez avoir une partition de swap au moins égale à la taille de votre mémoire. Cependant <kbd>s2disk</kbd> a le bon gout de compresser sa sauvegarde, permettant ainsi de dépasser quelque peu cette limitation. 
</p>
<p>
  Pour connaître la partition utilisée pour le swap sur votre machine, il suffit d'utiliser <kbd>swapon</kbd> :
  
  <div class='code-block code-block-traces'>
  <div class='container'>
  <div class='command'><span class='prompt'>root#</span>swapon -s</div><div class='result'>Filename				Type		Size	Used	Priority</div><div class='result'>/dev/sda5                               partition	4088500	0	-1</div><div class='command'><span class='prompt'>root#</span><span class='cursor'>&nbsp;</span></div>
  </div>
  
  </div>
</p>
<p>
  Ensuite, éditez le fichier <kbd>/etc/suspend.conf</kbd>, le fichier de paramétrage de <kbd>s2disk</kbd>, et remplacez la valeur de <kbd>resume device</kbd> par ce que <kbd>swapon -s</kbd> vous a donné comme partition.   
<p>
<p>
  Ceci fait, vous devez aussi indiquer au kernel où trouver ces sauvegardes lorsqu'il démarrera. Pour cela, allez dans <kbd>/boot/grub/menu.lst</kbd>, et à la bonne ligne <kbd>kernel</kbd> vérifiez la présence d'un paramètre <kbd>resume=/dev/sda5</kbd>. S'il n'est pas là ou si le chemin est mauvais, modifiez et sauvez. 
</p>
<p>
  Il ne reste maintenant plus qu'à tenter une hibernation 
  
  <div class='code-block code-block-fragment'>
  <div class='container'>
  hibernate --<span class="re2">verbosity=</span><span class="nu0">3</span>
  </div>
  
  </div>
</p>
<p>
   Normalement la machine a passé un temps à afficher la progression d'une sauvegarde d'état, et s'est éteint physiquement. Une pression sur le bouton d'allumage et le kernel Linux démarre puis stoppe sa progression pour recharger la sauvegarde. Et c'est terminé. 
</p>
<p>
  Si vous obtenez dans les traces une erreur du genre 
 
  <div class='code-block code-block-traces'>
  <div class='container'>
  <div class='command'><span class='prompt'>root#</span>hibernate -v3</div><div class='result'>...</div><div class='result'>hibernate: Running /usr/sbin/s2disk ...</div><div class='result'>suspend: Could not stat the resume device file</div><div class='result'>...</div><div class='command'><span class='prompt'>root#</span><span class='cursor'>&nbsp;</span></div>
  </div>
  
  </div>
</p>
<p>
  Il y a de fortes chances que le paramètre <kbd>resume device</kbd> soit faux, vérifiez-le et corriger. 
</p>
<p>
    Sur l'U810, l'hibernation prend 28 s à l'allée, et 33 secondes au retour. C'est déjà mieux qu'un allumage classique.  Notez que la désactivation de la compression ne semble pas entraîner une résurrection plus rapide. Sur une machine de bureau, l'extinction prends <b>4 seconds</b> et l'allumage <b>20s</b>.
</p> 


	<a name='chapter_5'></a>
  <h2>La colle avec gnome-power-manager</h2>
	
<p>
  Gnome Power Manager est l'outil standard de gnome pour la gestion de l'énergie. Il dispose d'une petite icône dans la barre de notification permettant la mise en veille et l'hibernation. Il a aussi le bon goût de connecter la touche <kbd>C-alt-D</kbd>, sous le lecteur d'empreintes, à la fonction <kbd>mise en veille</kbd>. 
</p>
<p>
  le problème est qu'il utilise une méthode d'hibernation et de mise en veille qui plante l'U810 ou le laisse sans écran. La solution est aussi simple qu'infernal à trouver. Il faut pour cela parler à .. HAL. Et modifier deux scripts qui se trouvent dans <kbd>/usr/lib/hal/scripts/linux/</kbd>. Tout d'abord <kbD>hal-hal-system-power-suspend-linux</kbd> où l'on trouve la raison du problème  : il ne prends en charge que pm-utils et pas hibernate. Pour régler cela modifiez pour que cela ressemble à ceci :

  <div class='code-block code-block-fragment'>
  <div class='container'>
  ...<br />
<span class="co0"># We only support pm-utils</span><br />
<span class="sy0">/</span>usr<span class="sy0">/</span>sbin<span class="sy0">/</span>hibernate --config-<span class="re2">file=</span><span class="sy0">/</span>etc<span class="sy0">/</span>hibernate<span class="sy0">/</span>ram.conf<br />
<br />
<span class="co0"># Refresh devices as a resume can do funny things</span><br />
...
  </div>
  
  </div>
</p>
<p>
  Maintenant que ce problème est réglé passons à l'hibernation en modifiant <kbd>hal-system-power-hibernate-linux</kbd> qui a le même problème que le frèrot :

  <div class='code-block code-block-fragment'>
  <div class='container'>
  <span class="co0"># We only support pm-utils</span><br />
<span class="sy0">/</span>usr<span class="sy0">/</span>sbin<span class="sy0">/</span>hibernate<br />
<br />
<span class="co0">#Refresh devices as a resume can do funny things</span>
  </div>
  
  </div>
</p>

<p>
Voilà, maintenant tout marche directement par gnome <img src="http://artisan.karma-lab.net/sites/all/modules/contrib/smileys/packs/crystal/smile.gif" title="Smiling" alt="Smiling" class="smiley-content"/> Et il est même possible de télécommander le tout en utilisant DBUS. Par exemple pour hiberner :

  <div class='code-block code-block-fragment'>
  <div class='container'>
  dbus-send --session --<span class="re2">dest=</span>org.freedesktop.PowerManagement --<span class="re2">type=</span>method_call --print-reply --reply-<span class="re2">timeout=</span><span class="nu0">2000</span> <span class="sy0">/</span>org<span class="sy0">/</span>freedesktop<span class="sy0">/</span>PowerManagement org.freedesktop.PowerManagement.Hibernate
  </div>
  
  </div>
</p>

	<a name='chapter_6'></a>
  <h2>Conclusion</h2>
	
<p>
 Bref, vous l'aurez remarqué, ça ne fût pas de tout repos mais le résultat est là, ça fonctionne et même très bien. Si pour un portable ce genre de paramétrage est simplement vitale, pour une machine de bureau, cela permet de gagner énormément sur la consommation énergétique. Car sincèrement, même pour une pause café, 24 secondes auquel il faut rajouter 10s pour le démarrage du BIOS, c'est pas très cher payer.  Et moins d'électricité consommé c'est un argument de moins pour certains empaffés de notre connaissance pour nous coller un 3ième EPR...
</p>
    ]]></content>
  </entry>
</feed>
