Geekeries et d'autres choses - Mot-clé - systemd2024-01-29T10:26:26+01:00urn:md5:51ff50324f4f72c0e78683659647f2c8DotclearMes problèmes de suspend, et comment je les ai résolusurn:md5:d67b9d823730a607066156a647a4642a2015-07-05T10:36:00+02:002024-01-29T11:19:43+01:00Julien WajsbergInformatiquelinuxsuspendsystemdtouchscreen<p>Depuis quelque temps, je restais sur le noyau 3.14 car c'était le seul qui fonctionnait sans trop de souci. Notamment les noyaux plus récents provoquaient des soucis au <em>suspend</em>: le PC se réveillait presque immédiatement.</p>
<p>J'ai essayé récemment le noyau 4.1 compilé manuellement, et j'ai eu le même souci... et même un souci supplémentaire puisqu'il ne se mettait parfois même plus en veille. Il était temps de déboguer un peu tout ça.</p>
<p><strong>Update novembre 2016</strong>: j'ai changé le type de service pour <code>multitouch_reload</code>.</p> <h3>Le PC ne se met plus en veille.</h3>
<p>La première étape consiste à comprendre pourquoi le PC ne se mettait plus en veille. Un peu de logs supplémentaires nous seraient utiles. Le plus simple pour les activer temporairement est d'exécuter la commande suivante en <em>root</em>:</p>
<pre>
systemctl set-environment SYSTEMD_LOG_{LEVEL=debug,TARGET=journal}
systemctl restart systemd-logind
</pre>
<p>Une fois ces commandes exécutées, on peut avoir des logs avec la commande <code>journalctl -b -u systemd-logind</code>:</p>
<pre>
juil. 01 08:12:22 beitou systemd-logind[22720]: Lid closed.
juil. 01 08:12:22 beitou systemd-logind[22720]: Ignoring lid switch request, 4 displays connected.
juil. 01 08:12:22 beitou systemd-logind[22720]: Ignoring lid switch request, 4 displays connected.
juil. 01 08:12:28 beitou systemd-logind[22720]: Lid opened.
</pre>
<p>Oh, j'ai donc 4 moniteurs connectés en même temps ! Ah, en fait non. Il doit donc y avoir une détection qui échoue. Pour en savoir plus, on peut demander gentiment à ACPI:</p>
<pre>
$ cat /sys/class/drm/*/*/status
unknown
unknown
unknown
unknown
</pre>
<p>Mais je m'aperçois qu'après un boot les valeurs sont correctes:</p>
<pre>
$ cat /sys/class/drm/*/*/status
disconnected
connected
disconnected
disconnected
</pre>
<p>Les valeurs deviennent incorrectes uniquement après un retour de veille. Cependant elles redeviennent normales après (par exemple) un appel à <code>xrandr</code>.</p>
<p>Après <a href="https://bugzilla.kernel.org/show_bug.cgi?id=100741">quelques rapports</a> <a href="https://github.com/systemd/systemd/issues/451">de bug</a>, j'ai des pistes. Il semble que ce souci n'arrive que depuis le noyau 4.1. Après avoir appliqué <a href="http://thread.gmane.org/gmane.comp.freedesktop.xorg.drivers.intel/62584/focus=62733">le patch d'un mail de la liste du noyau</a>, ce premier souci est corrigé. Il semble aussi que systemd v221 inclue un contournement au souci, mais je ne l'ai pas essayé.</p>
<p>Place aux autres soucis !</p>
<h3>Le PC se réveille après quelques secondes.</h3>
<p>Quelques forums m'ont mis la puce à l'oreille: il semble que ce soit le module USB qui envoie des événements de réveil.</p>
<p>On peut le voir en affichant <code>/proc/acpi/wakeup</code>:</p>
<pre>
$ cat /proc/acpi/wakeup
Device S-state Status Sysfs node
P0P1 S4 *disabled
XHC S3 *enabled pci:0000:00:14.0
HDEF S4 *disabled pci:0000:00:1b.0
RP01 S4 *disabled pci:0000:00:1c.0
PXSX S4 *disabled
RP03 S4 *disabled pci:0000:00:1c.2
PXSX S5 *disabled pci:0000:04:00.0
PXSX S4 *disabled pci:0000:05:00.0
*disabled platform:rtsx_pci_sdmmc.0
*disabled platform:rtsx_pci_ms.0
PEG0 S4 *disabled
PEGP S4 *disabled
PEG1 S4 *disabled
PEG2 S4 *disabled
LID0 S4 *enabled platform:PNP0C0D:00
</pre>
<p>Cela sert normalement à réveiller le PC si le clavier est actionné, mais on dirait que des événements sont envoyés qui ne devraient pas être reçus... La solution évidente consiste à désactiver cette fonction (en root):</p>
<pre>
# echo XHC > /proc/acpi/wakeup
$ cat /proc/acpi/wakeup
Device S-state Status Sysfs node
P0P1 S4 *disabled
XHC S3 *disabled pci:0000:00:14.0
HDEF S4 *disabled pci:0000:00:1b.0
RP01 S4 *disabled pci:0000:00:1c.0
PXSX S4 *disabled
RP03 S4 *disabled pci:0000:00:1c.2
PXSX S5 *disabled pci:0000:04:00.0
PXSX S4 *disabled pci:0000:05:00.0
*disabled platform:rtsx_pci_sdmmc.0
*disabled platform:rtsx_pci_ms.0
PEG0 S4 *disabled
PEGP S4 *disabled
PEG1 S4 *disabled
PEG2 S4 *disabled
LID0 S4 *enabled platform:PNP0C0D:00
</pre>
<p>Pour l'exécuter au boot, voici ce que j'ai fait.</p>
<p>J'ai d'abord édité <code>/etc/systemd/system/disable-xhc-wakeup.service</code> avec le contenu suivant:</p>
<pre>
[Unit]
Description=Disable XHC Wakeup
[Service]
ExecStart=/usr/local/bin/disable-xhc-wakeup
[Install]
WantedBy=multi-user.target
</pre>
<p>Puis j'ai édité <code>/usr/local/bin/disable-xhc-wakeup</code> avec ce contenu:</p>
<pre><code class="language-bash">#!/bin/sh
if grep -q XHC.*enabled /proc/acpi/wakeup ; then
echo XHC > /proc/acpi/wakeup
fi</code></pre>
<p>Et j'ai enfin activé ce nouveau service (en root):</p>
<pre>
# systemctl enable disable-xhc-wakeup.service
</pre>
<h3>Le touchscreen ne fonctionne plus après un <em>resume</em></h3>
<p>Après un peu de recherche, j'ai découvert que simplement décharger et recharger le module <code>hid_multitouch</code> corrigeait le souci:</p>
<pre>
modprobe -r hid_multitouch
modprobe hid_multitouch
</pre>
<p>Il ne reste plus qu'à le faire de manière systématique.</p>
<p><strong>Attention</strong>, beaucoup de documentation pointe vers <code>/usr/lib/pm-utils/defaults</code>, mais ce fichier n'est plus utilisé avec <code>systemd</code>.</p>
<p>J'ai donc créé un fichier <code>/etc/systemd/system/reload_multitouch.service</code>:</p>
<pre>
[Unit]
Description=Reload hid_multitouch kernel module
After=sleep.target
[Service]
Type=oneshot
ExecStart=/sbin/modprobe -r hid_multitouch ; /sbin/modprobe hid_multitouch
[Install]
WantedBy=sleep.target
</pre>
<p>Puis je l'ai activé:</p>
<pre>
# systemctl enable reload_multitouch
</pre>
<p>Et voilà !</p>
<p><a href="https://bugzilla.kernel.org/show_bug.cgi?id=100951">J'ai rapporté le bug sur le bugtracker du noyau Linux</a> donc vous pourrez suivre la résolution éventuelle !</p>