Hardware

Spontane Neustarts beim Samsung Galaxy Tab S2

14. November 2020 · Hardware · andreas · 3 Kommentare

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.


Roccat Kone - die Zweite

17. April 2019 · Hardware · andreas · 2 Kommentare

Nachdem sich meine erste Roccat Kone nach rund vier Jahren verabschiedet hat, hat es jetzt nach 5 Jahren auch den Nachfolger “Roccat Kone XTD” erwischt.

Die Symptome sind die gleichen: normales Arbeiten ist nur noch eingeschränkt möglich, sporadische Doppelklicks und Aussetzer beim Drag & Drop machen selbst das Arbeiten mit einem Texteditor spannend.

Das war’s für mich mit Roccat. Mal schauen, ob Logitech Geräte baut, die länger halten …


Nexus 5X R.I.P.

09. März 2019 · Hardware · andreas · Kein Kommentar

Im August 2016 im Ausfverkauf erworben, hat sich mein Nexus 5X vorletzte Woche nach rund 2 1/2 Jahren außerplanmäßig verabschiedet. Auch bei mir hat der berüchtigte Mainboard-Fehler zugeschlagen, der wie ein Damoklesschwert über jedem der Geräte schwebt. Mitten während einer Photoaufnahme ist das Bild eingefroren, das Display wurde schwarz und das Telefon reagiert seither nicht mehr.

Wie bei den meisten von Murphy sorgfältig geplanten Aktionen ist dies natürlich nicht kurz nach der mehr oder minder regelmäßig durchgeführten Datensicherung am heimischen PC passiert, sondern mitten im Urlaub. Der Verlust des Telefons und der damit verbundenen Kommunikationsmöglichkeiten war ärgerlich aber nicht weiter tragisch - deutlich schwerer wiegt der Verlust von rund 200 Photos, welche im Laufe des Urlaubs gemacht wurden und noch im internen Speicher des Telefons liegen.

Es gibt zwar verschiedene Methoden, mit denen das Telefon mit Glück kurz zum Leben erweckt werden kann, aber bis zur Datenrettung hat leider keine geführt. Zwar konnte mit Hilfe der Kühlmethode das Telefon nochmal bis in den Fastboot-Modus gestartet werden, aber schon das installierte TWRP-Revovery war bereits nicht mehr erfolgreich zu starten. Mit Hilfe eines modifizierten Bootimages, das die Anzahl der benutzten Prozessorkerne reduziert, gelang einmalig der Start im Recovery-Modus - aber auch hier erfolgte nach wenigen Sekunden ein Neustart.


SanDisk Ultra Fit 16 GB - Finger weg ...

07. September 2018 · Hardware · andreas · Kein Kommentar

Der Stick ist klein und schnell - und wird leider im Betrieb so heiß, daß man ihn nach wenigen Minuten im USB-Slot nicht mehr länger als unbedingt nötig festhalten möchte.

Für die USB-Buchsen kann das jedenfalls auch nicht wirklich gut sein …


Nacharbeiten nach NVIDIA Treiber-Update

22. April 2018 · Hardware · andreas · Kein Kommentar

Auch wenn im Updateverlauf lediglich von “NVIDIA - Display” die Rede ist, so wird bei einer Aktualisierung des NVIDIA-Treibers mittels Windows-Update zwangsweise auch Kram mitinstalliert, dessen Installation nicht unbedingt gewollt sein muß:

Als erstes fällt der Ordner “3D Vision” im “Alle Programme”-Menü auf, eine Anwendung, welche man glücklicherweise über die Programm deinstallieren"-Funktion der Systemsteuerung wieder entfernen kann. Ein Klick auf “NVIDIA 3D Vision Treiber” und “Deinstallieren / ändern” auswählen und nach der Bestätigung, daß man den Treiber auch tatsächlich entfernen möchte, ist dieser Bereich wieder bereinigt.

Der Nächste Blick sollte in die “Dienste”-Übersicht der Systemsteuerung erfolgen, ob der “NVIDIA Telemetry Container"-Dienst installiert und aktiviert wurde. Ist dies der Fall, den Dienst über die Dienstverwaltung stoppen und deaktivieren. Beim Update auf Version 23.21.13.9135 wurde die Einstellung “Deaktiviert” beibehalten.

Je nach installierter Treiberversion wurde der NVIDIA Shadercache entweder aktiviert oder deaktiviert. Sofern der Cache aktiviert ist, werden Dateien in einem Unterverzeichnis im “TEMP-Ordner des aktuellen Benutzers (i.d.R. “C:\Benutzer\Benutzername\AppData\Local\Temp\NVIDIA Corporation\NV_Cache”) abgelegt. Die Funktion kann in der NVIDIA Systemsteuerung unter “3D Einstellungen” / “3D Einstellungen verwalten” / “Shadercache” konfiguriert werden.

Als letztes sollte der eingestelle Farbraum in der NVIDIA Systemsteuerung überprüft werden: hier muß unter “Auflösung ändern” / “Dynamischer Ausgabebereich” die Option “Voll” gewählt werden. Beim Update auf Version 23.21.13.9135 wurde die Einstellung “Voll” beibehalten.

Aktualisierungen:
2018-04-29: Hinweis auf Shadercache hinzugefügt.