My computer suddenly won't shutdown or suspend anymore. Disks power down, but the computer won't. I have to shut down the computer by holding the power button.

The shutdown process ends with a "reboot: Power down" message, but nothing happens:

enter image description here

And it just stays like that. It used to work fine. The only thing I remember doing is running BootRepair a few days before because an update messed up booting. But I believe I may have shut down with no issues at some point after that.

Rebooting shows a similar message ("reboot: Restarting system") but after around 15 seconds, it does eventually reboot.

Things I have tried but made no difference:

  • Booting with previous kernels
  • Shutting down with sudo shutdown -P -h now, systemctl poweroff, sudo poweroff
  • Resetting BIOS (by removing the CR2032 battery)
  • Adding acpi=force, acpi=off, acpi=on, reboot=pci, reboot=bios, reboot=acpi to kernel params
  • Disabling USB 3.0 legacy mode in BIOS settings

I'm running:

  • Ubuntu MATE 18.04 with kernel 4.15.0-117
  • It's a desktop PC, so no TLP
  • Motherboard is ASUS P8H61-M LX3
  • Graphics card is ATI Radeon HD 4350/4550

EDIT: dmesg output: https://pastebin.com/gmA0RmEe Notice the

[    6.191250] ACPI Warning: SystemIO range 0x0000000000000428-0x000000000000042F conflicts with OpRegion 0x0000000000000400-0x000000000000047F (\PMIO) (20170831/utaddress-247)
[    6.191254] ACPI Warning: SystemIO range 0x0000000000000428-0x000000000000042F conflicts with OpRegion 0x0000000000000400-0x000000000000047F (\PMIO) (20170831/utaddress-247)
[    6.191257] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver
  • Rebooting gets stuck at "reboot: Restarting system", but after about 15 seconds it does actually reboot. That didn't use to happen though, it used to reboot immediately. I did run sudo update-grub. Actually, I mostly added the parameters directly in grub boot menu (pressing e). dmesg shows the same errors I posted above. Doesn't mention dw_i2c. pastebin.com/gmA0RmEe – gabrielfin Sep 19 '20 at 20:52
  • Also, since this is happening at the previous shutdown, the tail end of journalctl --boot=-1 might reveal something. – Frobozz Sep 19 '20 at 23:04
  • I'm going to try it in a little while (I'm unable right now) and I'll let you know. But if sudo poweroff is the same as systemctl poweroff, then no, it doesn't work. Here's the output of journalctl --boot=-1: pastebin.com/jEayHwpH I don't see anything interesting – gabrielfin Sep 20 '20 at 0:54
  • Ok, that was not very revealing. Looks like journaling stopped before our problem occurs. – Frobozz Sep 22 '20 at 19:00
  • 1
    I am back to CMOS. Did you short out the battery contacts for 5 seconds when you removed the battery? CMOS can live for hours on the residual charge on filter capacitors. Can you try Zeroing and then Factory Default one last time? – Frobozz Sep 22 '20 at 19:03

Editing /etc/default/grub:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash acpi=off"

and executing:

sudo update-grub

is known to eliminate these ACPI warnings in many cases. See https://unix.stackexchange.com/questions/97974/how-do-i-remove-acpi-warning-on-boot

However the ACPI Warnings are usually considered harmless. These might not be the cause of your hung shutdown.

BIOS reset:

Warning: resetting your motherboard configuration is an option of last resort - it may solve your problem, it may leave your system un-bootable! If your motherboard supports making a backup of your configuration, by all means do it before proceeding.

There are two methods of resetting the motherboard config and, in my experience, they can leave the motherboard with two different configurations

Built-in Factory Reset/Default: This will load into non-volatile memory a configuration the manufacturer figures will run, without modification, in the majority of circumstances. However, it does not necessarily zero out NVM which might leave you with bad data somewhere in CMOS.

CMOS zeroing: This method involves removing power from the motherboards non-volatile memory (historically CMOS) to zero it out. It will leave a default configuration but not necessarily the same one achieved above.


  1. Remove power from your system. (pull the plug!)
  2. Ground yourself to chassis to prevent static discharge damage.
  3. Open chassis
  4. Remove battery (CR2032 typically)
  5. Short out the battery contacts with a paper clip for 5 seconds.
  6. Replace battery (with new if there is any doubt...)
  7. Close chassis
  8. Apply power

IMPORTANT: CMOS memory can run on very little current. You must short out the battery contacts to discharge any residual charge or you will not zero CMOS memory effectively!

Typically, I will (testing between each attempt) Factory Reset, Zero CMOS, Factory Reset one last time. If the problem still exists, I look elsewhere.

  • Indeed, acpi=off did remove the warnings, but did not solve the issue – gabrielfin Sep 20 '20 at 19:52
  • Did @Raffles suggestion achieve a power-off shutdown? – Frobozz Sep 20 '20 at 22:18
  • No. Neither REISUB nor REISUO work at that stage. – gabrielfin Sep 22 '20 at 0:32
  • It was indeed CMOS. The first time I reset it I waited 5 minutes, but I didn't short the circuit. I don't know why resetting CMOS fixed it, since I didn't change any settings in setup... Anyway, thanks for the help! – gabrielfin Sep 26 '20 at 0:27
  • Glad to hear it. You are the second person having CMOS corruption I have talked to this week ... – Frobozz Sep 27 '20 at 16:50

If you are really stuck, hold down ALT+SysRq and type r e i s u s . This is not a solution to your problem but it is the best way to shut down the machine if all else fails.

  • At that stage, REISUB does nothing – gabrielfin Sep 20 '20 at 15:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.