https://bugzilla.kernel.org/show_bug.cgi?id=221657
Artem S. Tashkinov ([email protected]) changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #3 from Artem S. Tashkinov ([email protected]) --- (In reply to Timothée Monney from comment #2) > (In reply to Artem S. Tashkinov from comment #1) > > This looks like a BIOS/HW issue. No way the Linux kernel can be responsible > > for your HW spontaneously deciding to power on itself. > > > > The latest BIOS is 7D32vHN, you could give it a try. > > I gave it a try but it didn't change anythings. > > Should I maybe go on others forum to report this ? Do you know which one > would be appropriate ? You could ask on: * https://hardforum.com/forums/motherboards.4/ * https://forums.anandtech.com/forums/motherboards.6/ * https://www.reddit.com/r/techsupport/ * https://www.reddit.com/r/pchelp/ Also here's what an LLM has to say: This could still be firmware, ACPI, or a hardware wake/power-button issue. If the machine reaches true S5/off, Linux should no longer be able to “decide” to power it back on. But Linux can influence the shutdown path and ACPI state, so a kernel/driver/firmware interaction could make the board reboot instead of entering S5 cleanly. What can cause a motherboard to turn itself on: ### 1. It is not actually reaching true S5/off This is the big one. `poweroff` asks the kernel/systemd/firmware to transition to ACPI soft-off. If ACPI shutdown fails or firmware interprets the final transition as reboot, it can look like “the board turns itself on.” The fact that: * `sudo halt` leaves a black screen * `poweroff` / `shutdown -h now` restart * physical button also restarts suggests the final ACPI power-state transition is broken or being overridden, not merely a userspace command problem. ### 2. Firmware wake sources On MSI boards, check **Settings → Advanced → Wake Up Event Setup**. MSI’s own Wake-on-LAN docs mention `ErP Ready` and `Resume By PCI-E/Networking Device` as relevant BIOS settings for allowing wake from off/sleep states. ([MSI][1]) Likely candidates: * **Resume by PCI-E / PCIe device** * **Resume by USB device** * **Wake by RTC alarm** * **Wake by PS/2 keyboard/mouse** * **Wake by onboard LAN / Intel NIC** * **Power on by keyboard/mouse** * **PME event wake** * **Thunderbolt/USB-C wake**, if present * **Wake from onboard Wi-Fi/Bluetooth module** Even with Wake-on-LAN “disabled” in the OS, firmware-level PCIe/PME wake may still exist. ### 3. Network adapter or PCIe PME wake The RTX 3090, NIC, Wi-Fi module, USB controllers, and PCI bridges can all be wake-capable devices. Linux exposes some ACPI wake sources under `/proc/acpi/wakeup`; Arch’s power-management docs note that wake triggers include things like power buttons, WOL, and device-triggered wake events, and that there is no single unified interface for every possible trigger. ([Arch Wiki][2]) Useful check: ```bash cat /proc/acpi/wakeup ``` Then temporarily disable suspicious enabled devices, for example: ```bash echo XHCI | sudo tee /proc/acpi/wakeup echo RP01 | sudo tee /proc/acpi/wakeup echo GLAN | sudo tee /proc/acpi/wakeup ``` Names vary by board. Also check NIC wake state: ```bash sudo ethtool eno1 | grep Wake-on sudo ethtool -s eno1 wol d ``` Replace `eno1` with the actual interface. ### 4. Front-panel power switch fault Your “short circuit” suspicion is reasonable. A flaky case power switch or front-panel header can absolutely cause immediate power-on. Best test: 1. Shut down. 2. Disconnect the case **PWR_SW** connector from the motherboard. 3. Start the machine by briefly shorting the two power-switch pins with a screwdriver. 4. Shut it down again. If it now stays off, the case switch/wiring is suspect. Also inspect: * front-panel header polarity/placement * reset switch accidentally on power pins * damaged case wiring * stuck physical button * motherboard standoff short * metal debris behind the board ### 5. PSU / standby rail weirdness ATX systems are never fully dead while connected to AC. The motherboard remains powered via **5VSB** and can respond to wake events. A bad PSU or unstable 5VSB rail can create strange power behavior, though I would rank this below firmware/wake-source/front-panel causes. Testing with another PSU is worthwhile if BIOS wake options and PWR_SW isolation do not explain it. ### 6. AC power restore behavior not actually applying They said they set AC loss behavior to “Power Off,” which is good, but I would still clear CMOS and re-set it. Firmware settings can get weird after BIOS updates. Try: * clear CMOS * load optimized defaults * disable all wake events * set AC restore to **Power Off** * enable ErP * save, power-cycle, retest ### 7. NVIDIA / kernel interaction during shutdown The NVIDIA driver probably cannot “wake” the board from true off, but it can contribute to a broken shutdown path: GPU driver unload, PCIe power management, runtime PM, or ACPI handoff could leave the platform in a bad transition state. Given they tested `nomodeset` and disabled `nvidia-powerd`, that weakens but does not eliminate the possibility. A good isolation test: ```bash sudo systemctl isolate rescue.target sudo modprobe -r nvidia_drm nvidia_modeset nvidia_uvm nvidia sudo poweroff ``` Or boot a live USB with no NVIDIA proprietary driver and test shutdown. ### 8. “Poweroff” vs “reboot” path confusion Try forcing systemd/kernel behavior: ```bash sudo systemctl poweroff --force --force ``` Also test from firmware/installer/live environment: * boot Ubuntu live USB * do not install NVIDIA driver * power off from live session * test whether it restarts If it restarts even from UEFI setup screen or a live USB, it is almost certainly firmware/hardware/wake-source rather than Ubuntu userspace. ### My ranking Most likely: 1. **Firmware wake source / PCIe PME / USB wake** 2. **ACPI S5 transition bug between kernel and BIOS** 3. **Front-panel power switch or wiring fault** 4. **PSU standby rail / electrical issue** 5. **NVIDIA driver interfering with shutdown path** So yes, your hardware suspicion is valid, especially the power button theory. But I would not rule out Linux entirely. The cleaner statement is: Linux probably cannot power it on from a true off state, but Linux/ACPI/driver behavior can prevent it from ever reaching that true off state. [1]: https://www.msi.com/support/technical_details/MB_Wake_On_LAN "How to set up Wake-On-Lan (WOL) - msi Motherboard" [2]: https://wiki.archlinux.org/title/Power_management/Wakeup_triggers "Power management/Wakeup triggers" -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug. _______________________________________________ acpi-bugzilla mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla
