[Diskussion] CyanogenMod 7 mit 2ndboot für das Milestone (CM7)

[fipsy]

und irgendwo wäre das Modul auch recht unbrauchbar, wenn man am system nichts ändern dürfte oder?

Wo du recht hast, ...

ob es am gov liegen könnte? müsste ich mal testen, derzeit hab ich conservative eingestellt

Ich habe auch conservative eingestellt und es funktioniert. Daran liegt es also nicht.

Der ursprüngliche Beitrag von 16:29 Uhr wurde um 16:36 Uhr ergänzt:

Nadlabak kann den Fehler nicht nachvollziehen also bist nur Du, als derjenige der es regelmäßig hat, in der Lage es für ihn nachvollziehbar zu beschreiben.

Ich bin nicht der einzige, der es regelmäßig hat. Ich beschreibe es hier ja seit Monaten immer wieder so detailliert wie möglich. Nachvollziehbarer als bisher kann ich es nun leider nicht beschreiben, weil ich den Kernel ja nicht debuggen kann und es keine Möglichkeit gibt, den genauen Start-Zeitpunkt des Drains festzustellen. Ich kann es erst nach 20-30 Minuten feststellen, wenn ich den Drain statistisch aufgrund des Akkuverlaufs dingfest machen kann. Ich denke, der Ball liegt nun auf der Entwicklerseite, indem z.B. eine technische Möglichkeit geschaffen wird, dem Fehler genauer auf die Spur zu kommen.

Auch wenn ich jetzt CPUStats benutze (danke, FuFu!), so werde ich allenfalls Unregelmäßigkeiten bzgl. des Deep Sleeps oder der Taktraten feststellen können. Mehr ist für einen Anwender nunmal nicht möglich. Die Ursache kann nur der Entwickler finden bzw. der Anwender, wenn der Entwickler ihm entsprechende Werkzeuge zur Verfügung stellt!

 

[Loader009]

Ne kleine Idee, wäre nen nandroid nicht bei der Fehlersuche hilfreich?

Ich teste hier bei mir noch was und kann dann mit nem nandroid probieren, den Fehler nachzuvollziehen. Vielmehr werde ich aber nicht machen können, da ich kein debugging etc. beherrsche.

Ein nandroid sollte immer mit der Fehler-/Problembeschreibung zusammen gepostet werden. Auch wenn es ein reupload ist, dann sollte man auf den Quellpost/ersten Post verweisen. Das verhindert Verwirrungen beim Tester und den Helfenden.

Ist lediglich ein Vorschlag, die meisten beachten meine Vorschläge ohnehin nur selten

 

[fipsy]

Aber wer postet denn ein nandroid Backup? Mit allen Passwörtern und hochsensiblen, persönlichen Daten? Die vorher alle zu köschen, wäre wohl extrem aufwändig...

By the way: CPU Stats hat gerade meine schon lange gehegte Annahme bestätigt: Der Drain wird dadurch verursacht, dass das Handy PERMANENT auf höchster Taktrate läuft - auch wenn es überhaupt nicht genutzt wird - und nicht mehr in den Deep Sleep geht. D.h. der Governor wird quasi unwirksam und das Handy läuft dauerhaft auf performance. Ich habe es eben verifiziert:

CPUStats vor 1 1/2 Stunden:

Deep sleep time: 0 days, 09:16:07
800 MHz (48) 0 days, 01:30:34
600 MHz (36) 0 days, 01:05:05
400 MHz (26) 0 days, 00:09:22
250 MHz (18) 0 days, 00:34:39
150 MHz (12) 0 days, 00:59:40

CPUStats jetzt:

Deep sleep time: 0 days, 09:16:07
800 MHz (48) 0 days, 02:54:55
600 MHz (36) 0 days, 01:05:05
400 MHz (26) 0 days, 00:09:22
250 MHz (18) 0 days, 00:34:39
150 MHz (12) 0 days, 00:59:40

Das Gerät hat in den letzten 1 1/2 Stunden nur ungenutzt mit ausgeschaltetem Display in der Ecke rumgelegen. Erst nach einem Reboot funktioniert der Governor wieder.

 

[Loader009]

Da hast du schon recht, allerdings kann es mögliche Problemquellen ausfindig machen, wenn man sich auch um ein annehmbares nandroid bemüht.

CPUStats werde ich mir auch mal ansehen müssen, hab schließlich nen drain beim CM9.

 

[fipsy]

Es würde mich gar nicht wundern, wenn bei CM9 die Ursache genau die selbe ist!

Der Knaller ist ja auch: Ich habe die Taktrate bei ausgeschaltetem Display auf 600 MHz gestellt. Trotzdem läuft das Gerät bei ausgeschaltetem Display dauerhaft auf 800 MHz weiter. Das kann ja wohl auch nicht normal sein. Die Frequency transitions bei CPUStats ändern sich dann auch nicht mehr. Das heißt doch, dass es überhaupt nicht mehr möglich ist, den Prozessortakt zu ändern. Also solch ein Fehler ist eigentlich so evident, dass es im Grunde keiner weiteren Beschreibung bedürfte. Im Grunde ist damit die möglichle Fehlerquelle ja schon relativ weit eingegrenzt. Zumindest für jemanden, der sich gut mit dem Kernel auskennt.

 

[TeCci]

Ist die Aufzeichnung der App denn vertrauenswuerdig?

Nur mal so am Rande, waere ja theoretisch auch eine Variable. Weiss nicht, ob oder wie man das ausschliessen koennte.

 

[Android Noob 007]

Hi!
ich hab mal ne Frage bin Neuling und check noch nicht richtig durch!
Nun meine Frage!

Ich habe gestern mein Samsung Galaxy Gio gerotet und bis jetzt hat alles super geklapt! Jetzt will ich Cm 7.2 draufspielen die Datei an sich ( 7.2 ) hab ich bereits gedownloadet! Das Problem alle Links zu den Gapps sind nicht aufrufbar ( Erorr 404 ..... ) hat jmd. einen Link der aufrufbar ist? Wär echt ne tolle hilfe!!
Lg Android Noob 007

 

[fipsy]

Ist die Aufzeichnung der App denn vertrauenswuerdig?

Ich nehme an, du meinst nicht vertrauenswürdig, sondern eher "zuverlässig", oder?

Die App holt sich die Daten aus den entsprechenden Statistik-Dateien, die der Kernel im System anlegt. Mehr geht ja nicht, denn tiefer kommt man an das System als Nutzer bzw. App-Entwickler wohl nicht ran.

Der ursprüngliche Beitrag von 20:56 Uhr wurde um 21:02 Uhr ergänzt:

ich hab mal ne Frage bin Neuling

Dann erstmal ganz herzlich Willkommen hier im Forum!!!

Das Problem alle Links zu den Gapps sind nicht aufrufbar ( Erorr 404 ..... ) hat jmd. einen Link der aufrufbar ist?

Die Google Apps dürfen aus lizenzrechtlichen Gründen nicht mitgeliefert werden, du musst sie manuell nachinstallieren und findest sie hier:

Goo.im Downloads - Browsing gapps

@-FuFu-: Änderst du den Link in deinem Beitrag entsprechend?

 

[Android Noob 007]

@ fipys
vielen dank sehr nett!!

 

[-FuFu-]

cpustats liest die werte direkt vom system aus, also die vom stats modul erzeugten werten, daher sollte es sehr genau sein...

aber warum er nicht mehr in den deepsleep geht kann viele ursachen haben, meisten ein hintergrundprozess, der es verhindert, oft der Media prozess

 

[fipsy]

aber warum er nicht mehr in den deepsleep geht kann viele ursachen haben, meisten ein hintergrundprozess, der es verhindert, oft der Media prozess

Nönö. Erstens: Dann würde der Prozessor nicht ständig auf 800 MHz getaktet! Denn die CPU-Auslastung liegt dauerhaft bei nur 1-2%!!! Da müsste der Governor ja wohl auf jeden Fall innerhalb 90 Minuten einmal runter takten! Alle Beobachtungen sprechen absolut gegen einen Hintergrundprozess und auch gegen einen Prozess, der das Gerät zu stark belastet. Das haben ja auch schon die Beobachtungen mit Battery Mix vor einigen Wochen nahe gelegt. Und auch die Tatsache, dass das Gerät absolut flüssig läuft, wenn es in diesen Zustand verfällt, deutet darauf hin, dass der Prozessor völlig unbelastet ist.

Zweitens: Mein unbenutztes Handy würde nicht mit gleicher Konfiguration und gleichen Hintergrundprozessen stets 2-3 Tage durchalten ohne JEMALS in diesen Fehler-Modus zu geraten!

Das passiert immer nur, wenn man über 10-20 Minuten hinweg bestimmte Apps benutzt. Ich habe mittlerweile 2 Apps identifiziert, die das zuverlässig verursachen. Eine davon die CeBIT-App. Beide nutzen Internet-Verbindungen. Ob es damit zusammenhängt, weiß ich nicht.

 

[nadlabak]

By the way: CPU Stats hat gerade meine schon lange gehegte Annahme bestätigt: Der Drain wird dadurch verursacht, dass das Handy PERMANENT auf höchster Taktrate läuft - auch wenn es überhaupt nicht genutzt wird - und nicht mehr in den Deep Sleep geht. D.h. der Governor wird quasi unwirksam und das Handy läuft dauerhaft auf performance. Ich habe es eben verifiziert:

CPUStats vor 1 1/2 Stunden:

Deep sleep time: 0 days, 09:16:07
800 MHz (48) 0 days, 01:30:34
600 MHz (36) 0 days, 01:05:05
400 MHz (26) 0 days, 00:09:22
250 MHz (18) 0 days, 00:34:39
150 MHz (12) 0 days, 00:59:40

CPUStats jetzt:

Deep sleep time: 0 days, 09:16:07
800 MHz (48) 0 days, 02:54:55
600 MHz (36) 0 days, 01:05:05
400 MHz (26) 0 days, 00:09:22
250 MHz (18) 0 days, 00:34:39
150 MHz (12) 0 days, 00:59:40

Das Gerät hat in den letzten 1 1/2 Stunden nur ungenutzt mit ausgeschaltetem Display in der Ecke rumgelegen. Erst nach einem Reboot funktioniert der Governor wieder.

You are using insanely low vsel values!
Your CPU must be running in error correction mode most of the time.
No wonder you are experiencing weird issues.

Fix your vsels.
See e.g. this table for inspiration: http://wiki.maemo.org/Overclocking#Voltage_Table

I also recommend to get rid of the 150MHz opp slot (anything below 250Mhz is actually not helping the battery at all).

 

[fipsy]

These vsel values have been approved for months. I have no spontaneus reboots and no problems with any apps. I can increase these values for testing if you like but I'm quite sure this will not change the problem.

Overclocking - maemo.org wiki

This page is quite hard to access (long waiting times)...

I found some reasonable vsel Values on OPPtimizer Projekt - Milestone Overclock for OMAP4 Devices - Droid Bionic Development - RootzWiki. They are shown in the yellow graph in the chart below. My values are in the blue graph. They do not differ so much.

The red graph shows the values marked as "ideal" on maemo.org. They are looking VERY curious! The physical dependency between the frequency and the voltage in a processor is nearly linear! So the red values seem inadequate to me below 500 MHz. Though above 500 MHz they do not differ from the values I use right now!?!

All this looks much crazy to me.

 

[nadlabak]

Please try to determine:
Is the 'cpufreq stuck at the highest frequency issue' specific to the conservative governor in use?
Are you able to reproduce it when the interactive gov is used?

And another dimension to the question:
Are you able to reproduce it when the CM7 stock vsel values are used?

The physical dependency between the frequency and the voltage in a processor is nearly linear!

Say linear again, I dare you, I double dare you, say linear one more time...
Say linear again, I dare you, I double dare you, say linear one more time...

 

[-FuFu-]

ich komm mit meinem stats problem nicht weiter -.-
neustarts helfen nicht -.- das modul ist geladen aber ich krieg nur nullen.... aber immerhin zeigt er mit die deepsleep zeit an...

ich werd wohl morgen nochmal die original 10overclock testen und eventuell nochmal ohne build.prop tweaks, vielleicht hilft das ja irgendwie...

und fibsy, wenn der Boss sagt, es ist so, dann ist es so ^^ also nehm mal andere vsel werte

 

[fipsy]

Please try to determine:
Is the 'cpufreq stuck at the highest frequency issue' specific to the conservative governor in use?
Are you able to reproduce it when the interactive gov is used?

Yes, I can reproduce the error on the interactive gov! It occurs on the conservative as well as on the interactive.

I will observe this. At the moment I'm running the phone with the values from the OPPtimizer Projekt (yellow graph), with a vsel not less than 30 and with 250 MHz as the lowest frequency. Until now the error didn't occur again. Tomorrow I can say more.

Say linear again, I dare you, I double dare you, say linear one more time...

Okay, okay. Nearly linear excluding extremely low or high frequencies - of course! Maybe the assumed linearity below 400 MHz may have been the problem. I will not give up before I found the exact reason .

 

[nadlabak]

fipsy: Why have you decided to use vsel values for completely different CPU family?
OPPtimizer project targets OMAP 4 family: 45nm technology CPUs with Cortex-A9 core.
Our OMAP3430: 65nm technology CPU with Cortex-A8 core.

 

[TeCci]

ich komm mit meinem stats problem nicht weiter -.-
neustarts helfen nicht -.- das modul ist geladen aber ich krieg nur nullen.... aber immerhin zeigt er mit die deepsleep zeit an...

ich werd wohl morgen nochmal die original 10overclock testen und eventuell nochmal ohne build.prop tweaks, vielleicht hilft das ja irgendwie...

und fibsy, wenn der Boss sagt, es ist so, dann ist es so ^^ also nehm mal andere vsel werte

Muss ich das alles ins Terminal eintickern, was auf dem Screen von fipsy eine Seite zuvor zu sehen ist oder gibts nen anderen Weg diese Werte zu sehen?

Denn guck ich nachher auch mal nach was bei mir raus kommt

 

[-FuFu-]

wenn du setcpu nutzt, gibt es da unter infos ein time in state abschnitt
ansonsten das app hier [APP] CPUStats - simple cpu statistics (updated 06.03.2011) - xda-developers
da sieht man auch den deepsleep anteil besser ^^

 

[TeCci]

Jo hab ich.

Okay, mir erschliesst sich zwar noch nicht, in welchem Format er mir das anzeigt, aber er tut da was. Sekuendlich aendern sich die Zahlen hinter 400Mhz und 600Mhz fast immer gleichzeitig, 800 auch ab und an obwohl ich nix im Hintergrund laufen habe und nur den Bildschirm anstarre :x

Was heisst die Zahl "165710" hinter 400Mhz? HHMMSS ists nicht, da bei den anderen Werten sonst Sekundenwerte ueber 60sek ausgespuckt wuerden


Oh ich seh grad, dass ich zwischen 14:20 und 17Uhr nen drain hatte. Dabei habe ich um 14:10 aufs Handy geschaut, Uhrzeitcheck und gucken ob wer geschrieben hat und direkt wieder den Bildschirm ausgemacht und weggelegt.
In dieser Zeit hatte ich eine CPU Auslastung von Nahezu 0% und der Akku macht nen schoenen Abflug.
Screen uppe ich gleich.

Vielleicht hilfts ja zur Fehlersuche, dass er bei mir jetzt praktisch durchs kurz aktivieren des Displays und nach 2 Sek wieder ausschalten ausgeloest wurde?


Noch etwas Interessantes: Scheinbar hatte ich um kurz vor 5 einen reboot, jedenfalls sieht man ja, dass kurz das Wlan weg war.
Ich tippe einfach mal drauf los und sage, dass ich da aus welchem Grund auch immer einen Modem-restart hatte - Ohne PIN-Eingabe nach dem reboot.

Hatte den Modem-Fehler leider schon mehrfach, aber zu 80% wenn ich jemanden anrufen wollte und der Gespraechspartner grade abgenommen hat und ich ihn 1-2 Sekunden hoeren konnte oder wenn ich angerufen wurde und den Anruf grade entgegengenommen hatte.

Ich weiss zumindest, dass ich zu 100% um 14:10 und um 16:55 das Telefon fuer wenige Sekunden zum Uhrzeitcheck angemacht habe, beide male NICHT den Lockscreen entsperrt habe.
Das einfache erwecken kann es aber nicht gewesen sein, dadurch ist das Wlan-Signal ja nicht fuer nen Moment weg .
Innerhalb dieser Zeit wurde das Handy weder bewegt noch beruehrt. Er lag einfach so da, ganz allein im Rucksack .