yashsingh1/xdaforums huggingface dataset:
[Nexus S Android Development] :
Anyone on v6.0.3 can ignore v6.1 - they are identical. Linux mainline v3.0.47-rc1 was the same as v3.0.47
[Nexus S Android Development] :
The uevent stuff looks like it might not be necessary, and I completely disagree with the need for boostpulse.
[Nexus S Android Development] caliban2:
Wasn't asking to include them, but if they look like they break custom-kernels. Again. :p But I take it as a no.
[Nexus S Android Development] :
I don't think the uevent stuff will break compatibility, but if it does I'll be forced include it.
[Nexus S Android Development] caliban2:
It's two hours since I updated (on my way to work, makes me a perfectly normal nexus-user), so far 6.0.3 is playing along nicely. We'll see, last time (20121017) it took some hours before the incompatibilities caused crashes.
[Nexus S Android Development] leap_ahead:
thanks bedalus for stable Oc !!!
[Nexus S Android Development] :
You're welcome! How's the facebook page?
[Nexus S Android Development] leap_ahead:
Oh cool !!! 50 like . Many user from there say thanks to you
[Nexus S Android Development] :
I feel famous! Possibly infamous!
[Nexus S Android Development] leap_ahead:
View attachment 1421519
[Nexus S Android Development] CrackerTeg:
That's exactly what I was thinking. For that reason, I was never able to run any trinity kernels OC'd.

Now, my previous statement of not being able to use any version past 5.0.2, I take back. There have been so many versions cranked out its difficult to keep track. 5.0.2 stuck in my head because that had the terrific amount of usable RAM available. I just flashed 6.0.1 and so far so good. My setup:

Latest Rasbeanjelly

Smartassv2 200-1200 stock voltages

cfq (duh)

BLN off BLD set to 1 sec.

Those have been my settings for as long as I can remember. Not a single problem. My suspicion is the adoption of morfic's T11 parts. 6.0.2 and 6.0.3 were horribly unstable for me when I try to use previous settings (except for the OC speed, of course). Thought I would throw my .02 in the ring.
[Nexus S Android Development] alen1901:
Reboot. OC used, 1096mhz voltage bumped up for +25. All was stable. Rebooted while installing SwiftKey and charging. On 1ghz its rock stable. ;)

Edit: Last kmsg,

http://db.tt/vpaOEUSX

Edit2: would you make one kernel only with 1096mhz and not GPU oc? If that 96mhz makes some difference ofcourse

Sent from SpeedMachine i9023
[Nexus S Android Development] :
I think it's possible that I might be able to bring back the 1.2GHz step without FSB/GPU OC, and keep with 1.1GHz with it at the same time.
[Nexus S Android Development] Jamalsid:
Bedalus

Does slim rom come with your kernel by default? I only ask as they give you credit for your kernel sources on their website.
[Nexus S Android Development] :
I've been working with tchaari to help them bring my kernel source code into their build, rather than hacking in the pre-compiled boot.img.

On Slim Bean, the extra RAM will be available by default.
[Nexus S Android Development] Jamalsid:
I'll take that as a yes then?:confused:
[Nexus S Android Development] :
This morning I'm really pleased with myself for solving a really annoying and notorious bug, that the minimum frequency resets to 200 MHz if you try and set 100MHz (via script, NSTools, or the performance settings menu).

That'll be in the next release!
[Nexus S Android Development] Jamalsid:
Good stuff!!
[Nexus S Android Development] polobunny:
Yeah so I updated from v5 after ~177 hours uptime. It's pretty good. :p
[Nexus S Android Development] :
And now NSTools save and restore at boot feature works properly!

Also, just checked, and the power-management is still working (keeping the CPU at 200MHz or over when active)

A lot of crap was said about this being an NSTools bug, which now turns out to be false.

http://xdaforums.com/showthread.php?t=1333696

^ If you haven't already seen arifhn's thread, head over and show some support!
[Nexus S Android Development] Articudos:
R_data didn't planned, but that issue had been fixed only in ics version in long ago:p

Anyway, thanks for fixing this!

Keep your great work;)

V4.8.7>v6.1 my phone is flying now..

I planned to make new kernel controller, but it's needless now:p

Edit: that means...google made it min.freq to 200MHz by default?
[Nexus S Android Development] LibertyMonger:
I was testing for ebs512 and started out oc'd to 1096 and had a freeze-up then reboot so he told me to raise all the voltages by 25 so I did and within an hour later I tried downloading a file and had another reboot. Just for the record. So I went back to v5.2 and haven't had anymore issues and battery life is amazing.
[Nexus S Android Development] caliban2:
Okay, I get it, this is the overclocking-thread. Would somebody be so nice and point me to the marmite-thread? I can't find it. Thanks!
[Nexus S Android Development] polobunny:
I know the feeling. It's gonna be noob overclocker hell now. T_T
[Nexus S Android Development] LibertyMonger:
I don't think you do get it, I was asked to overclock for testing. I was asked to report my results here. Does it bother you that much?
[Nexus S Android Development] AzN MusiQ:
In CWM there was something with:

ununderstandable ... 3

lid is licked.

But in the settings I can see that the marmite Kernel is installed.

Is that normal?
[Nexus S Android Development] polobunny:
Yes, it's a joke.

Not bashing you or anything, but I don't know why people take these messages so seriously. You're not the first to ask if it's normal haha
[Nexus S Android Development] caliban2:
It already is. People overclocking without knowing what they're doing and why their sys is crashing. OC never was and never will be manageable for all by the dev. I'm just sick of all the "bug-reports" because of it.
[Nexus S Android Development] LibertyMonger:
The posts that complain about what other people are doing are just as bad as the noob posts! Why fight it? Why does it bother you so much? You're not gonna change anything to suit your standard of smartness and posting. I hope your sickness passes I'd hate for the rest of us to get it! Lol

I apologize this is a senseless post I'm just as bad for posting it.
[Nexus S Android Development] Nezhac:
Nice!
[Nexus S Android Development] polobunny:
I know what you mean. Actual bug reports get flawed by overclocking crashes, but most people wouldn't know the difference. That means less actual bug fixing and more fscking around trying to fix something that can't be fixed. I share the same opinion on overclocking as you. I've been overclocking computers since the Pentium II days and I know how it goes, but you'll never see me submit any sort of crash, bug or anomaly report if I'm running my hardware out of spec.

Try not to troll so hard, it's a valid point. Every second spent trying to figure out something caused by an unstable overclock is a second not spent improving important stuff. You know, like real stability issues that could arise whether you overclock or not.
[Nexus S Android Development] DarkhShadow:
Got reboot on 6.0.3 OC at 1,096

I have no idea if this is a full last_kmesg or if it was due to voltages but it was stable for a good 4-5 hours

http://db.tt/z8FLxqjL

Sent from my Jelly Nexus S
[Nexus S Android Development] kwibis:
Maybe we should not report bugs when oc? As the kernel itself already offers enough speed. If you want to oc, the kernel offers 1200 step already and in the future maybe 1100 as bedalus mentioned earlier.

Sent from my Nexus S
[Nexus S Android Development] atxbang56:
the main problem is that most people don't read posts before and on the first reboot they say "the kernel has a bug". read read read before telling s**t

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.0.3 ( CFQ / SmartAssV2, 1.1 GHz)
[Nexus S Android Development] alen1901:
Knock it off, acting like children here. Every intent for help in kernel dev is appreciate, and for the ones who dont know what they are doing or thinking wrong, we are here to help and direct in right direction. In simple, peaceful manner. We are like big family here. :rolleyes: so please stop fire and lets get back to topic. ;)

Sent from SpeedMachine i9023
[Nexus S Android Development] alen1901:
And for help. If you use 1096mhz OC, apply this Voltage like i did and test. So far its stable for me.

You see "setting to apply", thats what i raised. I raised voltage for 1096, 1000 and 800mhz.

Sent from SpeedMachine i9023
[Nexus S Android Development] caliban2:
Mhm. Okay, I'll help you with a question:

Why on earth did you up voltages for 1000 & 800?! Those steps are spec, they're set to stock-voltages. If any, you'd lower them, trying to squeeze out a littlebit more batt-time. But upping them - what's the point?! Where's the connection to the 1096-step? :screwy:

Edit:

Just had a closer look at your screenshot. Nice. Did you know that the smallest step is 25mV, a limit set by hardware? Your changes of 5 & 10mV do nothing, the CPU jumps to the nearest 25-step. (In your case: no change at all)

Maybe now you understand why overclocking is a field of it's own.
[Nexus S Android Development] alen1901:
Believe or not after i applied that voltage, my phone doesnt reboot. If i would raise only for 1096mhz, my phone would reboot after 15min of usage. Now its stable, we will see how far.

And dont be rude, not all of them here are smart and understand things. Just help if you want or pass it. Fox example now i learned about voltage thing, i suspected i can apply only 25mv to be affected but i tried and see if it applies less. It did, so i thought i can set like that. Hey we are all here to learn something. ;)

Sent from SpeedMachine i9023
[Nexus S Android Development] caliban2:
Did you always raise 1096 by 15mV? That means a jump of 25. If you did, it means you still can't trust it. If you didn't - well...The voltages of 800 & 1000 have nothing to do with it. And you still don't know if OC was even the reason, or something else. Btw, what are you raising? ARM, INT, both? GPU is overclocked as well @1096, so its voltages come into play as well. And then there's the factor of each phone being special, nobody knows how much your chips can take. What does this have to do with kernel-development?!
[Nexus S Android Development] alen1901:
Oh, ill quit posting now. It doesnt have anything with development but it has to do with open community and helping. Period.

Sent from SpeedMachine i9023
[Nexus S Android Development] :
r_data didn't fix this in his ICS kernel...

I found this: https://github.com/edoko/AIR-Kernel_ICS/commit/1dd16441395b52d12f4fd96e29b8eebe59dc8fbc

...but it's Ezekeel's Live OC commit, and it doesn't fix the issue, it just breaks power management by allowing the CPU frequency to drop below 100MHz even if the GPU is active.

Caliban2 is right, your voltage settings won't have had any effect because they need to be at 25mv increments. Also, custom voltage is disabled for 100/200/400/800/1000 MHz, as I stated when I released it. It's also in the OP, and in the changelog. This is to prevent the propagation of the myth that reducing voltages increases battery life. See my battery thread (link in sig.) Someone a few posts up already stated that reducing the volts increases battery life, which is a rather annoying myth that will be brutally stamped on in this thread.

In other news, 3.0.48 was released, so I'll update again. I'll release this version with the properly working GPU power management once I've re-introduced 1.2GHz without FSB OC. It'll be interesting code, because if that step is selected, the 1.1GHz step must be made unavailable. As far as I know, that's going to be quite a unique feature.
[Nexus S Android Development] CrackerTeg:
That would be great if 1200 comes back without the FSB OC. Eagerly waiting but perfectly content with 6.0.1 right now.
[Nexus S Android Development] caliban2:
Hehe, time to be provocative a bit... ^^

Of course it saves power. question is how much, is it even worth mentioning and worth the hassle to get it stable. (I know it's 1 or 2%)

:p :p :p

*taking cover, bracing for impact*
[Nexus S Android Development] CrackerTeg:
Quick! Duck behind the couch! If he can't see you, he can't hit you.
[Nexus S Android Development] :
Saves miniscule amount of power, then phone reboots and eats more than what you saved. Large risk for tiny gain is a bad policy.
[Nexus S Android Development] mishamosher:
Got confused here...

1.1 GHz and 1.2 GHz are going to be available in NSTools/Script/Whatever at the same time?

And, if 1.1 GHz is selected, FSB OC will turn on in 10 %, else if 1.2 GHz is selected FSB OC will turn off. In any other case, well... pretty obvious, no OC in CPU neither in FSB. I'm right? If I'm, men... that's gonna be cool, you're gonna have a great work done!

BTW, so far, zero troubles in marmite 6.x, including the extra ram CM versions. No OC.

Thanks for so great kernel and support!
[Nexus S Android Development] anshumandash:
After looking in to some posts above, I have a question. Should we continue to post issues & last_kmsg or not? If we need to follow rules, I would suggest Bedalus update the op with rules & only when an issue qualifies the rule, they will be posted in this thread.
[Nexus S Android Development] Hawkw1nd:
I guess if you have troubles whilst o/c, then don't bother posting unless the same error occurs @ normal clock rates?
[Nexus S Android Development] Articudos:
I learned something new..;)

[]
[Nexus S Android Development] asphantix:
Really love this kernel but I recently flashed fully stock 4.2.1 and the battery last longer than a day. Would love to stay with marmite but at the end of 8 hours work the battery is really low. Is there someone who gets >= 24 hours out of the phone with marmite?
[Nexus S Android Development] capoooro:
Now with 6.0.3 no trace at all of os battery bug. Always with strawberry.

Tnx
[Nexus S Android Development] leap_ahead:
after 15 hour i get reboot...

View attachment 1423697
[Nexus S Android Development] VerminX:
Another reboot on 6.0.3

I was browsing the net

Running rasjelly on 9020t 1096 overclock no voltage change

Kmsg included below

https://www.box.com/shared/i8odwrv9wspy5osln2zp
[Nexus S Android Development] LibertyMonger:
I suggest you read my posts before making accusations. I stated I was asked by ebs512 to overclock to 1096 testing it on blackbean 6 with marmite and I was told to report my freeze up and reboot here. So the whiners about me reporting my overclock issue would be the trolls. I never claimed it to be a bug. Maybe before bb6 decides to use marmite as a default kernel, they would like to see if it can handle 1096. It was none of any of your business to waste our time *****ing about something that didn't involve you.
[Nexus S Android Development] blakmazk:
Yeh yeh, WAR... yeh...
[Nexus S Android Development] StyxD:
6.1 on latest Slim Bean (2.7.0), no OC.

12+ hours working, no reboots or fc or whatever, everything seems fine. Good job.
[Nexus S Android Development] _yaz_:
yep. i have the same problem. the v6 serie produces some extreme drain. it seems as if sg would prevent it from going to sleep. tonight i detected about 5%/h drain which is fatal. so far, i haven't found any special w/bbs. as i haven't changed anything in the rom part it should be some kernel issue ... :-/

further i have rare but regular soft reboots (or whatever it is when there's no need to enter the pin but the system restarts). again, no real evidence for that. just a feeling but as if it'd be again sg with going to sleep.

i don't hack the kernel in any way. no oc/uv/..., it's ondemand/cfq as it is.

i'm on the same combo. use is excellent but the sleep state is quite strange. have you got stable low consumption sleep state ?

@bedalus

is there any hard coded timer for bln ? i use nstools to tune the kernel but i've just noticed that bln went off after awhile even if i set the timer to 0. point me please to the info how to set it exactly. (i don't used bld, so don't waste your time with that ...)

i love your kernel, anyway, so keep on please !
[Nexus S Android Development] Daniel.Stevens:
SlimBean 2.7.0

marmite 6.0.3 (6.1)

No oc, custom voltages etc. (For normal use it´s blazing fast and stable that way)

normal use (WhatsApp, Calls, G-Talk, Navigation, Twitter, Taking pictures etc. with 8 hours in airplane mode overnight)

Thx bedalus ;0)
[Nexus S Android Development] dotlab:
Well, speaking about reboots, 95% of them are result of OC which is IMO completely not needed. Get real, our phone already reached it's peak or in best case is very close to it. Hardware is almost squeezed to it's max and OCing by 100 or 200 MHz is pretty bad tradeoff for maxing the chance for instability and reboots. I was a crackflasher before but now the most important thing for me is to have a stable phone with good battery life and this kernel is already polished to bring everything I need, especially since Bedalus put fast charge in it. So to keep it short put your max freq to 1 GHz and just enjoy it ;)

Besides that, thank you Bedalus for your dedication to nexus, starting from benchmarks and this kernel is just a cherry on top.
[Nexus S Android Development] caliban2:
That's how it's intended to be. Until recently bedalus thought 800 MHz to be the most power-efficient frequency with deep idle. He changed his mind and now it's 400, but this has only been included in 1.4-test.

Long story short: everything's working as it should on your v1.3b.
[Nexus S Android Development] :
It's an everyday ondemand governor, it's just slightly more responsive. There's an overhead to the increased polling, but hopefully this is compensated for by the fact that it can drop to a lower frequency sooner if appropriate. It's a compromise between the stock ondemand governor and franco's tweaked ondemand governor. I think first, Ezekeel lowered the polling frequency to 30kHz in his lazy governor (ondemand based), then franco halved that, and also dropped the ramping up threshold to 80%. For me, Ezekeel didn't go far enough, and franco went too far!

As for my smartassV2 settings, I've not really worked on that. Well, I worked on it a bit, then it got messed up, so I borrowed steve.garon's setup, because I know it works well, having tested it: here.

There may still be room for improvement
[Nexus S Android Development] :
vis80k, you're using a kernel that's being developed based on my research: http://xdaforums.com/showthread.php?t=1639689

If you have DI disabled, you won't see that consistent 800 MHz. However, you want this! It's a power saving feature. Have a good read through the OP.

As caliban2 says, 400 MHz is actually the ideal DI frequency. I've a few testers running it now, and no-one has had any issues. I haven't released that one publicly yet because I'm making this feature more sophisticated. Currently, DI is fixed at a frequency by stashing the user's min/max preferences, then telling the system to use 400min/400max until the UI is restarted, when the stashed values are restored... which is a bit of a hack. The problem with this is that the governor still wastes CPU cycles calculating what frequency it wants to go to next, even though it's wedged at 400.

Instead, of this I now only set the max=400, and call the performance governor, which wastes no CPU cycles since it does not try to calculate a different frequency step to jump to, as by design, it's fixed in one place.

I've spent about 20 hours on this, coding, researching, building, flashing, rebooting, reading my debug messages... It's taking me a long time because I'm a noob kernel hacker. Fortunately after a little sleep, I seem to have fixed it.... However, I'm not 100% sure what happened, but I think I had a SOD [Sleep Of Death] so I'm not even releasing this to testers just yet.

@thalamus / morfic: if any of this is BS please straighten me out! :p
[Nexus S Android Development] caliban2:
How can you be unsure of that?! :D

Either your batt ran empty or it didn't wake up from standby. Apart from being annoying, SoD is pretty much straightforward. ^^
[Nexus S Android Development] KrisMurdrum:
Kudos for a great kernel!

Installed v1.3 about 21 hours ago and to begin with, my phone went crazy and drained a full battery in 6 hours. When I looked at the battery stats I saw that the phone had been awake ever since flashing the kernel. Unfortunately, at that time I had been up for 30 hours so I didn't think to pull logcat. While I was trying to screen-cap my phone died so I just shrugged, plugged it to the wall and went to sleep.

Been up for roughly 7 hours now and battery is still at 45%+ charge. No abnormal phone awake state.

Bugless Beast 06.09

Marmite 1.3

ondemand

100 - 1200

DI off

default scheduler

NS Tools won't work for me so I use Rom Toolbox but that app will not let me edit the last two and I'm too lazy to search for possible terminal code to alter them.
[Nexus S Android Development] :
I'm extremely tired. I may have just turned it off and forgot.

Anyway, I've decided to put out a new call for testers!

PM if you want to test and know how to collect a last_kmsg.

v1.4.pfrm_DI.zip:

-This new one is, as I'm sure you've read, a bit more experimental.

-DI is fixed at 400 MHz as with the previous kernel...

-...but this one achieves it with the performance governor.

-Don't worry, your governor gets reset to normal when you wake the UI

-Known issue: if you set your min at or above 800MHz, DI will sit on that instead.
[Nexus S Android Development] AirOne70:
Ok, thanks. But with 0.2b, I can't change "Screen v1 gamma hack" in Voodoo Sound 3.1.1.. :crying:
[Nexus S Android Development] vis80k:
ah. thought 1.3b was the one changed to use 400 during didle. my bad.

anyhow good that bedalus decides stay out of 800 coz it was making the phone pretty warm for comfort just listening to music...and battery drain was quite a bit in my case...which defeats the purpose of didle.

anyway, didle hasn't been goos to me in the past so I guess I'll turn it off for my use.
[Nexus S Android Development] Randomwalker:
Some more feedback on v1.4: had a couple of calls, used my phone as a A2DP music source for 2h in the gym, no issues at all, DI working.:good:
[Nexus S Android Development] madd0g:
Ah, wasn't aware JBQ posted the kernel sources already.
[Nexus S Android Development] :
That's not good. Heat is an indicator that your DI isn't working. Reboot your phone!
[Nexus S Android Development] Randomwalker:
Just had an old DI issue rear its head again: lost radio, only reboot would restore it.
[Nexus S Android Development] :
It'll either be fixed in the next testing version, or I may have to settle for the 800 MHz.
[Nexus S Android Development] 309041291a:
The kernel is incredibly stable. No reboots, slowdowns, jitters, nothing. Good work. The only request I have is changing the Voodoo Colors... I can't use the same custom colors I always use on this version. Morphic's Voodoo colors are too white IMO.

Nexus S (GMS i9020a)

Paranoid (1.6 - 4.0.4)

Matrix Kernel (CFS - 20.0)

Intellidemmand (800/100)

Deep Idle (On - Noop)

Live OC - 105 (800/1000)

BLX - 98 (Inverted Apps)
[Nexus S Android Development] caliban2:
On which test version is that? I'm not getting it at all on the first 400-version.
[Nexus S Android Development] Blackcrx:
sorry but how many versions are there for 1.4?

i think have the original 1.4test with 400mhz DI and everything has been awesome. no lag, reboots, reception issues at all, over or close to 48hrs of use

is there a second version of 1.4 that needs to be tested now?
[Nexus S Android Development] caliban2:
Yeah, this one: http://xdaforums.com/showthread.php?p=28891420

I'm on the first one too, never received a link from bedalus. Maybe he's been busy. Or slept all day. :D Anyhoo, 1.4-test is a keeper for me, should the new approach lead to nowhere.
[Nexus S Android Development] Randomwalker:
plain 1.4
[Nexus S Android Development] Athhar:
Works great

works great

but does not give a unified system storage.
[Nexus S Android Development] madd0g:
That's impossible on Nexus S, layout ain't the same as on GN.