I have a problem with phone. Sometimes it's became to get really slow/slaggish and act by vibrating on pressing keys, sometimes even just vibrating when key was pressed several seconds before. Only way to heal it is rebooting. Without rebooting it's getting worse.
I described this problem also here:
http://forum.xda-developers.com/showthread.php?p=3005495#post3005495
Sorry for duplicate but research seems to came to different level So it's now better fit this forum folder.
Actually the question. If we have a look at log while getting my problem it's always looks like this:
Code:
<4>[ 1711.873479] init sharp panel
<4>[ 1738.135677] select 1668 (app_process), adj 15, size 2775, to kill
<4>[ 1738.136043] send sigkill to 1668 (app_process), adj 15, size 2775
<6>[ 1738.150896] binder: release 1668:1672 transaction 89700 in, still active
<6>[ 1738.151323] binder: send failed reply for transaction 89700 to 825:1207
<6>[ 1738.164090] binder: release 1668:1673 transaction 89699 in, still active
<6>[ 1738.164670] binder: send failed reply for transaction 89699 to 825:910
<6>[ 1738.167813] binder: release 1807:1807 transaction 89479 out, still active
<3>[ 1738.169248] init: untracked pid 1807 exited
<3>[ 1738.173694] init: untracked pid 1676 exited
<3>[ 1738.175738] init: untracked pid 1686 exited
<3>[ 1738.176654] init: untracked pid 1680 exited
<6>[ 1738.186013] binder: release 1826:1826 transaction 89600 out, still active
<3>[ 1738.187447] init: untracked pid 1826 exited
<6>[ 1738.188576] binder: release 1808:1808 transaction 89399 out, still active
<3>[ 1738.190102] init: untracked pid 1808 exited
<6>[ 1743.833185] binder: 825:910 transaction failed 29189, size 0-0
<6>[ 1743.833572] binder: send failed reply for transaction 89479, target dead
<6>[ 1743.836898] binder: 825:1207 transaction failed 29189, size 0-0
<6>[ 1743.837508] binder: send failed reply for transaction 89399, target dead
<6>[ 1744.943429] binder: 825:830 transaction failed 29189, size 0-0
<6>[ 1744.943572] binder: send failed reply for transaction 89600, target dead
Look at these "binder:*" messages. They aint looks nice. Any time my phone getting mad I am seeing those message in my dmesg. And I can't remember to see those errors while everything goes ok.
Afaik binder is some kind of Linux IPC realization on Android. So by itself it's not telling us anything (where the problem is, which part of system cause it and why phone start to vibrate).
Probably anyone who is familiar with IPC/Bender could gimme a idea how it recognize those numbers and where to see next? It's probably some PIDs?
Look at the third line. The out-of-memory (OOM) killer is killing processes. Later log entries complain about failed replies and transactions. It seems as though you're out of memory. The OOM killer is killing the process that must reply to those transactions.
Uninstall some apps. Watch your logcat until "low memory" reports go away.
Related
OK. I finally got my tablet back today from the repair facility only to find two of my three problems fixed. Not happy needless to say. I am still trying to figure out why I am having battery drain/android OS using so much of my battery. Used logcat and these two lines keep coming up over and over and over. Would this be causing my tablet to not go to sleep?
W/ResourceType( 5665): Failure getting entry for 0x7f020022 (t=1 e=34) in package 0 (error -75)
W/PackageManager( 5665): Failure retrieving resources forcom.sec.minimode.taskcloser: Resource ID #0x7f020022
Hi Everyone,
Was hoping I could ask a few people to help me out here. Since Feb 28th(ish), I get random kernel panics on CM11 or any ROMs based on the unified moto8960 tree.
To help me out to see if it's just me or a wider problem, all you need to do is install this app:
https://play.google.com/store/apps/details?id=se.mumu21.bootlog
Which will keep track of your uptime. It needs root privileges in order to copy last_kmsg and trying to view from the logs will FC the app. This is fine, it still copies the logs which you can then view/etc from your filemanager (default is to save to internal sd card)
Once the app is installed, you need not do anything more other than grant it root privs (head into preferences of the app and enable all 4 check marks) -- If your phone reboots, there'll be a record and can capture the last_kmsg file and hopefully push this up to the CM team, if there's an issue.
The app is smart enough to detect between user reboot and unexpected reboots, you'll see it listed as "crash" in the logs.
Thanks to anyone who decides to help out!
EDIT:
For reference, I'm including links to my last_kmsg in the two times I caught it on two separate builds (same error)
http://forum.xda-developers.com/showpost.php?p=51000973&postcount=1567
http://forum.xda-developers.com/showpost.php?p=50707021&postcount=1477
End of the day, for me it appears to be here:
Code:
[11746.588339,0] PM: Preparing system for mem sleep
[11746.588522,0] pm_debug: suspend uah=154646
[11746.591849,0] Freezing user space processes ...
[11746.596732,1] msm_server_control: wait_event error -512 for command10
[11746.596855,1] msm_open send open server failed
[11746.624903,0] ov8820_power_down
[11746.670164,0] msm_open: destroy ion client(elapsed 0.08 seconds) done.
[11746.924399,0] Freezing remaining freezable tasks ...
[11746.925681,0] active wake lock alarm_rtc, time left 73
[11746.926291,0]
[11746.926536,0] Freezing of tasks aborted
[11746.930625,0]
[11746.930869,0] Restarting tasks ...
[11746.949212,0] Unable to handle kernel NULL pointer dereference at virtual address 00000000
Can see logging around going into mem sleep plenty of times before, this time it fails. On AOSP builds, the error also happens (moto_msm8960) but the error is not with msm_server_control but rather:
Code:
[ 5630.051304,1] PM: Preparing system for mem sleep
[ 5630.051548,1] pm_debug: suspend uah=106686
[ 5678.901571,0] [0:986:E :DAT] Set DXE Power state 0
[ 5680.681793,0] [0:986:E :DAT] Set DXE Power state 2
[ 5680.689881,0] [WLAN][987:E :TL ] WLAN TL:No station registered with TL at this point
[ 5690.081214,1] **** Suspend timeout
[ 5690.081366,1] kworker/u:16 D c08131e0 0 22912 2 0x00000000
[ 5690.081671,1] [<c08131e0>] (__schedule+0x780/0x90c) from [<c081457c>] (__mutex_lock_slowpath+0x178/0x1e4)
[ 5690.081824,1] [<c081457c>] (__mutex_lock_slowpath+0x178/0x1e4) from [<c081463c>] (mutex_lock+0x54/0x6c)
[ 5690.082007,1] [<c081463c>] (mutex_lock+0x54/0x6c) from [<c0172480>] (cpu_hotplug_disable_before_freeze+0x8/0x20)
[ 5690.082190,1] [<c0172480>] (cpu_hotplug_disable_before_freeze+0x8/0x20) from [<c01724e0>] (cpu_hotplug_pm_callback+0x28/0x40)
[ 5690.082373,1] [<c01724e0>] (cpu_hotplug_pm_callback+0x28/0x40) from [<c08181c8>] (notifier_call_chain+0x38/0x68)
[ 5690.082526,1] [<c08181c8>] (notifier_call_chain+0x38/0x68) from [<c0193a1c>] (__blocking_notifier_call_chain+0x40/0x54)
[ 5690.082709,1] [<c0193a1c>] (__blocking_notifier_call_chain+0x40/0x54) from [<c0193a44>] (blocking_notifier_call_chain+0x14/0x18)
[ 5690.082892,1] [<c0193a44>] (blocking_notifier_call_chain+0x14/0x18) from [<c01a70d8>] (pm_notifier_call_chain+0x14/0x2c)
[ 5690.083075,1] [<c01a70d8>] (pm_notifier_call_chain+0x14/0x2c) from [<c01a8010>] (enter_state+0x68/0x13c)
[ 5690.083167,1] [<c01a8010>] (enter_state+0x68/0x13c) from [<c01a92f0>] (suspend+0x68/0x180)
[ 5690.083350,1] [<c01a92f0>] (suspend+0x68/0x180) from [<c0189aa8>] (process_one_work+0x228/0x434)
[ 5690.083533,1] [<c0189aa8>] (process_one_work+0x228/0x434) from [<c0189e88>] (worker_thread+0x1a8/0x2c8)
[ 5690.083686,1] [<c0189e88>] (worker_thread+0x1a8/0x2c8) from [<c018e2a8>] (kthread+0x80/0x8c)
[ 5690.083869,1] [<c018e2a8>] (kthread+0x80/0x8c) from [<c0106714>] (kernel_thread_exit+0x0/0x8)
[ 5690.083991,1] Unable to handle kernel NULL pointer dereference at virtual address 00000000
Curious to see if others are hitting the same thing.
Had a random reboot a few hours ago on cm11 (March 11th). Just installed the app, let's see what we can get now.
CWGSM3VO said:
Hi Everyone,
...
Click to expand...
Click to collapse
The issue captured in the second log is long known to us.
It's caused by msm-dcvs CPU governor and despite a few already applied kernel patches, it remains problematic.
So the current recommendation is: do not use msm-dcvs CPU governor.
(for the reference, see https://github.com/razrqcom-dev-team/android_kernel_motorola_msm8960-common/issues/12 )
The issue captured by the first log is something new and I already experienced it myself today (for the first time).
It's obviously a race condition during suspend/resume of camera kernel drivers.
It needs to be investigated. At this point I have no idea which commit brought this issue to surface.
kabaldan said:
The issue captured in the second log is long known to us.
It's caused by msm-dcvs CPU governor and despite a few already applied kernel patches, it remains problematic.
So the current recommendation is: do not use msm-dcvs CPU governor.
(for the reference, see https://github.com/razrqcom-dev-team/android_kernel_motorola_msm8960-common/issues/12 )
The issue captured by the first log is something new and I already experienced it myself today (for the first time).
It's obviously a race condition during suspend/resume of camera kernel drivers.
It needs to be investigated. At this point I have no idea which commit brought this issue to surface.
Click to expand...
Click to collapse
With regards to the second capture, that makes sense and knew Epinter's commits were merged but will stay away from the governor again. And the explanation of the first is muched appreciated. I do know however, I've experienced the panic using interactive as well in effort to stay as "stock" as one can be.
I'll switch back (so far so good on 03-12) to interactive again and go from there.
Thanks again for responding.
The Nexus 5 turn to be asked this hehe
I've just now experienced this in the course of fixing another issue.
Normally in spite of how much i change ROMS whenever I set time manually and uncheck network derived time the date/ time maintains across restarts, now it doesnt.
It looks like a 4.4.4 issue? Dunno
Any help / ideas welcome.
What I did so far:
clean ROM not dirty flashed
switching between stock OMNI and Minux OMNI
all combinations of option in date/ time settings while
Each and everytime after reset the date time is 13 Aug 1970. Even if is set to automatic that date briefly appears before a connection to the net is made.
Did you find the solution?
Could be related to the RTC not storing the time. The qpnp-rtc-write device tree option controls whether the time can be set with hwclock. If set to 0 or omitted, you will not be able to set the RTC time through the standard RTC interfaces (hwclock -w). Now, apparently these Qualcomm devices have a proprietary time_daemon program which is supposed to store these values permanently. It is invoked through the TimeService.apk program which is some thin glue that calls into libTimeService.so which invokes the time_genoff_operation function. I guess that this function should ultimately update the RTC time, but have not investigated further.
TL;DR check whether your TimeService.apk is working. It should contain a classes.dex file (deodexed). For Android 5.1, note that the files from the factory images are ART-optimized. You can undo that using Riddle's oat2dex.jar tool.
Edit: apparently these Qualcomm RTCs cannot be written from software (at least, not directly). A Qualcomm consultant mentioned this during patch review:
Anirudh Ghayal (Qualcomm consultant) said:
In some of our MSM/QSD designs, we have a single RTC shared by multiple
processors (other than the ones running Linux). Thus, the need to have a
non-writable RTC using this pdata.
Click to expand...
Click to collapse
Someone already tried to patch the property in the kernel, but writing via hwclock was still not possible. I can confirm this for a Nexus 5 (rev_11, tested with this recovery image patching tool):
Code:
~ # /system/xbin/hwclock -w
hwclock: RTC_SET_TIME: Operation not permitted
<3>[ 25.821247] spmi_pmic_arb fc4cf000.qcom,spmi: pmic_arb_wait_for_done: transaction denied (0x5)
<3>[ 25.821338] qcom,qpnp-rtc qpnp-rtc-ee162000: SPMI write failed
<3>[ 25.821408] qcom,qpnp-rtc qpnp-rtc-ee162000: Write to RTC reg failed
In the end, I decided to accept this problem and be stuck with a RTC set to 1970. Note that this device has not been network-connected since I started experimenting.
As for the TimeService.apk/time_genoff/time_daemon functionality, all these components do is maintaining an offset in the /data/system/time/ats_X files. These are read on startup and applied as offset. Nast hack, and there are alternative opensource alternatives. Really, the only functional thing that this daemon does is reading the RTC time and then applying the offsets over it. It has no code to write back the actual time to the RTC. It is no magic. (Found by reverse engineering the binaries and libraries.)
Lekensteyn said:
Could be related to the RTC not storing the time. The qpnp-rtc-write device tree option controls whether the time can be set with hwclock. If set to 0 or omitted, you will not be able to set the RTC time through the standard RTC interfaces (hwclock -w). Now, apparently these Qualcomm devices have a proprietary time_daemon program which is supposed to store these values permanently. It is invoked through the TimeService.apk program which is some thin glue that calls into libTimeService.so which invokes the time_genoff_operation function. I guess that this function should ultimately update the RTC time, but have not investigated further.
TL;DR check whether your TimeService.apk is working. It should contain a classes.dex file (deodexed). For Android 5.1, note that the files from the factory images are ART-optimized. You can undo that using Riddle's oat2dex.jar tool.
Edit: apparently these Qualcomm RTCs cannot be written from software (at least, not directly). A Qualcomm consultant mentioned this during patch review:
Someone already tried to patch the property in the kernel, but writing via hwclock was still not possible. I can confirm this for a Nexus 5 (rev_11, tested with this recovery image patching tool):
Code:
~ # /system/xbin/hwclock -w
hwclock: RTC_SET_TIME: Operation not permitted
<3>[ 25.821247] spmi_pmic_arb fc4cf000.qcom,spmi: pmic_arb_wait_for_done: transaction denied (0x5)
<3>[ 25.821338] qcom,qpnp-rtc qpnp-rtc-ee162000: SPMI write failed
<3>[ 25.821408] qcom,qpnp-rtc qpnp-rtc-ee162000: Write to RTC reg failed
In the end, I decided to accept this problem and be stuck with a RTC set to 1970. Note that this device has not been network-connected since I started experimenting.
As for the TimeService.apk/time_genoff/time_daemon functionality, all these components do is maintaining an offset in the /data/system/time/ats_X files. These are read on startup and applied as offset. Nast hack, and there are alternative opensource alternatives. Really, the only functional thing that this daemon does is reading the RTC time and then applying the offsets over it. It has no code to write back the actual time to the RTC. It is no magic. (Found by reverse engineering the binaries and libraries.)
Click to expand...
Click to collapse
Hi, great explanation.. I didn't have this issue in stock Marshmallow, but now I have it in custom ROM.. maybe it's something related to some permissions?
bart.found said:
Hi, great explanation.. I didn't have this issue in stock Marshmallow, but now I have it in custom ROM.. maybe it's something related to some permissions?
Click to expand...
Click to collapse
There is a SELinux policy that must allow access, you can check your kernel logs (dmesg or maybe even logcat) for SELinux denials. The /data/system/time/ location must also be accessible for the time daemon.
Hi, I need a technical advice before putting my LG G6 H870 to the garbage ...
Since a few weeks, I started getting some random app crashes and a few boot-loops while running an updated stock rom.
A factory reset leads to the same way and even a reset to refurbished stock rom version raises the same errors: so the issue comes from the hardware.
After installing TWRP and formatting system partition I tried to identify if it was an internal storage issue (and spoiler alert: it was :crying.
I knew that I should be able to identify bad blocks to tell the filesystem to not used them, but the problem if the use of a Flash Translation Layer (FTL) by the hardware that is obfuscating real nand memory addresses by design.
If i run a one-pass badblocks:
Code:
/dev/block/platform/soc/624000.ufshc/by-name # badblocks -wsvt 0xFF system
Checking for bad blocks in read-write mode
From block 0 to 5726207
Testing with pattern 0xff: done
Reading and comparing: 103464% done, 0:47 elapsed
103466
103468
103470
288888
288890
288892
288894
3197580 done, 0:54 elapsed
3197582
3197584
3197586
3358788
3358790
3358792
3358794
done
Pass completed, 16 bad blocks found.
And If I run a 4-pass badblocks:
Code:
/dev/block/platform/soc/624000.ufshc/by-name # badblocks -wsv system
Checking for bad blocks in read-write mode
From block 0 to 5726207
Testing with pattern 0xaa: done
Reading and comparing: 110968% done, 0:47 elapsed
110970
110972
110974
303396
303398
303400
303402
3205312 done, 0:54 elapsed
3205314
3205316
3205318
3351108
3351110
3351112
3351114
done
Testing with pattern 0x55: done
Reading and comparing: 109356% done, 1:48 elapsed
109358
109360
109362
306392
306394
306396
306398
3206852 done, 1:55 elapsed
3206854
3206856
3206858
3353208
3353210
3353212
3353214
done
Testing with pattern 0xff: done
Reading and comparing: 110848% done, 2:48 elapsed
110850
110852
110854
304640
304642
304644
304646
3206292 done, 2:55 elapsed
3206294
3206296
3206298
3353228
3353230
3353232
3353234
done
Testing with pattern 0x00: done
Reading and comparing: 111992% done, 3:48 elapsed
111994
111996
111998
304668
304670
304672
304674
3215112 done, 3:55 elapsed
3215114
3215116
3215118
3353828
3353830
3353832
3353834
done
Pass completed, 64 bad blocks found.
Oh surprise (no it's not), bad blocks are never the sames because of the FTL, and that's probably why the badblocks binary is not a part of the standard recovery binaries list.
But since the hardware via the FTL should take care of bad sectors, why it's not the case for my LG G6 ?
Is there a way to enforce this check at low-level ?
My readings before posting:
https://android.stackexchange.com/q...d-sector-on-my-android-with-adb-recovery-mode
https://android.stackexchange.com/q...-bad-ram-addresses-and-fix-bad-storage-blocks
HALLOOO I've been having a problem for days and I can't really solve it. This problem occurs when I want to push a commit from terminal, I always get these errors:
error: RPC failed; curl 55 SSL_write() returned SYSCALL, errno = 32
fatal: The remote end hung up unexpectedly
As I understand these errors appear when the files that you want to upload to the server are quiet big, in my case they are commits of .playground files, that should not be heavy but they were accumulating because I have been dragging problems to upload files to github for a while. I'm not sure what the solution would be, but is there any way to delete everything and start from scratch?
I already tried to increase my push limit but I'm still having the same problem.