Unexplained hangs freezes and reboots with Archer c2600

Installing and Using OpenWrt
61

Hello,
I am quite lucky with these additional commands in /etc/rc.local:

echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor
echo 1200000 > /sys/devices/system/cpu/cpufreq/policy0/scaling_max_freq
echo 1200000 > /sys/devices/system/cpu/cpufreq/policy0/scaling_min_freq
echo 1 > /sys/devices/system/cpu/cpu0/cpuidle/state0/disable
echo 1 > /sys/devices/system/cpu/cpu0/cpuidle/state1/disable
echo 1 > /sys/devices/system/cpu/cpu1/cpuidle/state0/disable
echo 1 > /sys/devices/system/cpu/cpu1/cpuidle/state1/disable
2 Likes
62

I'm trying these settings, i've only adjusted scaling_min_freq to 800000 . Let's see how stable it is.

63

Hello.
I also have C2600 v1.1 with OpenWrt 19.07
On my case system work stabile when scaling_governor set to performance but my router got three times reboot after seven days.
Reboot was always when I try download big ISO file and on the same time I tried copy some file on LAN.

My max uptime was 83 day and currently 39 days.

I think this settings don't have sense.

performance - always set CPU clock to max and on this point at 1200MHz
Setting scaling_min_freq got sense only when scaling_governor is set to ondemand.

I think bellow settings should also be set to policy1 directory (I got this on OpenWrt 19.07)

echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo 1200000 > /sys/devices/system/cpu/cpufreq/policy0/scaling_max_freq
echo 1200000 > /sys/devices/system/cpu/cpufreq/policy0/scaling_min_freq

I think correctly should be (or other CPU frequency):

echo ondemand > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo ondemand > /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor
echo 1200000 > /sys/devices/system/cpu/cpufreq/policy0/scaling_max_freq
echo 800000 > /sys/devices/system/cpu/cpufreq/policy0/scaling_min_freq
echo 1200000 > /sys/devices/system/cpu/cpufreq/policy1/scaling_max_freq
echo 800000 > /sys/devices/system/cpu/cpufreq/policy1/scaling_min_freq
64

The settings avoid any switching between frequencies, that is intentional. It is a bit redundant, however without any side effects.

As mentioned, at least for my routers it is stable and reboots are not unscheduled:

echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo performance > /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor
echo 1200000 > /sys/devices/system/cpu/cpufreq/policy0/scaling_max_freq
echo 1200000 > /sys/devices/system/cpu/cpufreq/policy0/scaling_min_freq
echo 1 > /sys/devices/system/cpu/cpu0/cpuidle/state0/disable
echo 1 > /sys/devices/system/cpu/cpu0/cpuidle/state1/disable
echo 1 > /sys/devices/system/cpu/cpu1/cpuidle/state0/disable
echo 1 > /sys/devices/system/cpu/cpu1/cpuidle/state1/disable

The routers are consuming more energy by not clocking down. However, I prefer it to keep running without reboots. The maximum possible speed is also not used, as that might also trigger stability issues. 1.2GHz seems stable to what I can observe.

The ondemand scheduler always caused issues sooner or later.

65

I only use scaling_governor, my devices are at 345, 166 and 87 (it was powered down, not a reboot) days.
Use them as APs though, so there might be a difference, the one with the longest uptime, uses 19.07.3, the other two 19.07.6.

1 Like
66

Hmm, okay - I follow stable, so I am at 21.02.0 now. Perhaps a regression?

Update 03.12.2021: I followed to 21.01.1 and still the C2600 devices did not reboot unscheduled (so far?).

1 Like
67

Just bought a used C2600 v1.1 and I am on 21.02.1, don't see many posts about this version's behavior. Have everything on defaults ( scaling_min_freq at 600000, governor ondemand), let's see how it goes

2 Likes
68

I'm using the same combination, so far no issues to report:

Uptime	57d 22h 56m 42s

EDIT: Damn! ..unexpected power outage at 68days

EDIT2: 68 + 38 = 106days total, without any spontaneous reboots!

I have now moved on to 21.02.2, see how this performs

2 Likes
69

Strange indeed, but who knows what is causing it. Let's please update each other if unplanned reboots occur. For the interim I added the hints in the Wiki as well for others that might have issues and are looking for ideas on how to navigate around the issue.

1 Like
70

I'm currently at 20d with no reboots.

71

Running 21.02.5 and multiple reboots within minutes of installing.
Since no resolution, in desperation,
Tried the Ramon's suggestion meant for x86 following but still rebooting.

echo ondemand > /sys/devices/system/cpu/cpufreq/policy0/scaling_governor
echo ondemand > /sys/devices/system/cpu/cpufreq/policy1/scaling_governor
echo 800000 > /sys/devices/system/cpu/cpufreq/policy0/scaling_min_freq
echo 800000 > /sys/devices/system/cpu/cpufreq/policy1/scaling_min_freq
echo 25 > /sys/devices/system/cpu/cpufreq/ondemand/up_threshold
echo 10 > /sys/devices/system/cpu/cpufreq/ondemand/sampling_down_factor

echo 800000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
echo 800000 > /sys/devices/system/cpu/cpu1/cpufreq/scaling_min_freq

Nothing in system log.

Running 21 releases since I use BanIP.

EDIT: Time permitting, will revert to 21.02.4 to compare.

72

Iirc, release 21 has packet scheduler issues beyond 21.02.1 ... after that other algorithms than round robin were tried, to mixed results and this stuttering (while still operating) may be that.

Also the reboots are probably centered around krait (cpu) clocking and vlan stats gathering in the kernel.

Much work has gone into those areas for 22.03 which was not back-ported to v21.

If possible, strongly suggest you try the latest v22 release or even a snapshot.

EDIT saw that you're stuck at v21 - you might just go back to 21.02.1, set min, max cpu clock rate to 1.2ghz (fixed @ that rate).

And if you're using ath10-ct firmware, kmod ... switch to non-ct, and vice versa.

Mmmv,
M.

1 Like
73

Thanks Mpilon

dibdot is making headway on BanIP, so hopefully, I can start using current releases.

1 Like