Wattsolls
Super-Moderator & Beirat
Teammitglied
- 54.726
@Oronnun Hast Du vielleicht TT in der Version 5.4.9 benutzt? Alternativ sonst mal das hochladen mit Browser probieren. 
[ROM][5.1.1] CyanogenMod 12.1 Beta für das Gigaset QV1030
- 1.226 Antworten
- Letztes Antwortdatum
Bondar
Dauer-User
- 318
Nachdem mir die App LogCat aus dem Playstore nur Müll anzeigt, habe ich mich jetzt auch mal flott bzgl adb eingelesen.
Habe jetzt mal
in mein terminal unter linux gehauen und werde das Tablet mal über Nacht durchlaufen lassen.
Mal schauen, ob dabei etwas brauchbares bei rauskommt.
Habe jetzt mal
Code:
adb logcat -v long > logcat.txtMal schauen, ob dabei etwas brauchbares bei rauskommt.
AndHil1030
Neues Mitglied
- 0
Bondar schrieb:
Zeigt das Tablet bei Dir denn das Problem überhaupt wenn es am Strom / USB Port vom PC hängt ???
Bei mir tritt der Fehler immer nur dann auf wenn das Tablet autark, also ohne Strom im Standby ist ...
Bondar
Dauer-User
- 318
Am Ladegerät mehrmals. Ebenso ist es mir auch schon ohne aufladen passiert. Was ich noch nicht versucht habe, ist die konstante Verbindung über ein USB Kabel am Laptop. Laptop und Tablet laufen jetzt mal synchron durch, heute morgen gab es noch keine Tiefenentladung des Gigaset.
M
Michy
Neues Mitglied
- 1
Was ich seit diesem letzten ROM wieder habe sind freezes mitten beim Surfen, Maillesen, Tapatalk usw. Nur ein hartes Ausschalten hilft hier weiter.
Meistens habe dann unmittelbar nach dem Booten und dem Entsperren gleich wieder einen Freeze. Der zweite Start ist dann in der Regel wieder Ok.
Meistens habe dann unmittelbar nach dem Booten und dem Entsperren gleich wieder einen Freeze. Der zweite Start ist dann in der Regel wieder Ok.
M
mojo59
Neues Mitglied
- 0
Habe die neueste Version der ROM installiert und es läuft alles flüssig. Bis jetzt keine Entladen im Standby ...
Danke für die Weiterentwicklung und Pflege der ROM!
Danke für die Weiterentwicklung und Pflege der ROM!
NikolausKopernikus
Ambitioniertes Mitglied
- 29
Bei mir läuft die neue Version auch wieder Stabil…
PS: Wenn man ein logcat mitschneiden will kann man auch einen SSH Server aus dem Playstore installieren. Einfach mit Putty unter Windows/Linux per SSH auf dem Tablet einloggen und in den Optionen Logging aktivieren. Per "su" root anfordern und „logcat“ eingeben, et voilà wird alles aufgezeichnet.
SSH Server – Android-Apps auf Google Play
PS: Wenn man ein logcat mitschneiden will kann man auch einen SSH Server aus dem Playstore installieren. Einfach mit Putty unter Windows/Linux per SSH auf dem Tablet einloggen und in den Optionen Logging aktivieren. Per "su" root anfordern und „logcat“ eingeben, et voilà wird alles aufgezeichnet.
SSH Server – Android-Apps auf Google Play
AndHil1030
Neues Mitglied
- 0
Hab mir auf dem frischen Tablet mal "Logcat Recorder" aus dem AppStore installiert (Logcat Recorder - Android Apps on Google Play) ... danach ist das Tablet recht lange ganz normal in StandBy gegangen ... hab mich schon gefreut ... einfach einen Logger laufen lassen und das Problem ist gelöst ... aber am nächsten Morgen war das Tablet wieder mal warm und hat nicht reagiert ... na ja, diesmal wenigstens Logs ... leider nein ... der Logger hat, genau wie alles andere, einfach aufgehört zu arbeiten ... wie soll man einen Bug fixes der sich nicht greifen lässt ?? Gibt es denn HW Unterschiede bei den QV1030 ?? Es muss doch einen Grund geben warum bei einigen alles super-duper ist und bei anderen das Leben nicht so rosig ist ...
Zuletzt bearbeitet:
Spartaner25
Fortgeschrittenes Mitglied
- 823
- Themenstarter
- #1.089
Was meinst du mit "hat aufgehört zu arbeiten" ?
Eigentlich schreibt das Logcat Zeile für Zeile in eine Datei.
Wenn es daher abstürzt, müssten zumindest die letzten Zeilen geschrieben worden sein.
Und bezüglich der Hardwarerevisionen, kann ich dir nichts genaues sagen. Ich kenne bis jetzt nur das Modell fg6q mit dem macallan Board.
Was allerdings möglich wäre, ist eine Unterschiedliche Güte bei den CPUs, sprich einige können niedrige Spannungen und Takte besser ab als andere. Daher ist es im Bereich des möglichen, dass die Abstürze an der verhältnismäßig niedrigen Mindestfrequenz von 51MHz liegen. Wenn ihr wollt, könntet ihr dies mal mit dem Kerneladiutor hochregeln und sehen, ob das Problem besteht.
Eigentlich schreibt das Logcat Zeile für Zeile in eine Datei.
Wenn es daher abstürzt, müssten zumindest die letzten Zeilen geschrieben worden sein.
Und bezüglich der Hardwarerevisionen, kann ich dir nichts genaues sagen. Ich kenne bis jetzt nur das Modell fg6q mit dem macallan Board.
Was allerdings möglich wäre, ist eine Unterschiedliche Güte bei den CPUs, sprich einige können niedrige Spannungen und Takte besser ab als andere. Daher ist es im Bereich des möglichen, dass die Abstürze an der verhältnismäßig niedrigen Mindestfrequenz von 51MHz liegen. Wenn ihr wollt, könntet ihr dies mal mit dem Kerneladiutor hochregeln und sehen, ob das Problem besteht.
AndHil1030
Neues Mitglied
- 0
Spartaner25 schrieb:
Ich habe ja LogCat Recorder benutzt ... das schreibt im Minuten Intervall Logdateien auf die SD-Karten ... und für den fraglich Zeitraum gibt's halt keine Logs ... und in der letzten Datei steht nur die Grundinfo CPU% und RAM% keine anderen Meldungen ...
Bondar
Dauer-User
- 318
Ok, jetzt bin ich auch etwas verwirrt.
Mein Tablet lief jetzt drei Tage via USB und Terminal/LogCat an meinem Notebook. Ohne Absturz.
Entweder lag es an der App Folding@Home – Android-Apps auf Google Play welche ich mal deinstalliert habe.
Oder:
An meinem Ladegerät + Kabel, welches evtl. mehr Power in das Tablet jagt, als mein USB-Kabel am Notebook.
Tablet habe ich jetzt wieder mal an mein Ladegerät gesteckt, um zu sehen, ob sich das Teil jetzt wieder ausschaltet, damit ich die App mal ausschließen kann.
Kennt jemand noch eine Empfehlung, welche App direkt korrekt Logs erstellt, außer CatLog - Logcat Reader! – Android-Apps auf Google Play und via ADB/Terminal? So kann ich derzeit nur loggen, wenn mein Laptop mitläut, ohne das Netzteil.
Gruß
Mein Tablet lief jetzt drei Tage via USB und Terminal/LogCat an meinem Notebook. Ohne Absturz.
Entweder lag es an der App Folding@Home – Android-Apps auf Google Play welche ich mal deinstalliert habe.
Oder:
An meinem Ladegerät + Kabel, welches evtl. mehr Power in das Tablet jagt, als mein USB-Kabel am Notebook.
Tablet habe ich jetzt wieder mal an mein Ladegerät gesteckt, um zu sehen, ob sich das Teil jetzt wieder ausschaltet, damit ich die App mal ausschließen kann.
Kennt jemand noch eine Empfehlung, welche App direkt korrekt Logs erstellt, außer CatLog - Logcat Reader! – Android-Apps auf Google Play und via ADB/Terminal? So kann ich derzeit nur loggen, wenn mein Laptop mitläut, ohne das Netzteil.
Gruß
A
Android-N00b
Gast
@Spartaner25
Ist in der aktuellen Version von 2016 das Akkuproblem behoben? Scheint wohl ein echt schwierig zu lösendes Problem zu sein^^
Ist in der aktuellen Version von 2016 das Akkuproblem behoben? Scheint wohl ein echt schwierig zu lösendes Problem zu sein^^
freibooter
Dauer-User
- 2.213
Ich bin zwar nicht @Spartaner25, aber nein, ist es definitiv nicht. Der Stanby Freeze tritt weiter auf. Bei einigen öfter, bei anderen seltener. Bisher hat noch niemand die Ursache finden können.Android-N00b schrieb:
Spartaner25
Fortgeschrittenes Mitglied
- 823
- Themenstarter
- #1.094
Das schwierige ist, dass es anscheinend keinen gemeinsamen Nenner gibt. Anscheinend tritt das Problem mal weniger und mal öfter auf. Es passiert immer nach längerer Standbyzeit und ohne das irgendwelche Apps dafür verantwortlich dafür gemacht werden könnten.
Wenn ich das richtig verstanden hab, äußert sich das Problem darin, das irgendwann im Standby das Gerät "einfriert" sprich sich aufhängt, keine Eingabe mehr entgegen nimmt und dabei eine deutliche Wärmeentwicklung hat, was eben dazu führt, dass der Akku sich schnell leert.
Angenommen, es liegt nicht an Android, CyanogenMod oder an irgendwelchen Apps, da das wohl auch jemand anderem aufgefallen wäre. Außerdem nehme ich an, dass es nicht direkt an den Blobs vom Nvidia Note 7 liegt, da diese ja für Android 5.1 gedacht sind.
Dann bleiben drei mögliche Problem quellen:
1. Eine der HALs hieraus fährt sich irgendwann gegen die Wand. Die HALs selber sind für die Kamera, das GPS und die Sensoren (Die power.macallan.so habe ich gegen eine OSS Variante eingetauscht). Das ist eher unwahrscheinlich, da sie vorher kein solches Verhalten gezeigt haben, und eigentlich auch nicht in Benutzung sind.
2. Das Zusammenspiel der alten HALs mit den neuen ist fehlerhaft und/oder führt zu einem Crash. Bspw. die libnvmm_camer.so die (vermutlich) für das Memorymanagment der Kamera verantwortlich ist, muss irgendwie mit den anderen Libarys zusammen arbeiten, die ebenfalls für das Memorymanagment zuständig sind. Das ist möglich, aber dann würde das Problem nicht nur im Standby auftreten sondern eben auch bei der Benutzung der Kamera, oder auch im normalen Betrieb.
3. Der Kernel. Das wäre die "schlimmste" Möglichkeit, da das Debuggen hier nochmals schwerer wird. Ob und wann eine last_kmsg erstellt wird, scheint eher ein Glücksspiel zu sein und ein Reboot zuviel löscht sie aus dem Speicher. Und selbst mit der kmsg bleiben immer noch zig Zeilen Code, von denen ich zwar den Sourcecode habe, bei denen ich aber nicht sicher sagen kann, was vom Linux-Kernel, Nvidia, Google oder Quanta stammt. Aber ein problem mit dem kernel erscheint mir noch am wahrscheinlichsten, da dass am ehesten zu einem totalen Crash passt. Ich bin zwar im Moment dabei, den Kernel vom TegraNOTE 7 an unser Gigaset anzupassen, aber es ist eben auch nicht ausgeschlossen, dass ich eben eine kritische Anpassung von Quanta mit Übernehme und wir damit nichts gewonnen haben. Was auch für die Kernel-Theorie spricht ist, dass anscheinend kein anderes Tegra 4 Gerät solche Probleme mit Android 5 hat, obwohl die Blobs nicht all zu unterschiedlich sind.
Wenn ich das richtig verstanden hab, äußert sich das Problem darin, das irgendwann im Standby das Gerät "einfriert" sprich sich aufhängt, keine Eingabe mehr entgegen nimmt und dabei eine deutliche Wärmeentwicklung hat, was eben dazu führt, dass der Akku sich schnell leert.
Angenommen, es liegt nicht an Android, CyanogenMod oder an irgendwelchen Apps, da das wohl auch jemand anderem aufgefallen wäre. Außerdem nehme ich an, dass es nicht direkt an den Blobs vom Nvidia Note 7 liegt, da diese ja für Android 5.1 gedacht sind.
Dann bleiben drei mögliche Problem quellen:
1. Eine der HALs hieraus fährt sich irgendwann gegen die Wand. Die HALs selber sind für die Kamera, das GPS und die Sensoren (Die power.macallan.so habe ich gegen eine OSS Variante eingetauscht). Das ist eher unwahrscheinlich, da sie vorher kein solches Verhalten gezeigt haben, und eigentlich auch nicht in Benutzung sind.
2. Das Zusammenspiel der alten HALs mit den neuen ist fehlerhaft und/oder führt zu einem Crash. Bspw. die libnvmm_camer.so die (vermutlich) für das Memorymanagment der Kamera verantwortlich ist, muss irgendwie mit den anderen Libarys zusammen arbeiten, die ebenfalls für das Memorymanagment zuständig sind. Das ist möglich, aber dann würde das Problem nicht nur im Standby auftreten sondern eben auch bei der Benutzung der Kamera, oder auch im normalen Betrieb.
3. Der Kernel. Das wäre die "schlimmste" Möglichkeit, da das Debuggen hier nochmals schwerer wird. Ob und wann eine last_kmsg erstellt wird, scheint eher ein Glücksspiel zu sein und ein Reboot zuviel löscht sie aus dem Speicher. Und selbst mit der kmsg bleiben immer noch zig Zeilen Code, von denen ich zwar den Sourcecode habe, bei denen ich aber nicht sicher sagen kann, was vom Linux-Kernel, Nvidia, Google oder Quanta stammt. Aber ein problem mit dem kernel erscheint mir noch am wahrscheinlichsten, da dass am ehesten zu einem totalen Crash passt. Ich bin zwar im Moment dabei, den Kernel vom TegraNOTE 7 an unser Gigaset anzupassen, aber es ist eben auch nicht ausgeschlossen, dass ich eben eine kritische Anpassung von Quanta mit Übernehme und wir damit nichts gewonnen haben. Was auch für die Kernel-Theorie spricht ist, dass anscheinend kein anderes Tegra 4 Gerät solche Probleme mit Android 5 hat, obwohl die Blobs nicht all zu unterschiedlich sind.
A
Alec86
Neues Mitglied
- 8
@Spartaner25,
Hi, ich habe jetzt einige logs (5 Stuck) beim Absturz aufgezeichnet , vllt kannst du damit was anfangen. Was mir aufgefallen ist, ich habe im Standby radio laufen lassen, das radio lief bis zum Zeitpunkt wo ich das tablet aufwecken wollte recht gut, bis ich den power button gedrückt habe, dann kamm es zum freeze und der Bildschirm blieb schwarz.
Was auch merkwürdig ist , ist das die vom "Kernel Auditor/SetCPU" minimal gesetzte Frequenz keine Auswirkung hat im Standby, die Musik/Radio stockt immer noch. Obwohl mir SetCPU in der Statistik "Time in State" anzeigt dass die minimalen Frequenzen nicht genutzt werden. Was auch merkwurdig ist , ist sobald ich das Tablet am Ladekabel habe und dann radio im Standby laufen lasse, läuft es durchgehend ohne stottern.
Hi, ich habe jetzt einige logs (5 Stuck) beim Absturz aufgezeichnet , vllt kannst du damit was anfangen. Was mir aufgefallen ist, ich habe im Standby radio laufen lassen, das radio lief bis zum Zeitpunkt wo ich das tablet aufwecken wollte recht gut, bis ich den power button gedrückt habe, dann kamm es zum freeze und der Bildschirm blieb schwarz.
Was auch merkwürdig ist , ist das die vom "Kernel Auditor/SetCPU" minimal gesetzte Frequenz keine Auswirkung hat im Standby, die Musik/Radio stockt immer noch. Obwohl mir SetCPU in der Statistik "Time in State" anzeigt dass die minimalen Frequenzen nicht genutzt werden. Was auch merkwurdig ist , ist sobald ich das Tablet am Ladekabel habe und dann radio im Standby laufen lasse, läuft es durchgehend ohne stottern.
kriskros
Dauer-User
- 139
@Spartaner25
Ich wollte mich nur für deine enorme Arbeit bedanken! Wenn ich Ahnung davon hätte dann würde ich Dich unterstützen. Leider sind das Sachen die ich nicht einmal kenne! Es ist echt ein Glücksfall für mich/uns dass du so viel Zeit hierfür investierst! Vielen Dank dafür! Ich würde meinen Hut ziehen wenn ich einen auf hätte!
Ich wollte mich nur für deine enorme Arbeit bedanken! Wenn ich Ahnung davon hätte dann würde ich Dich unterstützen. Leider sind das Sachen die ich nicht einmal kenne! Es ist echt ein Glücksfall für mich/uns dass du so viel Zeit hierfür investierst! Vielen Dank dafür! Ich würde meinen Hut ziehen wenn ich einen auf hätte!
Spartaner25
Fortgeschrittenes Mitglied
- 823
- Themenstarter
- #1.097
@Alec86
Das dürften die ersten wirklich brauchbaren Logs zu dem Problem sein, danke dafür!
Wenn ich das richtig sehe, hast du die Logs aufgezeichnet, bis das System gecrasht ist?
Wäre es dir auch möglich mir dein tombstones zu schicken, da könnte noch zusätzlich was drin stehen.
Das Schema ist bei all deinen Logcats gleich, die Sensoren geben ihre üblichen Debuginfos raus, bis an einem Punkt folgende Nachricht erscheint:
Das führt dazu, dass der System-Server abschmiert und dabei so ziemlich alles an Services mit in die Tiefe reißt, die da sind. Daraufhin versucht das System wieder die Services zu starten, was anscheinend nicht gelingt, da sie sofort wieder abschmieren. Wenn sich das Muster so fortsetzen würde, könnte das auch gut erklären, warum das Gerät so warm wird.
Entweder ist es damit das offensichtliche und die erste Möglichkeit die ich auch vermutet habe, dass es eben an der veralteten SensorHAL liegt oder es ist was anderes, was mit der SensorHAL zusammenhängt.
Übrigens würde ich mich trotzdem über jedes Log freuen, auch wenn es "nur" den Verdacht bestätigt!
Das dürften die ersten wirklich brauchbaren Logs zu dem Problem sein, danke dafür!
Wenn ich das richtig sehe, hast du die Logs aufgezeichnet, bis das System gecrasht ist?
Wäre es dir auch möglich mir dein tombstones zu schicken, da könnte noch zusätzlich was drin stehen.
Das Schema ist bei all deinen Logcats gleich, die Sensoren geben ihre üblichen Debuginfos raus, bis an einem Punkt folgende Nachricht erscheint:
Code:
VALUE& android::KeyedVector<KEY, VALUE>::editValueFor(const KEY&) [with KEY = int; VALUE = sensors_event_t]: key not foundEntweder ist es damit das offensichtliche und die erste Möglichkeit die ich auch vermutet habe, dass es eben an der veralteten SensorHAL liegt oder es ist was anderes, was mit der SensorHAL zusammenhängt.
Übrigens würde ich mich trotzdem über jedes Log freuen, auch wenn es "nur" den Verdacht bestätigt!
A
Android-N00b
Gast
Spartaner25 schrieb:
Es wurde damals der Verdacht geäußert, dass es zwei verschiedene Hardware-Revisionen gibt. (Plastik vs. Metallrückseite) Womöglich unterscheidet sich die Hardware minimal, was bei manchen dann zu Problemen führt.
Ich habe von der Software leider keine Ahnung. Aber ich wollte das einfach mal "einwerfen".
tarjan
Dauer-User
- 372
@Spartaner25, werde mein Tablet jetzt mal 1-2 Tage im Standby laufen lassen. Mal schauen was dabei raus kommt.
@Android-N00b, siehe: Plastik oder Metall?.
@Android-N00b, siehe: Plastik oder Metall?.
A
Alec86
Neues Mitglied
- 8
@Spartaner25
ja die logs wurden bis zum crash aufgezeichnet. Die tombstones sind im anhang
ja die logs wurden bis zum crash aufgezeichnet. Die tombstones sind im anhang
Ähnliche Themen
satlink
