Defy / RIL Bug / Licht und Schatten

[a_s_z]

Hi,

Danke für die Infos! Mit Google ist da ja nicht so einfach was zu finden!

Die auf dieser CPU laufende Firmware verklemmt sich. Man sieht an obigem Aufbau schon, dass Neuladen des rild überhaupt nix bringen würde. Entladen des gkisystem führt sofort - selbst bei noch funktionierendem Modem - dazu, dass das Modem in den Panic-Modus geht (so hab ich den Workaround getestet). Da man das (intern via USB angeschlossene) Modem auch nicht neu enumerieren kann, bleibt nur der Reboot.

Wie funktioniert das dann eigentlich mit der PIN-Abfrage? wird da irgendwo ein Token zwischengespeichert, oder macht die SIM das "intern"?

Gar nicht. Die libgki musste beim Übergang von Froyo zu Gingerbread schon gepatcht werden, weil sich irgendwelche Binär-Interfaces geändert haben. Wenn du die Eclair-Libs verwenden willst, müsste man diesen Patch (und wahrscheinlich noch weitere) wieder anbringen. Dazu müsste man erst mal jemanden finden, der das kann (ich kann's nicht); bei der momentan verwendeten libgki hat das einer der Milestone-Leute gemacht.

Das gilt doch dann nur für den Defy-Build? Denn das Defy+ hat ja von Haus aus Gingerbread und sollte doch somit auch eine passende libgki haben, oder irre ich mich da?

PS: Ich habe selbst ein Defy, aber eigentlich inzwischen ein Defy+ Gingerbread-Kernel, 1Ghz und HFX5-Akku. Andere Unterschiede gab es doch eh nicht zwischen defy und defy+, oder?

CU,
Andre

 

[wieselmuff]

@ wieselmuff
Ich bin grad in Probierlaune --> hast einen Link zu letzten angeblich funktionierenden skank version? Link erste Seite ist nur die aktuelle Version...
(Solls auch das Datenproblem lösen, oder nur Telefonie?)

Hier die Euroskank Versionen die ich hab:
https://docs.google.com/folder/d/0ByzS9fSYbR8UVG84Vlh5NWtOLVU/edit

Habs hier auch mal unter Sources eingepflegt: http://forum.xda-developers.com/showpost.php?p=21686557&postcount=1

 

[vps]

Die Vermutung ist falsch. Deswegen konnte man ja einige Zeit die PIN-Abfrage mittels zwischenzeitlichem Booten ins Bootmenü umgehen.

Vielen Dank für den Link zur Aufbauskizze! Damit ist ist dann auch klar, daß PIN bzw die Authentifizierungsdaten auf einem anderen Prozessorteil vorgehalten werden und mit einem Neustart des DSP nichts zu tun haben.

Mal abgesehen davon, dass der Java-Code ein Neuladen des rild überhaupt nicht mögen würde, würde das bei dem Problem nicht helfen. Der Aufbau ist eher so:

rild (Daemon) <-> libril-moto-umts1 <-> libgki <-> gkisystem (Daemon) <-> Wrigley 3G

Wrigley 3G ist - vereinfacht gesagt - das Modem und läuft auf einer separaten CPU (das grüne ist das Modem, das rote der Hauptprozessor). Die auf dieser CPU laufende Firmware verklemmt sich. Man sieht an obigem Aufbau schon, dass Neuladen des rild überhaupt nix bringen würde. Entladen des gkisystem führt sofort - selbst bei noch funktionierendem Modem - dazu, dass das Modem in den Panic-Modus geht (so hab ich den Workaround getestet). Da man das (intern via USB angeschlossene) Modem auch nicht neu enumerieren kann, bleibt nur der Reboot.

Das heißt also der Code im DSP (Modem) verrennt sich und die jetzige Lösung bedeutet, den Code im DSP neu zu laden. Das geht nur über den -- auch im Wiki skizzierten -- Ablauf des Neustartens.

Nach google ist gkisystem propäritär, d.h. was genau passiert zwischen AP und DSP kann man gar nicht so einfach herausfinden. Sowohl was das von Dir angesprochene Entladen des gkisystem als auch den "RIL-Bug" betrifft. Und natürlich kann man auch nicht herausfinden, ob der DSP Code einen "Neustart ohne Neuladen" Zugang hat (obwohl, den hätte Motorola ggf schon selbst genutzt).

Tricky

 

[wieselmuff]

Ok ich hab mir mal nen Batch-Checksum-Vergleichstool rausgesucht womit es schnell ersichtlich ist, dass ziemlich viele Daten unterschiedlich sind.
Jetzt wollte ich mal in die unterschiedlichen Daten reinschauen, aber die müssen erst dekompiliert werden, oder? Bisher finde ich nur sowas wie UOTKitchen und so mit dem man apk's decompiled, aber nichts mit dem ich System-Dateinen und Treiber dekompilieren kann...
Kann mich mal jemand in die richtige Richtung schubsen?

/edit: Ok hat sich erledigt mit dem Dekompilieren. Mir wurde just erklärt, dass ich mit dem Ergebnis nicht wirklich viel anfangen könnte. Also schau ich mal ob es von Fuzz_ (Euroskank) n Github gibt.

 

[a_s_z]

Hi,

Das Modem.

Wrigley 3G ist - vereinfacht gesagt - das Modem und läuft auf einer separaten CPU (das grüne ist das Modem, das rote der Hauptprozessor). Die auf dieser CPU laufende Firmware verklemmt sich.

Mal noch eine Frage: Woher weiß man eigentlich, das im Defy ein Wrigley3G drin ist? Ich hab da nur was über das Milestone gefunden und einen direkten Kernel-Treiber scheint es auch nicht zu geben? Im Kernel ist nur das QSC6085-Modem aktiviert.

CU,
Andre

 

[maniac103]

Ok ich hab mir mal nen Batch-Checksum-Vergleichstool rausgesucht womit es schnell ersichtlich ist, dass ziemlich viele Daten unterschiedlich sind.
Jetzt wollte ich mal in die unterschiedlichen Daten reinschauen, aber die müssen erst dekompiliert werden, oder? Bisher finde ich nur sowas wie UOTKitchen und so mit dem man apk's decompiled, aber nichts mit dem ich System-Dateinen und Treiber dekompilieren kann...
Kann mich mal jemand in die richtige Richtung schubsen?

Poste einfach mal die volle Liste an Unterschieden

Mal noch eine Frage: Woher weiß man eigentlich, das im Defy ein Wrigley3G drin ist? Ich hab da nur was über das Milestone gefunden

Die RIL-Stacks vom Milestone und vom Defy sind praktisch identisch. Das Defy ist im Prinzip ein etwas moderneres (CPU, RAM) Milestone ohne Tastatur.

und einen direkten Kernel-Treiber scheint es auch nicht zu geben? Im Kernel ist nur das QSC6085-Modem aktiviert.

CONFIG_NETMUX_DRIVER, CONFIG_NETMUX_LINKDRIVER, CONFIG_MODEM_PM_DRIVER und CONFIG_SYSPANIC gehören zum Modem-Treiber. Eventuell ist da noch mehr (es gibt z.B. einen SIM-Treiber), aber die Kernel-Seite habe ich mir noch nie so richtig angeschaut.

 

[wieselmuff]

wird gemacht,sobald ich aus Berlin zurück bin. seltsam hier: nur 3G=Daten, 2G/3G=keine Daten, 2G=keine Daten. Autowechsel geht nicht. ZETT.

 

[my2ct]

So. Jetzt hatte ich mal Zeit, den ganzen Thread nochmal zu lesen. Der Neustart-Workaround ist ja schonmal eine Maßnahme... Hoffentlich greift Quarx den mit auf.

Ich selbst falle oft dem RIL-Bug zum Opfer, mit unterschiedlichen Ausprägungen:

-nur Datenverbindung weg, G|E|3G|H wird angezeigt Empfangsanzeige grau, auch keine sonstigen Datenverbindungen möglich
-nur Datenverbindung weg, G|E|3G|H wird NICHT angezeigt Empfangsanzeige grau, auch keine sonstigen Datenverbindungen möglich
-Daten UND Telefon weg, Empfangsanzeige grau (nicht erreichbar)

Und auch unterschiedlichen Abhilfen:

-Daten aus/an, bei Misserfolg
-Umschaltung 3G-->2G und zurück bei Erfolg, bei Misserfolg
-Flugmodus ein/aus wobei der Flugmodus sich oft nur nach Reboot deaktivieren lässt

Ich habe all diese Maßnahmen in diversen Foren als `teilweise zum Erfolg führend gefunden.

Ich meine sogar, dass diese `Rettungs-Phallanx` schon mal automatisiert wurde.
Die Boot-Verschiebung mit Notifikation ist da eine gute Ergänzung.

Frage: macht es Sinn, die Rettungsversuche von leicht (Daten aus/an) bis drastisch (Reboot) so nacheinander zu automatisieren (wenn möglich)? Ein Reboot dauert bei mir knapp 2min. Manchmal geht es ja auch ohne...

Ach ja: PIN-Abfrage habe ich ohnehin aus:
1. verliere ich eher nen Arm als ein Handy
2. Wenn Arm und Handy weg, dann möchte ich, dass das Handy noch möglichst lange in Betrieb bleibt und Latitude mir beim Finden hilft...

Gesendet von meinem Nexus 7 mit Tapatalk 2

 

[blur99]

Hallo, ich hätte noch ein paar Verständnis Fragen zu dem RIL Bug:
-Ist das Patch mittlerweile in die "normalen" nightlies integriert? oder gibt es ein patch, dass ich zusätzlich zu der aktuellen nightly installieren kann, benutze die vom 1.1.2013.
-wenn es kein zusätzliches patch gibt, kann ich auf eine ältere, aber gepatchte nighty zurückkehren ohne datenverlust?
-gibt es einen aktuellen link zu einer gepatchten nightly?

Vielen Dank für die Antworten!

 

[Defier]

@blur99: Nein, die neueste Version (von der wir hier sprechen) ist die vom 7.12.12 und diese ist hier zu finden und enthält den Patch:

https://github.com/maniac103/android_device_motorola_jordan-common/downloads

Der Patch wurde am 5.12.12 von maniac103 eingecheckt. Die aktuellen CM9/10/10.1 Nightlies enthalten diesen Patch (noch?) nicht.

Edit: Es gibt auch eine automatisch gebaute Version vom 1.1.2013, ich weiss allerdings nicht ob sie den Patch enthält:

http://download.cyanogenmod.org/?device=jordan&type=nightly

Der ursprüngliche Beitrag von 12:58 Uhr wurde um 13:53 Uhr ergänzt:

Ich habe eine Umfrage konzipiert, um mehr über die Symptome für diesen Fehler zu erfahren. Einen Draft findet ihr hier, ich würde mich sehr über Verbesserungsvorschläge freuen:

https://www.android-hilfe.de/forum/...-zu-ril-bug-kommentare-erwuenscht.362101.html

Der ursprüngliche Beitrag von 13:53 Uhr wurde um 14:04 Uhr ergänzt:

@my2ct: Den folgenden Effekt hast du nicht?:

- Empfangsanzeige nicht grau (Balken werden angezeigt)
- Datenverbindungssymbol (H, E, G, 3G) wird angezeigt
- Verbindungen kommen trotzdem nicht zustande

ebenso nicht folgenden Effekt?:

- Empfangsanzeige nicht grau (Balken werden angezeigt)
- Man is trotzdem nicht erreichbar

 

[Defier]

Die Umfrage ist fertig, ich bitte sehr um rege Teilnahme. Alle Details hier:

https://www.android-hilfe.de/forum/...erbindungen-und-neustarts-ril-bug.362775.html

 

[ichbinsnur]

Finde ich super das dieses Thema nun auf der Angenda ist. Mir war (bis ich dieses Thema gefunden habe) gar nicht klar wieso ich ab und zu keinen Anruf mehr bekommen habe.

Danke an alle die daran mithelfen.

 

[my2ct]

@blur99: Nein, die neueste Version (von der wir hier sprechen) ist die vom 7.12.12 und diese ist hier zu finden und enthält den Patch:

https://github.com/maniac103/android_device_motorola_jordan-common/downloads

Der Patch wurde am 5.12.12 von maniac103 eingecheckt. Die aktuellen CM9/10/10.1 Nightlies enthalten diesen Patch (noch?) nicht.

Edit: Es gibt auch eine automatisch gebaute Version vom 1.1.2013, ich weiss allerdings nicht ob sie den Patch enthält:

http://download.cyanogenmod.org/?device=jordan&type=nightly

Der ursprüngliche Beitrag von 12:58 Uhr wurde um 13:53 Uhr ergänzt:

Ich habe eine Umfrage konzipiert, um mehr über die Symptome für diesen Fehler zu erfahren. Einen Draft findet ihr hier, ich würde mich sehr über Verbesserungsvorschläge freuen:

https://www.android-hilfe.de/forum/...-zu-ril-bug-kommentare-erwuenscht.362101.html

Der ursprüngliche Beitrag von 13:53 Uhr wurde um 14:04 Uhr ergänzt:

@my2ct: Den folgenden Effekt hast du nicht?:

- Empfangsanzeige nicht grau (Balken werden angezeigt)
- Datenverbindungssymbol (H, E, G, 3G) wird angezeigt
- Verbindungen kommen trotzdem nicht zustande

ebenso nicht folgenden Effekt?:

- Empfangsanzeige nicht grau (Balken werden angezeigt)
- Man is trotzdem nicht erreichbar

Effekt1 selten, meist alles grau und ohne Dienstindikation (H/3G/...)

Effekt2 nie bemerkt, da habe ich eher o2 im Verdacht. Ein Kumpel mit nem EiFön ist oft erst beim 2ten Versuch erreichbar...


Gesendet von meinem Nexus 7 mit Tapatalk 2

 

[Defier]

Also Effekt 1 scheint lt. Umfrage schon vorzukommen, hier ein Zwischenstand:

---
14 Passiert es, dass dein Telefon keine Datenverbindung aufbauen kann, obwohl das Symbol für die Datenverbindung (z.B. "H", "E", "3G", "G") angezeigt wird?

Ja, (sehr) häufig
11.1% (4)
Ja, ab und zu
22.2% (8)
Ja, jedoch sehr selten
13.9% (5)
Nein
11.1% (4)
Weiss nicht / ist mir nicht aufgefallen
13.9% (5)
keine Angabe
27.8% (10)
---

Bei Effekt 2 scheint es eine deutlich Tendenz zu geben Richtung "Balken werden angezeigt, trotzdem nicht erreichbar":

--
12 Nur wenn dein Telefon keine Mobilfunkverbindung hatte: wie sah die Empfangsanzeige aus?

Keine Signalbalken (nur grauen Balken mit dem Kreuz)
11.1% (4)
Notrufsymbol (rotes Kreuz)
5.6% (2)
"Normale" weiße Signalbalken
36.1% (13)
Sonstige:
5.6% (2)
kleiner oder gleich 3 Balken
teils blaue Balken teils graue
keine Angabe
41.7% (15)
--

Angenommen es würde am Netzanbieter liegen - dann dürfte das Telefon doch gar keine Balken anzeigen sondern das "nur Notrufe"-Symbol, das sonst bei überlasteten Netzen (z.B. Silvester) erscheint. Sobald mehr Daten vorliegen werde ich versuchen die Effekte mit den Netzanbietern zu korrelieren, vielleicht gibt es manche Effekte verstärkt nur mit bestimmten Netzanbietern.

Balken anzuzeigen und trotzdem nicht erreichbar ist aus meiner sicht echt tödlich, speziell wenn man gerade auf nen wichtigen Anruf wartet und einem später vorgeworfen wird man wäre die ganze Zeit nicht erreichbar gewesen...

 

[KurtKnaller]

...

Da ein paar Stimmen behaupteten, dass die Euroskank-Versionen bis zum 3.12. stabil waren musste ich das mal testen und tatsächlich ist mir in drei Nächten nicht einmal die Verbindung abgeraucht (kann Zufall sein, aber ich glaube es fast nicht.)

...
Lieben Gruß.

Ich glaube, da ist nix dran. Der Hase in seinen Versionen 1.5x und 1.7x basiert ja m.W. auf der jeweils letzten euroskank (FuZZ_) und da kommt es, zumindest bei meinem defy+, häufig zum RIL-bug.

 

[wieselmuff]

Ich hoffe einfach doch. Die aktuellen Fuzz sollen wohl auch den RIL-bug haben, nur bis 121203 angeblich weniger... keine Ahnung.

Jetzt hatte ich auf jeden Fall endlich Zeit, die md5-compare-Liste anzufertigen. Hab die zips extrahiert und die Dateien mit Checksum Compare 1.2 verglichen.

Sysiphus lässt grüßen.

OT:
Ich bin übrigens sehr gespannt auf CyanMobile... wollte ich gleich mal testen.

 

[Lion]

Also mal meinen Senf zur Euroskank Version.
Wieselmuff hatte ja dankenswerterweise eine angeblich gute Version hier im thread hochgelanden bzw. verlinkt.
Ich hab sie jetzt seit einer Woche drauf.

Ich kanns kaum fassen, da ich extrem skeptisch war: Aber was den Datenverbindungsbug betrifft, ist das definitiv die beste Version seit stock.
Ich hatte so gut wie IMMER Internet. Und das ist wirklich überraschend, denn ich war extrem stark von Datenausfällen betroffen. Also auch kein Abreissen der Verbindung mit nachfolgendem Wiederverbinden --> die Verbindung ist einfach extrem stabil

Dadurch erkenne ich jetzt ersten den RIL bug --> wenn jetzt die balken weiss sind, trifft der Ril-bug zu --> hatte ich 2 x in dieser Woche. Früher konnte ich zwischen Daten und Ril-Bug nicht unterscheiden.

Warum das so ist - keine Ahnung
Aber meine "Wunschversion" wäre ganz klar: DIESE euroskank mit dem Ril-workaround von maniac.....

 

[Defier]

@Lion: Das klingt doch sehr vielversprechend. Und du bist sicher, dass diese Euroskank-Version auch das gleiche Baseband usw. genutzt hat wie die anderen Versionen, mit denen du immer Probleme hattest?

Und zu den Begriffen: Für mich ist der "RIL-Bug" ein Fehler im Radio Interface Layer, d.h. sowohl den Ausfall der Datenverbindung als auch den der Mobilfunkverbindung würde ich diesem Bug zuordnen. Das wurde in diesem Thread ja meist auch etwas wild durcheinanderdiskutiert, scheint aber beides ein Problem mit dem Modem bzw. seiner Firmware zu sein?

Wär echt interessant zu wissen was in dieser angeblich gesunden Euroskank-Version so viel anders ist als in CM7...

 

[h00bi]

Mich wundert es, dass dieser Bug mittlerweile sogar einen eigenen Namen bekommen hat, obwohl das Problem schon seit Monaten durch Quarx (so gut wie) behoben wurde:

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

Das ist auch der Grund warum ich kein CM7 mehr nutze, obwohl es mir viel viel besser gefällt als CM auf ICS oder JB Basis.

 

[Lion]

Mit cm10 wars mal besser, aber bei aktuellen Versionen ist der fix entweder nicht mehr drin, oder funktioniert nicht mehr, siehe http://forum.xda-developers.com/sho...M10 Data connectivity bug - unFIXED, it seems