I happen to run on an ASRock Fatal1ty B450 Gaming-ITX/ac motherboard that used to run fine, but ever since I installed one UEFI update, it has had this one annoying issue: whenever you reboot, it gets stuck at POST. Cold boots work fine and the shutdown-and-push-the-power-button cycle also does the trick, but it’s not something I want to do all the time, especially when the machine is out of reach.

Before you say it: no, warranty service was not an option here, especially since this motherboard has suffered a fall once and it has this slight curvature in it. No, this separate incident was after this freezing issue started occurring.

Initial troubleshooting

I went through most of the standard hardware troubleshooting procedures:

  • clear CMOS
  • re-seat RAM
  • try a different CPU
  • disable features in UEFI, reduce PCIe speeds
  • disconnect storage devices

No luck, issue was still there. The POST code was stuck at A0. When taking a look at the ASRock Dr. Debug POST codes list, I saw that A0 falls under

Problem related to IDE or SATA devices. Please re-install IDE and SATA devices. If the problem still exists, please clear CMOS and try removing all SATA devices.

Since I had just done that procedure, and the issue was still there, I was stumped.

Wake-on-LAN

I had tried wake-on-LAN many years ago and was successful with it, so I thought that perhaps this could be an option. After all, I really did not want to get a new motherboard if I could just work around this issue.

I checked the ASRock UEFI for various wake-on-LAN related settings and found a couple of them. Oddly enough, the Wake on LAN setting itself only became available after I enabled booting from LAN in a completely unrelated UEFI section. In addition to the Wake on LAN setting, I also made sure to enable waking up from PS2 and PCIe devices, just in case.

After a quick Google search I found the Arch Linux Wiki page on this topic and saw that I needed to make sure that my network adapter was configured properly for wake-on-LAN to work.

[root@my-machine]# ethtool enp9s0 | grep Wake-on
	Supports Wake-on: pumbg
	Wake-on: g

Super, everything should work then!

I set up an always-on machine to send the wake-on-lan magic packets using wol every minute so that the machine eventually wakes up again. It’s configured, I shut down the problematic machine and wait.

Nothing happens.

Huh, perhaps I missed something.

No, everything was configured properly and the magic packet setting g was on by default.

I checked the wiki page again and two things caught my eye:

Note: Setting one of u, m or b along with g might also be necessary to enable the feature.

It is known that some motherboards are affected by a bug that can cause immediate or random wake-up after a shutdown whenever the BIOS WoL feature is enabled

Well, that’s interesting.

I added * * * * * ethtool -s enp9s0 wol pumbg to my crontab and shut my machine down.

Power supply does a click. Silence. Another click, ethernet port LED-s light up and my machine is powered on again. Success!

As it turns out, I did not even need to enable sending wake-on-LAN magic packets from another machine, the two motherboard issues managed to cancel each other out.

Comments

If you prefer to share your thoughts on this post privately, just send me an e-mail!