I just imaged OpenWrt SNAPSHOT, r28965-371cad4f28ff to the ikoolcore R2 Max which is an Intel N150 based system. Everything is working with the exception of rebooting. When I issue a reboot command, the machine seems to hang. The only way to rescue it is to pull the power cable. With a monitor connected, I see:
# reboot
...
ACPI: PM: Preparing to enter system sleep state S5
reboot: Restarting system
reboot: machine restart
Does that ACPI line imply the reboot command is trying to suspend the box?
My approach for a very quick and dirty debugging approach for this would be to install your favourite general purpose distribution on this device, and then to test how kernel v6.6 (same as OpenWrt is using right now), v6.12 (latest LTS, so the next kernel OpenWrt will likely move to) and (maybe) v6.13 behave on this box (bonus points if you try to get the kernel config of your test kernels close to OpenWrt's in step 2 of the test).
Why? Because it's easy to build and boot any (reasonably) recent kernel on -e.g.- Debian (insert your favourite general purpose distribution here), while it's much harder to do the same on OpenWrt. So if you can reproduce the issue with v6.6 on $DEBIAN, but see that it's fixed with v6.12, we know that it's 'just' an issue with a rather old kernel on relatively new'ish CPUs, not something about OpenWrt itself. If that's the case, there'd be two alternative options, doing nothing and just waiting for v6.12 to become the default in main or trying to bisect the issue on $DEBIAN, so you can find out which exact commit(s) fixed the problem between v6.6 and v6.12 with a prospect of trying to backport them to OpenWrt.
Another thing to check... make sure you aren't running any processes that may hang the restart process.
For example, I once had this problem with iPerf3 -- I can't remember exactly how I started it, but it would specifically stall the reset command until it was manually terminated (i.e. in a different session). It might have been launching it as a server rather than a daemon. But regardless, look at any processes you are running (beyond the default) as possible reasons for the inability to execute the reboot.
JFTR: No. S5 is not a state of suspension but the "soft off" state. If you look at the kernel commit logs, the use of S5 for reboot has a bit of a complicated history, what with having been introduced, reverted, and re-introduced because it may fail for some (very) select machines. Your BIOS may be one of those odd ones out.
I have it all disabled in the bios, s5, hibernate, and suspend but still it was buggy. Hopefully that grub modification solves it. Iām liking the box otherwise. 13 W with all 4 ports connected mostly idle. Cool running too.
EDIT: OK, modification to the grub kernel line was NOT needed. What did fix it (verified with 3 consecutive reboots now), was a BIOS option (Advanced>ACPI Settings>Enable ACPI Auto Configuration = Enabled) rather than manually disabling all the bullshit sleep stuff.
Only occurrence I had was when I modified rc.local erroneously so it kept running. I could ssh into the box just fine, but reboot and poweroff did nothing in the shell.