Related
About a month ago some of you may remember my posts that I was working on a kernel. Here is my first public release. The whole thing works at about 95% or so.
==============
The advantages I notice while using it besides the normal issues associated with Eclair are as follows:
1. Memory management has changed (has good and bad effects) Good: when you fly through 45 websites the browser does not crash as it eats memory. Bad: when you blow through 45 websites the browser will hang (easy fix hit home, and use app killer to free memory from apps you are not using) (Personally I like not losing my place as I get lost in the web, it also will prevent apps from dieing in the background when you are using multiple apps at the same time, if memory gets low enough the OS WILL KILL the offending apps). I personally found Eclair for Fascinate to handle memory available worse than this kernel, and I find this kernel handles memory more like Eclair on the Moto Droid did, and the Moto Droid had far less memory to work with.
2. UI has a faster response vs stock kernels, the kernel is also running AS scheduling vs BFQ but I updated BFQ to run as well if you want to revert.
3. Internet Connectivity appears to be faster with those apps that properly use the API. Web browsing, CheezeBurger, youtube etc all load content faster (efficiently? / Maybe related to memory management?)
Want something added to this list? Post your requests, just please be reasonable If I like the idea I will try to implement it. Remember this is for kernel features not system ROM modifications.
==============
Issues to fix (ToDo List, I am working to fix these issues / Updated 01/30/11):
1. Investigate and address bluetooth connection issues [ Confirmed that this issue does not affect everyone / or all bluetooth devices ]
2. Investigate and address remaining data connection issues (Orbot activates and test show as using tor on normal websites, tor addresses fail to connect to servers, also Orbot is unable to de-activate [Confirmed]
3. Investigate and address remaining camera crash issues [ Please zip and send in logs from /proc/kmsg, specify if you used the volume control zoom or pinch to zoom ]
4. Improve on touchscreen timing for quick flicks on the first attempt without burning up processor time.
5. Investigate and fix stutter/crash on camera zoom followed by attempt to take photo.
Notice something that should be in this list? Please make a post describing your issue, remember to include the kernel version/rom and the steps you performed to reproduce the issue.
==============
For those doubting, this IS 2.6.29.6, I personally merged the code myself, IT IS NOT 100% COMPLETE. Some drivers still need merging, and the V4L2 code is not completely converted because Fascinate uses different (updated?) V4L code (compare Fascinate's Eclair to Eclair on AOSP)
If anyone wants to help bug hunt I will forever be grateful. I would like to finish squashing bugs in this in the next 2 weeks as I really want to attempt to work on a Froyo for Fascinate. Even if it uses Eclair code to run the only RIL code we have.
I also semi-blindly fixed about 50-100 coding problems in the Eclair Kernel, varied from not returning data from a function that should have, simple void definitions that were returning when they had no data to return and no function collected it. Correcting order of operations in if statements. Declaring data types that were vague (unsigned vs signed). You will notice it compiles a lot cleaner...attempting to fix the camera code nearly kills the camera completely, I am thinking the broken code dumps variables by accident that the corrected code does not.
Edit: I wanted to share a few things every dev (some of it specific to kernels) should remember when nights are long and sleep is a half world away.
1) Keep a backup of your most recent WORKING work safe, because it is too easy to....uh oh *[email protected]$
2) If you edit the config file, remember to make clean and make mrproper before you make, otherwise your still on your original config file (a copy of the one you actually edit .config)
3) Do not put comments to the right of options in the kernel config file...apparently they will be discarded (the entire option line, not the comment, you'll see it in your compile error message logs).
4) Automate the mundane, I have a nice build environment setup, I type one line and it will make a brand new kernel from scratch (I'll be sharing that later, keep an eye on this post)
5) Work with what you have, don't wait for someone else too. Somewhere, someone is working on something better, and tomorrow it will be out.
6) Laugh...at something...anything because lets face it, you make better decisions in a good mood, in a bad mood...entire trees (code) die, either from rm -Rf /work/crap//* or a sledgehammer to the motherboard. Which brings us back to the first thing to remember, where did you put that backup...different drive I hope?
Attached is a working kernel, it will have issues using DI01 (such as no vibrations), it works great with DJ05 ROMS and maybe DL09 system roms. At this time I can not recommend a DL09 system rom with this kernel, during my initial tests it appears to drop GPS and cell data connectivity frequently resulting in having to relock on GPS satillites, and losing data connections in networked applications.
I highly recommend the setup I am running, DL09 Radio, Son Of Skywalker Blackhole v2.4 and this kernel (if you can handle the few bugs that is, it is beta).
Please feel free to post bug reports please include detailed information about the issues, I AM NOT FIXING APP PROBLEMS. Please remember to only report kernel issues and information specific to the kernel crash. If an app crashes on other kernels and not just this one please do not submit a report. This kernel is NOT setup for debug info, I will post one setup with debug turned on later. Right now, play around with it and report your results! Enjoy and have a great time :-D
GITHUB: https://github.com/sirgatez/
Edit 1: I thought I would mention that I originally started with the JT1134 kernel source from late Nov. - mid Dec. and the Samsung Fascinate stock source (from Samsung's Opensource website) then I merged in source from 2.6.29.6 from www.kernel.org and from Cyanogen's 2.6.29.6 Eclair kernel. I stopped on 2.6.29.6 instead of moving higher because of 1 reason, once you step in to 2.6.30 there are major driver changes requiring a lot of double verification and back trekking....In a few words, it is lots and lots of work, and I think that jumping from 2.6.29 to 2.6.29.6 will help transition to the 2.6.30 (Froyo?) series of kernels because then the majority of the work is in restructuring the driver code (which would likely best be done backwards, from the system .h files, to the .c handlers, down to the device drivers) from Samsung to match that in the stock 2.6.30 set. Complexity will be reduced by a measurable amount
Notes 1: Samsung's Android code has some significant differences under the hood from AOSP Android code, I have not sorted it all out yet, but it is possible that without an AOSP stock system that a full kernel update to the current AOSP code may not be possible. There is a built in virtual CD driver for what appears to be hosting the ISO built into the base Samsung system image, I have not opened the image yet but it appears to perhaps be drivers? Also it does not sleep the SD card like standard AOSP does, attempts to do so will disable the SD card from use with no ability to remount without a battery pull. (This is in 3 of 4 lines of code that AOSP had that must be commented out from the Samsung kernel for this SD issue to be prevented). For those wanting it, CIFS and NFS are compiled modules in this kernel. The current kernel is not over-clocked, and does not have voodoo. It does support both with a kernel configuration edit required for voodoo with the proper init scripts, and over-clocking requires changing just a few files and recompiling, I did neither as I wanted a true comparison to compare changes against the original stock kernel. The kernel does have the BLN notification code built in. BLN, Voodoo, and Over-clocking code are not my own creation they are pulled from their respective creators.
REMOVED ALL OLDER KERNEL INFORMATION
Update RC3 v2.2.4-VooDoo/NoVooDoo: This is a minor/major (depending who you ask) bug fix to adjust the processor throttles. Think I've got it too set to a good sweet spot now, the peaks are steep and a little harder to climb but the falls are also quicker. After turning it my phone on with it last night and about 2 hours of use I went to sleep, wake up a couple times to silence various alarms (I wake to wake up, but I want to sleep a little more, can't I do both?), and these are the numbers that setcpu reports for time in state:
1.2Ghz = 0 (Had the phone thottled to 1.0Ghz for this test, but with 1.2 on it only uses it when it needs it, might could leave it on?
1.0Ghz = 164978 (Not such a big a number as before)
0.8Ghz = 292008 (much more reasonable than before, could be a little lower)
0.6Ghz = 117672
0.4Ghz = 114250
0.2Ghz = 104715
0.1Ghz = 2965562 (This is what I was aiming for proportionally for 0.1Ghz)
Remember these times are mostly from idling, the idea was to reduce clockspeed when not in use to save some juice. The phone might take a moment to wake up from idle, but once it is going you shouldn't feel hardly any difference between this and RC2. Bootup clockspeeds from your first 3-4 minutes will almost always remain in the top tier due to applications still loading, media scanner running, etc.
Update v2.2.4-VooDoo/NoVooDoo: This is a major fix kicking us out of RC status and into actual release. Now for the menu, prepare your appetite, for the appetizer we'll be serving a much demanded voodoo color fix, and voodoo sound fixes. Followed by a main coarse of throttle tweaks, throttle shift updates (these are new they decide what the next cpu speed will be when a throttle is exceeded up or down, every kernel to my knowledge including my last used the default for a 5 slot kernel, here is a true 8 slot), and for desert a reduction in logged touch screen data from the touch screen, and an additional surprise to everyone, a reduced cpu load when using the touch screen!
Apparently the touch screen had authority to force the cpu into any slot it wants, it defaulted to slot 1 (which was 1.0Ghz for Blazed, now it's 1.2Ghz). The result of which meant that if you pressed the touch screen your cpu load catapulted up to 1Ghz for as long as you touched it even if you only held your finger in one place with no apps open. I have changed that to only go to 400Mhz, we'll see how this goes, if anything we might bump it to 600Mhz, so far besides a slightly slower response when first touch my touchscreen after leaving it alone for a long period it doesn't effect normal use from one app to another. If your processor is already at 400Mhz or higher it will not up it further. You will find this kernel will likely end up being the most battery conscious you have ever seen, once you get things moving the speed follows. If you find this kernel has a slower response than you feel it needs let me know, because when I fixed the touch screen from blasting the cpu load through the roof, it through off my throttle settings some, now they may be too conservative, report back and we'll fix them if it is a problem. Ah yes, please don't forget to tip your waiter if you enjoyed the service... [ REMOVED - Aggressive throttles not configured for use without aggressive touchscreen driver ]
Update v2.2.4R2-VooDoo/NoVooDoo: This is a minor fix to correct the choppy feeling that v2.2.4 had, the choppiness was due to aggressive throttles to fight off the excessive high speeds the touch screen forced on. This should correct those issues. Unless I have another bugfix for 2.2.4, I will be adding 1.1Ghz in the next release making it a total of 9 slots. The higher speeds still need some tweaking, if your looking to hit benchmarks please set min and max to the speed you are testing, otherwise the throttle is trying to save you power that doesn't need to be used. But for everyday use, these settings should be good
Update v2.2.5-VooDoo/NoVooDoo: Voodoo sound is still broken, anyone have the patched files I could compare to? The screen should be about 15% dimmer than it usually is on the lowest setting (and scaled up from there to 100% at max), I found the dimmest setting just too bright in the dark for my self, and hopefully it will help me save a little extra juice because I usually use my phone on the lowest brightness setting anyway. Major fix to throttles, now they are better tailored to this many slots. Slots updated to 9, 100Mhz, 200Mhz, 400Mhz, 600Mhz, 800Mhz, 1.0Ghz, 1.1Ghz, 1.2Ghz, and 1.3Ghz. Increased processor voltages (my ultra low voltage was about 25uv lower in most slots than everyone else who has a uv kernel...I was a little too aggressive on that one). Update bluetooth driver, it should remain connected now, could someone please verify this? Stability has improved alot with the higher voltages and better handling of throttling for different situations. Several other pieces of hardware discover that have authority to play with processor. I capped highest touch screen processor forced at 600Mhz (the higher I set it the faster your battery goes, default stock is 1Ghz), and all other hardware at 1Ghz (not very many requests, but this is where rouge 1.2 use came from). If you had issues before except for camera zoom or data connectivity in apps give Blazed another try. The slightly higher voltages should improve a lot of the random issues people were having. You may see an improvement in cellular signal now, 1.3Ghz is also stable, but I wouldn't run it all day either due to heat generated etc...Well I hope everyone enjoys, this should be the best release of Blazed Yet!
Update v2.2.6-VooDoo/NoVooDoo: This is a major fix for cellular signal issues many people have been having, the issue again was related to timing and the kernel modules not waiting long enough for the modem to respond before proceeding with action resulting in errors that caused a disconnect or forced a modem reset (requiring a phone reset to regain signal). I found waiting too long only slowed the entire phone down, so I opted to go with nanosecond wait times, waits that short however are active and will warm the phone up some, please report back if it becomes an issue as I am looking for a better wait device than udelay, preferable more like sleep that doesn't keep the processor busy. There is some performance stutter in the phone on the high end of internet connectivity speeds, but your not going to be losing your connection either, I'll continue to attempt to improve on this issue later on. [ REMOVED - Timing further improved in v2.2.7 ]
Update v2.2.7-VooDoo/NoVooDoo: This is a minor for that makes a major difference. Improved timing for communication with GPIO/modem this should be the end of the majority of network connection issues. It was entirely a mailman problem, put package in box, check for package, package still there? no=do other stuff/yes=...wait,repeat at package still there?, etc. The fix is put package in mailbox, wait long, check is package still there? no=do other stuff,yes=short wait and check again...Hope this helps alot of you out, I am aware the touch screen is a little slow to respond and I will be looking into that issue. This little fix should also improve usable speed over v2.2.6 because the waits are better timed.
Update v2.2.8-VooDoo/NoVooDoo: Timing is everything with electronics and this post...as promised today before 11:59pm is v2.2.8. Working Voodoo Sound v4, updates to the dpram/dpio communications again improving connection stability, if you lose your connections please report back (permanent loss requiring a restart only, fluctuations are different issue). Throttles set a little more aggressive about 5% so (helps ease on light loads), stepped up the first throttle jump from 100mhz to 400mhz (touch screen snaps back now). Dropped the 1Ghz permission for misc hardware to 400mhz if you have issues let me know, touch screen retains it's 600mhz permissions. Also screen brightness is reducible to gamma 1 brightness 10, typically reserved for battery about to fail status (I found the lowest setting just too dang bright). Enjoy everyone! I've been hammering away on this since 7am this morning and only had voodoo sound working about 9am. Thanks to JT1134 for his prebuilt kernel containing voodoo sound v2 working, adding v3 & v4 was a snap after that. Please report if you have any issues with it and remember you MUST be using the new voodoo sound app from the market.
Update v2.2.8R2-VooDoo/NoVooDoo: Another dpram timing adjustment (will lower your upload speed a little but will be more stable in operation, down speeds should be around 200KB down 44KB up on a good connection). Adjusted 1.1Ghz dividers per nemesis (not sure that it looks right, appears to get better benchmarks than 1.2 now will follow up on it). Made throttles a little more aggressive, 2.2.8 looked all over the place and having difficulty controlling processor use.
Update v2.3.0-VooDoo/NoVooDoo: Alot of work went into fixing dpram.c and multipdp.c it seems they were incompatible from the very beginning resulting in alot of ril issues and stability problems not just on my kernel but others as well, especially with nonstandard clocks and multiple slot kernel. I also added a fix to the framebuffer courtesy of JT1134 that has long since been overdue but a rare bug most probably have never seen. I fixed all the timing in dpram.c I also fixed the non-matching buffer sizes for multipdp and dpram (they talked to each other using different sized buffers...come on?!) There are still some bluetooth compatibility problems and the camera may still crash on zoomed photo, but I'd say it's 100% out of Beta! Enjoy! :-D I will be working on a Froyo kernel so stay tuned folks!
Update v2.3.0R2-VooDoo/NoVooDoo: Minor fix to help prevent dpram crash by handling and disposing of invalid commands sent to dpram, should fix seeming random lockup. [ Edit: corrected incorrect version numbers in original v2.3.0 series xda posts, thanks to s44 who caught the error, this does not affect kernel downloads, this were named correctly ]
Update v2.3.1-VooDoo/NoVooDoo: I reduced the delays in the ce147 camera driver, repairing the dpram driver resolve many of the seemingly random issues that had once plagued Blazed. Also a special treat for all you Blazed users, a new voodoo sound option that I have named "HEADPHONE_STICK" essentially the option when enabled (per boot) will force all audio directed to the external speaker to be instead directed to the headphone jack if the headphone jack has a plug in it. I find it excellent for not disturbing others around me with notifications when I would rather the phone be silent but I have headphones plugged in. Also excellent for using that awesome amp you have in combination withr you fascinate to wake you up in the morning. I will be contacting the maker of the Voodoo sound app in the market to get this option added to his application for quick and easy access. Also a major rework in the way kernel modules are loaded, all modules non-essential to booting are now stored in /system/kmodules. So if you reflash your system folder reflash your kernel or it may not boot, a quick browse will reveal what modules are kept there, I have more readily compiled and will release a separate "modules only" update.zip for those interested. By moving the modules it will allow for more options that are only available for including in the kernel boot image.
Update v2.3.1R2-VooDoo/NoVooDoo: Reverted some of the CE147 delay changes, reducing all of them caused some minor camera instabilities. EXT3/EXT4 moved back into the kernel, for some reason even with it's depends loaded ext4 doesn't load correctly as a module (resulted in broken boot on voodoo, now fixed). Also You MUST USE RED CLOCKWORKMOD TO FLASH IF USING VOODOO, you may use green clockwork only if Voodoo is NOT enabled due to the fact that some modules required for bootup are now stored on the system partition and if your using Voodoo only red clockworkmod has access to it. Also if you flash a different system or restore a backup you must reflash the kernel to ensure your modules are up to date. Also is a new file KMODULES-FULL contains all of the modules I have been compiling for Blazed thus far, several nifty ones but I have not setup any of the configs to use them, anyone versed in Linux command line can utilize them or setup scripts to use them, have a look inside the zip too see what there is to play with, request and I will add more if the module could prove useful to others. Several of the modules in FULL are also in the Kernel due to being required for startup redundancy (such as the 3D video/LCD drivers etc, which without a Android system folder, Android won't boot, nor will it boot without these modules so system seemed like a reasonable place to store them. The kernel/initramfs file is less than 6MB with Voodoo due to moving these modules to the system folder. I plan to add ClockworkMOD as soon as I have time to test it, then Blazed will also work for Recovery.
The Great Voodoo Debate: I have also been benchmarking Blazed against stock, to determine the difference Voodoo has on the kernel, so far it would appear Blazed has modifications either in the file system handling or the manipulation layers that are nearly equal to negating the speed lost to RFS's use before Voodoo or EXT4 is even brought into the equation. Just compare Stock vs Blazed (novoodoo) using 'RL Benchmarks SQLite Performance" from the market. A difference of 33.246 seconds in favor of Blazed, my preliminary results are (124.944 Seconds Blazed-NoVoodoo) (158.19 Seconds Stock) using the same exact system install less than 20 minutes apart between boots, with over 300 applications installed and several running like any other day. Based on this alone I find Quadrant is at least partially flawed at measuring proper I/O transfer timing, and I would NOT rely on it for an accurate benchmark in regards to I/O at this time until the issue is resolved by the Quadrant team. Voodoo does not produce the outlandish high scores that Quadrant makes out that it does, and Blazed is plenty fast in I/O even with RFS in use as shown by these preliminary results that any one of you can verify on your own using the "RL Benchmarks SQLite Performance" application, Voodoo does improve transfer compared to RFS in my tests but I am still putting together the results on Blazed NoVoodoo vs Blazed Voodoo. But as far as a 1800+ or 2000 score, so far my results say it just doesn't look realistic...sorry guys. On the flip side, if there is an error in my kernel causing a misread on the score you guys are welcome to help me find it and I will push the correction, but right now it looks like the issue is in how Quadrant measures I/O time, and I think non-atomic disk writes are the reason for the high scores, theoretically they would return claiming data is written to disk almost immediately when in reality it is still in memory and the kernel will write it to the disk at later time without the write time being considered as part of the benchmark (Google: write-caching, also known for providing significant performance improvements over atomic-writes).
If you appreciate Blazed and enjoy using it, please consider making a donation. Thank you for trying it out and have fun!
My initial impression after playing around with it for 15 minutes:
Seems to have given my phone new life/snappiness back that it had when I first installed super dark rom and stupidfast 1.54. My phone seemed to be bogging down lately. The internet definitely feels quicker too.
So far so good!
will try, thank you for the release.
Great work!
Sent from my Galaxy-S Fascinate
I don't want to turn you away from your work, but have you considered heading over to IRC and joining the guys working on Gingerbread? I'd assume that the more competent people working on it, the better.
Great work, the kernel seems to have given new life to my test fascinate! ADB does however appear to be dead (I got error device not found every time I tried to connect) Other than that I have no complaints, keep up the good work
That is very odd, as I have not had any issues using adb. Please reload your drivers to be safe and double check debug mode has not accidently become disabled. I wired up my fascinate just now and confirmed that ADB is working. (It was invaluable in working with the camera crashes). Also it maybe related to a conflict in the system rom vs the kernel. I personally have not have any issues with DI01 Fascinate stock, and everything worked great using DL09 radio, DJ05 system from SonOfSkywalker (BlackHole 2.4). Right now I am running DL09 Radio, DL09 System Rom from SonOfSkywalker v3, and my kernel from this post, thus far no issues. I am using Ubuntu v9.04 to test right now, and not windows to confirm that ADB is working. I will check on windows later today when I have a chance.
anyone else having an issue with bluetooth? It says "Turning On" but does not turn it on just reverts back to "off" status.
I still have DJ05 modem and on blackhole 2.3 something but updated market and swype maunally.
Camera force closes when you go to zoom in.
Sent from my SCH-I500 using XDA App
I assume disabling voodoo would be a prerequisite to installing this kernel? Though I'm curious what partition scheme are you using for this? Is it using samsung's default filesystems for /system /data etc?
EDIT: Forgot to say, this is re-gosh-darn-diculously awesome, thanks for your hard work.
wizang said:
I assume disabling voodoo would be a prerequisite to installing this kernel? Though I'm curious what partition scheme are you using for this? Is it using samsung's default filesystems for /system /data etc?
EDIT: Forgot to say, this is re-gosh-darn-diculously awesome, thanks for your hard work.
Click to expand...
Click to collapse
Yes, you MUST disable voodoo before using this kernel. I will put together a voodoo and OC flavor of this for those interested later. As of now I have only been working with non-OC and non-Voodoo in this kernel to gauge how the work changed the experience.
Edit: Oh yes, it uses the default partition scheme. It is a goal of mine to eventually change the formats of partitions (similar to voodoo) but keep the layout, it is my thought that doing so provides the largest window of compatibility between stock Samsung/VZW Roms and custom Roms. With a proper recovery, the change could be performed and backups and restores would work no matter the format of the internal media as the layout remains the same.
I tried this kernel briefly. I couldn't get my computer to recognize that the phone was plugged into it. I use my phone for tethered net access. Deal breaker for me. It would beep once like it was going to work as normal when plugging in an accessory and then beeped three more times in quick succession like the cord was being pulled.
Sent from my SCH-I500 using XDA App
bwheelies said:
I tried this kernel briefly. I couldn't get my computer to recognize that the phone was plugged into it. I use my phone for tethered net access. Deal breaker for me. It would beep once like it was going to work as normal when plugging in an accessory and then beeped three more times in quick succession like the cord was being pulled.
Sent from my SCH-I500 using XDA App
Click to expand...
Click to collapse
Yea my phone is not recognized by the computer either, even after a restart.
Naturally I double checked usb debugging and the drivers (adb connected to my white fascinate just fine and I made a jump back to Geeknik's test kernel to double check that something hadn't died in ole blacky and it registered there as well) I wonder if its just this fascinate (as it has had a laundry list of its own issues). This phone is running Superclean DJ05 completely stock and was fresh off a complete wipe and restore
bwheelies said:
I tried this kernel briefly. I couldn't get my computer to recognize that the phone was plugged into it. I use my phone for tethered net access. Deal breaker for me. It would beep once like it was going to work as normal when plugging in an accessory and then beeped three more times in quick succession like the cord was being pulled.
Sent from my SCH-I500 using XDA App
Click to expand...
Click to collapse
I can confirm that I am unable to access the phone via Samsung's drivers using Windows XP. [Added this too my list]
Wireless tether does work in case you need it, that is why I hadn't noticed this issue. Good catch!
I really like the transparency of your work. It's refreshing to actually read about the process you're working on and the way you explain it definitely makes seems like you have a good grasp of what's going on. I can never quite tell with the other devs. Anyway good luck!
FDro said:
I don't want to turn you away from your work, but have you considered heading over to IRC and joining the guys working on Gingerbread? I'd assume that the more competent people working on it, the better.
Click to expand...
Click to collapse
Agreed! If they can get GB running nobody is going to be interested in Eclair or Froyo.
I like the sound of this kernel. Imma flash it when i get home. Looking forward to seeing the OC version
SCH I500 Super Clean v.9 DJ05 Revolution 3.6 OTB oc'd lv1200 Voodoo5
2 SirGatez.
It sounds like you are pushing towards performance optimizations. Have you checked supidfast sources? I tried it before geeknik left and it was significantly faster then stock. May be you can get something from him.
I really appreciate what devs do here, cool stuff! However I do not understand why that much talent spend in vain... Every developer has his own build, mods and bug fixes. Is this real open source spirit to have so many versions? Looks like brownian motion to me.
Now, you can say that I'm free to do it on my own etc, as other devs pointed here. But, full fledged development it not for everybody by various reasons. I hope it is obvious. Would be nice to see some consolidated development! Then it will be much more easy for mere mortal to contribute to that product. We all have same phone!
Once again I do not want to upset anybody.
bendbowden said:
Great work!
Sent from my Galaxy-S Fascinate
Click to expand...
Click to collapse
Also, great write up! I will report back if I notice any bugs not mentioned above.
I'm running stock 2.1 with JIT v2 enabled and SetCPU, but i've noticed an increase in Lag lately.
Is there a minimum of free space recommended for Android to run better? I've checked a few similar threads across xda and others but i couldn't find much useful information. My main memory currently has 100 MB and the sdcard 1,14 GB of free space.
Or maybe it's a cache issue? Never cleaned cache files before, can they actually cause lag? Hopefully is not the first signs of an incoming hardware fault.
Try using CacheMate and see...
a.monteiro said:
I'm running stock 2.1 with JIT v2 enabled and SetCPU, but i've noticed an increase in Lag lately.
Is there a minimum of free space recommended for Android to run better? I've checked a few similar threads across xda and others but i couldn't find much useful information. My main memory currently has 100 MB and the sdcard 1,14 GB of free space.
Or maybe it's a cache issue? Never cleaned cache files before, can they actually cause lag? Hopefully is not the first signs of an incoming hardware fault.
Click to expand...
Click to collapse
Laggy after JIT enabled?
Normaly,the phone will just lag for the first 30s-1 min after the booting.
After that,the phone would work like a charm.
Also,remember to maintain enough ram for you phone,kill unneccessery apps.
Also,check you SetCPU settings,I used the performance and set to highest frequency(not to worried the battery,my phone usually drops 2-3% for one light)
If problem continues,just reflash and problem should be solved.
cheers,
L
I have no idea what happened, phone was very slow for the last couple of days, but out of nowhere it simply got back to it's normal behaviour.
Since JIT my x10 has been working very smoothly, hence my surprise when things started stuttering like crazy, the only thing that made it lag like that was a beta for Fennec/Firefox i've tested, but that app was already uninstalled when the problem started.
My noob knowledge of the Android OS led to a conclusion that some app in the background was misbehaving and the system itself shut it down eventually. Does it make sense? Watchdog's last alert accused Pulse News, but nothing looked out of the ordinary.
It started again yesterday, this time i've got random boots as well. Uninstalled a bunch of apps and the difference in performance was instantly noticeable. I've removed Beautiful Widgets and Lookout, but the former is more likely to be the naughty app.
too bad i've payed for that crap.
Hey guys. I am creating this thread to assist Asus in identifying the apps related to the I/O issues, and how to resolve them. The majority of the Asus beta testers are not having the same issues that some are having, so it is not easy for Asus to come up with a fix to resolve the problems such as screen flickering, SOD, browser/general lag and gaming issues. The issues seems to stem from how the I/O scheduler allocates cpu usage for each app that requires background processes, so it's harder for Asus to solve this issue as not all Primes are running the same apps/system "enhancers'. Please take a few seconds to take a screenshot and/or list all your running processes, and list the current issues that you are having with your Primes. Also, as requested, please also go to settings/apps, running. Then after grabbing a screenshot, select the "Show cached processes" in upper left corner as this information can also prove to be very useful to Asus. Once we can determine the common app(s) running for those who are having issues, the easier it would be for Asus to pinpoint the problems. Since Demandarin is in direct contact with Gary, he can forward this info to him. This will be extremely helpful.
Also, please don't post how you shouldn't have to do this, as it should work already. If you don't want to help fix your Prime, then dont post here. There are some with real issues, and there are some who while they do have issues, also like to troll just to keep the flames burning. Instead of us continually posting about the issues we are having, let's take two minutes to try and resolve them. It will also be great for those with NO issues to also post here, so we can see what processes they have running compared to those WITH issues.
For my Prime, I do not have ANY flickering, rebooting or gaming issues anymore. My running apps according to my Prime are as follows-
-Settings (of course)
-Apex launcher
-Volume+
-Rotate
-NVCPL Service (Android process)
-com.asus.keyboard(android service)
-Google Services
-Google maps
-Asus Sync
640mb of free memory
Hopefully this thread can be made into a sticky, thank you all for your time.
PM sent to Demandarin to pass on the info posted here to Asus
I read your pm. once this gets rolling, ill forward it.
demandarin said:
I read your pm. once this gets rolling, ill forward it.
Click to expand...
Click to collapse
Thanks Demandarin. This would be great for not only Asus, but all of us. Besides Assisting Asus in identifying the I/O issues, if there are a few misbehaving apps(which I bet is a BIG cause of some issues), this thread can help pinpoint it.
Here is a screenshot of all the processes/apps running in the background on my Prime.
Sent from my Transformer Prime TF201 using XDA Premium HD app
MRCANNADY said:
Hey guys. I am creating this thread to assist Asus in identifying the apps related to the I/O issues, and how to resolve them. The majority of the Asus beta testers are not having the same issues that some are having, so it is not easy for Asus to come up with a fix to resolve the problems such as screen flickering, SOD, browser/general lag and gaming issues. The issues seems to stem from how the I/O scheduler allocates cpu usage for each app that requires background processes, so it's harder for Asus to solve this issue as not all Primes are running the same apps/system "enhancers'. Please take a few seconds to take a screenshot and/or list all your running processes, and list the current issues that you are having with your Primes. Once we can determine the common app(s) running for those who are having issues, the easier it would be for Asus to pinpoint the problems. Since Demandarin is in direct contact with Gary, he can forward this info to him. This will be extremely helpful.
Also, please don't post how you shouldn't have to do this, as it should work already. If you don't want to help fix your Prime, then dont post here. There are some with real issues, and there are some who while they do have issues, also like to troll just to keep the flames burning. Instead of us continually posting about the issues we are having, let's take two minutes to try and resolve them. It will also be great for those with NO issues to also post here, so we can see what processes they have running compared to those WITH issues.
For my Prime, I do not have ANY flickering, rebooting or gaming issues anymore. My running apps according to my Prime are as follows-
-Settings (of course)
-Apex launcher
-Volume+
-Rotate
-NVCPL Service (Android process)
-com.asus.keyboard(android service)
-Google Services
-Google maps
-Asus Sync
Hopefully this thread can be made into a sticky, thank you all for your time.
Click to expand...
Click to collapse
Running process... this changes routinely depending the app being used. Also, if you go that route, you should basically ask everyone to list ALL apps that each individual has installed.
Also, you should ask for static data on background process & app that are causing each issue. As far as I understand.. with absolutely diverse behavior of Transformer Primes... it's nearly impossible to obtain such static data. That & with .28 update... it isn't easy to replicate all the issues. They happen sporadically... and randomly.
Rebelwithoutacause said:
Here is a screenshot of all the processes/apps running in the background on my Prime.
Sent from my Transformer Prime TF201 using XDA Premium HD app
Click to expand...
Click to collapse
Thank you for your assistance. Can you also list the issues that you are having?
Thanks again
shinzz said:
Running process... this changes routinely depending the app being used. Also, if you go that route, you should basically ask everyone to list ALL apps that each individual has installed.
Also, you should ask for static data on background process & app that are causing each issue. As far as I understand.. with absolutely diverse behavior of Transformer Primes... it's nearly impossible to obtain such static data. That & with .28 update... it isn't easy to replicate all the issues. They happen sporadically... and randomly.
Click to expand...
Click to collapse
They do, but their are some apps that are constantly running and/or restarting. Also, apps that are not running are not required as they are not using cpu or being allocated in the I/O Scheduler.
I understand what you are saying, but again, since Asus is not using a large beta testing group, it will help them to see what issues each poster is having, and the apps that they are currently running. This really takes not time to post, but if it helps, then we cll can enjoy our $500+ tablets right?
MRCANNADY said:
They do, but their are some apps that are constantly running and/or restarting. Also, apps that are not running are not required as they are not using cpu or being allocated in the I/O Scheduler.
I understand what you are saying, but again, since Asus is not using a large beta testing group, it will help them to see what issues each poster is having, and the apps that they are currently running. This really takes not time to post, but if it helps, then we cll can enjoy our $500+ tablets right?
Click to expand...
Click to collapse
You should ask for background process as soon as they reboot (but most likely, all the basic ones will be shared by all).
After that... background process after the initial reboot once those "few" apps that restart & changes and etc... I for one.. have no idea how you will obtain this information nor how credible it actually will be.
Also, to capture background process when "issues" do arise...
And since they are sporadic, you will need "data" from over a long stretch of period for all "data" & information on all APPs installed.
BCO, .28, not rooted, 32gb, keyboard dock
Do not have any flickering, ANR's, rebooting, plays hd movies great (mp4), about 5 hours of battery life with constant use (tablet only, no dock). I do have an occasional pause when scrolling internet (Opera Mobile).
Running apps:
Settings
Lookout
Tripit
NvCPL Service
com.asus.keyboard
Google Services
Maps
Asus Sync
Ram: 358MB used, 631MB free
dalew729 said:
BCO, .28, not rooted, 32gb, keyboard dock
Do not have any flickering, ANR's, rebooting, plays hd movies great (mp4), about 5 hours of battery life with constant use (tablet only, no dock). I do have an occasional pause when scrolling internet (Opera Mobile).
Running apps:
Settings
Lookout
Tripit
NvCPL Service
com.asus.keyboard
Google Services
Maps
Asus Sync
Ram: 358MB used, 631MB free
Click to expand...
Click to collapse
Thank you! Seeing the running processes for people with NO issues as well as people who do is great as the different processes can be compared.
Also, thing to note is that I also have the same amount of free memory as you do.
shinzz said:
You should ask for background process as soon as they reboot (but most likely, all the basic ones will be shared by all).
After that... background process after the initial reboot once those "few" apps that restart & changes and etc... I for one.. have no idea how you will obtain this information nor how credible it actually will be.
Also, to capture background process when "issues" do arise...
And since they are sporadic, you will need "data" from over a long stretch of period for all "data" & information on all APPs installed.
Click to expand...
Click to collapse
no, we need the background processes that have been running, there is no need to only request processes after a fresh reboot as the app(s) in question might not be running at that time.
While I appreciate your info, let's keep this thread on topic of what is requested. If you do not want to provide the info, then there is no need to post here. XDA is about solving issues, not just complaining about them.
Thanks
I'm not sure if you understand how I/O scheduler works. Here...
http://en.wikipedia.org/wiki/I/O_scheduling
To get some "credible" data... you should ask for "factory reset" & background process info. after that... & how it performs.
And after that, I/O performance of each "app" & how it gets prioritizes in the background process... & how it effects the system.
But with extremely diverse behavior of each Prime from BK/BC batch to whatever C batch that it is released...
Simply getting background process of one "period" isn't going to do anything.
Edit: And I won't post anymore in this thread.
Why doesn't ASUS just buy the problem Primes from us and replace them? Then they solve two birds with one stone: they have Primes to test and the people with problems get a new prime.
Of course, if it is truly just a problem with certain apps then replacing the Prime won't help the end user, other than let them know that ASUS is taking this seriously.
CurrentWidget aint worth a damn otherwise but it does do a good job of logging all applications if you set up the log correctly.
com.android.email;com.manor.currentwidget;com.android.systemui;com.android.phone;com.nuance.xt9.input;com.google.process.gapps;system;android.process.acore;com.asus.filemanager;com.android.launcher;com.nvidia.NvCPLSvc;com.dropbox.android;com.google.android.apps.maps:NetworkLocationService;com.asus.DLNA;com.asus.pcsynctool:auth;com.asus.keyboard;com.mobisystems.editor.office_registered:search;youtube.download.helper.v1;com.facebook.katana;
since .28 I have been introduced to
screen flicker
google search will just crash on occasion if I start typing on my keyboard
taskbar hopping
all can be fixed with a soft reset until whatever happens to offend my prime starts up again.
I will post a log from current widget if my prime gets the shakes again.
By the way: I have never seen an anr on any app since browser2ram
Might I suggest that looking for specific apps causing / having issues may not be the correct course of action for Asus?
Most of the research done by fairly knowledgeable end users points to a common issue - the extremely slow write performance of the main device storage.
I'm sincerely hoping that this isn't headed down the workaround road. If the I/O were fixed, the app lag issues would be fixed, and Asus would have a lot of very happy and content Prime users.
Sent from my DROID RAZR using XDA
TBacker said:
Might I suggest that looking for specific apps causing / having issues may not be the correct course of action for Asus?
Most of the research done by fairly knowledgeable end users points to a common issue - the extremely slow write performance of the main device storage.
I'm sincerely hoping that this isn't headed down the workaround road. If the I/O were fixed, the app lag issues would be fixed, and Asus would have a lot of very happy and content Prime users.
Sent from my DROID RAZR using XDA
Click to expand...
Click to collapse
I agree with the first sentence but am pretty sure its not slow write causing screen flicker
whycali said:
I agree with the first sentence but am pretty sure its not slow write causing screen flicker
Click to expand...
Click to collapse
Agreed - and that issue needs to be resolved.
The lags and hesitations, however, are affecting everyone to some degree, in a way that more heavily impacts productivity and enjoyment. I would venture that it's the biggest current issue.
Surely Asus can run read / write tests internally and track down a cause. They just need to be properly motivated....
Sent from my DROID RAZR using XDA
Its good to see initiatives to send stuff to asus, i will wait for problems to occur, and will make a screenshot when it happens. Although i dont see relation to background apps.
- One of my issues is that the stock browser is slow as hell, crashes and gives ANR messages.
The fact that CFQ IO scheduler improves the browser and the fact that browser2RAM resolves it in total , combined with the really bad benchmark results on writes to internal sd, to me makes clear that this is caused by the slow internal memory. This is a structural problem, it does not matter what background process is running.
- Further CFQ io scheduler improves overall stability, less ANR, less lockups while installing Apps. I guess ASUS is able to install an app and browse the web at one time? Also i am pretty sure that there are asus employees who have old android flagship phones to compare.
Again i see no relation to which apps are running in the background.
Asus needs to look at what people in these forums all ready achieved. Motley with his kernel, wooky with his ROM, the sqlite thread, browser2ram and so on.
There isnt an App that causes all this! Problem lies at OS/driver/hardware level!
Sent from my Transformer Prime TF201 using Tapatalk 2
Edit: removed rant/concerns as correctly identified by op
OP, as long as we are trying to identify what currently running/in memory, could we ask that people go to settings/apps, Running. Then after grabbing a screenshot, select the "Show cached processes" in upper left corner (this is new to .28, is it not?) In any event, it could prove useful, and people are right there anyway.
Here are my 2: First is running apps, second is cached processes
My issues are ANR's from Browser, SOD (None yet on .28 ) and Games that stutter and freeze (even with the OPS Destroying all activities) as I leave them, and Background Process Limit) I DO have BETTER results with Background Processes limited to 1, but search fails and a few apps will not run. I have compromised with 2 and sometimes 3 background processes for a "decent" improvement, in most cases.
Just installed TUG ROM the other day; initially it was ok. I started loading some of my apps on it; I hate having a ton of apps, so I try to keep it minimal. I can't play any full screen intense game without some horrible lag. I thought this phone would be on par with my old Droid X (1Ghz processor, 512MB RAM); it would play just about any game I wanted to with no worries. Am I missing something? Is there some special tweak or script I'm supposed to run? With the SEMC Kernel (2nd one with wifi fixes) and TUG, the phone is definitely better, but still laggy. I have autokiller set to extreme, and autorun disabling all basic apps that are auto-running at boot. I was just hoping for more performance from this phone
RadRacer said:
Just installed TUG ROM the other day; initially it was ok. I started loading some of my apps on it; I hate having a ton of apps, so I try to keep it minimal. I can't play any full screen intense game without some horrible lag. I thought this phone would be on par with my old Droid X (1Ghz processor, 512MB RAM); it would play just about any game I wanted to with no worries. Am I missing something? Is there some special tweak or script I'm supposed to run? With the SEMC Kernel (2nd one with wifi fixes) and TUG, the phone is definitely better, but still laggy. I have autokiller set to extreme, and autorun disabling all basic apps that are auto-running at boot. I was just hoping for more performance from this phone
Click to expand...
Click to collapse
Nope this phone is just too old for good games. Maybe they would work if You had no apps installed. I think playing on this device is anyway crappy because of not fully working multitouch
I'll start off by saying I basically bought the surnia Moto E 2015 (xt1526) specifically for an affordable way to play Pokemon Go. When it's working it works quite well but when in very high particle effect situations such as Battling or Evolving Pokemon it will start to get very hot and then eventually the frame rate will drop and sometimes the app will crash. I've tried a few different ROMs (Cyanogenmod 13, ResurrectionRemix, Cypher) and all seem to have the same issue. The only Kernel I've tried so far are stock and Squid Kernel.
That being said though I've had some experience tweaking and trying to optimize phones for normal app and multitasking usage but I've no experience at all trying to optimize for gaming. If anyone has gotten this particular phone to run optimally without crashes etc while gaming would you kindly suggest the Kernel, Roms and/or settings I should use for doing so? I've seen that were some good gaming ROM's for otus but those seem to have not been brought over to the surnia.
TLDR: surnia xt1526 overheats plummets in FPS and crashes while battling in Pokemon Go, any help appreciated
Update: After trying many different suggestions though I'm sure they did help out others they did not work for me. My phone's GPU was overheating up to 62 degrees sometimes in particular while many people seemed to be tweaking their CPU's mine was still overheating and crashing with those tweaks.
So this is probably a YMMV thing but what finally worked for me was installing a kernel that had some good GPU tweaks and the one I found best so far has been Inazuma R5 it actually has the GPU's lowest setting underclocked to 100mhz, with 400mhz still being the max and also makes use of adreno idler to keep the GPU cooler.
So if you've been having these issues I'd suggest opening up Kernel Adiutor after your phone starts crashing and overheating and taking note of the temperatures. If it's your GPU look for a kernel with adreno idler. If it's CPU then you can go with some of the other suggestions below.
Edit: I want to be clear that this is mainly only a problem with BATTLE after 30-60 consecutive minutes in Pokemon Go (sometimes also with mass evolution because of the heavy animation effects during evolution) So please specify, if you could, whether or not you've had a stable battling experience for extended periods of time.
Ive been using CM13 and squid kernel r16g and had been experiencing lags in pokemon go until i tried out some settings in kernel auditor. In kernel auditor under the tab low memory killer scroll down and select 'very light' and disable adaptive low memory killer(the first option in the 'low memory killer' tab) and now switch the tab to 'virtual memory' and scroll down to the last option and set the memory limit to around 460-480mb. Now under the tab 'cpu-plug' disable the intelliplug switch and there will be an option called as touch to boost, you just gotta enable that(this option is a major player in making the game to perform well).So just try this and see if this works, it worked very well for, i hope it does the same for you.
P.S. This may cause your battery to drain more as you set ur phone to perform more, So after you finish playing the game set it to default.
ASKdroid said:
Ive been using CM13 and squid kernel r16g and had been experiencing lags in pokemon go until i tried out some settings in kernel auditor. In kernel auditor under the tab low memory killer scroll down and select 'very light' and disable adaptive low memory killer(the first option in the 'low memory killer' tab) and now switch the tab to 'virtual memory' and scroll down to the last option and set the memory limit to around 460-480mb. Now under the tab 'cpu-plug' disable the intelliplug switch and there will be an option called as touch to boost, you just gotta enable that(this option is a major player in making the game to perform well).So just try this and see if this works, it worked very well for, i hope it does the same for you.
P.S. This may cause your battery to drain more as you set ur phone to perform more, So after you finish playing the game set it to default.
Click to expand...
Click to collapse
I will try this tonight thank you for your response!
Can this phone run the game fine on stock firmware? Or have you only tried it on custom roms?
andrew129260 said:
Can this phone run the game fine on stock firmware? Or have you only tried it on custom roms?
Click to expand...
Click to collapse
A friend of mine tried playing this on stock ROM, frame drops lags and crashes all the way.
Havent quite used the stock rom lately....just been flashing roms quite frequently, so can't really say abt the performance of this game in stock And yes, a must try ROM recommendation for all you guys, playing pokemon go, wud be slim rom. Flashed Slim rom yesterday and found it to be light weighted ROM compared to many other roms n that too without a custom kernel. I tried playing pokemon go while in Slim and it worked just fine without lags or crashes. The only thing is that Slim is based on AOSP/CAF so features r limited unlike other roms.
it works fine on mine phone with stock 6.0 and squid kernel, I think that your lags are caused by ram hungry apps in background
ive bought three boost phones in the last couple of weeks just for spoofing devices, all running perfect. I pushed twrp 3.0.2, official cm13, and that's it.
edit: here is the full setup i used when flashing and unlocking/rooting from my google drive:
https://drive.google.com/file/d/0Bx5gPVuLapkKc0xxZ3BfY081bEU/view?usp=sharing
iks8 said:
it works fine on mine phone with stock 6.0 and squid kernel, I think that your lags are caused by ram hungry apps in background
Click to expand...
Click to collapse
I don't know I'm not really running much in the background just Gmail and Telegram, as I'm playing more and more it seems like it starts to overheat then starts lagging after doing battles for about 20mins straight. I have to put it in front of a fan and let it cool off before I can do battles again. So I think it's just a hardware issue. Unless anyone else has been able to do battles for more than 30mins without running in to lag and crashing
civicsr2cool said:
ive bought three boost phones in the last couple of weeks just for spoofing devices, all running perfect. I pushed twrp 3.0.2, official cm13, and that's it.
edit: here is the full setup i used when flashing and unlocking/rooting from my google drive:
https://drive.google.com/file/d/0Bx5gPVuLapkKc0xxZ3BfY081bEU/view?usp=sharing
Click to expand...
Click to collapse
Have you been able to do battles for more than 30mins straight with no problems?
Zellidon said:
Have you been able to do battles for more than 30mins straight with no problems?
Click to expand...
Click to collapse
Yes. The only problem I've been having is I think my spoofer is getting kicked out do to low RAM every once in a while and I've got to reboot it. Everything else is all good. I really love these phones.
http://forum.xda-developers.com/moto-e-2015/help/guide-how-to-run-pokemon-flawlessly-t3429755
That guide should fix all the problems you are experiencing!