yashsingh1/xdaforums huggingface dataset:
[Nexus S General] modifii:
Flashed new test release today morning, I can see phone is spending more time on 800mhz than Deep Sleep. Is this IDLE2 at work? If so, will this result in more battery drain?
[Nexus S General] :
Huh? Not here it isn't. https://plus.google.com/117940318375607427941/posts/YDFuFm6foMZ
[Nexus S General] modifii:
I haven't used phone much, but yeah its in charging via USB port since around last 2 hours. See my Nexus S' stats.
[Nexus S General] :
It won't sleep whilst it is charging.

It's not *actually* at 800MHz for that time either, because assuming the system is idle the CPU and L2 cache will be power gated for at least 95% of that time (conservative estimate, it's probably about 99%), so the frequency is actually 0 because the power is off and the time *actually* at 800MHz is less than 8 minutes.

I could _possibly_ export the time spent powergated into cpufreq stats so it would show on CPU spy. But I've got a couple of other things I want to do first.
[Nexus S General] albundy2010:
The phone does not enter deep sleep while being charged.

Deep sleep and idle2 are not the same thing. Deep sleep is when the phone is um sleep. No wake locks, not doing anything. Idle2 is a lower power state that is used when the phone is awake. Example. Playing music.

The 800mhz is there because it is set to come out of the idle2 state and go directly to 800mhz and back into idle2 as quickly as possible and avoid any unnecessary frequency scaling in between.
[Nexus S General] granets:
Just had a freeze and then a reboot. Here is the kmsg
[Nexus S General] :
Correct. Although, some devices can actually enter deep sleep whilst being charged.

Or more significantly, when a wakelock is being held which keeps the phone awake IDLE2 saves as much power as suspend in that situation.

Technically though, the differences between DEEP-IDLE and SLEEP aren't massive. They both involve power collapsing, although SLEEP power collapses the vast majority of the SoC, wheras DEEP-IDLE power collapses the A8 core, caches & FPUs, and sticks the TOP and SUB blocks in standby mode.

The difference is that application processing doesn't stop when DEEP-IDLE is entered, no tasks are frozen and the CPU is woken up on the next scheduler tick. It is also a hell of a lot faster to resume from. Sleep takes many milliseconds, DEEP-IDLE takes about 500 microseconds.

I'm actually trying to figure out a way of waking up from an alarm timer when the screen is off, instead of the scheduler tick. This would mean I could spend much longer in the idle states. Thats a goal for v0.400. I suspect if that could be implemented, it would be as efficient as suspend, because it's very close now.

The last thing you want to be doing whilst idling is more work. CPU frequency scaling involves work, and with the interactive governor, it isn't cheap, so you end up chugging away using cpu cycles and causing more scheduler ticks when you really want to be idling.

---------- Post added at 12:38 PM ---------- Previous post was at 12:35 PM ----------

Hmmm, that would be a typical XDA standard bug report then. No useful information what so ever.

What were you doing at the time of the reboot? Did anything in particular cause it? What ROM are you running? Were you playing music at the time or not? Which kernel are you using? Why am I having to ask these questions?

It also helps if you attach the last_kmsg...

Edit: last_kmsg is useless, it's from recovery..........................................
[Nexus S General] granets:
I was just about to open the browser to check for a new ROM. The phone froze, tried anything I could. Then the phone locked itself, tried to unlock (capacitive buttons lit up), then the next thing I saw was the pink unicorn. I am using the latest AOKP Nightly (29.08.2012) for a couple of days now, no issues. This is the first problem I've had and I just switched to your kernel last night, after jumping around bedalus' stuff and some of yours too ealrier (the JellyBelly days). If there's anything else I can help with let me know. I really like your kernels they are the best, but so many times I've found them unstable so I stopped using them for a while
[Nexus S General] :
The pink unicorn? So you had a soft reboot then...NOT a kernel issue, it'll be an app or the ROM and as you are using AOKP, that isn't a surprise tbh.

Are you for real or have I just been trolled? Alas, I don't test on CM derivatives because I refuse to install them on my device and I don't want to support them so they may well cause issues. I can tell you it is *perfectly* stable on stock though.

---------- Post added at 01:20 PM ---------- Previous post was at 01:07 PM ----------

For info, anyone using CM nightlies / AOKP or derivatives please note that my kernel is unsupported on those ROMs.

This means that if it works, fine, but if not you are on your own unless you can reproduce it with stable CM or the stock ROM.

Stable versions of CM I will support within reason, but I can't fix issues which are inherently embedded due to the deviation from AOSP.

I flatly refuse to have my kernel called unstable because of some buggy POS nightly ROM when I know it isn't the fault of the kernel.

But as there isn't a stable version of CM for JB yet, that is moot. So until there is, CM is completely unsupported too.
[Nexus S General] granets:
could be so. could you suggest a good rom? for instance what are you using? i want something stable and smooth with a moderate amount of extras (thats why I like AOKP-just the right amount of stuff)
[Nexus S General] Imppy:
Examples of ROMs you support include knzo aosp rom...stock ota ROM...and rasjelly?
[Nexus S General] :
Stock.

---------- Post added at 01:50 PM ---------- Previous post was at 01:48 PM ----------

I don't support any 3rd party ROMs as such, because I don't use them. But I'm well aware of the difference between a ROM issue and a kernel issue.
[Nexus S General] granets:
Thank you _thalamus, for wasting your time, answering my stupid questions. I will try a stock OTA ROM for a while, because, tbh, that's the only thing I haven't tried so far. Just one last thing - do you concider this ROM stock? : http://xdaforums.com/showthread.php?t=1854366 . if not, would you be so kind as to point me to one? Thanks again. :)
[Nexus S General] :
Stock is the one Google releases. Simple.
[Nexus S General] fear_factory84:
removed
[Nexus S General] mikegleave13:
What if we are on the NS4G? No stock jb ROM that I'm aware of.
[Nexus S General] :
Your mileage may vary.

It is what it is. I can only provide dedicated support for what I use and anything else is best guess. I don't have a 4G so how can I support it properly? I can't.
[Nexus S General] polobunny:
The NS4G got the incremental update from ICS 4.0.4. Just didn't get the full ROM. Doesn't mean you can't have stock JB ROM on crespo4g...
[Nexus S General] noizy1234:
http://xdaforums.com/showthread.php?t=1811491

This is basically the stock jelly bean ROM for NS4G.. I've been running thalamus' kernel for a while now on my NS4G with no problems as a matter of fact this is the smoothest kernel for me..
[Nexus S General] albundy2010:
No it did not. There is no jb ota for the 4g
[Nexus S General] polobunny:
I stand corrected. I was under the impression the OTA update came out but apparently not so. Nevertheless, nothing stops you from running a pete near stock AOSP built ROM. Only difference being that it's rooted.
[Nexus S General] :
Blah blah blah, ROMs blah blah blah.

This is a kernel thread. Let's get back on topic.

Basically, stock is fully supported, everything else is a case of your mileage may vary so don't blame me if you get breakage. Simple enough?
[Nexus S General] mikegleave13:
So should we have started a new thread to see what roms were working with your kernel?
[Nexus S General] :
Yes. Preferably somewhere where I don't have to look at it.
[Nexus S General] :
New test release here.

Short changelog:

Functionality to print time spent in suspend into dmesg

IDLE2 v0.383 - Fixes a couple of bugs and cleans up some of the code. Nothing major, functionality is identical.

Add external kill function, see v0.383 commit message. Currently used to workaround modem bug and for suspend, can easily be used elsewhere if you find other problems in other devices. It can be called in oneshot mode or in an explicit mode. It is used in oneshot mode in modem_ctl.c and in explicit mode in wakelock.c.

Use system workqueue instead of dedicated workqueue. We don't have enough work to warrant the memory and cost of using a separate workqueue.

Work around modem bug which causes it to fail to recover if it crashes whilst idle2 is enabled. It appears that the modem doesn't / isn't able to fire an interrupt once it crashes, so the driver doesn't fire an interrupt to wake the A8 up from DEEP-IDLE, so it all goes horribly wrong. The modem_ctl driver is full of nasty hacks anyway, the fact it works is more luck than anything else.

Remove PM notifiers due to calling idle2_kill() from wakelock.c.

Minor tidying in other functions.

Removal of unrequired #includes (let me know if you get issues on other devices and I will add what you need back).

Built from the tip of this branch.

Known issues:

WiFi still requires to be toggled off then on or on then off to get the most out of IDLE2. Not my bug, it's a bcmdhd bug.
[Nexus S General] yabdali:
steps to flash the latest test kernel?

Hi,

I am running JB 4.1.1 stock with Air Kernel. I am trying to flash the latest test release of your kernel, as per my understanding wipe cache, wipe dalvik, flash kernel, fix permission then reboot. Am I right?
[Nexus S General] rasengan82:
Just flash kernel. No need to wipe anything.
[Nexus S General] caliban2:
Oh wow, this is like watching an accident to happen. You're in for a little bit of _thalamus' finest... :D

Seriously, don't ask questions like that in a dev-thread. Yes, you can do all that. Wiping and fixing permissions isn't necessary, but it won't do any harm either. Result is a longer first boot.
[Nexus S General] apatal:
OP updated! ;)
[Nexus S General] :
Hahahaha. Dear oh dear. The dalvik / cache wiping and fixing permissions morons have landed.

Just because some moronic pseudo developers suggest that, it doesn't mean that it is necessary. In fact, by suggesting it, they prove just how little they know about Android....
[Nexus S General] knzo:
Flashing a different ROM: wipe data and cache.

Flashing same ROM, different version: wipe dalvik-cache.

Flashing a kernel: nothing.

This is the best compromise between avoiding conflicts and saving your time. The dalvik wipe for the second scenario is also susceptible to debate but there's no harm done in rebuilding the applications' dependencies tree.
[Nexus S General] :
I agree.

Second one is useful because it'll probably take slightly less time to boot as it won't have to load and check the dex files then realise they are mismatched then delete them and regenerate them. It's not a must because it'll deal with them anyway but it's useful.
[Nexus S General] korpo53:
With today's test kernel (kernel-v3.0.31-1728-gc5a9845-JB-20120905-124848.zip), on the stock-ish ROM (http://xdaforums.com/showthread.php?t=1784497), streaming over BT stops the moment the screen turns off (on my phone at least). This is listening to podcasts, and the phone is on power at the time. The podcast app (BeyondPod) continues to count the time as if it's playing when I wake the phone back up, but no amount of fiddling gets BT audio working again until I disable/enable BT.

Yesterday's test kernel did something similar, but I didn't test it as much. It went flaky while I was on a call and I just took it off the BT and held the phone to my head until I got home.

I went back to the stable kernel (kernel-S5PC110-3.0.39-27JB_rel.zip) and the problem went away. I'd been using the stable kernel for a month or so without issue.

Now, it seems like it'd be related to IDLE2 being added in the test kernels, and the phone kicking into IDLE2 when the screen turns off with music/podcasts playing. But I was under the impression that that phone wouldn't go to IDLE2 when it was on power or actively using BT. No? Even if it is supposed to go idle, I'd think BT should continue to work.

I'm not sure what logs would be helpful, but I can upload whatever you need.
[Nexus S General] Muvolt:
In the beginning, I liked your "pure" philosophy with stock ROMs and "clean" kernels...but...I'm starting to realize that you don't respect the other developers or even your own knowledge level, by constantly being arrogant and offensive.

It doesn't matter if the developer you are attacking knows what he is doing or not. He builds one of the fastest / smoothest ICS/JB kernels and I never had a problem, even with his test releases. He is also much more polite than you and this is much more important than his actual code.

How about trying to respect yourself first, by leaving comments like these for a person who is worse than you are?

P.S. I'm sorry for the off topic...
[Nexus S General] albundy2010:
Not again please stay on topic please!

The latest test kernel is lagging a lot for me. The fps are way down.

Test 64 kernel runs smooth on the same ROM. Tested another kernel today with the new idle2 code and had the same result.

Edit. Back on stock images and no more issues on the latest

Edit 2. Back to stock ROM with just antutu and root explorer installed.

Test 2d and 3d. That is fine. Then I got the phone to sleep. Awake it and run it again. And get that with massive amounts of lag.
[Nexus S General] :
@albundy2010 With antutu I've got 3226 points (CPU: 795, RAM: 360, GPU: 1427, I/O: 644)

I'm on CM10 latest build with your latest experimental kernel. I've very low I/O score...
[Nexus S General] coluichepensa:
Hi,

I tested few days the kernel with IDLE2 and it's good in term of stability but I noticed it drains more battery than this version of kernel-S5PC110-3.0.31-28JB_test-64-geb088d1-JB-20120903-185549. Checking with cpuspy I saw the cpu usage is for the most time in deep sleep, and a lot of time in 1000mhz, very little time in 800mhz and almost nothing for the remaining frequencies. Different story with 28jb where i saw a big use of deep sleep, more usage of other frequencies like 100mhz 200 and 400mhz and few usage of 800 and 1000mhz. More or less I utilized the phone in the same way. Probably is just a my impression but want to return back to version 28 just to better verify it.
[Nexus S General] :
No you aren't, otherwise you wouldn't have posted your opinion.

Tell you what, I've been looking for an excuse to leave this thread for a while, because to be honest, I've got better things to be doing.

You just gave me it. My statement about moronic pseudo developers was accurate. It's just a pity some users are so stupid they fall for all the bull**** which goes with their 'developing' aka cherry-picking and feature wanking. I do respect my own knowledge level, I have done Android development in the past, I know how Android works, and I also know how it *doesn't* work. Feel free to use Air Kernel from now on, I won't be releasing any more Nexus S kernels on here.

I also find it ironic that you assume that I'm attacking a particular developer. I wasn't actually, I was attacking any kernel developer who says that wiping anything is necessary.

Anyway, I'm out of here, congrats, you got what you wanted.

Edit: If anyone wants to come to my IRC channel, it's in my sig, as is my blog. There is also the IDLE2 thread for IDLE2 issues only.

korpo53: Bluetooth issue I'm looking into.

coluichepensa: Drain issue is still being looked into, unsure what is causing it currently.

albundy2010 and MattScherbatsky: Performance issue doesn't appear to be an issue here but I'll look into it anyway. Antutu does some funny things, so it probably isn't be best benchmark to use.
[Nexus S General] karx23:
It's a little better than stock, but performance and smoothness is way better with _thalamus kernel.

If you want a solid battery friendly rom with it, go for Bugless Beast latest nightly.

A very good combo. You 'll definitely see some improvement in battery life.
[Nexus S General] heX79:
Thank you _thalamus, for all your great work with this latest release! Also thanks to apatal for bringing this great kernel to XDA!

It runs extremely smooth for 1ghz! Coming from Trinity T132, I am a bit surprised at just how smooth it crunches ICS at stock cpu speed!

So far, very stable, fast and smooth. A keeper IMO!
[Nexus S General] irminsul:
After nearly 300 hours of uptime on the 3.0.34 version, I've flashed the latest kernel together with the new rascream build. And o yeah its really smooth!

Verstuurd van mijn Nexus S met Tapatalk
[Nexus S General] apatal:
Glad to hear you guys are enjoying the kernel. As you can see a couple of pages back, _thalamus drops by the thread every now and then and I'm sure he'll appreciate all the positive comments his work is receiving here. So keep it coming! :)

As for me, I am simply a messenger. Still, please don't forget to press the thank button when you can. Cheers! :D

Sent from my Crespo
[Nexus S General] wmdunn:
Apatal ... thanks for keeping the thread for us ... really appreciate it. If you ever get a chance to chat with "the man" himself, please relay how important voodoo color drivers are to some of his faithful followers.
[Nexus S General] :
Yeah, thanks for the positive comments.

I've been driving myself round the twist today building 20-30 different kernels with various toolchains to see which one performs the best.

I tested (with my tweaks and config): stock 3.0.8, stock 3.0.8 + android common 3.0.31, stock 3.0.8 merged up to 3.0.36 (my previous base) and stock 3.0.8 + android common 3.0.31 merged up to 3.0.36 (my current base). I've tested various toolchains, GCC 4.6.3 + newlib, Linaro 2012.06, arm-linux-gnueabi which is available in the Ubuntu repos, GCC 4.6.3 compiled with crosstool-ng, Linaro 2012.06 compiled with crosstool-ng.

After many runs of 0xBench (Linaros benchmarking tool), I conclude that each kernel version all performs almost identically as regards 3d/2d graphics when compiled with my usual toolchain, which means none can possibly have any more lag than any other, otherwise it would show as a reduced FPS on 3D scores in particular.

It seems that some toolchains do cause issues though, for example, stock 3.0.8 will not boot when compiled with Linaro GCC. Whatever causes that is seemingly fixed in later stable revisions.

This is statistically insignificant, but stock 3.0.8 *appears* to be slightly faster than the others, but I still have more runs to do with a couple of other toolchains, so I can't be entirely sure yet and the difference is so small it falls within the margin of error.

I will post again once I have figured out which is the best performing kernel, but at the moment all the results are the same allowing for noise.

---------- Post added at 11:12 PM ---------- Previous post was at 10:25 PM ----------

Maybe so, but sorry, I'm not adding it. If you need it that much you will have to use another kernel, or download my source, add it yourself and recompile.

Also, the more (unnecessary) garbage I add, the more my kernel becomes a clone of the many slow, buggy kernels on XDA which need 1.4GHz overclock just to run the additional kernel code they have added...

I don't want that, and I'm sure the majority of the users would prefer the kernel to stay as it is, lean and stable because none of the others are.

I don't understand why some users want my kernel project to become a clone of all the other kernels?

I added voodoo sound as a compromise, because I was pestered to death for it and because when I tested it I was actually impressed by the improvement it makes to the sound. If it hadn't made a difference I would not have added it.

Voodoo colour I have no such feelings over, I don't see the point and I don't feel it adds any value to my kernel. The panel is pretty much calibrated correctly and the temperature is correct compared with similar devices with similar panels, it doesn't need adjustment.

If I added voodoo colour, it would next be BLN which is important to somebody else, and if I add that it will be something else, and so on, until it just becomes a crappy clone with the same 'features' as all the others.

So apologies, but the final decision is that I'm not adding it, period.
[Nexus S General] heX79:
I can also confirm that todays release of Rascream + the latest thalamus is a perfect pair.

Time to remove "testing" from the signature, I found my new kernel to follow.

Great work! Still a bit shocked at how small the kernel is, but I suppose that's the positive side effect of a lean kernel, as opposed to a bloated one!
[Nexus S General] chronophase1:
Yeah. The sound add on was a great addition. It's been my go to choice now because it's the only kernel to provide consistent performance and stability, which at the end of the day is what I'm sure we all want :). Keep up the good work.

Sent by pocket technology
[Nexus S General] wmdunn:
" So apologies, but the final decision is that I'm not adding it, period."

Thanks anyway ...
[Nexus S General] :
My performance tests are finally concluded. The fastest kernel appears to be my current base compiled with a FSF GCC 4.6.3 bare metal toolchain which I built using crosstool-ng. (I'll post the crosstool-ng config when I do my next release for anyone who wants to replicate my setup.)

Statistically, they were all very close and probably within the result noise, but that combination edged ahead on more than one occasion.

Surprisingly enough, compiling with a Linaro GCC bare metal toolchain actually produces a slower kernel. I didn't expect that result!

Also, compiling with additional CFLAGS which which target Cortex-A8 and NEON produces a slightly slower kernel.

I wasted a lot of time today and almost melted my NAND to discover that additional CFLAG compiler optimisations are pointless, toolchains which claim to be better aren't, and that my current base is the highest performing. But still, it's good to test.

I think it might be time for a stable release tomorrow.

Night all. :)
[Nexus S General] jjhrrsn:
Keep up the great work and thanks.!
[Nexus S General] apatal:
+1. Looking forward to the next stable release! :fingers-crossed:
[Nexus S General] ironia.:
thanks, i think for the moment i will remain on stock ics + thalamus kernel
[Nexus S General] ironia.:
yeah release kernel is here!
[Nexus S General] apatal:
Something's wrong with your link, good sir.

Anyway, he's correct, looks like a new stable build was uploaded by thalamus. You can download it HERE

I'll update the OP as soon as the main man updates his blog. Enjoy! :)

Sent from my Nexus S
[Nexus S General] ironia.:
correct thank you
[Nexus S General] ironia.:
hi thalamus, tnx for your great release,

you suggest to do a dalvik wipe before flash???

tnx
[Nexus S General] :
No, I most certainly do not and kernel 'developers' that do recommend it should be lined up and tortured, as it does nothing useful and just makes the next boot take *even* longer than usual (which is long enough already lol).

Please read this.
[Nexus S General] apatal:
Wow! This is quite different than what I've been hearing about here in the forums. Which is weird because something so blatantly misconceived such as this should have warranted the ire of most recognized developers here.

So just to clarify, you are advising just a straight flash of any kernel to any ROM, correct? No matter if the new kernel is not an update of the previous one but a totally different one? Also, when do you recommend a wipe then, and which parts specifically (you mentioned user data and cache in the link above to the Oxygen forum but I want to make sure I understand it correctly).

Again, thank you for taking the time to explain these things to us since apparently, we've all been misinformed about a lot of things regarding custom kernels.

Sent from my Nexus S
[Nexus S General] coluichepensa:
thanks for your efforts thalamus,

I'm not an expert, what I can say it seems the phone goes directly to maximum frequency after the wake up instead of scaling on the right frequency based on the apps you are using
[Nexus S General] madd0g:
Yeah, read about interactive governor.