Add support for _CR3 critical standby (S3) threshold.

[crahman_gmail.com]

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.

[danfe]

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.)

[crahman_gmail.com]

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?

[pauamma_gundo.com]

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

[crahman_gmail.com]

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.

[danfe]

@crahman_gmail.com wrote:

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).

[bcr]

OK from manpages.

[danfe]

Anything else which prevents this from hitting the tree? It's been cooking for almost three months already.

[danfe]

Adding some of our ACPI experts to give this a further kick.

[jhb]

I agree with hardcoding S3 here. We don't support S0x idle states yet.

My one concern about this is we currently don't enable suspend by default out of the box. (E.g. lid switch state defaults to no change still) There should definitely be a release note for this change.

[danfe]

@jhb wrote:

My one concern about this is we currently don't enable suspend by default out of the box. (E.g. lid switch state defaults to no change still)

That's true, we don't (and that's a good thing I've always enjoyed), but since this is rarely hit critical condition path it should be okay POLA-wise I think.

[crahman_gmail.com]

I do very much appreciate the thoughtful reviews. Thank you.

It's not clear what further actions I might take to get the code committed, however.

Any suggestions or advice would be helpful.