Bug-Suche: System-Konfiguration - Board Revision

[TzGuf]

Hmmm. Hört sich interessant an, hast du mal einen link ?

Gesendet von meinem GT-I9001 mit der Android-Hilfe.de App

Kann mich auch irren, beim Nexus 4 weiß ichs aber sicher, dass es eine Klasseneinteilung gibt. Da die verwendeten Bauteile gerade bei der Größe ziemlich streuen werden dort die CPUs in die 4 Klassen eingeteilt.

Gerade nochmal geschaut - die Klasseneinteilung gibts doch nur beim APQ8064-Chipsatz. Sorry falls es da Verwirrung gegeben hat.

 

[XeLLaR]

Kann mich auch irren, beim Nexus 4 weiß ichs aber sicher, dass es eine Klasseneinteilung gibt. Da die verwendeten Bauteile gerade bei der Größe ziemlich streuen werden dort die CPUs in die 4 Klassen eingeteilt.

Gerade nochmal geschaut - die Klasseneinteilung gibts doch nur beim APQ8064-Chipsatz. Sorry falls es da Verwirrung gegeben hat.

Ah ok macht nichts

Gesendet von meinem GT-I9001 mit der Android-Hilfe.de App

 

[Muhtant]

ROM: CM 10 beta 1
Kernel: Phenom Kernel V1.2.8 UV
H/W-Revision: 6
Recovery: CWM 5.5.0.4
Bugs: Läuft bislang ohne Probleme

1.2.8 exUV folgt..

 

[pultuke]

Hallo zusammen,

habe die JB- Infos mal alle in die angekündigte Tabelle zusammengeführt;

siehe

https://www.android-hilfe.de/forum/...nelpaarungen-auf-sgs.372668.html#post-5329727

 

[XeLLaR]

Es gibt einfach zu viele variablen.

Board Revision 0x06 und CPU Revision 0x02. Cm10. Keine bugs außer die angegeben von ivendor

Gesendet von meinem GT-I9001 mit der Android-Hilfe.de App

 

[Rhonin]

Es gibt einfach zu viele variablen.

Board Revision 0x06 und CPU Revision 0x02. Cm10. Keine bugs außer die angegeben von ivendor

Gesendet von meinem GT-I9001 mit der Android-Hilfe.de App

Da hast Du recht - und genau das ist das Problem - wie sich auch schon jetzt zeigt, scheinen die unterschiedlichen Board Revisions nicht unbedingt etwas mit den auftauchenden Problemen zu haben - ich weiß nicht mehr wer es sagte Chritopher83 oder Xistance - ab Revision 6 scheinen die Boards wohl ausgereifter zu sein, so dass sich die Problematiken nicht mehr wirklich auf die Board-Revision zurückführen lassen.

Schade eigentlich , aber mitllerweile sind die Jungs drüben ja trotzdem richtig weit gekommen wenn man mal ein WE nicht dabei war....

Allen noch einen schönen Winteranfang

Gruß

Rhonin

 

[pultuke]

@Rhonin und Xellar:
außerdem kann man in Fortführung Deines Kommentars (board-rev 6 ausgereifter) und auch an der Tabelle sehen, dass die board rev. 7 wiederum noch besser als 6 ist ( oder ist das sowieso klar ?)- jedenfalls kann man jetzt besser beurteilen, ob ein SGS+ eher Fehler produziert, weil es eine alte board-rev. hat oder der Fehler vor dem Display sitzt. (Wenn man alles richtig gemacht hat beim Flashen)

Gesendet von meinem GT-I9001 mit der Android-Hilfe.de App

 

[XeLLaR]

Also, Board revision hin oder her, am liebsten hätte ich die Selbe board revision wie Ivendor, da er auf seinem handy die anpassungen der rom vornimmt und testet. Nur leider wissen wir nicht, welche er hat. Allerdings kann man hoffen das er auch auf 0x06 läuft, da das die am meisten verbreitete ist.

Naja..wenn wir diese liste fortsetzen wollen, müssen wir EINEN user mit Verschiedenen Revisionen ausstatten, da jeder eine andere vorstellung von Bugs hat, und jeder anderes userverhalten, einstellunge, Mods und Apps hat.
So wie das jetzt läuft ist alles chaos.

Aber die idee ist gut, das muss ich sagen.

Edit: Hier mal eine liste an variablen:

-Board Revision
-CPU Revision
-Kernel
-ROM
-OC (OverClock, wenn ja welche Frequenz?)
-UV (UnderVolt, wenn ja Welches UV Table?)
-User (Benutzerverhalten)
-Einstellungen (Governor, I/O Sheduler & etc)
-Mods
-Apps
-Systemapps gelöscht(Wenn ja, welche?)


Wer hat schon lust/zeit, das alles aufzuschreiben..

 

[Rhonin]

Also, Board revision hin oder her, am liebsten hätte ich die Selbe board revision wie Ivendor, da er auf seinem handy die anpassungen der rom vornimmt und testet. Nur leider wissen wir nicht, welche er hat. Allerdings kann man hoffen das er auch auf 0x06 läuft, da das die am meisten verbreitete ist.

Naja..wenn wir diese liste fortsetzen wollen, müssen wir EINEN user mit Verschiedenen Revisionen ausstatten, da jeder eine andere vorstellung von Bugs hat, und jeder anderes userverhalten, einstellunge, Mods und Apps hat.
So wie das jetzt läuft ist alles chaos.

Aber die idee ist gut, das muss ich sagen.

Edit: Hier mal eine liste an variablen:

-Board Revision
-CPU Revision
-Kernel
-ROM
-OC (OverClock, wenn ja welche Frequenz?)
-UV (UnderVolt, wenn ja Welches UV Table?)
-User (Benutzerverhalten)
-Einstellungen (Governor, I/O Sheduler & etc)
-Mods
-Apps
-Systemapps gelöscht(Wenn ja, welche?)


Wer hat schon lust/zeit, das alles aufzuschreiben..

Sehr gut das mit den Parametern Ich sehe ein, dass ich das ein wenig spartanisch gefaßt habe, da war /ist Pultukes Ansatz weiterführend - allerdings war meine Intention ja eher einen Zusammenhang zwischen Board-Revision und ROM-Problematiken herzustellen.

Also Lust so etwas zu betreuen hätte ich schon und auch die Zeit könnte ich erübrigen - nur empfinde ich die hier zur Verfügung stehenden Tools als unzureichend....

So etwas wie eine Umfrage , wo man nur anhaken muß und eine Auswertung aller Posts würde automatisch zusammengeführt.... - aber wahrscheinlich gibt e so etwas und ich bin nur zu b..... das zu finden ...

Gruß

Rhonin

 

[pultuke]

@Xellar
Du hast Recht; ist mir beim Ausfüllen der Tabelle auch aufgefallen am Beispiel UV/exUV. Auch da gibt es Unterschiede bei ein und demselben
user- wir nehmen mal an, er macht in beiden Fällen das Gleiche.
Aber deine Aufzählung bringt mich auf die Idee bzw. ich setze mal Deinen Gedanken fort - wir müssten eine "Norm"-Umgebung definieren, wo genau das festgelegt ist, wie eine Test-Konfiguration aussehen muss, wenn wir das mit der Vergleichbarkeit (die sich in der Tabelle widerspiegeln soll) zum debugging sinnvoll nutzen wollen. Ähnlich den 4 Zeilen in Rhonins Startpost müssen dann die Teilnehmer die erweiterten Angaben angeben, dann lassen die sich auch besser in die Zeilen eintragen. Dazu sollten von jeder board Rev z.B. ein/zwei erfahrenere Flasher die "Norm"-Tests durchführen ...

Gesendet von meinem GT-I9001 mit der Android-Hilfe.de App

 

[Th3 Witch3r]

Ich wäre dabei...

Denke schon das man so einen guten Überblick über die ganze Sache bekommen könnte.

 

[Ciapa]

Ich pushe das mal. Ist teilweise doch aktuell und zu schade, wenns unter den anderen Threads versinkt

Gesendet von meinem GT-I9001 mit der Android-Hilfe.de App

 

[XeLLaR]

Es ist nicht machbar. Wie soll das denn ablaufen?

Gesendet von meinem GT-I9001 mit der Android-Hilfe.de App

 

[lars95]

• ROM: CM 10 beta 4
• Kernel: 3.0.70-cyanogenmod-gec89ff3
  tiziano@tiziano-ubuntu #172
  Sun Mar 24 22:25:52 CET 2013
• H/W-Revision: 0X06
• Recovery: CWM 5.5.0.4
• Bugs: Spontane Neustarts mit PIN-Eingabe oder "komplettes Ausschalten"

 

[pultuke]

@Rhonin/Xellar/Th3Witch3r und weitere

Habe mal eine mögliche "Normumgebung" zusammengestellt und stelle sie hier zur Diskussion:

-Board Revision
-CPU Revision (wie findet man die ??)
-Kernel : Stock/UV/Bigmem
-ROM ....
-OC (OverClock, wenn ja welche Frequenz?) 1.805 Ghz
-UV (UnderVolt, wenn ja Welches UV Table?) das vom Kernel vorgegebene
-User (Benutzerverhalten) Telefon/Internet/Standardgame
-Einstellungen (Governor, I/O Sheduler & etc) die beste batt-schonende und die spielperformanteste
-Mods was gemeint ?/ besser keine
-Apps Standard von der ROM vorgegeben
-Systemapps gelöscht(Wenn ja, welche?) Nein

Jetzt kommt natürlich die Überlegung: wenn jemand mit dieser Konfiguration testet, hat er/sie wahrscheinlich nicht seine wichtigen Apps dabei, ist somit nicht mehr für seine übliche Umgebung erreichbar (1-3 Tage bis eine Woche) - ist das leistbar ?

Oder legen wir bestimmte grundsätzliche Apps über die Standard-apps der ROM hinaus fest, sodass wir ein grösseres Spektrum an möglichen Mitmachern haben ?

Manege frei ...

 

[XeLLaR]

Nette idee mit den Vorgegebenen stockapps, aber da ivendor ja jetzt einen neuen kernel rausgehauen hatt, warten wir mal ab. Der neue kernel soll ja um einiges stabiler sein, und nichtmehr so oft sod/rebooten. Bei xda hat noch keiner sod/reboots gemeldet.

Gesendet von meinem GT-I9001 mit der Android-Hilfe.de App

 

[Rhonin]

Es scheint ein neuer potentieller Hardware-BUG identifiziert zu sein....

Schaut mal in diesem Thread nach, da habt ihr die Infos, mit welcher App ihr feststellen könnt, ob ihr betroffen seid...

Ich drücke Euch mal die Daumen...

Gruß

Rhonin

 

[magicw]

Es scheint ein neuer potentieller Hardware-BUG identifiziert zu sein....

Schaut mal in diesem Thread nach, da habt ihr die Infos, mit welcher App ihr feststellen könnt, ob ihr betroffen seid...

Ich drücke Euch mal die Daumen...

Gruß

Rhonin

Das ist kein potentieller HW-Bug, sondern das ist der Monster-Mega Superbrick den grad alle Samsung devices spüren. SII, Nexus, Kindle und was weiss ich was für Geräte da grad betroffen sind. Im XDA wird da ja fleißig drüber diskutiert.

Hier nur mal zur Tragweite: ***WARNING!!! PLEASE READ! ICS Kernels and Recovery - xda-developers

Es gibt wohl ein paar Versionen der eMMC-Speicherbausteine, die sich mit einem speziellen Löschbefehl der 3.x-Kernel nicht vertragen.
Das tragische ist, dass der Chip wohl nicht gleich beim ersten mal defekt ist sondern er kann wohl auch noch einige Löschvorgänge "überleben" bevor er über den Jordan hüpft.

Wichtig ist, derzeit möglichst wenig/gar nicht zu formatieren oder flashen, sobald im recovery ICS/JB-Kernel involviert sind. Diese basieren i.d.R. auf 3.x-Kernel, die eine spezielle Löschroutine beinhalten, die diesen chip zerschiessen kann wenn er aus einer betroffenen Charge kommt.

Bei CWM6.x ist derzeit denke ich die größte Unsicherheit weil viele Versionen schon auf Kernel 3.x compiliert wurden. Ivendor hat grad einen CWM6.0.2.8 downgrade auf 2.x-Kernel eingestellt (downloadlinks in ivendors xda-startpost), damit man wieder beruhigt flashen kann.

CWM5 ist fürs Flashen sicher, weil das wohl noch auf Kernel 2.x basiert
TWRP ist bis zur Version 2.4.4.0_28.03.2013 ebenfalls noch auf Kernel 2.x also auch sicher diesbzgl.


Edit: Den Betrieb einer ICS/JB-ROM seh ich aber nicht als betroffen an, da es nur Wipe- und Formatierungsvorgänge betrifft, die ja doch nur sehr selten (bzw. gar nicht) über die Filemanager der jeweiligen ROMs durchgeführt werden.
Eine Datei zu löschen führt nicht zu dem Problem. Es geht immer um die ganze partition. Deshalb betrifft es vor allem die verwendeten recoveries.

 

[Muhtant]

Der thread auf den verwiesen wird isz abr schon reichlich alt...

 

[Philipp.hy]

Weiß man schon welche Marge bzw. emmc chip betroffen ist?

Gesendet mit meinem Samsung S Plus (@JellyBean)