New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
nvidia & hibernation #656
Comments
Hi, in an earlier version TLP actually contained your workaround, i.e. applying AC settings before a suspend/hibernate. You can reactivate this old behavior by configuring:
|
Thank you for the tip! I threw that parameter into tlp and ran a few tests for fairness. After it didn't work, I tried changing from 1 to 0, but it still won't hibernate on battery unless I use the script method. My unenlightened guess is that the tlp service is too deep in the process tree, and therefore too late, to apply any settings that would affect hibernation once the process begins. |
Not a tlp bug, can't be fixed by tlp. |
Did you test by executing
Using 0 is pointless. 1 is the only value that brings the desired behaviour. |
No, Void Linux is runit. There is no systemctl because there is no systemd. |
Well. A quick look at zzz reveals that it provides hooks in /etc/zzz.d/suspend/ and /etc/zzz.d/resume/. I don't know if the Void maintainer provisoned the necessary hooks in the tlp package. See Architecture for requirements. |
As far as I can see, he did not do that: https://github.com/void-linux/void-packages/blob/master/srcpkgs/tlp/template . Only TLP's script for elogind gets installed. I think you should resolve this with an issue against the Void tlp package. |
OK, this is becoming a little beyond my comprehension here, but do I understand correctly - if I were to trigger hibernation somehow using elogind, the flags we tested might work? |
Yes. But you can just as well create hook scripts for zzz: /etc/zzz.d/suspend/tlp
/etc/zzz.d/resume/tlp
Remember to make them executable. |
Thanks linrunner. I can see you went out of your way to help here. I'll try these hooks tomorrow and update then. |
As instructed:
Unfortunately, it didn't work, same as before, it hangs on hibernate unless AC is on or I use tlp to 'trick' the system into thinking it is. |
I'm aware that your real problem is the nvidia card and/or its driver. However, while looking for a workaround, I noticed that TLP doesn't seem to be called before and after hibernate (and suspend). This is not just about additional pm functionality that you need. The reason might be the Void What I need is a trace of a hibernate/resume cycle. For this you would have to add the following to your configuration
Then - on battery of course - hibernate by means of
|
OK, no worries!
At this point, Xorg stops, I get a cursor in TTY, and the system hangs indefinitely, does not power off.
So, I did as above and re-ran the test exactly as above, and here is the debug:
Hope this helps? |
Oh my. I had not considered that the ThinkPad freezes when you do that on battery. For what I need to know - whether the hooks are called - a hibernation/resume cycle on AC is sufficient. Could you test once more on AC? To get the trace before power off we also need one more switch:
|
No worries. So as before except now on AC, this command executed after a succesful hibernation and resume:
|
Now, the picture becomes clearer. The zzz hook calls
I'll see if I can reproduce this. Btw: what you shouldn't do while testing is switching to manual mode with
This could skew the results. |
Unfortunately I cannot reproduce on my system. Please adjust the trace extent to
and perform another hibernate/resume cycle on AC. Post the output of
Since the output is quite long you may show only the relevant part (according to timestamps) or use https://gist.github.com/ |
As req'd
|
Still doesn't contain the info I need ... I have to think about that. |
Perhaps I need a clean power off and bootup first. I think I know better the log section you're chasing too, so I'll cut it short for you. |
Unnecessary. Save yourself the time. |
Please show via Gist https://gist.github.com/ the output of:
|
Are you sure that this debug output is complete? It breaks inside the function save_device_states() and never reaches the call to apply_common_settings() - see https://github.com/linrunner/TLP/blob/1.5.0/tlp.in#L413. This fits exactly with the symptom that no settings are applied. Which shell is used by Void Linux for scripts? |
This is the entire output. I'm using bash for my shell, but I believe the default is dash:
|
Perhaps I could install a different shell and symlink sh to that instead? |
It is sufficient if you do
ps. TLP runs perfectly well with the dash on Debian and Ubuntu but somehow we have to keep trying. |
No worries, I'll get you a result tomorrow. |
Not quite. The bash does what it should, settings are applied. Could you provide the relevant section of the trace after the command, e.g.
|
Thanks. Dash aborts execution here: Line 342 in fe91d13
Bash however continues with rc=1: Line 350 in fe91d13
The whole thing is about saving the current state of all radio devices in |
Rationale: dash aborts executing the line if { : > /var/lib/tlp/rfkill_saved; } 2> /dev/null; then when the directory /var/lib/tlp is non-existent. Moreover 2> conceals the abort. In contrast, bash works as expected. Reference: * #656
No :-)
Would you like me to create this directory? |
Indeed. Afterwards please perform yet another hibernate/resume cycle on AC. Post the output of
Just to be clear: the abort is a bug in dash triggered by the missing directory. The missing directory itself is an issue with the Void tlp package. |
My laptop now hibernates on battery without the need for my script, so you've found and fixed the bug for the void team. Thank you, and well done! Here is the gist as requested: GIST Happy to do more tests for you if need be. |
Great. Thank you for your patience. Do you mind opening a package bug on Void about the missing directory? I would provide additional info if necessary, but I can not test a package correction here. That would be your turn. I would then take care of a bug report for dash. |
Done: here. |
This does not seem to be a bug but an expected behavior of the dash. It actually complies with [POSIX defaults]:(https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_08_01).
The failling null command ( Thanks @dywisor for the clarification. |
Hello,
I have a situation where hibernation with a Lenovo P72 and nvidia xorg driver in use will not hibernate, unless:
Is there any way I can get this idiot graphics card to stop getting in the way of hibernation?
At the moment I'm just using a bash script that needs to be run as root (or the sudo ticket expires):
Thank you so much for TLP!
The text was updated successfully, but these errors were encountered: