[KERNEL][UNIFIED] SiyahKernel v2.6.14

Ja ich verwende den JD,weil oft epmfohlen wurden ist ......

Nun werde ich deinstallieren.Jedoch ist es so das ich diese probleme nur mit den Kernel bekomme , bei CF kernel habe ich nicht solche probleme.

Cbeckstein , danke dir trotzdem für die nette infos

1.8rc1 ist raus.

Zitat von Rintenfinten

1.8rc1 ist raus.

Details dazu siehe Post 281

Interessante Diskussion, die sich da gerade anläßlich der Interaktion eines C++ Profis und des Kernelauthors Gohkan auf dem XDA-Thread zum Siyah ergiebt:

Frage eines (dritten) Siyah Users:

TL;DR: GPU voltages min: 900mV up to 1200mV in 50mV steps, CPU voltages min: 650mV up to an amazing 2225mV in 25mV steps, charger current from some value I don't remember up to 950mA in 50mA steps.


does this mean that the min gpu voltage is set at 900mv? in the scripts provided here shows 500mV

# CLOCK INFO:
# 100 114 133 160 200 267 400 are valid values
# 160 267 are default
# VOLTAGE INFO:
# 500000 min / 1200000 max
# 950000 1000000


so which is which? i really dun want another placebo effect..


Antwort des C++ Profis (mit Quellstellen aus dem Samsung Kernel belegt):


At the beginning we didn't know of the hard-limit on voltage and really thought it would work but then I got suspicious because all voltages worked. The script is no longer up to date, well at least those min values are not.

Right now Gokhan set up a minimum voltage in the GPU interface to 900mV because there's a lot of people who have the scripts set to voltages of around 800mV, as they thought it would really work and it's stable but it's not. Because now that hard limit has been fixed, there's a very high probability when people flash the kernel where the limit will be removed, that it will crash a lot of devices since they will really get that voltage, and it will be unstable. Also note: Everybody who undervolted with Tegrak under 900mV was also all just placebo since the hardlimit was not changed.

For now it is recommended that *EVERYBODY* raises the minimum voltages up to at least 900mV in their scripts to avoid this problem.


Natürlich wird schon an einem Fix gearbeitet...


Aber trotzdem: wenn das kein ungewollter Schlag in das Gesicht eines jeden hoffnungsvollen UV-lers ist )

hehe... Lass sie doch die ganzen Werte testen und Stresstests machen. "Meiner freezt bei 850" "Ich bin bei 800 stabil"... und alles nur Illusion. Find ich gut. Danke für den Beitrag!
LG SGSII

Also Leute, in dem Siyah XDA-Thread geht es momentan wirklich ab:

wer einigermassen C(++) kann, kann da was lernen

da debuggen gerade zwei C Profis gemeinsam mit Gohkan die Kernelquellen...

grosses Kino mit Kernelquellen als Drehbuch und damit eher ungewöhnlich selbst für einen Entwicklerthread auf XDA

sag ich doch schon immer das uv nix bringt

Und während die zwei C Profis im Siyah XDA Thread die neu entdeckten bugs (zum Teil aus den Samsung Quellen) noch mit Gohkan ausdiskutieren, hat der im Hintergrund schon mal den Backofen für den nächsten Release Candidate rc2 vorgeheizt:

CHANGELOG

SiyahKernel v1.8rc2
based on linux kernel 2.6.35.14 + SGS2 drivers
changed compiler optimizations
new cpu governor lagfree. based on conservative. screen off 100-200, screen on min 500. it is not laggy but may be buggy.
deadline I/O scheduler tweak (thanks to arighi). deadline is set to default.
enabled some logging features for debugging purposes.
no more AOS bug...
brazillianwax and savagedzen governors (test them. they may crash or be your favorite governors)
lots of bugfixes and code cleanups...
lowered min GPU voltage to 800mV and max AC&MISC current to 950mV
CFS low-latency patch removed.
touch screen lock freq set back to 500MHz as in stock (thanks to AndreiLux)
added advanced touch tune driver (thanks to tegrak)
updated su to 3.0.4
changed rooting script. if you delete /data/.siyah/root-installed root will be installed again even if you already have su or Superuser.apk
updated CWM recovery to 5.0.2.3 because of an increasing demand... if we don't test it it won't get better

das nenne ich mal eine furiose Kernel-Entwickung...

@Spline: man beachte auch die Erweiterung des Kernels bzgl. des neuen Tegrak Touch Tune Drivers!

Davon profitieren jetzt nicht nur die Lulzer sondern auch die Siyahner...

Was bringt denn der touch tune driver?

Zitat von blubb12

Was bringt denn der touch tune driver?

siehe hier: http://forum.xda-developers.com/show....php?t=1161262

und hier:

(wenn das Verlinken von Videos heir verboten ist, dann streue ich schon mal jetzt Asche auf mein Haupt)

sowie hier: https://market.android.com/details?i...grak.touchmove

der kernel von dem MIUI geht nur bei dem rom oder? http://forums.miuiandroid.com/showth...ontrol-sysfs-8
weil die jungs wo da mitdiskutieren sind ja von dort wie ich das lese auf xda

Noch ein cooles Zitat aus dem Siyah Kernel Thread:

"For some really odd reason , Ive noticed that SetCPU tends to consume more battery than save with undervolting . Maybe some wakelocks.
I've always noticed better battery life without SetCPU than with .
Strange things happen. And I hate ironies."

die stehen dort deshalb mittlerweile auf den oc daemon plus init.d Skripte...

Also wenn der kernel Fertig wird , sprich stable , wird ein hammer Kernel.Respekt von so eine leistung !!

Zitat von cbeckstein

Noch ein cooles Zitat aus dem Siyah Kernel:

"For some really odd reason , Ive noticed that SetCPU tends to consume more battery than save with undervolting . Maybe some wakelocks.
I've always noticed better battery life without SetCPU than with .
Strange things happen. And I hate ironies."

die stehen dort deshalb mittlerweile auf den oc daemon plus init.d Skripte...

genau das hab ich grad auch gelesen und sofort setcpu deinstallt

das OC daemon hab ich schon mal bei leomar probiert... aber schien ziemlich heavy das ganze :-/

Zitat von diddsen

genau das hab ich grad auch gelesen und sofort setcpu deinstallt

das OC daemon hab ich schon mal bei leomar probiert... aber schien ziemlich heavy das ganze :-/

muss gar nicht heavy sein:

besorge Dir die kitchen Pro app von hier:

http://forum.xda-developers.com/show....php?t=1171523

installiere sie, reboot, starte die kitchen app pro, wähle unter den mods den oc daemon aus und lass den nstallieren (zur Installation markieren und dann die Installation anwenden lassen), reboot und (fast) fertig:

jetzt ist der Daemon samt Daemon Controller App installiert und bereit, Dir alle Deine OC/UC Wünsche zu erfüllen...

jo, die kitchen hab ich immer drauf
momentan zwar sinnlos, da nicht für ki8 bislang, aber egal...

ja ja, drauf ist das "ding" schnell, aber dann gehts ja erst richtig los... was ist wie wo einzustellen damit es was bringt

Zitat von diddsen

jo, die kitchen hab ich immer drauf
momentan zwar sinnlos, da nicht für ki8 bislang, aber egal...

ja ja, drauf ist das "ding" schnell, aber dann gehts ja erst richtig los... was ist wie wo einzustellen damit es was bringt

wenn Du bescheiden (wie ich ) bist, dann beschränkst Du Dich fürs erste einfach darauf, im Daemon Controller folgendes einzustellen:

target daemon = virtuous oc
wake settings:
min = 100000
max = 1200000
governor=ondemand
sleep state settings:
min = 100000
max = 500000
governor = conservative

und dann apply

alleine schon damit erreiche ich (verglichen mit ohne) auf dem Siyah Kernel traumhafte Batteriezeiten (trotz heftiger Nutzung)

wenn Du oc daemon verwendest, solltest Du halt immer governor wählen, die ncht selber zustandsabhängig die Frequenzgrenzen ändern (wie das z.B. die ganzen ......X governor im Siyah tun oder der SmartassV2), eben z.B. den ondemand und den conservative ---
und natürlich keine anderen Tuningtools (wie SETCPU, no-frills, voltage control etc.) parallel installieren oder gar betreiben (wenn der oc das merkt, ist er beleidigt und deaktiviert er sich)

Details zu den governern und schedulern findest Du unter
http://forum.xda-developers.com/show....php?t=1242323

wie ich sehe kennst du dich auch damit aus

so wie du gerade die einstellungen beschrieben hast, hab ich mal "aus dem bauch raus" auch gedacht.
was ist der andrev oc??
und was hat es mit "Bypass" aufsich... (den brauch ich bald, wenns so weitergeht *ggg*)
es kam auch beim start des daemon kurz mal ne meldung das der cupfeq irgendwie nicht unterstützt werde (glaub ich stand da)...?!

das mit den ganzen smartass & co hab ich mir schon lange gedacht... das widerspricht sich doch irgendwie alles, denn setcpu versucht ja ständig dem geönse von den governors entegenzuwirken oder zumindest steigert es doch einiges das "hin und her geschalte" der frequenzen.

und wo ist in dem daemon dann UV? ... ach ja, braucht man ja nicht, bringt ja nix *g*

was benutzt du noch ausser den deamon cbeckstein? den Fill für die scheduler?

Zitat von diddsen

wie ich sehe kennst du dich auch damit aus

so wie du gerade die einstellungen beschrieben hast, hab ich mal "aus dem bauch raus" auch gedacht.
was ist der andrev oc??
und was hat es mit "Bypass" aufsich... (den brauch ich bald, wenns so weitergeht *ggg*)
es kam auch beim start des daemon kurz mal ne meldung das der cupfeq irgendwie nicht unterstützt werde (glaub ich stand da)...?!

das mit den ganzen smartass & co hab ich mir schon lange gedacht... das widerspricht sich doch irgendwie alles, denn setcpu versucht ja ständig dem geönse von den governors entegenzuwirken oder zumindest steigert es doch einiges das "hin und her geschalte" der frequenzen.

und wo ist in dem daemon dann UV? ... ach ja, braucht man ja nicht, bringt ja nix *g*

was den andrev oc angeht, siehe hier: http://forum.xda-developers.com/show...222020&page=21

mit bypass kannste den oc daemon vorübergehend deaktivieren --- z.B., weil Du mit einem andern Tuning Tool was einstellen und keine Querschläge vom oc daemon haben willst...

dass an anderen Stellen nicht daraufhingewiesen wird, wie unsinnig es ist, sich zwei gegenseitig behindernde Tuningmassnahmen wie SETCPU + selbst das Frequenzverhalten ändernde Governors auf das Handy zu packen, hat mich auch verwundert

OC/UC macht nur Sinn, wenn man es mit einem Governor tut, der nicht die Frequenzgrenzen (max und min) zwischen denen er herumschaltet selbstständig verändert; andernfalls richtet es mehr Schaden an als es bringt (und SETCPU läuft auch noch ständig ressourcenfressend im Hintergrund)

Undervolten oder den I/O Scheduler ändern kannst Du bei einem kernel wie dem Siyah, der init.d-Skripte beherrscht, eben mit solchen Skripten, z.B. stellt das folgende Skript den Scheduler auf sio um:

#!/system/bin/sh
#setting scheduler
echo sio > /sys/block/mmcblk0/queue/scheduler

wenn man es als root ausführt (z.B. automatisierbar mit der App Gscript)

und das folgende Skript von ienem der Hacker aus dem Siyah Thread zeigt Dir die momentane Konfiguration Deines Handys in Bezug auf OC/UC von CPU und GPU, governor und Ladeströme an:

#!/system/bin/sh
#Checking Stuff to see if init-scripts work as intended
echo "--[Kernel]--"
echo $(uname -r)
echo "--[Voltages]--"
cat /sys/devices/system/cpu/cpu0/cpufreq/UV_mV_table
echo "--[Max Freqency]--"
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
echo "--[Min Freqency]--"
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
echo "--[Active Governor]--"
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo "--[IO scheduler]--"
cat /sys/block/mmcblk0/queue/scheduler
echo "--[GPU Voltages]--"
cat /sys/devices/virtual/misc/gpu_voltage_control/gpu_control
echo "--[GPU Freqencies]--"
cat /sys/devices/virtual/misc/gpu_clock_control/gpu_control
echo "[charging current]"
cat sys/devices/virtual/misc/charge_current/charge_current

Aber bei Skripten immer schön aufpassen, dass die Zeilen Enden nach der Unix-Konvention haben, sonst bekommt Du bei der Ausführung die merkwürdigsten Fehlermeldungen vom Kernel und der Shell