[Kernel]Atrix-GB,CM7[2.6.32.56](Unified v024)OC~1.45GHz/UV/SLQB/BFQ [04 Fev]

[Spyder-ferrari]

[ GINGERBREAD (2.3.4/5/6) Kernel 2.6.32.56]

CWM File ==> Unified GB Kernel Version 024 @ 1.45 GHz

CWM File ==> Unified GB Kernel Version 024 @ 1.3 GHz

CWM File ==> Unified GB Kernel Version 024 @ 1.0 GHz

[ CYANOGENMOD 7 Kernel 2.6.32.56 ]

CWM File ==> Unified CM7 Kernel Version 024 @ 1.45 GHz

CWM File ==> Unified CM7 Kernel Version 024 @ 1.3 GHz

CWM File ==> Unified CM7 Kernel Version 024 @ 1.0 GHz

[ Installation: ]

[ CWM Method ]

1. reboot to CWM

2. Clear cache

3. install zip from SDcard

4. Reboot

Changelog - Version 024

switched to fast NoHz tree RCU

Completely rebuilt from scratch based on ATT 4591 baseline

Both Stock and Cyanogen now share the same baseline code base

Patched to latest kernel.org 2.6.32.56

Fixed some warnings during compilation

enabled NETFILTER_XT_MATCH_MAC (for wifi tethering app users)

arm/vfp: vfp_pm_suspend: Use local variable instead of rereading from register

ARM: vfp: clear fpscr length and stride bits on entry to sig handler

ARM: vfp: move user vfp state save/restore code out of signal.c

ARM: vfp: flush thread hwstate before restoring context from sigframe

crc32: Don't reference unnecessary crc32 tables in single-bit mode

ARM: proc-v7.S: remove HARVARD_CACHE preprocessor guards

ARM: net: JIT compiler for packet filters enabled by default

ARM: net: JIT compiler for packet filters

include/filter.h: add missing rcu_types.h for kernel usage

ARM: hwcaps: add new HWCAP defines for ARMv7-A

ARM: hwcaps: use shifts instead of hardcoded constants

mmc: fix deadlock from mmc core when suspend the device

mmc: change mmc_delay() to use usleep_range()

nohz: Remove ts->inidle checks before restarting the tick

Modifié 5 février 2012 par Spyder-ferrari

[Shirosagi]

Miam.

Merci bien pour ce superbe réveil...

[foxxy]

Quest-ce-qu'ils rapportent de plus ces kernels à part l'overclock?

Essayé mais ça me met failed to boot 2 à chaque fois donc obligé de reflasher avec un sbf sur rsd lite !

Modifié 5 février 2012 par foxxy

[Shirosagi]

Tu as déverrouillé ton BL ou pas? Quel recovery?

Comment tu fais???

Téléchargement + Transfert sur SD + Reboot en recovery + Flash + Wipe Cache/Dalvik + Reboot ça m'as prit quoi....

trois minutes max...

[N'oliv]

Ouaip, mais quels sont les réels avantages ?

L'overclock donne-t-il un gain de performances ? Sans plantage ?

Mes dernières expériences (sur mon ancien mobile) n'étaient pas concluantes, surtout en ce qui concernait la stabilité et l'autonomie

Modifié 5 février 2012 par Noliv

[foxxy]

Est-ce-que ces kernel sont compatibles avec une version retail fr ?

[Shirosagi]

Lis ma signature.

[foxxy]

Effectivement :)

Les kernel OC consoment-ils beaucoup de batterie en plus ou pas tant que ça? Et celui qui est juste optimisé mais qui reste à 1Gh, je suppose qu'il pompe moins que les autres.

Modifié 8 février 2012 par foxxy

[N'oliv]

J'hesite à passer sur un Kernel Overclocké : histoire de profiter un peu mieux de mon Lapdock.

Un conseil serait bienvenu, du moins des retours des utilisateur.

[Delewer]

Comme l'a dit Foxxy, le kernel de 1Ghz cossomme moins que celui OC.

Cela dis, le Lapdock est alimenté, donc il suffit de mettre un profil dans Setcpu pour OC totalement son kernel quand le telephone est branché, et de limitter la vitesse maximum quand il est debranché.

Le seul inconveniant du kernel OC, est que l'on peut "beaucoup" moins l'undervolter", c'est à dire diminuer la tension d'alimentation du processeur, pour qu'il consomme moins... Et comme ce n'est pas une science exacte, cela differe d'un téléphone à l'autre.

Si tu n'a jamais UV ton processeur, tu devrais y gagner, sinon, tu y perdra plus que tu n'y gagnera en dehors de l'usage de ton Lapdock.

[foxxy]

Moi j'arrive pas à bien maitriser les UV (de combien baisser et à quel pallier) et ainsi l'UV permettrait-il de consommer encore moins de batterie?

[Delewer]

Oui en effet, c'est le principe même. On "undervolt" jusqu'a instabilité du système. On a alors la limitte basse, et on remonte un peu.. On a alors l'UV le plus stable et le plus économe en energie.

Il faut le faire pour chaque palier de fréquence. Par exemple, en mettant, sur Setcpu, le fréquence basse et haute à la même valeur, et en laissant tourner tout ça une demi journée, puis en lançant Quadrant 3 ou 4 fois (ou en lançant un jeu en 3D)

Dès que l'UV est validé pour cette fréquence, on recommence pour le frequance suivante.

A la fin, on a la tension optimum (minimum plutôt) pour chaque fréquence.

Voilà le principe.

On y arrive aussi en tattonant, mais on galère toujours sur une ou deux fréquence en général.

La tension la plus importante, c'est celle qui sera attribuée à la fréquence "écran éteind" (à regler dans Setcpu)

C'est là où on va vraiment économiser.

[DNAngel]

Est ce que setcpu va regler tout ca lui meme ou il faut le configurer? Sur le forum du X10, il y avait des tuto pour les profils setcpu mais ici je ne trouve rien

[Delewer]

Non, il faut configurer soit même. Et pour compliquer le tout, il y a des régles à suivre... de palier de tension.

Tout les Kernels ne permettent pas le réglage en plus.

Pour le Kernel de Faux, ou de Clemsyn, ça marche pas mal

Regarde ici : http://forum.xda-developers.com/showpost.php?p=22237661&postcount=6

Le type a reglé les tensions (colonne à gauche en blanc), de 925mv à 400mv, soit, sans jamais dépasser un palier de 100mv

Si jamais il avait mis, pour le 312Mhz, une tension à -300mv, la tension à cette vitesse serait revenu à celle par défaut, car on aurait dépassé le palier de 100mv (on aurait eu 775mv au lieu des 475mv désirée).

Ca à l'air compliqué, mais on prend le coup.

[DNAngel]

Merci. Je regarde tout ca demain au boulot

[Shirosagi]

Bon. Je reviens ici faire un rapport après presque 20 jours d'utilisation de ce kernel 0.2.4...

Je ne sais pas ce qu'il donne pour les autres mais moi j'ai décidé de repasser à la version 0.2.3.

J'ai eu droit à un peu de tout: reboot en étant branché en usb, problème de localisation GPS, perte de signal réseau, et surtout ce qui m'a vraiment décidé à revenir en arrière, à savoir une autonomie vraiment exécrable. 8h tout juste en normal alors qu'à utilisation équivalente je tenais le double avec le kernel précédant.

Bref, je passerais sans doute à la 0.2.5 pour voir si c'est mieux, mais cette version 0.2.4 ça sera sans moi...

[DNAngel]

J'ai testé la baisse de tension. Sauf que j'ai pris le kernel a 1,3Ghz donc les voltages sur xda ne passent pas. J'ai eu droit a un freeze et reboot obligé. Du coup Shiro, tu fait comment? Tu pourrais faire un petit tuto pour noob comme moi?

[Xkz]

J'ai testé la baisse de tension. Sauf que j'ai pris le kernel a 1,3Ghz donc les voltages sur xda ne passent pas. J'ai eu droit a un freeze et reboot obligé. Du coup Shiro, tu fait comment? Tu pourrais faire un petit tuto pour noob comme moi?

C'est en fonction de ton téléphone après, une tension qui marchera pour toi ne marchera pas forcément pour un autre.

Quelles étaient tes réductions en mV pour chaque pas ?

[Shirosagi]

Sur la baisse de tension?

Plus simple, c'est de faire par palier de 25mV en "bloquant" la fréquence...

Dès que ton Atrix devient instable (freeze ou reboot), il faut remonter de 25mV.

Il faut refaire la même chose à toutes les fréquences.

Pour ma part, j'ai 7 fréquences à régler: 1,45GHz, 1,30GHz, 1,20GHz, 1GHz, 800MHz, 456MHz, 216MHz.

En tout cas, pour chaque Atrix ce sera différent...Donc c'est pas étonnant que les valeurs que tu as trouvé sur xda ne fonctionnent pas sur le tien.

[Xkz]

Pour chaque freq max ou freq min, tu aura toujours 7 pas avec le kernel de faux123 (ou même celui de Clemsyn d'ailleurs).

[DNAngel]

Bon ben pour l'instant j'ai baissé de 50 pour chaque palier. Le system est parfaitement stable (juste 1 reboot depuis qu'il est installé mais je pense que ce soit lié aux tensions). J'ai testé tout ca avec stability test sur le market.

Pour l'autonomie, elle est tres bonne. Je tiens plus de 30 heures a l'aise en usage normal : un peu de net, une 20aine de minutes d'appel, des sms.

Pour les voltages, je passe de 1300 mV pour 1300 MHz a 700 mV pour 216 MHz. Par contre j'ai reglé des profils avec setcpu ou le proc est bridé a partir de 30% de batterie (max 1000 MHz) et très bridé a 20% (max 800 MHZ). Il est aussi bridé a 800 MHz pendant les appels. Du coup j'economise pas mal de batterie sans perdre en réactivité.

Je n'ai pas encore testé de tensions plus basses mais si quelqu'un a testé, ca m'interesserais, je me lancerais aussi du coup.

[N'oliv]

CWM File ==> Unified GB Kernel Version 024 @ 1.45 GHz

Bon allez je me lance, je teste celui-ci. Je verrais à l'usage et ne manquerais pas de vous donner mes impressions, plantages, et surtout retombées qui seront positives... :D j'espère.

Sachant que je tourne avec la Motorola Retail 2.3.4...

Retour d'infos après quelques jours d'utilisation :

• Stable : aucun reboot constaté
  
• Consomme de la batterie : je trouve l'autonomie moins bonne qu'avec le Kernel Stock, malgrès le Downclocking à 1000 Mhz et l'utilisation à 1450 hz uniquement lors de l'utlisation du Lapdock
  

En gros rien de plus, rien de moins... Si ce n'est un lapdock plus réactif....

Modifié 26 mars 2012 par Noliv

[kyusu]

Jai tester la version 1ghz_24 pour la cyano7 ca consomme bcp de batterie alors que le tél est en veille.

1ghz_23 est plus autonome .

Quelqu'un d'autres a remarquer ceci ?

[Xkz]

Oui. faux123 devrait sous peu upload ces nouveaux kernels, il est en train de le faire actuellement pour plusieurs autres modèles. (En espérant que le tethering et la gestion du scaling par gouverneurs soit possible)

[kyusu]

tethering c'est bien le fait d'envoyer le net du telephone vers le pc via une cable usb ? Chez moi ca marche deja ca.

Oui sur le defy quand on mets le gouverneur en ondemand c'est moins econome en batterie que interactive.