FTVStick - Confirm RAM - Fire TV Q&A, Help & Troubleshooting

Hey,
My stick has been a PITA lately, slow and sluggish with SPMC.
System Info has the currant free mem dropping to 20-30mb and all I have running and installed is SPMC & Llama.
My surprise was Kodis System Info shows the device as only having 494 RAM! Never thought to check before!
I had to double check this as was sure it shipped with 1GB, Amazon site's specs confirm it.
Can someone with a UK pre-ordered FTVstick confirm this for me, I want to make sure its an issue with SPMC reading it wrong.
My FTVBox with the same SPMC reads it 19xx which would be right for the 2GB it ships with.
Im gonna stick a proper app on it later to see what it reads in case it i a SPMC issue.
TIA

adb shell cat /proc/meminfo
shows:
MemTotal: 506260 kB
MemFree: 13728 kB
Buffers: 11956 kB
Cached: 80888 kB
SwapCached: 0 kB
Active: 383912 kB
Inactive: 50468 kB
adb shell top -m 10
will show you which process uses CPU cycles

Cheers for the command!
Heres my stats:
MemTotal: 506260 kB
MemFree: 20144 kB
Buffers: 7704 kB
Cached: 42768 kB
SwapCached: 0 kB
Active: 413900 kB
Inactive: 24640 kB
Active(anon): 388796 kB
Inactive(anon): 220 kB
Active(file): 25104 kB
Inactive(file): 24420 kB
Unevictable: 684 kB
Mlocked: 0 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 0 kB
Writeback: 0 kB
AnonPages: 388776 kB
Mapped: 27840 kB
Shmem: 264 kB
Slab: 20008 kB
SReclaimable: 5052 kB
SUnreclaim: 14956 kB
KernelStack: 7864 kB
PageTables: 9200 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 253128 kB
Committed_AS: 4895500 kB
VmallocTotal: 483328 kB
VmallocUsed: 30768 kB
VmallocChunk: 416708 kB
User 1%, System 2%, IOW 0%, IRQ 0%
User 7 + Nice 0 + Sys 16 + Idle 585 + IOW 0 + IRQ 0 + SIRQ 0 = 608
PID PR CPU% S #THR VSS RSS PCY UID Name
2543 1 3% S 57 750496K 193888K bg u0_a1 com.semperpax.spmc
26012 1 0% R 1 1200K 504K shell top
29 0 0% S 1 0K 0K root ksmd
25132 1 0% S 32 498708K 19444K bg u0_a2202 com.amazon.storm.lightning.servic
s
6 0 0% S 1 0K 0K root migration/0
7 1 0% S 1 0K 0K root migration/1
8 1 0% S 1 0K 0K root kworker/1:0
9 1 0% S 1 0K 0K root ksoftirqd/1
10 1 0% S 1 0K 0K root khelper
11 1 0% S 1 0K 0K root netns
And heres my FireTV Box
MemTotal: 1993512 kB
MemFree: 595880 kB
Buffers: 104304 kB
Cached: 741024 kB
SwapCached: 0 kB
Active: 603528 kB
Inactive: 568520 kB
Active(anon): 327784 kB
Inactive(anon): 316 kB
Active(file): 275744 kB
Inactive(file): 568204 kB
This still says to me its only got 512 RAM whereas the FTVBox has 2GB?

Look up dedicated memory and shared memory to get a better explanation. The Fire TV stick shares its memory for graphics and the system. It has 1gb of memory 512mb for the system and 512mb for grapics. This is normal on systems where graphics cards do not have their own dedicated memory, so inside Kodi it will only show system memory.

porkenhimer said:
Look up dedicated memory and shared memory to get a better explanation. The Fire TV stick shares its memory for graphics and the system. It has 1gb of memory 512mb for the system and 512mb for grapics. This is normal on systems where graphics cards do not have their own dedicated memory, so inside Kodi it will only show system memory.
Click to expand...
Click to collapse
Ahh now that makes sense.
I hadn't read that it was shared memory. Cheers for that.
God I wish we had root so I could disable all the Amazon crap. If I hadnt got it for £19 I would've splashed out for the box, it just flies!

Related

Kernel source

I'm very interested in how the Desire kernel works in comparison to other devices. The kernel source, which HTC is obliged to provide under the GPL, is not currently listed at http://developer.htc.com/. I e-mailed them yesterday and this was their response:
Thank you for contacting us concerning your request fro the Kernal for the HTC Legend and the HTC Desire, My name is Chris and I will be helping you today.
I do understand how important it is to be able to use your device to the best of its capabilities. We are not withholding the kernel; we are currently working through the legal channels that we must go through to make the kernel available to you. Each product is individually under review. When the kernel is available, you will be able to find it on developer.htc.com. I apologize for any inconvenience you may have experienced, and thank you for your patience in this matter.
Click to expand...
Click to collapse
Kernel source will also help developers find root exploits (it seems as though fastboot oem unlock does not work on the Desire, or perhaps the majority of Desires). HTC has not been prompt in providing the kernel source before, while competitors like Motorola have provided it the day of launch or before, and Google has always provided kernel source of AOSP-based devices at android.git.kernel.org.
Thus, I will encourage everyone here to pester HTC about the Desire/Legend kernel source. This may help expedite the process. There is absolutely no reason HTC must go through "legal channels" in order to release the kernel source, unless they have plans to withhold the source if said legal channels deny them the privilege of releasing the source.
Also, I'm curious about the Desire's hardware. Can someone run a "cat /proc/meminfo" to see that extra 64MB of RAM? Also, run a multitouch test to see if the Desire uses a "fixed" panel.
To begin root speculation, can anyone confirm that there are OEM unlockable Desires in the wild? If so, could we downgrade production Desires to this older SPL and then unlock? HTC's latest kernels seem rock-solid, and are probably incredibly difficult to exploit: just look at the Eris.
coolbho3000 said:
I'm very interested in how the Desire kernel works in comparison to other devices. The kernel source, which HTC is obliged to provide under the GPL, is not currently listed at http://developer.htc.com/. I e-mailed them yesterday and this was their response:
Kernel source will also help developers find root exploits (it seems as though fastboot oem unlock does not work on the Desire, or perhaps the majority of Desires). HTC has not been prompt in providing the kernel source before.
Thus, I will encourage everyone here to pester HTC about the Desire/Legend kernel source. This may help expedite the process. There is absolutely no reason HTC must go through "legal channels" in order to release the kernel source, unless they have plans to withhold the source if said legal channels deny them the privilege of releasing the source.
Also, I'm curious about the Desire's hardware. Can someone run a "cat /proc/meminfo" to see that extra 64MB of RAM?
Click to expand...
Click to collapse
I think Mr. Chris does not have a clue what the hell are you talking about
those customer care guys are just there to make you feel better, in most cases they know nothing about what you really want, they just have a template that they can fill in the blanks from your request.
in the mean time, i will fire them an email too and see how they will fill in the blanks
Here's the output from meminfo below:
$ cat /proc/meminfo
MemTotal: 407900 kB
MemFree: 58380 kB
Buffers: 1224 kB
Cached: 122968 kB
SwapCached: 0 kB
Active: 242228 kB
Inactive: 80004 kB
Active(anon): 202488 kB
Inactive(anon): 0 kB
Active(file): 39740 kB
Inactive(file): 80004 kB
Unevictable: 0 kB
Mlocked: 0 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 0 kB
Writeback: 0 kB
AnonPages: 198052 kB
Mapped: 69508 kB
Slab: 8648 kB
SReclaimable: 2556 kB
SUnreclaim: 6092 kB
PageTables: 12284 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 203948 kB
Committed_AS: 4838304 kB
VmallocTotal: 466944 kB
VmallocUsed: 130264 kB
VmallocChunk: 305156 kB
s1977 said:
Here's the output from meminfo below:
$ cat /proc/meminfo
MemTotal: 407900 kB
MemFree: 58380 kB
Buffers: 1224 kB
Cached: 122968 kB
SwapCached: 0 kB
Active: 242228 kB
Inactive: 80004 kB
Active(anon): 202488 kB
Inactive(anon): 0 kB
Active(file): 39740 kB
Inactive(file): 80004 kB
Unevictable: 0 kB
Mlocked: 0 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 0 kB
Writeback: 0 kB
AnonPages: 198052 kB
Mapped: 69508 kB
Slab: 8648 kB
SReclaimable: 2556 kB
SUnreclaim: 6092 kB
PageTables: 12284 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 203948 kB
Committed_AS: 4838304 kB
VmallocTotal: 466944 kB
VmallocUsed: 130264 kB
VmallocChunk: 305156 kB
Click to expand...
Click to collapse
Thanks Looks pretty similar to the N1 after highmem, give or take 12MB or so. That 64MB is probably baseband-only after all...
Bump: Now that the HTC Desire has been rooted, it is more imperative than ever that we have the kernel source. Kernel source will allow low-level tweaks that is not possible without it!
Please bug HTC about this issue so that the Desire kernel can be modified.

SGY data dumps for comparison purposes

for some folks it may come in handy to have some data for comparison, if their local device e.g. went haywire
Code:
[FONT=Courier New][SIZE=2]
Build: GINGERBREAD.XXLA2
Bootloader: unknown
Radio: unknown
Network: Telekotz.jp
Kernel: Linux version 2.6.35.7 ([email protected]) [/SIZE][/FONT] [FONT=Courier New][SIZE=2]
(gcc version 4.4.3 (GCC) ) #31 PREEMPT Wed Jan 11 13:52:53 KST 2012
Command line: console=ttyS0,115200n8 mem=362M kmemleak=off
root=/dev/ram0 rw androidboot.console=ttyS0 [/SIZE][/FONT] [FONT=Courier New][SIZE=2]
mtdparts=bcm_uminand:[email protected](bcm_boot)ro,[email protected](loke)ro,
[email protected](loke_bk)ro,[email protected](systemdata)ro,
[email protected](modem)ro,[email protected](param_lfs)rw,
[email protected](boot)ro,[email protected](boot_backup)ro,
[email protected](system)rw,[email protected](cache)rw,
[email protected](userdata)rw,[email protected](efs)rw,
[email protected](sysparm_dep)ro,[email protected](umts_cal)ro,
[email protected](cal)r
BOOT_MODE=0 loglevel=0 BOOT_FOTA=0
DEBUG_LEVEL=LOW
------ MEMORY INFO (/proc/meminfo) ------[/SIZE][/FONT][FONT=Courier New][SIZE=2]
MemTotal: 296640 kB
MemFree: 19412 kB
Buffers: 2380 kB
Cached: 80208 kB
SwapCached: 0 kB
Active: 90208 kB
Inactive: 131512 kB
Active(anon): 57440 kB
Inactive(anon): 84872 kB
Active(file): 32768 kB
Inactive(file): 46640 kB
Unevictable: 2816 kB
Mlocked: 0 kB
HighTotal: 0 kB
HighFree: 0 kB
LowTotal: 296640 kB
LowFree: 19412 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 164 kB
Writeback: 0 kB
AnonPages: 141980 kB
Mapped: 27980 kB
Shmem: 364 kB
Slab: 21052 kB
SReclaimable: 4180 kB
SUnreclaim: 16872 kB
KernelStack: 4704 kB
PageTables: 11672 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 148320 kB
Committed_AS: 1954324 kB
VmallocTotal: 409600 kB
VmallocUsed: 36504 kB
VmallocChunk: 330360 kB[/SIZE][/FONT][SIZE=2]
[/SIZE]
How did you manage to get the info?
Sent from my GT-S5360 using xda premium
adb bugreport or similar.
it makes sense to dump some of the logfiles from internal mem. can be of some use after screw up.
adb bugreport > d:\report.txt
with MAROC-OS new SGY kernel
Build: GINGERBREAD.XXKI6
Bootloader: unknown
Radio: unknown
Network: (unknown)
Kernel: Linux version 2.6.35.7 ([email protected]) (gcc version 4.4.1 (Sourcery G++ Lite 2009q3-68) ) #36 PREEMPT Fri Mar 16 06:48:52 WET 2012
Command line: console=ttyS0,115200n8 mem=362M kmemleak=off root=/dev/ram0 rw androidboot.console=ttyS0 mtdparts=bcm_umi-nand:[email protected](bcm_boot)ro,[email protected](loke)ro,[email protected](loke_bk)ro,[email protected](systemdata)ro,[email protected](modem)ro,[email protected](param_lfs)rw,[email protected](boot)ro,[email protected](boot_backup)ro,[email protected](system)rw,[email protected](cache)rw,[email protected](userdata)rw,[email protected](efs)rw,[email protected](sysparm_dep)ro,[email protected](umts_cal)ro,[email protected](cal)r BOOT_MODE=0 loglevel=0 BOOT_FOTA=0 DEBUG_LEVEL=LOW

Normal CPU Behavior

Hi!
I recently got a new kernel, and got SetCPU. I'm using smartass. Everything seems to be working, but I just want to be sure. Here are my specs and all that (3 mins before posting:
Kernel
Linux version 2.6.35.10-ga66971c ([email protected]) (gcc version 4.4.0 (GCC) ) #2 PREEMPT Fri Jan 6 12:42:25 PHT 2012
Battery
Battery Temp: 30.9° C (87.6° F)
Battery Level: 100%
CPU
Frequency: 768000 kHz
Load Average: 7.30 7.13 6.84 1/822 13451
Processor : ARMv6-compatible processor rev 5 (v6l)
BogoMIPS : 767.55
Features : swp half thumb fastmult vfp edsp java
CPU implementer : 0x41
CPU architecture: 6TEJ
CPU variant : 0x1
CPU part : 0xb36
CPU revision : 5
Hardware : marvel
Revision : 0080
Serial : 0000000000000000
Time in State
120000 | 286047 | 3.62%
122880 | 0 | 0%
200000 | 46288 | 0.59%
245760 | 31688 | 0.4%
320000 | 3564078 | 45.15%
400000 | 235593 | 2.98%
480000 | 2990512 | 37.88%
600000 | 7580 | 0.1%
768000 | 387971 | 4.91%
787200 | 0 | 0%
806400 | 344867 | 4.37%
Memory
MemTotal: 428112 kB
MemFree: 18584 kB
Buffers: 204 kB
Cached: 107076 kB
SwapCached: 0 kB
Active: 165012 kB
Inactive: 190060 kB
Active(anon): 117796 kB
Inactive(anon): 145480 kB
Active(file): 47216 kB
Inactive(file): 44580 kB
Unevictable: 10736 kB
Mlocked: 10428 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 0 kB
Writeback: 0 kB
AnonPages: 258532 kB
Mapped: 55388 kB
Shmem: 4748 kB
Slab: 15688 kB
SReclaimable: 4080 kB
SUnreclaim: 11608 kB
KernelStack: 6576 kB
PageTables: 15612 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 214056 kB
Committed_AS: 3129444 kB
VmallocTotal: 475136 kB
VmallocUsed: 129264 kB
VmallocChunk: 296964 kB
Sent from a Time Lord, using his TARDIS.
Please post.
Sent from a Time Lord, using his TARDIS.

[DEVS & EXP-USERS ONLY] HTC One X - High I/O wait. Same issue as the N7. (confirmed)

[DEVS & EXP-USERS ONLY] HTC One X - High I/O wait. Same issue as the N7. (confirmed)
This little thread aims at getting some information about an issue I thought for months I am alone with.
Since I got my One X, stock or running custom stuff, my phone always gets sluggish far far beyond the point of being useable if I fill my /data partition with too much data (~1GB free triggers it usually), or move large files around in it (dd'ing some zeros onto it triggers it too).
No kind of rebooting, cache wiping, or anything else will fix it permanently. The lags will be back after a very short while once you experienced them.
Vodafone told me to RMA the phone (it was only software branded), but If you know me, then you know that I am lazy in these kinds of things and since I thought I was the only one and a wipe of /data fixed it every time for a short period, I didn't do it.
Yeah I know. Lazy b*tch.
A few hours ago 'Aux' who had complained about a very sluggish phone a few times already joined IRC and described his problem in more detail and I suddenly made the connection in my mind between my issue and his. He then allowed me to debug that stuff, and I came up with the exact same issue I am facing continuously:
High I/O waits while writing/reading from /data.
This thread aims at gathering intel on this issue. Do not answer here with pointless questions or howto...? stuff.
Ah btw: No, one lag after unlocking the phone is not the issue I am talking about. I mean: ~1-10 fps on the launcher, app opening takes minutes (games) & still lags like hell and downloading apps in the market is close to impossible. (~10byte p second)
So if you don't experience this, don't post logs. I am serious, I will report anyone who wastes my time on that.
To check if your phone suffers from this, run 'top'
if it shows something like this:
Code:
User 2%, System 1%, [COLOR="Red"][B]IOW 74%[/B][/COLOR], IRQ 0%
User 34 + Nice 0 + Sys 18 + Idle 263 + IOW 902 + IRQ 0 + SIRQ 1 = 1218
PID PR CPU% S #THR VSS RSS PCY UID Name
2061 0 1% S 13 471140K 32956K fg u0_a75 com.google.android.apps.reader
519 1 0% S 73 559264K 58024K fg system system_server
1035 1 0% S 20 512864K 63100K fg u0_a86 com.anddoes.launcher
2265 1 0% R 1 1132K 500K root top
[COLOR="red"][B] 105 0 0% D 1 0K 0K root mmcqd/0[/B][/COLOR]
898 1 0% S 14 483120K 60344K fg u0_a39 com.android.systemui
882 0 0% S 1 2768K 1488K wifi /system/bin/wpa_supplicant
435 0 0% S 1 0K 0K root kworker/0:2
173 1 0% S 11 29644K 10104K fg system /system/bin/surfaceflinger
[B][COLOR="red"] 123 1 0% D 1 0K 0K root jbd2/mmcblk0p15[/COLOR][/B]
879 0 0% S 1 0K 0K root irq/340-wl12xx
run 'vmstat', if it looks like this
Code:
procs memory system cpu
r b free mapped anon slab in cs flt us ni sy id wa ir
0 [COLOR="Red"]3[/COLOR] 29488 64232 261024 45956 1788 2723 0 22 0 29 99 [COLOR="red"]96[/COLOR] 0
0 [COLOR="red"]2[/COLOR] 29488 64284 261056 45952 620 905 0 1 0 4 99 [COLOR="red"]99[/COLOR] 0
1 [COLOR="red"]6[/COLOR] 29556 64284 261056 45908 472 755 0 1 0 4 99 [COLOR="red"]99[/COLOR] 0
3 [COLOR="red"]3[/COLOR] 29496 64284 261056 45908 454 680 0 0 0 1 99 [COLOR="red"]99[/COLOR] 0
0 [COLOR="red"]8[/COLOR] 29436 64284 261056 45904 462 767 0 4 0 4 99 [COLOR="red"]98[/COLOR] 0
3 [COLOR="red"]4[/COLOR] 31300 64328 261328 45840 2177 4151 0 50 0 15 99 [COLOR="red"]92[/COLOR] 0
and if 'cat /proc/fs/jbd2/mmcblk0p15-8/info' looks like this too:
Code:
cat /proc/fs/jbd2/mmcblk0p15-8/info
649 transaction, each up to 2196 blocks
average:
0ms waiting for transaction
1460ms running transaction
[B][COLOR="Red"] 16544590ms transaction was being locked[/COLOR][/B]
0ms flushing data (in ordered mode)
710ms logging transaction
603582us average transaction commit time
100 handles per transaction
7 blocks per transaction
8 logged blocks per transaction
Then you are most likely affected.
What I need from you:
Everything the above commands throw out as well as the following:
Code:
echo 1 > /proc/sys/vm/block_dump ; cat /proc/kmsg ; echo 0 > /proc/sys/vm/block_dump
(this is very spammy, you might want to add '> file.log' to the kmsg part)
-----
iostat
-----
iostat -kd 5
(keep it running for about 30 seconds)
-----
cat /proc/meminfo
-----
cat /proc/diskstats
This issue is the same I am facing on my N7. ~2.5Gb free will trigger a very poor performance on the N7 as well, so we have found a general bug in one of the used components (hardware if it's the same, the jbd journaling system, ... )
To figure out what this is exactly I need as much intel as you can gather if your device is in such a state.
I will attach my findings, this thread and all logs gathered on the already existing bug report for the N7 @google. (since it is more likely to get an answer out of them than it is to get one from HTC, sadly)
If you have a N7 facing the same issue:
Attach the logs here too, but please specify that they are from a N7.
It didn't happened to me while using my htc one x (probably because I don't fill the data partition). But I'm sure that low storage makes my nexus 7 slower and laggier(tested it). I hope you can find a solution to that. I will post logs tomorrow because I don't have time right now.
Temporary fix found:
1. Reboot to CWM.
2. Nandroid backup.
3. Factory reset/format data.
4. Nandroid restore.
And HOX back to normal! You can write lots more of data! Incredible!
It would be nice if guys with N7 tested.
So here is my commands output, hope it helps
EDIT: oups, I thought you need only these 3 commands, I didn't read your post to the end, will post the other commands tomorrow
TOP
Code:
User 5%, System 6%, IOW 0%, IRQ 0%
User 17 + Nice 0 + Sys 20 + Idle 279 + IOW 0 + IRQ 0 + SIRQ 0 = 316
PID PR CPU% S #THR VSS RSS PCY UID Name
4480 0 5% R 1 1100K 468K fg app_27 top
571 0 3% S 86 409676K 74528K fg system system_server
4200 0 2% S 14 302320K 49804K fg app_27 jackpal.androidterm
4460 0 1% S 1 0K 0K fg root kworker/0:2
897 0 0% S 13 308828K 65552K fg system com.android.systemui
39 0 0% S 1 0K 0K fg root kworker/u:1
145 0 0% S 33 192540K 9800K fg media /system/bin/mediaserver
142 0 0% S 10 33188K 13436K fg system /system/bin/surfaceflinger
885 0 0% S 1 2716K 1224K fg wifi /system/bin/wpa_supplicant
23 0 0% S 1 0K 0K fg root sync_supers
24 0 0% S 1 0K 0K fg root bdi-default
25 1 0% S 1 0K 0K fg root kblockd
26 0 0% S 1 0K 0K fg root irq/114-tegra_s
27 1 0% S 1 0K 0K fg root spi_tegra-1
28 1 0% S 1 0K 0K fg root irq/125-tegra_s
29 1 0% S 1 0K 0K fg root spi_tegra-3
30 0 0% S 1 0K 0K fg root khubd
31 1 0% S 1 0K 0K fg root irq/118-tps8003
32 1 0% S 1 0K 0K fg root tps65200
33 1 0% S 1 0K 0K fg root rpciod
34 0 0% S 1 0K 0K fg root kworker/0:1
35 1 0% S 1 0K 0K fg root cpu-tegra
36 1 0% S 1 0K 0K fg root cpu-tegra3
37 1 0% S 1 0K 0K fg root cpu-tegra3-plug
38 1 0% S 1 0K 0K fg root baseband_xmm_po
40 1 0% S 1 0K 0K fg root htc_simhotswap
41 1 0% S 1 0K 0K fg root charger_ctrl_ti
42 1 0% S 1 0K 0K fg root batt_timer
43 1 0% S 1 0K 0K fg root khungtaskd
44 1 0% S 1 0K 0K fg root kswapd0
45 1 0% S 1 0K 0K fg root fsnotify_mark
46 1 0% S 1 0K 0K fg root nfsiod
47 1 0% S 1 0K 0K fg root crypto
63 1 0% S 1 0K 0K fg root tegradc.0/a
64 1 0% S 1 0K 0K fg root tegradc.0/b
65 1 0% S 1 0K 0K fg root tegradc.0/c
66 0 0% S 1 0K 0K fg root irq/223-host_sp
67 1 0% S 1 0K 0K fg root nvhdcp1
68 1 0% S 1 0K 0K fg root tegradc.1/a
69 1 0% S 1 0K 0K fg root tegradc.1/b
70 1 0% S 1 0K 0K fg root tegradc.1/c
71 1 0% S 1 0K 0K fg root mhl_sii9234_wq
72 1 0% S 1 0K 0K fg root nct1008
73 1 0% S 1 0K 0K fg root vib
74 1 0% S 1 0K 0K fg root cable_detect
82 1 0% S 1 0K 0K fg root fsl_tegra_udc
83 1 0% S 1 0K 0K fg root f_mtp
84 1 0% S 1 0K 0K fg root file-storage
86 0 0% S 1 0K 0K fg root irq/393-synapti
87 1 0% S 1 0K 0K fg root cm3629_wq
88 1 0% D 1 0K 0K fg root kinteractiveup
89 1 0% S 1 0K 0K fg root kn3ocold
90 1 0% S 1 0K 0K fg root led
91 1 0% S 1 0K 0K fg root led_powerkey
103 1 0% S 1 0K 0K fg root binder
104 1 0% S 1 0K 0K fg root hd-audio0
105 0 0% S 1 0K 0K fg root mmcqd/0
106 0 0% S 1 0K 0K fg root irq/77-tegra_ac
107 0 0% S 1 0K 0K fg root irq/77-tegra_ac
108 1 0% S 1 0K 0K fg root detect
109 1 0% S 1 0K 0K fg root button
110 1 0% S 1 0K 0K fg root HS_PMIC_DETECT
111 1 0% S 1 0K 0K fg root HS_PMIC_BUTTON
112 1 0% S 1 0K 0K fg root HS_GPIO_DETECT
113 1 0% S 1 0K 0K fg root HS_GPIO_BUTTON
114 1 0% S 1 0K 0K fg root poke_queue
115 1 0% S 1 0K 0K fg root rq_stats
116 0 0% S 1 324K 184K fg root /sbin/ueventd
119 0 0% S 1 0K 0K fg root kworker/u:2
120 0 0% S 1 0K 0K fg root jbd2/mmcblk0p12
121 1 0% S 1 0K 0K fg root ext4-dio-unwrit
122 0 0% S 1 0K 0K fg root jbd2/mmcblk0p15
123 1 0% S 1 0K 0K fg root ext4-dio-unwrit
124 0 0% S 1 0K 0K fg root jbd2/mmcblk0p13
125 1 0% S 1 0K 0K fg root ext4-dio-unwrit
126 1 0% S 1 0K 0K fg root jbd2/mmcblk0p3-
127 1 0% S 1 0K 0K fg root ext4-dio-unwrit
128 0 0% S 1 0K 0K fg root jbd2/mmcblk0p18
129 1 0% S 1 0K 0K fg root ext4-dio-unwrit
130 1 0% S 1 0K 0K fg root jbd2/mmcblk0p19
131 1 0% S 1 0K 0K fg root ext4-dio-unwrit
Vmstat
Code:
procs memory system cpu
r b free mapped anon slab in cs flt us ni sy id wa ir
2 0 67328 119288 326872 37496 201 448 0 13 0 8 80 0 0
0 0 67328 119252 326876 37496 224 398 0 19 0 5 77 0 0
0 0 66820 119164 327452 37396 680 1076 0 21 0 15 99 0 0
0 0 66820 119180 327452 37388 188 267 0 10 0 6 86 0 0
0 0 66820 119252 327560 37388 264 517 0 14 0 16 73 0 0
0 0 66820 119252 327576 37388 185 376 0 14 0 6 81 0 0
0 0 66820 119252 327504 37388 233 400 0 15 0 6 82 0 0
1 0 68928 119252 325308 37388 205 399 0 16 0 6 80 0 0
0 0 68928 119252 325312 37388 252 614 0 12 0 11 80 0 0
0 0 68928 119252 325340 37380 245 385 0 10 0 9 81 0 0
0 0 68928 119252 325344 37376 245 408 0 8 0 7 88 0 0
3 0 68928 119252 325344 37376 256 340 0 11 0 14 78 0 0
2 0 68928 119252 325344 37376 283 411 0 10 0 13 81 0 0
0 0 68928 119252 325344 37376 227 421 0 10 0 7 85 0 0
0 0 68928 119252 325348 37376 230 399 0 12 0 11 79 0 0
0 0 68928 119252 325348 37376 201 405 0 11 0 7 85 0 0
1 0 68928 119252 325348 37376 215 392 0 10 0 10 83 0 0
0 0 68928 119252 325352 37376 221 399 0 11 0 8 83 0 0
0 0 68928 119252 325352 37376 202 378 0 12 0 7 84 0 0
0 0 68928 119252 325404 37376 253 793 1 16 0 11 75 1 0
procs memory system cpu
r b free mapped anon slab in cs flt us ni sy id wa ir
0 0 68928 119264 325372 37380 216 409 0 7 0 11 84 0 0
2 0 68928 119264 325376 37380 195 424 0 18 0 6 79 0 0
0 0 68928 119264 325376 37380 207 406 0 11 0 6 86 0 0
0 0 68928 119264 325376 37380 211 400 0 15 0 2 86 0 0
0 0 69672 118380 325484 37380 618 1261 0 38 0 16 49 0 0
2 0 69176 119304 325500 37380 328 787 0 14 0 9 77 0 0
cat /proc/fs/jbd2/mmcblk0p15-8/info
Code:
971 transaction, each up to 2196 blocks
average:
0ms waiting for transaction
370ms running transaction
0ms transaction was being locked
0ms flushing data (in ordered mode)
10ms logging transaction
6714us average transaction commit time
211 handles per transaction
5 blocks per transaction
6 logged blocks per transaction
I'll start by saying I don't have any logs to share. But I experienced the same thing after filling my phone with music. I was overseas and had a useless phone for a week.
Although you said it only seemed to affect your phone, my serial starts with HT23MW, could be from the same batch of phones?
While reading op I recall just saw someone asking JBQ on a Android Building's 4.1.2 in AOSP discussion..
any changes to address this problem?
"Nexus 7 slow when less than 3GB free "
http://productforums.google.com/forum/#!msg/mobile/loqbCbKVMWE/veH_7NAk-YgJ
- show quoted text -
Click to expand...
Click to collapse
I then went back there and follow up the link above..
By reading into the discussion thread at least we can confirmed that Google is working on it and the issue still left un-fix on JRO03S...
:angel:
Tabtoub said:
So here is my commands output, hope it helps
EDIT: oups, I thought you need only these 3 commands, I didn't read your post to the end, will post the other commands tomorrow
TOP
Vmstat
cat /proc/fs/jbd2/mmcblk0p15-8/info
Click to expand...
Click to collapse
Now look into the op, do you see the part where I say you shouldn't post here if you don't have those lags?
Now look again at the op, and check your logs with the one posted, especially the red parts. You notice something?
Thanks for posting logs with no issue present.
fizzlington said:
I'll start by saying I don't have any logs to share. But I experienced the same thing after filling my phone with music. I was overseas and had a useless phone for a week.
Although you said it only seemed to affect your phone, my serial starts with HT23MW, could be from the same batch of phones?
Click to expand...
Click to collapse
Mine is a HT23JW, though I really doubt that it is a hardware issue, or at least not solely a hardware issue.
i am not able to post logs at the moment, but wish to add my experiences to this topic.
Since getting my HOX, i had issues when transferring large amounts of data (music) to the phone. As has been said above, the phone becomes unresponsive, heats up and basically doesn't work until you either: a) wait 24-36hrs with it on charge b) refresh a rom from a nandroid
I moved to custom roms on day 2 of owning the HOX and was most disappointed to see it happen again. I have come up with this workaround to copy music to the phone:
1. mount as usb drive
2. copy as much data as you like over usb
3. after transfer, right click on the usb icon near the clock (in windows) and eject the usb drive from the computer
4. Without ending usb transfer mode on the phone, reboot it.
bizarrely, this stops the lag phase after music transfer. I've been able to do this 4 times successively now without running into the issue. I have no idea why this is???
zombiefly said:
i am not able to post logs at the moment, but wish to add my experiences to this topic.
Since getting my HOX, i had issues when transferring large amounts of data (music) to the phone. As has been said above, the phone becomes unresponsive, heats up and basically doesn't work until you either: a) wait 24-36hrs with it on charge b) refresh a rom from a nandroid
I moved to custom roms on day 2 of owning the HOX and was most disappointed to see it happen again. I have come up with this workaround to copy music to the phone:
1. mount as usb drive
2. copy as much data as you like over usb
3. after transfer, right click on the usb icon near the clock (in windows) and eject the usb drive from the computer
4. Without ending usb transfer mode on the phone, reboot it.
bizarrely, this stops the lag phase after music transfer. I've been able to do this 4 times successively now without running into the issue. I have no idea why this is???
Click to expand...
Click to collapse
I believe that's what I do when I add my music. And haven't had any lag but also.may not have enough on there.
Also, I have a Nexus 7 and TeamViewer if you want to check anything out with the N7
Sent from my EVO using Xparent SkyBlue Tapatalk 2
i had it only once in the past and it never appeared again
also i have it BIG TIME ON MY N7 although the N7 is in general extremely slow in IO
From the symptoms it looks like TRIM is not working.
With ext4 filesystems we need a mount option "discard" to enable this. Of course it's only really affective if we mount using this every time since a format.
Confirmed, it's exactly the same issue as the "Nexus 7 - issue".
{
"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"
}
I can confirm this issue, when you have <1GB of free space available. I didnt pull up terminal to see how bad the IO was, but the UI was crawling. Almost didnt need to, knew it was this issue.
Ill try and pull a log later...
I've compiled fstrim for Android and packaged it inside APK with nice GUI. You can find LagFix tool here. It is much better then backing up and formatting /data. And A LOT faster too!
Permission Denied in app ._. Lags are still available.. -_- especially while typing or something else...
Gesendet von meinem HTC One X mit Tapatalk 2
One-X-master said:
Permission Denied in app ._. Lags are still available.. -_- especially while typing or something else...
Gesendet von meinem HTC One X mit Tapatalk 2
Click to expand...
Click to collapse
Yes, I'm very sorry for not testing on Sense ROMs. I'll fix Sense issue ASAP, but it will take some time to backup and flash few ROMs.
AuxLV said:
Yes, I'm very sorry for not testing on Sense ROMs. I'll fix Sense issue ASAP, but it will take some time to backup and flash few ROMs.
Click to expand...
Click to collapse
Yes ok thank you not a big deal can wait...it's spot to see that there are such fixes ready
Gesendet von meinem HTC One X mit Tapatalk 2
One-X-master said:
Yes ok thank you not a big deal can wait...it's spot to see that there are such fixes ready
Gesendet von meinem HTC One X mit Tapatalk 2
Click to expand...
Click to collapse
In app thread AlexNone notes that chmod did not work and he pasted log. Do you experience the same issue?
I had the same problem on occasion - 100% IOWAIT and the fix was to factory reset and restore from backup. Usually happened after numerous upgrades of the same ROM (so no full wipe for a while but a lot of IO on /system). I also suspected trim/discard was not working, but I thought our phones didn't have anything like that and suspected filesystem corruption.
I also experienced FS corruption that triggered the same behaviour - fsync and journaling is there for a reason and a popular "tweak" is to disable it - bad, bad, bad for consistency...
Btw I just ran LagFix - worked fine, but I was surprised that a second pass trimmed a lot on /data again - about 50% what the first run did... subsequent runs did nothing as expected. (and it worked on a Sense ROM for me ) EDIT: looks like it didn't work after all? After reboot it just trims again the ~same amount of bytes... (nonsensical on /system)
AuxLV said:
In app thread AlexNone notes that chmod did not work and he pasted log. Do you experience the same issue?
Click to expand...
Click to collapse
The is trying to give permssions in data and then the folder where the files are right? The problem is it is always giving me permission denied because fstrim is not working or so...
Gesendet von meinem HTC One X mit Tapatalk 2

Battery drain 6.0.1

Hi, my battery works normally (48 hrs), but if i make a call from Contacts , the battery lasts about 16 hours. If reboot, the problem is solved. I have images but i can't attach them. Thank you.
Wearable-report
Build: M1D64T
Build fingerprint: 'Sony/tetra/tetra:6.0.1/M1D64T/3508863:user/release-keys'
Bootloader: TETRA_Release_118
Radio: BCM23550_14100_04
Network: (unknown)
Kernel: Linux version 3.10.17+ ([email protected]) (gcc version 4.8 (GCC) ) #1 SMP PREEMPT Thu Nov 3 17:34:00 CET 2016
------ UPTIME MMC PERF (/sys/block/mmcblk0/) ------
stat: 9856 3958 824554 26170 3360 2445 53441 11030 0 16410 37040
stat: read: 16131KB/s write: 2480KB/s
mmcblk0boot0/stat: 2 0 16 0 0 0 0 0 0 0 0
mmcblk0boot0/stat: read: 0KB/s write: 0KB/s
mmcblk0boot1/stat: 2 0 16 10 0 0 0 0 0 10 10
mmcblk0boot1/stat: read: 819KB/s write: 0KB/s
mmcblk0p24/stat: 54 1770 14592 330 0 0 0 0 0 270 320
mmcblk0p24/stat: read: 22639KB/s write: 0KB/s
mmcblk0p26/stat: 4 3 56 10 0 0 0 0 0 10 10
mmcblk0p26/stat: read: 2867KB/s write: 0KB/s
mmcblk0p30/stat: 24 72 756 0 10 2 96 0 0 0 0
mmcblk0p30/stat: read: 0KB/s write: 0KB/s
mmcblk0p31/stat: 7065 470 597274 18630 0 0 0 0 0 8850 18610
mmcblk0p31/stat: read: 16414KB/s write: 0KB/s
mmcblk0p32/stat: 2699 1643 211796 7200 2880 2443 53345 10970 0 9660 18040
mmcblk0p32/stat: read: 15061KB/s write: 2489KB/s
------ MEMORY INFO (/proc/meminfo) ------
MemTotal: 460620 kB
MemFree: 21148 kB
Buffers: 3456 kB
Cached: 159136 kB
SwapCached: 4 kB
Active: 168824 kB
Inactive: 167808 kB
Active(anon): 88600 kB
Inactive(anon): 88856 kB
Active(file): 80224 kB
Inactive(file): 78952 kB
Unevictable: 1592 kB
Mlocked: 0 kB
HighTotal: 0 kB
HighFree: 0 kB
LowTotal: 460620 kB
LowFree: 21148 kB
SwapTotal: 32764 kB
SwapFree: 30552 kB
Dirty: 16 kB
Writeback: 0 kB
AnonPages: 175696 kB
Mapped: 121496 kB
Shmem: 1788 kB
Slab: 25936 kB
SReclaimable: 11508 kB
SUnreclaim: 14428 kB
KernelStack: 5048 kB
PageTables: 10804 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 263072 kB
Committed_AS: 7012588 kB
VmallocTotal: 532480 kB
VmallocUsed: 80148 kB
VmallocChunk: 382980 kB
CmaFree: 12676 kB
CmaA(active): 0 kB
CmaA(inactive): 4 kB
CmaF(active): 16 kB
CmaF(inactive): 0 kB
CmaUnevictable: 0 kB
ContigAlloc: 3688 kB
------ CPU INFO (top -n 1 -d 1 -m 30 -t) ------
User 17%, System 22%, IOW 0%, IRQ 0%
User 37 + Nice 1 + Sys 49 + Idle 132 + IOW 0 + IRQ 0 + SIRQ 0 = 219
PID TID PR CPU% S VSS RSS PCY UID Thread Proc
1701 1701 1 9% R 2372K 932K fg shell top top
91 91 1 6% S 0K 0K fg root irq/411-2-0028
459 538 0 5% R 680248K 71456K fg system PhotonicModulat system_server
121 121 0 4% S 1036K 372K fg root ueventd /sbin/ueventd
459 488 0 3% R 680248K 71456K fg system PowerManagerSer system_server
788 788 0 2% S 401304K 29808K fg u0_a2 earable.ambient com.google.android.wearable.ambient
661 783 0 1% S 514612K 75568K fg u0_a3 SpeechThread com.google.android.wearable.app
157 174 0 1% S 35040K 4156K fg system DispSync /system/bin/surfaceflinger
459 468 0 0% R 680248K 71456K fg system HeapTaskDaemon system_server
157 184 0 0% S 35040K 4156K fg system surfaceflinger /system/bin/surfaceflinger
673 673 0 0% R 437216K 47556K fg u0_a15 rable.watchface com.sonymobile.wearable.watchface
459 478 0 0% S 680248K 71456K fg system Binder_1 system_server
459 863 0 0% S 680248K 71456K fg system Binder_A system_server
24 24 0 0% R 0K 0K fg root kworker/0:1
459 506 0 0% S 680248K 71456K fg system SensorService system_server
157 181 0 0% S 35040K 4156K fg system EventThread /system/bin/surfaceflinger
459 529 0 0% S 680248K 71456K fg system UEventObserver system_server
98 98 0 0% S 0K 0K fg root cfinteractive
160 469 0 0% S 13128K 1324K fg root netd /system/bin/netd
154 154 0 0% S 1700K 176K fg root healthd /sbin/healthd
157 531 0 0% S 35040K 4156K fg system Binder_3 /system/bin/surfaceflinger
25 25 1 0% S 0K 0K fg root kworker/1:1
8 8 1 0% S 0K 0K fg root rcu_preempt
157 173 0 0% S 35040K 4156K fg system Binder_1 /system/bin/surfaceflinger
459 459 0 0% S 680248K 71456K fg system system_server system_server
58 58 1 0% S 0K 0K fg root kswapd0
661 661 0 0% R 514612K 75568K fg u0_a3 id.wearable.app com.google.android.wearable.app
459 861 0 0% S 680248K 71456K fg system Binder_8 system_server
43 43 1 0% S 0K 0K fg root i2c_master_rese
46 46 1 0% S 0K 0K fg root i2c_master_rese
[top: 1.434s elapsed]

Categories

Resources