yashsingh1/xdaforums huggingface dataset:
[Nexus S Android Development] Hawkw1nd:
That's your opinion, and if you are happy @ stock clocks, then power to you, but you have no right to dictate what other ppl do with their phones. AFAIC, bedalus' 1.1Ghz/FSB220 works like a charm on my phone, and I'm happy with it. I don't need you or anyone else telling me what I can or should do.

I hasten to add, if I'd had problems o/c'ing my device, I wouldn't be spamming this thread with logs - I'd simply turn down the heat and be happy with what my phone could handle ...
[Nexus S Android Development] :
I'm still deciding the best way to approach it.

I'm a bit sleep deprived, so no updated this morning, but maybe after work I can finish the 1.2GHz step
[Nexus S Android Development] :
This reminds me, I need to remember to allow voltage control at both frequencies
[Nexus S Android Development] :
Thanks to several people for their kind words! I'm too tired now to reply individually, but it's really appreciated.
[Nexus S Android Development] caliban2:
You see, this has been the point all along. It's not about "you must not overclock", it's about reporting oc-freezes as kernel-bugs. :)
[Nexus S Android Development] dotlab:
Seems like you got me wrong, the last thing I want to do is to dictate something. The point of my post was to minimize last kmgs which are appearing in this thread as overclocking results (users don't even mention if their phone rebooted while OCed or no) and that's all. If you're happy and your device is working well with OC that's great for you, but as we all know all devices are handling this different and many "bug reports" are actually simple OC which someone's phone can't handle so no offense at all..
[Nexus S Android Development] Hawkw1nd:
Fair enough, and no offense taken :)
[Nexus S Android Development] polobunny:
Not trying to start a war, but if you're being a child about it, at least learn how to submit a proper bug report regarding overclocking. I'm pretty sure the procedure isn't to fall back to v5.2 at the sign of instability or to not submit a last_kmsg... See what we're getting at? How is anyone supposed to get overclocking to a stable level they way? Writing down "I had a reboot" is a good flag for bedalus to look into something, but providing the necessary information will help much more. :thumbup:

Full list of voltages arm and int, the frequency and obviously kernel version.
[Nexus S Android Development] granets:
version 6.1 is so good I want to have sexy time with it. my phone has been very been so smooth and responsive ever. I am oc-ing a bit and never had any fc's or reboots. best kernel ever ^_^
[Nexus S Android Development] benoit2600:
@bedalus Hi, do you know what APLL_VAL_1096 (and 100 and 800) is useful for ? when I increase the 137 value, my score at nenamark2 grow up.
[Nexus S Android Development] KrisMurdrum:
Oh boy, did I have a time with my phone last night!

Ok, first things first: i9020t, Flo's Stock 4.1.2 100.1% Google and Marmite v6.0.3. Same settings and setup I had with Marmite v5.

At first I had been OCing but had noticed there were random lag-spikes that occured. Chalking it down to OC-freeze I went ahead and set the kernel to its default settings. And it worked for a little bit. Then I started having lag-spikes again but this time they seemed to be lasting longer. (I should maybe go ahead and explain what I mean by lag-spike. It happened randomly, whether I was flicking through the app drawer; reading a book, writing a text, tapatalking, using android web browser, or chrome, or you name it; but my phone would quite suddenly shudder and stop. Then over then next minute or two, the phone would shudder occationally but eventually it would clear up and the phone would pretend nothing happened, until the next episode).

At this point I decided to boot into recovery and triple wipe cache and fix permissions, hoping it would fix stuffs. Except it didn't, by a long shot. In fact it had gotten so much severe that my phone was pretty much lagging perpetually. I went ahead and took several screenshots, as fast as my phone would let me. It took almost 20 minutes! :confused: At some point my battery-stats stopped updating. Yet just after I took that last screen-cap my phone shut off. I plugged it in and after two seconds of battery animation, the phone booted itself up. :confused: Didn't know that could happen. Anyway,I let the phone sit there on the charger while booting up and as soon the sdcard check indicator went away, my phone powered down again. I in fact could not get it keep a charge while at the desk (ie phone was consuming faster than the usb could draw from the desktop (I have power only usb cord, can't remember how that matters). So down the drain went to plug the phone to my laptop once I got home and pull logcat, I'm sorry for not helping in that regard but I needed a phone in somewhat useful state. Decided to do a full quadruple factory+system wipe (a: to be on the safe side. b: I may have accidentally deleted the wrong v5 when i deleted those cm based roms off my sd card :o ). Now I'm currently running the same rom with the embedded kernel... for "control" comparison

Well, I'm off to bed. Screen-caps are below.

ps. Sorry about the book.

pps. need more info?

Edit And of course, the photos fail. Hold on gimmie a sec...

Edit 2 Hope this works
[Nexus S Android Development] robyzal:
The 6.1 version is a machine of spend battery

Enviado desde mi Nexus S usando Tapatalk 2
[Nexus S Android Development] spider623:
ok where did 6.0.3 go and why is there 6.1 in it place :silly:

6.0.3 is a battery god for me but from what i have read 6.1 is a drinker but in the matrix it says that they are the same how is this possible :confused:

never mind found it they are the same sorry for trolling the post(even if i didn't know it :silly: )
[Nexus S Android Development] gregorypeg1000:
Slimbean and marmite 6.1v since it was uploaded and everything runs great.No reboot or something.For my phone to be stable at 1096 it needed +25mv arm volt and -50 int volt at 1096 step.
[Nexus S Android Development] kiden:
Guys, for those of you that are overclocking, try switching to smartassV2 and running 100-1000mhz instead. This will keep you more stable and give you better performance. Then if you want to save battery, you can tweak the smartassV2 values using an init.d script to tone it down.
[Nexus S Android Development] Warren_Orange:
Is there any way to get the stock Jelly Bean screen colours back?

I've tried altering voodoo colour but I can't get it the way I like it.

It just seems too green for me.
[Nexus S Android Development] alen1901:
Bedalus, or anybody who knows, what would happen if you would remove 200mhz step from kernel? So it would be switching from 100 to 400 insted from 100 to 200.

Dont start fire now Mister(yeah, you who you are :p), im just curious.

Sent from SpeedMachine i9023
[Nexus S Android Development] caliban2:
(IF it boots - big IF,) you'll get higher batt-drain (400 mhz becoming the new 200)
[Nexus S Android Development] polobunny:
The question is why though? There's no use as far as I'm aware removing frequency steps. :S
[Nexus S Android Development] Warren_Orange:
Ahh forget about the above. I've got it more to my liking now.

Great kernel by the way.
[Nexus S Android Development] alen1901:
I thought it would quicker complete some operation and return back to 100. So it wouldnt be switching 100-200 five times, it would swtich once to 4. Just my lunatic theory. :D

Thats just my question, im asking with no purpose, i just wanted some ideas on that. :)

Sent from SpeedMachine i9023
[Nexus S Android Development] polobunny:
The idea is there, but the battery drain wouldn't be worth it I believe. If you want to reduce switching between frequencies, then use the performance governor. Or same max-min. :p
[Nexus S Android Development] caliban2:
The good old race to idle, I see... Nah, pretty sure you'll pay more than you get. And wasn't there something with the GPU only being fully active from 200 onwards, tamed on 100?

Can't remember, wait for bedalus. Just have a look at cpuspy, 200 shouldn't be used so much anyway.
[Nexus S Android Development] polobunny:
I believe you are right. HW rendering necessitates the CPU to be at 200MHz in Jellybean IIRC.
[Nexus S Android Development] alen1901:
I thought GPU is used at 200mhz only if you are in some GUI, like in some game, or thinkfree office. Like, gpu is used for rendering heavyer stuff.

Sent from SpeedMachine i9023
[Nexus S Android Development] polobunny:
If you need GPU rendering, the CPU speed is at least 200MHz. If you remove the 200MHz, then the next step is 400MHz. So I'm guessing it would be less efficient that way running a higher step for no good reason. Might be wrong, but it's all theory anyway.
[Nexus S Android Development] alen1901:
Yeah. Lets leave it. ;)

Sent from SpeedMachine i9023
[Nexus S Android Development] caliban2:
Just look at my stats from today - I wouldn't want to add that time @200 to 400. Can't imagine it would be saving battery.
[Nexus S Android Development] BenHeng:
I have similar stats (almost) with black bean and marmite v6.1 ... however I used only 2g WiFi during most of the day (no 3g).

No reboots, no lags, no freezes.
[Nexus S Android Development] caliban2:
Nah, mine is with 3g plus wifi in the evening, gmail-sync, beautiful widgets (weather-sync), whatsapp, some browsing - it's a smartphone, after all! :D For this profile I'm pretty happy with battery.
[Nexus S Android Development] alen1901:
I meant 100-400. But i see there is 400 used 1% more than 200, so in big numbers it would be like 10% more. So 200 would be really missing there, yes.

Sent from SpeedMachine i9023
[Nexus S Android Development] :
200 is needed for battery saving.

Anyway, I got extra sleep before work, and also got home early, so I'm going to see what I can do about this 1.2GHz step.
[Nexus S Android Development] BenHeng:
OK, I've just noticed 1 little things that might worth being reported: flashing v6.1 wiped my cache and dalvik. That's not something important but I think it's the first version doing this and it was stated otherwise in the op.

@Caliban: damn you! But you have a pretty good signal all day where I spend half day with a ****ty connection :D

Envoyé depuis mon Nexus S avec Tapatalk
[Nexus S Android Development] jimdem:
I have 6.1 with the AOKP b5 and it is super. I also have a i9023 and the crt off animation is fine. No problems. Perhaps BenHeng you have a value of 0.5 at the animations in developer options?
[Nexus S Android Development] BenHeng:
I had indeed disabled animations. My bad :D

Thanks for the quick correction

Envoyé depuis mon Nexus S avec Tapatalk
[Nexus S Android Development] :
There's no cache/dalvic wiping in the kernel script. ^^

Anyway, after lots of sleep and a shorter day at work, I'm feeling bright and breezy, and have managed this 1.2GHz with no problems.

Custom voltage is allowed for the two OC'd frequencies, but not those from 100-1000MHz. I'm seeing some new wifi errors in the last kmsges that have been posted. I'm not sure if this means I changed something I shouldn't have, or that Dimity's commits just added extra debug prints. Just to be safe, I'll revert the ones I did personally and see if these messages go away.

Will upload shortly.
[Nexus S Android Development] ebs512:
Within 5min of flashing and rebooting to 6.1 had 1 reboot just browsing web site no custom oc or voltages, will keep longer to see if it will settle in nice
[Nexus S Android Development] alen1901:
What about GPU oc, is it oc'ed and if yes, when?

Sent from SpeedMachine i9023
[Nexus S Android Development] :
100-1000MHz ::: NO GPU OC

1.1GHz :::::::::::: +GPU OC

1.2GHz :::::::::::: NO GPU OC and 1.1GHz forbidden
[Nexus S Android Development] :
It might be that I cocked up something in wifi. I've just now attempted to un-**** it, and am running some tests before I make a general release.
[Nexus S Android Development] jayjay3333:
Oh Stop complaining about OCing and last_kmsg's and watch this...lol :silly:

http://phandroid.com/2012/10/23/sht-android-fans-say/
[Nexus S Android Development] :
version 6.2 is here: http://goo.gl/HvUrp

-Fix wifi deadlock issue (again)

-Fix annoying bug where GPU power management resets the minimum frequency to 200MHz

-Merged to mainline 3.0.48 (nothing really here - one revert)

-Add custom OC

The GPU bug fix is very nice because now everyone can use NSTools to set their preferences and tick the 'Restore at boot' option without fear of it resetting the minimum frequency to 200MHz. The same goes for any other frequency control app, or if you are on a ROM with these settings in a menu somewhere. They will now all work properly, and GPU power management is still working.

However, if you've been using scripts to get around this bug, why not keep that going? It's good practice.

Custom OC will be explained thoroughly in the next post, because I intend to link to it in the OP.
[Nexus S Android Development] :
Custom OC to 1.1GHz or 1.2GHz

The overclock I have provided here is to either 1.1 or 1.2GHz. At 1.1GHz you get 10% GPU/FSB OC. Some devices cannot handle this, so at 1.2GHz there is no GPU/FSB OC, and at 1.2GHz the 1.1GHz step will not be used.

Custom voltages are available for 1.1GHz and 1.2GHz but no other frequencies. I.e...

Voltage	FSB/GPU
Control	OC

100MHz	No	No
200MHz	No	No
400MHz	No	No
800MHz	No	No
1000MHz	No	No
1096MHz	Yes	Yes
1200MHz	Yes	No

If you find instability when you are overclocking, you might try to raise voltages.

Raise them in 25mV increments.

It's best to try and find settings that work for you when your battery is low.

The settings included in the kernel are stable for me, even when my battery is below 20%, but you may need to try different settings. And if raising them didn't work, try lowering them.

Because it is possible to raise or lower ARM and INT, there are eight combinations to try:

1) Raise both ARM and INT

2) Lower both ARM and INT

3) Lower ARM and raise INT

4) Raise ARM and lower INT

5) Raise just ARM

6) Raise just INT

7) Lower just ARM

8) Lower just INT

...and if 25mV didn't work for you, you could try 50mV on ARM and/or INT or on both ARM or INT. This gives 32 possible combinations.

...and if you try all these combinations for both 1.1GHz and 1.2GHz, that's 64 possible combinations.

...one of which might be stable for you.

If you are overclocking, I'm not going to be interested in a last_kmsg, because if you're out of spec. there is no guarantee against undefined behaviour. So from now on, only report a reboot if it happened and you were not overclocking

Please try and be thorough when you report a reboot.

-Device

-ROM

-kernel version

-A statement that you were not overclocking

Do not expect me to remember what device or ROM you were on from the last time you posted. Repost that info each time. Do not expect me to read your signature, because I may be on my phone, and unable to see it while using the XDA app. If I am not satisfied that your report met the above criteria, I will not read it. If you can manage that, I will be very grateful, because you will be helping me improve the kernel.

If you cannot successfully overclock your device, be happy with 1 GHz or buy a newer phone.
[Nexus S Android Development] ebs512:
No issues on bb6 great job
[Nexus S Android Development] polobunny:
On an absolutely not related note, I have trouble getting blinking to work. I've posted about this and the past but didn't care enough to troubleshoot it, but turns out I get some time tonight.

Using kiden nicely formatted init.d script. Testing it using Script Manager

# Enabled (0 - Disable; 1 - Enable)
echo 1 > /sys/class/misc/backlightnotification/enabled

# Blink (0 - Disable; 1 - Enable)
echo 1 > /sys/class/misc/backlightnotification/in_kernel_blink

# Blink Speed (1 is fastest; 10 is slowest)
echo 10 > /sys/class/misc/backlightnotification/blink_speed

# Blink Mode
# MODE 1: Normal blinking, no special timing effects
# MODE 2: Starts fast, and slows
# MODE 3: Starts slow, and speeds up
# MODE 4: Starts fast, slows, then speeds up again, etc
echo 1 > /sys/class/misc/backlightnotification/blink_mode

# Max Blink Mode
# MODE 1: how blinks there will be.
# MODE 2/3/4: how many times the pattern will repeat
echo 1 > /sys/class/misc/backlightnotification/max_blink_count

# Final Blink State(1 is on, 0 is off)
echo 1 > /sys/class/misc/backlightnotification/blink_finalstate

Lights don't come on.

If I change max_blink_count to 0, I get infinite blink. So blinking works. If I set it to 1 like in the code above, nada, niet, nothing. So yeah, something is kinda broken, or I can't figure out something simply. D:
[Nexus S Android Development] infernalMan:
i think u've been revolute the android kernel existence.

now kernels would have NIGHTLY version just like roms :D

great work bedalus !!

try it soon.
[Nexus S Android Development] polobunny:
So I tested some stuff while I was waiting for my oven cleaner spray to do it's thing (multitasking manly man or something!)

Switching blink speed to 1 breaks it. The init.d script I posted up there was the one that was working. Setting blink speed to 10, it works as intended. So what's up with that? Theory: It's too frigging fast. :p
[Nexus S Android Development] Skyline969:
Change it to 100 or so.
[Nexus S Android Development] polobunny:
Except I don't want it to blink (uses much more battery than just being on). I want it to come on and stay on. I don't think it's really broken per se, just that setting a blink speed of 1 is too quick for the phone to bring it on and keep it on for some reason. Setting it to 10 works just fine, so that's what I'll use.
[Nexus S Android Development] Skyline969:
Then why don't you just disable BLN?

echo 0 > /sys/class/misc/backlightnotification/enabled
[Nexus S Android Development] polobunny:
Because then the backlight won't come on? :S

---------- Post added at 10:47 PM ---------- Previous post was at 10:15 PM ----------

aaaaaand first reboot in a while. Last_kmsg useless because it seems it soft rebooted back to boot animation (showing kalimocho recovery).

Nexus S i9020a

cm-10-20121023.0907-crespo

Marmite v6.2

I am not overclocking

Uncool :(

Edit: Nothing showed me that v6.0.3 was unstable. I wasn't doing anything with the phone (screen was off), heck I just had it updated and everything.
[Nexus S Android Development] mishamosher:
Sweet. So much thanks for this!

Its me, or I count only 24 combinations? 48 with both 1.1 and 1.2 steps.

First four cases, changing both INT and ARM by +/- 25/50 mV gives 4 cases (+INT/+ARM ; +INT/-ARM ; -INT/+ARM ; -INT/-ARM) x 4 +/- combinations (25/25 ; 25/50 ; 50/25 ; 50/50) = 16

Last four cases, changing only INT or ARM by +/- 25/50 mV gives 4 cases (+INT ; -INT ; +ARM ; -ARM) x 2 +/- combinations (25 ; 50) = 8

Where are those 8 combinations that I don't have?
[Nexus S Android Development] kiden:
If this line is set to 0:

echo 0 > /sys/class/misc/backlightnotification/in_kernel_blink

it will not blink and instead just stay on. Have you tried that?

Also, glad you liked the script. :)

---------- Post added at 10:43 PM ---------- Previous post was at 10:42 PM ----------

wooo! thanks, 6.1 has been perfectly stable. cant wait to try this one out.
[Nexus S Android Development] caliban2:
echo 1 > /sys/class/misc/backlightnotification/enabled
echo 1 > /sys/class/misc/backlightnotification/blink_finalstate
echo 0 > /sys/class/misc/backlightnotification/in_kernel_blink
echo 0 > /sys/class/misc/backlightnotification/max_blink_count
[Nexus S Android Development] ja_ma:
Which version should I use for slimbean? 6.2CM, or just stock 6.2 or 6.2????
[Nexus S Android Development] towelboy:
Regular 6.2 cause its from aosp base not cm
[Nexus S Android Development] :
If I am correct, tchaari will release new version soon, with custom iocontrol, which will require cm base. But 2.7 and earlier require "all other ROM" version
[Nexus S Android Development] X1111:
how can i use this for other kernels as a script please?
[Nexus S Android Development] :
@polobunny

Caliban is right. If you don't want blinking, set it to 0. And you were right about your one blink at speed 1, it goes off again too quick to see.
[Nexus S Android Development] :
Wipe cache and dalvic and fix permissions and pray! Some of the last kmsgs posted recently show some stuff going haywire with the dalvic virtual machine.

If I remember rightly, apps are cached as odex files, so if you flash a nightly, code has changed, so you need to wipe so that these odex files can be rebuilt. It's also possible that the nightlies are unstable of course! But there's nothing I've changed from 6.0.3 that I would say has introduced instability. If it was an actual kernel fault, it also exists in 6.0.3
[Nexus S Android Development] caliban2:
When flashing nightlies, go the long way:

Wipe dalvik, /cache, /system and /boot. Then flash ROM, gapps and kernel. You won't lose any personal settings and apps (that's on /data).

Don't care if someone says it's not necessary, I know it shouldn't be. But too many bugs have been solved that way.

Today's nightly and 6.2 seem to be a great combination, you see new smoothness in list-scrolling (for example "apps" in settings). Let's see if it's stable.
[Nexus S Android Development] atxbang56:
Bedalus : would you marry me?

Sent from my AwEsOmE Nexus S

Samsung Nexus S

Android 4.1.2 Jelly Bean

ROM : MIUI 2.10.19 by MIUI France

Kernel : Marmite v6.2 ( CFQ / SmartAssV2, 1.1 GHz)
[Nexus S Android Development] :
Unfortunately I am spoken for, but I appreciate the sentiment :D
[Nexus S Android Development] polobunny:
I always wipe cache and dalvik on a rom update because I push my modified mms.apk. Doesn't boot get recreated too? There's only system left, but that's kinda of a pain having to push back apks I've made as system apps only to supposedly solve an issue. Fix permissions is my last step every flash though.

Either way, it went through the night without a reboot, so I'll pray for a fluke.

---------- Post added at 07:52 AM ---------- Previous post was at 07:45 AM ----------

I understand the speed of 1, but if it's set to stay on after blinking shouldn't it stay on? Setting it to a blink count of 1 with speed 1 and stay on 1 it will not stay on. :p

Thanks for the rest though, I'll look into it.
[Nexus S Android Development] :
I think it might be better to put your apks in the system folder of the zip before flashing. Maybe you could write a script to automate it. Then you can do it for each nightly with 'one click'

For BLN, you have blink_finalstate set to 1? If so i think you must be right about this bug. I'll look into it.
[Nexus S Android Development] caliban2:
Add those apk's to gapps-zip -> get reflashed every time and you don't have to worry about permissions. Their data & settings are on /data, so no problem.

My gapps-file has 150mb, compare that with yours... ;) Only apps that won't work this way (that I've stumbled upon) are chrome and goggles. Guess they need an .so-file too, but I never cared to find out.

@BLN:

What is it you want? The settings I posted are for "standard" BLN, light goes on and stays on, no blinking. Thought you wanted that, but now I'm not so sure. ^^
[Nexus S Android Development] polobunny:
No that's exactly it, it works fine. :)

The "issue" is that if you set blink speed to 1 and you want the led to stay on after blinking, sometimes it won't stay on, as if the phone didn't register the last on/off or something. Slowing it down will make it work fine all of the time. Another fix is change to more blinks but even then sometimes it won't stay on after blinking. I only tested with the speed at 1, but maybe 2 and 3 are also too fast for the phone to register the changes properly.

Edit: Oh and I'll probably integrate the apks I need as system in gapps. Not a bad idea, and flashing them is pretty quick anyway (much quicker than doing it manually after rom flash anyway).
[Nexus S Android Development] jark99:
On Aokp build 5, getting high "system ui" usage. Inspecting though better battery stats, it shows media scanner service. How do I fix that to use less than 10%/hr? Using maramite 6.2

Sent from my Nexus S
[Nexus S Android Development] sgtkid12:
I am also using Aokp build 5 and on Marmite 6.2 but I am not having that

Problem.