yashsingh1/xdaforums huggingface dataset:
[Fascinate Android Development] sixstringsg:
That's because the version that ssewk2x posted with the nandroid fix is from the latest beta source, so BLN is fixed properly in it, along with a few other things.
[Fascinate Android Development] ssewk2x:
Heh, oops! Sorry if I let any cats out of any bags.

You guys really gotta learn how to use git tag when you build releases ;)
[Fascinate Android Development] sixstringsg:
Haha, it doesn't really matter. I'll either remember to bother Tk about it, or do it myself.
[Fascinate Android Development] schu9120:
I have been using the Glitch kernels on my fascinate since version 11 came out and since I was getting tired of the aokp unicorn boot animation, I decided to to make one that was Glitch themed. I have never been able to contribute to the glitch community because , well I'm just not as smart as you guys :D so here is my way of saying thanks...

Its the first boot ani that I have ever made...

http://xdaforums.com/showthread.php?t=1539458

Sorry for the off topic post
[Fascinate Android Development] AtropineNa:
what are some settings to get good battery life on this kernel? batteryxtender 95%?DIDLE? uv? not sure how to undervolt and the differences between arm/internal... thanks for any input and lovin' this AOKP/glitch combo
[Fascinate Android Development] k_nivesout:
Deep idle doesn't seem to be working, although I haven't tried it on the latest test builds. Batteryxtender doesn't have anything to do with battery life, it controls how "full" of a charge you get. UV isn't really worthwhile since the gains are small enough to be negated by the risk of reboots (which would consume more power than you're saving with UV).

If battery is a concern, make sure you don't have any apps holding wakelocks and watch your sync settings.
[Fascinate Android Development] sageDieu:
My deep idle definitely works as long as I keep wifi off which is a known issue.
[Fascinate Android Development] AtropineNa:
Awesome thanks! How would I go about checking any apps that are holding wakelocks? [not even quite sure what that is tbh...] As for syncs, I only have my google stuff synced, so that shouldn't be too bad..
[Fascinate Android Development] k_nivesout:
What exact kernel are you using? I tried it with B5 for 6.1 (and a later test kernel) and couldn't get any time in TOP=ON or TOP=OFF.

A wakelock is basically when an app doesn't allow your device to get to "deep sleep", where the most power savings are. The app BetterBatteryStats will show wakelocks, you can get it for free here on XDA.
[Fascinate Android Development] Deliquified:
I sort of got it to work previously on b5 for 6.1 and had time in top=on but no time in top=off. I had to turn screenstate scaling off to fix some issues with my phone hard locking. TBH, I believe it was Fiops scheduler causing it. I don't recall having a lockup since I went back to deadline. I'll turn scaling back on with deadline and do some testing to see if that's what was causing it. I noticed it mostly when loading gallery, watching videos, and browsing on chrome.
[Fascinate Android Development] sixstringsg:
Androtransfer is back up to the speeds you all know and love. If you want to know more about why, read on.

So, I've always been quite an open developer, so I'm going to explain what's been happening. Outside of Glitch, stevespear46 and I have been working on adding more open-source support (Such as Gummy, CNA, and AOKP) to the Galaxy S line. That, combined with already high downloads of this kernel (~18,000 per release last I measured) and other developers that I host for, creates quite a bit of traffic. Specifically, 5.25TB so far this month, and it's only the 12th. My hosting company (currently OVH) didn't inform me of this, but instead capped my bandwidth to 8mb/s, which was problematic considering the server runs at 125mb/s pretty much constantly. So, what's being done to fix it: recently I was donated a server by bytemark hosting for first of all a buildbot, but secondly for hosting (for more information see http://glitchteam.com) I do not have bandwidth caps with them. Therefore, every android file for anything I host will be automatically mirrored between two dedicated servers until at least when my OVH lease is up.

What this means for users: If you are a ROM dev that needs hosting, hit me up, I can help. For regular users, downloads will only be limited by your internet connection, never by the server. Which means, I can download a ROM on my connection in 32 seconds.
[Fascinate Android Development] sendan:
Holy **** that's a lot of data flow, you guys rock!
[Fascinate Android Development] k_nivesout:
Yeah, after doing some experimenting I'm also able to get time in TOP=OFF. I was trying to get it working on an earlier kernel and was messing around with screenstate scaling too (I thought I'd read it needed to be enabled) and had some issues. I guess it was a mix of messing with scaling/schedulers and the wifi thing that led me to believe it was a little unstable, but I haven't done any "good" testing with consistent stable settings. And I always forget that I have deep idle on and turn on wifi :o

I have a hard time finding a stable spot for liveOC, even when running the same percentage and voltages. Sometimes it'll be stable for days, but then I'll reboot and re-apply the settings and it'll lock up not long afterwards. I don't know, I should probably just stress test it locked at different frequencies and see what's going on.

Thanks for the update six, and thanks for the excellent work that you and steve are doing/have done with the ICS roms. I'm glad to see there are so many other glitch fans out there across the galaxy S devices! :thumbsup:
[Fascinate Android Development] thisguy23:
+1 Idk if it is possible but can we get the old OC with GPU linked? It always worked 100%. 110% works and then a random reboot. 120% works and then a random reboot. 101% works and then a random reboot. All with or without custom voltages.

This is under development and so are the roms. I'm fine with that. Everything still works well enough for daily drivers with stock speeds. However, I feel like GB was much faster than any custom speed with ICS.

Thanks devs for all your work and patience with us. I know we (I) complain a lot but I am truly thankful.
[Fascinate Android Development] neh4pres:
@tkGlitch. When you gave the init voltages in your guide you told the ones you used for different leakages. However at the higher clock speeds there was a set gpu oc that went up as clock speed increased. So those init voltages can't be used as a direct reference for live oc can they? because your old method had init finely tuned to the gpu overclock right? And the gpu was overclocked at Varying levels as clock speed increased peaking first at 1500mhz then again at 1700mhz?

it seems like there is apples to oranges being compared when giving a starting init value for different leakages from the old method. If so maybe a more accurate starting point could be figured out to help peoples stability.

If init needs to raise as gpu speed increases that would explain why at about 1000mhz on the old system, init would start climbing by.0025v per step. And maybe we should be only raising .0025v every few steps with liveoc as the gpu does not increase in speed.

nobody listen to my garble! It's highly likely i have been overanalyzing how this all works. I tend to think to deeply into things.
[Fascinate Android Development] sageDieu:
if it helps, I haven't touched voltage since switching to live OC and NSTools. too scary

Sent from my ICS SCH-i500
[Fascinate Android Development] ssewk2x:
Heh, well I guess I'm the poster-boy for figuring out what not to do with deep idle. Last night, emboldened by some folks on here who got it working using deadline and no screenstate scaling (which is my setup), I turned it on before bed.

I use my phone at night sometimes as a music/white noise player. I have a nice MP3 that works very well for that if set on repeat. Anyway .. not 15 seconds after turning deep idle on, with music playing and charger plugged in, my phone locks up and the music turns into that stuck thumping sound where it plays the same fraction-of-a-second sample over and over again. Had to do the 2-finger-salute to get it back.

So .. should I not have had the charger? The music? I have GB bootloaders, no wifi, 3g data was on, and I was using Android Music player which I downloaded from the market. Deadline scheduler, OC up to 1.5GHz using the old-school method to configure for the same voltages as old medium leakage, and -50 uv on all steps above 1.0 GHz, -75 on all steps below. Min speed is 200MHz. I'm too scared to do live OC right now, lol.

So does anyone see anything glaring in the above that would cause DIDLE to lock my phone like that?
[Fascinate Android Development] kuronosan:
Test kernel eats my battery with the same settings.

Sent in an Ice Cream Sandwich from my SCH-I500.
[Fascinate Android Development] k_nivesout:
I could swear I had read something about screenstate scaling needing to be enabled with deep idle, but that could be false. I tested it a little bit the other day and got some time in TOP=ON, however I can't remember if I have SS scaling on or off (whatever is default I suppose).

Also, I'd think that undervolting is gonna introduce a lot more potential for instability, especially when playing around with DIDLE it seems. If you haven't checked out this thread which has some very informative battery drain benchmarks and info on UV, I'd highly recommend it.

XDA thread

Also since I haven't seen much about the whole phantom press thing, I'm assuming that the other people using your test kernel have seen good results as well. I think it's happened once or twice in the last few days, which is a great improvement in the frequency of occurrences, and the "intensity" of them as well (before, the phantom presses would be insistent and happen back to back instead of intermittently).
[Fascinate Android Development] ssewk2x:
Nice link, thanks! Made some changes. One thing I noticed is it said leaving GPS on can induce instability with DIDLE .. and I've always left gps on, so maybe that's my problem. I'll hafta try it later when I'm not fixin to leave work and drive home :)
[Fascinate Android Development] k_nivesout:
Nice, I'll be interested in hearing your experience with DIDLE, I haven't had as much time to mess around with it lately as I'd like.

Also one other BLN-related thing. I love the new "blink" feature, but has anyone else noticed it will stop blinking then just keep the keys lit after 5 minutes?
[Fascinate Android Development] sendan:
Yep, I actually like that it stops blinking after a while though. It would make sense if it's intended, but I'm not sure if it is.
[Fascinate Android Development] speedingcheetah:
I had the same thing happen to me..was listening to music via my earbuds....and then bam..locked up and just got that creepy buzzing noise...I am using the newest kernel..posted a page or 2 pack...live OC 105%...max step 1300mhz...oddly..it locked up twice in a row...but it hasn't done it since...I do not have DIDLE or screenstate enabled..
[Fascinate Android Development] sixstringsg:
That's by design to keep battery usage lower. Blinking uses a lot more power than static.
[Fascinate Android Development] Deliquified:
If I had to guess (doing some of my own testing) i'd attribute the lockup to OC @ 1.5ghz with the undervolt. Personally, my phone locks at will above 1.2ghz with stock voltages. Even when I could get up to 1.5ghz with my original fassy, (new one is refurb like new) it'd lock if i was above -25uv with 1.3ghz+ speeds. Try using SIO/deadline scheduler with no undervolt and see if that makes a difference. Or, turn your OC down a bit to 1.2ghz. I don't personally see much of a point OC above 1.2ghz as you get far higher battery drain and little performance boost. It also seems to add a good bit of instability. I actually got didle to work without lockups for 2 hours last night using SIO, smoothass, 110min/1100 max (110 Live OC), and stock voltages. Give it a try and let me know what your results are. I'm curious to see if anyone else is able to get a stable didle as well.
[Fascinate Android Development] sageDieu:
ssewk2x, you described the exact same thing that happens to me if I leave DIDLE on while streaming google music over wifi. happens every time.

Sent from my ICS SCH-i500
[Fascinate Android Development] bobloblaw1:
I think I've found some very nice settings that balance battery and performance so I'll share.

Sched: fiops

Gov: Smartassv2 (glitchassv2)

Live OC: 108%

Max Cpu step: 1200 (1296mhz)

A -50mv on the 1200 ARM Volt step. Everything else the same.

It's been solid as a rock for me. I also installed the LagFreev2 tweak. Unsure exactly how much of a difference that made.

DIDLE doesn't seem to work.

I could push it to the next CPU step (1404) but it really adversely impacts the battery it seems.

EDIT: please don't set these values to apply at boot until you are POSITIVE they are stable on YOUR phone.
[Fascinate Android Development] Deliquified:
Through experience I've found fiops to be extremely unstable.. My phone would hard lock when cpu was doing heavy processing (videos, chrome switching tabs, browsing gallery).. Ever since I switched to SIO I haven't had a single hard lock..
[Fascinate Android Development] Not_So_There:
Recovery Ram Error

I'm attempting to flash a theme that was posted as working for the fascinate here: http://rootzwiki.com/topic/20081-themeblack-infinitum-aokp-milestone-4/

It works in the normal fascinate recovery but when you try and flash it in the glitch recovery it gives the error "There is not enough free RAM to work!". It is using something called "Universal Flasher Tool" when you start to flash the zip.

Is there another solution to make this work in glitch recovery or is there a flashable version of just the original AOKP m4 kernel and recovery I can use to flash to to install this theme and then change back to glitch without having to re flash the whole rom?
[Fascinate Android Development] bobloblaw1:
Odd man. I've been running this setup with ssewk2x's test kernel since he released it and I've yet to "hard lock". That includes using it as both a GPS and streaming radio in the car simultaneously and playing Dead Space on the train. Might just be differences in our SoC but that's why I put the edit in.
[Fascinate Android Development] ssewk2x:
I've looked into it a little bit and I'd like you to try something for me if you don't mind.

1. Boot into glitch recovery

2. connect to your computer and bring up an adb shell

3. in the adb shell, do: mkdir /Utmp

3a. the above command is case-sensitive, so make sure you get the U right.

4. try flashing the zip and let me know what happens. I think it might work.

Thanks :)
[Fascinate Android Development] Not_So_There:
I tried this and I still received the same error. I checked and I do see that the Utmp directory was created. It's default permissions are 777.
[Fascinate Android Development] ssewk2x:
Ok thanks. I'll dig some more.
[Fascinate Android Development] remicks:
While you are digging, u might wanna do some nandroid testing on the restore function as well. With AOKP and CNA I have restored nandroids from the newest kernels and had my system partition messed up, having system apks not fully restored (showing up with half the file size and such) and not working at all and causing random reboots to recovery as well. The weirdest thing is that it even happens on the test kernel I'm on that six forgot to include the glitch recovery in... :confused:
[Fascinate Android Development] ssewk2x:
Yeah, TK did a lot of strange-looking stuff to file system code and IO schedulers ... I can't even begin to try to get to the bottom of it. It seems stable enough for normal use, but it still has me worried a little. I think there's potential for some of the wonkiness we're seeing, but I think Tk-Glitch is gonna have to be the one to fix it for the next beta or whatever it ends up being.
[Fascinate Android Development] speedingcheetah:
Lockups

So..I am definitely having issues with playing music with the screen off and having lockups...DIDLE and Screen state are both disabled...wifi is off...

I am using Amazon Mp3 to play music files from my SD card....a 32gb Class 10 Transcend....

I have tried switching io schedulers (in NS tools)from fiops, to deadline, to sio....i still experience lockups...

Under cpu I am using, GlitchOndemand, Min cpu: 110mhz, Max cpu: 1320...Live OC 110%...

I have never done anything with logcat before...so I found a free app for it 'aLogcat"....I noticed by sorting the log by "Fatal"..that I see this at the time the lock up happened:

[03-15 09:44:12.113 1541:0x605 F/libc ]

Fatal signal 13 (SIGPIPE) at 0x0000060a (code=0)

For whatever reason...I do not see that in the full log..once I reboot from the lockup and go into the app and save the log...guessing it clears it out as the log's timestamps starts exactly after that fatal error.....but I am attaching the log cat anyway...Open in Wordpad...as it seems to preserve the formatting...

One other thing I am noticing...In CPUSpy...after the lockup and reboot...the app is reporting that 1650Mhz is a used state...but lists all 0's for time and %...It's odd because it only reports this AFTER the lockup and reboot...I know because I cleared out the stats the first time I had a lockup....played a song and check the stats..played another song and it locked up 1 min into the song..rebooted..and cpuSpy reported that step....

So it appears to me that (maybe) something is causing the cpu OC limit to go past its limit and thus lock up the phone...I know that my hardware WILL freeze at the 1400mhz step....That was the case back on cm7, the old versions of the glitch kernel (as well as the other kernels out)then on Froyo and GB...

Hope this helps...

I am posting this in both the Glitch kernel thread and the AOKP thread....because I am using both...
[Fascinate Android Development] droidstyle:
have you tried not using any live oc?
[Fascinate Android Development] speedingcheetah:
Forgot to mention..yes..tried at stock settings...no live oc..(set at 100%)...haven't touched the voltages..still locks up...even when CPU steps set to stock 100-1000mhz.
[Fascinate Android Development] ssewk2x:
That "broken pipe" thing indicates that something went away, like a file or connection it then tried to read from. Like maybe it unmounted your sdcard or something...

I started fiddling with live OC yesterday, too, and today I checked CPU spy and noticed the 1650MHz state as well. I have never seen anything like that before moving the live OC thing off 100%. I don't want my phone doing that, so back to 100% it goes.
[Fascinate Android Development] speedingcheetah:
If it unmounted the SD card while it was reading from it(playing a music file)...I suppose that could be why the music freezes and just buzzes...but would that cause the whole phone to lockup?...perhaps there is more than one thing going bonkers that is attributing to this issue....I don't recall having lockups on AOKP Build 27...and the Glitch Kernal from the OP..
[Fascinate Android Development] ssewk2x:
It's entirely possible, depending on how badly the application handles the error. If it handles it by either ignoring it and trying to read over and over again, causing an infinite loop of exceptions, then yes...and I bet that's not unlike what is going on. Whether that's the root cause of the issue or just one more symptom is another question, tho.
[Fascinate Android Development] neh4pres:
I think it is a glitch in the cpu spy app... It starts logging when you boot, then you change all the freq.when you oc.. Right after changing liveoc go and reset you cpu spy and you won't see it again until after you reboot and change your oc again.
[Fascinate Android Development] sageDieu:
wait wait wait you guys are describing exactly the issue I've had multiple times... it happens almost every time without fail if I am using wifi and gps is turned on while deep idle is enabled. I listen to music all day, usually google music streaming, and if I let the phone sleep and have DIDLE on then it won't turn back on and my music does what was described. turn off DIDLE and see if the issue goes away.

Sent from my AOKP SCH-i500
[Fascinate Android Development] speedingcheetah:
I do not have DIDLE or wifi on and it is still doing it..without fail...but not regularly...for example...I can go for an hour playing music...then it locks up...reboot...start playing song again.....not 2 min into the song..locks up...reboot..play same song again..an hour or so goes buy..no lock up...
[Fascinate Android Development] sol_671:
Same here, no DIDLE enabled and wifi is off, the lockup is random like speedingcheetah described, I noticed too that when playing music through auxiliary cable to speakers the music is not so smooth, a bit skippy when screen is off until I unlock my phone again then music starts playing normal.
[Fascinate Android Development] speedingcheetah:
CPU governers affect screen off issue

Ok..so..now I'm getting the skippy music issue(on top of the Lock-up issue)...

I switched the CPU governor from GlitchOndemand(default)...to Glitchassv2....got worse music skipping...switched to lagfree...no skipping...also on smoothass...i think Smoothass is a bit faster...going to run on that for a while and see if I get any lockups...

Also, as far as IO schedulers go...Fiops is way faster than Deadline....especially reading from sd card....

Has anyone had any lock-up issues while playing video?..(screen on)...i haven't (as of yet)...as that still is reading from the sd card, just as playing music is...but in a screen-on state....screen state seems to be the major factor here..

On that note about the screen-state...if the lock-up issue is directly realted to the screen state...have anyone had any issues while on a call..as the sceen shuts off when you hold the phone up to ur face to talk...I don't get much calls...and when I do, I usualy not on long...(except when my mother calls :eek:..she never stops talking.)....

EDIT: BTW...I randomly stumbled across a page that explained the differences among the CPU Governors...one that I actually understood...thought I would share it: http://wiki.rootzwiki.com/CPU_Frequency_Scaling
[Fascinate Android Development] sageDieu:
for skipping music try raising your minimum frequency to the 200 or 400mhz level while playing music. the skipping usually happens when the CPU goes down to 100mhz and the music thread gets low priority from being in the background or something.

Sent from my AOKP SCH-i500
[Fascinate Android Development] shag_on_e:
Is anyone having random spurts of awesomeness lately with this kernel? I've found the sweet spot with a 1.4 max, LL int volt settings, default governor/scheduler, and a small 102% push on the LiveOC. Loving it. Just another note of appreciation to Team Glitch.

~~~~There is no spoon~~~~
[Fascinate Android Development] speedingcheetah:
Well...millage varies from device to device...my hardware..no matter the settings...will fail at 1.4ghz...every time...no matter the kernel/rom...

Glad u found ur sweet spot....

As for me...continuing to use Smoothass cpu gov...no skipping music..and no lock-ups..after a bit over an hour of music...so far..so good...but a random issues..is just that ..random...we shall see if my luck holds out...
[Fascinate Android Development] sageDieu:
dude do you have like an ellipsis button on your phone or something? jeez

Sent from my AOKP SCH-i500
[Fascinate Android Development] speedingcheetah:
LOL...I am just lazy I guess...hadn't noticed my over use of that. I'll try working on that. Sorry.
[Fascinate Android Development] ssewk2x:
I've always read it as internet-speak for "I'm typing this as i think, and now i need to gather my thoughts for a moment before proceeding, but my fingers insist on doing something in the meantime ... therefore ... ellipsis!"