BUG: Android 7.0 - "logcat -d" always active with 10-20% of CPU

[Jecht_Sin]

A couple of weeks ago I had the bad idea of changing this setting once (Developer Option/Logger buffer size) to 4MB:

Because it is something usually required to do when reporting a bug with Xperia phones. Now just few minutes after reboot "logcat -d" is constantly using 10-20% of CPU:

Mem: 1457472K used, 156240K free, 87488K shrd, 7628K buff, 239712K cached
CPU: 28.6% usr 35.4% sys  2.2% nic 33.6% idle  0.0% io  0.0% irq  0.0% sirq
Load average: 41.30 40.21 39.63 4/2596 19622
  PID  PPID USER     STAT   VSZ %VSZ CPU %CPU COMMAND
17443  1277 u0_a140  S    1371m 86.7   3 22.1 {roid.youtube.tv} com.google.android.youtube.tv
18240 18218 u0_a0    R     4000  0.2   0 16.2 logcat -d

Checking the logcat I've seen that it is spamming hundreds/thousands of this error message (and that's why the logcat CPU usage is so high):

08-10 13:18:18.409  8725  8725 E libc    : Access denied finding property "persist.mtk.mlog2logcat"
08-10 13:18:18.409  8725  8725 E libc    : Access denied finding property "persist.mtk.mlog2logcat"
08-10 13:18:18.409  8725  8725 E libc    : Access denied finding property "persist.mtk.mlog2logcat"
08-10 13:18:18.409  8725  8725 E libc    : Access denied finding property "persist.mtk.mlog2logcat"
08-10 13:18:18.409  8725  8725 E libc    : Access denied finding property "persist.mtk.mlog2logcat"
08-10 13:18:18.409  8725  8725 E libc    : Access denied finding property "persist.mtk.mlog2logcat"
08-10 13:18:18.409  8725  8725 E libc    : Access denied finding property "persist.mtk.mlog2logcat"
08-10 13:18:18.410  8725  8725 E libc    : Access denied finding property "persist.mtk.mlog2logcat"
08-10 13:18:18.410  8725  8725 E libc    : Access denied finding property "persist.mtk.mlog2logcat"

As usual it isn't suprising that it is a message coming from Mediatek (mtk) libraries..

If I change the setting on the top again to 4MB and then back to 64KB the logcat error message disappears, and so it does the "logcat -d" CPU usage. But after a reboot it comes back again. I am not sure if it comes back after a while as well, without rebooting.

@Anonymous I am quite sure that this time it isn't "working as designed" at all!! 

Hopefully there is a way to remove that persist flag (which should be the default situation) without root, otherwise I must reset (again!!) to factory settings.

[Anonymous]

Hi

Summary:

• If setting log buffer to 4MB you get loads of errors and CPU usage of 10-20%
• If setting it back to the default 64KB, then all is fine.

Sorry, It might have been a long day for me today, but.....  Just leave it at 64KB (the default) is surely the solution?

Unless you are meaning - that setting it back to 64KB and the setting does not hold and reverts back to 4MB??

Cheers

[Jecht_Sin]

@Anonymous No, it has been more or less like this:

• Changed the option to 4MB
• Checked few logcats
• Rebooted the TV
• The value goes (always) back to 64KB
• After few days (as soon as I've run "top") I've seen "logcat -d" taking up to 20% of CPU
• After each reboot it doesn't start immediately. It takes minutes, maybe hours before to show up

To temporarily fix it:

• The value is already at 64KB
• Change the value back to 4MB
• Change it to nothing (I think this step must be done as well)
• Change it to 64KB
• "logcat -d" CPU usage goes back to normal and the error message stop spamming
• It lasts only until next reboot

At least I believe it has been caused by that parameter, because changing it it stops this error message spamming:

08-11 11:10:48.592 15668 15668 E libc    : Access denied finding property "persist.mtk.mlog2logcat"

Also I think it is worth nothing that this is the second time I get issues with Mediatek's modified libc. The other on is with the VPN bug casuing OS reboots.

I also tried to see if I could disable it via adb shell, but the above property doesn't show in the list of defined properties in Android:

BRAVIA_ATV2:/ $ getprop | grep persist.mtk
[persist.mtk.k2mlog]: [1]
[persist.mtk.printk_level]: [0]
BRAVIA_ATV2:/ $ 

And then without root it wouldn't be modifiable anyway.

PS: Yes, I know already. I had to leave that value alone.

[Anonymous]

Ok - I think I understand

You mentioned factory resetting the TV - have you done that yet?

[Jecht_Sin]

I'm doing that now. I am quite sure it will fix the issue, because the persist properties gets stored like:

/data/property/persist.this.is.my.property

And changing it once must have created it. Which should trigger the bug. Obviously I can check because it requires superuser permission just to list that directory.

Anyway, I am resetting also because I am getting random reboots in standby (again!!), picture settings going banana (once it showed HMDI 2 when changing picture settings in YouTube and other apps. Plus all kind of mess), Discovery randomly crashing and all type of hideous behaviours. I mean, very seldom (not the random reboots though. I have got at least a couple in the last two days), but annoying nonetheless. And 20% of CPU thrown away because of "logcat -d" doesn't help much either with app like Amazon Video..

In all honesty this is the worst version of Android I have ever had. 

[Jecht_Sin]

I have reset the TV and now, after going into deep sleep, the Ethernet connection goes away. To fix it I have to unplug and plug the ethernet cable again. Actually I have just restarted the router (which is working as a LAN bridge connecting to the ISP router), and that restored the connection again. Let's hope that fixes it for good. It seems to me that since (at least) Android 6.0.1 the sleep/awake has serious issues. I mean, this happened immediately after resetting the TV!!

"logcat -d" instead is not using much CPU anymore (obviously), but the performances when watching videos (YouTube/Amazon Video) are worse than before. Not in terms of CPU usage (it's about the same I had without logcat going nut), in terms of smoothness of play. YouTube with 1440p60fps videos microstutters a bit more than the last time I checked, and Amazon Video was an huge mess last night.

One would hope that two months after a major OS upgrade (actually longer than that since the security patches are from April 2017) the TV would get at least one update with major bug fixes. I don't believe indeed that the HW of these TVs (awful Mediatek SoCs included) isn't capable enough to run Android TV. It's just that it has to deal with so many bugs that the whole system slows down always for a different reason!