<div dir="ltr"><div><div><div>Hi,<br><br></div>I'd like to point out that my usage of echo 0 > ... pm_async in 780956 was related more to an apparent race issue in the HDD driver than a udev event. The udev trigger works correctly on my system, but with async pm often after it was triggered and applied requested settings on resume the HDD driver suddenly timed out and the SATA link was reset and lost the settings state.<br></div><div><br></div>Kind regards,<br></div>Ondřej Grover<br><div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 28, 2015 at 6:00 PM, Chris <span dir="ltr"><<a href="mailto:email.bug@arcor.de" target="_blank">email.bug@arcor.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
There is now a specific spin-off from the closed<br>
<a href="https://bugs.debian.org/780956" target="_blank">https://bugs.debian.org/780956</a> (laptop-mode-tools hooks not triggerd)<br>
in the udev binary package: (reassing to src:systemd did not succeed)<br>
<br>
<br>
To ensure packages have a reliable resume event hook available, udev may<br>
echo 0 > /sys/power/pm_async, or some device blacklist may be needed (in<br>
the kernel?) to disable async pm?.<br>
<a href="https://bugs.debian.org/783638" target="_blank">https://bugs.debian.org/783638</a><br>
(original reporters may subscribe)<br>
<br>
The relevant "trigger on resume" mechanism from udev seems to be:<br>
ACTION=="add|remove", SUBSYSTEM=="machinecheck", RUN+="lmt-udev auto<br>
force"<br>
</blockquote></div><br></div>