Bug 238392 - System does not power off
Summary: System does not power off
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 12.0-RELEASE
Hardware: amd64 Any
: --- Affects Only Me
Assignee: freebsd-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-06-07 14:49 UTC by Matthew Woehlke
Modified: 2019-06-07 17:53 UTC (History)
0 users

See Also:


Attachments
Output of `dmesg` (system was booted with "verbose" enabled) (92.87 KB, text/plain)
2019-06-07 14:51 UTC, Matthew Woehlke
no flags Details
Output of `acpidump -dt | xz -c` (60.27 KB, application/x-xz)
2019-06-07 14:52 UTC, Matthew Woehlke
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Matthew Woehlke 2019-06-07 14:49:47 UTC
Shutting down the system (`poweroff` or `shutdown -p now`) does not turn off the machine; it is necessary to hold the power button until the BIOS cuts power. Rebooting works.

CPU: AMD Ryzen Threadripper 1920X
Motherboard: Gigabyte X399 Aorus Pro
BIOS: ID=8A07BG04, Version=F1, Date=2018-10-01
Kernel: 12.0-RELEASE r341666 GENERIC

Output of `dmesg`, `sysctl hw.acpi` and `acpidump -dt | xz` will follow. Please let me know what other information I can provide or what experiments I can try.

Linux (Fedora 29) is able to power off the system, so presumably it is not a hardware problem as such, but likely some ACPI quirk that Linux knows about and FreeBSD doesn't.

Possibly related: #132602, #149371
Comment 1 Matthew Woehlke 2019-06-07 14:51:07 UTC
Here is the output of `sysctl hw.acpi`:

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
Comment 2 Matthew Woehlke 2019-06-07 14:51:46 UTC
Created attachment 204882 [details]
Output of `dmesg` (system was booted with "verbose" enabled)
Comment 3 Matthew Woehlke 2019-06-07 14:52:24 UTC
Created attachment 204883 [details]
Output of `acpidump -dt | xz -c`
Comment 4 Conrad Meyer freebsd_committer freebsd_triage 2019-06-07 16:48:04 UTC
FWIW, I don't seem to have the same problem with a similar CPU and chipset (different exact CPU, different board manufacturer):

AMD 1950X
ASRock X399 Taichi
BIOS 3.30 (I think); 2018-08-21
Kernel: 13-CURRENT

My `sysctl hw.acpi` is identical to yours, except that my hw.acpi.verbose=0.

I don't have a verbose boot handy, so I don't have much to say about dmesg.

I'm looking at a diff between my 'acpidump -dt' and yours.

In FACP, our reset reg and value seem to match; my Flags= is mostly identical but also has "APIC_PHYSICAL."

You're missing SRAT and SLIT tables entirely (do you have NUMA disabled in BIOS?).

But nothing really jumps out at me from the acpidump diff — I'm no ACPI expert.
Comment 5 Matthew Woehlke 2019-06-07 17:53:06 UTC
Hi, Conrad!

Since you have a different motherboard manufacturer, I suspect you also have a very different BIOS (at minimum, "3.30" is clearly a very different versioning scheme than "F1"), and I'd guess my problem is BIOS-related.

> You're missing SRAT and SLIT tables entirely (do you have NUMA disabled in BIOS?)

If there's a setting for that, I sure can't find it. Besides, I didn't think that applied to single-socket systems? (Were you thinking of something else?)

I'm very much *not* an ACPI expert... the extent of my knowledge is roughly "something to do with power management" and "probably the culprit if the system won't sleep/reboot/poweroff". (Is there any way to tell what Linux is doing different from FBSD without being an expert in the kernel code of both?)