yashsingh1/xdaforums huggingface dataset:
[Nexus S Android Development] Scofield.:
Hi,

I'm using that kernel with CM10 now and all my smoothness issues are gone. Love it.

One question.

Is there a chance for a version that would support the built-in CM BLN Settings?

Now its greyed out, so I have to use another app like BLN Control pro. The BLD Settings are working fine.

Thank you for the nice kernel.
[Nexus S Android Development] towelboy:
I'm not sure cause I don't really change the settings.

press thanks if I helped! :D
[Nexus S Android Development] infernalMan:
+6.2
[Nexus S Android Development] polobunny:
No. But read the first post and you will know how to use a very simple script to set bln with even more advanced functions than cm10 gives you. All that without using another app that runs in the background. :)
[Nexus S Android Development] :
There's no need for anyone to kick off at caliban2, he's been very helpful to me, and it's fine if he doesn't want to post bug reports. I'm not forcing anyone to do anything they don't want to. If anyone see's a post they don't like, just skip over it.

I don't normally drink, but I got trashed last night with some work colleagues, and I've been using the phone normally, but unfortunately I'm getting a massive battery drain problem with the would-be v6.2.2

I'm going to have to selectively revert what I've been working on until I pin down the problem, but I want people to know that I found a couple of mistakes (that I made :p) that govern how the clocks (that feed the processor) change frequency during changes between the CPU steps. Unfortunately I'm too hung over to deal with it right now.

In fact I've got to get my daughter some breakfast, and I feel like a gorilla is trying to smash it's way out of my skull. Why have I done this to myself???? :p Good times!
[Nexus S Android Development] asphantix:
I'm using full stock (stock rom + stock kernel) for almost 2 weeks and this is what I got: 1 d 14 h and 62% battery left!!

Don't get me wrong: I love marmite and really appreciate the work behind but there are two possibilities:

- marmite and other custom kernels have a higher drain than the stock kernel

- full wipes (+sdcard wipe) result in better battery usage (I usually don't wipe but for 4.1.2 I did)

I will make an nandroid backup and test marmite again ony my fresh clean device. Marmite is cool but when it turns out that battery will last longer with the stock kernel I probably will try this great kernel building tutorial (big thanks for that) for merging the animation fix with the stock kernel.
[Nexus S Android Development] :
That sounds like a good idea. Go for it! Let me know if you get stuck.

I have a terrible hang over, but I didn't let that get in the way of me building a new kernel this morning.

I've made a guess at what might have caused the battery to drain, and have uploaded the cm and cm (4G) versions if people want to have a little test. If it turns out that I didn't fix the problem, then flash back to a previous version and everything will be fine.

Edit: links removed. Bad drain not fixed!
[Nexus S Android Development] Daniel.Stevens:
Are you about to rename the kernel "vodka" (or whatever you drank last night) or are we safe and marmite has still made you the sickest you ever were in your life ?!? :silly:
[Nexus S Android Development] capoooro:
Kaboom reboot

9023

Strawberry

Marmite 6.2.1

Oc 1098

Everything was OK for 20 hours...

And then I was searching in contacts... freeze and reboot

Lastkmsg

https://docs.google.com/open?id=0B2tiVR5srvr4UTYtNUMxT1R5ckk
[Nexus S Android Development] Scofield.:
I just made an init.d script with nstools and it works.

The script is looking like this:

#!/system/bin/sh
echo 1 > /sys/class/misc/backlightdimmer/enabled
echo 5000 > /sys/class/misc/backlightdimmer/delay
echo 1 > /sys/class/misc/backlightnotification/enabled
echo 0 > /sys/class/misc/backlightnotification/in_kernel_blink
echo 60 > /sys/class/misc/backlightnotification/max_blink_count
echo 100 > /sys/class/misc/batterylifeextender/charging_limit
echo ondemand > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo 20000 > /sys/devices/system/cpu/cpufreq/ondemand/sampling_rate
echo 95 > /sys/devices/system/cpu/cpufreq/ondemand/up_threshold
echo 1 > /sys/devices/system/cpu/cpufreq/ondemand/sampling_down_factor
echo 0 > /sys/devices/system/cpu/cpufreq/ondemand/powersave_bias
echo cfq > /sys/block/mtdblock4/queue/scheduler
echo cfq > /sys/block/mmcblk0/queue/scheduler
echo 100 > /sys/class/misc/liveoc/oc_value
echo 1000000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq

I've tried to delete all the other stuff beside the bln code (everything under echo 100) and it stopped working, so I leave all the other stuff alone.

My question is, can the other code give me some problems or is it ok if its there?
[Nexus S Android Development] CrackerTeg:
That's exactly like mine minus the governor and clock speed. Works just fine for me every time.
[Nexus S Android Development] tchaari:
I am listening and I already put marmite as the default kernel for Nexus S in Slim Bean :D
[Nexus S Android Development] :
Hello, the next version will be much better I think. I've solved a couple of problems (that I caused :p) in the way the processor changes between frequency steps, and this alone could have been causing reboots.

I've also been experimenting with some other tweaks and bits and bobs, and at some point I've introduced a bug, so I'm working backwards through the tweaks at the moment to eliminate the issue. But it's taking me longer than expected! Don't worry though, it'll be out soon, and it'll be worth the wait!
[Nexus S Android Development] :
You were overclocking, so that alone might have caused the reboot. Funny things can happen when systems are pushed past their specified operating range.
[Nexus S Android Development] caliban2:
Exactly. I just didn't like the wording of your response, but that's my personal decision, same goes for posting logs. Big deal for you if you don't get any from me, I'm only harming myself. :p Seemed to be a one-time glitch, no problems ever since.

Regarding those jokers posting in response of all this, a glance at their posting history triggered two questions: Who they are and why should their "opinion" matter in the slightest?! That's why I ignored them.
[Nexus S Android Development] polobunny:
Welcome back. =)

You see bedalus last post about frequency switching? Might be something like that.
[Nexus S Android Development] caliban2:
Maybe, but don't think so. There were all kinds of things wrong in that log. Even during boot, and somehow I have a hard time believing freq-jumping corrupts wifi-driver. ^^
[Nexus S Android Development] polobunny:
I believe bedalus fixed the broadcom wifi errors in v6.2.1
[Nexus S Android Development] caliban2:
v6.2.1 produced the first crash in weeks, that's the funny thing. But as it was only one... Wifi-driver was just an example, also had a pvr-warning, many ecc-errors - and all from boot. But so far it's fine again.
[Nexus S Android Development] polobunny:
I feel you. My first crash in a while was with 6.2. Now I'm still running it and all is fine, so what the hell really.
[Nexus S Android Development] capoooro:
Yes I know. The three reboot before were at standard freq.

Now back again to standard freq...
[Nexus S Android Development] :
Wifi is fixed, the reason for the extra stuff in the kernel log is just from updates from android-3.0/common: Dimitry has introduced some debug logging stuff that wasn't there before.

https://android.googlesource.com/kernel/common/+/4744c266a6a254631a9369eeb2c311bda8a8c542

...from the 17th of September. So whenever I merged this in, that's when these messages started appearing. It's normal.

I did however look at some other stuff from android-3.4/common, because some of the code has crossovers, despite the large number of differences introduced as the kernel evolves. The deadlock fix fix fix fix fix was needed because the system locks all the required resources for wifi to perform certain operations, and I got the code in the wrong place, and every time I attempted to correct it, I made some other mistake! But it's definitely correct now. I think it was solved in v6.2.1, but it's definitely solved in v6.2.2, along with the CPU frequency stuff. I just need to identify what it is that I've done that's causing the battery to drain horribly. Hopefully, if I crack that one this evening, I can release an update, but it's proving to be a chore (battling with hangovers, family commitments, work, etc...)
[Nexus S Android Development] :
Hmmm. I think the massive battery drain I was getting was in fact due to some bad behaviour from an app. Just to make sure there's no battery drain issue, I'll just ask for a few people to test this CM version, and report back if they notice battery draining abnormally:

http://d-h.st/KBr

Can you wipe your battery stats while in CWM recovery when you flash this please? When you boot the phone, can you power off the screen asap and leave it for 15 minutes then switch on and go straight to the battery usage screen and make a note (or take a screenshot) of your stats, and report back please? Thanks!
[Nexus S Android Development] :
https://github.com/bedalus/marmite/commits/bedalusv6.3d

I've put a lot of effort into tidying up my github with all the recent changes. I've boiled down 20+ individual little commits into 4 or 5 grouped commits. This may help people who've forked my repo to cherry-pick the latest changes.

EDIT: In the post below you can see capoooro experiencing the issue that I've been struggling with. But at least since I've tidied up my git source I might be able to spot it easier.

I'll leave the download available for other users for now, it'd be nice to get some more confirmations of the bug.
[Nexus S Android Development] capoooro:
Here it is capitain:)
[Nexus S Android Development] :
Yeah, it looks like the OS is constantly busy. I still haven't managed to resolve this yet.
[Nexus S Android Development] fldc:
I don't have this problem on a kernel forked from your tree, probably because of these changes,

http://review.cyanogenmod.com/#/c/23540/
[Nexus S Android Development] :
That change is already merged into my source, in three files appended with .cm

I just swap them when I build the cm version.
[Nexus S Android Development] sidnoit22:
I was using 6.2 then saw there is a 6.2.1 also so i flashed it, and it was so slow i m back on 6.2.

ROM : XenonHD
[Nexus S Android Development] :
Yes, I should really go and sort out the download page. The next version will be much improved.
[Nexus S Android Development] sidnoit22:
That will be great, using Marmite since you released v4 lol ( embarrased ) While i still test the other ones :)

Waiting for the next release, lid has been licked. ;)
[Nexus S Android Development] :
The above version will definitely cause high Android OS drain.

I installed v6 and the OS bug was still there. I thought maybe a number of battery pulls has corrupted storage. After trying a full wipe and clean install, the bug was still there. After a nandroid, the bug was still there. I made a backup and formatted my SDCard and re-installed strawberry (thought I'd try a different ROM for elimination purposes) and the bug is still there.

I've quite methodically reverted all of the individual commits since this bug appeared, and have had no luck. Now that I've got a clean install I'm going to have to try all over again!

EDIT: Damn! Still no luck!!! This is really starting to get on my tits.
[Nexus S Android Development] fldc:
Ah, ok, I know I definitely had this problem before, and i use your latest source as a base, don't know where it was fixed then :)

Skickat från min Nexus S via Tapatalk 2
[Nexus S Android Development] pan1980:
I have news, i uninstalled juice defender and reboots disappeared.

I increased voltages to 1.350 for 1.1 and 1.2 steps and its stable at theses steps too.

i9023, slimjb 2.8, 6.2 kenrel.
[Nexus S Android Development] sdhanjal15:
This is how I have it set up with noop =6 hours screen time

Edit: bedalus...what from are you running?
[Nexus S Android Development] caliban2:
6 hours? Sweet. I always wondered how you guys accomplish that - now I can see one piece of the puzzle: no mobile data connection. Well, I don't want a dumbphone... :p

I always wondered what smartass settles for with these non-existant steps (300 & 500 MHz) - the next higher or lower?

Never saw noop in a bedalus-kernel, only deadline and cfq.
[Nexus S Android Development] sdhanjal15:
Oh and black backgrounds with a red theme. Red saves battery and black
[Nexus S Android Development] caliban2:
Only on amoled, I've got LCD. :)
[Nexus S Android Development] sdhanjal15:
Ahhh I seee
[Nexus S Android Development] :
Sorry guys, I know I put the word out for testers, but I accidentally introduced an annoying frequency stepping glitch, and I've been out all day... I'm just sorting it now, and when I go through my PMs I'll send you all the new link.
[Nexus S Android Development] :
From what am I running? Do you mean like 'my lurid pole-dancing past' or something? Sorry, just being a smartass. Haha. Oh me.
[Nexus S Android Development] sdhanjal15:
Damn auto correct......ROM
[Nexus S Android Development] caliban2:
A Brit pole-dancing. Oo

That's one thing I don't have to see.

Although... Maybe. In a pub, after a few pints and England has just won against Germany via penalties. One can dream... :( (of this game, not you at the pole! :p )
[Nexus S Android Development] :
Oh you'll see it... can anyone say boot-animation?

To answer your original question, the smartass settings I use are the ones supplied with the kernel, but I believe these can now be safely tweaked, I'm hoping to use more sensible mathematical values to reduce the amount of grunt work the governor has to do while approximating when you step to a non-existent value. (I did try this once before, and it didn't work well, but again this may have been down to a frequency stepping error I'd accidentally introduced, so I'll have another look).
[Nexus S Android Development] sdhanjal15:
Haha so after you said that I change them to realistic values.
[Nexus S Android Development] :
Thanks to everyone who PMed for the testing version: check your inboxes.

Still To Do

-Upload a minor update for the stable 800MHz-DI version

-Check smartass values

-Double check colours (but I'm pretty sure I'm happy with them already)

-Possibly a non-bigmem version for early JB fans (this is not a promise!)
[Nexus S Android Development] Blackcrx:
I'm confused now. I thought 400mhz was the best for DI and battery usage?
[Nexus S Android Development] :
You are right 400 is the most power saving fq step for deep idle to sit on.

...what I meant was that there were few, if any, problems reported with the 800 MHz version that had min and max fixed at the same frequency.

I've been working very hard on the 400 MHz version, but it's still in testing. However, while I was working on the new 400 MHz performance-DI version, I picked up on a few other bugs.

...so...

Here is v1.3c: http://d-h.st/HJY

-Minor bugfix release

-If you have no issues with 1.3b skip this, and wait for v1.4
[Nexus S Android Development] Blackcrx:
i think a few of the 1.4 testers have reported no issues except randomwalker with the loss of reception. I personally think the original 1.4 is pretty damn stable and bug free.

I can't imagine how much more you can add to 1.4 before you release but I'm excited. haha
[Nexus S Android Development] Randomwalker:
I also want to emphasize that I experienced this issue with every DI kernel I tested, as some others have as well. On the other side it seems that this problem is rare, so maybe device dependent.
[Nexus S Android Development] y3mita:
Bedalus I did notice that "Android OS" does jump really high when it's not connected to wifi. The normal I have seen it's about

12-15 percent. I do get 35-45 sometimes.
[Nexus S Android Development] noobiekins:
I think it maybe because when connected to wifi, it syncs near instantly, when wifi off, you use 3g to sync, which is longer.
[Nexus S Android Development] y3mita:
That's correct but 45%bit too high
[Nexus S Android Development] :
I'm not sure how that statistic is calculated, but it might just be a glitch. Can anyone else confirm?
[Nexus S Android Development] leap_ahead:
I find 1350 stable for me too...what int voltage you use ?
[Nexus S Android Development] capoooro:
Going back to 6.2.1 and tadaa no OS drain....

Hope this can help :D
[Nexus S Android Development] pan1980:
the default from kernel, 1.150.
[Nexus S Android Development] polobunny:
Purposely rebooted at lunch time because my backlights kept staying on even though I had no notifications. BLD worked, but as soon as I put my phone to sleep the backlights either came on or came off but if I brushed my finger against the softkeys they came back on.

Otherwise it was decent, but after 96 hours the phone always feel less snappy than when you just booted it so a reboot doesn't hurt. :)
[Nexus S Android Development] mpjoe2000:
hi, maybe what i'm going to say it has been said but there are too many post to read (and actually i read some android os post and some of them are just complaining without real testing), and i don't have the time right now.

i have used some marmite kernels and i had a strange behavior with android os on all kernels i've installed.

Usually shows up when i just charged my battery (or charged enough to have battery stats cleared), leave the phone alone for about 10 minutes, then you go to battery stats and you can see "android os" on 4 - 7% with some seconds or even 1 minute awaked, which is normal for me. Then i leave my phone alone for 20 minutes, and check out battery stats again and you can see "android os" with less %, which is pretty good, but what is strange for me is that time awaked has decreased.

Is this a normal behavior? why awaked time from android os decreases while you leave your phone sleeps?

have you notice such behavior on Air Kernel and CM Kernel?

i usually have: wifi=on bt=off gps=off, data=on, wcdma preferred (3g signal almost all the time)
[Nexus S Android Development] :
You can execute git log --author=bedalus

and it'll print out a list of my commits. You can scroll down, and press q to quit the log viewer
[Nexus S Android Development] :
You should leave the INT voltage alone for 1.2GHz, because there is no extra demand on the BUS/GPU even though the CPU is OC'd

At 1.1GHz the default is 1150mV, which you may need to raise or lower.
[Nexus S Android Development] :
Is there a bug in BLD? Can you reproduce it?
[Nexus S Android Development] polobunny:
I don't believe I can reproduce it, and I'm not even sure it is kernel related. It just happened all of a sudden, my phone was in my pocket. Vibrated 2 times (as if I lost cell reception, which isn't surprising considering storm Sandy) and I looked at it, only to see this happening. :S
[Nexus S Android Development] :
I actually think I had the same thing once. It's probably some esoteric bug I'll never pin down. I'm home early (felt sick at work) so I'm curled up with a blanket, and I'm determined to nail down this OS drain bug. I really want to get this next version out and see how the stability holds up.
[Nexus S Android Development] polobunny:
Yeah I don't believe the BLN bug is of very high priority.

Unless that's the reason for the high Android OS bug. :p
[Nexus S Android Development] :
v6.3 is here: http://goo.gl/HvUrp

-Merged to mainline 3.0.49

-New wifi commits from android-3.0/common

-Bugs fixed in CPU frequency code

-RWSEM_XCHGADD_ALGORITHM: possible 6% increase in the number of read/writes compared to RWSEM_GENERIC_SPINLOCK, but I'm taking this one someone else's authority (i.e. I didn't personally attempt any measurement)

I'm hoping this release brings a new smoothness and stability. Please feedback in the usual manner.
[Nexus S Android Development] agnostic900rr:
what happened to the 1096 MHz OC?
[Nexus S Android Development] polobunny:
Android OS fixed or not? Just wondering. :)
[Nexus S Android Development] neosynthesis:
6.3 rebooted

hi bedalus. FYI: After first install on 6.3, the phone rebooted during the first phone call. It was a soft reboot, like the phone app crashed, and returned to homescreen with all widgets on "loading". I'm back on 6.2.1.

Nexus S, MIUI US v4 on 4.1.1,

init.d settings: 100/1000MHz, smartass V2, no voltage tweaks
[Nexus S Android Development] Basche:
have you tried to do fix permissions, as sometimes you need to do that when flashing a kernel.
[Nexus S Android Development] anshumandash:
I think bln increases android os usage. I enabled bln for an hour on 6.2 and it showed android os wake lock for 20 mins while notifications were waiting. This made Android os usage at the top of battery stats. I didn't configure blinking.

I am using bb6, 200-1000 smartassv2.

Sent from my Nexus S
[Nexus S Android Development] :
Yes, it's fixed, but I broke 1.1GHz! I'll have to check what happened. I've got some time this morning
[Nexus S Android Development] :
Yes, blinking keeps the CPU awake to time the on/off intervals
[Nexus S Android Development] :
Yes, it seems one of the CPU frequency steps went missing. Where it says 'bugs fixed' in the change log, it should probably say 'bugs introduced' :p

If things aren't right there, it's likely to be a source of instability.
[Nexus S Android Development] granets:
yay, new bugs introduced, it's always nice to see this. bugs lead to fixes that lead to improvements, so I don't mind them. you have to break something to fix it and make it better :)
[Nexus S Android Development] :
I've sorted it out now. I fixed my OS drain bug, then restored things like the GPU power management fix, custom voltage for the OC frequencies, and the OC code itself. However, I restored things in the wrong order, and basically took the OC code back in time. But fortunately it was easy to sort out.

I'll build and upload as v6.4
[Nexus S Android Development] ej8989:
i'm running on strawberry rom. what version should i flash? stock, cm nightly?

edit: it's CM. flashed it >.>

running stable so far. OC'd at 1200mhz with 1350mV

tried temple run, shadowgun, and a few other games.
[Nexus S Android Development] :
v6.4 is here: http://goo.gl/HvUrp

-Fixed missing 1.1GHz step

I did a few benchmarks to make sure things are as expected

Nenamark 2

1.2GHz: 27 FPS

1.1GHz: 28.1 FPS (4.4% increase)

1GHz: 26.9 FPS

Linpack

1.2GHz: 8.84s (17% increase)

1.1GHz: 9.31s (11% increase)

1GHz: 10.34

The linpack results make sense, but the GPU results don't really make sense, since a 10% boost in the FSB should make for closer to 10% increase in FPS.

I probably need to spend some more time thinking about why this might have happened. It might be normal.
[Nexus S Android Development] stojshic:
If we don't use OC, should we flash this, or we can skip it?
[Nexus S Android Development] micha3lvd:
Running 6.3 atm.. but after 2h 55m the android OS has gone up to 31%, and the android system to 19%.. and battery from 98% -> 86% in the mentioned time.. with only 8m of screentime

Phone details:

Slim Bean 2.8

KB3 Radio

fixed permissions after flashing kernel

EDIT:

Testing now with 6.4 (resetting battery stats)
[Nexus S Android Development] ej8989:
poweramp won't open after i flashed 6.4.

uninstalled it and tried to reinstall but it won't install.
[Nexus S Android Development] polobunny:
Did you find the commit causing trouble?
[Nexus S Android Development] atxbang56:
thank you God

Envoyé depuis mon Nexus S avec Tapatalk
[Nexus S Android Development] :
I recommend everyone just holds off updating for a few minutes while I see if I can improve GPU performance.

If I can't, everyone should update.
[Nexus S Android Development] :
Yes, I went through a process of reverting commits. Eventually I gave up and went back in my history, and started re-adding them. I discovered the commits causing the OS drain issue, so I readded everything else, but in the wrong order, so Custom OC needed to be added again.

I'm just testing another tweak now that will hopefully improve GPU performance at 1.1GHz

Android OS bug is gone, but none of the versions on the spreadsheet have that problem.
[Nexus S Android Development] :
Flash back to a previous version and report back please.