yashsingh1/xdaforums huggingface dataset:
[Nexus S Android Development] caliban2:
Doubt it. And I don't think it's a rom bug either, never experienced something like this with any version of cm and marmite.

v6.7.4 worked fine on nightly 1108, as does v6.7.5 on nightly 1111. :)
[Nexus S Android Development] deani77:
That would be bad news for me... My Nexus S would come to it end soon.
[Nexus S Android Development] :
Thanks. I should have realised there would be no last_kmsg if you did a battery pull, but thanks for reporting fully. Unfortunately your reboot can be attributed to OC. Try playing with your voltages.
[Nexus S Android Development] :
v6.7.6 is here: http://goo.gl/rqjUX

-BLN is now either on or off. No blinking

-This should prevent any conflict with BLD

-Lights on uses about 1mA, which is very little, not a battery drain concern.

EDIT: I checked BLX on my device, and it stops charging at 90% like I wanted. I think there may be an exception to this which is when you boot the phone and it is already connected to a USB cable or the charger, it carries on charging.
[Nexus S Android Development] polobunny:
I might have to upgrade with pm_fast fixed. BLN stopped giving me trouble with the test version strangely enough. :)

P.S. 134 hours oooo
[Nexus S Android Development] _yaz_:
thx ! i'm testing now ...

i never boot the phone when charging as it makes battery go crazy. blx issue must come from sw else. again, it's not a problem with 6.7.0
[Nexus S Android Development] Basche:
I too was getting the same problem of removing the battery and putting it back to power on the phone. I reverted back to 6.7 and it seem fine will now try the newer version and see it it persists

EDIT: need to update to 6.7.7 lol such quick updates

You have just been beamed
[Nexus S Android Development] caliban2:
Shame though, I still didn't get SoD with it.

Btw, didn't this start after you added the performance-gov for didle...?
[Nexus S Android Development] :
Please can you post your settings?

polo, see if y3mita has good settings for you. I might compromise and split the difference between the old and new multipliers.
[Nexus S Android Development] polobunny:
Will do and will report. Maybe with some samples I can figure out a way to convert the values too.

I have to test it more anyway, lots of stuff going on lately giving me very little time doing actual testing. Who would have thought testing was one of my pastime. :p

Good thing my condo is nearly sold, now to move somewhere else and bingo, i'll have some free time!
[Nexus S Android Development] :
I had a SOD with the min/max method too. It's a weird thing that it's so temperamental. Also, when I started messing with kalim's code, he'd annotated it:

Except the weird thing was, his code didn't raise the minimum, it only brought the maximum down to 800 MHz. Kinda the opposite of what his note was saying. This remains a mystery to me... I can't tell whether he intended for DI to use 800 MHz and up, or 800 MHz and down.

Just had an idea on the fly:

Drain dBm	...in mW	...in mA @3.7V
Frq 800	mV 1200	6.8	4.79	1.29
Frq 400	mV 1050	6.2	4.17	1.13
Frq 200	mV 950	6.4	4.37	1.18

...looks like 200 MHz is the next best step... Hmm... it could be worth a go? It feels a little counter-intuitive, because if 800 works, 400 doesn't... then surely 200 wouldn't? I'm gonna build it and see what happens... :D
[Nexus S Android Development] :
...well, that couldn't have gone much worse! At DI fixed at 200, the very first screen-off event caused a SOD. So, it looks like kalim intended to do what he said he intended to do, but didn't actually do it... So, that settles that... 800 MHz it is. I'm going to build one without that other dodgy bit of kalim's code and performance governor DI at 800 and release it as stable. Unless anyone on the general testing release had an issue today?
[Nexus S Android Development] polobunny:
To the risk of sounding weird, I gotta say I love just reading through these kind of posts and seing the developement go forward. All of this is very educating on the inner working of many things kernel related. :)
[Nexus S Android Development] :
I'm sorry, you said 'development' lol? I see a big mess personally.
[Nexus S Android Development] :
Do you have to do this to me publicly? This makes me upset. I've been very open about my ****-ups. I feel like I've learned a lot from trial and error: the things I've broken, I've been able to mend, and in doing so I'm learning new bits and pieces all the time. Are there some specific bits of code you're referring to?
[Nexus S Android Development] :
Just about every commit here: https://github.com/bedalus/bedalusKERNEL/commits/performance_DI except for my fix, which *does* actually fix something.

I've never seen such obscure f*ckage in my entire life, and the fact it's been released to users is scary!

How you managed to break everything so much that pick_next_task_rt() started bugging, I will never know.

Perhaps you should stick to benchmarking kernels instead, no offence intended, but someone has to be realistic here, don't they? :confused:
[Nexus S Android Development] :
I didn't break it, if you look at that last_kmsg it's bugging in the piece of code that kalim wrote. I'd already taken that code out once as it seemed redundant. Since I was having SODs at 400 MHz I brought it back because I was second guessing myself. In the next release that code is gone again.

Are there any specific bits of code that are wrong?
[Nexus S Android Development] polobunny:
Some of man's greatest discoveries have been made entirely by accident. Serendipity, etc etc *shrugs*

Nothing wrong with trial and error, and nothing actually wrong to releasing it publicly. People would flash just about anything named .zip if they could, so it's not really to the dev to constantly warn people they could **** **** up. If someone doesn't understand the risks of some things, then they probably shouldn't be doing it.

Nevertheless, although being a fan of your work, I'm also a fan of many other mods and hacks (as unclean as they are) which you are not going to include, and ready to face the risk of absolutely obliterating my phone in a billion pieces. Bedalus offers us these, without any warranty, and that suits me just fine. Can't have it all, I guess. There's always some tradeoffs to be made.
[Nexus S Android Development] :
This kmsg? http://xdaforums.com/showpost.php?p=28958901&postcount=485

That is bugging in pick_next_task_rt() as I said earlier. I do *know* how to read a stacktrace.

Look at the error firstly:

kernel BUG at kernel/sched_rt.c:1113!

Look at the backtrace:

Backtrace:
[<c003c0b8>] (__bug+0x0/0x30) from [<c0058138>] (pick_next_task_rt+0xf8/0x108)
[<c0058040>] (pick_next_task_rt+0x0/0x108) from [<c055eb90>] (__schedule+0x340/0x404)
[<c055e850>] (__schedule+0x0/0x404) from [<c055f174>] (schedule+0x50/0x68)
[<c055f124>] (schedule+0x0/0x68) from [<c0560038>] (do_nanosleep+0xa0/0xd8)
[<c055ff98>] (do_nanosleep+0x0/0xd8) from [<c0082bc0>] (hrtimer_nanosleep+0x98/0x114)
[<c0082b28>] (hrtimer_nanosleep+0x0/0x114) from [<c0082cc0>] (sys_nanosleep+0x84/0xb0)
[<c0082c3c>] (sys_nanosleep+0x0/0xb0) from [<c0038680>] (ret_fast_syscall+0x0/0x30)

I haven't looked exactly what causes pick_next_task_rt() to call BUG(), but I would hazard a guess that it must have been some serious f*ckage which caused it, which caused that function to fail. Probably something to do with all that obscure code you added.

The thing you have to remember in kernel development is that little things in one area can have a massive, critical impact in another area, particularly when you have no idea what you are doing.

The kernel is horribly sensitive. Even something that you don't think will affect anything else can have wide ranging implications for stability and reliability. Perhaps more reading and less random coding is in order, actually learn about the kernel first, it's APIs, do's and don'ts etc.

Just some friendly advice.
[Nexus S Android Development] :
Right, anyway...

Here is v1.4: http://d-h.st/MoU

-Deep Idle now fixed at 800 MHz for stability

-Governor also switches to performance for DI to save CPU cycles

There's no doubt that thalamus is a genuine dev, compared to me as an enthusiast, but just in case anyone is accepting his vague dismissal of my github commits I can happily justify every piece of code that's been altered. I'm gonna start with the code I found in kalim's original kernel source, and show what I did to it and why.
[Nexus S Android Development] :
tl;dr - Don't aspire to produce something decent as it isn't the developers responsibility, it's up to the user. Did I get that right?

Rubbish.
[Nexus S Android Development] polobunny:
tl;dr, give the man some slack for he clearly wants to improve his knowledge with trial and error.

Edit: Besides, he is asking the right person isn't he? It's not like you're not looking over his stuff. Better that than just pilling on features like every other kernel.
[Nexus S Android Development] :
Maybe you can justify it, but you don't know what you are doing, that is the issue. Hence why you introduce bugs then don't even know where the bug is actually occurring, even though you have a stacktrace which clearly tells you. That isn't the sign of someone who understands kernel development.

I was trying to give you some advice, and perhaps make you take a step back and look at the stuff you are doing, but you are clearly right, and I am completely wrong. What the hell do I know?

It doesn't matter, continue on with your pursuit of total kernel f*ckage, I'm outta here.

---------- Post added at 08:57 PM ---------- Previous post was at 08:56 PM ----------

Lol. Trial and error is fine, I do enough. Test it yourself though, don't release random hunches every 2 minutes. :eek:
[Nexus S Android Development] polobunny:
Which is pretty much what I was getting at. Haven't seen bedalus force someone to flash his kernel. I'm all for freedom. The choice to stay stock, or the choice to flash something and end up with a brick. Couldn't care less if people can't understand the risks, and neither should the devs imho. =)
[Nexus S Android Development] rasengan82:
So if the bugs are coming from base cm...does that mean CM9 is not as stable as people think?
[Nexus S Android Development] Randomwalker:
Well, this is about DI code if I get bedalus right. There is apretty explicit warning in CM9 about DI not being stable.
[Nexus S Android Development] jeepcook:
I installed the 6.7.3 version and now I see there is 3 new versions !! what a speedy rythm !!!
[Nexus S Android Development] :
morfic just got back to me on the ARM MCS value code, so I'm gonna check that now, and if it's wrong, then 6.8 is coming out next
[Nexus S Android Development] RunTech:
With marmite 6.7.6 no problem with the power botton....i'm going to see if something goes wrong and i will notice to you
[Nexus S Android Development] :
v6.7.7 is here: http://goo.gl/rqjUX

-Fix an issue in the cpufreq.c code that manages how various clocks values are multiplied

-ARM MCS CON mask is supposed to apply to the bottom two frequencies, and I had it working only for the bottom frequency.

-Thanks to morfic for confirming

This is a 6.8 candidate, reboots appear to be solved, pm_fast is solved, alarms are solved, BLN is solved, BLX may never have been an issue. Please test aggressively. If your device suffers a reboot please report your model, your ROM, what you were doing, and provide a pledge of 'I wasn't overclocking!', and try to provide a last_kmsg.

Please let me know if there are any other issues I've forgotten about.
[Nexus S Android Development] caliban2:
Will test tonight if blx=90 works for me. Just wanted to remind you that I had another "problem" with it when it's set to 100. It would charge to 97, then say "charged" and continue trickle-charging to 100 over hours. It's just that it doesn't behave like it should (and once did).

At the speed you fix things today (I like it!!! One step at a time) I'll be testing it on 6.8 probably, need to get home first. :)

Edit:

And there's the next candidate already... :D
[Nexus S Android Development] :
If this version holds up to testing I'll re-add bigmem and see if reboots return.
[Nexus S Android Development] Basche:
i'm trying to keep the custom settings i have in NStools constant so i don't have to load it every time i power on my phone, using Setting preferences with init.d from the first page, and I'm stuck in finding /etc/init.d/ where i have to copy the text file. there is no init.d folder there. What do I do?
[Nexus S Android Development] stojshic:
Your rom probably doesn't support init.d (rasbean, for example, doesn't support it, by default). If you want, do to this thread, there's zip to flash, that will enable init.d for your rom, just be sure to install busybox in /xbin instead of /bin

http://xdaforums.com/showthread.php?t=1953230
[Nexus S Android Development] caliban2:
For those using init.d-scripts and using standard bln (simply lights on), you need only this line in your script starting with 6.7.7:

echo 1 > /sys/class/misc/backlightnotification/enabled
[Nexus S Android Development] :
Just want to give a big shout out to simms22 who most will recognise as one of the most helpful and patient people here. Still helping out in our section even though his nexus s bought it in the hurricane.
[Nexus S Android Development] caliban2:
Bedalus was right, BLX works when used to limit charge. Just tried with 35%.
[Nexus S Android Development] _yaz_:
yep. blx/bln seem to work fine in 6.7.6. thx !
[Nexus S Android Development] vnsilva:
Hi

Have you plans to add feature "touch wake"?
[Nexus S Android Development] :
I love Ezekeel's creativity, but I don't see the value of this mod. When you shut off your screen you always push the power button right? So just increase your screen timeout length. It works exactly like touchwake except without the touching.
[Nexus S Android Development] simms22:
ezekeel, the developer of touchwake, himself said that touchwake prevents the device from properly sleeping. unless thats been rectified, i dont see it being added. but, only bedalus can properly answer the question ;)

edit.. bedalus answered :p
[Nexus S Android Development] waterface:
Last thing we need with these phones, stuff that prevents them from properly sleeping!

big hug simms22, I have friends in NY, heard some horror stories. all the best!
[Nexus S Android Development] AzN MusiQ:
Because of you, bedalus, i must flash every day ^^

Gesendet von meinem Nexus S mit Tapatalk 2
[Nexus S Android Development] :
Uh, you mean four times a day, right?
[Nexus S Android Development] Maxxd01:
Anyone can provide the "normal" 6.7.7 version? Link is broken :(
[Nexus S Android Development] beppegg:
Just had something very similar to SID... Just entered pin code, opened tapatalk and I was reading this topic. Suddenly three phone turned black and I had to pull battery.

Marmite 6.7.7, rasbeanjelly Nov, 6th, i9023, stock kernel settings!

Inviato dal mio Nexus S con Tapatalk 2
[Nexus S Android Development] anshumandash:
Oh man, I didn't check xda for few hours as I was out. Now I am 4 versions behind. :)

I wanted to report alarm and data works fine on 6.7.3 after few possible tests. But now I am going to flash the latest version of the kernel.

You are amazing Bedalus.

Sent from my Nexus S
[Nexus S Android Development] beppegg:
QHard reboot on 6.7.7 while reading some articles saved on pocket, and a freeze on my first try in writing this message.

Now I've fixed permissions, let's hope that will settle.

Rasbeanjelly Nov, 6th

Marmite 6.7.7 default settings,

i9023

Last_kmsg: http://db.tt/WlTZjAed

Inviato dal mio Nexus S con Tapatalk 2
[Nexus S Android Development] :
Aha, kernel panic. Timers. Thanks for reporting fully.

After further investigation, this might be due to some android-3.4 code I merged in to prevent unnecessary spinlocks in the scheduler. It seemed like a good idea, but what works in 3.4 doesn't necessarily work in 3.0. I'll revert the change and upload a new set.
[Nexus S Android Development] caliban2:
Nothing bad to report with 6.7.7cm so far. I made some calls, send some messages, surfed the web, played need for speed - all is fine.

One issue occurred, but not sure where to put it yet:

Alarm failed this morning. BUT: I'm using 4.2-deskclock, and while it didn't go off, it greeted me with a fc-message. So it tried to go off, but crashed. This is leaked software, not official, one would expect things like this. On the other hand it worked perfectly fine for almost two weeks, until you started meddling with timers beginning with 6.7.3.

It's a first, maybe just a hiccup. But now you know about it. :)
[Nexus S Android Development] :
Cool, thanks. The additional RTC clock I enabled for the 8998 chip seemed to cause problems, so that's already reverted since v6.7.4

Try the next version, which is up already (v6.7.8)
[Nexus S Android Development] caliban2:
I'm the one who downloaded it as "marmite_CM.zip"... :o
[Nexus S Android Development] :
here is v6.7.8: http://goo.gl/HvUrp

-Revert a commit which backported part of the android-3.4 kernel in the task scheduler, that prevented some spinlocks. This experimental tweak might have caused a kernel panic, safer to revert it. Not everything in 3.4 will happily work back in 3.0

Thanks alen1901 for spotting the typo!
[Nexus S Android Development] alen1901:
Its 6.7.8 not 6.8.8 :p
[Nexus S Android Development] anshumandash:
You are right. It is 6.7.8. But I am not going to flash it now unless I get some re-boots. Now I am going to OC to 1096 and try all sorts of games on 6.7.7 and see if it reboots. :p

If it does, 6.7.8 will make to my phone today. :D
[Nexus S Android Development] atxbang56:
just flahed and works perfect for me

Nexus S 9023 running MIUI 2.11.9

Envoyé depuis mon Nexus S avec Tapatalk
[Nexus S Android Development] :
If it reboots when you oc, play with your voltages. But don't report reboots. I only want to hear from people who don't oc
[Nexus S Android Development] :
v6.7.9 is here: http://goo.gl/rqjUX

-Re-merges the mainline v3.0.35 minus the changes to mm/vmalloc.c.

This patch set caused an issue where the entire OS would collapse, leaving only the notification bar visible, sometimes followed by a reboot.

The changes I'm leaving out affect how memory is freed, so may prevent this bug. Please test aggressively, without oc. If you do discover this bug still exists, please report fully and flash back to a previous version.
[Nexus S Android Development] atxbang56:
typo error in downloaded file -> it's 6.7.9 not 6.8.9

Sent from my pretty cool Nexus S

Phone : Google Nexus S i9023

ROM : MIUI 2.11.9 by MIUI France

Kernel : Marmite v6.7.8 by Bedalus @1096MHz
[Nexus S Android Development] :
Sorry about that!
[Nexus S Android Development] jeepcook:
there is very too much version ... could you name some versions as stable and others as test ?
[Nexus S Android Development] stojshic:
As much as I know, bedalus uses numbering as x.y or x.y.z where x.y are stable versions, and x.y.z are test versions.
[Nexus S Android Development] treesurf:
What is that...5 kernels in 24 hours? Slow down man!

OKCD!!

aka Obsessive Kernel Compiling Disorder.
[Nexus S Android Development] :
Try v6.7.8

v6.7.9 needs more testing because there is still a chance that some code may cause a bug
[Nexus S Android Development] atxbang56:
No problem...

modifying again and again my signature after flashing 10 times a day... :)

Sent from my pretty cool Nexus S

Phone : Google Nexus S i9023

ROM : MIUI 2.11.9 by MIUI France

Kernel : Marmite v6.7.9 by Bedalus @1096MHz
[Nexus S Android Development] jeepcook:
x.y are stables ? I don't think .. because if you read the long list of patches ... it seems previous versions are not very stables...
[Nexus S Android Development] anshumandash:
I know I won't. :)
[Nexus S Android Development] :
I think the last two or three stable versions weren't particularly stable. However, whatever the problem was seems to be solved now.

I'd appreciate the help testing the latest version, but at the moment v6.7.8 is the one least likely to have any issues.
[Nexus S Android Development] atxbang56:
@bedalus : it's awesome to think that Google doesnt' give you a job...how can Google release so poor kernels on their own androphone

Sent from my pretty cool Nexus S

Phone : Google Nexus S i9023

ROM : MIUI 2.11.9 by MIUI France

Kernel : Marmite v6.7.9 by Bedalus @1096MHz
[Nexus S Android Development] treesurf:
By the way, Didn't mean for this to seem like I'm giving you a hard time. Just kidding around. Truly appreciative for the work you share with us.
[Nexus S Android Development] :
You are correct. Unfortunately I was more than a little over-zealous while labelling those versions. A new stable is going to be available as soon as v6.7.9 reveals the bug I described.... However, if a sufficient number of downloads are registered, and a sufficient amount of time passess with no bug reports, then I will keep the v6.7.9 patch and re-classify it as v6.8

There's been lots of versions recently because I've decided to release test versions change-by-change, otherwise it makes it very difficult to say what changes are safe. Hopefully this will make the stable releases have more meaning.

I may just release test versions in one format once I hit the next stable, because building and uploading five different versions for each change is going to cause me to burn out quite quickly. This is likely to be whichever version has historically had the highest level of downloads.
[Nexus S Android Development] caliban2:
And after all, I don't think someone's holding a gun to your head, forcing you to flash every version. :D

Nah, I like him taking it step by step. Those who don't want to test, can always sit it out and wait for the next stable.
[Nexus S Android Development] :
There's nothing wrong with their kernel, or the Samsung source, but they have to play it very safe and ensure stability. But the Linux kernel is a constant work in progress. Also, Android kernel is the same. Plus we're wedging new bits of code in to prove unofficial features, like mtp or over clocking... This is the fun bit! But it's not fun if you're late for work or miss an exam because your alarm failed... So while I'm meddling to see what happens, I'm also trying to balance that with keeping it as reboot-free as possible. I'm trying to get strict about how I do this.

Anyway, as long as people are willing to test changes, things can progress quickly.
[Nexus S Android Development] :
:D yes i got it was a joke. I said something similar a couple of pages back!
[Nexus S Android Development] sperelli:
SM 2.9.0 + 6.7.7CM...

+NSTOOLS

min freq 100

BLN on, 0 / 0 / 0

god blessed me,

my baby is sleeping

and UNBELIEVABLE...BLN lights turn on and stay ON!!!!

Fantastic.. this solves part 2 in this post of mine: http://xdaforums.com/showpost.php?p=33112705&postcount=4

THANKS a LOT, BEDALUS!!:good::good::good::good:

EDIT: I left BB6 for to try the CMversion of bln coding... once BB7 is released, i'll try that..
[Nexus S Android Development] :
Actually, I suppose I should let things sit for a few days, to allow some longer uptimes.
[Nexus S Android Development] :
Hahaha awesome. I'm glad it works for you
[Nexus S Android Development] ScOULaris:
So I decided to try out a few other kernels yesterday, and all of them were a very noticeable step back from Marmite in terms of performance and possibly even battery life. I don't know what kind of voodoo magic Marmite is using, but it seems to be hands-down the best kernel for my Nexus S running on CM10.
[Nexus S Android Development] :
Thanks. Make sure you test it thoroughly.
[Nexus S Android Development] polobunny:
When was this mainline patch added? That seems like it would have been added a damn while ago!

I recall getting this issue previously, but haven't seen it's ugly head in a while.
[Nexus S Android Development] gregorypeg1000:
When the bln works and the touch keys light up,should the phone be in deep sleep or stay at 100mhz?
[Nexus S Android Development] polobunny:
Once they're lit up, it will go back to deep sleep.
[Nexus S Android Development] caliban2:
Deep sleep.

(If it's set to just stay on. Dunno about blinking.)