yashsingh1/xdaforums huggingface dataset:
[Nexus S Android Development] caliban2:
You have absolutely no idea what you're talking about, right? And no, it isn't.
[Nexus S Android Development] leap_ahead:
guys its safe to oc to 200-1200 and how much cost on battery life ?

thanks
[Nexus S Android Development] :
I've left the thalamus base behind. And I tried interactive, which I thought didn't give any improvement, and used too much high frequencies, i.e. battery eater.

I'm trying to keep this kernel as stripped out as I can, I feel restraint is as valuable as additional-features.
[Nexus S Android Development] granets:
4.2 broke YouTube playback for me. Going back to 3.5
[Nexus S Android Development] :
Just flash the bigmem patch in the op!
[Nexus S Android Development] leap_ahead:
cool with patch is working ...

you can add them in next version ?
[Nexus S Android Development] caliban2:
Don't like the idea of adding the patch. I never had any playback-problems on jellybro (cm10-kang), must be rom-related. Adding the patch adds the chance of breaking stuff on ROMs not needing it. :)
[Nexus S Android Development] leap_ahead:
for me i must use it ...
[Nexus S Android Development] Articudos:
In cm10, already patched..

Kalim made those libs, afaik;)
[Nexus S Android Development] caliban2:
That explains it. :)

At first I thought fixing rom-bugs via kernel opens a can of worms, but since it's introduced by kernel (bigmem) in the first place...

Just babbling, bedalus' decision anyway.

---------- Post added at 03:46 PM ---------- Previous post was at 03:07 PM ----------

Just had a full freeze while typing a post on opera mobile. Waited two minutes, but phone didn't reboot, had to pull batt.

Do I really have to add no last_kmsg to be found at all? :(

I think for a proper elimination I have to go back to something more stock though. I like cm10 and its kangs, but I don't trust it.
[Nexus S Android Development] xjerlzx:
the script...

correct?

cant seem to get it work even with the sd-booster app. stays at 128 when i check at /sys/devices/virtual/bdi/179:0/read_ahead_kb

#!/system/xbin/bash

. /system/etc/liberty.cfg

if busybox [ -e /sys/devices/virtual/bdi/179:0/read_ahead_kb -a $SD_BOOST_AT_BOOT -eq 1 ]; then

busybox echo 2048 > /sys/devices/virtual/bdi/179:0/read_ahead_kb

fi
[Nexus S Android Development] polobunny:
No last_kmsg is extremely rare. In 99.9% of times you'll have a kmsg. Only the biggest *uckups will result in no kmsg being recorded, not that I think anyone here could ever produce one just compiling a kernel.
[Nexus S Android Development] JokerAce:
Edited my guide with the following in bold after reading queries subsequent to my post, and edit some spellings.
[Nexus S Android Development] caliban2:
Thanks, but what exactly is it you're trying to tell me? :confused:
[Nexus S Android Development] JokerAce:
You are the unlucky 0.1%. :fingers-crossed:
[Nexus S Android Development] polobunny:
You said you didn't have any last_kmsg? That's extremely rare. There's very few errors that lead to not having any last_kmsg, and most are related to a failing SD (or disk, depending on the architecture).
[Nexus S Android Development] 4tticuz:
Yes, that's it!

Thanks for editing, it was so much easier to recognize what that guide is for!

After editing the file, NSTools can be deleted, right?
[Nexus S Android Development] caliban2:
Rare doesn't mean impossible. :p

"Good" thing is it happened while i was using the phone, so maybe I can reproduce it while pulling logs via adb... Same thing happened with v3.5 (I think) on an earlier Jellybro-build, but back then the phone rebooted by itself after being frozen for ~30 secs. (But no new last_kmsg, the one from cwm still in place)

I know a dev can't fix anything without a log, but what am I to do - say nothing, all's fine?!
[Nexus S Android Development] polobunny:
No, not at all. But I'm wondering if it's really a software issue rather than a hardware issue. When I say rare, I mean it. It's rare the kernel won't be able to write to the SD (no interrupt handler/not syncing being a "popular" one but not really SD related). Others often being related to being unable to write to the SD because the memory was removed (unlikely since embedded) or failing (yikes). That's why I'm surprised.

I've had these symptoms before and was always able to extract last_kmsg.
[Nexus S Android Development] pan1980:
Bedalus does this any version of your kernel has swap file support ?
[Nexus S Android Development] caliban2:
I agree that it's a big booboo. It was an instant freeze, screen on, backlight stayed on more than a minute, no response to hw- or softkeys.

But hw-related? Not so sure... I think it should happen more often then, not just twice in two weeks. And of course I don't wanna hear anything about my hw failing. ;)

Nah, I need my laptop and start looking at live logs. I'm sure I'll spot something.
[Nexus S Android Development] polobunny:
Hopefully it's not a HW failure, although if you look around it seems a lot of Nexus S are starting to fail (unable to mount SD card and the like).
[Nexus S Android Development] Imppy:
I wonder if I change kernel I need to delete init.d folder?
[Nexus S Android Development] Articudos:
Only Jellybelly 0.1.5, 0.1.5.1

IMO.

Other ROM doesn't have kernel restriction, afaik.:)
[Nexus S Android Development] :
He did a battery pull, no last_kmsg is normal
[Nexus S Android Development] :
Really helpful! Much appreciated :)
[Nexus S Android Development] :
No keep posting all issues!
[Nexus S Android Development] :
No, and you wouldn't want a swap file to artificially boost memory, because performance would take an unacceptable hit, which is why we do our best to free RAM instead.
[Nexus S Android Development] :
I worked out somewhere in one of my crackflashing ROM benchmark threads that according to the limit of write cycles we have on our NAND, we ought be able to flash about 800,000 ROMs before it fails.
[Nexus S Android Development] :
One pretty good way to make sure your init.d is correct is to open up the zip of the ROM you use. Copy the /etc/init.d contents. Delete the init.d contents of your Nexus S (but if you have made your own scripts, back them up first!). Paste in the copy from the ROM zip, and replace your own scripts.
[Nexus S Android Development] caliban2:
It just happened again, phone completely frozen. This time in settings.

Attached it to the pc, it get's recognized via adb devices, but apart from that - nothing. Can't pull any log, just empty. (I mean, I can't even log on to shell)

Big boo boo indeed. ^^

Edit:

I forgot something. Few minutes before it happened, I wanted to install an app (from SD). Installation always aborted, "couldn't be installed". So something could be fishy with memory/file system after all. Bedalus, is there any commit in .35 which would point to that area?

Edit2:

adb reboot worked - and i've got a last_kmsg. :)

http://pastebin.com/47SmPeqC
[Nexus S Android Development] :
Good effort getting that. It looks strange to me. It's getting a request to wake up but nothing is happening. Can you flash back to v4.2 and see if the problem goes away?
[Nexus S Android Development] caliban2:
Will do.

But I think there's more to it than that. at line 3111 it started to kill lots of services, looks like practically everything to me. then that repeated alarm_release at 3179 and some untracked pids right after. don't these point to ramdisk?
[Nexus S Android Development] FirePoncho86:
Favorite GB kernel: Matr1x

Favorite ICS kernel: Matrix

Favorite JB kernel: Bedalus' kernel/ Marmite.

Thanks Bedalus for this amazing kernel!

Sent from my Nexus S eating jelly beans in the mat-- er.. um.. Marmite ;)
[Nexus S Android Development] JokerAce:
.31 is most stable and battery friendly according to mk here :fingers-crossed:
[Nexus S Android Development] CrackerTeg:
Just flashed marmite and I've gotta say, I've never laughed white flashing a kernel. The comedy in the script is great. One thing that would be awesome to add, fast charge. Just a thought. Otherwise, great work bedalus.
[Nexus S Android Development] polobunny:
And how did you calculate that? Theory is nice, but since I'm from the computer field I damn well know practice is different. Nothing stops one very little area to be causing huge problems down the road if it corrupts data over time. Seeing the random pattern of flash memory, I wouldn't be surprised. You have to say that we're really seeing a lot of Nexus S memory problems pop up as of late...

Don't let me scare you, but if it is indeed a problem related to your memory remember I said I told you. :p
[Nexus S Android Development] technogravy:
Anyone experiencing high Android OS usage in the battery stats? Didn't have this problem before 4.1
[Nexus S Android Development] caliban2:
You're just guessing, so why should I be scared?! You made up your case on the fact that there wasn't any last_kmsg - bedalus told you why that was the case, i've showed you how to get one anyway and if you can read the log, you'll see it points to software.

But yeah, better stop it now, there are enough people around here who will believe everything.

Next we'll see people claiming their memory is failing, while they were simply too dumb to flash gapps-zip...
[Nexus S Android Development] dinuvali:
Yep, me too. I've tried to use betterbattstats and it showed that the maps app was the one using the most battery..
[Nexus S Android Development] Articudos:
I'm Experiencing MMS battery drain, over 60%.(BLN on)

I guess it's euroskank cm10 problem(or not)

, so....Just uploading betterbatterystat.apk's log will be helpful?

(4.2 marmite)
[Nexus S Android Development] towelboy:
I second all the high android system & os battery usage. So far 4.2 is more smoother then 3.5 but it drains a lot more battery..
[Nexus S Android Development] :
I worked it out in the ROM benchmark thread somewhere, based on the size of the ROM, the capacity of the nand, and the maximum write cycles. This was assuming that the wear leveling algorithm was sufficiently fair, and the detection and correction of bad blocks was effective.

I think I'm seeing less complaints about the nand tbh. When i first came to the forum i saw a lot of posts about the nand "burning out", meaning faulty, rather than worn out.

I think there's been more bug reports recently, but that doesn't necessarily mean there's more bugs, it could mean that more people feel like posting them. Also, i haven't seen any posts that indicate a problem with reading data off the drive. I've seen bad behaviour where apps/os/kernel have been to blame, but we just got jb, and some kinks need ironing out.

While i don't personally think there's a nand issue in the forums at the moment, a precautionary backup certainly wouldn't go amiss. That's always a good policy anyway!
[Nexus S Android Development] :
I read some stuff about the media server doing extensive searches in jb. I think it's an os bug. Not sure. But unfortunately the logs won't help with the kernel side, thanks anyway!
[Nexus S Android Development] :
Thalamus had a rant about the mainline patch policy, and went back from .39 to .31

I went to .40 (reboot central) then followed thalamus lead to .31

Now .34 seems perfectly fine. .35 may have some issues. But if i can eliminate the offending code, a move to .38 will be on the cards.

It's going to take at least six builds to eliminate the dodgy commit in .35 and probably more if i want to get safely to .39

But I'm happy to do this because i generally feel quite positive about patching. Just because one commit doesn't play nice with Android doesn't mean we should ignore the other 19
[Nexus S Android Development] polobunny:
True that. Battery pull didn't help in not getting any last_kmsg. :p

On another point, as far as I can see, Bedalus didn't pinpoint any problem with your last_kmsg. Heck, nothing came out of both of you guys regarding the analysis of it other than "it crashed". If you think that's how a resolved case looks, then hurray for you. To me, I see the issue as still unknown if not still present. The joys of trial and error...

It's a decent approach if it's really because of the NAND itself failing, but the BGA for the NAND had a tendancy to fail early on the Nexus S. Mine suffered that not very long after I first got it (brand new!). Most of the people that cannot write to the SD cannot write AT ALL, not even 1 bit of data. I wouldn't be surprised if it's a more widespread problem than we'd like to believe, although nothing of extreme magnitude.
[Nexus S Android Development] caliban2:
Bedalus, here's another pastebin, an excerpt of my current kmsg: http://pastebin.com/SUSdtsyD

I noticed phone being a bit laggy, so I thought I'd check -> it's been busy killing services again... No freeze though (yet) and everything's snappy now, kmsg looking normal. This is with 4.2, which is deemed stable. So I don't know, maybe it's caused by ROM and a full wipe is in order (been a while since the last one).

Just to let you know. :)
[Nexus S Android Development] polobunny:
I'm running Jellybro myself and I experience the same kind of behavior from it. After a few hours, near 50 or so, I have to reboot my phone to make it snappy again because otherwise it seems to be getting laggy. Apparently all JB roms have the same problem whereas they get slow over time.

Was it you that mentionned this before? A bit bummed having to reboot my phone "so often" when in theory you shouldn't really ever need to reboot it.
[Nexus S Android Development] caliban2:
Nope, not me.

Mine is running 9 1/2 hours now. I'm wondering why it's been so desperate to kill all services and reboot them. I think it tried 3 times (same processes being killed again and again). Didn't have to reboot though, sorted itself out. ^^ Couldn't be bigmem-patch, could it?

But I think (!) what happened with my previous freezes is me putting extra "stress" to the phone when it's been busy sorting memory...

And I still don't trust cm10 (=jellybro), it's in alpha-stage.
[Nexus S Android Development] polobunny:
I don't trust early builds of ROM either, but from I remember reading someone said it happened even on stock ROM, thus pointing to either a custom kernel issue or a JB issue in itself (because I don't recall if the person mentionned if they were running a different kernel)

When I reboot my phone I have plenty of RAM free, and whenever I notice it becomes sluggish all I can see is RAM being magically taken away (apps in running apps don't add up) as the apps running are the same as what I had at boot. No matter how many apps I kill I never come back to the snappy feeling of a reboot neither to the same amount of RAM free. Not that I'm obssessed with free RAM in itself but this is too strange to be a pure coincidence.

All in all, annoying little problem to me.
[Nexus S Android Development] technogravy:
I think the high Android OS usage is more kernel related.. I changes from slim to paranoid Android and no issues until I flashed 4.2 and switched BLN on. Then the Android OS seems to eat up the battery when idle. This is the same with 4.2 on slim bean.

Better battery seems to show 'kworker'as a culprit. Any idea's?
[Nexus S Android Development] Imppy:
I get android is battery drain too..on pa
[Nexus S Android Development] polobunny:
You're using BBS wrong here. Don't need to see the process list, rather partial wakelocks or kernel wakelocks. Doubt it's kernel related to boot but rather apps or user related.
[Nexus S Android Development] Bureunwoolmyeon:
I use stock OTA jellybean(JRO03E) with your 4.2 stock OTA version. It's very good for both battery and performance.

Thank you for your kernel. but,

what is the difference of stock OTA version and the other?
[Nexus S Android Development] :
Only the ramdisk. The Stock OTA ramdisk doesn't support init.d, but I have added MTP.

There may in fact be no need for two separate versions, but I haven't looked properly at it yet.
[Nexus S Android Development] gabling23:
Very good battery life :)

Sent with Tapatalk 2
[Nexus S Android Development] :
I'd say it's not a kernel issue, it's OS level.

As for the correlation for lag and uptime, I can't say. I usually flash a new kernel version every evening at the moment, so my uptime is never more than a day. But if the system is having some issue with killing things, then this will also have an impact on free memory and the processor overhead of unnecessary running services.

My library recently failed to find all my music and photos after flashing a new ROM. To solve the issue, I copied all my media on to my computer, before formatting the sdcard partition. When I copied my stuff back, it found it immediately. I've no idea what sort of things happen between the ROM and the sdcard, but there are some system files stored there. I don't want to initiate some new cargo cult, but perhaps following the same procedure might help solve these nebulous issues?
[Nexus S Android Development] :
With good reason.

I did actually spend a lot of time looking through mainline commits the other day and I cherry-picked the stuff that was directly useful to the devices at hand, which fixed bugs with the actual ARM architecture or scheduler issues, or serious issues in other subsystems.

For maguro, there was a total of 8 commits (6 ARM and 2 scheduler which aren't even in 3.0 stable). For crespo, 4 commits (2 ARM and 2 scheduler), because the other 4 only apply to SMP or A9 devices.

For grouper, substantially more (about 20 rings a bell), but that is stuck on 3.1.10 and hasn't seen any mainline updates in ages.

Not worth taking 1000 commits when only a handful are of any use...is it?
[Nexus S Android Development] :
Certainly not, but it's knowing which ones are useful and which aren't. Unfortunately I'm not experienced enough to make those sorts of calls.

In theory, at least one of the commits between 3.0.31 and 3.0.40 has introduced instability. If it's one of the one's you've picked, how will you eliminate it?
[Nexus S Android Development] :
Looks like some discussion of the same issue going on in the cm thread:

http://xdaforums.com/showthread.php?t=1399035&page=731
[Nexus S Android Development] caliban2:
Yeah, but that's been caused by rommanager, placing a nomedia-file in sd-root. version 5.0.1.4 fixes that. or so, i don't use it, just following the thread. :)
[Nexus S Android Development] :
Ah.... That makes sense.
[Nexus S Android Development] sidnoit22:
Exactly i was asking this thing and you said give me a good reason why i do this.. nvm ;)

Good to know!
[Nexus S Android Development] sidnoit22:
bedalus r_data release 3.0.41 kernel.. have something new or it will smooth our marmite? :D
[Nexus S Android Development] :
I'm just looking at r_data's github now, he's got a collection of wifi patches. I've already squashed those into one commit (718eb47cf36863b8938909c13773a03842174d5b if any other devs want to save time)

Looking at r_data's github, it also looks like he is experimenting with reverting back to 3.0.31

Thalamus has collected the individual commits that are actually relevant to our device from all the mainline patches to date. However, one of those commits might also be the culprit for the reboots. I don't know how thalamus would predict which one in advance, which would be interesting to find out.
[Nexus S Android Development] yourlookingatbob:
Will this work on Blackbean 2?
[Nexus S Android Development] :
It should. I haven't personally tested it.
[Nexus S Android Development] caliban2:
Mash them in and we'll see what happens. :) Worst thing that could happen is another reboot/freeze.

I don't remember any problems with 3.4.39, btw.
[Nexus S Android Development] CrackerTeg:
That's what I'm running right meow. Ignore what my sig says. I'm leaving my last completely stable rom there until I find a good DD.
[Nexus S Android Development] :
I think there were some at .39 but it didn't get bad until .40

I haven't had any issues with .35 so I'm going to move to .38 as I'm certain things were ok at that point.

I don't know why mk's ics kernel couldn't handle .35, perhaps it's a matter of incompatible tweaks?

Anyway, I'll release the .38 as testing. As usual, any brave testers will be expected to report in detail all issues, and try to supply a last_kmsg.

Will upload shortly.
[Nexus S Android Development] raducux:
No voodoo sound ?
[Nexus S Android Development] :
It has it. Did i miss it from the feature list?

Yes i did. D'oh!
[Nexus S Android Development] :
Here is v4.3_test2 http://d-h.st/K3L (TESTING!)

-Merged up to 3.0.38 mainline

-Merged in bcmdhd patches (thanks edoko!)

-New BLN blink pattern

Usual testing caveats apply!

echo 1 > /sys/class/misc/backlightnotification/blink_finalstate

>>> 1 is BLN light stays on after timeout, 0 is off

echo 1 > /sys/class/misc/backlightnotification/in_kernel_blink

>>> Turn blink on to try the new pattern!

echo 6 > /sys/class/misc/backlightnotification/max_blink_count

>>> Multiples of 10 seconds. 6 = one minute. This timeout applies even without blinking enabled

Try turning blinking on!
[Nexus S Android Development] Articudos:
This is OS specific, Only for JB:)
[Nexus S Android Development] tchaari:
lol, bitter? you are the only one claiming that everything is running fine with it :p

Yeah I am busy with work these days. Can you imagine that I didn't used my nexus S since more than 24 hours? :p

I set the minimum frequency to 100Mhz, checked "apply on boot", rebooted and everything is fine. This kernel seems to be well cooked in the marmite :D
[Nexus S Android Development] caliban2:
v0.9 still running stable after 14 hours.

So either it's caused by different setups or my phone takes longer than others to crash. (Was the same when testing matr1x-stuff)
[Nexus S Android Development] sisterchick:
Here it goes!

Taking the plunge with v0.9 now. Thanks for all the research and work you have put into this project.
[Nexus S Android Development] Icecoldmeat:
V0.9 runs fine for like 10 hours now.

Sent from my Nexus S©
[Nexus S Android Development] spupuz:
Gone back to matrix22 that is more stable and performant

Inviato dal mio SmartTab10 con Tapatalk 2
[Nexus S Android Development] 1PATRIK:
0.9 rebooted itself after 13hrs.
[Nexus S Android Development] KrisMurdrum:
Flashed v0.9 last night and since then it rebooted twice while I slept... Damned phone won't let me pull the logcat though, says access denied, but it's been a while and I wonder if I am forgetting a step...

I'm getting a better battery life though, even with the two random reboots.
[Nexus S Android Development] :
I've been messing around with this all day. I think I've solved the stability issue in ondemand by reverting franco's tweak.

The smartass governor, I did have some settings that allowed it to reboot and keep 100 MHz, so I'm just trying to find them again... will attempt to upload when fixed!
[Nexus S Android Development] :
Me too. :D
[Nexus S Android Development] :
OK. v0.9.1 is here: http://d-h.st/eKB (Test/experimental)

It's passed midnight, so expect no replies for at least 12 hours...

If you're happy to test, can you see if the reboots are gone with ondemand. And, if you use smartass, can you see if 200MHz still becomes the minimum on rebooting.

I made one other change which was to force Deep Idle to use only the 800MHz step for maximum power efficiency.
[Nexus S Android Development] Bestplayer55:
In fact i love this kernel is very smooth with kangry rr rom and the battery life is the best for me ... the only problem is the bluetooth doesnt work :-(
[Nexus S Android Development] sisterchick:
Got a reboot when turning on wifi using ondemand with v0.9. Will try update. Thanks.
[Nexus S Android Development] y3mita:
I had to go back to kangorade ROM and trinity! I just love the colors on that kernel and not sure why but everything is faster n smoother!

I think daxmax ROM (based off romanbb ROM) lacks the speed or maybe your kernel?

Not too sure, I'll keep testing later your work bedalus and thanks for the opportunity you gave us all.
[Nexus S Android Development] DaXmax:
Sorry dude, my roms are all based off from westcrip.
[Nexus S Android Development] pan1980:
is there any plan of supporting OTG ?
[Nexus S Android Development] :
I too love morfic's colors. Should i ask him if i can copy?