Related
Hi,for the past two weeks,i discovered my HTC desire (unrooted,unbranded and unlocked,on froyo) has been laging like crazy not just web browsing but the entire OS.for example,the smooth transition between each screen (Home screen and the rest) is gone.Also,accessing menus and apps tend to lag, basically everything.You can easily tell that the device is definitely buggy.
Could anyone please recommend a fix different from hard/factory reset?As I've put so much work into device i.e. customizing screens,sorting out apps,and most importantly getting all my email accounts functioning.
It would be a big shame if I have to do a complete factory reset and if that's the only solution for now,will a future software update resolve this issue (lags)? And if i decide to go ahead with the hard reset,will the device let me do automatic backup of the following details:
* Text and multimedia messages
* Settings in the Messages application
* Web bookmarks
* Keyboard dictionary
* Settings in your phone that fall under these categories:
o Wireless & networks
o Sound & display
o Location
o Applications
o Date & time
o Language & keyboard - only the Locale setting
Thanks
what have you done to it?!?!
since day 1, I had loads of apps, no lag, loads of music, movies, pictures etc.. no lag. now, counting.. counted.. 48 rows x 4 columns of apps.. = 192 apps including all the sense ones.. still NO LAG! do a factory reste and see if that works, if not, try flashing a different ROM laterz.
Are you using a task killer?
Invisible Elf said:
Are you using a task killer?
Click to expand...
Click to collapse
I used one called Advanced Task pro but uninstalled it immediately as soon as I found out 'task killers' are more damaging .
Sent from my Archos5 using XDA App
Im underclocking my desire to 700mhz and even then, the only time it lags is the first few minutes after boot....
Sent from my HTC Desire using Tapatalk
Checked RAM usage?
Hi nasimdejai!
I have a similar problem after a day or two, when I have often browsed the web, searched for something and watched youtube vids in browser.
Is the problem after a reboot gone?
Have you checked if you are running out of mem? (Install e.g. Temp+CPU V2 from market and put the widget on your homescreen)
Because in my case, there are running a few instances of the android browser which are eating up my mem and don't get killed by the process managment.
To check this, install Terminal emulator and type in ps.
When there are more processes like com.android.browser or FP_DoPlay you have the same issue like I do. (see attachments)
I kill the unwanted/older instances with the command kill 5920 (PID number from process, see 1st attachment).
You can easily tell that the device is definitely buggy.
Click to expand...
Click to collapse
There is no "Galaxy S lag" type problem/bug that affects all Desires, so I think it is your configuration/setup, not the device itself per se!
My advice to you would be to take a Nandroid backup and then factory reset, so see if this "cures" your problem. If it does, chances are you have a rogue app that is causing your problems rather than a "system" setting, so you then have two realistic options.
1. Restore your Nandroid backup and start de-installing applications until performance becomes acceptable again. If you have something like Titanium Backup, you can always backup the app+data you wish to de-install, so that you can bring it back again easily if you require.
2. Start setting your device up from scratch again.
Note that if your phone is not rooted, you won't be able to make a Nandroid backup anyway, so you'll be left with option 2 only!
Regards,
Dave
hi floyd0815,thanks for the suggestions.I've got this app that displays memory (RAM) each time i use the device for any task be it browsing,youtube vids.And I could tell that some of these tasks do eat up memory but after completing said tasks,i immediately go into the "manage application" setting,clear the cache for each process/app used and then the RAM usually goes back to the previous size.Presently i've got 71MB of RAM and execution of processes/applications usually shaves 2MB or 3MB at most,off the current memory size.Alot of people tend to have way less RAM on their devices and still have fully function phones without lags.The reason for me being a bit worried.I'll either wait for the rumoured december update or do a factory reset if the problem persists.I'll try downloading Terminal emulator.Cheers
71MB of RAM????????? My Desire usually had 200MB of ram free before i rooted! Use a task Killer. Its nessecary. those things that tell you they are not are not always true. Get a good task killer like quick process killer or such. that should solve your problem.
Hi nasimdejai!
After a fresh boot, I have got about 120mb of free mem with the browser opened, but after 1-2 days it's going down to 70-40mb and stays there. Then it's sluggish. (e.g. FolderOrganizer onscreen-folder links open slowly,...) There I first started to clean the caches and logs, but that gave only a few mb's and the system stayed slow. Then I have seen those multiple browsers in the terminal.
I don't understand, why the android-process-managment doesn't kill the old browser instances but other processes that provide widgets?!
When I kill that old instances, I have up to 160mb+ of free RAM and the system is snappy again.
Do you have Astro (file manager) installed? If so, you can open it and press menu -> Tools -> Process manger -> Processes and look for FP_DoPlay (thats the browser). There it's shown how much RAM those processes need. (look at my 1st posts 2nd attachment)
Keep me updated about your Terminal emulator result! (ps)
P.S.: I don't use a task killer for killing running processes, only if something has crashed or as list of running apps.
shockem said:
Its nessecary. those things that tell you they are not are not always true. Get a good task killer like quick process killer or such. that should solve your problem.
Click to expand...
Click to collapse
Not again!
No task killers are *not* necessary. Some people perceive some benefit from using them, but in general as long as you don't have an errant app they are most certainly not necessary!
Also - the amount of free memory you have is not an good indicator of performance! Remember than by default Android does not "swap" and just because memory is being consumed doesn't mean that CPU cycles are.
If anything, freeing up memory by killing processes can actually slow the system down because the process might not be consuming any CPU cycles but may well be required later and so keeping it in memory will actually allow it to resume far quicker than it would do otherwise.
Regards,
Dave
Hi Dave!
I am not a killer too! ;-)
But my system gets really slow after a while. (1-2 days, depending on how often I use the browser)
Before I have seen the multiple browser instances, I tried to make it faster by clearing caches and logs with no big change.
I know "the amount of free memory you have is not a good indicator of performance" but it was the only thing I noticed when the system was getting sluggish.
And as you can see in the attachments of my 1st post here, the android browser needs A LOT OF RAM (4 instances: 150mb+) and doesn't get killed by the android process managment.
PLEASE type in a terminal ps > /sdcard/ps.txt to save the output onto your sd-card and then post it here, so we can see if your system does the same! (your desire should have been runing for a while)
THX in advance!
My ps attached. Note that I hadn't used the browser this morning (last time was last night), so I started it and opened all 4 windows to different sites before running ps.
It definitely sounds to me like the Android memory management is not running correctly on your device - have you done anything to it, or set up swap etc?
Regards,
Dave
@Dave
THX for the quick response!
In your system are 2 running browser processes (and some FP_DoPlay = flash?), which could be normal, but one of them (PID 4734) is old and maybe should have been closed by the system.
Would be nice to check later again, when a task manager tells you, that there is no running browser.
And no, I haven't done anything to the memory management or something else.
Leedroid 2.2d + sdfix kernel + bright silence theme
Radio ***09.05.30_2
This also happend on PinkyROM, after that I did a full wipe.
THX
EDIT: In /system/etc/sysctl.conf is standing "vm.swappines=1", so on my system is swapping enabled?!
floyd0815 said:
n your system are 2 running browser processes (and some FP_DoPlay = flash?), which could be normal, but one of them (PID 4734) is old and maybe should have been closed by the system.
Click to expand...
Click to collapse
I wouldn't expect the system to kill a process just because it is old if there is sufficient memory available.
EDIT: In /system/etc/sysctl.conf is standing "vm.swappines=1", so on my system is swapping enabled?!
Click to expand...
Click to collapse
Have you partitioned your SD card with a swap partition?
Regards,
Dave
I wouldn't expect the system to kill a process just because it is old if there is sufficient memory available.
Click to expand...
Click to collapse
Thats true and I don't know if your sys is running out of mem, but in my case, android should close those processes. (only ~40mb left)
I also read, that the "vm.oom_kill_allocating_task=1" in the sysctl.conf means, android kills the processes with the highest mem usage, but it doesn't! (in my case)
And I haven't made a swap partition or customized the sysctl.conf. (stock from LeeDroid 2.2d) Just read, that ...swappines=1 doesn't take an effect if you haven't got swap.
But now I changed "vm.oom_kill_allocating_task=0" and rebooted.
Lets see what happens!
floyd0815 said:
Thats true and I don't know if your sys is running out of mem, but in my case, android should close those processes. (only ~40mb left)
Click to expand...
Click to collapse
40mb left is nowhere near running low on resources IMO - killing at 40mb free is just a waste of 40mb memory.
And I haven't made a swap partition or customized the sysctl.conf. (stock from LeeDroid 2.2d) Just read, that ...swappines=1 doesn't take an effect if you haven't got swap.
Click to expand...
Click to collapse
I don't have a sysctl.conf file at all, so "stock" isn't always stock!
Regards,
Dave
T
foxmeister said:
40mb left is nowhere near running low on resources IMO - killing at 40mb free is just a waste of 40mb memory.
Click to expand...
Click to collapse
But I see the android process manager working to free RAM, kicking out apps but not the browser, which is huge?! With the sysctl.conf "vm.oom_kill_allocating_task=1"?!
I don't understand that and I don't care anymore.
I make me a script like:
Code:
#!/bin/sh
ps|grep com.android.browser|grep -v grep|awk '{print $1}'|xargs -r kill
exit
und Pasta!
I have the same problem, but i can't kill browsers through terminal emulator. Nothing happens when I enter kill *pid*
And fp_doplay isn't listed there it is listed in astro with 78mb! But i can't kill it there.
My terminal emulator ps after browser closing:
export PATH=/data/local/bin:$PATH
$ $ps
PID USER TIME COMMAND
1 0 0:03 /init
2 0 0:00 [kthreadd]
3 0 0:22 [ksoftirqd/0]
4 0 0:24 [events/0]
5 0 0:00 [khelper]
6 0 0:00 [ksmartass_up/0]
7 0 0:05 [ksmartass_down/]
8 0 0:00 [async/mgr]
9 0 50:24 [suspend]
10 0 0:00 [sync_supers]
11 0 0:01 [bdi-default]
12 0 0:01 [kblockd/0]
13 0 0:02 [kmmcd]
14 0 0:00 [bluetooth]
15 0 0:01 [smd_tty]
16 0 0:00 [qmi]
17 0 0:00 [rpcrouter]
18 0 0:00 [krpcserversd]
19 0 0:00 [microp_work_q]
20 0 0:00 [detection/0]
21 0 0:00 [button/0]
22 0 0:00 [detect/0]
23 0 0:00 [button/0]
24 0 0:06 [kswapd0]
25 0 0:00 [aio/0]
26 0 0:00 [kslowd000]
27 0 0:00 [kslowd001]
28 0 0:00 [crypto/0]
41 0 0:59 [panel_on/0]
42 0 0:00 [msm_serial_hs]
43 0 0:00 [mtdblockd]
50 0 0:00 [msm_hsusb]
51 0 0:00 [usb_mass_storag]
52 0 0:00 [gs_tty]
53 0 4:37 [synaptics_wq]
54 0 0:00 [proximity_wq]
55 0 0:01 [ls_wq/0]
56 0 0:03 [curcial_wq]
57 0 0:00 [w1_bus_master1]
58 0 0:00 [kstriped]
59 0 0:00 [kondemand/0]
60 0 0:00 [kconservative/0]
61 0 0:00 [kinteractive_up]
62 0 0:00 [knteractive_dow]
63 0 0:00 [binder]
64 0 0:00 [krfcommd]
65 0 3:33 [ds2784-battery.]
66 0 2:59 [mmcqd]
85 0 0:00 [kjournald]
129 1000 0:04 /system/bin/servicemanager
130 0 0:04 /system/bin/vold
131 0 0:04 /system/bin/netd
133 1001 0:33 /system/bin/rild
136 1002 0:01 /system/bin/dbus-daemon --syst
137 0 0:01 /system/bin/installd
138 1017 0:01 /system/bin/keystore /data/mis
139 0 0:01 /system/bin/ipd
140 1008 3:40 /system/bin/akmd
391 0 0:06 [loop0]
393 0 0:00 [kdmflush]
407 0 0:00 [kcryptd_io]
408 0 0:47 [kcryptd]
891 0 0:00 [loop1]
892 0 0:00 [kdmflush]
893 0 0:00 [kcryptd_io]
894 0 0:03 [kcryptd]
897 0 0:00 [loop2]
898 0 0:00 [kdmflush]
899 0 0:00 [kcryptd_io]
900 0 0:00 [kcryptd]
901 0 0:00 [loop3]
902 0 0:00 [kdmflush]
903 0 0:00 [kcryptd_io]
904 0 0:00 [kcryptd]
905 0 0:00 [loop4]
906 0 0:00 [kdmflush]
907 0 0:00 [kcryptd_io]
908 0 0:06 [kcryptd]
923 0 0:04 [loop6]
924 0 0:00 [kdmflush]
925 0 0:00 [kcryptd_io]
926 0 0:31 [kcryptd]
4864 0 0:00 [loop5]
4865 0 0:00 [kdmflush]
4866 0 0:00 [kcryptd_io]
4867 0 0:03 [kcryptd]
5370 0 0:00 /system/bin/debuggerd
10069 10007 0:00 com.android.browser
10074 10007 0:00 com.android.browser
11135 10014 0:36 com.htc.android.htcime
11142 10024 0:26 com.google.process.gapps
11489 10049 0:00 com.android.mms
12799 10005 0:06 com.android.htccontacts
15240 9999 0:31 com.htc.launcher
15403 10105 1:21 com.zomut.watchdoglite
15759 10010 0:07 com.htc.bgp
15988 10010 0:11 com.htc.bg
16748 10121 0:00 com.handyapps.easymoney
16769 0 0:00 [flush-179:0]
16906 10040 0:00 com.esmertec.android.jbed
16932 0 0:00 [iscan_sysioc]
16933 0 0:00 [dhcp_sysioc]
16934 0 0:00 [dhd_watchdog]
16935 0 0:00 [dhd_dpc]
16936 0 0:00 [dhd_sysioc]
16937 1007 0:00 /system/bin/logwrapper /system
16939 1010 0:00 /system/bin/wpa_supplicant -Dw
16955 1014 0:00 /system/bin/dhcpcd -ABKL eth0
17048 10088 0:00 org.peterbaldwin.client.androi
17079 10123 0:02 com.google.code.appsorganizer
17090 10067 0:02 com.android.vending
17110 10121 0:00 com.handyapps.easymoney:remote
17119 10096 0:08 com.thedeck.android.app
17136 0 0:00 [flush-31:0]
17147 10076 0:01 com.google.android.googlequick
17175 10039 0:00 com.htc.WeatherWallpaper
17198 10093 0:00 jackpal.androidterm
17205 10093 0:00 /system/bin/sh -
17210 10131 0:02 com.estrongs.android.taskmanag
17228 10093 0:00 /system/bin/sh -
17231 10093 0:00 ps
22931 1013 2:49 /system/bin/mediaserver
22932 0 0:16 zygote /bin/app_process -Xzygo
22937 1000 80:34 system_server
23034 1001 5:06 com.android.phone
23043 10085 0:25 sg.ruqqq.quickdesk
24864 10005 3:22 android.process.acore
27354 10007 0:00 com.android.browser
$
Hi Vukis!
Seems that we are the only ones having this problem, maybe because others are flashing/restarting there Desire daily so they don't have/get it.
Try:
Code:
su
kill -9 10069
kill -9 10074
...
It's an aggresive killing, but the only way I know to get rid of these "zombies".
Regards,
Floyd
It seems like once a day, my phone will become super sluggish, to the point of no longer being usable. A simple reboot will clear up the problem, but there seems to be a larger issue as this is happening every day.
ROM - Myn's Warm 2.2 RL2
Kernel - Ziggy's 10/26
Code:
# top -m 5 -n 1
User 92%, System 7%, IOW 0%, IRQ 0%
User 278 + Nice 0 + Sys 23 + Idle 0 + IOW 0 + IRQ 0 + SIRQ 0 = 301
PID CPU% S #THR VSS RSS PCY UID Name
106 98% S 67 303536K 50328K fg system system_server
76 2% S 3 2764K 304K fg compass /system/bin/akmd
21278 1% R 1 940K 416K fg root top
5 0% S 1 0K 0K fg root events/0
21238 0% S 10 165336K 20484K fg app_124 jackpal.androidterm
Is this just an issue of needing to find a new kernel or rom? I am just not sure where to start looking for the culprit.
Thanks
I was having that issue as well and even sluggishness as well when touching the screen. I ended up reading about other people having that issue on his thread with his rom so check there. Might have to do alot of reading though. But I ended up leaving and going back to Baked Snack 1.9
Globetrahter said:
I was having that issue as well and even sluggishness as well when touching the screen. I ended up reading about other people having that issue on his thread with his rom so check there. Might have to do alot of reading though. But I ended up leaving and going back to Baked Snack 1.9
Click to expand...
Click to collapse
Yeah, I tried to read through the thread, but it turned in to a clusterF pretty quickly, just like every other rom thread.
This issue only started on Thursday, the 28th, so like I said I wasn't sure how to figure out where the real problem was. Guess I'll grab some beer and start reading through Myn's thread again.
If anyone has an idea of how to track down the culprit, please let me know.
Note: I am not a developer. I am merely informing the community about this rom. I take no credit for this rom. All credits for this rom go to the Virtuous Team for such an amazing rom I will post updates as the rom gets updated
Click to expand...
Click to collapse
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Virtuous Infinity
We are pleased to announce the first release of Virtuous Infinity.This ROM is the first ever which brings the full Sense 4 experience to your favorite WVGA device.Thanks to great effort of our M10 team (including Cypis, Diamondback and Flemmard) we finally cracked the new m10 format to bring you the lastest HTC software!It is based on the 1.11.401.110 release RUU of VilleC2. We would like to give special thanks to Football for the RUU.This build currently is a X-Series release, however, it is suitable for use as a daily driver if you can live with a few minor bugs.We hope to have the ROM feature complete as soon possible. Check bellow for a full list of what is working and what is not.
Primo is the result of a collaborative, team effort by the following developers:
Flemmard
Diamondback
rmk
chrisch
mdj
seo
eViL_Dee
cypis
cjward
tbalden
Features
Based on the VilleC2 ROM (1.11.401.110).
"Full" Sense 4 resized for WVGA resolution
Tweaks app build with latest HTC SDK 15
Fully Deodexed
Ported for almost full functionality on all of supported devices
Heavily optimized for fluid performance and usability.
Market-sourced applications (Gmail, Maps, Voice, etc) automatically installed on first boot into /data/app for easy removal.
Bloatware and unnecessary applications removed.
Working
Camera
HW Acceleration
WiFi
Bluetooth
Mobile Data, SMS, MMS & Voice Calls
GPS
Sensors
Audio
USB Storgage (No 3rd Party App Required)
FM Radio
Not Working
Rosie: Folder isn't perfectly resized in landscape
Rosie: Mail widget is force closing
Weather: Weather animation in landscape mode broken
Weather :Full screen weather animation broken
Camera: Not all effects are working
You tell us
Screenshots:
Devices Supported:
Desire Z / G2
Desire HD
Inspire 4G
My Touch 4G
Desire S
Incredible S
My Touch 4G Slide
Incredible 2
Credits and Acknowledgements
Virtuous Team - For an amazing rom
Bangincrazy – For testing on MT4G
lowveld – For pointing us in the right direction to fix WiFi
Football – For the RUU
xvicdice – For music playback fix
Download Link:Bug Tracker
Since you made a link here I'll go ahead and attach some stuff.
Wifi, Data, Music Player working.
Camera works rather nicely in both default app and third party apps (instagram etc)
Attached are some screen shot with the default camera app, actually doing special effects smoothly in live preview.
It's a bit slow, especially if you're multitasking, but I'm impressed with how far they got with the camera.
When initially setting up, the setup stage can seem painfully slow (i.e.: on screen keyboard taking a sec or two to register a key, or the next/confirm dialog taking just as long).
Also wake by trackpad doesn't work even though the option is there.
The power menu requires a longer than normal long-press to activate (noticed this when getting the screenshots).
Also Infinity appears to install some apps to the SD Card via it's own custom folder (screen shot also attached).
by the way in terms of 'not all effects', I haven't come across a single effect on the list of effects that didn't seem to crash (maybe not rendered, but didn't die either).
I've switched back to EliteMod in the meantime (normal working hours have approached), I haven't had much time to test extensively how multitasking behaves (i.e.: Facebook, twitter, etc) or any graphical type of games etc.
The free ram at just bout any time is around 10MB, and uptime showing loads around 5.0 on average. The launcher can lag a bit on redraw even if you got the device clocked to 1400mhz (I believe it's more a ram issue than anything, so between supercharger V6 and swap, it might be bearable.)
---------- Post added at 08:07 AM ---------- Previous post was at 08:05 AM ----------
Oh also adb connectivity is somewhat glitchy. Devices never showed up during the initial boot, and had to mess with the power menu a couple of times (between charge only, HTC sync, and disk) to get it to show up and be able to do stuff with adb shell. Switching between various USB modes tends to be laggy.
Though one nice thing about the preview is that I did not receive a single force close or crash, just lags, and some functionality not occurring at all (i.e.: trackpad wake, FM radio).
Desire HD (ace), Desire Z (vision), Inspire 4G bugs
When phone goes into sleep you need to make a long press of the power button to wake it up
Mic doesn't work in some apps like Voice Search, Soundhound, ...
Camera isn't working on some phones
Camcorder only works with disabling sound in the video settings
I have a funny feeling it's going to turn into a bit of a 'can you port Sense Camera to XXX ICS Rom?', when it was the other way around.
FM Radio appears to be broken on both the included FM app, and the FM Radio Widget.
Though fine with SpiritFM Free Edition (which of course requests root permission).
Also the stock FM Radio app, seems to never turn off, it's always "Turning Off", and when the dialog does go away, it's still "On" (showing the icon in the status bar)
How's video recording, 720p?
The above mention of 10MB of free RAM is scaring me away from trying it though. Hell with CM7 as soon as it hits 70MB's, I feel like its lagging too much.
Tried some games with this, with supercharger, swap and 1.4ghz o/c:
Temple Run: Without swap it closes immediately, with swap its getting huge lags while playing, but when theres no lags its smoother then previous kernels.
Death Rally: Smooth as s..t.
Helicopter 3D: Smooth as f..k.
these games rather heavy considering their 3d natures. so its a good thing that this rom can run them smoothly.
generally speaking, if you make this your dd, it will drive you crazy time to time because the interface is slower then most of the roms out there. hope it will get better tho.
edit: with swap and supercharge i get 100-120 mb free ram ( at least it shows that way on the task manager)
boost3d23 said:
How's video recording, 720p?
The above mention of 10MB of free RAM is scaring me away from trying it though. Hell with CM7 as soon as it hits 70MB's, I feel like its lagging too much.
Click to expand...
Click to collapse
I find this pretty common of just about every ICS rom though (mostly cached it would seem). i.e.: free ram is wasted ram.
I'll try out the video soon as TiB does some app restores (I kind of doubt it's full 720, but maybe it'll surprise me).
---------- Post added at 10:15 AM ---------- Previous post was at 10:13 AM ----------
By the way home screen lag ain't so bad once you replace HTC Sense with the Apex Launcher (though I guess some people want the whole experience )
---------- Post added at 10:24 AM ---------- Previous post was at 10:15 AM ----------
720p is Selectable (though 1080p is also shown, obviously won't record at that though), however when you finish recording and had audio turned on, it's the forever-saving-video issue.
With audio off... did saving video for a while, and then force closed, and also a very funky buffer issue (like the screen split in half and scrolled up while recording.
The result from both are files with thumbnails with exclamation marks.
Now if I set the Video quality to 800x480 Wide (default), and audio off, it saves fine.
I respect your work.I'm about to try.
Can't even get it working it lag badly after the setup and hot reboot more than 6 times =\ anyway,good job to them as they get the camera working make me looking forward for updates XD
Sent from my Desire Z using xda app-developers app
Steven How said:
Can't even get it working it lag badly after the setup and hot reboot more than 6 times =\
Sent from my Desire Z using xda app-developers app
Click to expand...
Click to collapse
Would help if your hboot/radio/etc info was in your signature
kbeezie said:
Would help if your hboot/radio/etc info was in your signature
Click to expand...
Click to collapse
Ah...I forget abt radio and all those... does it effect the performance? And I'm using a Italian dz not g2
Sent from my Desire Z using xda app-developers app
Steven How said:
Ah...I forget abt radio and all those... does it effect the performance? And I'm using a Italian dz not g2
Sent from my Desire Z using xda app-developers app
Click to expand...
Click to collapse
As long as it's a DZ hboot it should be fine (i.e.: because the G2 hboot only has a ~400MB /system which is way too small, as this preview takes up about 96% of /system on DZ hboot).
Also depending on what rom you're coming from (i.e.: /system, etc may still be formatted as ext3 instead of ext4).
And far as radio... I don't know if this requires 26.13.04.19 or equivalent.
I guess if you can attempt a logcat output, might be helpful to someone who knows how to read those things.
kbeezie said:
As long as it's a DZ hboot it should be fine (i.e.: because the G2 hboot only has a ~400MB /system which is way too small, as this preview takes up about 96% of /system on DZ hboot).
Also depending on what rom you're coming from (i.e.: /system, etc may still be formatted as ext3 instead of ext4).
And far as radio... I don't know if this requires 26.13.04.19 or equivalent.
I guess if you can attempt a logcat output, might be helpful to someone who knows how to read those things.
Click to expand...
Click to collapse
I'm using 4ext recovery and I only left 20mb in my system space..I have restore back to ARHD 6.3.3.. until infinity become more rock stable perhaps? hope so
Sent from my Desire Z using xda app-developers app
Steven How said:
I'm using 4ext recovery and I only left 20mb in my system space..I have restore back to ARHD 6.3.3.. until infinity become more rock stable perhaps? hope so
Sent from my Desire Z using xda app-developers app
Click to expand...
Click to collapse
Hence why it NEEDs the DZ hboot
it is an alpha/preview
I enabled swap with this script http://dl.dropbox.com/u/1169731/swap_enabler.sh (ie: pop it on /data/local/tmp, chmod 775 , run it, reboot). So will see how SD-swap helps it.
I would remove some unesacary apps from the Rom to free up space
Sent from my HTC Sensation 4G using xda premium
I DO know how to enable swap lol, but it still lag badly.. after opening an app it hang there and finally reboot...lol I understand it's an alpha build so I'm not that demanding for the best performance for now
Sent from my Desire Z using xda app-developers app
evilcuber said:
I would remove some unesacary apps from the Rom to free up space
Sent from my HTC Sensation 4G using xda premium
Click to expand...
Click to collapse
Seems kind of pointless since the /system partition isn't normally going to change after installation. So removing those apps from /system doesn't really give you much benefits in 'freeing up space'. If it were on /data/app that'd be a different story, but it's pretty light in that department upon start.
Now you *could* disable some system apps (if it won't break anything) to improve some degree of performance, but then again what would be the point of testing/previewing if you didn't take it as is.
---------- Post added at 11:26 AM ---------- Previous post was at 11:15 AM ----------
So with 128MB swap on, overall it does seem smoother. However for any *new* item, there can be occasional freezes for a few seconds, in which time I'll notice the swap usage (via adb shell) will jump 20-30MB at a time, eventually once the phone has unfrozen it'll be quite smooth after that. In the last 3 freezes I've jumped from about 30MB to 60MB to 96MB.
Right now it's down to 87MB after about a minute since the last freeze (added a power widget to the desktop, taped the brightness, froze for about 15-20 seconds, changed the brightness, was smooth after that).
Also I'm not using the launcher that came with it, but rather Apex Pro and fancy widgets.
current memory usage, uptime and top:
Code:
[email protected]:/ # free
total used free shared buffers
Mem: 370420 360300 10120 0 600
-/+ buffers: 359700 10720
Swap: 131580 88232 43348
[email protected]:/ # uptime
15:25:04 up 34 min, load average: 2.69, 3.22, 3.40
Code:
Mem: 360772K used, 9648K free, 0K shrd, 1020K buff, 57144K cached
CPU0: 5.7% usr 5.7% sys 0.0% nic 88.4% idle 0.0% io 0.0% irq 0.0% sirq
Load average: 2.18 2.93 3.29 2/680 8348
PID PPID USER STAT VSZ %MEM CPU %CPU COMMAND
316 104 1000 S 425m117.2 0 2.3 com.android.systemui
209 104 1000 S 403m111.3 0 1.1 system_server
7173 104 10148 S 378m104.5 0 0.0 com.facebook.katana
421 104 10165 S 373m103.0 0 0.0 com.anddoes.launcher
467 104 10141 S 372m102.7 0 0.0 com.htc.idlescreen.shortcut
513 104 10018 S 351m 97.0 0 0.0 android.process.acore
3783 104 10017 S 334m 92.2 0 1.1 com.google.process.gapps
501 104 1001 S 329m 91.0 0 2.3 com.android.phone
760 104 9999 S 322m 89.0 0 0.0 com.htc.launcher
7847 104 1000 S 313m 86.4 0 0.0 com.android.settings:remote
1323 104 10018 S 310m 85.6 0 0.0 com.android.htccontacts
482 104 10163 S 310m 85.5 0 0.0 com.touchtype.swiftkey
7394 104 10106 S 309m 85.3 0 0.0 com.android.mms
7882 104 10017 S 301m 83.0 0 0.0 com.google.android.gsf.login
8235 104 10014 S 301m 83.0 0 0.0 com.htc.calendar
8192 104 10014 S 301m 83.0 0 0.0 com.htc.bg
8163 104 9996 S 300m 82.9 0 0.0 com.htc.notes
7862 104 10153 S 300m 82.8 0 0.0 com.google.android.googlequicksear
8214 104 10146 S 300m 82.7 0 0.0 com.dropbox.android
5568 104 10162 S 298m 82.3 0 0.0 com.mhuang.overclocking.ProfilesSe
kbeezie said:
Seems kind of pointless since the /system partition isn't normally going to change after installation. So removing those apps from /system doesn't really give you much benefits in 'freeing up space'. If it were on /data/app that'd be a different story, but it's pretty light in that department upon start.
Now you *could* disable some system apps (if it won't break anything) to improve some degree of performance, but then again what would be the point of testing/previewing if you didn't take it as is.
---------- Post added at 11:26 AM ---------- Previous post was at 11:15 AM ----------
So with 128MB swap on, overall it does seem smoother. However for any *new* item, there can be occasional freezes for a few seconds, in which time I'll notice the swap usage (via adb shell) will jump 20-30MB at a time, eventually once the phone has unfrozen it'll be quite smooth after that. In the last 3 freezes I've jumped from about 30MB to 60MB to 96MB.
Right now it's down to 87MB after about a minute since the last freeze (added a power widget to the desktop, taped the brightness, froze for about 15-20 seconds, changed the brightness, was smooth after that).
Also I'm not using the launcher that came with it, but rather Apex Pro and fancy widgets.
current memory usage, uptime and top:
Code:
[email protected]:/ # free
total used free shared buffers
Mem: 370420 360300 10120 0 600
-/+ buffers: 359700 10720
Swap: 131580 88232 43348
[email protected]:/ # uptime
15:25:04 up 34 min, load average: 2.69, 3.22, 3.40
Code:
Mem: 360772K used, 9648K free, 0K shrd, 1020K buff, 57144K cached
CPU0: 5.7% usr 5.7% sys 0.0% nic 88.4% idle 0.0% io 0.0% irq 0.0% sirq
Load average: 2.18 2.93 3.29 2/680 8348
PID PPID USER STAT VSZ %MEM CPU %CPU COMMAND
316 104 1000 S 425m117.2 0 2.3 com.android.systemui
209 104 1000 S 403m111.3 0 1.1 system_server
7173 104 10148 S 378m104.5 0 0.0 com.facebook.katana
421 104 10165 S 373m103.0 0 0.0 com.anddoes.launcher
467 104 10141 S 372m102.7 0 0.0 com.htc.idlescreen.shortcut
513 104 10018 S 351m 97.0 0 0.0 android.process.acore
3783 104 10017 S 334m 92.2 0 1.1 com.google.process.gapps
501 104 1001 S 329m 91.0 0 2.3 com.android.phone
760 104 9999 S 322m 89.0 0 0.0 com.htc.launcher
7847 104 1000 S 313m 86.4 0 0.0 com.android.settings:remote
1323 104 10018 S 310m 85.6 0 0.0 com.android.htccontacts
482 104 10163 S 310m 85.5 0 0.0 com.touchtype.swiftkey
7394 104 10106 S 309m 85.3 0 0.0 com.android.mms
7882 104 10017 S 301m 83.0 0 0.0 com.google.android.gsf.login
8235 104 10014 S 301m 83.0 0 0.0 com.htc.calendar
8192 104 10014 S 301m 83.0 0 0.0 com.htc.bg
8163 104 9996 S 300m 82.9 0 0.0 com.htc.notes
7862 104 10153 S 300m 82.8 0 0.0 com.google.android.googlequicksear
8214 104 10146 S 300m 82.7 0 0.0 com.dropbox.android
5568 104 10162 S 298m 82.3 0 0.0 com.mhuang.overclocking.ProfilesSe
Click to expand...
Click to collapse
This rom didn't come with virtuous oc?
Sent from my Desire Z using xda app-developers app
Well, one of the graphical glitches we've been experiencing with KitKat on the Galaxy Nexus is black boxes appearing in the AOSP browser and anything using the rendering engine the browser uses. I looked through some logs and found this:
Code:
E/IMGSRV (31385): :0: gralloc_module_map: Mismatching lock usage bits 0xP...FHWR=0x00000033 vs requested usage bits 0xP...FHWR=0x00000100
E/IMGSRV (31385): :0: MapBufferObtainParams: Mapping buffer failed
E/IMGSRV (31385): :0: WSEGL_GetDrawableParameters: Failed to obtain buffer parameters
E/chromium(31385): [ERROR:gl_image_egl.cc(36)] Error creating EGLImage: 12300
that file is at external/chromium_org/ui/gl/gl_image_egl.cc in my AOSP directory. This seemed to pop up in the logs whenever a black box appeared. Figuring out exactly what's causing the problem is a little over my head, I don't have much experience with OpenGL ES/EGL/whatever, but I figured some other dev might have a better idea as to what's going on.
Another thing that has been happening is complete lock-ups of the phone, some kernels requiring a battery pull to reboot and other kernels just do a reboot anyways. This is some stuff I pulled from logcats when the screen completely froze, linebreaks represent random junk being removed:
Code:
W/SurfaceFlinger( 139): setTransactionState timed out waiting for previous animation frame
### Screen is now completely frozen here.
W/ManagedEGLContext(31385): doTerminate failed: EGL count is 2 but managed count is 1
W/ManagedEGLContext(31146): doTerminate failed: EGL count is 3 but managed count is 1
E/ActivityManager( 462): ANR in com.android.systemui
E/ActivityManager( 462): PID: 588
E/ActivityManager( 462): Reason: Input dispatching timed out (Waiting because the touched window has not finished processing the input events that were previously delivered to it.)
E/ActivityManager( 462): Load: 4.38 / 2.79 / 2.31
E/ActivityManager( 462): CPU usage from 3613ms to -2817ms ago with 99% awake:
E/ActivityManager( 462): 84% 788/com.google.android.googlequicksearchbox: 0% user + 84% kernel / faults: 30 minor
E/ActivityManager( 462): 24% 462/system_server: 15% user + 9.3% kernel / faults: 1862 minor 29 major
E/ActivityManager( 462): 5.1% 151/adbd: 0.6% user + 4.5% kernel / faults: 16 minor
E/ActivityManager( 462): 3.7% 737/com.android.phone: 1.8% user + 1.8% kernel / faults: 1612 minor 5 major
E/ActivityManager( 462): 0.9% 588/com.android.systemui: 0.6% user + 0.3% kernel / faults: 662 minor 10 major
E/ActivityManager( 462): 0.9% 5101/com.google.android.apps.plus: 0.6% user + 0.2% kernel / faults: 1185 minor 2 major
E/ActivityManager( 462): 1.3% 753/com.sec.android.internal.ims: 0.6% user + 0.7% kernel / faults: 1740 minor 2 major
E/ActivityManager( 462): 1.3% 2411/kworker/1:2: 0% user + 1.3% kernel
E/ActivityManager( 462): 0.1% 768/com.android.nfc: 0.1% user + 0% kernel / faults: 2029 minor 1 major
E/ActivityManager( 462): 0.9% 5267/com.google.android.youtube: 0.3% user + 0.6% kernel / faults: 189 minor
E/ActivityManager( 462): 0.3% 31385/com.android.browser: 0.3% user + 0% kernel / faults: 240 minor
E/ActivityManager( 462): 0.7% 4410/android.process.media: 0.3% user + 0.4% kernel / faults: 45 minor
E/ActivityManager( 462): 0.7% 5180/com.google.android.music:main: 0.6% user + 0.1% kernel / faults: 9 minor
E/ActivityManager( 462): 0.6% 4053/kworker/0:0: 0% user + 0.6% kernel
E/ActivityManager( 462): 0.6% 31500/com.facebook.katana: 0.1% user + 0.4% kernel / faults: 42 minor
E/ActivityManager( 462): 0.4% 2724/com.google.process.gapps: 0.3% user + 0.1% kernel / faults: 10 minor
E/ActivityManager( 462): 0% 96/mmcqd/0: 0% user + 0% kernel
E/ActivityManager( 462): 0% 5247/com.google.android.setupwizard: 0% user + 0% kernel / faults: 9 minor
E/ActivityManager( 462): +0% 5510/logcat: 0% user + 0% kernel
E/ActivityManager( 462): 70% TOTAL: 13% user + 55% kernel + 1.5% iowait
E/ActivityManager( 462): CPU usage from 1773ms to 2326ms later:
E/ActivityManager( 462): 94% 788/com.google.android.googlequicksearchbox: 0% user + 94% kernel
E/ActivityManager( 462): 90% 788/equicksearchbox: 0% user + 90% kernel
E/ActivityManager( 462): 16% 462/system_server: 7.2% user + 9% kernel / faults: 3 minor
E/ActivityManager( 462): 5.4% 474/HeapTrimmerDaem: 5.4% user + 0% kernel
E/ActivityManager( 462): 5.4% 483/ActivityManager: 0% user + 5.4% kernel
E/ActivityManager( 462): 1.8% 567/ConnectivitySer: 1.8% user + 0% kernel
E/ActivityManager( 462): 1.8% 783/Binder_4: 1.8% user + 0% kernel
E/ActivityManager( 462): 1.8% 737/com.android.phone: 1.8% user + 0% kernel / faults: 4 minor
E/ActivityManager( 462): 1.1% 5101/com.google.android.apps.plus: 1.1% user + 0% kernel / faults: 1 minor
E/ActivityManager( 462): 1.1% 5116/Binder_2: 1.1% user + 0% kernel
E/ActivityManager( 462): 1.2% 5267/com.google.android.youtube: 1.2% user + 0% kernel / faults: 13 minor
E/ActivityManager( 462): 56% TOTAL: 7.2% user + 49% kernel
I/ActivityManager( 462): Killing 588:com.android.systemui/u0a7 (adj -12): background ANR
I/art ( 5267): Wrote stack traces to '/data/anr/traces.txt'
W/SurfaceFlinger( 139): setTransactionState timed out waiting for previous animation frame
E/ActivityManager( 462): ANR in com.android.settings (com.android.settings/.Settings)
E/ActivityManager( 462): PID: 30674
E/ActivityManager( 462): Reason: Input dispatching timed out (Waiting because the touched window has not finished processing the input events that were previously delivered to it.)
E/ActivityManager( 462): Load: 4.33 / 2.83 / 2.33
E/ActivityManager( 462): CPU usage from 7196ms to 0ms ago:
E/ActivityManager( 462): 95% 788/com.google.android.googlequicksearchbox: 0% user + 95% kernel
E/ActivityManager( 462): 8% 462/system_server: 6.8% user + 1.2% kernel / faults: 870 minor 3 major
E/ActivityManager( 462): 1.6% 5267/com.google.android.youtube: 1.1% user + 0.5% kernel / faults: 204 minor 5 major
E/ActivityManager( 462): 0.8% 31500/com.facebook.katana: 0.2% user + 0.5% kernel / faults: 28 minor 8 major
E/ActivityManager( 462): 0.5% 2724/com.google.process.gapps: 0.2% user + 0.2% kernel / faults: 5 minor
E/ActivityManager( 462): 0.5% 4410/android.process.media: 0.2% user + 0.2% kernel / faults: 24 minor
E/ActivityManager( 462): 0.4% 737/com.android.phone: 0.1% user + 0.2% kernel / faults: 7 minor
E/ActivityManager( 462): 0.4% 753/com.sec.android.internal.ims: 0.4% user + 0% kernel / faults: 156 minor
E/ActivityManager( 462): 0.4% 5180/com.google.android.music:main: 0.4% user + 0% kernel / faults: 7 minor
E/ActivityManager( 462): 0.2% 151/adbd: 0.1% user + 0.1% kernel
E/ActivityManager( 462): 0% 118/irq/206-mms_ts: 0% user + 0% kernel
E/ActivityManager( 462): 0% 136/netd: 0% user + 0% kernel / faults: 8 minor
E/ActivityManager( 462): 0.1% 4053/kworker/0:0: 0% user + 0.1% kernel
E/ActivityManager( 462): 0.1% 5101/com.google.android.apps.plus: 0% user + 0.1% kernel / faults: 3 minor
E/ActivityManager( 462): 0.1% 5247/com.google.android.setupwizard: 0.1% user + 0% kernel / faults: 4 minor
E/ActivityManager( 462): 0% 31146/ru.mail.games.android.JungleHeat: 0% user + 0% kernel / faults: 148 minor
E/ActivityManager( 462): 56% TOTAL: 5% user + 50% kernel + 1.1% iowait
E/ActivityManager( 462): CPU usage from 1729ms to 2249ms later:
E/ActivityManager( 462): 96% 788/com.google.android.googlequicksearchbox: 0% user + 96% kernel
E/ActivityManager( 462): 98% 788/equicksearchbox: 0% user + 98% kernel
E/ActivityManager( 462): 11% 462/system_server: 5.7% user + 5.7% kernel / faults: 1 minor
E/ActivityManager( 462): 5.7% 474/HeapTrimmerDaem: 5.7% user + 0% kernel
E/ActivityManager( 462): 3.8% 483/ActivityManager: 0% user + 3.8% kernel
E/ActivityManager( 462): 52% TOTAL: 2.8% user + 50% kernel
I/art ( 788): Wrote stack traces to '/data/anr/traces.txt'
I/Process ( 462): Sending signal. PID: 462 SIG: 3
I/art ( 462): Thread[3,tid=469,WaitingInMainSignalCatcherLoop,Thread*=0x414c3250,peer=0x64d4a238,"Signal Catcher"]: reacting to signal 3
I/art ( 462): Wrote stack traces to '/data/anr/traces.txt'
I/DEBUG ( 137): timed out waiting for tid=139 to die
I/DEBUG ( 137): ptrace detach from 139 failed: No such process
I/DEBUG ( 137): debuggerd committing suicide to free the zombie!
I/DEBUG ( 5560): debuggerd: Nov 15 2013 13:07:12
I/Process ( 462): Sending signal. PID: 462 SIG: 3
I/art ( 462): Thread[3,tid=469,WaitingInMainSignalCatcherLoop,Thread*=0x414c3250,peer=0x64d4a238,"Signal Catcher"]: reacting to signal 3
I/Process ( 462): Sending signal. PID: 737 SIG: 3
I/art ( 737): Thread[3,tid=744,WaitingInMainSignalCatcherLoop,Thread*=0x41557b08,peer=0x64d52a60,"Signal Catcher"]: reacting to signal 3
I/art ( 462): Wrote stack traces to '/data/anr/traces.txt'
I/art ( 737): Wrote stack traces to '/data/anr/traces.txt'
I/DEBUG ( 5560): timed out waiting for tid=139 to die
I/DEBUG ( 5560): ptrace detach from 139 failed: No such process
I/DEBUG ( 5560): debuggerd committing suicide to free the zombie!
I/DEBUG ( 5573): debuggerd: Nov 15 2013 13:07:12
I/Watchdog_N( 462): dumpKernelStacks
I/Process ( 462): Sending signal. PID: 462 SIG: 9
W/Watchdog( 462): *** WATCHDOG KILLING SYSTEM PROCESS: Blocked in monitor com.android.server.wm.WindowManagerService on foreground thread (android.fg), Blocked in handler on ActivityManager (ActivityManager)
W/Watchdog( 462): foreground thread stack trace:
W/Watchdog( 462): at com.android.server.wm.WindowManagerService.monitor(WindowManagerService.java:10695)
W/Watchdog( 462): at com.android.server.Watchdog$HandlerChecker.run(Watchdog.java:147)
W/Watchdog( 462): at android.os.Handler.handleCallback(Handler.java:733)
W/Watchdog( 462): at android.os.Handler.dispatchMessage(Handler.java:95)
W/Watchdog( 462): at android.os.Looper.loop(Looper.java:137)
W/Watchdog( 462): at android.os.HandlerThread.run(HandlerThread.java:61)
W/Watchdog( 462): ActivityManager stack trace:
W/Watchdog( 462): at android.view.SurfaceControl.nativeCreate(Native Method)
W/Watchdog( 462): at android.view.SurfaceControl.<init>(SurfaceControl.java:238)
W/Watchdog( 462): at com.android.server.wm.WindowStateAnimator.createSurfaceLocked(WindowStateAnimator.java:686)
W/Watchdog( 462): at com.android.server.wm.WindowManagerService.relayoutWindow(WindowManagerService.java:2885)
W/Watchdog( 462): at com.android.server.wm.Session.relayout(Session.java:190)
W/Watchdog( 462): at android.view.ViewRootImpl.relayoutWindow(ViewRootImpl.java:5114)
W/Watchdog( 462): at android.view.ViewRootImpl.performTraversals(ViewRootImpl.java:1412)
W/Watchdog( 462): at android.view.ViewRootImpl.doTraversal(ViewRootImpl.java:998)
W/Watchdog( 462): at android.view.ViewRootImpl$TraversalRunnable.run(ViewRootImpl.java:5582)
W/Watchdog( 462): at android.view.Choreographer$CallbackRecord.run(Choreographer.java:749)
W/Watchdog( 462): at android.view.Choreographer.doCallbacks(Choreographer.java:562)
W/Watchdog( 462): at android.view.Choreographer.doFrame(Choreographer.java:532)
W/Watchdog( 462): at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:735)
W/Watchdog( 462): at android.os.Handler.handleCallback(Handler.java:733)
W/Watchdog( 462): at android.os.Handler.dispatchMessage(Handler.java:95)
W/Watchdog( 462): at android.os.Looper.loop(Looper.java:137)
W/Watchdog( 462): at com.android.server.am.ActivityManagerService$AThread.run(ActivityManagerService.java:1848)
W/Watchdog( 462): *** GOODBYE!
### Bunch of services just die here, no more logs come in after.
Also attached is the /data/anr/traces.txt, pulled from the device once the logcats stopped coming in.
I just haven't really seen much for logs in attempts to debug this, so hopefully I've been able to get something substantial here to work with. I'm doing what I can to look through the logs, grep my AOSP directory for things in it to find where stuff is messing up, and checking the git logs to see what's changed in those files and related files since 4.3. I know there are lots of people here much more talented and skilled than myself, and I feel confident that we can all figure this stuff out before December, or at least the middle of it.
EDIT: Based on feedback from some users of my ROM, other ROMs, and some experience with the freezes myself, it seems to happen when doing one thing and then quickly trying to do something else, one thing that usually ends up triggering it for myself is unlocking the phone and then nearly immediately pressing the Dialer icon to open the Dialer app. The app doesn't even open, the screen freezes with the little glow around the icon and that's it. Looks to be related to the:
Code:
W/ManagedEGLContext(31385): doTerminate failed: EGL count is 2 but managed count is 1
part of the log. Seems an extra EGL Context is being created, but the maximum allowable is 1? Something like that? Again, not a lot of experience with OpenGL ES for me.
I'm also now attaching a couple logcats from a user of my ROM who was able to get a couple of them, @sonic147862, so thanks to him. The second logcat has some very interesting GL stuff at the bottom of it as well.
not sure if this helps but
W/ManagedEGLContext(31385): doTerminate failed: EGL count is 2 but managed count is 1
seems to come from the code in https://github.com/android/platform...gl/java/android/opengl/ManagedEGLContext.java
lines 111- 126
Code:
// Need to check how many EGL contexts are actually running,
// to compare with how many we are managing.
EGL10 egl = (EGL10) EGLContext.getEGL();
EGLDisplay display = egl.eglGetDisplay(EGL_DEFAULT_DISPLAY);
if (display == EGL_NO_DISPLAY) {
Log.w(TAG, "doTerminate failed: no display");
return false;
}
if (EGLImpl.getInitCount(display) != sActive.size()) {
Log.w(TAG, "doTerminate failed: EGL count is " + EGLImpl.getInitCount(display)
+ " but managed count is " + sActive.size());
return false;
}
so what exactly might happen if that was removed? I'm not a coding expert but it might at least get us past that particular error and show other ones that might need fixed
metalspring said:
not sure if this helps but
W/ManagedEGLContext(31385): doTerminate failed: EGL count is 2 but managed count is 1
seems to come from the code in https://github.com/android/platform...gl/java/android/opengl/ManagedEGLContext.java
lines 111- 126
Code:
// Need to check how many EGL contexts are actually running,
// to compare with how many we are managing.
EGL10 egl = (EGL10) EGLContext.getEGL();
EGLDisplay display = egl.eglGetDisplay(EGL_DEFAULT_DISPLAY);
if (display == EGL_NO_DISPLAY) {
Log.w(TAG, "doTerminate failed: no display");
return false;
}
if (EGLImpl.getInitCount(display) != sActive.size()) {
Log.w(TAG, "doTerminate failed: EGL count is " + EGLImpl.getInitCount(display)
+ " but managed count is " + sActive.size());
return false;
}
so what exactly might happen if that was removed? I'm not a coding expert but it might at least get us past that particular error and show other ones that might need fixed
Click to expand...
Click to collapse
looks like the managed EGL count does not exceed 1 at any case, so we need to find the code for setting sActive.size() .
i think removing this part of the code well lead to even further errors and freezes, but lets wait for some experienced developers for their comments.
gh0stslayer said:
looks like the managed EGL count does not exceed 1 at any case, so we need to find the code for setting sActive.size() .
i think removing this part of the code well lead to even further errors and freezes, but lets wait for some experienced developers for their comments.
Click to expand...
Click to collapse
sActive is an array.
sActive.size() depends on how may times sActive.add(this); is called.
sActive.size() increase any time a new ManagedEGLContext is created.
I think the error is not in sActive,size() being 1, but in EGLImpl.getInitCount(display) returning 2, while only 1 ManagedEGLContext has been created.
I'm trying to see where EGLImpl.getInitCount() is defined...
UPDATE: can't understand where those "native" functions can be found for GNex...Which is the correct repo for C stuff for GNex?
http://review.cyanogenmod.org/#/c/54291/
Looks like it was tracked down, Google basically had us just beta testing this stuff for them, lol.
I know this is an old thread.
But all other ROMs except for CM still experience rare freezes/reboots(even on 4.4.2 which has the Refactor gpuMemoryBuffer patch included already).
Can anyone please list out all the commits that eventually let to complete eradication of the freeze/reboot issue on CM?
Thanks Guys!
sd3993 said:
I know this is an old thread.
But all other ROMs except for CM still experience rare freezes/reboots(even on 4.4.2 which has the Refactor gpuMemoryBuffer patch included already).
Can anyone please list out all the commits that eventually let to complete eradication of the freeze/reboot issue on CM?
Thanks Guys!
Click to expand...
Click to collapse
I am also still wondering about this. This is the only thread I've found with accurate, concise information concerning the lockup->reboot behavior that almost all of the Galaxy Nexus KitKat ROMs are experiencing, except for CM. I don't want to just rip off CM's code, but I'd like to actually see if we could figure out what's going on and how it could be fixed. I've also isolated these few lines consistently from logs right before reboots occur:
Code:
E/IMGSRV ( 5116): :0: gralloc_register_buffer: Cannot register a buffer twice (ID=6)
W/GraphicBufferMapper( 5116): registerBuffer(0x46168508) failed -22 (Invalid argument)
E/GraphicBuffer( 5116): unflatten: registerBuffer failed: Invalid argument (-22)
I/ActivityManager( 454): Process com.android.musicfx (pid 5313) has died.
I/Choreographer( 5116): Skipped 35 frames! The application may be doing too much work on its main thread.
W/SurfaceFlinger( 128): setTransactionState timed out waiting for previous animation frame
I/Choreographer( 454): Skipped 294 frames! The application may be doing too much work on its main thread.
W/SurfaceFlinger( 128): setTransactionState timed out waiting for previous animation frame
baldwinguy77 said:
I am also still wondering about this. This is the only thread I've found with accurate, concise information concerning the lockup->reboot behavior that almost all of the Galaxy Nexus KitKat ROMs are experiencing, except for CM. I don't want to just rip off CM's code, but I'd like to actually see if we could figure out what's going on and how it could be fixed. I've also isolated these few lines consistently from logs right before reboots occur:
Code:
E/IMGSRV ( 5116): :0: gralloc_register_buffer: Cannot register a buffer twice (ID=6)
W/GraphicBufferMapper( 5116): registerBuffer(0x46168508) failed -22 (Invalid argument)
E/GraphicBuffer( 5116): unflatten: registerBuffer failed: Invalid argument (-22)
I/ActivityManager( 454): Process com.android.musicfx (pid 5313) has died.
I/Choreographer( 5116): Skipped 35 frames! The application may be doing too much work on its main thread.
W/SurfaceFlinger( 128): setTransactionState timed out waiting for previous animation frame
I/Choreographer( 454): Skipped 294 frames! The application may be doing too much work on its main thread.
W/SurfaceFlinger( 128): setTransactionState timed out waiting for previous animation frame
Click to expand...
Click to collapse
I've been hunting around the a little and i narrowed down the error to these two files
/frameworks/native/libs/ui/GraphicBuffer.cpp & /frameworks/native/libs/ui/GraphicBufferMapper.cpp
I've tried a few things to fix the errors but I wasn't successful.
Also I have no idea where IMGSRV or 'gralloc_register_buffer' are located? Do you know where they are?
I'm starting to wonder if the fix for the reboots is hidden somewhere completely unexpected, I know I've personally tried pulling in just about everything related to graphics in cm's frameworks_native repo and still getting the reboots on omnirom
Let's just hope the fix isn't hidden in frameworks/base (since that's one of the repos that gets the most commits)
Sent from my Galaxy Nexus using Tapatalk
metalspring said:
I'm starting to wonder if the fix for the reboots is hidden somewhere completely unexpected, I know I've personally tried pulling in just about everything related to graphics in cm's frameworks_native repo and still getting the reboots on omnirom
Let's just hope the fix isn't hidden in frameworks/base (since that's one of the repos that gets the most commits)
Sent from my Galaxy Nexus using Tapatalk
Click to expand...
Click to collapse
ill look around in there tonight..never know what cm has up their sleeve.
pattyboi:) said:
ill look around in there tonight..never know what cm has up their sleeve.
Click to expand...
Click to collapse
metalspring said:
I'm starting to wonder if the fix for the reboots is hidden somewhere completely unexpected, I know I've personally tried pulling in just about everything related to graphics in cm's frameworks_native repo and still getting the reboots on omnirom
Let's just hope the fix isn't hidden in frameworks/base (since that's one of the repos that gets the most commits)
Sent from my Galaxy Nexus using Tapatalk
Click to expand...
Click to collapse
I scanned through the commits in /harware/libhardware too and pulled almost all commits related to graphics since 1st Nov but none really helped :/
I guess it's time to take a deep breath and dive into /frameworks/base then!
---------- Post added at 11:17 AM ---------- Previous post was at 10:29 AM ----------
I took a quick look through the commits in external/chromium_org/
Here the commits I found interesting.
https://github.com/CyanogenMod/andr...mmit/18760af88a405ded53cf524d9a273b217e759807
https://github.com/CyanogenMod/andr...mmit/294545aa54ddff00ccb2f1188f231ff0ebbd9386
https://github.com/CyanogenMod/andr...mmit/e1049c797e39f4f9f9753731b3c7054473db1b45
https://github.com/CyanogenMod/andr...mmit/e31b3128a419654fd14003d6117caa8da32697e7
Plus can anyone verify that this commit https://github.com/CyanogenMod/andr...mmit/dd37648c2dfb0405e11028c264ef37200ef75001 is already included in AOSP 4.4.2? Because i THING that all reboot/freeze issues were fixed right after CM merged in this commit into 4.4 (4.4.1 and 4.4.2 weren't released back then.
Allright guys, @akash3656 built an Omnirom using metalspring's device trees and a commit found by @steven676 (http://forum.xda-developers.com/showpost.php?p=49009667&postcount=574) that really worked against graphic glitches & reboots.
I've been messing around and those gralloc buffers still got messed up but It will not make the device reboot or display weird graphical glitches. However, the affected app become choppy. just kill that thread for now
Loureiro said:
Allright guys, @akash3656 built an Omnirom using metalspring's device trees and a commit found by @steven676 (http://forum.xda-developers.com/showpost.php?p=49009667&postcount=574) that really worked against graphic glitches & reboots.
I've been messing around and those gralloc buffers still got messed up but It will not make the device reboot or display weird graphical glitches. However, the affected app become choppy. just kill that thread for now
Click to expand...
Click to collapse
No. I managed to trigger freezes even with the fix. Glitch is still there :/
Sent from my Galaxy Nexus using XDA Premium 4 mobile app
sd3993 said:
No. I managed to trigger freezes even with the fix. Glitch is still there :/
Sent from my Galaxy Nexus using XDA Premium 4 mobile app
Click to expand...
Click to collapse
Dammit. Guess I didn't stressed the rom that much. I was able too see throught adb logcat the buffers not being registered properly and all those IMGSRV errors, and none of those glitches appear.
I'll continue trying to trigger a freeze.
Loureiro said:
Dammit. Guess I didn't stressed the rom that much. I was able too see throught adb logcat the buffers not being registered properly and all those IMGSRV errors, and none of those glitches appear.
I'll continue trying to trigger a freeze.
Click to expand...
Click to collapse
Open G+. Click on a link that will open in a browser. One the page loads fully navigate a little. Then click on recents button and choose G+. You'll see the GraphicBufferMapper errors in logcat and the black boxes in G+.
Sent from my Galaxy Nexus using XDA Premium 4 mobile app
I'm trying to trigger, but without success so far.
got
E/IMGSRV gralloc_register_buffer: Cannot register a buffer twice (ID=6)
E/GraphicBuffer unflatten : registerBuffer failed: Invalid argument (-22)
and a warning related to GraphicBufferMapper
registerBuffer(...) failed -22 (Invalid argument)
But didn't saw any black boxes. I'm still jumping between aosp browser / dialer / G+ / tapatalk / settings using recents button. Those 2 erros keep showing on logcat but there's no graphical glitches nor reboots.
As far as I understood, it's normal that GraphicBuffer unflatten() still throws that error. But now with that commit, it clears the buffer when the error occurs, not poiting to anywhere else, that was causing graphic corruption.
The reboots are rare. But i don't think that error should occur at all. If i had a Nexus 4 or 5 i could test it on those. Do you know anyone with those devices? Maybe you could ask them to see id these occurs on their devices?
Sent from my Galaxy Nexus using XDA Premium 4 mobile app
sd3993 said:
Plus can anyone verify that this commit https://github.com/CyanogenMod/andr...mmit/dd37648c2dfb0405e11028c264ef37200ef75001 is already included in AOSP 4.4.2? Because i THING that all reboot/freeze issues were fixed right after CM merged in this commit into 4.4 (4.4.1 and 4.4.2 weren't released back then.
Click to expand...
Click to collapse
No, it is not part of AOSP at the moment -- that comes from Chromium sometime around the Chrome 31 development cycle, and AOSP is still on Chrome 30.
To be clear, black boxes in WebView is a different bug than the one causing device crashes and screen corruption in random apps, and the workaround for one will not fix the other -- you'll need both patches applied.
steven676 said:
No, it is not part of AOSP at the moment -- that comes from Chromium sometime around the Chrome 31 development cycle, and AOSP is still on Chrome 30.
To be clear, black boxes in WebView is a different bug than the one causing device crashes and screen corruption in random apps, and the workaround for one will not fix the other -- you'll need both patches applied.
Click to expand...
Click to collapse
Yes i figured it out with a little bit of research
BTW the patch(the one that modifies GraphicBuffer.cpp & IGraphicBufferProducer.cpp) which you linked in the Nexus S didn't work. Reboots are still an issue.
I'm still hunting around.
So I merged in this commit that other people have been talking about quite a lot and my users haven't reported any reboots yet.
Hello everyone!
I've been playing with this awesome widget for a while, mostly overlaying images to do cool clocks and stuff
However I got to a point today where, inside a fisheye I wanted to put an image of a timelapse scenery that moves horizontally based on a 24 hrs data.
For the life of my I cant figure out the code (Even though Im a master in MS Excel) to make it move to a 150 coordinate at noon, -30 at midnight with a middle point of 60 at 6 pm and am, so basically it has to go back and forth, like this:
X Y
0 -30
3 15
6 60
9 105
12 150
15 105
18 60
21 15
24 -30
Im thinking on some IFs to pull it out but I cant put it together in the code for the widget.
Please help me