Obsolete. This has been merged into the most recent releases of my ROMs.
TRIM for Galaxy Tab 10.1
These are kernels with TRIM enabled.
Backstory:
In 2011/2012 the eMMC DISCARD operation (aka TRIM) resulted in the SuperBrick bug on this device and many other Samsung devices. Samsung released a fix[1] back then but the Android community was not happy with the way Samsung had treated the them. So it seems that many ROM maintainers did not trust that the issue was fixed. The SuperBrick bug patch was never merged for most devices despite it being merged into the mainline Linux kernel. Instead the indie developers opted to disable the DISCARD operation all together. Since then every major ROM/kernel/recovery for this device has had DISCARD disabled.
Fast forward to the past year and a half or so some developers began to release kernels with the Samsung brickbug patches and renabling the DISCARD operation. The buggy operation that resulted in bricking eMMC cards is the secure DISCARD operation. The plain DISCARD operation is safe. The patch from Samsung simply disables the buggy secure DISCARD.
I have been testing TRIM for this device on my own since shortly after[2] I first released the Lollipop ROM in November 2014. I have not run into any problems since then.
Developer @Lanchon has been publicly testing[3] it on the Galaxy S2 i9100 for a long time. Recently the DISCARD functionality was officially merged into the CM-13.0 kernel for that device. He also pointed out in a recent post that the lifespan of eMMC cards are adversely affected by write amplification[4] if TRIM is not being used.
So all things considered I think we are overdue for re-enabling the DISCARD operation and having TRIM working for this device.
Additional note:
Wiping in recovery is still safe. Some devices use the same kernel for the ROM and recovery. This device does not. This device has a seperate kernel for the ROM and recovery. So there is zero risk with using this kernel and any recovery that is also itself safe to use.
That was a major concern for devices that use a single kernel for the ROM and recovery but that does not apply to this device. Every recovery I have released to date still has DISCARD completely disabled.
You can find plenty of documentation/articles/threads about the SuperBrick bug saga so I won't write anymore than needs to be said.
[1] https://wiki.cyanogenmod.org/w/EMMC_Bugs
[2] https://github.com/Decatf/android_kernel_samsung_p4/commit/15ca63c60b63a9e6796b9554694c1a2c9aed2a53
[3] http://forum.xda-developers.com/galaxy-s2/development-derivatives/rom-brickbug-aftermath-speeding-t2843238
[4] https://en.wikipedia.org/wiki/Write_amplification
Downloads:
I'm posting these as a separate project because I won't be re-enabling DISCARD in the kernel of my ROM releases until these kernels have been tested publicly for some time.
Standard disclaimer applies. Use this at your own risk!
p4wifi_kernel-aosp-5.1-20150305-TRIM.zip
p4_kernel-aosp-5.1-20150305-TRIM.zip
p4tmo_kernel-aosp-5.1-20150305-TRIM.zip
Only compatible with aosp-6.0.1-20160428 and older. ROMs newer than 20160428 have TRIM included by default.
p4wifi_kernel-aosp-6.0-20160414-TRIM.zip
p4_kernel-aosp-6.0-20160414-TRIM.zip
p4tmo_kernel-aosp-6.0-20160414-TRIM.zip
Using TRIM:
Android runs TRIM automatically (since Lollipop) so you don't need to install any app to do it. You might want to run it manually once after you've installed this kernel since most of your devices probably have never been TRIMed before.
There is a command to do it manually from the terminal. It must be run as root.
Code:
$ fstrim -v /data
$ fstrim -v /system
$ fstrim -v /cache
XDA:DevDB Information
TRIM for Galaxy Tab 10.1, Kernel for the Samsung Galaxy Tab 10.1
Contributors
decatf
Kernel Special Features:
Version Information
Status: Testing
Created 2016-03-07
Last Updated 2016-08-23
Thanks bro. Will surely try it
Hello
There is problem. I cant install p4 trimm kernel because of error message " your unit isn't p4tmo" My unit is really p4 the message is failed. Please correct the error. Best regards joe ps your rom is fantastic
decatf said:
TRIM for Galaxy Tab 10.1
These are kernels with TRIM enabled.
Backstory:
In 2011/2012 the eMMC DISCARD operation (aka TRIM) resulted in the SuperBrick bug on this device and many other Samsung devices. Samsung released a fix[1] back then but the Android community was not happy with the way Samsung had treated the them. So it seems that many ROM maintainers did not trust that the issue was fixed. The SuperBrick bug patch was never merged for most devices despite it being merged into the mainline Linux kernel. Instead the indie developers opted to disable the DISCARD operation all together. Since then every major ROM/kernel/recovery for this device has had DISCARD disabled.
Fast forward to the past year and a half or so some developers began to release kernels with the Samsung brickbug patches and renabling the DISCARD operation. The buggy operation that resulted in bricking eMMC cards is the secure DISCARD operation. The plain DISCARD operation is safe. The patch from Samsung simply disables the buggy secure DISCARD.
I have been testing TRIM for this device on my own since shortly after[2] I first released the Lollipop ROM in November 2014. I have not run into any problems since then.
Developer @Lanchon has been publicly testing[3] it on the Galaxy S2 i9100 for a long time. Recently the DISCARD functionality was officially merged into the CM-13.0 kernel for that device. He also pointed out in a recent post that the lifespan of eMMC cards are adversely affected by write amplification[4] if TRIM is not being used.
So all things considered I think we are overdue for re-enabling the DISCARD operation and having TRIM working for this device.
Additional note:
Wiping in recovery is still safe. Some devices use the same kernel for the ROM and recovery. This device does not. This device has a seperate kernel for the ROM and recovery. So there is zero risk with using this kernel and any recovery that is also itself safe to use.
That was a major concern for devices that use a single kernel for the ROM and recovery but that does not apply to this device. Every recovery I have released to date still has DISCARD completely disabled.
You can find plenty of documentation/articles/threads about the SuperBrick bug saga so I won't write anymore than needs to be said.
[1] https://wiki.cyanogenmod.org/w/EMMC_Bugs
[2] https://github.com/Decatf/android_kernel_samsung_p4/commit/15ca63c60b63a9e6796b9554694c1a2c9aed2a53
[3] http://forum.xda-developers.com/galaxy-s2/development-derivatives/rom-brickbug-aftermath-speeding-t2843238
[4] https://en.wikipedia.org/wiki/Write_amplification
Downloads:
I'm posting these as a separate project because I won't be re-enabling DISCARD in the kernel of my ROM releases until these kernels have been tested publicly for some time.
Standard disclaimer applies. Use this at your own risk!
p4wifi_kernel-aosp-5.1-20150305-TRIM.zip
p4_kernel-aosp-5.1-20150305-TRIM.zip
p4tmo_kernel-aosp-5.1-20150305-TRIM.zip
p4wifi_kernel-aosp-6.0-20160305-TRIM.zip
p4_kernel-aosp-6.0-20160305-TRIM.zip
p4tmo_kernel-aosp-6.0-20160305-TRIM.zip
Using TRIM:
Android runs TRIM automatically (since Lollipop) so you don't need to install any app to do it. You might want to run it manually once after you've installed this kernel since most of your devices probably have never been TRIMed before.
There is a command to do it manually from the terminal. It must be run as root.
Code:
$ fstrim -v /data
$ fstrim -v /system
$ fstrim -v /cache
XDA:DevDB Information
TRIM for Galaxy Tab 10.1, Kernel for the Samsung Galaxy Tab 10.1
Contributors
decatf
Kernel Special Features:
Version Information
Status: Testing
Created 2016-03-07
Last Updated 2016-03-07
Click to expand...
Click to collapse
decatf said:
TRIM for Galaxy Tab 10.1
I tried this on my P4 Wifi running [AOSP] Android 6.0.1 Marshmallow this evening and the tab rebooted while trying to run the first command. However second attempt seemed to work and trim successfully. :good:
Click to expand...
Click to collapse
Sagij0619 said:
There is problem. I cant install p4 trimm kernel because of error message " your unit isn't p4tmo" My unit is really p4 the message is failed. Please correct the error. Best regards joe ps your rom is fantastic
Click to expand...
Click to collapse
Install the p4 TRWP.
Wow, thank you for that!
My P4wifi was dying (many lags).
I will test your kernel when I have time.
This is awesome! My tablet is running better than ever! I've used it for a week without any issues. It trimmed almost 1.5 GB in data partition when I ran it manually, as advised it the post. Since then, no more lag.
Thank you very much, @Decaft
Enviado de meu GT-P7510 usando Tapatalk
Running this on my p4wifi and boy does this seem to make a huge difference! I installed the kernel then ran the commands as outlined above then rebooted and this thing just flies now. can't believe this is running marshmallow before my note5 awesome work @decatf
It is done. I've installed your Trim kernel on my p4wifi with Lollipop ROM.
I'm not comfortable with terminal so I used Trimmer store app to trim partitions. All went well. No brick. :good:
New toy? Nice! One question though: How does this kernel (release date of March 5 when I wrote this) compare to the one included in your March 14th AOSP 6.0 ROM? I noticed that the kernel build date in the ROM version is also March 14 while this one is earlier (as of this posting). Were the wifi issues that were fixed in the March 14 ROM userspace issues or kernel issues? And a dumb question: If using F2FS, is running fstrim manually once installed still worthwhile, or is that more for ext4 systems?
rtiangha said:
New toy? Nice! One question though: How does this kernel (release date of March 5 when I wrote this) compare to the one included in your March 14th AOSP 6.0 ROM? I noticed that the kernel build date in the ROM version is also March 14 while this one is earlier (as of this posting). Were the wifi issues that were fixed in the March 14 ROM userspace issues or kernel issues? And a dumb question: If using F2FS, is running fstrim manually once installed still worthwhile, or is that more for ext4 systems?
Click to expand...
Click to collapse
It was kernel issues.
Use TRIM regardless of what filesystem it is. Pay no attention to posts elsewhere saying that TRIM doesn't work on F2FS or that it's not worthwhile. Those issues apply to old versions of F2FS. Some maintainers enable an F2FS option that runs DISCARD internally but Android runs TRIM periodically so there's no need to enable that.
Worked great on P7510. No issues at all. Were able to TRIM right after reboot and installation of a terminal .
Just great to get this old relich taken out of deep storage and brought to life again with updated kernel and android 6.0.1 ROM :good:
I'd suggest the app eMMC Brickbug Check for probing the hardware in your tab10.1 flash disk and a little reading online. The first trim after all these years use gives the greatest improvement, removing a monster clog in the hardware. Further trims depend on how much writing/deleting one does.
Working great on my P7510 with decatf rom and pico apps.
---------- Post added at 11:55 AM ---------- Previous post was at 11:23 AM ----------
My eMMC hardware says:
Type: SEM16G
Date: 05/2011
CID: blah long number blah
FwRev: 0x90
YMMV
App rotate soft reboot
@decatf, as if you need more logs to indict rotate sensors, here's another.
I once again ran eMMC Brickbug Check to add the output to my previous post to share with the thread and, like many phone-centric apps, it only runs in portrait mode even though I keep my tab locked in landscape (which nearly eliminated soft reboots), but when the app started in portrait mode, instant soft reboot. Good luck and thanks again.
DrGirlfriend said:
I'd suggest the app eMMC Brickbug Check for probing the hardware in your tab10.1 flash disk and a little reading online. The first trim after all these years use gives the greatest improvement, removing a monster clog in the hardware. Further trims depend on how much writing/deleting one does.
Click to expand...
Click to collapse
Tried the eMMC check.
Result is:
eMMc chip
Type: MAG4FA
Date: 09/2011
CID: 1501004d414734464112f813e2fe9e00
FwRev: 0x12
Brick Bug?
YES. Insane chip
Is the "Brick Bug YES" significant when the path have been put into the kernel ? I gues it is'nt
PowerDK said:
Tried the eMMC check.
Result is:
eMMc chip
Type: MAG4FA
Date: 09/2011
CID: 1501004d414734464112f813e2fe9e00
FwRev: 0x12
Brick Bug?
YES. Insane chip
Is the "Brick Bug YES" significant when the path have been put into the kernel ? I gues it is'nt
Click to expand...
Click to collapse
This fixes the brick bug so it should be safe to use.
TRIM Kernel
The TRIM kernel is working great for me so far on p4wifi.
The aosp-6.0 TRIM kernel been updated with changes from the 20160326 ROM merged in.
could you please tell me how to do it manually? Thanks a lot
dihoc said:
could you please tell me how to do it manually? Thanks a lot
Click to expand...
Click to collapse
If you mean "how to trim manually" the easiest way is to follow LeBourrin's suggestion earlier in the thread and download the Trimmer app from the Play Store. It worked for me.
LeBourrin said:
It is done. I've installed your Trim kernel on my p4wifi with Lollipop ROM.
I'm not comfortable with terminal so I used Trimmer store app to trim partitions. All went well. No brick. :good:
Click to expand...
Click to collapse
Related
2012-09-11: update. So far 12 xda users reported a bricked gt8.9. Don't join them...
2012-09-08: update. I will be out of town this weekend. I will keep the top post summarized once per day (if there is news)
Current knowledge is: (note: knowledge on this issue is still evolving and may become more accurate in future)
there is a serious bug in a hardware EMMC chip (or its driver) used in many Samsung devices
in GingerBread / HC this bug was not triggered
in its ICS kernels Samsung has used a feature to wipe EMMC in a way that triggers the bug in the chip
when xda developers used Samsung ICS kernel sources to continue work with (e.g. as kernel for the recovery - which has separate kernel from the ROM itself), they pulled the issue into their work
this has caused many bricks on many many different Samsung devices.
gt8.9 tab's CWM 6.0.1.2 includes this ICS kernel, and is dangerous if used to wipe /system or any other wipe (theoretically, that includes nandroid restore)
gt8.9 earlier CWM are believed to be safe (5.1.2.6, 5.5.0.4, 6.0.0.8, 6.0.0.8_alternate)
potentially, even update-binary inside a flashable .zip can be dangerous: IF it includes a specific (ext4) module from faulty ICS kernel, and IF the updater-script does a format(). So far there are no reports of such so far on the gt8.9
potentially, the same issue can be triggered from the kernel in the ICS ROM (although less risky, as that kernel is normally never used to wipe the boot or system partition). Nobody has reported issues after doing a "factory reset" from within Samsung p7310 stock ICS (USA region). We don't know if the ICS kernel inside that ROM is dangerous. Still, you are (till further notice) adviced not to use that feature inside any ICS rom. If you do, report here!
2012-09-07: v1 (modified)
Still more people are reporting bricking their device, after using CWM 6.0.1.2, even though it's already known 24-48 hours that this recovery can lead to this error.
I will link some threads in a follow up where the issue is discussed. Still, I recommend to try focus the discussion to just 1 thread... It will be easier on us all.
Proposal
- I propose to bump this thread hourly or so, for a few days at least, so that everybody has a chance to see it.
- There are many threads that discuss this issue. Try to keep the discussion a little focussed, don't continue posting in 6-7 different threads. Use this one
- If you see this disappearing from page 1 in General Forum, just reply with either:
* good idea, keep bumping
* stupid, stop it already
- If you heard of this issue here first, hit thanks
Thanks
Links
CWM 6.0.1.2 was made available in the CM9 thread (dev forum) around Sep 4.
By Sep 5 the first reports of bricked devices were coming in. The CM9 thread, starting from post 1066 (link, quote below) has been all about that for several pages. If you have found something really useful, reply on that dev thread. Do not spam it though.
kallt_kaffe said:
FYI, I might have bricked my P7310 so development is paused for now. Was flashing a CM10 build yesterday that I was experimenting with when it got stuck at "Formatting /cache" and after a while I did a long press on power thinking it would recover from it.
However I'm now stuck with black screen and it identifies itself as APX in Device Manager.
(...)
Click to expand...
Click to collapse
If you want to discuss in general, mention you have the same issue, ask for updates, etc, just reply here
other threads started for same issue. just for reference...
http://forum.xda-developers.com/showthread.php?p=31177035
http://forum.xda-developers.com/showthread.php?p=31158609
http://forum.xda-developers.com/showthread.php?p=31238668
http://forum.xda-developers.com/showthread.php?p=31172928
http://forum.xda-developers.com/showthread.php?t=1875756
Reserved
Sent from my HTC Desire using xda app-developers app
I hope those with the problem get a fix soon, i wouldnt be able to sleep if that happended to me
Sorry and up for this thread to warn others
Sent from my GT-P7300 using xda app-developers app
Im not really sure what makes this bugs happen..
But this issues is not new for me in galaxyNOTE gt n7000 and Sgs2 I9100 we call this as EMMC superbrick..
It happen in ICS kernel stock if you operates some EMMC_CAP_ERASE in kernel such as wiping your data or system.. Format.. Or deleting large file in recovery operation or factory reset in EMMC with firmware revision 0x19(firmware of this chip)..
It cannot recover with regular utility like JTAG coz This superbrick makes EMMC faulty in /data partition or /system partition blocks..
If you go to Samsung Service Centre.. Your device should be on mainboard replacement..
Sorry for my english.. You could use this app for testing your emmc has a bug or not..
If you had the emmc bug.. Dont use any recovery from ICS sources until someone with expert knowledge confirm that everything is fine..
Please read this thread for complete issues and discuss..from recognized developer entropy512
http://forum.xda-developers.com/showthread.php?t=1633938
I think it not about cwm version but the kernel is..
THANKS for makes this
Ups seems the i got the bug :-/
Sent from my GT-P7300 using xda app-developers app
I too got the bug and CWM 6.0.0.8 but my tablet will stay with AOKP for the time being until the dust settles.
Could somebody tell me what is the latest safest CWM to use for flashing KK's CM10 preview ROM.
Bump.
Cwm 5.1.2.6, 5.5.0.4 and 6.0.0.8 have all been around long enough to conclude that they are safe (in terms of this emmc bug)
You guys have a twrp?
Sent from my SGH-I727 using xda premium
Well, crap on a cracker...
Okay, so after reading the dumbed down facts about the issue at hand, it would seem that the latest CWM is not completely at fault for bricking devices. This most likely happened to users who were already on ICS and who already had a kernel that will allow the EMMC_CAP_ERASE to execute over a chip incapable of handling it.
The reports of using the latest CWM and successfully updating to ICS experimental builds without bricking most likely came from people going from stock Honeycomb to ICS?
Any of this true?
de3pkeeper said:
Well, crap on a cracker...
Okay, so after reading the dumbed down facts about the issue at hand, it would seem that the latest CWM is not completely at fault for bricking devices. This most likely happened to users who were already on ICS and who already had a kernel that will allow the EMMC_CAP_ERASE to execute over a chip incapable of handling it.
The reports of using the latest CWM and successfully updating to ICS experimental builds without bricking most likely came from people going from stock Honeycomb to ICS?
Any of this true?
Click to expand...
Click to collapse
Yes... You got the point..
strange.
What I understood (not necessarily correct) - simplified and without pointing fingers
the fault is likely in the kernel that is in that recovery 6.0.1.2.
there is another kernel, for the "Android OS", and it could hypothetically contain the same bug, but noone has found any ROM kernel to have the bug.
some developer tried to integrate a (Samsung?) ICS kernel (as released in the opensource for the ROM) in the CWM kernel -
some other developer copied that first developer's work and compiled it for the 8.9 tab
lots of bricked tabs.
So that's not correct? I've been reading about this all day, but I could have missed something in the last few hours.
de3pkeeper said:
The reports of using the latest CWM and successfully updating to ICS experimental builds without bricking most likely came from people going from stock Honeycomb to ICS?
Click to expand...
Click to collapse
I think kallt_kaffe said he flashed at least 10 ROMs using 6.0.1.2 before it failed on him...
Let me look if I can find that back.
orlandoxpolice said:
You guys have a twrp?
Click to expand...
Click to collapse
I've read about that recovery on the 10.1 forums, and on the sub-forum for Galaxy Tab 8.9 SGH-i957 (LTE, 4g version).
But never seen it for the P7300 and P7310.
fred_be9300 said:
I think kallt_kaffe said he flashed at least 10 ROMs using 6.0.1.2 before it failed on him...
Let me look if I can find that back.
Click to expand...
Click to collapse
First.. This bug it doesnt depends how many times you use.. Its random.. Maybe just once or twice or ten times when you wipe..
Second..hardbrick and superbrick is different..superbrick cannot recover with jtag because The chip is broken..
I hope this issue not happen to our tab..we need some testing and investigation..but who can do that?
I guess all samsung device with that kind of type EMMC chipsg is risky when in ICS..
this bug existed for the skyrocket as well as soon as ICS was released, it never existed with gingerbread. seemed completely random as well.
One dumb question: how about if you have already installed ICS kernel. By using CWM 6.0.0.8 or version below and do restore, wipe, etc, will it also brick the tab? Could someone confirm this if it is safe? Or has experience with lower CWM and survive the brick bug? Thanks
nexus_g said:
One dumb question: how about if you have already installed ICS kernel. By using CWM 6.0.0.8 or version below and do restore, wipe, etc, will it also brick the tab? Could someone confirm this if it is safe? Or has experience with lower CWM and survive the brick bug? Thanks
Click to expand...
Click to collapse
All indications are that CWM 6.0.0.8 is 'safe'. The problems appeared to start with 6.0.1.2.
Bump... Just hoping no others get brick from known issue
Hi there!
I'm doing a script for chroot for an easy ongoing GNU/Linux Distro where all can fork it on github and make your own attempts.
A script chrooted like openembedded but it is not.
twitter.com/vicetechno
github.com/vic3t3chn0/zazyl_chroot
The github is where it lies the script.
This is an attempt of an ongoing GNU/Linux where everyone choose which software to package it.
I'll update the script every week.
Thank you so much.
Hi There
Obviously this is still in the early stages and I'm sure you have a plans but 1 question instantly spring to mind
1. How does this relates to Archos Tablets? ( other than the obvious that some G9's have an Omap4460 ) because there are a number of changes that Archos have made to the standard omap kernel. I'd be extremely but pleasantly surprised if you could boot a device using the pandaboard kernel.
This is the the repo for the official archos g9 kernel - git://gitorious.org/archos/archos-gpl-gen9-kernel-ics.git the linux-ics-3.0.21 is the current one in use by the stock firmware.
Myself and @Quallenauge made some further modifications which added a the ability the either boot off the internal or external ramdisk depending on the value of the androidboot.mode which can be passed via the kernel command line and essential turns sde mode into a dual boot mode while leaving standard archos recovery untouched as a safe guard.
@Quallenauge has also ported 3.0.31 and 3.0.58 and is in the process of creating a 3.4 version. All these kernel are located @ https://github.com/Quallenauge/kernel-archos
We are currently using 3.0.58 in the CM-10.1 Rom in this section but all of these should be considered unstable as they haven't been thoroughly
tested.
It's a good idea but not a small task. Also in it's Current state it is far too generic to be relevant to Archos Tablets.
Thanks
Trevd
Hi there!
To answer you.
Yes it is an early stage. To be related to gen9 archos tablets i want to build a own distro to get wiork on pandaboard also gen9 tablets.
I think i've answered you.
Don't hesitate to contact me.
[INFO] Android 4.3 JSS15J&JSS15Q vs. JWR66V&JWR66Y, Custom Kernels and Graphic Issues
So, since this issue pops up often in various threads ever since 4.3 was released, I thought I'd make a thread I could point people to instead of repeating the same explanation over and over.
This has been discussed greatly in various Kernel/ROM development threads and I've been even getting PM's about it so I'll try explaining everything here. Most info is taken from discussions made on CyanogenMod-related threads, Franco kernel thread, thracemerin's WiFi-fix thread, and Google-related sources, so thanks also goes to everyone who participated.
On to business...
Background:
When Google released Android 4.3, it came in a few forms. One is the familiar OTA update zip and factory images. This is what people refer to as 'stock'. The build number for that stock release is JWR66V, also known as Android 4.3r1. This was later updated to JWR66Y (Android 4.3r1.1).
As you all know, Android is open source, which leads us to the Android Open Source Project (AOSP). This is where the source for Android located, and one could build the operating system/kernel (with provided drivers) from scratch and make a working flashable operating system. This is also the 'base' for custom ROMs.
AOSP has newer android revisions - Android 4.3r2.1, build number JSS15J, and Android 4.3r2.2, build number JSS15Q. These builds are newer than 'stock' JWR66V/JWR66Y, but they are official, are made by Google, and are available for anyone to build from scratch, just like JWR66V/JWR66Y. The differences are Google Apps, such as Google+, YouTube, Gmail, etc, which will not be included in an AOSP build, but could be downloaded from the store (or available as a flashable zip) anyway. AOSP also has a different browser while 'stock' comes with Google Chrome (which you could manually download if you wanted to). The system itself is still the same Android. If one decides to build Android from the older JWR66V/JWR66Y revisions, they will have the same system as someone else who flashed stock.
Why didn't Google release JSS15J as stock?
A Google employee mistakenly thought that JSS15J only has changes related exclusively to the new Nexus 7 device. He later apologized and acknowledged his mistake. JSS15J has an updated Nexus 4 kernel with dozens of GPU commits/improvements.
Which build is better?
Depending on who you ask. If newer is better, JSS15Q is better. If factory images are better, JWR66Y is better.
Which build should I use?
People who like factory images will stay with factory images. People who like the stock experience but care less about "factory images" could use a clean non-customized JSS15Q build. In a way, JSS15Q could be considered 'stock AOSP' if it's not customized. It's even more minimalistic than what comes with the factory images, because applications such as Google Keep/Earth/Maps and so on are not forced as system apps, and can be optionally installed from the store only if you want them.
Any other differences besides the updated kernel/GPU commits?
Most changes are under-the-hood. There was an updated network setting found in JSS15J/Q that doesn't exist in JWR66V/Y.
I heard something about a Wi-Fi change though?
There is indeed a major difference related to Wi-Fi. I won't get into many details here as there is a dedicated thread with months of discussions, but in short, JWR66V & JWR66Y still have the Wi-Fi notification delay issue that 4.2.2 had. This is because Google turned off ARP offloading for those builds, but later turned it on in JSS15J & JSS15Q. It was also on in JWR66N, the leaked unofficial build that we got prior to the official release.
If Google were to build a new factory images now from JSS15Q, it would have ARP offloading on, and Wi-Fi notification delays fixed. The change is only to an .ini file and the drivers are the same, so while a fix is needed for JWR66V/JWR66Y, it's a simpler fix. If you use JSS15Q you don't have to flash any Wi-Fi fixes at all.
What does this mean for Custom ROMs?
Custom ROMs are usually synced with the latest AOSP revisions and changes. CyanogenMod's Android build is JSS15Q, and the same goes for rasbeanjelly, Carbon, and most custom ROMs. Clean or clean-ish JSS15Q AOSP builds are also available for those who still want both the newest revision and the stock experience, just check the development threads.
HELP! My screen is stuttering and/or has weird green colors and/or doesn't respond properly to touch and/or is yelling at me!
That is mostly why this thread was needed. As mentioned before, JSS15J&JSS15Q have an updated kernel with some GPU fixes. This means that your kernel MUST match your ROM for the issue to go away. There are workarounds, such as disabling hardware overlays, but that is not really a solution. No hardware overlays = reduced performance and possibly other issues.
The basic rule is this:
If you use JWR66V/JWR66Y, either stay with its stock kernel, or MAKE SURE the custom kernel you flash was based on JWR sources.
If you use JSS15J/JSS15Q, either stay with its stock kernel, or MAKE SURE the custom kernel you flash was based on JSS sources.
This is of course a headache for kernel developers, as they need to either drop support for one version, or release two versions each time. Many kernel developers are already offering two version of their kernels - one for JWR-based builds and one for JSS-builds.
This means that if you use the AOSP build or most custom ROMs, you will have the screen issues if you use JWR-based kernels.
So there you have it. Unless some other solution is found, there will have to be 2 kernels - one for each build.
Well done
Wayne Tech Nexus
Anyone have links to a pure AOSP build with literally no alterations?
Sent from my Nexus 4 using Tapatalk 4 Beta
jaju123 said:
Anyone have links to a pure AOSP build with literally no alterations?
Click to expand...
Click to collapse
There are two I know of, they do have some very slight changes you could read about in their threads, I don't know of one with literally zero alterations whatsoever, but again the changes are very minor:
[ROM][JSS15J] aosp 4.3 for Nexus 4
[ROM][28/07/2013] AOSP JSS15J KALO v3.0
Cheers for the clear up, was doing my head in with all the weird builds
Sent from my Nexus 4 using Tapatalk 4 Beta
Is there any way we can (nicely) ask Google to release a factory image from the JSS build? I think that would be the perfect solution, and I don't think it is really too hard for them to push it.
redsmith said:
Is there any way we can (nicely) ask Google to release a factory image from the JSS build? I think that would be the perfect solution, and I don't think it is really too hard for them to push it.
Click to expand...
Click to collapse
They could definitely do it if they wanted to, probably somewhat easily too. The OTA is being pushed slowly for a reason - not just for bandwidth purposes, but so that if some mistake happened, not all devices would be affected. It's probably not a very high priority for them like what happened previously with the December bug, but they could release a JSS15J-from-JDQ39 OTA to devices that haven't been updated yet, and JSS15J-from-JWR6V for those who did update. Posting factory images is easier, and the binaries are already good for both JWR6V and JSS15J. If they chose to release it, we'd forget about this whole thing 1-2 weeks later. But it's hard to say if they'll listen. Might be worth a try as long as it's done in nice/acceptable ways and not by spamming/yelling/threatening and so on.
They won't release new factory images...
Jean-Baptiste Queru said so...
He said both branchs are the same with the only difference in JSS15J being the new stuff for Nexus 7...
The new GPU commits are from the other branch... So that both matchs and don't give tearing effects or other problems...
Enviado do meu Nexus 4
He had some update statements since. Here they are:
In theory, JSS15J should work just as well as JWR66V for the existing devices. In practice, I expect that there could be minor differences (except for the new Nexus 7 where there are big differences), so if you're targeting a single device you might as well use the source code that matches the retail version the most. Personally, I like to live more on the bleeding edge, so when I carry an AOSP device I'm more likely to be running the master branch.
Click to expand...
Click to collapse
Here's an long-ish explanation of what happened:
-For a number of reasons, the kernel is built separately from the Android tree. We submit binaries of the kernel in the Android tree.
-Those binaries are large. In Google's internal tree, there are 1.5GB of Nexus 4 kernel binaries. With the way our tools work, that's 1.5GB of data that needs to be downloaded and stored by each user in each source tree. At the same time, the binaries don't have any significant value, since the value is in the source history, which is stored separately.
-To avoid making every AOSP user download gigabytes of unnecessary kernel binaries, starting with Nexus 4 (and now also in the new Nexus 7), we've been storing kernel binaries in dedicated projects, and I maintain a parallel history for AOSP that only contains the binaries that are necessary. Right now for Nexus 4, that tree is 31MB (to compare to 1.5GB).
-The retail release process of a new version is actually different for existing devices and for the new Nexus 7. To better reflect that, they each got their release branch, with existing devices in the JW branch (jb-mr2-release) and the new Nexus 7 in the JS branch (jb-mr2.0-release). JW entered final stabilization earlier than JS, which means that the jb-mr2-dev branch and the master branch in AOSP are closer to JS than to JW.
-To save space in the AOSP kernel projects, I try to have as few kernel binaries as possible in there, which means that I prepare those branches at the last minute (in this case I did that on Monday). During testing, I don't stage those projects and I manually use kernels directly from the development branches. For Nexus 4, when I did the final staging on Monday, I only included into the AOSP what ships to end users, i.e. from the JW branch, so I explicitly didn't include the kernel from the JS branch and I used the kernel from JW everywhere instead.
-Since the only changes in JS (compared to JW) were supposed to be related to the new devices, I assumed that the N4 kernel would be the same between the two (without actually checking), and I did all my testing of jb-mr2.0-release, jb-mr2-dev and master with the JS kernel (which was easier as it allowed me to use the same process for Nexus 4 and for the new Nexus 7). One of the changes done for the new devices was in the GPU code, in a way that required a new kernel for Nexus 4.
-The fix was to add the JS kernel to the relevant branches in AOSP.
So, there you have it: I mistakenly assumed there there'd be no kernel changes for N4 between JW and JS, and from there I did all my testing with the wrong kernel.
Sorry about that.
JBQ
Click to expand...
Click to collapse
markd0wn said:
He had some update statements since. Here they are:
Click to expand...
Click to collapse
So peolple who are on stock are outdated and still not enjoying all the gpu optizations?
Correct me if im wrong
typed from my NeXuS 4 tasting some revamped Jellybeans (stock 4.3).
C4SCA said:
So peolple who are on stock are outdated and still not enjoying all the gpu optizations?
Correct me if im wrong
typed from my NeXuS 4 tasting some revamped Jellybeans (stock 4.3).
Click to expand...
Click to collapse
Technically you are not wrong. It's a fact that JSS15J and its kernel has GPU optimizations/commits that are not included in the JWR66V build.
markd0wn said:
Technically you are not wrong. It's a fact that JSS15J and its kernel has GPU optimizations/commits that are not included in the JWR66V build.
Click to expand...
Click to collapse
So this 4.3 update is a huge fail for nexus 4 owners... And i was thinking that i wasnt going root it again...
Google messed up this time
4.3 is almost all about the gpu opt. and now people dont have it all on stock? ? ?
typed from my NeXuS 4 tasting some revamped Jellybeans (stock 4.3).
C4SCA said:
So this 4.3 update is a huge fail for nexus 4 owners... And i was thinking that i wasnt going root it again...
Google messed up this time
4.3 is almost all about the gpu opt. and now people dont have it all on stock? ? ?
typed from my NeXuS 4 tasting some revamped Jellybeans (stock 4.3).
Click to expand...
Click to collapse
I don't know how huge those optimizations are. I'm sure someone will do some GPU-specific benchmark comparison between the builds at some point and see. But yes, a mistake did occur. The average person will be updated to JWR66V (at least at this point) only. Others could install JSS15J manually from one of the threads mentioned in the previous page.
Thanks for the info. I flashed the factory images last night thinking I would much rather go with official images from now on. This thread tempted me to give the AOSP builds another try.
Honestly though, I don't know important the optimizations are. Maybe it's just me. Maybe it's just my own device...... but I find the stock build smoother than the AOSP builds. I get stutters while scrolling through my mms messages, for instance. And transitions on the stock feel smoother so far.
How does one know if we have delays in our wifi notifications though?
markd0wn said:
They could definitely do it if they wanted to, probably somewhat easily too. The OTA is being pushed slowly for a reason - not just for bandwidth purposes, but so that if some mistake happened, not all devices would be affected. It's probably not a very high priority for them like what happened previously with the December bug, but they could release a JSS15J-from-JDQ39 OTA to devices that haven't been updated yet, and JSS15J-from-JWR6V for those who did update. Posting factory images is easier, and the binaries are already good for both JWR6V and JSS15J. If they chose to release it, we'd forget about this whole thing 1-2 weeks later. But it's hard to say if they'll listen. Might be worth a try as long as it's done in nice/acceptable ways and not by spamming/yelling/threatening and so on.
Click to expand...
Click to collapse
Agreed. Any way we can contact them? Maybe in their support pages? I'm kind of lost here =D
We should definitely give it a try, we've got nothing to lose.
Why I can't boot into recovery?
I flashed factory image JWR few days ago, everything was good until today I just realized that I cannot boot into stock recovery. Everytime I enter bootloader and select recovery I only get dead android image with red exclamation mark.
Anybody experience this too?
Wonderful! I've been looking for somerthing since 25/07!
Thanks!!
simorangkir_dcs said:
I flashed factory image JWR few days ago, everything was good until today I just realized that I cannot boot into stock recovery. Everytime I enter bootloader and select recovery I only get dead android image with red exclamation mark.
Anybody experience this too?
Click to expand...
Click to collapse
Hold volume up + down and press the power button (may have to do it a few times). The stock recovery has its options hidden unless you press that combination once you get to the screen you are seeing.
Sent from my Nexus 4 using Tapatalk 4 Beta
mattkroeder said:
Thanks for the info. I flashed the factory images last night thinking I would much rather go with official images from now on. This thread tempted me to give the AOSP builds another try.
Honestly though, I don't know important the optimizations are. Maybe it's just me. Maybe it's just my own device...... but I find the stock build smoother than the AOSP builds. I get stutters while scrolling through my mms messages, for instance. And transitions on the stock feel smoother so far.
How does one know if we have delays in our wifi notifications though?
Click to expand...
Click to collapse
Can someone confirm this?
mattkroeder said:
Thanks for the info. I flashed the factory images last night thinking I would much rather go with official images from now on. This thread tempted me to give the AOSP builds another try.
Honestly though, I don't know important the optimizations are. Maybe it's just me. Maybe it's just my own device...... but I find the stock build smoother than the AOSP builds. I get stutters while scrolling through my mms messages, for instance. And transitions on the stock feel smoother so far.
How does one know if we have delays in our wifi notifications though?
Click to expand...
Click to collapse
Same too ,i feel stock smoother than AOSP .
Sent from my Nexus 4 using Tapatalk 4 Beta
Welcome to the first custom kernel for the KitKat Shield.
This thread is for the development and building of the Shield Portable kernel.
This is not intended to download a build, post issues, and return when fixed.
Kernel Source:
https://github.com/StarKissed/starkissed-kernel-roth
Kernel Downloads:
https://goo.im/devs/playground/shieldroth
The kernel can be built using the commands below or the included script.
Code:
make tegra11_android_defconfig -j$CPU_JOB_NUM ARCH=arm CROSS_COMPILE=$TOOLCHAIN_PREFIX
make tegra114-roth.dtb -j$CPU_JOB_NUM ARCH=arm CROSS_COMPILE=$TOOLCHAIN_PREFIX
make -j$CPU_JOB_NUM ARCH=arm CROSS_COMPILE=$TOOLCHAIN_PREFIX
App & Donations:
StarKissed [SKU] on Google Play allows you to configure many of the options provided by this kernel. Issues or comments about the app can be posted at the XDA StarKissed app thread
Donations are not being collected through the forum. If you would like to donate, you may do so through StarKissed [SKU] on Google Play by using the donate options located in the top right (the green dollar bill guy).
[Kernel] Shield Kernel Development
The included ramdisk is for update 98. If you are on 72, this will most likely result in a bootloop. Using the 72 ramdisk will not work with this kernel, as the source is specific to "OTA 5" according to the Nvidia gitweb.
I recently updated the source and changed a few commands that may explain why current source resulted in non-working builds. I will be testing builds soon and then begin modifying the kernel once the core build is verified working.
Nice, I hope there will also be an overclocked kernel for 4.4. I know it's silly but I miss the 4.3 overclocked kernel.
rylen said:
Nice, I hope there will also be an overclocked kernel for 4.4. I know it's silly but I miss the 4.3 overclocked kernel.
Click to expand...
Click to collapse
All the code is there, it just loops. I'm not sure what's going on with it. The shield tablet version works.
Quick question. Any chance you could update the usb ethernet drivers in this? Specifically, I'm suffering from this bug on an ASIX 88772 on the official kernel, and it seems their driver is rather out of date. Thanks, and keep up the good work!
bakageta said:
Quick question. Any chance you could update the usb ethernet drivers in this? Specifically, I'm suffering from this bug on an ASIX 88772 on the official kernel, and it seems their driver is rather out of date. Thanks, and keep up the good work!
Click to expand...
Click to collapse
Won't do much good until it boots
True enough, just thought I'd bring it up since it's a fairly easy fix. In the meantime, I threw together a stock kernel with an updated driver to get by. I had one problem after another with the latest official driver, but the good folks at LKML had already put some work in on v4.1.0 several years ago. Using drivers/net/usb/asix.c and usbnet.c from the 3.4.106 source built without problems.
Beginning to think I may have to settle for building against the full source on this one. It boots fine when doing that, but not built alone. The shield tablet builds fine alone, so there's no explanation for it.
you are going to make a new build of your kernel? if you need help with the tests i can help.
YamazakiRobert said:
you are going to make a new build of your kernel? if you need help with the tests i can help.
Click to expand...
Click to collapse
Things are a bit crazy, but once I can get all of the changes fixed up and it'll build clean, I'm going to try to run it over night.
Slightly off-topic, but I'll ask you since you're the only other person I know building a shield kernel. I built nvidia's kernel, changing only the two drivers associated with my ethernet, but for some reason console mode has stopped working now. Have you ran into a similar problem? Plugging HDMI in pops up the selector, but clicking on console mode doesn't do anything - it just stays on the selector screen.
bakageta said:
Slightly off-topic, but I'll ask you since you're the only other person I know building a shield kernel. I built nvidia's kernel, changing only the two drivers associated with my ethernet, but for some reason console mode has stopped working now. Have you ran into a similar problem? Plugging HDMI in pops up the selector, but clicking on console mode doesn't do anything - it just stays on the selector screen.
Click to expand...
Click to collapse
It shouldn't be related. You may need to check the proprietary drivers. I believe HDMI is one.
Didn't bother to find out what the problem was, it just stuck around because I was doing dirty builds as I tested. Once I got a few other tweaks and had some time, I did a clean build and it resolved itself. Did you manage to get your kernel booting when building it by itself? I'm sure I'm doing something wrong there too, but I've been grudgingly building the entire device, since that at least works reliably.
What is so special about this kernel compared to stock ? goodjob already btw, you're one of the few who actually have a kernel
It's really sad how not much development is going on, it's such a good device there is only like 1 release at the original section :/
Hi,
since the official maintainer "solk2" for the GT-I9506 moved on to CM12 before providing a final build incorporating his latest fixes I decided to make my own builds.
According to my personal experience the battery life has vastly improved. In particular the power consumption while the display is off has decreased substantially. Solk2 has apparently fixed some issues with the kernel so the battery issues are gone. So for everyone not yet willing to transition to CM12 (in my case inter alia due to the currently unstable state and the lack of a stable Xposed framework in Android 5) this might be a good alternative.
I will gladly share my unofficial ROMs, however I would need someone to host the files in order to do that. If anyone would be so kind as to host ROMs please let me know.
If any relevant code changes to CM11 will appear I will most certainly compile a new version.
* IMPORTANT *
Please note that these builds are based on nothing else than the unchanged official code from Cyanogenmod, solk2 and others. So every credit goes to them.
I will not and cannot make any changes to the code. The only thing I can do and will do is build a ROM thereof in case some interesting fixes etc. appear. However, since CM11 is becoming outdated there will most probably not be a lot of changes to come.
Also, it should be understood that I take no responsibilities whatsoever if anything goes wrong when you install the ROM. Like the original ROM this is completely at your own risk!
However, you can expect that any ROM I share has been installed on my own GT-I9506 (with Samsung firmware of 4.4.2 nordic countries) and runs without obvious issues. Your mileage may vary.
Here is the current version, including the CM-11.0 code base up to http://review.cyanogenmod.org/#/c/97688/ :
https://www.mediafire.com/folder/j0jynk3en95j5n1,soag9jcmrcajdhq/shared
* Note *
At least some of the issues with solk2's latest official builds were apparently caused by preceding changes to the kernel code. My builds use the latest code base of February 16 incorporating solk2's latest fixes (see https://github.com/CyanogenMod/android_kernel_samsung_ks01lte/commits/cm-11.0).
Unless solk2 will make further changes to the kernel (which I doubt as he has turned his attention to CM-12) the changes in my builds are only related to merged changes in the official Cyanogenmod code for CM-11.0 (see http://review.cyanogenmod.org/#/q/status:merged+branch:+cm-11.0). In other words the kernel will remain the same, even if the build date thereof may change.
Thank You. Perfect rom. in 2015-05-20 mms is working by default I have not find any bugs.
I'm on arter97 CM12.1 and I'd like to try this one. I can imagine a such install procedure:
-flash kk stock firmware (CNJ1 nordic) from odin
-reboot
-flash custom recovery from odin
-reboot
-flash your rom from custom recovery
Is that right?
ilfavi said:
I'm on arter97 CM12.1 and I'd like to try this one. I can imagine a such install procedure:
-flash kk stock firmware (CNJ1 nordic) from odin
-reboot
-flash custom recovery from odin
-reboot
-flash your rom from custom recovery
Is that right?
Click to expand...
Click to collapse
You do not need flash any stock. Just flash TWRP, make full wipe and flash this rom + gapps
Why is this rom so ignored? I flashed it a few days ago and I find it's great. Very very fast and absolutely rock solid. No bugs, no fc, no reboots.
ilfavi said:
Why is this rom so ignored? I flashed it a few days ago and I find it's great. Very very fast and absolutely rock solid. No bugs, no fc, no reboots.
Click to expand...
Click to collapse
I do not know how many have installed this ROM (anyone having done so please leave a reply here).
I see only a very limited number of reasons to transition to a new version of a ROM or Android in general:
1. If the new version provides functionality that I want or need (and material design isn't one of those); or
2. If the new version fixes a bug or security flaw (there is none that I know of).
At the moment CM-12 does not fulfill any of these criteria, instead I would lose the solidly working Xposed framework for an alpha version thereof.
I'm not intending to advertise this ROM, inter alia because the only thing I did was build it, so the credits should still go to solk2. But if anyone hears that someone has issues with the latest "official" version of CM-11, please direct them here.
HI !
This rom is awsome (smooth fast and stable) but is lacking of functionality...
@NeuDLi do you think I can use this rom for patchrom miui v5 or v6 on ? (as base)
And thanks for your work !
3lambda said:
HI !
This rom is awsome (smooth fast and stable) but is lacking of functionality...
@NeuDLi do you think I can use this rom for patchrom miui v5 or v6 on ? (as base)
Click to expand...
Click to collapse
I suppose so... Since it does use the official CM sources, just go ahead and try it.
Thanks for the reply
Do you have some knowledge on building stuff ? (via linux command, problem etc)
What should happen if I update via OTA as it ask me to do?
edit: I realized that the updates suggested are cm12 so can be ignored
I had one strange bug in this rom (maybe reason was in gapps): Go to SMS app, push new and write name in address line from above: phone getting list of contacts to chise. You choisew one and see wrong number (without region code) in address line.
If you push on contacts button and choise contacts here everything will be ok.
NeuDLi said:
I do not know how many have installed this ROM (anyone having done so please leave a reply here).
I see only a very limited number of reasons to transition to a new version of a ROM or Android in general:
1. If the new version provides functionality that I want or need (and material design isn't one of those); or
2. If the new version fixes a bug or security flaw (there is none that I know of).
At the moment CM-12 does not fulfill any of these criteria, instead I would lose the solidly working Xposed framework for an alpha version thereof.
I'm not intending to advertise this ROM, inter alia because the only thing I did was build it, so the credits should still go to solk2. But if anyone hears that someone has issues with the latest "official" version of CM-11, please direct them here.
Click to expand...
Click to collapse
Do you know to make compatible with this ROM, the Arter97 kernel?
Alexyerga said:
Do you know to make compatible with this ROM, the Arter97 kernel?
Click to expand...
Click to collapse
No, as stated I'm not a coder. And also why use Arter97 kernel anyway?
NeuDLi said:
No, as stated I'm not a coder. And also why use Arter97 kernel anyway?
Click to expand...
Click to collapse
Because the Solk2 kernel causes random reboots sometimes
Alexyerga said:
Because the Solk2 kernel causes random reboots sometimes
Click to expand...
Click to collapse
Then maybe you should ask Arter97 what's different in his kernel... Without any hint what difference causes this no-one has a realistic chance to find out. Or ask him to adapt his kernel to CM-based ROMs. I didn't know that his kernel does not work with CM, is that so?
Also, on my S4 I do not have frequent reboots. However, I once activate the advanced option "kernel samepage merging" and then had two reboots in 1-2 days. After resetting to deactivated no more reboots since about 2 weeks... Worth a try to check.
I would like to help, but I simply do not have anywhere near the experience and knowledge to find a kernel bug that apparently solk has not found himself!
NeuDLi said:
Then maybe you should ask Arter97 what's different in his kernel... Without any hint what difference causes this no-one has a realistic chance to find out. Or ask him to adapt his kernel to CM-based ROMs. I didn't know that his kernel does not work with CM, is that so?
Also, on my S4 I do not have frequent reboots. However, I once activate the advanced option "kernel samepage merging" and then had two reboots in 1-2 days. After resetting to deactivated no more reboots since about 2 weeks... Worth a try to check.
I would like to help, but I simply do not have anywhere near the experience and knowledge to find a kernel bug that apparently solk has not found himself!
Click to expand...
Click to collapse
Last time ago arter's kernel was compatible but he removed the support because he didn't have time to maintain two kernels.
Thanks anyway NeuDLi, i will tray the option "kernel samepage merging", it cames activated or deactivated by default? Because when I tried, I didn't change any option
Alexyerga said:
i will tray the option "kernel samepage merging", it cames activated or deactivated by default? Because when I tried, I didn't change any option
Click to expand...
Click to collapse
Well, another problem... I'm not sure if it is a bug in settings.apk or only in connection with our device. However, when you check the option is always ON, and upon leaving the settings.apk it will always return to being ON. So at least I can say that turning if OFF cannot have had an effect because it was never turned OFF.
However, I will try with KSM disabled now. For the time being you can manually disable it and lock this state (well at least until next reboot) by doing the following in an adb session or the terminal:
echo 0 > /sys/kernel/mm/ksm/run
chmod 444 /sys/kernel/mm/ksm/run
Another way would be to recompile the kernel with the option disabled. It would be far better to fix the issue in settings.apk. However, to file a bug report one would have to check if the behaviour is the same in the official nightlies... I read that someone reported this as a bug for the Oneplus One, but it was never resolved.
As an somewhat veteran in other xda-like forums, I advertised link to neudlis reply with his/her first build because it has been rock stable and fast. With my I9506 nordic.
No other customs have been this solid for 3 weeks straight, and I have been trying roms since december !
iBuu said:
As an somewhat veteran in other xda-like forums, I advertised link to neudlis reply with his/her first build because it has been rock stable and fast. With my I9506 nordic.
No other customs have been this solid for 3 weeks straight, and I have been trying roms since december !
Click to expand...
Click to collapse
Although I cannot often enough remind everyone that I did not provide or change any code but just build it that's still not too bad for the first build of a guy not that much into coding .
After a weekend with not much use but some hours of listening to audio books I was left with 21% charge after more than 3 days (see attached screenshot). That's just awesome! So I believe it can safely be said that any power consumption bug was resolved by solk2's latest patches to the kernel.
Also I believe that turning off kernel samepage merging might have helped additionally, so I encourage everyone to try it as well (see above post for manual way to turn it off as bug in settings.apk won't let you otherwise). In my opinion this option should default to off as it is said to be potentially unstable and the I9506 surely has enough RAM not to need it. So I prefer to lessen CPU load for longer battery life in exchange for potentially increased RAM occupation.