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.
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.
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
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.
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.
* * * * * 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.
If you prefer to share your thoughts on this post privately, just send me an e-mail!