Unexpected shutdowns after upgrade to kernel 5.10.105

[EdgarMichie]

This is not about the maximum frequency, which is fine as it is, @LubOlimex. When the board overheats, it throttles somewhat. The thermal system manages the latter, while cpufreq handles the former; the two are essentially orthogonal.

[mossroy]

Does the latest kernel provided by Olimex (5.10.105-olimex #072307 SMP Wed Oct 12 07:24:41 UTC 2022) fix this stability issue?

I did not find anything related in the latest commits of https://github.com/OLIMEX/linux-olimex/commits/release-20220413-v5.10.105

[tayyabyounas]

@LubOlimex, the maximum frequency is good as it is; this is not about that. The board throttles a little bit when it gets too hot. The two are essentially orthogonal; the thermal system controls the latter and cpufreq controls the former.

[mossroy]

I see no related commit in your latest kernel branch https://github.com/OLIMEX/linux-olimex/commits/release-20230217-v5.10.105 

Again, the idea is not to switch to another governor or change maximum frequency, but to adjust temperature thresholds to avoid boards overheating and shutting down.

[teniie3]

Perhaps it stems from a change you made to the most recent image (other than the kernel) that wasn't made available for update in your apt repository? It's only a potential explanation that you may try to replicate.

[jch]

https://github.com/OLIMEX/linux-olimex/commit/06780cf8d37e200110f57b4ddcf393cdf5d84510

[mossroy]

https://github.com/OLIMEX/linux-olimex/commit/06780cf8d37e200110f57b4ddcf393cdf5d84510

I don't think this is new.

I found the same commit in the previous 5.10.105 branches: https://github.com/OLIMEX/linux-olimex/commit/91a2fe1f7b9991f9961e577cfbef560fd9c69fcc, and even in the previous 5.10.60 branches: https://github.com/OLIMEX/linux-olimex/commit/3d7e99cc2accf3dfe6465693ca691be3762a8ce2 or 5.8.x branches: https://github.com/OLIMEX/linux-olimex/commit/e84ac0994a07c7be319bb7afe2bdf420c4052bab and https://github.com/OLIMEX/linux-olimex/commit/cf242383ba098e8f571ac5d8f156c91b685e3542

So this commit will not solve this issue, as we already have it in our current kernel (and previous ones)