Was it a soft reboot, or a power off/on?
I ran reboot from the command line, and it never came back up (no LEDs on, OKD style). Power remained connected throughout.
Hooking up a TTL to the serial and a power cycle showed the error.
I have seen some other recommendations to set the min freq to 600MHz or use performance (which I would prefer not to do just from trying to keep my always on infrastructure at the minimum necessary power usage).
Is there anyone else in this thread who has done the same and can report ideally a) an episode of OKD while already on the 600Mhz frequency
b) switching to 600MHz after having multiple OKD and not having any further OKD for quite some time?
(Maybe there are too many variables, given the multiple different installer versions, etc. but before I make the change on my routers, I'd love to hear whether this has been working for others.)
Thanks!
I also encountered the same problem last year. After adding the following code to rc.local, the reboot never encountered any problems again.
echo 812500> /sys/devices/system/cpu/cpufreq/policy0/scaling_min_freq
Not exactly what you're asking for, but my 3 E8450s are configured to use schedutil CPU scaling governor and it scales from min (437.5MHz) to max (1.35GHz) CPU freq.
So far it seems stable and able to warm reboot for the few times I needed them to.
1 Like
There was an error in these readings, see non-blurred response further below:
My Kill-A-Watt measures (when idle):
- 4.9 to 5.2 Watts when using
scaling_max_freq:1350000andscaling_governor:performance - 4.7 to 4.9 Watts when using
scaling_max_freq:600000andscaling_governor:schedutil
If this were a whole PC being used as a router, the power usage difference might matter, but in something like this it doesn't make a significant difference. It's better to run it at the recommended speed (1350000) and avoid the risk of a hung device on boot.
1 Like
How many watts on full load (i.e. running iPerf between 2 wireless clients or doing a full speedtest)?
Mine is very stable on 600Mhz min and ondemand governor.
1 Like
Confirming the changes took place:
cat /sys/devices/system/cpu/cpufreq/policy0/scaling_governor
ondemand
cat /sys/devices/system/cpu/cpufreq/policy0/scaling_min_freq
600000
reboot
The first reboot right after I changed the scaling_min_freq to 600000 didn't help as it didn't came back until I applied the refrigerator trick.
1 Like
Thanks for doing the measurements! I should have done it myself instead of speculating, but I also didn't want to unplug/reboot my router even though it seems I can recover it now without too much effort.
I decided to "start slow" and run my min freq at 600000.
echo 600000 > /sys/devices/system/cpu/cpufreq/policy0/scaling_min_freq
I think in addition to adding the line to rc.local, you need to run that command on the command line via SSH before the first reboot, so that the CPU frequency is already not running at the lower value on the first reboot before it gets far enough in the boot to set the setting from rc.local.
3 Likes
Correcting my idle results from above (I accidentally used scaling_max_freq instead of scaling_min_freq)
- 5.0 W with
scaling_min_freq:600000andscaling_governor:schedutil - 5.3 W with
scaling_min_freq:1350000andscaling_governor:performance
Speed test (Ethernet):
- 5.1 to 5.5 W with
scaling_min_freq:600000andscaling_governor:schedutil - 5.2 to 5.8 W with
scaling_min_freq:1350000andscaling_governor:performance
Speed test (WiFi):
- 4.8 to 9.3 W with
scaling_min_freq:600000andscaling_governor:schedutil - 5.1 to 9.5 W with
scaling_min_freq:1350000andscaling_governor:performance
So while it does make a tiny difference, the risk of not being able to boot on any power failure isn't worth it. If you really need to save 0.3 W somewhere, you'd be better off adjusting your thermostat or turning off extra lights in the house.
Also, take into account that at this level of power, some of these differences could be related to the sample rate of the Kill-A-Watt (screen updates once a second), or variations the measuring components having different temperatures, etc.
2 Likes
I have tried your solution and it also works. Maybe it's cooler friendy
echo schedutil > /sys/devices/system/cpu/cpufreq/policy0/scaling_governor
@el_charlie maybe you should value it.
thanks to both.
Greetings
2 Likes
Changing the subject, has anyone used this router to make mesh networks with batman or bmx6?
I was trying batman but I'm getting errors in luci web interface which I have posted here
Well, it reboots just fine with schedutil. I'll test it for few days. And yes, it should be a bit cooler because the CPU can go down to 437MHz instead of 600.
Although I read here that Mediatek recommends to run it at full speed (1.37GHz) in performance governor.
Thanks!
1 Like
Hello everyone, I have a Linksys e8450, and I tried all the configurations. Governor performance, Governor OnDemand with 600Mhz as a min and so. All this produce the OKD. In my case it happens with 2 reboots:
The first time the router will not reboot and no lights. just unplugging the power for 1hour and then plug it again and the router is up.
The second reboot it takes the serial cable to revive it.
Hope this will help the troubleshooting.
Thanks
1 Like
It is recommended to run at full MHz and use the performance governor as advised by Mediatek, as it makes almost no difference in power consumption and it helps to remove one possible cause of OKD.
If you are still seeing OKD when running at full speed, and are able to recover using the serial procedure, please post what installer version you used when doing the initial openwrt install. I posted a table with some installer build dates here.
If you have your OEM firmware backups since before you installed openwrt, one option might be to restore back to OEM firmware, then re-install openwrt using the 1.0.2 installer.
1 Like
Please provide a proper reference for your statement. I have not found any evidence that āMediatekā made any recommendations.
And see also:
1 Like
IMHO, it is really quite unlikely that a SoC has not been validated and tested to work correctly at all CPU frequencies before it is released to manufacturing. I donāt think Mediatekās QA is that bad.
My takeaway from the linked post is someone being told that MTKās software engineer only testing their builds on the max frequencies, thatās all. If switching CPU frequencies is problematic, it should not just affect reboot, it should, affect all aspects of the router and we will get crashes left right and center. I do not see this for all 3 of my E8450s happily scaling its CPU frequencies.
The way I see it, it is a win if less heat is being released into the environment to combat global warmingā¦ heh heh.
".... someone being told that MTKās software engineer only testing their builds on the max frequencies.." this someone works for MT.