How I fixed one hardware issue with another one
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.