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

Quote:

---

Originariamente inviato da Christopher83

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 ;)

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

codice:

---

- 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!

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?

Quote:

---

Originariamente inviato da 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?

---

416?? Una volta erano 340! roftl

Quote:

---

Originariamente inviato da 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?

---

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.

Quote:

---

Originariamente inviato da Christopher83

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.

Quote:

---

Originariamente inviato da Christopher83

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

Quote:

---

Originariamente inviato da Fra98

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

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

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...

Quote:

---

Originariamente inviato da Redwraith

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

---

Anche nella prima versione? Mi sa che è stato quello a farmi semi-hard brickare il Wonder

Sempre preciso e puntuale @Christopher83! Lo installerò al più presto, grazie!

Quote:

---

Originariamente inviato da 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...

---

Solo per sapere quanto hai fatto di bench con la versione da 416Mb?Io utilizzando antutu benchmark x ho fatto 7200 e qualcosa, e mi sembra un po poco rispetto agli 8200-8300 che facevo con la versione 4.4.2 della cm11 forse è solo perche antutu ha cambiato qualche valore per il punteggio..

Quote:

---

Originariamente inviato da Fra98

Anche nella prima versione? Mi sa che è stato quello a farmi semi-hard brickare il Wonder

---

No solo nell'ultima versione.

Quote:

---

Originariamente inviato da Redwraith

Solo per sapere quanto hai fatto di bench con la versione da 416Mb?Io utilizzando antutu benchmark x ho fatto 7200 e qualcosa, e mi sembra un po poco rispetto agli 8200-8300 che facevo con la versione 4.4.2 della cm11 forse è solo perche antutu ha cambiato qualche valore per il punteggio..

---

Con l'S Plus arrivo oltre gli 8300 con picchi di 8500 usando Antutu.
Per effettuare dei benchmark abbastanza affidabili:
- assicurati che il cel non sia attaccato al caricatore o al cavo usb
- imposta un governor prestante (SmartAssV2, Interactive, Lulzactive o Ondemand) o addirittura il governor Performance (che usa sempre la frequenza massima, ma ricordati poi di reimpostare il governor precedente appena hai finito i test)
- effettua l'overclock a 1824MHz
- metti il cel in aero mode
- chiudi tutte le app/processi inutili in esecuzione
- apri Antutu
- effettua 3/4 test consecutivi
- ripristina il precedente governor e frequenza massima

Fammi sapere.

Appena flashato il 416exuv ma il telefono si blocca all'immagine di boot... Cosa posso fare?

Edit: togliendo la batteria in 3 volte è riuscito a completare l'upgrade delle app dovuto al wipe dalvik ma poi si blocca all'immagine di boot (la freccia che gira intorno alla faccina blu si blocca) e resta lì, riavviandosi da solo dopo circa 5 minuti.

Edit2: senza fare wipe ho messo il 416uv e ora funziona. Cosa può essere?

Quote:

---

Originariamente inviato da jnr88

Appena flashato il 416exuv ma il telefono si blocca all'immagine di boot... Cosa posso fare?

Edit: togliendo la batteria in 3 volte è riuscito a completare l'upgrade delle app dovuto al wipe dalvik ma poi si blocca all'immagine di boot (la freccia che gira intorno alla faccina blu si blocca) e resta lì, riavviandosi da solo dopo circa 5 minuti.

Edit2: senza fare wipe ho messo il 416uv e ora funziona. Cosa può essere?

---

Purtroppo la tua cpu non supporta la versione extreme undervolted, ma puoi usare tranquillamente quella undervolted.
Non preoccuparti, rispetto al kernel stock hai comunque un buon risparmio di carica della batteria.
Sul mio thread XDA puoi trovare la tabella comparativa dei voltaggi adottati.

Quote:

---

Originariamente inviato da Christopher83

Purtroppo la tua cpu non supporta la versione extreme undervolted, ma puoi usare tranquillamente quella undervolted.
Non preoccuparti, rispetto al kernel stock hai comunque un buon risparmio di carica della batteria.
Sul mio thread XDA puoi trovare la tabella comparativa dei voltaggi adottati.

---

Immaginavo, si si sto seguendo anche il thread su xda e ho visto la tabella. Userò l'uv allora..Vedremo nei prossimi giorni come si comporta la batteria, per adesso con l'oc a 1651Mhz il telefono sembra molto fluido! Grazie!

Quote:

---

Originariamente inviato da Christopher83

Con l'S Plus arrivo oltre gli 8300 con picchi di 8500 usando Antutu.
Per effettuare dei benchmark abbastanza affidabili:
- assicurati che il cel non sia attaccato al caricatore o al cavo usb
- imposta un governor prestante (SmartAssV2, Interactive, Lulzactive o Ondemand) o addirittura il governor Performance (che usa sempre la frequenza massima, ma ricordati poi di reimpostare il governor precedente appena hai finito i test)
- effettua l'overclock a 1824MHz
- metti il cel in aero mode
- chiudi tutte le app/processi inutili in esecuzione
- apri Antutu
- effettua 3/4 test consecutivi
- ripristina il precedente governor e frequenza massima

Fammi sapere.

---

Ok mi sono accorto di avere il ksm abilitato quindi subito dopo l'ho disabilitato e ho fatto i test:
smartass v2 + noop
1* test : 8128
2* test : 8271
3* test : 8204
interactive + noop
4* test : stuck e reboot del telefono
5* test : 8106
6* test : stuck e reboot del telefono

Non faccio in tempo a testare il kernel con calma che esce la nuova versione ;) stamattina ho installato il 416exuv (ottimo,bravissimo christopher) ho provato al contempo a portare il processore a 1.6,la differenza in fluidità e reattività si nota molto ma sono appena tornato a 1.4 xchè mi sembra che consumi un bel po di batteria in piu. È solo una mia impressione o lo ha notato qualcun'altro?

Inviato dal mio GT-I8150 usando Androidiani App

Ho appena messo a 1,6. Faccio un giorno di prova e ti dico.

Comunque la durata della batteria con questo kernel è spettacolare in 9 ore di stand-by in aero mod è scesa solo del tre precento.:)

Quote:

---

Originariamente inviato da Redwraith

Comunque la durata della batteria con questo kernel è spettacolare in 9 ore di stand-by in aero mod è scesa solo del tre precento.:)

---

OK.....ma una considerazione del genere su questo tipo di utilizzo lascia un po il tempo che trova..praticamente cosi il telefono non serve a niente ;)

Inviato dal mio GT-I8150 usando Androidiani App

Stramattina la batteria si è scaricata del tutto in 3 ore e il telefono si è bloccato 3 volte rendendo necessario il riavvio dopo aver tolto la batteria. Controllando con cpuspy ho visto che è rimasto tutto il tempo con la frequenza a 1.6 GHz che era quella massima che avevo impostato. Cosa può essere successo?
Ieri funzionava benissimo ed il telefono entrava regolarmente in deepsleep.

Quote:

---

Originariamente inviato da fra85

OK.....ma una considerazione del genere su questo tipo di utilizzo lascia un po il tempo che trova..praticamente cosi il telefono non serve a niente ;)

Inviato dal mio GT-I8150 usando Androidiani App

---

Si lo so e che volevo fare un confronto con altri kernel che anche se lasciavo il telefono in stand-by mi consumava fino al 10% di batteria.

Quote:

---

Originariamente inviato da jnr88

Stramattina la batteria si è scaricata del tutto in 3 ore e il telefono si è bloccato 3 volte rendendo necessario il riavvio dopo aver tolto la batteria. Controllando con cpuspy ho visto che è rimasto tutto il tempo con la frequenza a 1.6 GHz che era quella massima che avevo impostato. Cosa può essere successo?
Ieri funzionava benissimo ed il telefono entrava regolarmente in deepsleep.

---

Che governor hai impostato?Perchè se è performance lascia la frequenza massima bloccata.

Quote:

---

Originariamente inviato da Redwraith

Che governor hai impostato?Perchè se è performance lascia la frequenza massima bloccata.

---

Purtroppo il telefono non è mio e non posso verificare subito, comunque mi pare di ricordare che sia impostato ondeman, anche perché per il primo giorno è funzionato bene.

La durata della batteria con ov a 1612 mi sembra buona. Non si discosta molto da 1400 ed il telefono è più reattivo.

Niente da fare per me con l'uv 416mb... Telefono bloccato anche oggi e batteria scarica in 5 ore...

Christopher83 non riesco a inviare messaggi con l'applicazione di default,appena provo ad inviare un messaggio compare l'errore com.process.phone,allora ho provato a fare alcuni log e ho trovato che ci sono errori tipo ION_IOC_ALLOC failed with error - Out of memory, Failed to find cpu subsys,bindService() for wappush manager failed e altri errori.Ti allego qui sotto i tre log:

-logcat

-logcat radio

-dmesg

Ciao a tutti,
ho rilasciato le nuove build del kernel v1.3.
Changelog:

codice:

---

- Kernel 3.4.96
- Built with my latest custom Linaro 4.9.1-2014.06 toolchain optimized for Cortex-A8
- block: bfq: Squashed update from BFQ-v7r4 to BFQ-v7r5 (credits to arco68)
- misc: pmem: Support for dynamic allocation through CMA (credits to Christopher83)
- msm7x30: Simplify the code for hybrid memory allocations on board side (credits to Christopher83)
- msm7x30: Allow to optionally enable the use of CMA for ION MM and PMEM ADSP heaps (credits to Christopher83)
- msm7x30: Use CMA for PMEM ADSP (credits to Christopher83)
- msm7x30: Update defconfigs (credits to Christopher83)
- msm7x30: Use a higher memory allocation if CMA is used for ION MM heap (credits to Christopher83)

---

NOTE:
Il kernel include una nuova implementazione dell'allocazione dinamica degli heap PMEM attraverso CMA, in modo da risolvere i problemi riscontrati usando la fotocamera/camcorder (reboot, freeze) e include anche una fix per consentire la visualizzazione di alcuni video HD e il re-encoding di video lunghi prima dell'invio con alcune app (come WhatsApp).
Continuate a tenere disattivato il KSM (l'opzione è in Impostazioni -> Prestazioni -> Gestione memoria -> Fusione pagine kernel).

Ottimo, ora posso flashare l'ultima build della cm11 ;)

Inviato dal mio GT-I8150 usando Androidiani App

Ciao,

volevo segnalare che sul mio telefono con l'ultima cm11 build del 04/07 + k^kernel 416 mb exuv (stesso per uv) il Wi-Fi non funziona..

Nessuno ha lo stesso problema ??

nel caso allego i log di dmesg e logcat

Grazie.

Spoiler:

dmesg: pastebin.com/m54MmtwK logcat: pastebin.com/XMJ0vZRS

Allegato 115552

Quote:

---

Originariamente inviato da androidmen1245

Ciao,

volevo segnalare che sul mio telefono con l'ultima cm11 build del 04/07 + k^kernel 416 mb exuv (stesso per uv) il Wi-Fi non funziona..

Nessuno ha lo stesso problema ??

nel caso allego i log di dmesg e logcat

Grazie.

Spoiler:

dmesg: pastebin.com/m54MmtwK logcat: pastebin.com/XMJ0vZRS

https://www.androidiani.com/forum/at...2&d=1404593498

---

Ho la stessa build e lo stesso kernel,xò il WiFi non mi da problemi

Inviato dal mio GT-I8150 usando Androidiani App

Quote:

---

Originariamente inviato da androidmen1245

Ciao,

volevo segnalare che sul mio telefono con l'ultima cm11 build del 04/07 + k^kernel 416 mb exuv (stesso per uv) il Wi-Fi non funziona..

Nessuno ha lo stesso problema ??

nel caso allego i log di dmesg e logcat

Grazie.

Spoiler:

dmesg: pastebin.com/m54MmtwK logcat: pastebin.com/XMJ0vZRS

Allegato 115552

---

Ciao,
probabilmente hai la partizione system senza abbastanza spazio, quindi non riesci ad installare tutti i moduli del kernel. Installa delle gapps meno ingombranti oppure rimuovi qualche app di sistema inutile.

Quote:

---

Originariamente inviato da Christopher83

Ciao,
probabilmente hai la partizione system senza abbastanza spazio, quindi non riesci ad installare tutti i moduli del kernel. Installa delle gapps meno ingombranti oppure rimuovi qualche app di sistema inutile.

---

Grazie mille, avevi proprio ragione installando un pacchetto gapps più piccolo il wifi funziona regolarmente.
Eppure mi sembra strano perchè avevo già ridotto di qualche app quello presente nel thread della cm11 e con le precedenti build funzionava senza problemi.

Quote:

---

Originariamente inviato da Christopher83

Ciao a tutti,
ho rilasciato le nuove build del kernel v1.3.
Changelog:

Quote:

---

- Kernel 3.4.96
- Built with my latest custom Linaro 4.9.1-2014.06 toolchain optimized for Cortex-A8
- block: bfq: Squashed update from BFQ-v7r4 to BFQ-v7r5 (credits to arco68)
- misc: pmem: Support for dynamic allocation through CMA (credits to Christopher83)
- msm7x30: Simplify the code for hybrid memory allocations on board side (credits to Christopher83)
- msm7x30: Allow to optionally enable the use of CMA for ION MM and PMEM ADSP heaps (credits to Christopher83)
- msm7x30: Use CMA for PMEM ADSP (credits to Christopher83)
- msm7x30: Update defconfigs (credits to Christopher83)
- msm7x30: Use a higher memory allocation if CMA is used for ION MM heap (credits to Christopher83)

---

NOTE:
Il kernel include una nuova implementazione dell'allocazione dinamica degli heap PMEM attraverso CMA, in modo da risolvere i problemi riscontrati usando la fotocamera/camcorder (reboot, freeze) e include anche una fix per consentire la visualizzazione di alcuni video HD e il re-encoding di video lunghi prima dell'invio con alcune app (come WhatsApp).
Continuate a tenere disattivato il KSM (l'opzione è in Impostazioni -> Prestazioni -> Gestione memoria -> Fusione pagine kernel).

---

Cristopher83,mi puoi togliere una curiosità?Ma questo kernel è lo stesso che è stato introdotto nella CyanogenMod 11.0 build 17?


Inviato dal mio GT-I8150 usando Androidiani App

Ciao ragazzi,
ho rilasciato le nuove build del kernel v1.4.

Changelog:

codice:

---

- Kernel 3.4.98
- Built with my latest custom Linaro 4.9.1-2014.06 toolchain optimized for Cortex-A8
- misc: pmem: Retry again a few times if DMA allocation fails (credits to Christopher83)
- defconfig: Disable KSM (credits to arco68)
- Revert "msm: mdp: Update sync pt. behaviour" (credits to arco68)
- cpufreq: Persist cpufreq time in state data across hotplug (credits to Ruchi Kandoi)
- prctl: adds the capable(CAP_SYS_NICE) check to PR_SET_TIMERSLACK_PID. (credits to Ruchi Kandoi)
- net: wireless: Increase scan entry expiration to fit new scan time (credits to Dmitry Shmidt)
- DMA: PL330: Fix racy mutex unlock (credits to Javi Merino)
- cpufreq: fix sleeping in atomic context when realloc freq_table for all_time_in_state (credits to Minsung Kim)
- s3c2410_wdt: Add locking to cpu frequency transition notifier (credits to Mark Salyzyn)
- net: core: Support UID-based routing. (credits to Lorenzo Colitti)
- Handle 'sk' being NULL in UID-based routing. (credits to Sreeram Ramachandran)
- rtc: alarm: Squashed revert of power-on alarm feature and related commits (credits to Christopher83)
- binder: search for receiving context pid in global namespace (credits to Ricardo Mendoza)
- staging: binder: add vm_fault handler (credits to Vinayak Menon)
- Staging: android: binder: More offset validation. (credits to Arve Hjønnevåg)

---

NOTE:
Il nuovo kernel non è compatibile con le vecchie rom, è compatibile con l'ultima rom CM 11.0 rilasciata da arco68 ieri (13/07) e le prossime rom che includono le sue ultime modifiche.
Ciò è dovuto alla rimozione dell'uso del retire fence per il driver MDP che ha comportato modifiche sia lato kernel che lato rom.

Grazie agli utenti dec0der, lafactorial e LeroViten di XDA per il loro supporto in fase di test!

Grazie mille. Penso che allora dovrò aggiornare il thread al piu presto prima che qualcuno bricki

Quote:

---

Originariamente inviato da Fra98

Grazie mille. Penso che allora dovrò aggiornare il thread al piu presto prima che qualcuno bricki

---

No, tranquilli, nessun rischio di brick, l'incompatibilità è in termini grafici, cioè se si usa il nuovo kernel su una rom vecchia, l'interfaccia grafica a tratti è scattosa.
Per questo è necessario avere una rom aggiornata...

Buongiorno a tutti. Anche voi non avete più la voce l'opzione "Fusione pagine kernel" in > Prestazioni -> Gestione memoria? Cyanogen 11 build 20 aggiornata ieri.
La voce è scomparsa o è rintracciabile in altri percorsi?

Grazie a tutti.

Quote:

---

Originariamente inviato da Mic77

Buongiorno a tutti. Anche voi non avete più la voce l'opzione "Fusione pagine kernel" in > Prestazioni -> Gestione memoria? Cuanogen 11 build 20 aggiornata ieri.
La voce è scomparsa o è rintracciabile in altri percorsi?

Grazie a tutti.

---

Il ksm è stato tolto dalle opzioni in modo che nessuno vada ad abilitarlo e perchè se abilitato causa crash della fotocamera e altri problemi.
Però spero che questo problema venga risolto..