[KERNEL][3.4.x][KK] K^Kernel 3.4.x per KitKat ION+PMEM ADSP

[navax]

Il problema è causato dalle Gapps. Il pacchetto è troppo grande, la partizione di sistema è quasi piena e non c'è spazio per i moduli del kernel.
Prova a cancellare delle app di sistema inutili oppure a riflashare rom e un pacchetto di gapps più piccolo.

risolto erano le gapps

[Christopher83]

Ciao a tutti,
ho rilasciato le nuove build del kernel v2.4:

- Kernel 3.4.94
- Built with my latest custom Linaro 4.9.1-2014.06 toolchain optimized for Cortex-A8
- msm: rpc: add shutdown and restart handler for rpc (credits to Angshuman Sarkar)
- msm: rpc: add shutdown and restart handler for rpc (credits to Arun Kumar Neelakantam)
- msm: restart_7k: Disable local IRQ interrupt (credits to Tirupathi Reddy)
- msm7x30: Disable unsupported features (credits to Blefish)
- misc: pmem: Add support for CMA (credits to Blefish)
- msm7x30: Use CMA for PMEM ADSP (credits to Christopher83 and Blefish)
- New memory configurations with 396MB, 406MB or 416MB of free RAM and everything
  should be working, including camera, camcorder and video playback (credits to Christopher83)

Nota:
Ora la memoria destinata allo heap PMEM ADSP (quello usato dalla fotocamera e camcorder) è dinamicamente allocata attraverso il framework CMA, così la quantità di memoria, pari a 26MB, precedentemente riservata è riutilizzabile quando la fotocamera non viene usata.
Le nuove configurazioni di memoria dovrebbero avere, anche per questo device, fotocamera, camcorder (registrazione a 480p e 720p) e video playback funzionanti.
Un ringraziamento a Blefish per il suo lavoro!

[Redwraith]

La versione con 416 Mb o che comunque supera i 408 Mb ha detto hurtsky che produce un errore nella gelloc allocation,esiste qualche rischio a proposito?

[IlPessimoFra]

La versione con 416 Mb o che comunque supera i 408 Mb ha detto hurtsky che produce un errore nella gelloc allocation,esiste qualche rischio a proposito?

416?? Una volta erano 340!

[Christopher83]

La versione con 416 Mb o che comunque supera i 408 Mb ha detto hurtsky che produce un errore nella gelloc allocation,esiste qualche rischio a proposito?

Inanzitutto gli errori "gelloc allocation" non esistono, non so a cosa si stia riferendo, forse il genalloc, ma non ho mai visto errori provenienti da quel modulo.
Tutti i kernel highmem, ad esclusione di quello stock (quello che ora ha 396MB), hanno una allocazione ION riservata al surfaceflinger/stagefright (si occupa di comporre i vari layer grafici da inviare poi al framebuffer per la visualizzazione sullo schermo) ridotta di qualche MB (da 8MB a 18MB, in base alla configurazione scelta) per lasciare maggiore memoria libera, diciamo che è un'escamotage per ovviare alla poca memoria disponibile sui nostri device.
Questa riduzione comporta, nelle circostanze in cui ci siano vari layer da visualizzare, l'uso dello heap di sistema piuttosto che lo heap riservato al surface flinger, poichè lo spazio riservato a volte non è sufficiente. Lo switch dallo heap ION dedicato al surfaceflinger, allo heap ION di sistema, avviene automaticamente ed in maniera trasparente per l'utente. Lato logcat viene riportato il messaggio che indica appunto "non riesco ad allocare tutta la memoria nello heap dedicato, uso lo heap di sistema". Ciò non comporta alcun degrado di prestazioni (il sistema è comunque fluido nell'aprire le app e nelle animazioni di transizione), lo switch dallo heap dedicato a quello di sistema è molto veloce, e ci consente di tenere libera della memoria nel caso in cui non serva al surfaceflinger.

Preferisco non commentare i post di questo tipo, come non avevo commentato il post in cui sirmordred diceva che aveva dimezzato il voltaggio dello schermo...

Era da un po' che meditavo di rilasciare il K^Kernel anche per gli utenti del Galaxy W, anche se ci ho messo più di un anno e mezzo per decidermi visto il poco tempo a disposizione. Probabilmente ora, gli utenti che hanno creato dei kernel nella vostra sezione, pur basandosi sui miei sorgenti e integrando man mano le varie modifiche che vi apporto, vogliono cercare di differenziare almeno un po' il proprio kernel dal mio, anche perchè, effettivamente, non avrebbe molto senso avere più kernel completamente uguali... Ciò non è affatto una brutta cosa, è una sorta di sfida a chi fa qualcosa di migliore e più innovativo, mantenendo anche la comunità di utenti attiva, ma l'importante è che facciano le cose con giudizio e non a caso, documentandosi almeno un po', cercando di verificare le modifiche che fanno, piuttosto che rischiare potenzialmente di rovinare il cellulare.

[Redwraith]

Inanzitutto gli errori "gelloc allocation" non esistono, non so a cosa si stia riferendo, forse il genalloc, ma non ho mai visto errori provenienti da quel modulo.
Tutti i kernel highmem, ad esclusione di quello stock (quello che ora ha 396MB), hanno una allocazione ION riservata al surfaceflinger/stagefright (si occupa di comporre i vari layer grafici da inviare poi al framebuffer per la visualizzazione sullo schermo) ridotta di qualche MB (da 8MB a 18MB, in base alla configurazione scelta) per lasciare maggiore memoria libera, diciamo che è un'escamotage per ovviare alla poca memoria disponibile sui nostri device.
Questa riduzione comporta, nelle circostanze in cui ci siano vari layer da visualizzare, l'uso dello heap di sistema piuttosto che lo heap riservato al surface flinger, poichè lo spazio riservato a volte non è sufficiente. Lo switch dallo heap ION dedicato al surfaceflinger, allo heap ION di sistema, avviene automaticamente ed in maniera trasparente per l'utente. Lato logcat viene riportato il messaggio che indica appunto "non riesco ad allocare tutta la memoria nello heap dedicato, uso lo heap di sistema". Ciò non comporta alcun degrado di prestazioni (il sistema è comunque fluido nell'aprire le app e nelle animazioni di transizione), lo switch dallo heap dedicato a quello di sistema è molto veloce, e ci consente di tenere libera della memoria nel caso in cui non serva al surfaceflinger.

Preferisco non commentare i post di questo tipo, come non avevo commentato il post in cui sirmordred diceva che aveva dimezzato il voltaggio dello schermo...

Era da un po' che meditavo di rilasciare il K^Kernel anche per gli utenti del Galaxy W, anche se ci ho messo più di un anno e mezzo per decidermi visto il poco tempo a disposizione. Probabilmente ora, gli utenti che hanno creato dei kernel nella vostra sezione, pur basandosi sui miei sorgenti e integrando man mano le varie modifiche che vi apporto, vogliono cercare di differenziare almeno un po' il proprio kernel dal mio, anche perchè, effettivamente, non avrebbe molto senso avere più kernel completamente uguali... Ciò non è affatto una brutta cosa, è una sorta di sfida a chi fa qualcosa di migliore e più innovativo, mantenendo anche la comunità di utenti attiva, ma l'importante è che facciano le cose con giudizio e non a caso, documentandosi almeno un po', cercando di verificare le modifiche che fanno, piuttosto che rischiare potenzialmente di rovinare il cellulare.

Ok ora capisco,grazie per il chiarimento tecnico Christopher83 e ora forse ho capito perchè ho dovuto mandare in assistenza il telefono per due volte sempre perchè si era bruciata la scheda madre,da ora in poi installerò solo il tuo kernel oppure se devo installarne altri valuterò meglio i cambiamenti che hanno fatto.

[IlPessimoFra]

Inanzitutto gli errori "gelloc allocation" non esistono, non so a cosa si stia riferendo, forse il genalloc, ma non ho mai visto errori provenienti da quel modulo.
Tutti i kernel highmem, ad esclusione di quello stock (quello che ora ha 396MB), hanno una allocazione ION riservata al surfaceflinger/stagefright (si occupa di comporre i vari layer grafici da inviare poi al framebuffer per la visualizzazione sullo schermo) ridotta di qualche MB (da 8MB a 18MB, in base alla configurazione scelta) per lasciare maggiore memoria libera, diciamo che è un'escamotage per ovviare alla poca memoria disponibile sui nostri device.
Questa riduzione comporta, nelle circostanze in cui ci siano vari layer da visualizzare, l'uso dello heap di sistema piuttosto che lo heap riservato al surface flinger, poichè lo spazio riservato a volte non è sufficiente. Lo switch dallo heap ION dedicato al surfaceflinger, allo heap ION di sistema, avviene automaticamente ed in maniera trasparente per l'utente. Lato logcat viene riportato il messaggio che indica appunto "non riesco ad allocare tutta la memoria nello heap dedicato, uso lo heap di sistema". Ciò non comporta alcun degrado di prestazioni (il sistema è comunque fluido nell'aprire le app e nelle animazioni di transizione), lo switch dallo heap dedicato a quello di sistema è molto veloce, e ci consente di tenere libera della memoria nel caso in cui non serva al surfaceflinger.

Preferisco non commentare i post di questo tipo, come non avevo commentato il post in cui sirmordred diceva che aveva dimezzato il voltaggio dello schermo...

Era da un po' che meditavo di rilasciare il K^Kernel anche per gli utenti del Galaxy W, anche se ci ho messo più di un anno e mezzo per decidermi visto il poco tempo a disposizione. Probabilmente ora, gli utenti che hanno creato dei kernel nella vostra sezione, pur basandosi sui miei sorgenti e integrando man mano le varie modifiche che vi apporto, vogliono cercare di differenziare almeno un po' il proprio kernel dal mio, anche perchè, effettivamente, non avrebbe molto senso avere più kernel completamente uguali... Ciò non è affatto una brutta cosa, è una sorta di sfida a chi fa qualcosa di migliore e più innovativo, mantenendo anche la comunità di utenti attiva, ma l'importante è che facciano le cose con giudizio e non a caso, documentandosi almeno un po', cercando di verificare le modifiche che fanno, piuttosto che rischiare potenzialmente di rovinare il cellulare.

Secondo te il kernel di sir mordred era fatto bene? Ci sei su hangouts, forse si fa a prima a parlarne la.
Lo chiedo perchè da ad un certo punto il mio telefono mi ha abbandonato

[Redwraith]

Secondo te il kernel di sir mordred era fatto bene? Ci sei su hangouts, forse si fa a prima a parlarne la.
Lo chiedo perchè da ad un certo punto il mio telefono mi ha abbandonato

Nel kernel di sir mordred c'era qualche problema nei voltaggi(troppo bassi e non supportati da un driver del nostro telefono) che ha dato al display lcd,che poteva fare danni all'hardware.
Ti rimando alla discussione su xda dove sono stati fatti i test:
[KERNEL][3.4.94][KK][ION] K^Kernel 3.4.94 v1.2 for KK 4.4 ION+PMEM ADSP [25/06/2014] - Page 11 - xda-developers

[jnr88]

Qualcuno ha provato il 416mb exuv? Come si comporta la batteria overclockando a 1.8Ghz? È sicuro arrivare a quella frequenza?
@Christopher83 sei un genio

[Christopher83]

La frequenza di 1.8 GHz è ancora sicura per la nostra CPU, quelle superiori (da 1.9 GHz in su) possono provocare dei danni, soprattutto quando fa un po' caldo oppure dopo un uso prolungato.
Overclockando naturalmente il cel risponde più velocemente, nei giochi o app più pesanti è più reattivo, tuttavia si perde un po' di durata della batteria, perchè più la frequenza è alta e più la cpu ha bisogno di energia, comunque il kernel EXUV a 1.8 GHz usa solo 75mV in più rispetto al voltaggio che usa il kernel stock (quindi senza undervolting) a 1.4 GHz.
Io uso abitualmente un oveclocking a 1.6 GHz, però non gioco quasi mai e i giochi che uso sono i classici semplici giochini, mentre uso l'overclocking a 1.8 GHz durante le varie sessioni di benchmark e test di stabilità.
Il kernel EXUV a 416MB è il più scaricato al momento...