yashsingh1/xdaforums huggingface dataset:
[Nexus S Android Development] KrisMurdrum:
Flo's 100.1 % Stock Google

Marmite v6.6

i9020t

Default kernel settings

Had a reboot last night while working. Wouldn't have noticed if I hadn't looked at battery stats.

As can be seen in this screen cap it happened shortly after I took it off the charger and got off a ten minute break

Here is my last_kmsg http://ubuntuone.com/1SGOKWB6w5l4pZgCIVmGed

Carved into the void with my Magic Rune Stone
[Nexus S Android Development] :
The bus clock caused a kernel panic. You're running a version that I pulled. Update to the latest please!
[Nexus S Android Development] skavis:
well that was easy. and WHAT a compression!! 900kb to 33kb!
[Nexus S Android Development] :
This isn't the first time I've seen some crazy stuff about Bluetooth in a kmsg. Were you using Bluetooth?

I may have to see if any recent commits from Android common have impacted on Bluetooth code. Maybe they messed something up.
[Nexus S Android Development] caliban2:
... and on the other hand it jumps right up to 1000 each time it wakes up. I just tried it, those two steps each manage 35% of workload during screen on (no heavy duty stuff, just reading and scrolling, bit of typing). In between steps, and especially 400, aren't used so much. Smartassv2 has around 80% in the area of 100-400, ~5% on 800 and 15% on 1000. (I've reset cpuspy and read some articles with opera for 10 minutes)

In standby it's the same picture, ondemand wakes up at 1000 and then goes more or less directly to 100. SmartassV2 wakes up at 400 and scales agressively down to 100. (smartassv2 with the settings posted beneath)

As for responsiveness - ondemand is losing. It really does. It may save a tiny winy bit of battery, but for gaming you still need another setup and it's less snappy in daily use.

That's why I'm so unhappy with the loss of 200 - I need it for my all-purpose-gov. ^^ (Remember, I'm playing NfS MW and Temple Run with it too)

After all it's still your kernel and I can always start/try to compile my own. But please, just for laughs, try these settings: :)

echo smartassV2 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo 400000 > /sys/devices/system/cpu/cpufreq/smartass/awake_ideal_freq
echo 100000 > /sys/devices/system/cpu/cpufreq/smartass/sleep_ideal_freq
echo 400000 > /sys/devices/system/cpu/cpufreq/smartass/sleep_wakeup_freq
echo 50 > /sys/devices/system/cpu/cpufreq/smartass/min_cpu_load
echo 85 > /sys/devices/system/cpu/cpufreq/smartass/max_cpu_load
echo 200000 > /sys/devices/system/cpu/cpufreq/smartass/ramp_down_step
echo 200000 > /sys/devices/system/cpu/cpufreq/smartass/ramp_up_step
echo 49000 > /sys/devices/system/cpu/cpufreq/smartass/down_rate_us
echo 48000 > /sys/devices/system/cpu/cpufreq/smartass/up_rate_us

PS: Of course, without the 200-step, its workload goes to 400, also that from 100 (the ramp_down-story)
[Nexus S Android Development] :
I'll put some more thought into it when i get back from work.
[Nexus S Android Development] omlet:
going back to 6.6 much faster at all!
[Nexus S Android Development] beppegg:
I too am having the feeling of 6.7.1 being less smooth then 6.6-6.7. Maybe it's just my imagination..

Inviato dal mio Nexus S con Tapatalk 2
[Nexus S Android Development] :
After doing a little digging, it seems the HCLK_MSYS value I mentioned before (the reason I removed the 200 MHz step) may be fine. It does however need further investigation, as it seems that the value for this in the samsung sources changed in moving from gingerbread to ICS. It might be that they made a mistake, or that some extra code is required, but it's really difficult because the code is not only complex, but has transmuted vastly over time. I'm trying to learn what each bit does, and did, and how it changed, what is needed, and why certain bits were discarded.
[Nexus S Android Development] :
Get onto 6.7.2 please!
[Nexus S Android Development] polobunny:
46 hours with test version so far. Except a glitch where Gmail hung and started draining my battery, nothing wrong to report. So far. :p
[Nexus S Android Development] CrackerTeg:
I'm thoroughly enjoying 6.7 with custom smartass settings. Mmmm butter.
[Nexus S Android Development] :
If it turns out that it was ezekeel's bigmem that was responsible for the steady stream of reboots I'm going to kick myself, because I thought I'd already eliminated that. But it does mean that I can start re-integrating some other things that I suspected of causing instability, like the SLUB memory allocator, 200 MHz step, uh, disable some debug stuff... It'd be nice to have a properly stable kernel. Better not jinx myself now... Luckily the table I'm touching is made of wood.
[Nexus S Android Development] CrackerTeg:
Bed, I mentioned in my previous post about custom settings. The settings I'm using on 6.7 are caliban's. I'm really enjoying it just like that and would recommend those settings for anyone else. Of course, I'm running at 1200 and smooth on stock kernel voltages.
[Nexus S Android Development] polobunny:
I don't know, did you remove ezekeel bigmem for the vCM you linked me to? Because that's the one I'm running and so far all is good. If you removed it after, then that's not linked in my case.

Edit:

That one
[Nexus S Android Development] skavis:
It may of been turned on (bluetooth), but I wasn't using it at the time. I only use it when driving and it's never given any issues.

*edit - and by the way.. you are amazing.
[Nexus S Android Development] caliban2:
About bigmem:

It's still stable for me @407mb. How long is it at that now, one month? Apart from OC, I think some bug reports are caused by sub-par setups, meaning something's fishy in the ROM. One of my oc-crashes caused my phone to lag afterwards, only a full wipe fixed it. Since nothing had changed (ROM, kernel, apps), one of these crashes must have been the cause (corrupted data somewhere).

Yeah well, on 1200 MHz... :rolleyes:

Glad you like them. But keep in mind that screen-on-time will be a bit less than with ondemand. We can't have performance AND batt-saving. It's always a compromise, but this one is worth it I think (one fits all).

I have to add that I'm using these settings since December or January (before marmite showed up), and back than I had to overclock or use performance-gov to play temple run or NFS hot pursuit. Not anymore, marmite has been getting better and better and in the last month CM had a performance-boost of its own. Why am I telling you this? ROM and kernel have an in influence of their own, so if your using an older ROM or even stock, these settings maybe won't allow lagless gameplay. They are not tuning smartass towards full performance (which would mean more batt-drain).
[Nexus S Android Development] :
Good point. I'm not sure. Check settings > about phone > hardware information > memory

People are still reporting reboots on 6.7 and 6.7.1 but not yet on 6.7.2
[Nexus S Android Development] beppegg:
My, I was sure I'm running the latest version.. Updated right now!

Anyway, this morning my phone froze just before ringing my alarm... I discovered that an hour later and I had to pull the battery...

(now I'm an hour late! :p)

Inviato dal mio Nexus S con Tapatalk 2
[Nexus S Android Development] :
Were you on v6.7.1?

v6.7.3 will be out soon. I'm going to bring back 200mhz and use add Caliban2's smartassV2 settings, within the next couple of hours.
[Nexus S Android Development] caliban2:
So you tested those settings yourself? Hope you don't just take my word for it. :D Thanks for bringing 200 back!
[Nexus S Android Development] :
Well, it's going to be a hybrid
[Nexus S Android Development] beppegg:
Yes I were... And I have just flashed 6.7.2! :D

Inviato dal mio Nexus S con Tapatalk 2
[Nexus S Android Development] caliban2:
Hehe, lemme guess, you don't trust 400/100/400, we'll see an 800 there somewhere. :D Definitely gonna try yours though.
[Nexus S Android Development] :
Sorry about you being late btw. I guess that's a tricky one to explain to the boss.
[Nexus S Android Development] vnsilva:
Reboot's (need help)

Hi

I'm using version 6.7.2, but the problem is not in this version, because I reboot's in any version.

Already tested in OC and stock, the reboot's always occur.

Lately I've noticed is that before the reboot the image is distorted

I'm using rom miui 2.11.2

Bedalus, thank you for sharing your work

ps: sorry my bad english
[Nexus S Android Development] :
v6.7.3: http://goo.gl/HvUrp

-Added a missing config option for the 8998 chip which fixes a kernel warning during bootup, may improve stability. May do nothing!

-Meddled with smartassV2 options to make it slightly more power saving. Thanks caliban2, although I didn't use his settings, he inspired me to take another look at it

-Re-enabled SLUB memory allocator, more high performing than SLAB, and apparently not correlated to instability since my initial removal of it hasn't helped

-Restored 200MHz step, it appears the setting I use for the 200MHz step were standard in Gingerbread, so I'm happy that they are stable, and it certainly helps improve the smoothness and potential for battery saving

I'm fairly convinced that the source of reboots has been uncovered, but time will tell. Feedback please! If you're interested in trying to collect a last_kmsg for me, please avoid OC. So far good reporting has helped me determine that the reboots are not device or ROM specific, so keep it up. Thanks to all the brave testers who are willing to be late for work to improve this kernel! :p
[Nexus S Android Development] :
Well, that sounds like a voltage issue. I know CM upped their 1GHz step to 1275mV, so I'll investigate this option a little more. I can provide custom voltage for this step if necessary.
[Nexus S Android Development] vnsilva:
Tell me what I can do to help.

I put in the last post (edit) the file last_kmsg.
[Nexus S Android Development] hiphopboy:
File not found when clicked on Download link
[Nexus S Android Development] caliban2:
You got the links, but no 6.7.3-files on server. :)

http://d-h.st/users/bedalus?s=file_created&d=DESC
[Nexus S Android Development] :
Thanks, off the back of that voltage idea, I just checked and it turns out I'm unintentionally undervolting something, so I've corrected it (whatever it is, some sort of voltage regulator for an internal rail I think) and I'm re-uploading. I'm not sure if this is going to help or not, but it's worth a go. Links will be restored shortly.
[Nexus S Android Development] :
Wait a while, v6.7.3 will be up with fixed volts soon.

EDIT: Links restored.
[Nexus S Android Development] hiphopboy:
You always care about our question ! Thanks for your support bedalus :) Every luck to you :)
[Nexus S Android Development] treesurf:
Could someone please educate me as to what the "Powersave" option in NSTools does? Is this something that can help save battery, or am I asking for trouble if I mess with it?

By the way: my totally unscientific impression after using 6.7.3 for 10 minutes is that it seems smoother and quicker than 6.7.2. Take that for what it's worth...which isn't much. :P
[Nexus S Android Development] aladin6:
Feedback: AOKP+marmite 6.7.3, smartassV2 => performance is unbelievable :). I'll see battery ;)
[Nexus S Android Development] :
It's definitely smoother. Powersave isn't available in my kernel. Are you asking generally?
[Nexus S Android Development] alen1901:
What about RAM in 6.7.3? Is it reduced to 403?
[Nexus S Android Development] caliban2:
Does it say "restored some bigmem-thingy" in the changelog?
[Nexus S Android Development] CrackerTeg:
Now I don't disagree but I overclock because I can with this kernel. Other kernels I've used in the past, my phone couldn't take it. I know I really don't need to most times but having that quick boost when it does become necessary helps. Either way, my usage normally doesn't touch the higher frequencies very often. Here's a last screen shot of CPU spy to show.
[Nexus S Android Development] deetailed:
I was just about to post about having used 6.7.2 stock for 25 hours without reboot, but 6.7.3 is already here, lol.

Sent from my Nexus S
[Nexus S Android Development] treesurf:
Under the CPU settings in NSTools is an option called "Powersave bias" which can be adjusted on a scale from 0 to 1000. I'm using the latest version of your kernel.
[Nexus S Android Development] alen1901:
No, but i thought he just updated 6.7.2 with new thingys. You could have just answered like: no, RAM is not reduced, or - no, RAM is like before 407mb. It would sound less arogant.
[Nexus S Android Development] caliban2:
While you could just read the logs or flash it yourself and see for yourself. It would make you look less lazy and taking advantage of others.
[Nexus S Android Development] alen1901:
For your information you were not helpfull at all. I flashed it. And guess what, it has 404mb of RAM, and not 407. -.- now zip it.
[Nexus S Android Development] :
0 is the most power saving. I wouldn't change it.
[Nexus S Android Development] :
Bigmem was reverted in v6.7.2 that means 4 less mb ram, which i can always add back, but i think it's the source of instability.
[Nexus S Android Development] caliban2:
I see what you did there...

While I can understand awake_ideal @800 for gaming (on slow systems :p ), I was always wondering what you need that high frequency for during standby? (honest question)
[Nexus S Android Development] Basche:
Just a question here, I like the settings caliban had posted earlier and when i power off my phone and turn it on, the setting in nstools are reverted back. I have saved the settings and have to load it every time I turn on my phone after powering it off. How can i keep the settings?

You have just been beamed
[Nexus S Android Development] CrackerTeg:
Read the first post. There's a link on how to do it.
[Nexus S Android Development] Basche:
Are you talking about setting preference with init. d part?

You have just been beamed
[Nexus S Android Development] polobunny:
407Mb of RAM and 60 hours (and counting). I might just be lucky and haven't yet encountered a reboot.
[Nexus S Android Development] CrackerTeg:
Yup.
[Nexus S Android Development] alen1901:
Bedalus, did you put your own volts for arm and int at 1096mhz?
[Nexus S Android Development] :
It's definitely an exciting development. I'm going to measure the amps before i abandon Ezekeel's.
[Nexus S Android Development] :
@testers of 400_pfrm_DI.zip can you switch to CFQ and see if you get SODs?
[Nexus S Android Development] Randomwalker:
Here it is, I hope it's of any help...
[Nexus S Android Development] :
Remove this line and see if it behaves right:

echo 100000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
[Nexus S Android Development] Blackcrx:
haha. same problem

i havent had a single SOD since install. i'm starting to think it is user error. haha

original 1.4test kernel. will try airplane mode later at home or at the gym
[Nexus S Android Development] :
Lol, oh dear, that looks kinda funky.

Something is slightly screwed up there...
[Nexus S Android Development] caliban2:
Right, forgot about that. Step is used now.
[Nexus S Android Development] polobunny:
Hey bedalus, is there a reason the Voodoo colors are so off? I can't use my usual Voodoo colors neither can I actually get anything close to it. A bit clueless here. Everything is just so... yellowish... and bright.

Otherwise keep up the good work. It's nice to see you with your rigorous testing developing something on the solid grounds of _thalamus. Good set of features and you're making DI actually worth using. :good:
[Nexus S Android Development] Randomwalker:
Care to elaborate a little bit? Are you talking about the kernel or the testbed (phone/ROM etc.)?
[Nexus S Android Development] :
The kernel.

pick_next_task_rt() should not be bugging. Lol.
[Nexus S Android Development] Blackcrx:
Quick question bedalus:

do you want us to move to the new kernel for testing and stop using the original 1.4test with 400mhz DI?
[Nexus S Android Development] polobunny:
Any answer for me bedalus? :)
[Nexus S Android Development] :
A few people have taken issue with morfic's multipliers. They don't seem to work the same on this kernel as they do in his, but I think he doesn't use voodoo, so there may be some other maths going on somewhere that I don't know about... still I think the colour is an improvement on the one's I got when I originally merged in steve.garon's voodoo branch. Have you tried playing with the gamma settings in voodoo app? Tried raising all of them to the top?
[Nexus S Android Development] polobunny:
Yep. I cannot get actual "blacks" with any settings. Whatever I try, they're all greyish. And the colors at "default" aren't like morfic's either. :/

That's pretty much the only thing bugging me. I know this is meant to be a personal kernel of yours, and people who like it can use it and the others can... skip it, but it would be nice if voodoo colors implementation was properly working, or at least you could achieve a decent color.
[Nexus S Android Development] :
Well, even though I am a complete novice, my interpretation of that is that message is that the smartass governor is having a fight with some code that kalim wrote, that I'd removed because it seemed to be redundant, but I changed my mind and brought it back. I put a printk in there, which is how I was able to get those * * * DAVE * * * messages into the log.

I've taken that code out again, and have a new testing version (DI at 400) which I might be emailing to the private testers. If anyone else also wants to help and knows how to collect a last_kmsg, please PM me.

EDIT: Maybe not, had a SOD within a few minutes. I think it's just the 400 step. That's a shame. I'm gonna call it quits with that step. Lemme build an 800 MHz version, and I'll update the general test version.
[Nexus S Android Development] :
I think partly it could just be individual subjectivity... But I'll take a look at what the other devs are doing and see what I can come up with. Um, but not until after I abandon or achieve stability with this 400 MHz DI.
[Nexus S Android Development] polobunny:
I completely understand. It is indeed a subjective thing, but just find it strange I cannot get real blacks with it.

Is there a reason why "basic" voodoo colors wasn't implemented instead of using morfic values then stacking voodoo stuff on it? Simply wondering, not looking to start a debate here. :p

I also conceive it is not exactly your priority, since many people seem to have no problem with the colors as-is. Maybe it not so bad on S-LCD, as opposed to SAMOLED?
[Nexus S Android Development] y3mita:
True, after applying values (morfics multipliers) to this kernel you won't get the rich dark colors as in trinity. You need to adjust with voodoo app to get it as close.
[Nexus S Android Development] polobunny:
Were you able to replicate VERY similar results though, using the voodoo app? Because I cannot seem to get it right. Otherwise I wouldn't be asking here, rather providing a conversion chart for those interested. :p
[Nexus S Android Development] caliban2:
Well, if even polobunny(!) gets a stable system with 407 mb, it might be okay after all... :D :p

Now excuse me, I have to find some cover before polobunny gets back to me for that remark. ^^

---------- Post added at 04:07 PM ---------- Previous post was at 03:53 PM ----------

No, I just meant something would have to be really, really wrong if it wasn't running smooth @1200. :)

Btw, right after boot it runs consistently at the highest step for 2-4 minutes, depends on how long indexing the sd-card is taking. Take that into account when reading cpuspy-stats.
[Nexus S Android Development] polobunny:
I see what you did there... ;D

I won't call that stable just yet though, because I've had problems up to the 100 hours mark. We'll see how it goes, but i'm pleased with the results.
[Nexus S Android Development] caliban2:
Come on, we're all running beta-stuff, be it ROM or kernel. Are you still on that KANG in your sig? You can't go any more "beta". ^^ Expecting 5 days uptime is - well, wrong. I'd say everything reaching 48h is already okay.
[Nexus S Android Development] polobunny:
Yep, still on it. Can't build something solid on weak foundations. I think bedalus would agree with that. =)

And 100 hours is just 4 days, psh that's no biggie.
[Nexus S Android Development] caliban2:
4 and 5 are so close on the keyboard, add my fat fingers and you'll see that my math-skills might have nothing to do with it. :o But my point stands, you're asking too much from your ROM. Also, even if it holds 4 days, you'll still be reporting on an old kernel. At the speed bedalus releases them, you would be 2, if not 6 (^^) versions behind. What's the point?
[Nexus S Android Development] polobunny:
Pointing out bugs? There's no reason a bug couldn't be skipped if you only stay on the same kernel/rom version for 20 hours at a time...

Bedalus thinks bigmem might be causing reboots and glitches, but so far I've got nothing when I used to have a reboot on previous versions. I don't think bigmem is to blame here, at least not in my case as I stated earlier.

I don't think there's any point just trying every freaking thing you can when it comes to development, even less in kernel development. That's only a good way to blur every idea you had of what could be causing problems. I agree with thalamus on that point, bedalus releases too many kernels in too short of a time to get a good representation of what's going on, and I'm sure bedalus himself would agree that statistically, you can't make any actual trend with such small and disparate samples. Attempts at fixing bugs can be summed up as "a shot in the dark".

All in all, I don't need to jump on the bandwagon of "ZOMG THIS IS NEW UPDATE NOW" unless it brings something valuable, even less if I don't have anything stable to fallback to. :)
[Nexus S Android Development] polobunny:
Sadly this last_kmsg is unusable, it's from recovery.

[ 0.000000] Initializing cgroup subsys cpu
[ 0.000000] Linux version 2.6.35.14-cyanogenmod-g1ad182f (kalimochoaz@KalimochoAz-HPUbuntu) (gcc version 4.4.3 (GCC) ) #1 PREEMPT Mon Dec 12 17:45:07 CET 2011
[Nexus S Android Development] caliban2:
When it crashed, last_kmsg wasn't written, thus you only got the one from recovery (perfectly normal).

Question is why. It did reboot by itself, right? Also, did it reboot to google-logo or bootanim?
[Nexus S Android Development] Ser Gilgoroth:
Reboot on 6.7.3, using NS Tools, went to look at overclocking, brought up the frequency menu and it locked up. On BB6, this is my first kmsg, hopefully I did it right.
[Nexus S Android Development] polobunny:
Yep that's perfect! (as far as a reboot can be, and that kmsg looks pretty terrible on it's own haha)
[Nexus S Android Development] caliban2:
A reboot to bootanim isn't a "real" reboot. Eg, you don't have to unlock your sim when that happens. It explains why no last_kmsg was written. Rest asured it's almost certainly a rom-failure, not kernel. And as nightlies are stable currently (yes, they are, spare me the "but"), the problem is on your phone.

I'm assuming you know how to do a proper full wipe, so that leaves a specific app or, more likely, your backups. I have no way of knowing what you backed up (I hope it's not even one sys-app, where you restore app+data, but data alone can cause troubles), but what you described almost certainly rules out something on sdcard (since the phone is permanently bogged down). But try backing up your stuff and format sdcard too when doing a full wipe. Still, your backup is most likely the cause.

Tl;dr:

Not a kernel-issue.

PS:

What's that?! "Flashed CM, restored my backups and flashed marmite"

You flash ROM, gapps, marmite. Then boot and restore backups with Titanium. Don't tell me you restore a nandroid-backup after flashing the ROM... Oo :)
[Nexus S Android Development] _yaz_:
blx seems not to work in 6.7.3 :confused:

[edit]

... and bln either

[rolling back to 6.7.0]