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

Par le dans . Marqué comme , , , avec 2 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 !

2 Commentaires


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


» Notifiez-moi des commentaires à venir via courriel.
Vous pouvez aussi vous abonner sans commenter.
« »