Ubuntu, comment régler le problème de mise en veille

Par le dans . Marqué comme , , , avec 19 Commentaires

Ubuntu, comment régler le problème de mise en veille

Plop,

Après avoir galéré un bon moment avec ma nouvelle machine (celle dont je parle dans mon billet précédent pour ceux qui suivent ^^), j’ai décidé de partager avec vous la solution à un problème que j’ai rencontré … c’est à dire … l’impossibilité de mettre en veille son ordinateur.

J’ai installé sur mon laptop Asus il y a quelques semaines maintenant, la distribution GNU/Linux Ubuntu 12.10 en 64 bits.

Jusque là, pas de problème en particulier et la machine fonctionnait parfaitement. Suite à une mise à jour, je me suis rendu compte que la mise en veille ET l’hibernation du système ne fonctionnaient plus. Et franchement … une machine portable qui ne se met plus en veille, ce n’est pas super pratique xD

Je me suis donc mis en quête d’une solution viable et j’ai fini par trouver mon bonheur après de nombreuses heures de recherches dans les abysses de la Toile. Si vous êtes dans la même situation que moi, j’ai donc ce qu’il vous faut pour arrêter de vous prendre la tête et retourner à une activité plus « productive » :)

Origine du problème :

D’après ce que j’ai pu lire et suite à quelques tests, j’ai pu comprendre que le processus de mise en veille du système d’exploitation était annulé lors de son initialisation.

Cette annulation est, dans la plupart des cas, causée par la présence d’un composant au sein de la machine qui refuse de « couper » son alimentation. Ces fameux composants désobéissants peuvent être les cartes graphique, les cartes son, les contrôleurs de ports USB ou les cartes réseaux (Ethernet, Wifi, Bluetooth, etc.).

Mais comment cibler le composant fautif et repérer l’origine du problème ?!

Suite à mes différents essais et à l’aide de plusieurs personnes avec qui j’ai pu discuter sur le canal IRC d’Ubuntu France (merci à eux d’ailleurs), j’ai pu trouver en « fouinant » dans les logs de ma machine plusieurs messages d’erreurs qui m’ont mis sur la piste d’une solution.

Comment récupérer les logs d’une mise en veille ?!

Pour cela, il n’y a pas d’autre solution que de mettre les mains dans le cambouis et de dégainer son terminal favori.

Nous allons donc analyser le contenu des fichiers suivants :

  • /var/log/pm-suspend.log
  • /var/log/syslog.

Pour ceux qui ont déjà mis le nez dans ces fichiers, vous savez que de nombreuses informations inutiles à notre enquête sont présentes et en particulier dans le fichier syslog.
Afin de ne garder que les informations nécessaires, il suffit d’utiliser la commande tail qui permet d’afficher sur la sortie standard les 10 dernières lignes du fichier qu’on lui passe en paramètre. Nous utiliserons aussi l’option -f qui affiche en temps réel les informations qui sont ajoutées au fichier étudié.

Dans un premier onglet de votre terminal, tapez la ligne de commande suivante, puis ajoutez quelques lignes vides pour séparer les informations qui s’afficheront à celles déjà présentes dans le fichier :

tail -f /var/log/pm-suspend.log

Dans un deuxième onglet de votre terminal, tapez la ligne de commande suivante, puis ajoutez quelques lignes blanches pour séparer les informations qui s’afficheront à celles déjà présentes dans le fichier :

tail -f /var/log/syslog

Ouvrez ensuite un troisième onglet dans votre terminal et entrez la commande suivante :

sudo pm-suspend

Cette commande permet de lancer une mise en veille de la machine qui va forcément planter sinon vous ne sauriez pas en train de lire ce billet ^^

Les deux premières commandes ont alors permis de récupérer les logs que la mise en veille a généré, nous allons donc pouvoir les analyser.

En ce qui me concerne, j’ai fini par tomber sur ces lignes qui m’ont mis la puce à l’oreille :

Feb 20 11:22:38 sadaharu kernel: [  297.626898] alx 0000:03:00.0: PHY SPD/DPLX unresolved :ffff
Feb 20 11:22:38 sadaharu kernel: [  297.626901] alx 0000:03:00.0: eth0: shutown err(ffffffea)
Feb 20 11:22:38 sadaharu kernel: [  297.626903] alx 0000:03:00.0: shutdown fail in suspend -5
Feb 20 11:22:38 sadaharu kernel: [  297.626916] pci_pm_suspend(): alx_suspend+0x0/0x90 [alx] returns -5
Feb 20 11:22:38 sadaharu kernel: [  297.626922] dpm_run_callback(): pci_pm_suspend+0x0/0x140 returns -5
Feb 20 11:22:38 sadaharu kernel: [  297.626924] PM: Device 0000:03:00.0 failed to suspend async: error -5

Nous avons maintenant la preuve qu’un composant empêche la mise en veille de la machine … mais comment savoir de quel composant il s’agit ?!
Il faut alors utiliser la commande « magique » et indispensable dans ce genre de cas … j’ai nommé « LSPCI« . Cette commande permet de lister les périphériques connectés aux bus PCI de sa carte mère et d’afficher des informations les concernant.

Voici la commande en question, l’option -nn permet d’afficher des informations sur le fabricant du matériel ainsi que son nom et sa référence.

lspci -nn

Voici ce que j’obtiens :

00:00.0 Host bridge [0600]: Intel Corporation 2nd Generation Core Processor Family DRAM Controller [8086:0104] (rev 09)
00:02.0 VGA compatible controller [0300]: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller [8086:0106] (rev 09)
00:14.0 USB controller [0c03]: Intel Corporation 7 Series/C210 Series Chipset Family USB xHCI Host Controller [8086:1e31] (rev 04)
00:16.0 Communication controller [0780]: Intel Corporation 7 Series/C210 Series Chipset Family MEI Controller #1 [8086:1e3a] (rev 04)
00:1a.0 USB controller [0c03]: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #2 [8086:1e2d] (rev 04)
00:1b.0 Audio device [0403]: Intel Corporation 7 Series/C210 Series Chipset Family High Definition Audio Controller [8086:1e20] (rev 04)
00:1c.0 PCI bridge [0604]: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 1 [8086:1e10] (rev c4)
00:1c.1 PCI bridge [0604]: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 2 [8086:1e12] (rev c4)
00:1c.3 PCI bridge [0604]: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 4 [8086:1e16] (rev c4)
00:1d.0 USB controller [0c03]: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #1 [8086:1e26] (rev 04)
00:1f.0 ISA bridge [0601]: Intel Corporation 7 Series Chipset Family LPC Controller [8086:1e5e] (rev 04)
00:1f.2 SATA controller [0106]: Intel Corporation 7 Series Chipset Family 6-port SATA Controller [AHCI mode] [8086:1e03] (rev 04)
00:1f.3 SMBus [0c05]: Intel Corporation 7 Series/C210 Series Chipset Family SMBus Controller [8086:1e22] (rev 04)
02:00.0 Network controller [0280]: Atheros Communications Inc. AR9485 Wireless Network Adapter [168c:0032] (rev 01)
03:00.0 Ethernet controller [0200]: Atheros Communications Inc. AR8162 Fast Ethernet [1969:1090] (rev 10)

Et que pouvons nous remarquer ? Une information présente dans la première colonne du résultat retournée par la commande me rappelle quelque chose, pas vous ?

Regardez de plus près : PM: Device 0000:03:00.0 failed to suspend async: error -5z

On dirait que l’on retrouve l’identifiant de notre composant rebelle non ?!

03:00.0 Ethernet controller [0200]: Atheros Communications Inc. AR8162 Fast Ethernet [1969:1090] (rev 10)

Voilà qui va nous être utile pour avancer dans nos recherches !!

Pour information, on m’a également donné sur le canal IRC d’Ubuntu la commande suivante :
$ lspci -nn | grep ‘0200’
Elle retourne précisément la ligne concernant la carte Ethernet, mais je ne suis actuellement pas capable de l’expliquer. Si vous avez une explication, je suis preneur !

A la recherche de la cause de ce problème :

Cette information en poche, je suis reparti à la chasse aux informations sur le Net et j’ai trouvé sur le forum d’Ubuntu un poste ultra complet (en anglais) d’une personne qui explique la source de tous nos tracas. Il se trouve que pour certaines cartes de la marque Atheros et en particulier les cartes Atheros Communications Inc. AR8162 Fast Ethernet (mais aussi de nombreuses autres), les drivers utilisés par défaut par Ubuntu ne sont pas pleinement fonctionnels. La solution est donc de réinstaller ces drivers pour rendre pleinement fonctionnelle notre carte réseau.

Une solution simple à mettre en place :

Ok, nous sommes prêts à appliquer notre correctif, mais avant toute chose, un petit récapitulatif :
Sous Ubuntu (toutes versions) et pour certaines machines possédant des cartes réseaux Atheros Commmunication Inc, des problèmes de compatibilité du matériel peuvent être rencontrés.
Nous allons donc suivre les manipulations suivantes pour ré-installer une version correcte des drivers réseaux et régler « temporairement » ce problème. Je précise temporairement, oui et non, j’y reviendrai plus tard.

# On se place dans un répertoire (celui de votre choix est également possible)
cd Documents
# On récupère et installe des paquets qui seront utiles à la compilation du pilote réseau
sudo apt-get install linux-headers-generic build-essential
# On télécharge les sources du pilote à installer sur la machine
wget http://www.orbit-lab.org/kernel/compat-wireless-3-stable/v3.5/compat-wireless-3.5.1-1-snpc.tar.bz2
# On décompresse l'archive fraîchement récupérée
tar -xf compat-wireless-3.5.1-1-snpc.tar.bz2
# On se place dans le répertoire créé lors de la décompression
cd compat-wireless-3.5.1-1-snpc
# On exécute un script permettant de sélectionner le pilote à installer
sudo ./scripts/driver-select alx
# On compile le pilote pour sa machine
make
# On installe le pilote que l'on vient de compiler
sudo make install
# On sélectionne le pilote à utiliser
sudo modprobe alx

Après avoir exécuté l’ensemble de ces commandes sans erreur, il sera nécessaire de redémarrer la machine. La carte réseaux Ethernet est maintenant pleinement fonctionnelle.

Pour le vérifier, je vous conseille la commande suivante qui permet de connaître l’état des cartes réseaux :

sudo lshw -C network 

Pour en savoir plus, voici ce que retourne un man lshw :
lshw is a small tool to extract detailed information on the hardware configuration of the machine.

Une solution temporaire … Mais WTF ?!

Comme promis, je reviens sur cette notion de solution temporaire. C’est très simple, les drivers qui viennent d’être installés, l’ont été pour la version des noyaux présents sur votre machine.
Lors d’une mise à jour de ces noyaux (ce qui arrive régulièrement), les drivers ne seront alors plus compatibles avec les noyaux utilisés et une réinstallation de ceux-ci sera nécessaire.

C’est un peu contraignant, mais pour le moment je n’ai pas trouvé mieux … Enfin rien de bien compliqué, il vous suffira de ré-exécuter les commandes suivantes et de redémarrer :

cd Documents 
tar -xf compat-wireless-3.5.1-1-snpc.tar.bz2
cd compat-wireless-3.5.1-1-snpc
./scripts/driver-select alx
make
sudo make install
sudo modprobe alx

Astuces et informations supplémentaires :

Dans ce chapitre, je liste quelques informations et/ou commandes que j’ai trouvé intéressantes et qui m’ont été utiles pour la rédaction de ce billet.

Logs de mise en veille :
$ tail -f /var/log/pm-suspend.log
$ tail -f /var/log/syslog

Liste de commandes utiles :
pm-suspend : permet la mise en veille de la machine
pm-hibernate : permet la mise en veille prolongée de la machine
pm-suspend-hybrid : permet d’utiliser un système de mise en veille mixant mise en veille normale et hibernation. Cela permet d’économiser l’énergie et l’espace disque car cela n’utilise pas la partition swap de la distribution.
pm-powersave : permet de configurer l’ordinateur dans un mode économie d’énergie afin de réduire sa consommation électrique et d’augmenter la durée de vie des batteries des machines portables.
rfkill list all : permet de connaître l’état du matériel réseau de la machine (soft blocked ou hard blocked).
nm-tool : permet d’obtenir des informations sur les cartes réseaux en fonction sur la machine

Pour conclure :

J’espère que vous n’aurez pas trouvé ce billet trop violent et que mes explications sont assez claires et compréhensibles.
J’espère également qu’en tombant sur cet article, vous aurez gagné un peu de votre temps, car pour récupérer l’ensemble de ces informations et pouvoir à nouveau utiliser mon pc portable avec une mise en veille stable, il m’aura tout de même fallu plusieurs heures de travail ^^

Si vous avez des questions ou des précisions à apporter, n’hésitez pas à m’en faire part dans les commentaires, je mettrai le billet à jour si nécessaire :)

Sources utilisées pour la rédaction de l’article :
– Poste sur le forum Ubuntu utilisé pour la rédaction de ce billet : http://ubuntuforums.org
– Plusieurs âmes charitables présentes sur le channel #ubuntu-fr du serveur IRC Ubuntu, encore une fois, merci à eux ;)

Sources des images utilisées en illustrations :
– L’image utilisée en illustration de ce billet a été réalisée par mes soins sur une idée originale d’Howlburn !

19 Commentaires


  1. Super tuto très bien fait, j’ y ai retrouvé des commandes oubliées et que je ne connaissais pas.
    Cela m’a fait gagner un temps précieux merci.

  2. bonjour, j’ai un problème avec la commande : sudo ./scripts/driver-select alx
    mon ordinateur dit que c’est une commande introuvable…
    aidez moi s’il vous plaît ^^’
    ah et aussi… ça veut dire quoi alx ?

    • Salut Théo :)

      Alors pour répondre à ta question, « alx » est le nom du driver que la ligne de commande que tu as exécuté permet d’installer sur ta machine.
      Pourrais-tu me donner l’erreur exacte que te retournes ton terminal stp histoire de voir un peu ce que raconte ta machine ?
      Autre question, tu as suivi le tuto à la lettre ou tu l’as modifié un peu pour qu’il respecte les nouvelles versions des paquets utilisés ?

      N’hésites pas à repasser et bonne soirée !

  3. Salut, et bonne année a tous linuxien ou pas je suis pas comme ça(moi aussi j’ai encore un pied sous MS)…
    Pas loin d’un an après cette manip m’aura aidé à identifier un de mes soucis sous 14.04. Le coupable c’était la carte graphique alors j’ai tenté un « coup de poker » avec les pilotes proprio nvidia et ça marche.Elle faisait planter au démarrage, pendant les mises en veille et en sortie de veille mais c »est du passé grace a cette manip le coupable est démasqué MERCIIII

    • CooooL ! Content d’avoir pu t’aider, c’est sympa de savoir que cette astuce est encore valable depuis le temps.
      Merci d’avoir pris le temps de laisser un petit commentaire, cela me va droit au cœur :)
      Surtout n’hésites pas à repasser par ici si tu as besoin d’aide sur d’autres sujets, j’essaierai de t’aider si j’en suis capable !

  4. Salut, Merci pour ce tuto très bien fait et instructif.
    En cherchant pour trouver une solution à mon problème de mise en veille, j’ai trouvé ça :

    « L’installation « en créant un paquet .deb » proposée ci-dessous permet de charger dynamiquement le module du pilote pour ne plus avoir à le recompiler à chaque mise à jour du noyau Linux. »

    Paragraphe 2.2 du lien suivant http://doc.ubuntu-fr.org/catalyst#via_le_site_officiel.

    Cela pourrait aider pour ne pas réinstaller à chaque maj des noyaux!

    Bonne journée

    • Salut Edouard,

      Merci pour le partage du lien, je pense en effet que cela peut être une solution plus « propre » pour résoudre ce problème de mise en veille !
      Tu as installé le paquet sur ta machine ? Depuis tout est OK ? Les mises à jour se font correctement ?

      Encore merci pour le retour et @ bientôt :)

      • Non, je n’ai pas encore résolu mon problème.
        Cela provient de ma carte graphique, Gallium 0.4 on AMD KABINI, mais je n’ai pas trouver de driver qui marche.
        Je peux lancer la veille mais l’ordinateur redémarre à la sortie. Je n’ai donc pas testé le paquet.

        @+

  5. Re ! après un voyage au Canada je reviens, donc pour t’expliquer, quand je fais la commande :

    wget http://www.orbit-lab.org/kernel/compat-wireless-3-stable/v3.5/compat-wireless-3.5.1-1-snpc.tar.bz2

    il me met :

    requête HTTP transmise, en attente de la réponse… 404 Not Found
    2015-01-23 18:43:49 ERREUR 404: Not Found.

    j’en ai donc déduit qu’il y avait un problème là ! et oui je suis intelligent xD mais autre chose m’a préoccupé, quand j’ai fait la commande d’avant, c’est à dire :

    sudo apt-get install linux-headers-generic build-essential

    il me dit tout ce qu’il faut puis un truc qui me tracasse :

    Veuillez utiliser « apt-get autoremove » pour les supprimer.
    0 mis à jour, 0 nouvellement installés, 0 à enlever et 18 non mis à jour.

    est-ce ça qui fait planter ? merci d’avance ^^

    • Salut Théo la forme ?

      Tu reviens du Canada … roooh c’est cool ça, j’adore ce pays !! Tu as été dans quel coin ?

      Concernant l’erreur 404 pour le wget, cela signifie tout simplement que le fichier n’est plus disponible à l’adresse demandée.
      J’ai vérifié, et en effet, le fichier n’est plus présent sur le serveur orbit-lab. Par contre, je l’ai encore sur une de mes machines… mais avant que je trouve un moyen de te le rendre accessible, es-tu sûr que c’est bien de ce driver dont tu as besoin ? Ta machine est bien équipée d’une carte Atheros ?

      Concernant ta seconde question, tu ne risques rien, la commande « apt-get autoremove » est utilisée pour supprimer les paquets (présent sur ta machine) qui ont été automatiquement installés pour satisfaire les dépendances pour d’autres paquets et qui ne sont désormais plus nécessaires. Pour plus d’informations, je te conseille de taper la commande suivante dans ton Terminal « man apt-get » cela te permet d’accéder au manuel de la commande apt-get.

      J’attends une réponse de ta part concernant la marque de ta carte :)

      Bonne soirée !

  6. Yoh ! donc chuis allé au Yukon, c’était sympa mais je préfère le Japon XD
    sinon, apparemment ma carte graphique est une Intel® Sandybridge Mobile
    du coup je sais pas quoi faire ^^’
    merci de répondre vite ^^

    • Je n’ai pas encore eu l’occasion d’aller visiter le Japon, mais j’avoue que ce pays est sur ma liste d’endroits à visiter ;)
      Tu en es où du coup de ton problème de carte ? Tu as toujours ton problème de mise en veille ?

      • Et oui toujours le meme problème… Vu qu’il s’agit d’une carte Intel® Sandybridge Mobile le programme doit etre différent… Et comme je suis vraiment nul en informatique je sais pas du tout quoi faire…

        • Je t’avouerai que n’ayant pas accès à ce type de matériel c’est un peu compliqué de t’aider, à la base, j’ai rencontré ce problème avec ma carte réseau …

          Tu n’as pas un bout de logs à me donner ou quelque chose qui puisse orienter nos recherches ?
          Regardes ce lien quelqu’un y explique comment installer les drivers les plus récents pour ce type de carte graphique … avec un peu de chance, ton problème vient de là !
          Ou encore ce lien qui explique comment réinstaller les drivers par défaut.

          Bon courage pour les manipulations :)

  7. Bonjour,

    mieux vaut tard que jamais donc un peu de dépoussiérage :D

    Alors pour répondre a la question « pourquoi la commande : $ lspci -nn | grep ‘0200’ retourne précisément la ligne concernant la carte Ethernet ? »

    c’est parce que ce [0200] correspond a la classe du périphérique, ici le contrôleur réseau (02) mais plus particulièrement l’ethernet (00) (pour le network controller nous verrions [0280] )

    Comme le partage c’est le savoir et l’apprentissage, on peut trouver pas mal d’information sur le décodage des données de PCI et de sortie lspci sur les hôtes Linux ici : http://prefetch.net/articles/linuxpci.html

    bonne lecture :)

    • Hello Gurty,

      Un grand merci pour le partage de cette information et du lien qui explique pas mal de choses.
      Il est vrai que je n’avais pas pris le temps de creuser plus loin concernant ce point, j’avais lu quelques trucs par ci par là mais sans plus.

      C’est un sujet intéressant, cela mériterait un article pour en dire plus !

N'hésitez pas, laissez un commentaire — DoFollow activé sur ce site —


« »