[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Laptop resumes each 1h13 after suspend-to-ram



On 20/09/2025 01:10, Eugen Dedu wrote:
I tried removing S3 state from UEFI, but the laptop did not sleep anymore.  So I added it back in UEFI.

Sure. I think, Jeffrey disabled various PM states to prevent suspends. That is why I expect, you should have all of them enabled. For me, it surprising that changing S3 checkbox in UEFI is not reflected in /sys/power/mem_sleep some way.

Have you tried kernel from trixie-backports?

There *are* some ACPI errors (shown in red), during booting:
Sep 17 08:26:08 snoopy kernel: ACPI BIOS Error (bug): Failure creating named object [\_SB.PC00.XHCI.RHUB.HS03._> Sep 17 08:26:08 snoopy kernel: ACPI Error: AE_ALREADY_EXISTS, During name lookup/catalog (20240827/psobject-220) Sep 17 08:26:08 snoopy kernel: ACPI: Skipping parse of AML opcode: OpcodeName unavailable (0x0014) Sep 17 08:26:08 snoopy kernel: ACPI BIOS Error (bug): Failure creating named object [\_SB.PC00.XHCI.RHUB.HS03._> Sep 17 08:26:08 snoopy kernel: ACPI Error: AE_ALREADY_EXISTS, During name lookup/catalog (20240827/psobject-220)

You may hit "-S" and scroll to reveal whole log entries. Search engines would be more helpful then me to decide if specific ACPI errors are relevant.

On 19/09/2025 05:02, Max Nikulin wrote:
It seems, I failed to describe the test clear enough. Suspend the laptop using the sleep button, close the lid and leave for > 2.5 hours. If you are patient enough then you may open lid afterward and leave the laptop for another couple of hours (resume on lid open should be disabled). The question is whether closed lid may prevent wake ups.

So: I disabled sleep button from /etc/systemd/logind.conf:
   HandleLidSwitch=ignore
   #######HandleLidSwitch=suspend
   and restarted service:
   systemctl restart systemd-logind.service
   Now, closing lid does not suspend laptop.

I expect that UEFI (BIOS) setup should have something like "wake up on lid".

I get quickly the answer:
Press power button => suspend
After 10 secs, close lid
After 10 secs, open lid
=> laptop awakes.  So even if lid switch is ignored, when closing lid it does nothing indeed, but when opening lid it resumes the laptop!

Is this test enough?  Note that I cannot test the second part of your test, because when I open the lid the laptop awakes anyway.

Of course it awakes. You disabled another setting that prevents suspend on lid close while I suggested to disable resume on opening the lid.

My primary interest is whether you laptop may resume despite the lid is closed (when it is suspended by the sleep button). 10 seconds is not enough for this test.

Is 1h13m the interval since initial suspend? Or does first resume occur at certain wall clock time?

It is clock time (wall time), no matter when I suspend.

To avoid ambiguity, are you saying that first resume may happen e.g. half an hour after initial suspend and 1h13m is the period of following wake ups?

I would read the laptop manual that might be a source of inspiration. The setting might be behind some marketing title.

If our system administrator, who received the laptop, still has it...

Isn't it available at the manufacturer web site? My experience is that user guide (and service manual) may be more accurate than model description at reseller web sites.

In my case several lines has non null value in active_count, I put the output at https://dedu.fr/wakeup_sources.

I have no idea what is expected for suspend-to-idle since suspend-to-RAM works for me.

I am puzzled by rather high count in "i2c-VEN_0488:00 2322144" and by card reader events (mmc). I am in doubts if ucsi-source-psy-USBC000:001 related to a drive connected to USB-C, perhaps "lsusb -vt" may clarify it. Notice non-zero wakeup_count! Is wake on USB really disabled in UEFI? PNP entries might be for the lid sensor or for some platform timer (unsure). Boot log and search engines should help to decipher "serio0" and other entries.

Comparing counts before and after an "1h13" event may give some clue as well.


Reply to: