Page MenuHomeFreeBSD

Add support for _CR3 critical standby (S3) threshold.
Needs ReviewPublic

Authored by crahman_gmail.com on Fri, Jul 29, 5:51 AM.

Details

Reviewers
None
Group Reviewers
manpages
Summary

Along with _PSV, _HOT, and _CRT, ACPI supports the _CR3 threshold which specifies a
temperature above which a system should transition to the S3 standby state.

On FreeBSD, this is more useful than _HOT, which specifies the S4 transition
threshold temperature (since FreeBSD does not generally support the S4 state), or, in
many cases, _CRT, since after transitioning to S3 the system can cool and then be
resumed.

Test Plan

Stop the cooling fans, run a cpu-intensive job, and/or set _CR3 to a low
temperature. The system will enter standby, cool down, and can be resumed in the usual
fashion.

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint OK
Unit
No Unit Test Coverage
Build Status
Buildable 46669
Build 43558: arc lint + arc unit

Event Timeline

That looks quite useful, STR (S3) makes a lot more sense, esp. contrary to unsupported S4.

sys/dev/acpica/acpi_thermal.c
628

Is it right to hardcode ACPI_STATE_S3 here? Should it rather uphold user's hw.acpi.suspend_state setting? (Which defaults to S3.)

This is a good question. According to the specification, we should use S3 unless the FADT LOW_POWER_S0_IDLE_CAPABLE flag is set. If the flag is set, we can use 'an equivalent low power state'. The flag indicates that 'S0 idle achieves savings similar to or better than those typically achieved in S3'.

Rather than using hw.acpi.suspend_state, or hw.acpi.standby_state, perhaps the thing to do is to check the flag, and if it's set use the highest available sleep state; otherwise using S3?

Manual page English LGTM, but holding back until someone approves the design and implementation.

I've given this a little more thought. I don't think it's appropriate to use hw.acpi.suspend_state (or hw.acpi.standby_state) in this case.

The issue is that we're not trying to suspend to a user's preferred state. In general, the manufacturer who has enabled and picked a CR3 threshold temperature has done so after confirming it is safe to transition to that state to prevent further overheating. While there may be users who would set hw.acpi.suspend_state knowing it would affect thermal management, in most cases this will not be true. In other words, I think it would create a problem.

I do think it would be appropriate to detect the FADT LOW_POWER_S0_IDLE_CAPABLE flag and shutdown to a higher state if it's set, but I will not do it now. If anyone is interested and asks, and is willing to test the code, I'll be happy to implement it. But I don't personally have any systems that can do this and I don't want to put out untested code related to something critical to thermal management.

According to the specification, we should use S3 unless the FADT LOW_POWER_S0_IDLE_CAPABLE flag is set. [...] While there may be users who would set hw.acpi.suspend_state knowing it would affect thermal management, in most cases this will not be true. In other words, I think it would create a problem.

Fair enough, I agree that S3 specified by the spec makes sense here (neglecting the S0 idle capability flag corner case).