[Kernel][Request] - HTC Stock Sense kernel with GPU+ 5pt multi touch? - Droid Incredible Android Development

Would any dev or anyone who knows a bit about compiling be able to do this? I've tried some other kernels, and generally love some of the features and performance they bring, but none of them has been 100% stable for me. Stock kernel is 100% stable, but lacks the 5 point multitouch which I do use for emulators, and GPU+ which makes a noticeable difference in 3D graphics smoothness.
The closest I found was HeyItsLou's #8 (I might have the number wrong) which runs great, has the multitouch, but no GPU+ Lou's has some other good features that seem to help smoothness and battery life too.
Maybe Lou or someone could throw GPU+ into that kernel? Or just take the stock kernel and add GPU+ and multitouch? Would anyone else be interested in this?

Um what about the. 32 incredikernel?
Sent from my ADR6300 using XDA Premium App

That's what I'm running now but it will randomly peg the CPU (system panel shows Android System as maxed out) and slow the phone to a crawl, requiring a reboot. And no, I'm not running SetCPU. That is the ONLY problem I have with that kernel, but I've never had that happen on the stock kernel. I don't want to deal with the random lockups anymore.
Ziggy's kernel doesn't have the lock ups, but doesn't run as smooth either, and I notice a lot of stutters while gaming.

I don't know why that would be. I compiled it for someone a few days ago and he loves how it runs.
Sent from my ADR6300 using XDA Premium App

what is 5pt multi touch?????

jdog94 said:
what is 5pt multi touch?????
Click to expand...
Click to collapse
Just that, you are able to use five fingers (or "points") simultaneously.
From my understanding, multitouch is affected by the touch panel you have, and also the way it is flashed. There was a compatible recovery floating around a while ago, but it's no longer maintained.

Yeah not all phones support 5pt
Sent from my ADR6300 using XDA Premium App

Phydo - I've actually been running your undervolted version of Chad's kernel for the last few days. I'm still having the same issue. In Chad's thread, there were actually a few people having the exact same issue. It was thought that SetCPU was somehow to blame, but again, I don't even have that installed.
From a performance standpoint, Chad's kernel is the one I've had the best results with and keep going back to, but this issue with the CPU getting stuck at 100% load happens regularly, every 24-48 hours.

bast525 said:
Phydo - I've actually been running your undervolted version of Chad's kernel for the last few days. I'm still having the same issue. In Chad's thread, there were actually a few people having the exact same issue. It was thought that SetCPU was somehow to blame, but again, I don't even have that installed.
From a performance standpoint, Chad's kernel is the one I've had the best results with and keep going back to, but this issue with the CPU getting stuck at 100% load happens regularly, every 24-48 hours.
Click to expand...
Click to collapse
I'd be willing to bet your problem is the ProcessStats.java bug documented in Issue 9733. It is exacerbated by kernels that add extra frequencies. Some ROMs work around the issue by making the time_in_state file unreadable, but SetCPU undoes this workaround every time you open it. 24-48 hours seems about right for the time it was taking for me to run into this problem. I'm now running with an init.d script that redoes the chmod 600 every 5 minutes just in case I open SetCPU and the problem has gone away.

Aweaver33 - would this be something I could easily incorporate into my own ROM? I'm running a mostly stock ROM that I customized by adding an earlier Evo framework and taking out some stuff I didnt want. Would I be able to flash your init.d script? Or since I don't run setcpu, could you explain or point me somewhere I could figure out how to make time_in_state unreadable?
EDIT: nevermind.... aweaver you are awesome for posting that link. I will try to chmod the time_in_state file as outline in that thread and see if I can make it 48 hours without it making the cpu.
Do you know how specifically this is kernel related? I've had this issue with Chad's kernel, and the old KingKlick kernels. I have NOT had the issue on the very old Hydra kernel or any of the stock kernels. I guess its just the number of frequencies they enable? Man if chmod'ing that file is all it took to fix that bug.... you are my friggin hero dude. I've been mostly using Chad's kernel since December and love it but MAN I hated the phone locking up every two days!

bast525 said:
Do you know how specifically this is kernel related? I've had this issue with Chad's kernel, and the old KingKlick kernels. I have NOT had the issue on the very old Hydra kernel or any of the stock kernels. I guess its just the number of frequencies they enable?
Click to expand...
Click to collapse
Yeah, it's mostly just the number of frequencies they enable. Also a potential, but smaller, contributor would be governor settings that result in a more even distribution of frequencies, which would result the overall file size getting larger more quickly. I first noticed this issue when I was doing stability testing that intentially created an even distribution of frequencies and made it less than a day before triggering the bug.

Well, I'm at 36 hours of running now, so far no issues. I did open the time in state file and noted it is still updating, though the permissions were correctly changed.
My only problem now is the leaked GB roms that popped up today... I want to flash one but I REALLY want to see if after six months of dealing with this very annoying bug, if it is finally fixed. I gonna TRY to resist flashing til tomorrow.

Any way to make the change in permissions to the time in state file stick? It undoes the changes on reboot

bast525 said:
Any way to make the change in permissions to the time in state file stick? It undoes the changes on reboot
Click to expand...
Click to collapse
That's where the init.d script comes in. Put the following in a file in /etc/init.d/ and set permissions to 755:
Code:
#!/system/bin/sh
while [ 1 ]; do
chmod 400 /sys/devices/system/cpu/cpu0/cpufreq/stats/time_in_state
sleep 300
done

If there is no /etc/init.d folder, and I create and throw that file in there will it work?
EDIT: nevermind... tried it, didn't work. Created the folder, put the file I'm there, rebooted. Let phone sit five mins, looked at permissions for time in state file, they were still at default. Does it need to have an extension? I just named it "fix".

Sorry, it looks like the /etc/init.d/ directory is not standard Android. The following is the last line in my /bootcomplete.inc.rc file, which looks like what enables running the scripts in the /etc/init.d directory:
Code:
/system/xbin/busybox run-parts /system/etc/init.d
I'm not sure if that line was automatically added when I installed busybox, or if something else put it there.

It's cool, I found an alternate method. There's a very small app in the market simply called "Autostart", to use it you create a script, name it autostart.sh, drop it in a folder you create in /data/, and it runs at boot same as if it were in init.d. I took your script and modified it a bit to make it not repeat every 300 seconds. I don't run SetCPU so I only need it to run once at start up.
I still haven't let the phone run for 48 hours straight to verify this fixed it, but still man thank you for the info, it is greatly appreciated. After reading that Google bug thread you linked, I have very high hopes that this is the fix I've been looking for for six months now.
Thanks again man and I'll report in a day or two as I have no more reasons to reboot for a while.

48 hour mark just passed and still running like a champ

Related

CM-5.0.5/6: "akmd" alwasy takes up to 3% cpu

guys, I found out that the G-sensor daemon "akmd" alwasy takes up to 3% cpu on my N1 with CM-5.0.5/6.
I compared with stock ERE-27 rom, in which "akmd" in that takes less than 1%.
While during standby, it take no CPU usage.
Does it matter? I mean, would that kill our battery?
Actually I first found that out when I was using CM-5.0.5. One day I put my fully charged N1 beside my pillow and after 7-hr sleep, only 86% power left..
Maybe it has something to do with the 360 degree launcher2.
I personally don't use that feature. I'm gonna take a look at my usage.
I just noticed this as well while tinkering.
Gimpeh said:
I just noticed this as well while tinkering.
Click to expand...
Click to collapse
I realize I'm bumping an older thread now but I still feel this might be relevant.
Running top at any point will still show "/system/bin/akmd" which is the system daemon for the compass.
In my case, it almost always resides underneath "system_server". I've tweeted it at Cyanogen once but got no response to my question.
So, after doing some digging, I pulled down the SDK and fired up the "Dalvik Debug Monitor" here's what I saw (See attached: android-troubleshooting2.jpg)
Edit: i42.tinypic.com/m953rq.jpg
Not that it needed reiterating but the AK8973 is the 3-axis compass chip and something calling it or (the driver itself) is throwing an error almost precisely every 10 seconds. Now, I belive this has only been happening since the upgrade to CM5.0.6-N1 (Although I am now on CM5.0.7-Test1) either way whatever bug there is, still remains.
Edit: i40.tinypic.com/21liauh.jpg
Googling for that error: "Compass driver encountered fatal error2" pulls up a single page in the CyanogenMod Forums and two error logs on PasteBin.
Bump!!-Bumb!!
Thanks for the bump! Being a lurker has it's definite disadvantages.
prophetjinn said:
Maybe it has something to do with the 360 degree launcher2.
I personally don't use that feature. I'm gonna take a look at my usage.
Click to expand...
Click to collapse
In my testing, the use of 360º rotation nor the setting of "Launcher Rotation" changed whether akmd was consuming resources.
Full size image link: i40.tinypic.com/dxh0yu.jpg
Just as GaryD had posted here:
forum.cyanogenmod.com/index.php?/topic/3129-ak8973-compass-driver-encountered-fatal-error2
after a reboot the errors disappear for a while. I don't know the pattern to which they reappear (e.g. due to a buffer overflow or some other reason.)
confirmed...
I think this issue is with newer kernels. I saw it on various versions of CM before switching to enom's TheOfficial rom. Doesn't exist on unmodified versions of enom's rom, but I just loaded several of the newer 2.6.33.x kernels and all show akmd using 1% cpu while the phone is sleeping.
Additionally, power drain while sleeping with these kernels is between 5 and 7 milliamps, while with the stock rom (and enom's stock kernel) it is between 3 and 5 milliamps.
If anyone wonders how I am getting these numbers, I am using OSMonitor (from the market). I sort the processes, reversed, by CPU%. To get the power drain, I look at the dmesg log and filter for the "batt" tag.
I may post this as a new topic for the kernel devs to review if it gets no attention here...
bubbahump said:
I think this issue is with newer kernels. I saw it on various versions of CM before switching to enom's TheOfficial rom. Doesn't exist on unmodified versions of enom's rom, but I just loaded several of the newer 2.5.33.x kernels and all show akmd using 1% cpu while the phone is sleeping.
Additionally, power drain while sleeping with these kernels is between 5 and 7 milliamps, while with the stock rom (and enom's stock kernel) it is between 3 and 5 milliamps.
If anyone wonders how I am getting these numbers, I am using OSMonitor (from the market). I sort the processes, reversed, by CPU%. To get the power drain, I look at the dmesg log and filter for the "batt" tag.
I may post this as a new topic for the kernel devs to review if it gets no attention here...
Click to expand...
Click to collapse
Since I haven't run any other roms I was hesitant to drag anyone else's ROMs into the discussion. I've seen it with InsectrRaven and the Pershoot but they're obviously all pulling from CM's commits on Github. I realize they're not large amounts of cycles but any usage that can be minimized is something. Right? Maybe I'm just a minimalist at heart.
Much appreciated on the bump and the bump towards the devs.
Another confirm here.
I'm on CM5.0.7-test2 with pershoot 2.6.33.4 kernel. Mine was steady at 6% CPU though.
Confirmed..
E/AK8973 ( 101): Compass driver encountered fatal error2 is thrown in every 10 seconds.
CM-5.0.7.1-N1
Kernel 2.6.33.4-cyanogenmod
this TOTALLY makes sense to me. used the stock ROM for last 3 months and had great battery life. after using cyanogen 5.0.7 the last 4 days, battery life is much worse than the stock ROM for me. also different is in cyanogen this "akmd" always shows up in my battery usage, but this never appears in the stock ROM. i'd make a solid bet that this is a cause of the poor battery life on current cyanogenmod, especially if this thing is hitting every 10 seconds with some fatal error. wonder if it can be easily fixed?
I have an EVO, unrooted, no OTA update, fully stock but used the 'top' app to notice the compass /system/bin/akmd consistently using resources.
Disabling auto orientation has fixed it, and done miraculous things for my battery life (battery graphs can have flat lines!), but I want my auto-rotate back. Is this a case of the accelerometer writing out a bad settings file, or it's a bug or what?
I'm still seeing this issue in the latest cyan r c 2 nightly. I'm confused why the compass would be used for the screen orientation. As far as I know, we are talking about 2 different sensors. The phone has a compass sensor, which is akmd, and also has an accelerometer sensor, which is used for auto screen rotation. The compass I thought is only used in things like maps street view and Google sky map.
Regardless, is there any solution to get akmd to stop running all the time? What process is calling this to even run all the time exactly?
I have the exact same problem (though akmd often takes up 80% here) on Hero with CM6 nightly build Aug 19th. I hope I can simply delete the file somehow.
dvfk said:
I have the exact same problem (though akmd often takes up 80% here) on Hero with CM6 nightly build Aug 19th. I hope I can simply delete the file somehow.
Click to expand...
Click to collapse
was same for me.. i had disabled auto-rotating in "settings->display" and in cyganamod settings.. AND in launcher pro.. (i always lay down on the side and the phone flips and i dont like it).. i did this 2 days ago.. and phone been laggy as **** since then. akmd have had 70-99% cpu all the time.. so i turned it all back on again. and now akmd takes 1% wake and 0% sleeping.. so wierdo.. shud be the other way around!
any updates on this?
having the issue as well, can't get rid of it.
please someone let me know.

JAC kernel bug: using audio randomly kills phone

(I figured to post this in Android Development as it wasn't really a fit for any other forum; and made its own thread since multiple ROMs and threads use non-stock kernels.)
I ran into an issue running JAC's OC/UV kernel, as detailed at http://forum.xda-developers.com/showthread.php?t=806116 . Essentially, whenever any kind of audio was playing, whether through headphones or the speaker, local media (i.e. mp3 player) or remote (i.e., Pandora), at some point the phone would just.. die. Capacitive buttons wouldn't light up, no unlock; music would die; and basically a battery pull was required to turn the phone back on. adb logcat reports nothing - you can see the audio streaming, then the logcat shut off with the phone.
Based on the thread above (and searching the Bionix thread), it seems that a non-stock kernel does this. (There are only a couple of posts out of the thousands on Bionix's thread.) I have not tested KingKlick's kernel, only JAC's; perhaps KK doesn't suffer from this. This issue is independent of overclocking/underclocking the phone (verified by setting JAC kernel to 1000/200, then uninstalling setcpu); Voodoo lagfix (verified by disabling lagfix and running audio for about an hour); and ROM (tested using multiple versions of Franken-Twiz and Hybrid - maybe there's an inherent issue with eugene's mods, but I haven't seen any other posts.)
I suppose this thread serves as a warning/bug report for anyone that might encounter this issue if running a non-stock kernel. The best way to resolve AFAIK is to revert to a stock kernel.
Thank you for posting this! My phone had suffered from this at random times since I started using JAC's kernel. I asked about it in a couple of threads but never got a single reply. Glad to know it's not only me
I'm running the same kernal and about 20 minutes ago running pandora my phone just turned off too and had to pull the battery to restart
Sent from bionix 1.9.1 jacs oc/uv kernel
Had that issue at the Gym the other day, not even on Bionix.
I had similar issues, also with the KK Kernel, its not just JAC's kernel. You don't have to pull the battery either to get out of the freeze, you can hold the power button for several seconds and it does a hard reset.
I have found though that the KK Kernel is less likely to do it if you set your setcpu to 400 min and 1000 max before using pandora. Those settings seems to have worked for me every time..also after setting up pandora make sure to fix permissions with rom manager.
Just a little work around, try it to see if it works for you.
Sent from my SGH-T959 using XDA App
Actually this is a known problem since even the G1.
If you have anything like setCPU, which I do, and you set the idle or lowest speed lower then 400 Mhz the phone will more then likely freeze up when playing music or when going to idle.
I don't remember off the top of my head what causes it to do this when it goes below that certain Mhz, but Im sure I or someone here can dig the old thread up.
Man without this thread I could never get pandora to work with a custom kernal. I setcpu at 400 min and 1000 max and not a single freeze. Thanks so much for posting that tip, you made my day.
Sent from my SGH-T959 using XDA App
Ive had this problem to.... but it was ONLY with Jacs 1.1, I revert every ROM back to his 1.0 and have no problems. Everytime I dont, I get a phone freeze.
I was having this problem with jac's newest kernel so I went back to his first OC/UV, it is a known problem and he's working on it according to his twitter. how I got around this is I used his OC script and got rid of setcpu, from what Quadrant says I'm still running 100/1200. Hope that helps you guys
jmercil said:
I have found though that the KK Kernel is less likely to do it if you set your setcpu to 400 min and 1000 max before using pandora. Those settings seems to have worked for me every time..also after setting up pandora make sure to fix permissions with rom manager.
Click to expand...
Click to collapse
Interesting. I'll try installing JAC OC/UV/Voodoo again and see if this observation is consistent.
r6kid said:
I was having this problem with jac's newest kernel so I went back to his first OC/UV, it is a known problem and he's working on it according to his twitter. how I got around this is I used his OC script and got rid of setcpu, from what Quadrant says I'm still running 100/1200. Hope that helps you guys
Click to expand...
Click to collapse
Yeah, I think the problem only exists when you use the OC kernel with setCPU, and setup setCPU under 400Mhz, other wise the kernel with out setCPU works just fine when it goes below 400Mhz.
Once again I don't remember why it does that but it has something to do with setCPU not being able to initialize properly after the phone goes idle and falls below 400Mhz.
Would have to agree. There's a bug somewhere. Not sure if its limited to jacs though.
Currently on masters rom kk. Only problem is pandora.
i had this problem too. kinda disappointed cause the kernels make everything run so much better. so i had to go back to using stock cause i listen to music a lot :/
There's definitely some hardware variability, because I can't recreate this bug. I listen to music all day long (MixZing, Slacker, Pandora) running 1.8 w/ JAC's OC/UV Voodoo. Never seen this.
Likewise with Jacs 1.1, had a couple other weird issues running that specific kernel too, not a single problem when I flashed back to 1.0
Sent from my T959 running Bionix1.9 with Jacs OC/UV and Voodoo
i get this same thing. ive had it happen with SetCPU both installed and not. right in the middle of a good song bam phone just shuts up. walk over to my toolbox and sure enough the phone is in a state of being divided by zero and only a battery pull lets it return to the world of the living. not greally a good thing when i have sevearl iphone dorks in the shop and they pop on over to my speakers and they say out of the way lets plug in a REAL phone. makes me want to scream LOL. ****ing iphone >_<
i retort with soooo when you get it out of the box....thats it right? nothing can be changed right? oh look that program sucks....what you cant make your own? ...yea...i thought so. hey look im making a call in the scrap room surrounded by 4ft thick concrete walls.... i got full bars lol. they got nothing in the empty parking lot cuz there holding it wrong LOL
Blkegk said:
Man without this thread I could never get pandora to work with a custom kernal. I setcpu at 400 min and 1000 max and not a single freeze. Thanks so much for posting that tip, you made my day.
Sent from my SGH-T959 using XDA App
Click to expand...
Click to collapse
Glad it worked for ya!
Sent from SGSV Bionix 1.9.1 KK OC/UV with the quickness!
sxfx said:
Yeah, I think the problem only exists when you use the OC kernel with setCPU, and setup setCPU under 400Mhz, other wise the kernel with out setCPU works just fine when it goes below 400Mhz.
Once again I don't remember why it does that but it has something to do with setCPU not being able to initialize properly after the phone goes idle and falls below 400Mhz.
Click to expand...
Click to collapse
I tried that though, as you can see in the thread I linked to above. Uninstalling SetCPU didn't help..
I think it's hardware.... One of the unlucky ones....
Try with a stock kernel. Jac and kk kernels do uv by default, which is like overclocking in reverse. It has the same possible stability issues.

[Q] Anyone care to share up-to-date SoD remedies?

There seems to be plenty of us still suffering sleep deaths on our cappies and I figured an up-to-date list of possible remedies would be nice, just in case there's been any progress in figuring out what causes the problem and how one could go about fixing it.
So far the solutions I've tried that did not work for me...
-Increased minimum clock speed
-Increased voltage of minimum clock speed
-Removed Titanium Backup
-Removed all third party apps
-Disabled deep idle
-Removed/didn't use task killers
-Tried various ICS & JB ROMs
-Tried various ICS and JB kernels, including baked-in versions
-Tried i9000 bootloaders
These are pretty much all the details I have so far on these SoDs, hopefully they add up to a possible cause or explanation...
-SoDs happen anywhere from 1-2 times an hour to 1-2 times a day and only when screen is locked/phone is idle
-Having GrooveIP or Skype running doesn't prevent SoDs, but Pandora Radio running seems to prevent it
-Sometimes on a fresh ROM install I can go about 24-36 hours before the first sleep death, but after that they occur normally
-If I unlock the screen every few minutes it seems to stay on. If I let it sit anywhere from 15-30 minutes or longer then it will usually shut off.
-The only time I can get this phone to not suffer an SoD is on stock software(GB KK4). Not sure what this means, but it is aggravating because I would like to have better software.
What remedies have you tried, and what worked/didn't work for you?
johnnyrichter said:
There seems to be plenty of us still suffering sleep deaths on our cappies and I figured an up-to-date list of possible remedies would be nice, just in case there's been any progress in figuring out what causes the problem and how one could go about fixing it.
So far the solutions I've tried that did not work are...
-Increase minimum clock speed
-Increase voltage of minimum clock speed
-Remove Titanium Backup
-Remove all third party apps
-Oneclick back to stock with most recent GB bootloaders
-Disable deep idle
-Remove/don't use task killers
My sleep-deaths are random, almost always occur over night while I'm asleep, can sometimes happen within seconds or minutes after locking the screen. Leaving apps running also doesn't stop the problem(GrooveIP is always running, Skype is running most of the time).
The only thing that stops sleep deaths on my phone is leaving it plugged in.
What remedies have you tried, and what worked/didn't work for you?
Click to expand...
Click to collapse
The first thing I'd try after disabling deep idle is to change kernel. Also, usually sleep deaths happen even when plugged so yours is kinda special lol.
BWolf56 said:
The first thing I'd try after disabling deep idle is to change kernel. Also, usually sleep deaths happen even when plugged so yours is kinda special lol.
Click to expand...
Click to collapse
I've used all sorts of different kernels and ROMs, get SoDs with everything. Some might result in a day or maybe three days of no sleep deaths, but they eventually start right back up without any sort of a "trigger" to cause it...like changing a certain setting or installing a certain app.
I was hoping someone would have determined the actual cause by now but it seems it's still an unknown factor causing it.
johnnyrichter said:
I've used all sorts of different kernels and ROMs, get SoDs with everything. Some might result in a day or maybe three days of no sleep deaths, but they eventually start right back up without any sort of a "trigger" to cause it...like changing a certain setting or installing a certain app.
I was hoping someone would have determined the actual cause by now but it seems it's still an unknown factor causing it.
Click to expand...
Click to collapse
SoD doesn't happen much with JB, it's usually due to deep idle or bad kernel user config (not saying this is the case here).
Have you tried flashing back to stock KK4 and do a clean flash of whichever ROM you want to use?
If you could narrow down what causes it or get some sort of logcat of when it happens, that would probably help. Although, flashing back to stock still seems like the best bet.
Also, you're running on a nightly build (as per your signature). Ever concidered using a daily (stable) ROM?
BWolf56 said:
SoD doesn't happen much with JB, it's usually due to deep idle or bad kernel user config (not saying this is the case here).
Have you tried flashing back to stock KK4 and do a clean flash of whichever ROM you want to use?
If you could narrow down what causes it or get some sort of logcat of when it happens, that would probably help. Although, flashing back to stock still seems like the best bet.
Also, you're running on a nightly build (as per your signature). Ever concidered using a daily (stable) ROM?
Click to expand...
Click to collapse
I've wiped back to stock numerous times and have used many different stable ICS/JB kernels and ROMs. I've tweaked almost every kernel setting possible, tried all sorts of different overclocks, tried deep idle on and off, etc.
The only time I never had SoDs is when the phone was originally stock. Ever since the first time I rooted and ROM'd it I've been getting sleep deaths. I have not tried actually using stock software again to see if the SoDs go away mainly because I don't want stock software.
johnnyrichter said:
I've wiped back to stock numerous times and have used many different stable ICS/JB kernels and ROMs. I've tweaked almost every kernel setting possible, tried all sorts of different overclocks, tried deep idle on and off, etc.
The only time I never had SoDs is when the phone was originally stock. Ever since the first time I rooted and ROM'd it I've been getting sleep deaths. I have not tried actually using stock software again to see if the SoDs go away mainly because I don't want stock software.
Click to expand...
Click to collapse
That's very unusual. If I were you I'd still try to use stock for testing purpose. Oh and I'm sure you already tried this but don't OC/UV.
If you don't get SoD on stock, try flashing something else that people haven't reported SoD on (like AoCP on stock kernel). Which makes me wonder, have you used a JB rom with it's stock kernel (CM10/AoKP)?
BWolf56 said:
That's very unusual. If I were you I'd still try to use stock for testing purpose. Oh and I'm sure you already tried this but don't OC/UV.
If you don't get SoD on stock, try flashing something else that people haven't reported SoD on (like AoCP on stock kernel). Which makes me wonder, have you used a JB rom with it's stock kernel (CM10/AoKP)?
Click to expand...
Click to collapse
Most ROMs I've tried I kept the stock kernel. I'm also on the stock kernel for CM10 at the moment.
I have tried two different AOSP ROMs with their stock kernels and had SoDs on those as well.
I have also tried no OC with at least three different kernels/ROMs.
johnnyrichter said:
Most ROMs I've tried I kept the stock kernel. I'm also on the stock kernel for CM10 at the moment.
I have tried two different AOSP ROMs with their stock kernels and had SoDs on those as well.
I have also tried no OC with at least three different kernels/ROMs.
Click to expand...
Click to collapse
I'm really running outta ideas here.. This doesn't seem normal. Only other thing I can really think of is either that it's coming from a app or it's a hardware problem (maybe battery but somehow doubt it).
So yeah, only thing I could suggest other than stock KK4 and AoCP is to clean flash without restoring your apps (Gapps are fine of course) and use stock kernel.. After that, I'm all outta ideas.
You got some testing to do, I'll be looking forward to the results.
BWolf56 said:
I'm really running outta ideas here.. This doesn't seem normal. Only other thing I can really think of is either that it's coming from a app or it's a hardware problem (maybe battery but somehow doubt it).
So yeah, only thing I could suggest other than stock KK4 and AoCP is to clean flash without restoring your apps (Gapps are fine of course) and use stock kernel.. After that, I'm all outta ideas.
You got some testing to do, I'll be looking forward to the results.
Click to expand...
Click to collapse
The only apps that have been consecutive across all my different software installations have been...
-Gapps
-Gmail
-Facebook
-Pandora
-GrooveIP
-Heywire
-Skype(Only been using this for a couple of weeks so I can probably rule it out)
I could try a fresh CM10 nightly and only run gapps. Maybe wait a few days and then install GrooveIP, wait a few days and then install Skype, etc until I can maybe get an app install to trigger the SoDs.
You mentioned logcats...what are those? Is this some sort of debug log? If so, do you think it could actually pick up any events leading up to an SoD or even log the SoD itself? I'd imagine if that was possible someone would have posted the results by now.
johnnyrichter said:
The only apps that have been consecutive across all my different software installations have been...
-Gapps
-Gmail
-Facebook
-Pandora
-GrooveIP
-Heywire
-Skype(Only been using this for a couple of weeks so I can probably rule it out)
I could try a fresh CM10 nightly and only run gapps. Maybe wait a few days and then install GrooveIP, wait a few days and then install Skype, etc until I can maybe get an app install to trigger the SoDs.
You mentioned logcats...what are those? Is this some sort of debug log? If so, do you think it could actually pick up any events leading up to an SoD or even log the SoD itself? I'd imagine if that was possible someone would have posted the results by now.
Click to expand...
Click to collapse
A Logcat is simply a log of everything your phone does (Logcat Extreme is a good app for it). You'd have to set it to run in background until a SoD happen and then you'd see w/e your phone did before the SoD happened. Could help narrow down the problem. The only thing I'm not sure is if it will save the log before your phone shuts down but that could be something to look into. If not, then it won't be any help eh.
BWolf56 said:
A Logcat is simply a log of everything your phone does (Logcat Extreme is a good app for it). You'd have to set it to run in background until a SoD happen and then you'd see w/e your phone did before the SoD happened. Could help narrow down the problem. The only thing I'm not sure is if it will save the log before your phone shuts down but that could be something to look into. If not, then it won't be any help eh.
Click to expand...
Click to collapse
I'll check out that app right now and report back with any findings.
johnnyrichter said:
I'll check out that app right now and report back with any findings.
Click to expand...
Click to collapse
Booted phone up just now after an SoD and the only log available is the one it just started. So if it logged anything before it looks like it didn't save it. Crap.
One-clicked back to stock GB KK4 and after a few hours I have yet to get a sleep death so far, but overnight idling will be the final test for that. That's with the following installed...
-GoLauncherEX
-Skype
-Gmail
-Facebook
-Opera
-GrooveIP
-Heywire
While installing all my apps I realized that the GrooveIP installation I was using was an apk I got ages ago, one that I don't think has been automatically updating. I thought maybe that could be the issue so I went with a fresh install from the market.
If it turns out that SoDs only appear when rooted/ROM'd then I'll probably toss this phone once I find a replacement because I can't be without my CM10 and devil kernel. I really wish someone could figure out the cause and a possible solution for this.
johnnyrichter said:
One-clicked back to stock GB KK4 and after a few hours I have yet to get a sleep death so far, but overnight idling will be the final test for that. That's with the following installed...
-GoLauncherEX
-Skype
-Gmail
-Facebook
-Opera
-GrooveIP
-Heywire
While installing all my apps I realized that the GrooveIP installation I was using was an apk I got ages ago, one that I don't think has been automatically updating. I thought maybe that could be the issue so I went with a fresh install from the market.
If it turns out that SoDs only appear when rooted/ROM'd then I'll probably toss this phone once I find a replacement because I can't be without my CM10 and devil kernel. I really wish someone could figure out the cause and a possible solution for this.
Click to expand...
Click to collapse
CM10 features can be found in other ROMs. As for Devil, it could be the problem. Hopefully KK4 will be fine, at least we'll have a start point to work from. If you get SoD on it, get rid of GrooveIP and heywire. We'll then know if it's app related.
Sent from my SGH-I897 using xda app-developers app
BWolf56 said:
CM10 features can be found in other ROMs. As for Devil, it could be the problem. Hopefully KK4 will be fine, at least we'll have a start point to work from. If you get SoD on it, get rid of GrooveIP and heywire. We'll then know if it's app related.
Sent from my SGH-I897 using xda app-developers app
Click to expand...
Click to collapse
Still no SoD and that's with/without Skype running. GrooveIP boots with phone.
If it won't SoD on stock software then I wonder what the problem could be? It's SoD'd with every kernel and ROM I've ever tried.
Sorry for the extreme noob moment here, how do I tell if my device went into SoD? Is it when it gets so extremely slow that even the power button seems to have no effect?
I get that a lot when I've been browsing for a few minutes (even on stock browser) or when playing some games.
Sent from my SGH-I897 using xda app-developers app
JoeCastellon said:
Sorry for the extreme noob moment here, how do I tell if my device went into SoD? Is it when it gets so extremely slow that even the power button seems to have no effect?
I get that a lot when I've been browsing for a few minutes (even on stock browser) or when playing some games.
Sent from my SGH-I897 using xda app-developers app
Click to expand...
Click to collapse
SoD means, while idle, that it randomly turns itself off. It was a defect in X amount of phones produced up to a certain IMEI number, and ATT/Samsung at one point offered an exchange program so people can turn theirs in for a model that didn't have the issue.
What you're suffering from is low memory. You probably have apps running in the background that are utilizing X amount of RAM, and your browsing/gaming is eating up the rest which slows down the phone. Some ways to fix this...
-Use a kernel that allows you to increase maximum memory. I think Devil kernel allows up to 396mb with no downsides, and 413mb at the cost of something that has to do with playing a certain video resolution IIRC.
-Use a task killer. This lets you kill running tasks except for those you choose to "lock." Some advise against using a task killer, but honestly I've yet to have a problem with any of them. My favorite is the one you can get for GOLauncherEX.
-Use Titanium Backup to delete(or freeze if you buy the pro version) apps that you don't use that you can safely remove, specifically items that constantly run in the background eating up your RAM.
-Use a different ROM. There's plenty of ROMs out there including slim/aosp/etc releases that are faster and arguably better-performing.
I believe you tried this already but using the I9000 bootloaders seems to have fixed the SoD issue for many people on JB.
I'm not sure if that would change anything, but try flashing Mosaic.
BWolf56 said:
I believe you tried this already but using the I9000 bootloaders seems to have fixed the SoD issue for many people on JB.
I'm not sure if that would change anything, but try flashing Mosaic.
Click to expand...
Click to collapse
I don't think I've tried the i9000 bootloaders. Any time I flash back to stock I use the link in my sig(one-click w/ bootloaders) and those are the GB version. My phone still hasn't SoD'd on stock software/GB bootloaders so I wouldn't think those bootloaders are the problem, but on the other hand I suppose it's possible that a third party kernel/rom clash with them on my phone.
Are there any downsides to using the i9000 bootloaders? Would you happen to have a link to this mosaic thing you mentioned?
ETA: If it matters any, when I got the phone I believe it was on GB KK4 and was never modded before. When I got it I used the easy-root to corn 7.0a method and first ran Legend5 ICS ROM. That was the first time I started suffering sleep deaths. Ever since then I have used the one-click back to stock w/ GB bootloaders before using any other kernel or rom.
I've used several different kernels/cwm versions to obtain root, at least 6 different ROMs, several different versions of gapps, and numerous other kernels after ROM installation. I've also used the baked-in kernel of each ROM for at least several days before upgrading to something like Devil or Sema. SoDs on everything, both ICS and JB.
I have also tried one-clicking back to stock with what I believe were "up-to-date" GB bootloaders. This was posted by another member that did it and fixed his SoD problem. It didn't produce any sort of a change for me.
I have not tried checking for SoDs on just a root(without ROM). I suppose if I did this I could figure out if it's the root or the ROM that is triggering the sleep deaths, but even if I did get any results from that I'm still not sure how to figure out exactly what's causing the problem since this event apparently can't be logged.
johnnyrichter said:
I don't think I've tried the i9000 bootloaders. Any time I flash back to stock I use the link in my sig(one-click w/ bootloaders) and those are the GB version. My phone still hasn't SoD'd on stock software/GB bootloaders so I wouldn't think those bootloaders are the problem, but on the other hand I suppose it's possible that a third party kernel/rom clash with them on my phone.
Are there any downsides to using the i9000 bootloaders? Would you happen to have a link to this mosaic thing you mentioned?
Click to expand...
Click to collapse
Mosaic is a ROM that was made by The Family; http://forum.xda-developers.com/showthread.php?t=1061203
It is I9000 based so I'm thinking you won't get any SoD on it. Thing is that it's not JB based. Devs aren't porting from I9000 anymore so you won't find a I9000 ported JB ROM. (Hoping I'm not wrong on this lol)
And yeah, many users reported that flashing the I9000 bootloaders with a JB ROM fixed their SoD problem. Back in GB, it wasn't suggested to have I9000 bootloaders and run a I897 ROM (music player wouldn't work and some other little things) but it seems fine now.
EDIT: I highly doubt root is the problem.

AOSP Stuttering Issues

So I want to start this out by saying this isnt a Note 4 vs Nexus 6 thread or a complaining thread about how the Nexus 6 sucks.
This is a thread to try and figure out the culprit of an issue I think a lot of us are having, but not all of us.
I was running Euphoria OS for a while, loved it. But there was one nagging issue, it would stutter. It was almost as if there was a delay and the device couldnt process all the frame and would drop them. It was still responsive, just not fluid at all. It wasn't on every single screen or animation, but it would appear on every unlock, opening certain programs and almost always on swiping in a sidebar menu. It is very very noticeable if you put Phase Beam or Sun Beam wallpapers on, the animation was not even remotely smooth. I tried different Kernels (I was decrypted BTW) and all of them showed the same behavior. I then set my governors to Performance to speed up the ramp up time, no change. I adjusted the DPI, no change. Nothing I could do would get rid of the janky issues.
I chalked it up to the ROM and installed the nightly CM build (1/20), the exact same issue appeared even without signing into my Google account. Just the ROM and GAPPS were flashed. Switched to another AOSP (modified) based ROM (not CM based) and the same issue happened again. It seems that only stock unmodified ROM's run smoothly on my device.
Is anyone else seeing this? Does anyone else have any thoughts as to why I am seeing this. I know I am not alone, a few people on Reddit said they saw the same thing on Euphoria (again its not the ROM's fault, its something else).
My device:
32GB Nexus 6
Sandisk/Samsung
Decrypted Androbench numbers on Franco R9:
Fsync ON - SEQ RD 163.46MB/s - SEQ RW 43.35MB/s
Fsync Off - SEQ RD 152.76MB/s - SEQ RW 198.95
altimax98 said:
So I want to start this out by saying this isnt a Note 4 vs Nexus 6 thread or a complaining thread about how the Nexus 6 sucks.
This is a thread to try and figure out the culprit of an issue I think a lot of us are having, but not all of us.
I was running Euphoria OS for a while, loved it. But there was one nagging issue, it would stutter. It was almost as if there was a delay and the device couldnt process all the frame and would drop them. It was still responsive, just not fluid at all. It wasn't on every single screen or animation, but it would appear on every unlock, opening certain programs and almost always on swiping in a sidebar menu. It is very very noticeable if you put Phase Beam or Sun Beam wallpapers on, the animation was not even remotely smooth. I tried different Kernels (I was decrypted BTW) and all of them showed the same behavior. I then set my governors to Performance to speed up the ramp up time, no change. I adjusted the DPI, no change. Nothing I could do would get rid of the janky issues.
I chalked it up to the ROM and installed the nightly CM build (1/20), the exact same issue appeared even without signing into my Google account. Just the ROM and GAPPS were flashed. Switched to another AOSP (modified) based ROM (not CM based) and the same issue happened again. It seems that only stock unmodified ROM's run smoothly on my device.
Is anyone else seeing this? Does anyone else have any thoughts as to why I am seeing this. I know I am not alone, a few people on Reddit said they saw the same thing on Euphoria (again its not the ROM's fault, its something else).
My device:
32GB Nexus 6
Sandisk/Samsung
Decrypted Androbench numbers on Franco R9:
Fsync ON - SEQ RD 163.46MB/s - SEQ RW 43.35MB/s
Fsync Off - SEQ RD 152.76MB/s - SEQ RW 198.95
Click to expand...
Click to collapse
Well, I get the unlock stutter and some other subtle stutters on every non-stock kernel that I've tried. It happens consistently, then disappears completely once I flash the stock kernel. This is on 5.0.1 stock, though. I've only been on one AOSP ROM briefly and experienced the same.
My device:
32GB Nexus 6
Sandisk/Samsung
Decrypted
you have to play with your cpu, and set it up to run how you like it. it doesnt happen on its own, you have to do it. unless you really like how the roms stock kernel runs.
simms22 said:
you have to play with your cpu, and set it up to run how you like it. it doesnt happen on its own, you have to do it. unless you really like how the roms stock kernel runs.
Click to expand...
Click to collapse
Like I mentioned in the OP though, I have run all AOSP eligible Kernels on various governors and settings with no change. However, If I run any of the kernels on a stock based it runs like butter.
altimax98 said:
Like I mentioned in the OP though, I have run all AOSP eligible Kernels on various governors and settings with no change. However, If I run any of the kernels on a stock based it runs like butter.
Click to expand...
Click to collapse
Yeah you may be right. My brother nexus 5 stock not even rooted look smoother then my phone. I'm running pure shamu with Franco. I'm Also gonna try a stock ROM to see the differences.
altimax98 said:
Like I mentioned in the OP though, I have run all AOSP eligible Kernels on various governors and settings with no change. However, If I run any of the kernels on a stock based it runs like butter.
Click to expand...
Click to collapse
ive run aosp since aosp came out, no stutters. but i run it at 2650mhz(3033mhz now)/300mhz, ondemand/deadline.
funcrusher said:
Well, I get the unlock stutter and some other subtle stutters on every non-stock kernel that I've tried. It happens consistently, then disappears completely once I flash the stock kernel. This is on 5.0.1 stock, though. I've only been on one AOSP ROM briefly and experienced the same.
My device:
32GB Nexus 6
Sandisk/Samsung
Decrypted
Click to expand...
Click to collapse
So if you run CM or any of the others on the default Kernel you are fine, but not on custom kernels... Interesting, I cant recall if I used the stock CM kernel or not. I know Euphoria ships with Lean so It wouldnt matter there.
edit - Dont you lose theme manager though? Or do you use the app to set the SELinux to Permissive?
simms22 said:
ive run aosp since aosp came out, no stutters. but i run it at 2650mhz(3033mhz now)/300mhz, ondemand/deadline.
Click to expand...
Click to collapse
I even tried Performance 2650/1728 with no changes to the stutters.. I don't think its a speed issue.
altimax98 said:
I even tried Performance 2650/1728 with no changes to the stutters.. I don't think its a speed issue.
Click to expand...
Click to collapse
performance is the absolute worst governor to use, ever.
altimax98 said:
So if you run CM or any of the others on the default Kernel you are fine, but not on custom kernels... Interesting, I cant recall if I used the stock CM kernel or not. I know Euphoria ships with Lean so It wouldnt matter there.
edit - Dont you lose theme manager though? Or do you use the app to set the SELinux to Permissive?
Click to expand...
Click to collapse
No, I'm saying that I experience the same stutter you're describing (particularly unlock) on the 5.0.1 factory image using any custom kernel. It goes away once I flash back to the stock kernel.
simms22 said:
performance is the absolute worst governor to use, ever.
Click to expand...
Click to collapse
Oh, I thought it just ran it harder. I usually run Interactive.
It sounds to me like all the different rom makers are including some common change in their kernels compared to the factory kernel. Not all that surprising, since when one person makes a change that everyone likes, everyone will do a pull and bring in ALL the changes from that kernel (including the bad ones).... and or everybody forks someone, who is probably not AOSP. CM tends to be a common place to fork or pull from.

[Kernels] N4N-2DQI6/I5-[12-19-17]710,715,810,815,817

N4N (Neked 4 Nougat) I6/I5 Kernel for 710,715,810,815,817​There's just nothing like good ol' stock. Everything just works. Even after 2 years they're still selling these Tabs. And they can still compete with newer ones. So on with the show!!!!
You flash this at your own risk. I'm am not responsible for anything that happens!!! There's the discaimer.
MAKE A FULL BACKUP IN TWRP!!!!!
These kernels modify your ROM. So you WILL NOT be able to FLASH/RESTORE the stock kernel only.
A kernel tuner (Synapse) is enabled for V2.0 only - Get Synapse from the Playstore
See post #2 for Synapse info and other stuffs​
Install instructions:
You MUST HAVE TWRP installed to flash this!!
MAKE A FULL BACKUP IN TWRP!!!!! YOU HAVE BEEN WARNED!!!!!!!!!
Flash Kernel- it'll wipe cache, dalvic automatically,
Flash SU v2.82, https://s3-us-west-2.amazonaws.com/supersu/download/zip/SuperSU-v2.82-201705271822.zip
Wipe cache and dalvic when SU asks,
Reboot
Profit!!
So whats in this thing?!
V2.0 Synapse enabled (You should use a tuner (Synapse recommended) for this one as that's all that was added) But will run fine without
All below plus
Under volting
Overclock-big 2.2Ghz LITTLE 1.6Ghz
Underclock-big 500Mhz LITTLE 200Mhz
HMP tweaks and tunables
KSM with tweaks
Enabled all stock govs
V1.3 All below plus
Patched to 108EOL
V1.2 All below plus - Pulled for random issues-Use V1, V1.1 or V1.3
Patched to 3.10.105
817 only has this version
V1.1 All below plus
Patched to 3.10.61
V1
4.9 UBERTC Toolchain
Screen Mirroring built in - Seems to only works with Samsung enabled TV's
CIFS
OTG
TCP's-Cubic is default. Reno, Westwood+ and HTCP added
CDROM support
XPAD game controller support
A few tweaks
Bugs
If you have Synapse installed , make all settings to stock and uninstall. It'll probably still give you a "System UI error". Just move on, and reboot after a couple minutes.
Source
https://github.com/engine95
Thanks to
@andyroidking - for the 715,815, and 810 boot.img's
Donations. Never expected, but much appreciated
@sebmue
@andyroidking
Downloads
V2.0 Synapse enabled and recommended
710-I6 - https://www.androidfilehost.com/?fid=673791459329065685
810-I6 - https://www.androidfilehost.com/?fid=962021903579496837
715-I6 - https://www.androidfilehost.com/?fid=745849072291693169
815-I5 - https://www.androidfilehost.com/?fid=889964283620770516
817-3CQE4 - https://www.androidfilehost.com/?fid=962021903579499361
V1.3
710-I6 - https://www.androidfilehost.com/?fid=889964283620768631
810-I6 - https://www.androidfilehost.com/?fid=745849072291691184
715-I6 - https://www.androidfilehost.com/?fid=962021903579494937
815-I5 - https://www.androidfilehost.com/?fid=962021903579494940
817-3CQE4 - https://www.androidfilehost.com/?fid=889964283620772774
V1.2 Only for 817
817-3CQE4 - https://www.androidfilehost.com/?fid=745849072291694892
V1.1
710-I6 - https://www.androidfilehost.com/?fid=962021903579492239
810-I6 - https://www.androidfilehost.com/?fid=745849072291688529
715-I6 - https://www.androidfilehost.com/?fid=817906626617946405
815-I5 - https://www.androidfilehost.com/?fid=889964283620765858
817w-3CQE4 - https://www.androidfilehost.com/?fid=673791459329067028
V1
710-I6 - https://www.androidfilehost.com/?fid=889964283620763792
810-I6 - https://www.androidfilehost.com/?fid=817906626617944296
715-I6 - https://www.androidfilehost.com/?fid=745849072291686448
815-I5 - https://www.androidfilehost.com/?fid=889964283620763794
I'm just not a fan of the DevDB format anymore. It's difficult to update and modify. So this is what you get.
SYNAPSE Kernel Tuner - Maybe some others stuffs too.....​
Well, because Synapse is built in now, here's some needed info on it:
Synapse is an awesome and custom built kernel tuner. It can do so much more than a lot of other tuners. And because we have Exynos processors, it's about the only one we can use. But it can create a lot of problems getting to work. Hence this post. :silly:
I decided to make this built in instead of a flashable add on. It's actually easier and less invasive to do it this way.
UCI, is what Synapse uses to work. It's built into the ramdisk. I've added a lot of tunables and may add more later.
Now for the fixes and problems you WILL run into:
If you have issues, make sure to check out these threads. As they will probably have better info about Synapse issues. https://forum.xda-developers.com/showthread.php?t=2736986 and https://forum.xda-developers.com/showthread.php?t=3558888
No UCI support detected These are the famous words you WILL run into.
When will this show up?
When Synapse is first installed
On reboot
When you've pushed your Tablet too far
The fixes:
On first install from the Playstore. You will need to go to Settings>Apps>Synapse>Storage. Then select "Clear Cache", THEN "Clear Data. In that order!!
You may have to backout to Settings and do it one or two more times. You want the numbers for cache and data at "0".
On reboot: This usually works unless you've messed up the settings or flash another kernel
On reboot select "Menu" and "Close all".
Open Synapse and hit "CANCEL" to have your last settings applied. (I know it's not normal but it works)
Close synapse, and reopen it to make sure of settings. (If "apply or cancel" don't show up at the top, you're good to go.)
Worst case scenario:
You will need to go to Settings>Apps>Synapse. Select "Force stop". Select "Storage". Then select "Clear Cache", THEN "Clear Data. In that order!!
You may have to backout to Settings and do it one or two more times. You want the numbers for cache and data at "0".
If you follow the above, Synapse will work. It hasn't failed me in over 50 tests, probably more. :silly:
810 good to go. Have to wait til later this week to try mirroring, gave my daughter my sammy tv..
Edit: confirmation #5H0834012J5874316 - Thanks for your hard work!
andyroidking said:
810 good to go. Have to wait til later this week to try mirroring, gave my daughter my sammy tv..
Edit: confirmation #5H0834012J5874316 - Thanks for your hard work!
Click to expand...
Click to collapse
Thank you for the donation!
Hopefully the 810 looks better on the screen. The 710 is a weird screen size and doesn't fill it. But it still comes in handy.
My "Neked Maker Rom" has it built into the build.prop. But i found I could add it to the kernel. It'll still work with both installed, which I have.
engine95 said:
Thank you for the donation!
Hopefully the 810 looks better on the screen. The 710 is a weird screen size and doesn't fill it. But it still comes in handy.
My "Neked Maker Rom" has it built into the build.prop. But i found I could add it to the kernel. It'll still work with both installed, which I have.
Click to expand...
Click to collapse
I posted a couple days ago but apparently it didn't send. Screen is fine! Everything seems good. It is charging good again too, probably not kernel related but take the credit will ya...
andyroidking said:
I posted a couple days ago but apparently it didn't send. Screen is fine! Everything seems good. It is charging good again too, probably not kernel related but take the credit will ya...
Click to expand...
Click to collapse
Ok.
I'm wondering if it is Synapse with the battery. Guess we'll see.
Haven't spent a lot of time with the kernels lately. Trying some different things, but keep coming back to what I've had in the past.
EX kernel managers builder was interviewed on XDA recently. flar2 . Had some interesting things to say about SELinux. Guess that might be why his tuner doesn't have an option for permissive. Just food for thought for us all.
engine95 said:
Ok.
I'm wondering if it is Synapse with the battery. Guess we'll see.
Haven't spent a lot of time with the kernels lately. Trying some different things, but keep coming back to what I've had in the past.
EX kernel managers builder was interviewed on XDA recently. flar2 . Had some interesting things to say about SELinux. Guess that might be why his tuner doesn't have an option for permissive. Just food for thought for us all.
Click to expand...
Click to collapse
I'll read through that later... his kernel is what I use on my nexus9. His dev app is pretty good too, playstore- DevCheck Hardware and System Info. Smart guy.
Just a little update
I have the 710 and 810 kernels done. I should get 715 and 815 shortly. Then I'll get them uploaded
Just patched to 3.10.61. No additions til I get them as far as I can.
The kernel is EOL at 3.10.108
V1.1 for all 4 is in OP Just patched to 3.10.61
I've changed the way I'm doing it so it's faster. And it's easier for others to track.
I'm hoping to get all the way to 3.10.108 for the next version. Then the addons.
We shall see. :fingers-crossed:
Thank you ! Amazing and smooth as expected ??
810 v1.1 A-Okay
V1.2 is in OP!!!!! Just patched to 3.10.105, which is Feb 2017
Not quite sure if I'll go to 108, or do some addons. I'm kinda burned out on the patches.
More than likely I'll patch to 108, but I am dreading it as just the 3 more patches has over 750 fixes.
And seeing as how our Tablets AND our Kernel is at EOL, I might as well finish it out.
Regardless, enjoy.
engine95 said:
V1.2 is in OP!!!!! Just patched to 3.10.105, which is Feb 2017
Not quite sure if I'll go to 108, or do some addons. I'm kinda burned out on the patches.
More than likely I'll patch to 108, but I am dreading it as just the 3 more patches has over 750 fixes.
And seeing as how our Tablets AND our Kernel is at EOL, I might as well finish it out.
Regardless, enjoy.
Click to expand...
Click to collapse
Thank you, thank you. Don't burn out!
---------- Post added at 01:50 PM ---------- Previous post was at 12:56 PM ----------
andyroidking said:
810 v1.1 A-Okay
Click to expand...
Click to collapse
1.2 good to go of course.
Okay, so I don't know what is missing or changed in the kernel but all of a sudden I am getting horrible battery life I can almost watch it drop sometimes. If you're thinking of updating more maybe putting back some of the tweaks that you had? First?
Edit- it literally dropped a percent when I typed the above.
andyroidking said:
Okay, so I don't know what is missing or changed in the kernel but all of a sudden I am getting horrible battery life I can almost watch it drop sometimes. If you're thinking of updating more maybe putting back some of the tweaks that you had? First?
Edit- it literally dropped a percent when I typed the above.
Click to expand...
Click to collapse
Now that's interesting. I used my Tab last night and all was well.
It could be a rogue app. Or maybe you need to shut it off for a minute. Then boot it up again. There were a lot of changes in the kernel and resetting doesn't always fix things. The battery might need to relearn too.
Side note:
Ya know how when climbing you see a peak and you just have to keep going til you can see over it? Yeah, well, I've just about finished the patches to 108. It'll be a couple days. I just barely got it built and need to see how it does.
Here's some pics of battery for me. And I've installed the kernel a few times too. So reboots are included.
Edit
There's an old trick I still do for "Ghosts in the computer".
Power the Tab off, wait for bout 15 sec, then just press the vol down, vol up and power buttons. Just a press. Do it a few times then boot it up.
The old belief is that there is still an electrical charge that can keep things in memory. By doing this, it'll discharge any current that is lurking.
It may be nothing, but I feel better doing it.
engine95 said:
Now that's interesting. I used my Tab last night and all was well.
It could be a rogue app. Or maybe you need to shut it off for a minute. Then boot it up again. There were a lot of changes in the kernel and resetting doesn't always fix things. The battery might need to relearn too.
Side note:
Ya know how when climbing you see a peak and you just have to keep going til you can see over it? Yeah, well, I've just about finished the patches to 108. It'll be a couple days. I just barely got it built and need to see how it does.
Here's some pics of battery for me. And I've installed the kernel a few times too. So reboots are included.
Edit
There's an old trick I still do for "Ghosts in the computer".
Power the Tab off, wait for bout 15 sec, then just press the vol down, vol up and power buttons. Just a press. Do it a few times then boot it up.
The old belief is that there is still an electrical charge that can keep things in memory. By doing this, it'll discharge any current that is lurking.
It may be nothing, but I feel better doing it.
Click to expand...
Click to collapse
I really wish it was ghosts or Rogue app... rebooted 1.2 browsed Reddit for 17 minutes lost 7%. Flashed 1.1 browsed Reddit and as I'm typing this only 2% in 22 minutes.... We will see what 1.3 brings when it is cooked.
HTML:
andyroidking said:
I really wish it was ghosts or Rogue app... rebooted 1.2 browsed Reddit for 17 minutes lost 7%. Flashed 1.1 browsed Reddit and as I'm typing this only 2% in 22 minutes.... We will see what 1.3 brings when it is cooked.
Click to expand...
Click to collapse
So with 1.2 I was getting 3 to 4% at idle an hour battery drain. Installed 1.1 and overnight 8 hours 1%. Could just be something with my tab and that kernel not liking each other, lol.
andyroidking said:
So with 1.2 I was getting 3 to 4% at idle an hour battery drain. Installed 1.1 and overnight 8 hours 1%. Could just be something with my tab and that kernel not liking each other, lol.
Click to expand...
Click to collapse
I think I found the issue. It was very random and hard to find, but I'm pretty sure I have it fixed now. It'll come out when I finish/ release 108.
For now, all the kernels run fine, so if there's no issues with what's installed, then just keep running it till I get 108 up. Like I said, it's a random thing with 105. Hit or miss. I'll pull v1.2(105)when I get v1.3(108) up.
Thanks for making me look into it. Lol
Thank you @engine95 for your amazing effort. You made my tablet super smooth. And really I was about to sell it, but you let me keep it for another year . Thanks ??????
V1.3 is in OP for all 4 kernels Patched to 3.10.108EOL
I've pulled V1.2 as it had random issues and/or isn't needed now with the fixed V1.3
Just a little FYI
Stock 3.10.9, vs Patched 3.10.108 - Stability vs Security
V1 is the mostly stock 3.10.9 kernel. It will be the most stable of all the kernels as Samsung has tailored it to our Tablet
The rest
These should be the most secure as it has all the Linux patches to date. Thing is, Samsung hasn't made adjustments to optimize the kernel to anything past 3.10.9
Patching it can cause some problems. Usually WiFi, Bluetooth, Battery, USB.
Patching it may make more current products useful. Routers, Game Pads, Hard drives etc....
So from here, I'll wait and see if we have more issues with the patched kernels before moving on.
My options?
Keep going with the patched kernel to build on
or
Go back to 3.10.9 for the stability, and leave the patched kernel where its at.
Let me know how V1.3 does so I can start with the addons on one or the other.
Thanks all and enjoy. :good:

Categories

Resources