[KERNEL][JB][JSS15J / JWR66V / CM] hells-Core b41 [28/11/2013]

[DickenAc]

Weil Hells es, gefühlte 30 Seiten zuvor angekündigt hatte

 

[black_bottom]

in meinem urlaub hatte ich ein CK von mitte oktober und den hells b39-CM im einsatz. nun wieder daheim wollte ich von 2 probs berichten:

1. google-camera (also die mit photosphere) im film-modus: die app stürzt ab beim filmen wenn ich dabei zoome. am ende (nach 2 etwa 15 sekunden) erfolgt die meldung das gallery geschllosen werden muss. danach kann man die app neu aufrufen.
2. bluetooth bringt das ganze smartphone für etwa 30 sekunden zum stillstand. wenn ich BT aus- und einschalte.

Der ursprüngliche Beitrag von 14:21 Uhr wurde um 14:36 Uhr ergänzt:

Mit dem vetzki-kernel treten die Probleme nicht auf.

 

[hellsgod]

Ich habe weder am BT noch am Kamera Code irgendwas gemacht. Von meiner Seite her daher ein dickes Fragezeichen. Sind diese Sachen für dich wichtig, wirst du vorerst wechseln müssen.

hells

Der ursprüngliche Beitrag von 14:49 Uhr wurde um 15:27 Uhr ergänzt:

Oder mal den readahead senken. Schon probiert?

 

[black_bottom]

Beim vetzki kernel ist der readahead laut trickser 128 (cfq). Wie liefert du seinen kernel aus?
Und ein zu hoher readahead ist die Ursache meiner beiden Probleme bei Nutzung deines kernel?

 

[TzGuf]

Ich glaube 1024 sind Stock.

 

[Daniel.Stevens]

Kann ich noch nicht mit Sicherheit sagen. Ich habe erstmal andere Ausgaben (Umzug usw.) somit kommts für mich in nächster Zeit nicht in Frage *

hells

(*hells auf die Frage ob er sich ein Nexus 5 kaufen wird...)

NNNNNEEEEEEEEEEEIIIIIIIIIIIIIIIIINNNNNNNNNNN !!!!

Dann verabschiede ich mich hier mal... War schön mit Euch und vor allem mit hells.
Vielen, VIELEN Dank für all die tollen Kernel, den super Support hier im Thread und die ganze Zeit die Du investierst... !!!!

Ich habe das N4 mit Deinem Kernel so genossen das ich nie gedacht habe "Ich habe ein Nexus 4" sondern eigentlich immer "Ich habe ein Nexus 4 MIT Hell´s Kernel" weil das so ein drastischer und wirklich unerreichter Unterschied ist ;0)

Sollte sich hells irgendwann einmal dazu bereit erklären bzw. Lust haben auch die Zeit/Nerven etc. in die Entwicklung für das Nexus 5 zu stecken möchte ich bitte von irgendjemandem informiert werden (hells ist ja zu bescheiden/nett/zurückhaltend das selbst zu tun) und halte hiermit schriftlich fest das ich mind. 10% der Anschaffungskosten eines Nexus 5 16GB übernehme bzw. falls er sich das Gerät selber kauft ihm diesen Betrag (mind.) spenden werde!

 

[c@p]

An einer Spende / Sammlung für ein Entwickler N5 für Hells würde ich mich auch sehr gerne beteiligen!

 

[Daniel.Stevens]

P.s.: Ich wollte mit dem Beitrag keine Diskussionen lostreten, bleibt hier bitte beim Topic... ;0)

Wenn hells allerdings sein o.k. gibt (also fürs Nexus 5 entwickeln WILL\KANN) würde ich gerne einen Spenden-Thread*** aufmachen in dem jeder einen festen Betrag "pledged".
Nicht so nach dem Motto "Ich würde ja auch spenden.." sondern wirklich "Ich spende! Und zwar so viel: ...."
So kann hells direkt absehen was ihn das ganze kosten würde (wenn dann für ihn überhaupt noch Kosten übrig bleiben) und die Spender behalten den Überblick...

***Danke @ MadMurdoc für den Hinweis (eins drunter): Dann erkläre ich mich eben bereit auf meiner eigenen Internetseite einen Eintrag vorzubereiten in dem die Leute sich eintragen können, ne Aktion bei Betterplace.org zu starten oder hier Spenden-Pledges per PN zu sammeln und zwischendurch irgendwo den Zwischenstand zu veröffentlichen... (aber nur wenn hells sein o.k. gibt)

(P.p.s.: Und nicht das mich jemand in nem halben Jahr anschreibt: "Der hells will sich jetzt n N5 kaufen, hau mal Kohle raus..." *lol* Da hab ich schon halb wieder n anderes Handy ;0))

 

[MadMurdoc]

Spenden Threads werden nicht akzeptiert.

 

[vetzki]

Ich glaube 1024 sind Stock.

max 128 / min 16 sind stock.

 

[bugz]

Was hast du alles im Hintergrund laufen? Allein deine Benachrichtigungsleiste hat 3 apps die dauerhaft laufen?

Ja, die laufen dauerhaft. Sind eigentlich nur 2 App (LBE + Trillian)

Der ursprüngliche Beitrag von 10:55 Uhr wurde um 10:55 Uhr ergänzt:

Schraub mal nicht auf 1ghz runter.

hells

Dann ist es noch schneller leer!

Der ursprüngliche Beitrag von 10:55 Uhr wurde um 10:56 Uhr ergänzt:

Ohne von BBS den Alarms Reiter zu wissen können wir da raten bis wir schwarz finden und bekommen keine Lösung zusammen..ich vermute mal das da irgend ein Wakelog Amok läuft.

Alarms Reiter ist leer!

 

[MadMurdoc]

Das kann ja nicht sein, der Kernel lässt ja zu das alles ausgelesen wird und irgendeine App macht immer Alarm.

 

[MyBega]

Vllt einfach mal einen Tag ohne Trillian versuchen. Kann mir gut vorstellen das die App tierisch am Akku saugt.

 

[black_bottom]

Readaheadbuffer: was gilt da nun beim hells kernel? Beim vetzki kernel sind es 128.

@vetzki: mein post 6253 eine Seite zurück: warum treten die von mir beschriebenen Probleme bei deinem kernel nicht auf? Kannst du dir das erklären? Merci für Hinweise. Rainer

 

[vetzki]

so ganz spontan würde ich eher aufs uv tippen, denke eher nicht das am readahead cache liegt (du könntest ja testweise bei hells mal auf 128 setzen). Kannst du nicht evtl. zum Zeitpunkt wenn die Probleme auftreten ein log mit logcat machen und kmsg (nicht last_kmsg). Am besten an pc hängen log starten (adb logcat bzw. adb shell cat /proc/kmsg) und Problem provozieren vll. sieht man was.

sonst
readahed bei hells: 1024
beim "stock" kernel: 128

 

[Hansi Hinterseer]

Vllt einfach mal einen Tag ohne Trillian versuchen. Kann mir gut vorstellen das die App tierisch am Akku saugt.

Ne, trillian funktioniert per Push, die App zieht annähernd nichts.

 

[hellsgod]

Dann ist es noch schneller leer!

Das ist nicht korrekt. Da wäre die ganze Theorie mit Race to Idle völliger quatsch, was es definitiv nicht ist. Je nach Nutzungsverhalten kann ein höherer Takt einen Task schneller beenden und kann somit schneller wieder in einen Energiesparzustand. Mitunter können z.B. 2 Sekunden auf 1.5ghz weniger Verbrauchen als 3 Sekunden auf 1ghz. Damit wäre das runtertakten kontraproduktiv.

hells

 

[hellsgod]

Zum Thema Spenden möchte ich kurz etwas anmerken: Ich fühle mich geehrt, dass ihr eine Spenden Aktion erwähnt habt, doch weiss ich nicht, ob das der richtige Weg ist. Natürlich, ich investiere viel Zeit in dieses Projekt, ich verwende jedoch hauptsächlich Code von anderen. Ich sehe mich daher auch nicht als Kernel Dev, sondern als Koch. Wer mir etwas Spenden möchte, der kann das über den Link in meiner Signatur tun. Einen Spendenaufruf braucht es dafür aber nicht, danke euch

Achja, wer Lust zu testen hat, die -t4 ist im Test Ordner b41 basiert auf b39 mit ein paar Commits von b40 + ein paar neue Sachen:

Wheatley mit Touch Boost
Neue Modul Parameter für den msm_hotplug: "Add options for number of min/max/boost cpus"
Upstream auf 3.4.68
ext4 patches
RCU Boost
Zen IO Scheduler (standard zum testen)

dev-host

hells

 

[Caho]

Deine Bescheidenheit ehrt Dich!

 

[bugz]

Das ist nicht korrekt. Da wäre die ganze Theorie mit Race to Idle völliger quatsch, was es definitiv nicht ist. Je nach Nutzungsverhalten kann ein höherer Takt einen Task schneller beenden und kann somit schneller wieder in einen Energiesparzustand. Mitunter können z.B. 2 Sekunden auf 1.5ghz weniger Verbrauchen als 3 Sekunden auf 1ghz. Damit wäre das runtertakten kontraproduktiv.

hells

Probiere ich mal aus... Habe nun auch Alarms für BBS aktiviert, standardmäßig ausgeschalten, daher war da auch leer.