Spontane Neustarts beim Samsung Galaxy Tab S2

Das Samsung Galaxy Tab S2 ist auch 4 Jahre nach Erscheinen noch ein tolles Gerät: 9,7 Zoll Super-AMOLED-Display mit einer Auflösung von 2048 × 1536 Pixel, 3 GB Hauptspeicher und eine Qualcomm Snapdragon 652 als CPU - und das alles bei einem Gesamtgewicht von 389 g.

Leider hat die Tatsache, daß Samung mit dem Galaxy Tab S2 eines der leichtesten und dünnsten Tablets bauen wollte einen gravierenden Nachteil: mit zunehmendem Alter fängt das Tablet vor allem bei verminderter Akku-Ladung an, im laufenden Betrieb neu zu starten.

Das Problem scheint im Zusammenspiel zwischen Akku und CPU zu liegen und verschiedene Beiträge auf XDA (s.o.) berichten, daß die Geräte auch nach einer erfolgreichen Reparatur meist nach kurzer Zeit wieder ein ähnliches Fehlerbild zeigen.

Als brauchbarer Weg zur Verhinderung der Neustarts hat sich eine Limitierung der Taktfrequenz erwiesen: mit einer App wie SmartPack-Kernel Manager (Google Play) oder Kernel Adiutor (F-Droid) werden die CPU-Parameter so gesetzt, daß die “großen Kerne” nicht mehr bis höchstmöglichen Taktfrequenz von 1804800 getaktet werden, sondern bereits bei einem niedrigeren Wert Schluß ist.

Da zum Setzen der CPU-Frequenz zwangsweise root-Rechte erforderlich sind, kann mit Hilfe von Magisk auch komplett auf eine App verzichtet und stattdessen ein Boot Script im Verzeichnis “/data/adb/service.d” verwendet werden:

#!/system/bin/sh
# 2020-09-07 athul/initial

echo '4:1382400' > /sys/module/msm_performance/parameters/cpu_max_freq
echo '5:1382400' > /sys/module/msm_performance/parameters/cpu_max_freq
echo '6:1382400' > /sys/module/msm_performance/parameters/cpu_max_freq
echo '7:1382400' > /sys/module/msm_performance/parameters/cpu_max_freq

echo '1' > /sys/devices/system/cpu/cpu4/online
echo '1382400' > /sys/devices/system/cpu/cpu4/cpufreq/scaling_max_freq

echo '1' > /sys/devices/system/cpu/cpu5/online
echo '1382400' > /sys/devices/system/cpu/cpu5/cpufreq/scaling_max_freq

echo '1' > /sys/devices/system/cpu/cpu6/online
echo '1382400' > /sys/devices/system/cpu/cpu6/cpufreq/scaling_max_freq

echo '1' > /sys/devices/system/cpu/cpu7/online
echo '1382400' > /sys/devices/system/cpu/cpu7/cpufreq/scaling_max_freq

Der Erfolg kann (zu Testzwecken) ebenfalls mit Hilfe eines weiteren Skripts überprüft werden:

#!/system/bin/sh
# 2020-09-07 athul/initial

echo "available frequencies:"
cat /sys/devices/system/cpu/cpu4/cpufreq/scaling_available_frequencies

echo "scaling_max_freq:"
cat /sys/devices/system/cpu/cpu4/cpufreq/scaling_max_freq
cat /sys/devices/system/cpu/cpu5/cpufreq/scaling_max_freq
cat /sys/devices/system/cpu/cpu6/cpufreq/scaling_max_freq
cat /sys/devices/system/cpu/cpu7/cpufreq/scaling_max_freq

echo "cpu_max_freq"
cat /sys/module/msm_performance/parameters/cpu_max_freq

echo "scaling_available_governors"
cat /sys/devices/system/cpu/cpu4/cpufreq/scaling_available_governors

Das Skript zeigt, daß die gesetzten Werten übernommen wurden:

available frequencies:
400000 883200 940800 998400 1056000 1113600 1190400 1248000 1305600 1382400 1612800 1747200 1804800 
scaling_max_freq:
1382400
1382400
cpu_max_freq
0:4294967295 1:4294967295 2:4294967295 3:4294967295 4:1382400 5:1382400 6:1382400 7:1382400

scaling_available_governors
interactive ondemand userspace powersave performance

Sofern die Werte für einige Kerne nicht angzeigt werden, liegt dies daran, daß diese aktuell zwecks Strom sparen abgeschaltet sind.