Hi,
after scouring the web a bit, I found a workaround:
echo 0 > /sys/power/pm_async
This makes the suspending and resuming process synchronous and solved the
race issue in the disk drivers.
After that the APM levels are correct on resuming.
So in the end this indeed is not a bug in LMT and can be
On Tuesday 24 March 2015 04:02 PM, Ondřej Grover wrote:
> Thank you for the explanation.
> I added
> NOLM_AC_EXEC_COMMAND_0="logger -i 'LM executed'"
> in the exec-command.conf module.
> See the attached log file abou
> t the suspend and resuming process. It seems LM is indeed triggered,
> but perh
Thank you for the explanation.
I added
NOLM_AC_EXEC_COMMAND_0="logger -i 'LM executed'"
in the exec-command.conf module.
See the attached log file abou
t the suspend and resuming process. It seems LM is indeed triggered, but
perhaps the ata link resetting is the real problem.
I'll try to fix the AT
On Tuesday 24 March 2015 02:29 PM, Ritesh Raj Sarraf wrote:
> That it should. We leverage the "trigger on resume" mechanism from udev,
> not systemd.
> So either udev got screwed up recently (which I doubt) or else something
> is overriding the changes.
FYI to self. udev is not screwed. It still i
On Tuesday 24 March 2015 01:36 PM, Ondřej Grover wrote:
> Hello,
>
> I enabled the service and restarted the laptop, it was started as
> expected, but not restarted after suspending, which results in APM
> levels to not be restored as I feared. However, sometimes it is not
> reset (or at least that
Hello,
I enabled the service and restarted the laptop, it was started as expected,
but not restarted after suspending, which results in APM levels to not be
restored as I feared. However, sometimes it is not reset (or at least
that's what I think is happening).
I am willing to test a deb package,
6 matches
Mail list logo
