Sleep on lid close is not suspending system

This [HowTo] I wrote shows you how to change kernel parameters:

(and it’s a good to have that activated anyway). The bit where the kernel parameter gets changed is:

echo kernel.sysrq=1 | sudo tee --append /etc/sysctl.d/99-sysctl.conf

where the kernel parameter being changed is kernel.sysrq=1 so just substitute yours for that one (I don’t know, but it’ll probably be initcall_debug=1, check the article)

:innocent:

1 Like

Its all just to much. I wanted help to make things a little easier not twice as much techno babble as before. Appreciate the help though.

Iv read i can just use /etc/default/grub and add arguments to GRUB_CMDLINE_LINUX_DEFAULT then do a update-grub

Regarding the argument itself, it was just an example. The link i gave list many many for debugging this problem but this is just the first one. It does not say to use an “=1” anywhere?

Quote:-

2.1 initcall_debug

Adding the initcall_debug boot option to the kernel cmdline will trace initcalls and the driver pm callbacks during boot, suspend, and resume. It is useful to check if any specified driver/component fails. Make sure to always enable it when debugging STI/STR/HTD related issues. In general, positive results mean the callback has no error/warning and returns 0 in a reasonable time. This is demonstrated in the following:

[ 76.201970] calling 0000:00:02.0+ @ 2298, parent: pci0000:00 
[ 76.217006] call 0000:00:02.0+ returned 0 after 14677 usec

Negative results means the callback either contains some error/warning, or it takes an unreasonable long time to complete.

After adding it (or any of the others) you still didnt say where i should look for their output?

Suspend issues are difficult in any OS. (including Windows)

Yup, you can do that too. I just thought the command would make your life easier. :innocent: :wink:

The following are a few good starting points:

man dmesg
man journatctl

Sorry for making you read even more, but I can’t give you a silver bullet to make this work on your system with your hardware with all of your applications as I don’t have access to your system… (It would take me some thorough investigation too…)

:sob:

Yea sorry, i didn’t mean to sound harsh its just im banging my head against a wall of “i don’t understand” for the last week and im still nowhere really.

I did manage to get a relevant app to work (i think its working, not 100%sure). This is my system doing a sleep/wake cycle. I just need to try and run it while its failing which is no easy thing and then try and understand what its telling me, its pretty though.
https://i.imgur.com/prz6xgP.png

So can i just use /etc/sysctl.d/99-sysctl.conf ? Mine is empty atm so can i just append a load of switches/arguments (whatever they are called).

So if i just make it like this is it ok?

initcall_debug
no_console_suspend
ignore_loglevel

and then save it I don’t need to do an update-grub just reboot (i assume) and all these 3 arguments will be active? How will i test that they are actually active and ready to capture my next sleep failure as that could be days away and i dont want to miss it?

Heres the info on these 3 arguments:-

2.1 initcall_debug

Adding the initcall_debug boot option to the kernel cmdline will trace initcalls and the driver pm callbacks during boot, suspend, and resume. It is useful to check if any specified driver/component fails. Make sure to always enable it when debugging STI/STR/HTD related issues. In general, positive results mean the callback has no error/warning and returns 0 in a reasonable time. This is demonstrated in the following:

[ 76.201970] calling 0000:00:02.0+ @ 2298, parent: pci0000:00 [ 76.217006] call 0000:00:02.0+ returned 0 after 14677 usec

Negative results means the callback either contains some error/warning, or it takes an unreasonable long time to complete.

2.2 no_console_suspend

Adding the no_console_suspend boot option to the kernel cmdline disables suspending of consoles during suspend/hibernate. Once this option is added, debugging messages can reach various consoles while the rest of the system is being put to sleep. This may not work reliably with all consoles, but is known to work with serial and VGA consoles.

2.3 ignore_loglevel

Adding the ignore_loglevel boot option to the kernel cmdline prints all kernel messages to the console no matter what the current loglevel is, which is useful for debugging.

Yup

look at the different messages you’re getting during boot:

journalctl --system --boot=-1 | head --lines=25
journalctl --system --boot=0 | head --lines=25

The first command will give you the first 25 lines of the previous boot whereas the second command of the current boot. You should see the parameters applied.

As I said earlier:

:stuck_out_tongue_winking_eye: :crazy_face:

P.S. I think you should read this to have a laugh or 2:

because I can feel your pain…

:frowning_face:

Yea but its not just a case of sending it to sleep, i can do that all day long. Iv even got a bash script to sleep/wake on constant rotation on/off/on/off… no. Its a case of catching it when it decides that on a random particular sleep it’s going to fail and stay awake. It only does it on occasion, I can not force it i just have to wait for it to happen.

Yep very funny & interesting. I wish i had the time, iv been away from windows for 2.5 years now. I know quite a lot but my memory is not what it used to be and if i don’t use something for a good while i WILL forget it. I try to keep organized cherrytree notes of every problem iv had and how i fixed it in the end but its never enough.

1 Like

Iv been trying all night but i dont think this is working.

Iv put just initcall_debug into /etc/sysctl.d/99-sysctl.conf
so :-

❰greg❙~❱:heavy_check_mark:≻ cat /etc/sysctl.d/99-sysctl.conf
initcall_debug

But when i reboot i catch a glimpse of the red error that I found in the kernel logs that says :-

06/09/2020 00:59 systemd[1] Failed to start Apply Kernel Variables.

I looked at the head of this boot but i dont see anything, although i dont really know what im looking for.

Summary

❰greg❙~❱:heavy_check_mark:≻ journalctl --system --boot=0 | head --lines=25
– Logs begin at Tue 2020-01-21 11:10:14 GMT, end at Sun 2020-09-06 01:10:00 BST. –
Sep 06 00:59:39 greg-pc kernel: microcode: microcode updated early to revision 0xd6, date = 2020-04-27
Sep 06 00:59:39 greg-pc kernel: Linux version 5.4.60-2-MANJARO (builduser@LEGION) (gcc version 10.2.0 (GCC)) #1 SMP PREEMPT Sat Aug 22 14:35:41 UTC 2020
Sep 06 00:59:39 greg-pc kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-5.4-x86_64 root=UUID=c0628b7a-2f31-4e76-9eef-6dda7407ac6f rw
Sep 06 00:59:39 greg-pc kernel: KERNEL supported cpus:
Sep 06 00:59:39 greg-pc kernel: Intel GenuineIntel
Sep 06 00:59:39 greg-pc kernel: AMD AuthenticAMD
Sep 06 00:59:39 greg-pc kernel: Hygon HygonGenuine
Sep 06 00:59:39 greg-pc kernel: Centaur CentaurHauls
Sep 06 00:59:39 greg-pc kernel: zhaoxin Shanghai
Sep 06 00:59:39 greg-pc kernel: x86/fpu: Supporting XSAVE feature 0x001: ‘x87 floating point registers’
Sep 06 00:59:39 greg-pc kernel: x86/fpu: Supporting XSAVE feature 0x002: ‘SSE registers’
Sep 06 00:59:39 greg-pc kernel: x86/fpu: Supporting XSAVE feature 0x004: ‘AVX registers’
Sep 06 00:59:39 greg-pc kernel: x86/fpu: Supporting XSAVE feature 0x008: ‘MPX bounds registers’
Sep 06 00:59:39 greg-pc kernel: x86/fpu: Supporting XSAVE feature 0x010: ‘MPX CSR’
Sep 06 00:59:39 greg-pc kernel: x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256
Sep 06 00:59:39 greg-pc kernel: x86/fpu: xstate_offset[3]: 832, xstate_sizes[3]: 64
Sep 06 00:59:39 greg-pc kernel: x86/fpu: xstate_offset[4]: 896, xstate_sizes[4]: 64
Sep 06 00:59:39 greg-pc kernel: x86/fpu: Enabled xstate features 0x1f, context size is 960 bytes, using ‘compacted’ format.
Sep 06 00:59:39 greg-pc kernel: BIOS-provided physical RAM map:
Sep 06 00:59:39 greg-pc kernel: BIOS-e820: [mem 0x0000000000000000-0x000000000009c7ff] usable
Sep 06 00:59:39 greg-pc kernel: BIOS-e820: [mem 0x000000000009c800-0x000000000009ffff] reserved
Sep 06 00:59:39 greg-pc kernel: BIOS-e820: [mem 0x00000000000e0000-0x00000000000fffff] reserved
Sep 06 00:59:39 greg-pc kernel: BIOS-e820: [mem 0x0000000000100000-0x00000000852b8fff] usable
Sep 06 00:59:39 greg-pc kernel: BIOS-e820: [mem 0x00000000852b9000-0x00000000852b9fff] ACPI NVS

Is it working or is it not working, i have no idea:(
Iv searched everywhere and i can not see exactly where or how to use these arguments?

iv tried initcall_debug=1 (even though i have searched just about everywhere and nowhere do i see an “=1” in any examples or description) but lets try it anyhow.

ok iv rebooted, now how do i know if its working?

❰greg❙~❱:heavy_check_mark:≻ dmesg -s 128000 | grep “initcall”
dmesg: read kernel buffer failed: Operation not permitted
❰greg❙~❱✘≻ dmesg
dmesg: read kernel buffer failed: Operation not permitted
❰greg❙~❱✘≻

well thats great, lets try journalctl

❰greg❙~❱✘≻ journalctl --system --boot=0 | grep ‘initcall’
Sep 06 07:29:34 greg-pc systemd-sysctl[234]: Couldn’t write ‘1’ to ‘initcall_debug’, ignoring: No such file or directory

So it dont look like it is “initcall_debug=1” either?

Please help :sob:

I’m not familiar with these specific kernel parameters, but in my experience you need to turn on debugging options while compiling the kernel and that’s not a road you want to go down.

(I only ever did this once because I was still on Ubuntu and they’re not as good as Manjaro in providing newer kernels so I kind of had to if I wanted to use the AC portion of my WiFi as I bought a new router)

Release candidate 2 for the 5.9 kernel has been released, so you could try that, but that’s beta software and for something that’s happening every couple of weeks I wouldn’t go down that road…

I’m re-iterating what I said before:

If it happens, look at which piece of :poop: software that you run only intermittently is causing this (Keeping a game open would qualify)

:man_shrugging:

Iv finally managed to get the kernel options working but now i have another problem.

I want to do the stress test because its a very intermittent fault and i can’t reproduce it to order.

on the instruction site it says :-

2.11 rtcwake

rtcwake is a tool that can be used to enter a system sleep state (suspend/hibernate) until a specified wakeup time. And you can easily use it to perform suspend/hibernate stress tests. For example, you can use this simple script to run 1000 STR cycles easily

for i in $(seq 1000); do
    rtcwake –m mem –s 30
done

But when i create a shell script and run it it refuses to see the -s argument and throws an error:-

❰greg❙~/git/pm-graph(git≠master)❱✔≻ sudo ./rtcwake.sh 
rtcwake: must provide wake time (see --seconds, --time and --date options)
rtcwake: must provide wake time (see --seconds, --time and --date options)
rtcwake: must provide wake time (see --seconds, --time and --date options)
❰greg❙~/git/pm-graph(git≠master)❱✘≻ cat rtcwake.sh
#!/bin/bash
for i in $(seq 3); do
    rtcwake –m mem –s 30
done
❰greg❙~/git/pm-graph(git≠master)❱✔≻ 

but I can run sudo rtcwake –m mem –s 30 just fine in the terminal?

Check if the - is really a - and not some copy/pasted (which is a whole other character). Edit your bash script, and enter it manually via keyboard.

1 Like

You are a master :), yes it was exactly as you say. It looked exactly the same as a “-” but obviously was not. I never even knew such was possible and if it is/was why would instruction sites with “code sections” that are meant to be copy pasted even use them???! Are they trying to give people brain damage ^^

Right, onwards towards the next confusing headache but onwards nonetheless. :smile:

Would you mind posting the solution and then pressing the Solution button so that the next person that has the exact same problem you just had will benefit from your post as well as your question will now be in the “solved” status.

:innocent:

I did push “solution” on the other thread where i asked how to pass kernel options. However, this thread is asking how to get to the bottom of my suspend/sleep bug which i have not managed to do yet, im getting there very slowly, but not there just yet.

1 Like

I have managed to capture the suspend error whilst i had initcall_debug & no_console_suspend debugging switched on. I have a copy of the relevant dmesg and journalctl logs.

Could someone take a look for me, it’s gobbledygook to me but i suspect the answer is in there somewhere.


well, it’s taken over a month so far and i have only managed to narrow it down. The problem is definitely firefox. I have been using brave for the last month and it has been fine, as soon as i go back to firefox it starts failing to sleep again.
I have reset the firefox profile back to new. I reinstalled my addons, added my usercontent.css & userchrome.css back and its still doing it.
I have now got to test each and every addon & user script for weeks one at a time. Some of them i just can not live without for any time let alone a few weeks example uBlock, bitwarden, suppose i shall just leave them to last and hope its not one of them.

O there must be a better way :frowning:

1 Like

I’m sorry, but that’s the only way but once you’ve found the culprit, you’ll be able to file a bug request at the addon developer or ask your money back.

:grin:

1 Like

Well iv completed my testing of all my addons and its none of them. It’s still doing the same with a clean firefox. Its something to do with plasma & FF because without one of them running it works fine. There must be a way to figure what the problem is but its way over my head.

All i can do is to use another browser. Seriously a PITA.

Does starting firefox --safe-mode exhibit the same behaviour?

:thinking: