Solved ACPI shutdown not working on AMD X399/Threadripper

I can't get ACPI to turn off the machine completely. Shutdown works up to the point where USB devices are detached, then instead of turning off, the machine just keeps going. I have to use the power button. Rebooting works correctly though.

I have tried the workaround suggested here: https://docs.freebsd.org/doc/6.1-RELEASE/usr/share/doc/handbook/acpi-debug.html#AEN17372
Setting hw.acpi.disable_on_poweroff="0" or "1" does not help.

The machine is an ASUS X399 Prime motherboard with a Threadripper processor. OS is 12.0-RELEASE, upgraded today.
I am suspecting an ACPI BIOS bug or something of the sort.

Here is the output of sysctl hw.acpi:
Code:
hw.acpi.cpu.cx_lowest: C1
hw.acpi.reset_video: 0
hw.acpi.handle_reboot: 1
hw.acpi.disable_on_reboot: 0
hw.acpi.verbose: 1
hw.acpi.s4bios: 0
hw.acpi.sleep_delay: 1
hw.acpi.suspend_state: S3
hw.acpi.standby_state: NONE
hw.acpi.lid_switch_state: NONE
hw.acpi.sleep_button_state: S3
hw.acpi.power_button_state: S5
hw.acpi.supported_sleep_state: S3 S4 S5

I upgraded the BIOS a couple of months ago, I have to check if they have updates.
Any ideas would be appreciated, thanks in advance.
 
I can't get ACPI to turn off the machine completely. Shutdown works up to the point where USB devices are detached, then instead of turning off, the machine just keeps going. I have to use the power button. Rebooting works correctly though.
What command are you using? On Linux you typically use shutdown -h now but on FreeBSD this will only shutdown, not power off. To have it power off you need to use shutdown -p now.
Keep in mind that's a manual from 6.1-RELEASE, that version has been EoL for 10 years. Lots of things have changed since then.
 
What command are you using? On Linux you typically use shutdown -h now but on FreeBSD this will only shutdown, not power off. To have it power off you need to use shutdown -p now.

Keep in mind that's a manual from 6.1-RELEASE, that version has been EoL for 10 years. Lots of things have changed since then.
Thanks for reminding me, I forgot to mention.
I use "poweroff" and "shutdown -p now". It should theoretically work, I doublechecked.

Regarding the old docu, I noticed the low version but I thought maybe nothing changed from back then. Otherwise Google should have shown me the newer info first.
 
Glad it worked!
I spent far too much time trying to find the actual root cause instead of a workaround, but to no avail. I can't find anything consistent between the Threadripper users affected by this issue and not, either.

cem was kind enough to submit my patch upstream, and imp merged it with some changes* here:
https://reviews.freebsd.org/D18506
I don't know if that means it'll land in 12.1 or only in 13-CURRENT. But it's in now.
If you want, it may be helpful to let cem know this patch worked for you here, since he was asking for feedback:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233998

(* I'm a little afraid as they changed my patch to default to enabled. I don't know if there are systems that work with ACPI shutdown but have issues with EFI shutdown or not. I guess we'll find out soon ^-^;; I also probably should have added EFI reboot as well, as there could easily be boards with bad ACPI reboot, too.)
 
Thanks for the patch, byuu! I am a Threadripper 1950/ASUS X399 prime user and the problem can be confirmed with this configuration.
Regarding the patch - it's nice that it's been accepted. There is no urgency, the kernel can be patched locally, so there's no rush.

I posted the feedback to the link mentioned by you.

(* Also I would prefer putting it to "off" by default. We don't want to influence all other hardware users, right? Maybe enabling it by default could be sensible in combination with a check for the specific buggy hardware. However, the maintainers should be knowing what they're doing, it's probably not too risky, because EFI should also work as a standard. At the end of the day, if my machine is off, I don't care if it went off via EFI or ACPI :)
 
Thank you very much! I figure it's good they know this helps some people, so that when the (inevitable?) future bugs due to EFI shutdown roll in, they won't completely revert the patch ^^;

I love that I'm using an OS where I can patch my own kernel issues, and when I tell others how to patch their kernels, they can do it too! :D

I figure it should be perfectly safe to shutdown via EFI instead of ACPI in any case. This happens well after FreeBSD has detached all storage, powered off all peripherals, and waited a while even after that. In the end, both are just extremely over-engineered and abstracted ways of executing a single outw(PM1a_CNT, SLP_TYPa | SLP_EN) write. Why not write an entire buggy virtual machine to do that, right? :p

In case others find this post: my configuration is a Threadripper 2950X + ASRock X399M.
I have tried upgrading the BIOS (even to the latest beta version), toggling every last option in the BIOS, disabling everything possible in the BIOS (though most hardware disable settings don't actually work), disabling every possible device and driver in FreeBSD (including all of *HCI/USB), removing and swapping out all other hardware in my build, disabling SMT and all extra CPU cores, compiling the kernel with ACPI debug and disabling every ACPI component that still allowed the machine to boot, flipping every sysctl I could possibly find on ACPI, and still nothing fixed the issue. As best I can tell, Intel's AML parser is calling AcpiOsSleep, which calls tsleep/pause("acpislp"), which waits for an interrupt after FreeBSD has already disabled interrupts. The BIOS debug LED says "05" while it waits, which is a shutdown code meaning "entering S5 state". (Lots of people online misinterpret this code by assuming it's a POST code when it's not.) You *could* just hold the power button in for a few seconds at that point, but what fun is that when you can learn about ACPI + EFI and hack your kernel instead? ^-^

Tangent: ShruggingAtlas' link got mangled very badly if you inspect the HTML for this post; it's escaping the anchor tag. Someone may want to file a bug with XenForo, as there may be an XSS exploit lurking there.
 
We all can touch different parts of the elephant and think it's a snake, hippo or whatever.
It might seem overengineered at some point, but I always try to keep in mind that standards are made for a wide variety of cases. There must be a reason for this VM to appear, it's just not obvious for us from our point of view. It might be some obscure gambling machine in some Vegas casino's corner for example. All kinds of weird hardware must be supported by the standard.

I find much more important incentivizing companies to adhere to the standard as it is defined. Buggy firmware should not be shipped, Windows is not the only OS in the world. In general, hardware should not make any assumptions about the OS running on it *period*. It's the software that stands on top of the hardware, not the other way around. However, if you take a look into the ACPI code dump, it's full of switch() statements with OS names, that's unacceptable.
 
Back
Top