Defy / RIL Bug / Licht und Schatten

[wieselmuff]

bei mir immer beides:
daten und telefonie. aber da gibts doch schon nen thread!

 

[a_s_z]

Hallo und schönen guten Abend,

mich trifft der RIL-Bug auch. Mal öfters, mal nicht so oft. Auch die Telefonie ist schon mal betroffen gewesen.

Bei mir ist eigentlich immer das Problem, das nichts mehr hilft außer das Telefon neu zu starten. OK, damit kann ich leben, wenn ich zumindest "kurzfristig" mitbekomme, das die Datenverbindung/Telefonie abgeschmiert ist.

Da es ja offensichtlich nicht so einfach möglich ist, den Bug zu beseitigen oder einen automatischen Workaround für alle Fälle zu bauen, stellt sich mir die Frage ob der Zustand denn softwareseitig zumindest erkennbar ist (Zumindest für einige Fälle scheint es ja was zu geben (z.B. in WR 1.8).

Wenn ja, würde ich mich über Hinweise freuen, wie man in diesem Fall z.B. eine Benachrichtigung macht und einen Ton abspielt, damit der Benutzer das Problem zumindest mitbekommt. Wenns da ne App gibt ists gut, aber ein SL4A-Skript wäre natürlich auch super, da man das ja z.B. mit TaskBomb verwenden könnte!

Ich selbst habe das Defy mit WhiteRabbit 1.8, Defy+ Akku und GB kernel, und bin von WR/CM7 grundsätzlich im Vergleich zu dem Stock-ROM begeistert. Großes Lob schon mal dafür an die Entwickler!

Ich hatte leider auch Probleme mit dem WLAN (instabile Verbindung), konnte das aber durch die Umstellung auf TKIP statt AES lösen. Oder gibt es da eine andere Möglichkeit? Naja, vielleicht sollte ich dieses Problem aber lieber in einem anderen Thread posten ...

Liebe Grüße,
Andre

 

[wieselmuff]

ping mit tasker oder so? ich könnte so nen hinweis auch brauchen!!! gute idee...

 

[RATTAR]

Es ist zwar nicht die Lösung des Problems, aber es hilft zu mindestens einen Netzausfall zu erkennen.
Mit der App Network Signal Info kann eine Alarmierungsfunktion eingerichtet werden die bei Netzverlust eine Warnmeldung abgibt.

 

[KurtKnaller]

Es ist zwar nicht die Lösung des Problems, aber es hilft zu mindestens einen Netzausfall zu erkennen.
Mit der App Network Signal Info kann eine Alarmierungsfunktion eingerichtet werden die bei Netzverlust eine Warnmeldung abgibt.

Ein Problem scheint mir ja zu sein, dass es diesen Fehler schon lange gibt, er aber noch nicht vernünftig analysiert worden ist.

Ich kann mich täuschen, aber ich meine, man ist nicht erreichbar, obwohl das Netz guten Ausschlag zeigt. Das wurde auch von anderen in der Vergangenheit berichtet.

Aber Danke für den Tipp. Ein Versuch ist es allemal wert.

 

[wieselmuff]

Leider nur in der Pro-Version verfügbar... da würde ich mir gerne erst sicher sein ob das auch so funktioniert. Vielleicht find ich ja noch ne Alternative.

 

[vps]

Ja, hast du.

Edit: Ich hatte überlesen, dass du Telefonieprobleme hast. Das, was allgemein als RIL-Bug bezeichnet wird, verursacht allerdings nur Datenverbindungsprobleme. Von einem Telefonieproblem höre ich hier zum ersten Mal; das ist definitiv kein bekanntes Problem. Meine Abhandlung unten bezieht sich nur auf die Daten-Probleme.

Ich kann bestätigen, daß die Telefonie nicht geht. Und da ich seit der ersten CM7 stable dabei bin und mitlese, weiß ich, daß ich nicht der einzige bin. Vielleicht sollte man man die Meldungen dazu immer genauer eingegrenzen (in einem offenen Forum schwierig):

1. Bug: keine Telefonie, keine Daten, beim versuchten Wechsel in Flugmodus wird dieser nie erreicht. Einzige Lösung: reboot.

2. Bug: keine Datenverbindung mehr. Datenverbindung kommt nach einiger Zeit automatisch / durch manuellen Wechsel 2G-3G / durch Wechsel Flugmodus und zurück wieder.


Ich kenne den 2. nur so, daß nach einiger Zeit automatisch wieder alles da ist. Den 1. habe ich häufig, hier hilft wirklich nur reboot. Ich habe den Verdacht, daß es diesen Bug schon bei Froyo gab und er sich dort durch automatischen Reboot des Telefons äußerte.

 

[wieselmuff]

wurde hier: https://www.android-hilfe.de/forum/...ch-im-automatikmodus-staendig-auf.179898.html

schon vielfach drüber geschrieben.
Vorschlag:
Entweder könnte sich jemand die Mühe machen, die Infos dort zu filtern und hier einzubringen oder aber dort weiter diskutieren.

 

[maniac103]

Ich kenne den 2. nur so, daß nach einiger Zeit automatisch wieder alles da ist. Den 1. habe ich häufig, hier hilft wirklich nur reboot. Ich habe den Verdacht, daß es diesen Bug schon bei Froyo gab und er sich dort durch automatischen Reboot des Telefons äußerte.

Ah, da kommen wir der Sache doch schon näher
Stock-Froyo hat für diesen Fall (Baseband-Firmware stirbt komplett) einen Daemon namens 'panic_daemon', der den Absturz erkennt und einen Neustart einleitet. Ich hab grade, als ich über die gesamte Sache nochmal drübergeschaut habe, gesehen, dass der in CM nicht richtig läuft. Ich werd' mal ein neues Build mit diesem Daemon machen, aber zur Verifizierung könnte einer der betroffenen User mal folgendes machen:

• Warten, dass Fehler (d.h. komplett gestorbene Telefoniefunktion) auftritt
• Radio-Logcat (idealerweise Radio- und Main-Logcat) aufnehmen (z.B. mit CatLog) und mir zukommen lassen
• Im Terminal-Emulator 'lsusb' ausführen und mir die Ausgabe ebenfalls zukommen lassen.

In der lsusb-Ausgabe sieht man, ob das Baseband gestorben ist; mit der Logcat-Ausgabe will ich sehen, ob die GENERIC_FAILURE-Fehler genau dann kommen, wenn das Baseband gestorben ist.


BTW, da spielt dann die SIM-PIN-Abfrage-Sache mit rein: Bei so einem Neustart will man ja nicht, dass die PIN wieder abgefragt wird...

 

[a_s_z]

Hi,

Ah, da kommen wir der Sache doch schon näher
Stock-Froyo hat für diesen Fall (Baseband-Firmware stirbt komplett) einen Daemon namens 'panic_daemon', der den Absturz erkennt und einen Neustart einleitet. Ich hab grade, als ich über die gesamte Sache nochmal drübergeschaut habe, gesehen, dass der in CM nicht richtig läuft.

OK, jetzt weiss ich wenigstens, warum das Defy öfters mal einfach so neu gestartet hat Macht der Daemon das dann unter CM auch so? Da würde ich eine Benachrichtigung oder eine Konfigurierbarkeit der Auto-Aktion besser finden, denn vielleicht macht man ja gerade aktiv was, und Datenverlust wäre schon blöd
Bei einen solchen Neustart sollte dann in WR 1.8 die DB-Optimierung am Anfang nicht laufen. Die verzögert den Start bei mir nämlich schon einige Minuten

Ich werd' mal ein neues Build mit diesem Daemon machen, aber zur Verifizierung könnte einer der betroffenen User mal folgendes machen:

• Warten, dass Fehler (d.h. komplett gestorbene Telefoniefunktion) auftritt
• Radio-Logcat (idealerweise Radio- und Main-Logcat) aufnehmen (z.B. mit CatLog) und mir zukommen lassen
• Im Terminal-Emulator 'lsusb' ausführen und mir die Ausgabe ebenfalls zukommen lassen.

In der lsusb-Ausgabe sieht man, ob das Baseband gestorben ist; mit der Logcat-Ausgabe will ich sehen, ob die GENERIC_FAILURE-Fehler genau dann kommen, wenn das Baseband gestorben ist.

Gut, dann stell ich mal wieder auf 2G/3G-Auto, damit das Ganze eher auftritt

BTW, da spielt dann die SIM-PIN-Abfrage-Sache mit rein: Bei so einem Neustart will man ja nicht, dass die PIN wieder abgefragt wird...

PS: Wie kann ich mich bedanken? Habe keinen Danke-Knopf gefunden

Liebe Grüße,
Andre

 

[maniac103]

Hi,


OK, jetzt weiss ich wenigstens, warum das Defy öfters mal einfach so neu gestartet hat Macht der Daemon das dann unter CM auch so?

Ja - ist ja auch der selbe Daemon

Da würde ich eine Benachrichtigung oder eine Konfigurierbarkeit der Auto-Aktion besser finden, denn vielleicht macht man ja gerade aktiv was, und Datenverlust wäre schon blöd

Das ist richtig, das würde ich aber - wenn überhaupt machbar - in einem zweiten Schritt machen. Machen könnte man z. B. Benachrichtigung + verzögerten Reboot. An letzterem führt allerdings kein Weg vorbei, wenn das Baseband wirklich in den Panic-Modus geht.
Interessanterweise habe ich dieses Problem in 18 Monaten CM7 noch nie selbst gesehen, und das trotz extrem schlechten (O2-)Netzes auf Arbeit.

Gut, dann stell ich mal wieder auf 2G/3G-Auto, damit das Ganze eher auftritt

Ist ja nur 1x

PS: Wie kann ich mich bedanken? Habe keinen Danke-Knopf gefunden

Dafür brauchst du mindestens 10 Postings.

Gesendet von meinem MB525 mit Tapatalk 2

 

[Einsteinno1]

die Datenbank optimierung kannst ausschalten indem du im Ordner system/etc/init/S01defrag löschen

wow sehe gerade das ich 3390 Beiträge habe und somit ein GURU bin, CRAZY, finde ich überhaupt nicht

 

[a_s_z]

Hi,

Das ist richtig, das würde ich aber - wenn überhaupt machbar - in einem zweiten Schritt machen. Machen könnte man z. B. Benachrichtigung + verzögerten Reboot. An letzterem führt allerdings kein Weg vorbei, wenn das Baseband wirklich in den Panic-Modus geht.

Den Reboot an sich finde ich nicht so schlimm (wenn wie schon gesagt das Starten danach nicht > 5 Minuten braucht), was mich ziemlich stört ist der Neustart ohne Vorwarnung und/oder Möglichkeit den Reboot zu verschieben. Ist halt doof, wenn man gerade eine ellenlange Antwort für Android-Hilfe schreibt, und dann plötzlich alles weg ist weil das Telefon einen Reboot macht Das geht ja bei Win auch

Dafür brauchst du mindestens 10 Postings.

OK, na dann mach ich hier mal weiter mit meinen Postings, damit ich mich auch bald bedanken kann

CU

 

[HammDefy]

@ Einstein: Passt aber zu Deinem Namen

 

[a_s_z]

Hi,

die Datenbank optimierung kannst ausschalten indem du im Ordner system/etc/init/S01defrag löschen

Also ich finde die Optimierung an sich eine gute Sache.

Hab natürlich beim ersten Mal gedacht, das Defy hängt weil sich in dieser Zeit ja gar nix tut. Gibt es da die Möglichkeit einer Fortschrittsanzeige, oder kann man zuerst die Bootanimation starten?

Eine einfache Möglichkeit wäre doch, sich den letzten Zeitpunkt zu merken und nur nach z.B. 2 Tagen wieder was zu machen, oder? Ist doch nur ein "einfaches" Shellskript. Für eine schöne Ausgabe und Logdatei könnte man natürlich auch das Detailing-Skript nehmen, das im SuperChargerV6 ist.

Eine noch bessere Variante wäre natürlich das für jede Datei zu machen und ungeänderte Datenbanken erst gar nicht zu optimieren. Dann sichert Titanium auch beim nächsten Lauf nicht wieder alles


PS: Ich hab hier öfters das Problem, das der Bildschirm nach dem Aktivieren "leer" bleibt. Wenn ich dann noch mal aus und an mache geht es dann wieder. Ist das "normal" bzw. bekannt?

CU

 

[wieselmuff]

am WE bin ich auch wieder in meiner Testzone. Dann kommen die Daten. wäre das geil!!

da würden sich einige drüben beim xda jb thread auch drüber freuen!

 

[jrahe]

OT @Einsteinno1

GRATULATION zum GURU
(...voll berechtigt, wie ich finde)
/OT

Gruß Jörg

 

[vps]

Ah, da kommen wir der Sache doch schon näher
Stock-Froyo hat für diesen Fall (Baseband-Firmware stirbt komplett) einen Daemon namens 'panic_daemon', der den Absturz erkennt und einen Neustart einleitet. Ich hab grade, als ich über die gesamte Sache nochmal drübergeschaut habe, gesehen, dass der in CM nicht richtig läuft.

Wie war das denn bei Eclair? Damals trat das Problem bei mir nie auf, weder Verbindungsverluste noch Reboots. Und ein paar Monate lang war Exclair auf diesem Defy (ist erste Serie, November 2010 gekauft).

Ich werd' mal ein neues Build mit diesem Daemon machen, aber zur Verifizierung könnte einer der betroffenen User mal folgendes machen:

• Warten, dass Fehler (d.h. komplett gestorbene Telefoniefunktion) auftritt
• Radio-Logcat (idealerweise Radio- und Main-Logcat) aufnehmen (z.B. mit CatLog) und mir zukommen lassen
• Im Terminal-Emulator 'lsusb' ausführen und mir die Ausgabe ebenfalls zukommen lassen.

In der lsusb-Ausgabe sieht man, ob das Baseband gestorben ist; mit der Logcat-Ausgabe will ich sehen, ob die GENERIC_FAILURE-Fehler genau dann kommen, wenn das Baseband gestorben ist.

Ist aufgetreten als ich aus dem Haus ging, bemerkt als ich WLAN abschaltete. Logfiles gesichert, lade später irgendwohin und poste Link, jetzt gerade etwas Arbeit hier.

Edit: hier der link http://vitus.warpmail.net/public/Defy/vps-notel.tgz

 

[JohnMcLane]

War bei mir damals genau anders herum. Unter Eclair Verbindungsverlust sowie Random Reboots. Ging erst ordentlich mit Froyo wieder weg.

 

[vps]

Ich weiß noch, daß ich bei Eclair einiges mit EasyProfiles automatisiert hatte: Daten auf 3G im Auto, 2G auf Arbeit, WLAN zuhause. Alles durch Lokationen undd Ladezustand getriggert. War mit Froyo schlagartig unmöglich.

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.

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