Reboot command in E8450 bacomes poweroff, not OKD problem

Installing and Using OpenWrt
1

Hello everyone,

I’ve encountered a strange issue with my E8450. That is, Whatever I use the "reboot" button in the LuCI interface, the "reboot" command in SSH, my E8450 always shuts down instead of rebooting. when I try or the "poweroff" command in SSH, it also shtus down. lol

In this situation, the only thing I can do is toggle the power switch on the back of the router to OFF and then back to ON. I know this sounds odd, but this is the case I’m facing...

Please allow me to describe my situation as simply as possible, and I’d appreciate it if anyone who knows the solution can share their insights. Thanks in advance! (If anything is unclear, feel free to ask, and I’ll provide the information you need.)

--In 2022, I flashed my E8450 to OpenWRT 22.03 (UBI) using this guide (huge thanks to dangowrt for the amazing invention that gave this router a new lease of life!):

--A few days ago, I upgraded my E8450’s OpenWRT system to the official version 23.03.5 from the OpenWRT website. The current version is:
OpenWrt 23.05.5 r24106-10cc5fcd00 / LuCI openwrt-23.05 branch git-24.264.56413-c7a3562

I used the official sysupgrade ROM for the upgrade:
https://firmware-selector.openwrt.org/?version=23.05.5&target=mediatek%2Fmt7622&id=linksys_e8450-ubi
This ROM is great and can be directly upgraded from the 22.03 LuCI interface without errors—no drama at all.

--Before the upgrade, I followed the official instructions to check for the "OpenWrt Kiss of Death (OKD)" issue. Luckily, my TF-A version is 2.4, which means it’s not at risk of triggering OKD. Here’s the official guide:
https://openwrt.org/toh/linksys/e8450

Here are the results of my OKD check:

OpenWrt 23.05.5, r24106-10cc5fcd00

root@OpenWrt:~# grep "(release)" /dev/mtd0ro
v2.4(release):OpenWrt v2021-05-08-d2c75b21-3 (mt7622-snand-1ddr)
v2.4(release):OpenWrt v2021-05-08-d2c75b21-3 (mt7622-snand-1ddr)
v2.4(release):OpenWrt v2021-05-08-d2c75b21-3 (mt7622-snand-1ddr)
v2.4(release):OpenWrt v2021-05-08-d2c75b21-3 (mt7622-snand-1ddr)

--To further confirm that my issue isn’t related to OKD, I conducted a crude test by unplugging the router’s power and plugging it back in after a few seconds. My E8450 was able to boot up normally, which suggests it’s indeed not in an OKD issue.

However, this "reboot become shutdown" problem is truly perplexing. Has anyone else experienced a similar issue? If you’ve encountered it and resolved it, I’d love to hear how. Thank you!

2

It is you only, Did you migrate configuration or re-entered it after reset when upgrading?

3

It's possible this could be related to operating voltages at the time of the intended restart. By any chance is your frequency governor set to something other than 'performance'? If so, it could be that the reboot causes it to lower operating frequency to a previously existing setting that is outside of the reliable range. The end result is that the warm reboot doesn't reset the operating speed and the DRAM fails to initialize properly, thereby effectively preventing boot.

1 Like
4

Yeah. I did change and install a lots of thing. while when I saw this issue. I have tried reset the system, and even at the fully new system I will face this situation. thank you anyway.

5

I din't know how to change the frequency governor thing. let me try to use back the original adapter. thanks for your advice.

6

Your situation is exactly like mine on my RT3200 since Openwrt 23.05.x and even on recent SNAPSHOTs.

In my case, as commented by @grauerfuchs , has to be with the operating frequency after the reboot that prevents a subsequent boot.

I solved changing the default governor to schedutil or performance, instead of leaving the default ondemand. You could also leave ondemand but raise the minimum CPU frequency to 600MHz instead of the default 437.5MHz.

To do this, go to Luci > System > Startup > Local Startup to edit the /etc/rc.local file (you can do it on SSH, too).

And add:

echo schedutil > /sys/devices/system/cpu/cpufreq/policy0/scaling_governor
or
echo performance > /sys/devices/system/cpu/cpufreq/policy0/scaling_governor
above the exit 0 line

In schedutil, the CPU could go down to 437.5MHz but quickly go to max speeds instead of trying to stay at that low speed and raising it when a process needs it in ondemand. They perform mostly the same, but ondemand tries to stay at the lowest speeds when possible. schedutil doesn't try to do that. The performance governor always keep the CPU at the max speed of 1.3GHz.

The factory default is the performance governor, but you can lower your temps a bit with schedutil or even ondemand if you don't face those reboot problems.

Another option would be lo leave ondemand but use 600MHz as the minimum frequency. Instead of the above, you can add this to the /etc/rc.local file:

echo 600000 > /sys/devices/system/cpu/cpufreq/policy0/scaling_min_freq

You might need to execute any of the commands in SSH before a reboot, for the changes to make effect.

Cheers!