Defy / RIL Bug / Licht und Schatten

[maniac103]

Naja, das RIL Problem ist auch ein merkwürdiges: um 19:00 ist es direkt nach Beenden der Google Navigation aufgetreten, mitten in der Großstadt (nix mit schwacher Empfang) . Ich mußte dringendst telenieren deshalb keine Logs.

Ist auch ok, a_s_z hat mir die Logs schon zukommen lassen

Was sich daraus ergeben hat:

• Wenn die Telefonie wegfliegt, liegt das - wie schon vermutet - daran, dass das Modem in den 'Panic-Modus' geht.
• Wenn das passiert, kommen die schon bekannten GENERIC_FAILURE-Returncodes aus dem RIL.
• Warum ich nicht eher drauf gekommen bin, dass dieser Fehler an der Modem-Panic liegen kann, ist mir schleierhaft Ihr könnt auf alle Fälle vps danken, dass er mich auf das Stichwort 'Reboot' gebracht hat
• Die einzige Möglichkeit, an dieser Stelle die Telefonie wieder herzustellen, ist ein Reboot.
• Im Stock-ROM macht das der panic_daemon, der momentan in CM nicht (richtig) läuft.
• Ich werde versuchen, den panic_daemon in den Java-Code rufen zu lassen, so dass man das ganze etwas, z.B. mit einer Notification, aufhübschen kann.

Ich werde hier zeitnah mal ein Test-Build hochladen, das

• das SIM-Abfrage-Problem bei Reboot aus dem Bootmenü gefixt hat
• bei Modem-Panic eine Notification anzeigt, die beim Draufdrücken einen Reboot auslöst

Das ganze dient dem Test, ob das wirklich so funktioniert, wie ich mir das vorstelle. Wenn das funktioniert, kann ich in einem zweiten Schritt die UI noch verbessern. Ich stelle mir so was vor:

• wenn Screen aus, sofort Reboot
• ansonsten Notification 'Telefon wird in 1 Minute neu gestartet' mit runterzählendem Timer
• wenn man auf die Notification drückt, kann man zwischen 'Jetzt neu starten', 'erinnere mich in 5 Minuten nochmal' und 'ich starte selber neu' wählen

 

[jrahe]

...das hört sich doch schon sehr vielversprechend an...

 

[Zwergpirat]

Ich freue mich ganz ausserordentlich, dass jetzt doch wieder Bewegung in diesem Thema ist! Bin ein wenig stolz, durch meinen Threadstart dazu beigetragen zu haben, ein ganz fettes DANKE aber an maniac, der sich des Problems wieder annimmt und auch an alle anderen, die sich beteiligen!

lg, z.

 

[maniac103]

So, Testbuild wird grad hochgeladen und ist in ein paar Minuten hier zu finden. Die Telefonie sollte damit nicht mehr absterben, ohne dass die Notification (mit Warndreieck) kommt.

Gebt mal Feedback; wenn's funktioniert, baue ich die UI noch wie erwähnt um und mache auch ein Build für's Defy+.

EDIT: Upload ist fertig.

 

[Zwergpirat]

Ich würde gerne testen, bekomme die Installation aber gerade nicht gebacken.. Bin aber wie gesagt Anfänger in Sachen Custom-ROMs.. Mal sehen, ob ich es noch hinbekomme, ohne mich von Euch an die Hand nehmen zu lassen..

 

[wieselmuff]

ich teste es heut Nacht mal, aber muss sich dafür natürlich aufhängen! mal sehen!

/edit: Jetzt will der scheiß nicht abstürzen!!! argh. immer wenn man es mal bräuchte.

 

[KurtKnaller]

Was sich daraus ergeben hat:

• Wenn die Telefonie wegfliegt, liegt das - wie schon vermutet - daran, dass das Modem in den 'Panic-Modus' geht.
• Wenn das passiert, kommen die schon bekannten GENERIC_FAILURE-Returncodes aus dem RIL.
• Warum ich nicht eher drauf gekommen bin, dass dieser Fehler an der Modem-Panic liegen kann, ist mir schleierhaft Ihr könnt auf alle Fälle vps danken, dass er mich auf das Stichwort 'Reboot' gebracht hat
• Die einzige Möglichkeit, an dieser Stelle die Telefonie wieder herzustellen, ist ein Reboot.
• Im Stock-ROM macht das der panic_daemon, der momentan in CM nicht (richtig) läuft.
• Ich werde versuchen, den panic_daemon in den Java-Code rufen zu lassen, so dass man das ganze etwas, z.B. mit einer Notification, aufhübschen kann.

Aus meinen Erfahrungen heraus kann ich das allerdings nicht bestätigen. Es scheint auch eine Art Selbstheilung ohne reboot stattzufinden, es sei denn, ich würde den bisher nicht bemerkt haben. Glaub ich aber eigentlich nicht.

Letzte Woche saß ich mit Freundin im Auto, als gleichzeitig bei ihrem und meinem Telefon ein Tonsignal kam. Bei Ihr dafür, dass ich wieder erreichbar sei und bei mir die bekannte "Anruf verpasst"-message. Sie hatte mich etwa 30 Minuten vorher versucht anzurufen, ich war aber mal wieder nicht erreichbar. Wir sind beide bei congstar. Mein defy war die ganze Nacht unberührt in der Jackentasche. Kurzum - bei mir ist das oft so: die Telefonie ist unbemerkt weg und 20 oder 30 oder wann-auch-immer plötzlich wieder da. Anscheinend ohne reboot.

Noch etwas anderes: Habe noch vor kurzem eine Diskussion gelesen, wo es um die Anschaffung des defy ging. Hierbei wurde negativ angeführt, dass das defy (stock) ständige reboots habe und deshalb nicht zu empfehlen sei. Ist das dieser panic-daemon? Ist diese Geschichte eine defy-spezifische oder allgemein bei den Androiden verbreitet?

 

[wieselmuff]

äh ist der test build zufällig fürs defy+ ?? batterie läd nur bis 84%...

/edit: läd doch weiter aber unglaublich langsam!

naja egal, ist ja nur ein test.

 

[Defier]

Ich hatte / habe diesen Bug nur ganz selten, trotzdem kann ich mich an sowas erinnern. Zwei Fragen:

• Sind davon nur die CM7 Nightly Builds betroffen (die älteren, vor Maniacs gestrigem Fix ), oder betrifft es auch die als stable deklarierten CM7.1 / CM7.2?
• Ist das Problem mit der Datenschaltung und den Übergängen 2G/3G verwandt, die schon im Stock ROM nie gelöst wurden aber seit CM7 (meist) besser funktionieren?

 

[wieselmuff]

ok ERSTER!

Hatte gerade einen RIL bug. Kurz danach sah ich ein Warndreieck in der Statusleiste... "Modem-Problem. Berühren um neu zu starten."

Hab auch n log, kann den hier grad nicht hochladen.

Danke maniac. Keine Beseitigung der Ursache, aber definitiv ein guter Kompromiss/Workaround!!

Wohooo

 

[vps]

Ich muß die Frage stellen, auch wenn die Antwort vmtl klar ist: hat das Defy eine Möglichkeit, das Modem separat zu powercyclen?
Oder bräuchte man zur Beantwortung einen Schaltplan, den keiner kennt?

Gesendet von meinem MB525 mit der Android-Hilfe.de App

 

[maniac103]

Danke maniac. Keine Beseitigung der Ursache, aber definitiv ein guter Kompromiss/Workaround!!

Danke für die Rückmeldung. Ich werd' dann mal noch die UI etwas aufhübschen
Beseitigen lässt sich die Ursache ja leider nicht (siehe unten).

Kannst du evtl. mal deine Tombstones durchschauen, ob da einer von gkisystem und/oder protocol_driver dabei ist? Wenn ja, lass mir den bitte mal zukommen.

Ich muß die Frage stellen, auch wenn die Antwort vmtl klar ist: hat das Defy eine Möglichkeit, das Modem separat zu powercyclen?
Oder bräuchte man zur Beantwortung einen Schaltplan, den keiner kennt?

Mit Sicherheit beantworten kann dir das nur Motorola, die Vermutung liegt aber sehr nahe, dass es diese Möglichkeit nicht gibt. Zwei Indizien sprechen dafür:

• Auch nach über zwei Jahren Milestone- und Defy-Hacking hat noch keiner einen Weg gefunden, das zu tun (deswegen überspringen die 2ndboot-Kernel auch die Enumerierung des Modems, das müsste man nicht tun, wenn man es powercyclen könnte).
• Motorola selbst benutzt den Workaround 'Reboot' - warum sollten sie das tun, wenn es nicht nötig ist?

 

[a_s_z]

Hi,

Kannst du evtl. mal deine Tombstones durchschauen, ob da einer von gkisystem und/oder protocol_driver dabei ist? Wenn ja, lass mir den bitte mal zukommen.

Kann man diese Protokolle irgendwie aktivieren? Oder passiert das vollautomatisch?

Motorola selbst benutzt den Workaround 'Reboot' - warum sollten sie das tun, wenn es nicht nötig ist?

Ich befürchte, die haben das gemacht weil diese Lösung einfach billiger war, als das Problem wirklich zu beheben Blöd finde ich da vor allen die fehlenden Benutzer-Informationen. Da muss man sich durch x verschiedene Foren fräsen, um überhaupt irgendwelche Infos zu bekommen

Naja, jetzt nicht mehr. Jetzt gibt es ja diesen Thread

CU

 

[maniac103]

Kann man diese Protokolle irgendwie aktivieren? Oder passiert das vollautomatisch?

Das passiert automatisch.

 

[wieselmuff]

die Logs zum RIL bug mit aktivierem panic_daemon

1. als referenz ohne ril hänger
2. der ril hänger (musste komprimiert werden, da 2 MB groß)
3. (ich glaube) live aufnahme bei reboot oder so...

Unter /data/Tombstones habe ich alle tombstones nach "gkisystem und/oder protocol_driver" durchsucht, aber nichts gefunden. :/

Gruß.

 

[maniac103]

die Logs zum RIL bug mit aktivierem panic_daemon

1. als referenz ohne ril hänger
2. der ril hänger (musste komprimiert werden, da 2 MB groß)
3. (ich glaube) live aufnahme bei reboot oder so...

Danke. Das Panic-Handling scheint ja im großen und ganzen zu funktionieren

Unter /data/Tombstones habe ich alle tombstones nach "gkisystem und/oder protocol_driver" durchsucht, aber nichts gefunden. :/

OK, war auch nur ein Gedanke, weil man die Modem-Panic auch durch Absturz von gkisystem Triggern kann (so hab ich das getestet). Wahrscheinlich ist's dann wirklich ein Problem im Baseband-Prozessor.

Mal was anderes: Habt ihr eine Meinung, wie die UI bei Baseband-Panic aussehen sollte. Ich stelle mal zwei Varianten zur Wahl:

1. Wie oben beschrieben
   Notification bei Panic mit herunterzählendem Timer, wenn Timer 0 -> Reboot
   Klick auf Notification öffnet Dialog mit Wahlmöglichkeiten 'Reboot', 'Später erinnern', 'Nicht mehr erinnern'
   bei 'Später erinnern' kommt die Notification + Timer 5 Minuten später wieder
2. Warn-Dialog
   bei Panic geht direkt ein Dialog mit den oben beschriebenen Wahlmöglichkeiten im Vordergrund auf, ohne Notification
   Im Dialog läuft der Timer wie bei 1. runter, wenn Timer 0 -> Reboot (sollte auch bei ausgeschaltetem Gerät zutreffen)
   bei 'Später erinnern' kommt der Dialog 5 Minuten später wieder

Ich hab im Moment lokal 1. implementiert; tendiere allerdings zu 2., da ich denke, dass 1. nicht auffällig genug ist (es ist ja nicht offensichtlich, dass das Gerät in Bälde neu gestartet wird).

Meinungen und/oder zusätzliche Vorschläge dazu?

 

[Microphone]

@maniac: das nenne ich mal cherry picks!

ich persönlich tendiere auch zur zweiten möglichkeit...obwohl ich wirklich mit beiden leben kann

danke für deine tolle arbeit!!!

 

[a_s_z]

Hi,

Mal was anderes: Habt ihr eine Meinung, wie die UI bei Baseband-Panic aussehen sollte. Ich stelle mal zwei Varianten zur Wahl:

1. Wie oben beschrieben
   Notification bei Panic mit herunterzählendem Timer, wenn Timer 0 -> Reboot
   Klick auf Notification öffnet Dialog mit Wahlmöglichkeiten 'Reboot', 'Später erinnern', 'Nicht mehr erinnern'
   bei 'Später erinnern' kommt die Notification + Timer 5 Minuten später wieder
2. Warn-Dialog
   bei Panic geht direkt ein Dialog mit den oben beschriebenen Wahlmöglichkeiten im Vordergrund auf, ohne Notification
   Im Dialog läuft der Timer wie bei 1. runter, wenn Timer 0 -> Reboot (sollte auch bei ausgeschaltetem Gerät zutreffen)
   bei 'Später erinnern' kommt der Dialog 5 Minuten später wieder

Ich hab im Moment lokal 1. implementiert; tendiere allerdings zu 2., da ich denke, dass 1. nicht auffällig genug ist (es ist ja nicht offensichtlich, dass das Gerät in Bälde neu gestartet wird).

Ich bevorzuge auch die Variante 2, bin auch der Meinung 1 ist nicht auffällig genug. Als zusätzliche Option wäre eine (konfigurierbare) "aktive" Benachrichtigung per Vibrieren, Ton und/oder rot blinkender LED super.
Wenn man den Neustart verschiebt, wäre eine permanente Notification über das Problem gut, damit man nach fünf Minuten nicht wieder überrascht ist .

Zudem könnte man unterschiedliche Wartezeiten vorgeben, je nachdem ob der Bildschirm an oder aus ist.
Als NonplusUltra wären diese Zeiten natürlich auch konfigurierbar.

Naja, Hauptsache es gibt überhaupt was.
Alles andere ist die Kür

Vielen Dank für den tollen Einsatz!

Ach so, kann man dann vor diesem Reboot eine Flag-Datei oder so was erzeugen? Dann könnte man in den Init-Skripten auf Existenz dieser Datei prüfen um den Neustart zu beschleunigen. in WR1.8 läuft z.B. DB-Optimierung und Zipalign, wobei gerade das erste einiges an Zeit verbraten kann.


CU

 

[wieselmuff]

Ich bin ebenfalls mit beiden Möglichkeiten zufrieden. Tendiere auch zu 2.

Meine Gedanken dazu:

• Optional ein akustisches Signal, aber andererseits: wenn es eh automatisch neu startet braucht man das auch nicht.
• Ein Hinweis+Counter NACH dem Reboot.
  Zum einen um zu sehen wie oft ein Reboot erfolgte, den man nicht mitbekommen hat, zum anderen um bestimmte Apps neu zu starten. Dann wundert man sich nicht zu sehr darüber, dass Samba plötzlich nicht mehr läuft...
• Was ist, wenn man sich in empfangsbefreiten Gebieten (Kellerparty) befindet? Hat man dann alle 3 Min. ein Reboot?
• Nach kurzer Diskussion mit meinem Kollegen: Pop-Up ist gut, dann hat man direkt die Möglichkeit den Reboot zu verschieben, wenn man gerade was macht. Zumal Wifi ja weiter läuft und Internetaktivitäten möglich sind.
• Hin und wieder reicht es ja bekanntlich auch, den Flugmodus zu togglen. Wäre es vielleicht eine Idee erst Flugmodus togglen, falls erfolglos dann reboot?

Vielen vielen Dank. Wird mal wieder Zeit für ne Spende!

/edit: Kann es sein, dass Eppy deine commits schon gemerged hat? (Verdammte Anglizismen! Aber übersetz das mal!!)

 

[a_s_z]

Hi,

• Ein Hinweis+Counter NACH dem Reboot.
  Zum einen um zu sehen wie oft ein Reboot erfolgte, den man nicht mitbekommen hat, zum anderen um bestimmte Apps neu zu starten. Dann wundert man sich nicht zu sehr darüber, dass Samba plötzlich nicht mehr läuft...

Na dafür gibt es doch Apps wie Tasker, Llama usw. Das "Problem" tritt doch nach jedem Reboot auf und nicht nur nach dem "provozierten". Da würde ich es eher an einer Stelle halten.

Die Meldung nach Reboot / Counter finde ich eine sehr gute Idee!

CU