[ROM] CyanogenMod 10.1 (Android 4.2) Nightly Builds

[Aslolo]

Hat damit eigentlich nichts zu tun, da für den shutdown erstmal ein boot stattfinden muss, oder?
Ist einfach reines Eigeninteresse ^^

 

[Blechdose]

Ich werd aus dem Quellcode nicht schlau, hab mit sowas noch nie gearbeitet
Naja, es ist schon spät, und ich nicht mehr der wachste, deswegen schau ichs mir morgen nommal an
Nur ne kurze Frage hätte ich den.
Der .32er hat ganz am Ende diese Zeile Code:
Der 3.0er hingegen diese:
Wieso einmal mit dem Begriff "omap" und einmal ohne?
MfG und Gute Nacht

Ich denke die Funktionen wurden einfach umbenannt; in 2.6 findet sich darüber
static void ehci_omap_shutdown(struct usb_hcd *hcd) {} und bezieht sich darauf, in 3.0 wurde das vermutlich ausgelagert oder fehlt.
Schonmal eine Sache, die ich porten kann Aber das Problem ist nicht das herunterfahren oder das Powermanagement an sich, sondern eher, dass die Kommunikation nicht erfolgt.

 

[ch-world]

Da du sagst die Kommunikation läuft nicht war mir erstmal ein Initialisierungsproblem in den Sinn gekommen. Spontan fällt mir da die omap_start_ehc auf. Die hier wird ja wirklich viel auch auf lowlevel Ebene gemacht (Clocks setzen, GPIOs aktivieren etc). Ein fehlendens Clock setzen würde ja bedeuten, dass die Kommunikation unterschiedlich flott abläuft und somit nur Müll ankommt.

Auch die neue omap_ehci_hw_phy_reset fällt mir da auf, hier nur ein simples GPIO an, aus...

Sehe jetzt aber, es ist viel mit dem ohci gemischt. Mh.

 

[Blechdose]

Da du sagst die Kommunikation läuft nicht war mir erstmal ein Initialisierungsproblem in den Sinn gekommen. Spontan fällt mir da die omap_start_ehc auf. Die hier wird ja wirklich viel auch auf lowlevel Ebene gemacht (Clocks setzen, GPIOs aktivieren etc). Ein fehlendens Clock setzen würde ja bedeuten, dass die Kommunikation unterschiedlich flott abläuft und somit nur Müll ankommt.

Auch die neue omap_ehci_hw_phy_reset fällt mir da auf, hier nur ein simples GPIO an, aus...

Sehe jetzt aber, es ist viel mit dem ohci gemischt. Mh.

Das mit der unterschiedlichen Geschwindigkeiten ist Quarx auch schon aufgefallen, ehci läuft nur mit 12mb/s sollte aber 480 oder ähnlich sein.
Ja omap_start_ehc fehlt dabei komplett, aber wie bereits gesagt, ehci-omap wurde stark vereinfacht.
Ich versuch mich grade an einem kleinen cleanup und habe mal omap_ehci_soft_phy_reset komplett gelöscht sowie ehci_hcd_omap_shutdown dem Code von 2.6 angepasst.
Ich schau mir das mit dem reset aber nochmal an, das könnte wirklich ein Problem darstellen, da der Kernel versucht bei einer nicht aufgebauten Kommunikation eben das zu resetten.
Danke, immer weiter, werde das auch mal Quarx melden!

 

[Aslolo]

Da du sagst die Kommunikation läuft nicht war mir erstmal ein Initialisierungsproblem in den Sinn gekommen. Spontan fällt mir da die omap_start_ehc auf. Die hier wird ja wirklich viel auch auf lowlevel Ebene gemacht (Clocks setzen, GPIOs aktivieren etc). Ein fehlendens Clock setzen würde ja bedeuten, dass die Kommunikation unterschiedlich flott abläuft und somit nur Müll ankommt.

Auch die neue omap_ehci_hw_phy_reset fällt mir da auf, hier nur ein simples GPIO an, aus...

Sehe jetzt aber, es ist viel mit dem ohci gemischt. Mh.

Kann mir jemand die oben markierte Zeile etwas vereinfachen?
Welche Clocks werden wofür gesetzt?
Was sind GPIOs?
MfG

 

[Blechdose]

Dazu muss man verstehen wie das mit dem Modem funktioniert. Unser Modem ist sehr sehr sehr sensibel (sehr!), das heißt, es lässt sich nicht zum Beispiel einfach neustarten, wenn es schonmal lief.
Dazu muss dann immer das gesamte Telefon neugestartet werden.
Unter 2.6.32 ist das so, dass der Reset vom BL umgangen (wenn ein anderer Kernel geladen wird, denn der würde das Modem neustarten) wird und das Modem beim übergreifen des Kernels nicht stirbt (Stock Kernel -> Unser Kernel).
Es bleibt also von Anfang an aktiv.

omap_start_ehc kümmert sich in .32 um die Geschwindigkeit soweit ich das sehe und startet den eigentlichen Controller, existiert aber so im nicht im Gegenstück 3.0 oder irgendwo anders.
Interessant hierbei sind eventuell die verschiedenen Modi (usbhost_120m_fck und usbhost_48m_fck). Zumindest könnte ich hier etwas vermuten...

Ich könnte jetzt hier logs zeigen, aber das verwirrt vermutlich nur noch mehr.
Stellt euch die Reihenfolge ungefähr so vor:
Stock bootet (Modem lebt) -> Kernel 3.0 wird geladen (Modem wird erkannt) -> ehci bekommt aus irgendeinem Grund einen disconnect (Kernel resetet auf 12mb/s anstatt der angedachten 480, hatte aber mal 480(!) -> Modem reset) -> Kommunikation failed.

Ich habe omap_ehci_soft_phy_reset und omap_ehci_hw_phy_reset mal komplett entfernt, machte keinen Unterschied, wird auch so gut wie nicht aufgerufen.

Für interessierte:

<7>[ 1.343963] hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0008 
<7>[ 1.343994] ehci-omap ehci-omap.0: GetStatus port:3 status 001002 0 ACK POWER sig=se0 CSC 
<7>[ 1.344024] hub 1-0:1.0: port 3, status 0100, change 0001, 12 Mb/s

gpio ist hier wohl nicht so interessant, zumindest denken Quarx und ich so, aber hier was zum lesen.

 

[ch-world]

Habt ihr schonmal bei ohci geschaut? Da sind ja auch einige ehci Funktionen zwischen.

 

[Aslolo]

Durch einen unbekannten Fehler wird also der Clock auf 12mb/s getrimmt.
Gibt es eine Möglichkeit ihn wieder anzuheben?
Falls man ihn anheben kann, dann müsste man die Funktion des "Modem resets" im Kernel deaktivieren, aber so einfach ist es dann doch nicht, oder?
Mal was ganz anderes, im N7 Abteil des XDA Forums hab ich was interessantes gefunden. Kexec-hardboot patch - xda-developersIst das vllt in irgendeiner Weise hilfreich?

Noch was (tut mir Leid wenn ich etwas nervig bin, habt mich neugierig gemacht ) die omap_start_ehc ist im 3.0 nicht enthalten. Ist das wegen dem ausgelagerten Powermanagement?
Wodurch wird in 3.0 die Clockgeschwindigkeit gesteuert?
MfG
http://forum.xda-developers.com/showthread.php?t=2104706

 

[Fight4Music]

Mensch Aslolo, du nervst nicht
Du lieferst Sinnvolle Ansatzpunkte, ich kann da aber leider nicht mitreden, wie viele andere, aber das wissen sicher alle anderen auch zu schätzen

(Ich bleib lieber beim News posten )

Achso, schön das du dich auch mal wieder blicken lässt

Gesendet von meinem MB526 mit Tapatalk 2

 

[Blechdose]

Durch einen unbekannten Fehler wird also der Clock auf 12mb/s getrimmt.
Gibt es eine Möglichkeit ihn wieder anzuheben?
Falls man ihn anheben kann, dann müsste man die Funktion des "Modem resets" im Kernel deaktivieren, aber so einfach ist es dann doch nicht, oder?
http://forum.xda-developers.com/showthread.php?t=2104706

Genau das ist ja das Problem wir wissen nichtmal warum der Kernel das macht...
Das mit dem Modem ist nicht das Problem, da hat Quarx schon einen "dirty" hotfix für geschrieben.
kexec scheitert allein daran, dass wir kein fastboot zur Verfügung haben (ich meine mich zu erinnern, dass es da vor einem Jahr schonmal eine Diskussion fürs Defy gab, kann mich aber irren).

@ch-world
schau dir mal das Commit von Quarx an, ohci ist deaktiviert

Ich glaube im 3er kümmert sich direkt USB Treiber um die Clocks und kein Subtreiber, aber da müsste ich auch mal schauen...
omap_start_ehc sieht nämlich wirklich interessant aus. Aber ich verfolge hier auch einen anderen Ansatz als Quarx (zumindest etwas). Vielleicht sollte ich den Stand von ehci-omap auf den gleichen bringen wie bei .32, aber das dauert, wenn ich da durch die gesamte Historie gehen muss

 

[Aslolo]

Mensch Aslolo, du nervst nicht
Du lieferst Sinnvolle Ansatzpunkte, ich kann da aber leider nicht mitreden, wie viele andere, aber das wissen sicher alle anderen auch zu schätzen

(Ich bleib lieber beim News posten )

Achso, schön das du dich auch mal wieder blicken lässt

Gesendet von meinem MB526 mit Tapatalk 2

Man kann ja nie wissen, es gibt immer jemanden
@Blechdose Kann man die Ursache nicht via Log feststellen?
Theoretisch müsste sich doch irgendwas melden, wenn es einen Fehler bemerkt, oder?
Oder startet der Log erst nachdem dieses Problem auftritt?

 

[ch-world]

Über Logs hatte ich auch schon nachgedacht. Der Auszug oben war aber bereits aus dem Kernel Log... Das kannst du auf den meisten Linux System mit dem Tool dmesg auslesen oder im entsprechenden Logfile.

Das Problem, wenn ich es richtig verstanden habe ist aber, dass der Kernel nicht merkt, dass irgendwo ein Fehler aufgetreten ist. Der Code sieht auch eher nach "soll funktionieren" aus. Schließlich fehlen auch sämtliche Kommentare seit Jahren...

@Blechdose ich vermute ihr habt die Funktionen schonmal mit printf bzw. printk aufgebläht um die Funktionsaufrufe zu protokollieren?

 

[Blechdose]

Ja haben wir, wenige Funktionen werden auch tatsächlich aufgerufen.
Das Problem ist, der Kernel setzt auf 12mb/s dadurch verliert Netmux die Verbindung,
anfangs läuft er aber mit 480 mb/s. Meine Idee war noch, dass etwas mit
suspend/resume nicht funktioniert aber selbst das wird nicht aufgerufen...

In den logs steht eben nur die Änderung, nicht aber was sie hervorruft.
Wenn ich Zeit finde und es erwünscht ist, kann ich mal ein komplettes dmesg-output posten.

 

[canplus]

Im Moment läufts wirklich perfekt. 3 Tage ganz ohne Ausfälle nach einer Quasi-Neuinstallation. Nachts mit Flugzeugmodus schaffe ich 89% Deep Sleep (gerade nach normaler Tagesnutzung 70%), der Akku hält ebenso lang (vielleicht minimal weniger) wie mit JBC 8.2.2 oder CyanMobile. Also ungefähr 40 Stunden mit durchschnittlicher Nutzung und ner knappen Stunde Gaming, immer entweder UMTS oder WLAN an. WiFi-Tether geht, Empfang ist dauerhaft da, und das WiFi-Störproblem mag vielleicht vorhandensein, aber nicht so, dass ich es bemerken würde. Kann es denn sein, dass ich da verschont wurde, oder ist es dann einfach so, dass die Störung bei mir nicht so stark ins Gewicht fällt?

 

[Aslolo]

Einfach mal total von Thema abgewichen
Welche Störung genau meinst du den?
@Blechdose und ch-world ist es möglich, erstmal einen REINEN Bootkernel zu schreiben, welcher auf dem 3.0er basiert, aber nur die allerwichtigsten Zeilen und funktionen enthält? Um praktisch ausschließen zu können, was die Fehlerursache ist.
Er muss ja nichtmal booten, sondern nur das Modem "richtig" ansprechen.
Ich denke mal das ist ne Menge Arbeit, deswegen würde ich helfen wo ich kann, falls es denn geht.
Oder wir finden eine Methode um die Problemursache zu finden.
Gibt es keine Möglichkeit einen kompletten Log (vllt mit externer Quelle) zu erstellen?
Wenn ich das richtig verstehe, dann hilft dieses dmesg nur bedingt, da es nur die Folgen, aber nicht die Ursache anzeigt.
MfG

 

[Blechdose]

Was meinst du mit reinem Bootkernel? Der Kernel bootet bereits und läuft auch.
3.0 hat an die 15 Millionen Zeilen Code, da ist nichts mit mal schnell umschreiben, nicht einmal wenn wir non-stop dran sitzen würden

Nein Spaß beiseite, das was du meinst sind Optimierungen, die kommen aber erst später (Treiber abschalten, die keiner brauch), wenn eben das andere läuft und das was nicht gebraucht wird, wird bereits schon gelöscht von Quarx (commits mit "cleanup" im Titel weisen darauf hin). Das ist quasi wie die Nadel im Heuhaufen, wo das Problem ist, ist schwer zu sagen..
Vor allem, da in der Anfangsphase die Geschwindigkeit stimmt.

Linux benötigt in der Hinsicht keine externen Quellen (Vorteil von Linux), abgesehen mal von adb. Die debug-messages sind schon sehr hilfreich ohne geht fast nichts (deswegen ist es auch sinnvoll immer logs zu posten). Für versierte CONFIG_USB_DEBUG ist bereits an.

Wie gesagt, meine Idee ist ehci-omap von 2.6.32 zu bringen, obs das bringt keine Ahnung, aufwändig ist es in jedem Fall..

 

[canplus]

Einfach mal total von Thema abgewichen
Welche Störung genau meinst du den?

Hehe, ne bitte lasst euch nicht stören, ein funktionierender 3er-Kernel würde mir auch gut schmecken.

Ich meine die Störungen von denen man hier (oder bei xda? weiß nicht mehr) im Zusammenhang mit 4.2.2 lesen konnte, dass das Defy-WiFi die Geschwindigkeit anderer Geräte im Netzwerk ausbremst. Jedesmal, wenn jetzt ein Video nicht zügig lädt, gucke ich natürlich misstrauisch Richtung Handy. Vielleicht hab ich mich da auch zu früh gefreut... gerade stockte ein Video schon wieder mehr, als es sollte. Aber könnte auch Paranoia sein, kommt schonmal vor. Wenn ich das ausschließen könnte, würde die ROM für mich vollkommen alltagstauglich sein. Und wohl ne Weile draufbleiben. Bis zur ersten Version mit Dreierkernel. So, Brücke zurückgeschlagen, jetzt dürft ihr wieder

 

[Fight4Music]

Quarx ist wieder am arbeiten


ce11140 USB: EHCI: fix timer bug affecting port resume
068d4e8 USB: EHCI: notify usbcore about port resumes
d8957c1 USB: add usb_hcd_{start,end}_port_resume.

Falls jemand damit was anfangen kann

Gesendet von meinem MB526 mit Tapatalk 2

 

[Blechdose]

Das sind commits, die ich ihm vorgeschlagen habe.... funktionieren aber auch nicht.

Btw. ich habe Quarx gesagt, dass das Problem vielleicht hier liegt:

if ((temp & PORT_OCC) && !ignore_oc){
			status |= USB_PORT_STAT_C_OVERCURRENT << 16;

			/*
			 * Hubs should disable port power on over-current.
			 * However, not all EHCI implementations do this
			 * automatically, even if they _do_ support per-port
			 * power switching; they're allowed to just limit the
			 * current.  khubd will turn the power back on.
			 */
			if ((temp & PORT_OC) && HCS_PPC(ehci->hcs_params)) {
				ehci_writel(ehci,
					temp & ~(PORT_RWC_BITS | PORT_POWER),
					status_reg);
				temp = ehci_readl(ehci, status_reg);
			}
		}

Aber die gesamte ehci_hub_control() Funktion habe ich bereits von .32 auf meinem Zweig portiert (drivers/usb/host/ehci-hub.c)...

 

[Akula_1980]

Ich habe mir die Build vom 15.4.2013 gestern aufgespielt als Neuinstall und muss sagen ich bin begeistert. KEINERLEI Verbindungsabbrüche oder Hänger, Abstürze ect.! Meiner Meinung nach die beste ROM die es fürs Defy+ neben der Stock Rom gibt. Ich hatte schon überlegt das Defy+ gegen ein anderes Modell auszutauschen. Aber dank der ROM bleibt Ihm das nun ersparrt.

Danke an alle Entwickler für die Tolle Arbeit die Ihr da vollbracht habt. Für mich ist die Rom so wie sie ist Alltags tauglich. Über die kleineren Bugs und Fehler kann ich locker drüber hinweg sehen.

LG Akula