yashsingh1/xdaforums huggingface dataset:
[Nexus S Android Development] leap_ahead:
i get it from folder /proc
[Nexus S Android Development] :
Yeah, you got the right file.

With a battery pull, or sometimes with a severe reboot the kernel didn't have a chance to copy the kmsg log to the backup file "last_kmsg"

This means the file "last_kmsg" didn't get overwritten, so it contains the output of whatever kernel log was successfully written last. In your case the last kernel to successfully backup it's log was the recovery kernel, compiled by kalimochoaz
[Nexus S Android Development] :
I'm really glad you got that kmsg. Because I've been looking in more detail at a lot of graphics stuff recently, I was a bit more savvy to what might be connected. Anyway I knew the bug was introduced in 3.0.35. This is the first time I've seen a good description of the same bug in my own thread though...

Anyway: http://www.kernel.org/pub/linux/kernel/v3.0/ChangeLog-3.0.35

...shows the commits in this patch-set. I believe the first one is the only candidate, because it modifies mmap(), which is involved in graphics' DMA processes. When I looked deeper into the commit, the author does not specify that it is suitable for this kernel version, and also points out that it was not extensively tested! I however did extensively test this patch-set, comparing it to the previous patch-set, and I know that something in 3.0.35 introduced a problem.

I know this particular bug only surfaces once in a blue moon, so it'll be difficult to say it has been resolved until a significant period of time elapses. Regardless, when 3.0.44 officially arrives, I'll release v4.8 as the new stable. (I've been testing 3.0.44rc1 with no issues)
[Nexus S Android Development] lukappaseidue:
Hi Bedalus, Hi everyone,

I need Your help.

I'm using this amazing kernel with CODENAME 365 ROM on my Nexus S 9020T

I'm not able to set min freq to 100Mhz.

Is There a way to do it?

Thank You in advance
[Nexus S Android Development] capoooro:
For me works. Try to use nstools. Change before the max frequency... then the min... try two o three time... then go back to the max you desire.
[Nexus S Android Development] :
Avoid trying to change the frequency, and the minimum will be 100mHz. Download CPUspy it will confirm what frequencies are being used.
[Nexus S Android Development] linuxxp:
Yes! Full wipe resolve the problem with random reboots.
[Nexus S Android Development] polobunny:
Thanks for the look bedalus, and I told you last kmsg was useless in this instance. :p

I'll try to get a log whenever/if it happens again.
[Nexus S Android Development] towelboy:
Awesome.
[Nexus S Android Development] lukappaseidue:
thank you Bedalus, thank you capoooro

I've checked the frequency using CpuSpy.

The only freq not used are the 1200 and 100 Mhz.

As governor I'm using smartassV2 but ondemand too

and CFQ. nothing else.

what is wrong?
[Nexus S Android Development] miklosbard:
did you click the set on boot in nstools? if so, unclick it, reboot, only set what you need and do not touch the lowest frequency. recheck in cpuspy
[Nexus S Android Development] lukappaseidue:
I'm using the "PERFORMANCE SETTING" of the Codename ROM.

:( bedalus could You help me?

Edit

even with NStools..... I can't select 100 MHZ. :(
[Nexus S Android Development] CrackerTeg:
The performance governor will have your phone at the highest speed at all times. Select either ondemand or smartass so that it will cycle through all the frequencies properly. Also, you won't be able to select 100Mhz with nstools. It's a known bug.
[Nexus S Android Development] miklosbard:
That's why I told you not to touch it, cause it's bugged:) the default settings of the kernel includes the lowest frequency as 100 MHz, so if you reflash the kernel and just don't tinker with the frequency you are good to go
[Nexus S Android Development] :
Don't use any performance setting apps or menu options. Read jokerace's guide in the OP if you want to OC.
[Nexus S Android Development] CrackerTeg:
Truth. I use a variation of it but works beautifully.
[Nexus S Android Development] :
v4.8 has finally arrived: http://goo.gl/HvUrp

-Merged in mainline 3.0.44

-Completed removed deadline

-Found further debug stuff to remove

-Removed init.d mounts tweak. This will eliminate possible conflicts with ROM or user tweaks. It's not a particularly significant tweak anyway!

-Reverted one individual commit from 3.0.35 involving mmap() function which corrolates to a possible PVR driver bug

-This version has undergone abusive testing on my own device and has not crashed. No reports on the thread of any crashes related to the kernel, apart from the one described in the bullet point above, that only time will tell if it has been properly fixed. Since I'm feeling optimistic, this is the new stable!

That said, if you do experience problems, please consider using the debug version. Otherwise, enjoy! :D
[Nexus S Android Development] androidforeve:
On it will report back
[Nexus S Android Development] :
Cool. Actually I should probably update the 4G thread.
[Nexus S Android Development] CrackerTeg:
Downloading meow.
[Nexus S Android Development] :
Is that some sort of meme? I'm too old now for shenanigans.
[Nexus S Android Development] CrackerTeg:
Super troopers reference.

Just flashed it and smooth as I expected. Using same settings as before.
[Nexus S Android Development] polobunny:
Will flash and report if I get anything. I won't be touching the ROM, just in case. :)
[Nexus S Android Development] FirePoncho86:
Will Flash and report tomorrow! I've been at school for 12 hours only to use ****ty public transit and study some more. In this state, I'll most likely try to flash oxygen ROM..
[Nexus S Android Development] antrobi3:
Reeboot during call and infinite bootloop with Marmite 4.7.6CM on CM10 10.01 nightly !?

---------- Post added at 03:39 AM ---------- Previous post was at 03:32 AM ----------

On which roms have you made the tests ?
[Nexus S Android Development] vinamilk:
Mtp works fine. Speed much faster than usb storage mode which in bug on ICS/JB Roms now.
[Nexus S Android Development] caliban2:
38 hours running on CM 1001 with 4.7.6 and counting... :) Now I don't know if I should flash 4.7.8 right away or wait another 5 hours until I flash CM 1003. ^^

Edit:

I'll wait and give it 5 more hours to prove it's stability.
[Nexus S Android Development] granets:
I've always wanted to ask, bedalus, is this "UNUNDERSTANDABLE MESSAGE 3..." a normal thing, or is my phone not doing something right
[Nexus S Android Development] sgtkid12:
Its just something for fun that he puts in for fun. That's what I think
[Nexus S Android Development] :
Oh dear! Get some rest!
[Nexus S Android Development] :
This isn't intended as an advertisement, because i think the ROM you use has to match your needs, which are going to be different for every user. That said, I always use slim bean. Occasionally I test on other ROMs but that's happening less frequently now as I'm relying more on other user's feedback.
[Nexus S Android Development] :
Yep, MTP is awesome. Consider a donation to krarvind for making it work.
[Nexus S Android Development] :
Go directly to v4.8! (I suppose it might have been a typo.)

Anyway, thanks for the diligent testing!
[Nexus S Android Development] :
It's the same thing as a derstandable message.
[Nexus S Android Development] :
https://docs.google.com/spreadsheet/ccc?key=0AntDDKv-lS6IdERmeUtqX2ROYzR5Z19RM2xITnRscHc

The above links to a spreadsheet where I tried to work out if the voltage is correct for the 1200MHz step. The red number is adjusted from its current value of 1325 to 1300 mV. This seems to bring it into alignment with the gentle upward curve. I'm assuming it ought be an upward curve, because if it were ogive or logarithmic that would imply deteriorating power efficiency at high speeds, which I think is the opposite of what how chips behave (someone knowledgeable in these matters confirm?). It would also seem to imply a gradually increasing resistance to working faster (that sort of thing applies in wind tunnels, not silicon).

People with experience in OC'ing to 1200MHz are welcome to feedback if they had stable voltages, but I'm also interested in releasing a test version with reduced voltage at this step.

Please note, I do not endorse undervolting. What I'm trying to do here is find the nominal volts to ensure this step is as stable as possible for anyone who uses it. For anyone who is confused about how reducing the voltage might help improve stability, think about what might happen in your plumbing if the pressure was too high. Having more taps on at the same moment the pressure increases would certainly help prevent your pipes from exploding (i.e. more volts are fine at higher frequencies) but the pressure that forces the water along the pipes also acts in all directions, so equally the water pushes against the sides, and once the pressure is higher than the pipes can contain, they rupture. Now obviously this doesn't happen in a chip. What happens is more electrons start to dissipate as heat. This always happens to a certain extent, but when the chip gets too hot, it shuts itself off before it burns out. So the voltage needs to be low enough to prevent this and high enough to supply the extra power needed at the frequency.

Anyway anyway anyway... feedback welcome!
[Nexus S Android Development] caliban2:
Jup, of course that's been a typo. ^^

Made the switch after 43 hours stable.
[Nexus S Android Development] :
Excellent. Really appreciate the long testing. I actually rely on your tests, and other users who also provide useful feedback! There's a few users out there deliberately trying to break stuff, and it really helps zone in on bugs.

I'm gonna pat myself on the back too for learning some graphics code, because that might just have been the key to solving the pvr bug. But only time will tell on that front so I'll hold off on the self patting for now.

Keep posting your last_kmsges everyone, and if you think you've found a reproducible bug, consider using the debug kernel to get me a more detailed last_kmsg. Thanks!
[Nexus S Android Development] polobunny:
When you overclock, you kind of hit a figurative wall at some point in your steps where you'll need to push much more voltage than expected to get it stable. Usually one would stop overclocking before that wall as to preserve efficiency and not invest precious time/efforts or money for added cooling just trying to get it stable for sometimes only an addiotional 100MHz. This is also very valid in the grand scheme of things (desktop computers, not just phones).

With phone overclocking the biggest issue stays the heat generated. Unlike PCs you cannot add cooling (I guess you could, but probably nobody does :p) so you're pretty much battling against an OEM design meant to cool "just well enough" for the chip to be able to operate at stock speeds. You can be lucky and find out the cooling is very effective, or use another phone and find out there's little overclockability in a chip + the cooling is hardly sufficient.
[Nexus S Android Development] mishamosher:
I'm posting my experience with 1.2 GHz OC step.

I've been using it since marmite 3.3, so, I've tested it a lot of time and with a lot of ROMs.

Never had a trouble on my i9020A, just a little more of heat (that's of course normal).

If its useful, I use SmartAssV2 governor, oh, and also played hours and hours of 3D heavy games and its so rock stable!

Thanks for the awesome kernel!
[Nexus S Android Development] lukappaseidue:
HI bedalus,

first I want to say that the min freq setting has been solved.. unchecked everyting on "PERFORMANCE "SETTING of CODENAME 365 ROM and than update to your latest stable kernel.

But now there is a new bug, but I don't know if it is kernel related.

After updating kernel, I've seen that AUTOROTATE doens't function anymore.... but I don't know if it was OK before ROM UPDATING

(in fews words, it was ok until 360 Codename ROM and MARMITE 4.6)

What Do you think about?
[Nexus S Android Development] Articudos:
Did u try to fix permission?

For me, Auto rotate works great with rasbean+marmite v4.8.
[Nexus S Android Development] cyrus_e:
Thank you so much for the explanation! However as I've noticed with your kernel, voltage tweaks are not possible with NSTools. Does that mean that any changes that you might have made for 1200mhz OC is imbedded in the Kernel?

Also, with the new update, why was "Deadline" removed? I have been using it with SmartassV2 as together they gave me the smoothest experience. Would you recommend an alternative?

Thanks again for everything that you have done. A really wonderful kernel! :highfive:
[Nexus S Android Development] lukappaseidue:
Thank you for your reply

the bug has been soon solved reupdating the kernel without wipeing anything
[Nexus S Android Development] melvinchng:
It is very fast in 4.8... fastest ever... no reboot until now.. and the battery seems not too good...

Accidentally sent from my Google Nexus S
[Nexus S Android Development] miklosbard:
what exactly do you mean by that?
[Nexus S Android Development] melvinchng:
drain a little bit faster

Accidentally sent from my Google Nexus S
[Nexus S Android Development] CrackerTeg:
I wish I could give long term impressions on the kernel but I keep fiddling with files and rebooting to have them set in. Between those reboots though, 4.8 is damn smooth and fast at 1200MHz, SmartassV2 (stock settings) and CFQ. My experience at that clock speed was with ICS and using Matr1x. As that version of the kernel was extremely UV'ed, I'd get random reboots with phone calls lasting longer that 15 minutes. Dropping to 1000MHz took care of the reboots. I personally don't know all that much about how IC's work so I can't provide any insight on that. As for battery draining a bit faster on this current version, I don't see that TBH. I'd say I'm draining my battery faster than others just because I keep modding files and testing other things that really have nothing to do with the kernel. All for the funsies.
[Nexus S Android Development] polobunny:
Mid day idle review:

So far so good. Started at 8:15am with 99%, currently at 96% at 1:30pm. I've received 1 call that I refused but otherwise didn't touch my phone. I have 4% Android OS battery usage so all is good there.
[Nexus S Android Development] Shawtux:
Nice kernel. Fast as matrix!

I don't see any improvement compared to matrix though other than the fact that it has faster dev releases which is greatly appreciated.

Currently using cm10 nightly 1002 and battery life not so great but very similar to matrix.

I don't know how ppl can get 20+ hours. Any advice?

Edit:

Ah yes. Also using 4.8
[Nexus S Android Development] :
At 2 standard deviations, deadline is better, but at three standard decisions, cfq wins. I've done seriously detailed tests of this, twice! Also, i sometimes got temporary lockups with deadline. Continue with smartassv2 if you prefer it, there's no conflict with cfq.
[Nexus S Android Development] :
I think if you

1) Disable usb debugging

2) Enable MTP

3) Connect to computer, copy files, etc

4) Disconnect from computer

5) Disable switching app

6) Enable usb debugging

...that works right? This is pure speculation...
[Nexus S Android Development] :
Patch applied successfully!

Now I'm working on that annoying 200 MHz thing. Once again I think it's been caused by a failure to understand the code... but fingers crossed, the build compiling now will sort it... :o

EDIT: Booted... looking good *holds breath* Damn, still not working. Back to the drawing board.

Actually, that 'retaining authorship' I think is probably quite important. I know it's open source and everything, but I think there's some code I've just copied with a text editor. Is that bad form?
[Nexus S Android Development] :
Yes, but you have to reboot after changing between MTP and UMS, which isn't ideal.
[Nexus S Android Development] Blackcrx:
So with that said. Would it work if I disabled deep idle and used the music player, once finished close music player and re enable deep idle?
[Nexus S Android Development] :
Yeah, you shouldn't copy and paste code if you can git cherry-pick it or git am it, as a cherry-pick (done correctly) will maintain authorship. Of course, if you can't cherry-pick or am it, you should put a note of the original author in the commit, but most people don't bother to do that either.

It has always irritated me when people either remove git history or change the authorship because it looks like they are trying to take credit for your work and in some cases that is the intention.
[Nexus S Android Development] :
NO!

Sorry. I wasn't clear. Use DI as you normally would. But if you open antutu, you'll need to disable DI until you can reboot your phone.
[Nexus S Android Development] pan1980:
i cannot install the USB mode switch app from market, trying with cybergr rom and toyr latest kernel, its says its not compatible with nexus s....

any chance someone give me the apk ?
[Nexus S Android Development] :
I'll see if I can get hold of the developer...

EDIT:

While googling, found this. Run in terminal:

setprop persist.sys.usb.config mass_storage,adb" <- enables mass storage.
setprop persist.sys.usb.config mtp,adb" <- enables mtp

...anyone wanna check that to see if it works? Reboots may be needed after applying before the new mode becomes active... but check it before you reboot just in case.
[Nexus S Android Development] doc_v15:
Wow!! And MIUI ROM??? which rom?

Mine with MIUI never lasted more than 7 hrs
[Nexus S Android Development] :
Here we have v1.3: http://d-h.st/eJt (TESTING/EXPERIMENTAL)

Changes:

-thalamus' mutex to spinlock patch has been integrated. I've tested this, as I'm sure thalamus has, and DI of course still works fine, but because this is the first time anyone has touched the DI code in a few months, I think it's safer to call this a TEST release.

-I fixed the minimum fq getting stuck 200MHz issue, which was an issue actually caused by myself: when I was altering the available OC I failed to adjust all the levels correctly. :o

If anyone finds their minimum still sticking at 200 MHz try using an init.d script instead of NSTools, and don't include the line

echo 100000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq

Let me say that again. DON'T include ^^^ that line!

You copy your saved NSTools setting from

/data/data/mobi.cyann.nstools/settings

...and paste them into a new init.d script, or at the end of an existing one. And if it's working well, back it up.

Note - you can still use NSTools, but uncheck SETTING>Set on boot
[Nexus S Android Development] Articudos:
No, rascream 0625 with dark elegant theme :)
[Nexus S Android Development] :
We're sticking with 800 MHz for now... but in the future 400 MHz would be better:

Drain dBm	...in mW	...in mA @3.7V
Frq 800	mV 1500	8.2	6.61	1.79
mV 1200	6.8	4.79	1.29
mV 1150	6.6	4.57	1.24
mV 1125	6.4	4.37	1.18
Frq 400	mV 1500	7.8	6.03	1.63
mV 1050	6.2	4.17	1.13
mV 950	6.2	4.17	1.13
Frq 200	mV 1500	8	6.31	1.71
mV 950	6.4	4.37	1.18
mV 850	6.4	4.37	1.18

From my research here.

As you can see, it's 400 MHz that saves the most power. Incidentally it's worth reminding everyone that, as you can see, undervolting saves almost nothing.

It's also worth restating that my old analogue equipment wasn't capable of entirely accurate measures, so whether or not those final mA readings are even in the ball-park of reality is certainly debatable. However, we can be sure that less is definitely less, so the value I'm looking at is 1050mv at 400 MHz, being the lowest drain with music playing.

I'll work on getting that 400 fix, and keep you all posted.
[Nexus S Android Development] caliban2:
This min-freq issue is getting a bit strange...

Bedalus, I'm still using the settings I sent you some days ago (100) and a script instead of nstools. (Didn't remove the min-freq line from it yet)

Did some testing today and can't make anything from the results:

- With 1.2, cpuspy showed 100-step being used, but nstools, antutu and cm9's performance-settings always showed min-freq at 200. (Like in the screenshot I posted earlier, the 100-step showed up in "current freq" of cm9 though)

- With 1.3, it's a bit different. Cpuspy shows 100 used, nstools and cm9 show 200 min. If I now start antutu, under info it will first show 200, but if I wait a few seconds it changes to 100. Now nstools and cm9 also show 100. A minute later it's back to 200 with them.

Almost getting the impression it's a cosmetic bug, some apps just reading the wrong value. Because according to cpuspy it scales down to 100.
[Nexus S Android Development] :
Yes: close then reopen nstools, there's a good chance that it now shows the right value.
[Nexus S Android Development] :
Already done: v1.4 LINK PULLED EXPERIMENTAL

-Fixed screen off frequency to 400MHz when using Deep Idle for maximum power efficiency (see read this post.)

Please feed back on whether you see extra DI savings, especially if you are coming from another kernel and if you previously used Ezekeel's Lazy governor with SOMF set to ON. You should still see some gain. *famous last words* :p

Edit: :( bad bad bad
[Nexus S Android Development] mixtapes08:
dude your smokin fast....:silly:
[Nexus S Android Development] apatal:
May I know the reason for recommending this setting in such emphatic manner? ;)

EDIT: Oh yeah, I'm asking because I always include this in my script. Thanks!
[Nexus S Android Development] :
Good point. Maybe it's fine!
[Nexus S Android Development] apatal:
Well, actually, _thalamus did mention that these values are default for his kernel so it might really not be necessary to include it in the init.d script.

Anyway, I'm testing if NStools have really been causing the 200MHz min cpu freq issue. I'll be monitoring my phone using cpu spy.

P.S. I'm using latest thalamus kernel on JB port, nut I'm posting here since you seem to be tackling these issues with cpu frequencies. ;)
[Nexus S Android Development] pan1980:
bedalus success

setprop persist.sys.usb.config mtp,adb enables mtp on cybergr so i suppose it enables it at any rom

and setprop persist.sys.usb.config mass_storage,adb restores the standard mass storage function

command must be given through adb shell or at terminal as su.

restart needed either way.
[Nexus S Android Development] :
You've hit on a few issues there. I'll try and address them all.

No, there's no performance difference to any other kernel. I spent a long time benchmarking various kernels, and when set at the same clock speed they perform the same. I'm trying to strike a balance between useful features and self restraint. For instance, I know cfq is the best io scheduler, so the others are removed.

I don't know about "fast" releases. It feels like it's been a long while since 4.7. I'm lucky people are so happy to use the test versions, it makes development quicker. I've been using a policy of quite frequent but quite minor updates, so if something should go haywire, it'll be easy to track down.

Maybe your battery is aging. Could be cm nightly has brought in some issues. :p Hard to say. Google now might be eating your reserves up. I have a thread on battery saving if you follow the link in my signature.
[Nexus S Android Development] Shawtux:
hahaha thanks for all the answers!

i was just complimenting you on the fast releases and the high speed!

ive been followign your benchmarks for a while now. i believe i have been doing the recommended stuff. maybe its aging :(

thanks for your quick reply! :D
[Nexus S Android Development] dekaru01:
Tried to install 4.8. Got stuck on Google logo afterwards. Three times, then I gave up. Latest Rasbean. I've been running 4.7.4 and 4.7.6 on the same ROM without issues.