AM3356: Freezing is refused

Hello Katsuyama-san,

Can you share the full log? Please include info on what commands you are using. Does the log show which tasks are not freezing?

Are you testing this on custom hardware or a TI EVM or Beagle Bone device? If you are using custom hardware, does it also occur on a TI EVM or beagle bone black?

Please be aware that tomorrow is a TI US holiday so please expect a delayed response.

Best Regards,

Anshu

Hi, Anshu-san,

I have attached the journal log (syslog_260612_not_Sleep.zip).
The refusing messages appear on lines 721, 944, and elsewhere.
The sleep command is as follows:
-----------------------------------------------------
cat /sys/power/wakeup_count > /sys/power/wakeup_count
echo suspend > /sys/power/state
-----------------------------------------------------
They are not seen in the log.

And you cannot see which tasks are not freezing in the log.
That test board is manufactured by our company.
This phenomenon does not occur on every board.
Therefore, I would like to understand the cause.

Best Regard
Katsuyama
syslog_260612_not_Sleep.zip

Hello Katsuyama-san,

Takeharu Katsuyama said:

This phenomenon does not occur on every board.

Under what conditions do you see this error?

Best Regards,

Anshu

Hi, Anshu-san,

We are currently investigating the situation.
Since the issue is occurring in the client's environment, we cannot
immediately identify the specific conditions involved.

It appears that this message is output by the `try_to_freeze_tasks()`
function in `power/process.c`, and I would like to know the conditions under
which this happens.

Best Regard
Katsuyama

Hello Katsuyama-san,

Please see the Linux SDK documentation: https://software-dl.ti.com/processor-sdk-linux/esd/AM335X/09_03_05_02/exports/docs/linux/Foundational_Components/Power_Management/pm_suspend_resume.html

For low power modes, see the commands they use.

echo suspend > /sys/power/state is not something we've tested.

Best Regards,

Anshu

Hi, Anshu-san,

echo suspend > /sys/power/state

We learned this method from your company as a way to prevent conflicts with wakeup events when transitioning to the suspend state.
So, we would like to retain this method.

Best Regard
Katsuyama