Related
Hi there,
Could anyone explain me, this strange errors in dmesg log?
I checked and there aren't this errors on stock (don't rooted rom),
but after use unrevoked3 tool on this rom, errors appears in log,
also on pre-rooted teppic rom and another pre-rooted stock roms from here.
[...]
<3>[ 25.553009] msm_nand_erase: erase failed, 0x4d40000
<3>[ 25.553436] msm_nand_erase: erase failed, 0x4dc0000
<3>[ 25.553894] msm_nand_erase: erase failed, 0x4f80000
<4>[ 25.554199] yaffs_read_super: isCheckpointed 0
<3>[ 25.554687] msm_nand_write_oob 11a80000 800 1c failed -5
[a lot of same messages]
[a lot of same messages]
[a lot of same messages]
<3>[ 25.617645] msm_nand_write_oob 11afc800 800 1c failed -5
<4>[ 25.617828] save exit: isCheckpointed 1
<6>[ 25.632659] yaffs: dev is 32505861 name is "mtdblock5"
<6>[ 25.632781] yaffs: passed flags ""
[...]
Hey guys, was just wondering..
What hardware changes are made in new WFS's ??
I think, there is something new in screen or GPU, because:
- CWM recovery 5.0.2.x recovery is with blank screen
- CWM Recovey 6.0.x.x doesn't work at all
- CM7 and CM9 build-in kernels doesn't start
- after replace kernel CM's roms starts, but touchscreen and 4 bottom buttons doesn't work
- old versions of CM7 starts, but screen is blank all the time (rom and touch works - I see this in [email protected])
I think there are changes in BOOT section of CM's - I wonder if it is possible to replace boot section and kernel from stock 2.3.5 rom.
Maybe then touchscreen will be working.
Maybe HTC provides some technical data about hardware changes in WFS's ???
dmesg log
As is described here http://forum.xda-developers.com/showpost.php?p=29846194&postcount=31 with adb shell dmesg command I got this log file.Hope it helps.I can't yet post in dev section.And thank you,Marchelius because I was planning to try CM7,but for now I stay with same ROM as you.I put other 2 dmesg logs which was made in recovery.
Bravo!
sorinaugusto said:
As is described here http://forum.xda-developers.com/showpost.php?p=29846194&postcount=31 with adb shell dmesg command I got this log file.Hope it helps.I can't yet post in dev section.And thank you,Marchelius because I was planning to try CM7,but for now I stay with same ROM as you.I put other 2 dmesg logs which was made in recovery.
Click to expand...
Click to collapse
This should help narrow down the issue so the community can come up with a fix for these devices. Which kernel/ROMs are users of these devices able to use without display issues?
WoefulDerelict said:
This should help narrow down the issue so the community can come up with a fix for these devices. Which kernel/ROMs are users of these devices able to use without display issues?
Click to expand...
Click to collapse
I think every stock GB will be work. I tried 2.13 and 2.26 stock roms and works fine.
EQDKP roms works too - I tried v4.7 v4,0 and v5.0 deodexed. I think, roms like wildchild etc. will be work OK.
I used kernels : Dust, Jikantu and Cake - all of them work OK
With AOKP, CM7 and CM9 i tried Cake kernel - after replace roms starts, but still is problem with screen.
I tried replace boot.img from stock rom and apply to CM9 - flashed OK, but roms doesn't work - still had startup logo and phone freeze after few minutes.
More logs would be really helpful!
marchelius said:
I think every stock GB will be work. I tried 2.13 and 2.26 stock roms and works fine.
EQDKP roms works too - I tried v4.7 v4,0 and v5.0 deodexed. I think, roms like wildchild etc. will be work OK.
I used kernels : Dust, Jikantu and Cake - all of them work OK
With AOKP, CM7 and CM9 i tried Cake kernel - after replace roms starts, but still is problem with screen.
I tried replace boot.img from stock rom and apply to CM9 - flashed OK, but roms doesn't work - still had startup logo and phone freeze after few minutes.
Click to expand...
Click to collapse
So, ROMS based around the stock HTC kernels and software boot without display issues but, completely custom firmware and kernels are a mixed bag? As I understand it Dust, Jikantu and Cake kernels are extended drop-in replacements for ROMs based around the stock GB releases and those all work fine. Have you managed to get any CM7 ports working with a replacement kernel? Are all the AOKP ports you've tried ICS based?
I don't imagine you'll have much luck plugging a GB kernel into an ICS rom like CM9. There were a number of changes in the way Android expects it's hardware to be presented between Gingerbread and Ice Cream Sandwich that would keep it from working properly; however, most of the work is still based off the kernel source released by HTC.
In your experiments with AOKP, CM7 and CM9 you say that after replacing the kernel with one that worked in a stock GB ROM it booted but, the display still didn't properly initialise? Could you still poke the device through ADB? If it's responsive a logcat and dmesg would be extremely helpful.
---------- Post added at 04:20 PM ---------- Previous post was at 03:53 PM ----------
There are two types of log you can generate that would be extremely helpful in tracking down this issue: dmesg and logcat. In this situation dmesg is likely our greatest ally. Dmesg contains all of the kernel degugging messages which will allow developers to look for errors from the kernel regarding the display. Logs from healthy systems and broken systems can be equally utilitarian in tracking down what's happening with your devices.
You can pull a dmesg from any device that has successfully booted and has adb running even if it hasn't initialised the display properly. The basic command looks like this.
Code:
adb shell dmesg
To make it easier to share this information you can redirect the output to a text file in the working directory using >. This works in both windows and *nix. Should you choose you can also specify a path for the command to drop the file into.
Code:
adb shell dmesg > dmesg.txt
If users wouldn't mind naming them dmesgDisplayOK.txt and dmesgDislayFAIL.txt depending on if the display was properly initialised when the log was generated I'd certainly appreciate it.
If you've successfully booted a ROM the system will also supply logcat data which can be collected by the following command. As with the previous command this will also direct the output to the specified location. Most recovery software doesn't start logcat.
Code:
adb logcat > logcat.txt
As with dmesg I'd appreciate easily identifiable names like logcatDisplayOK.txt and logcatDisplayFAIL.txt to help developers.
If you've booted a recovery distribution most keep their own logs. This file is most often hidden in /tmp and called recovery.log. You can pull this file using the following command and it will drop it into your current working directory. Should you choose it will also accept a destination path.
Code:
adb pull /tmp/recovery.log
The more information about the software you were running at the time the logs were generated you can include the better.
Points of interest...
When browsing the recovery logs submitted by sorinaugusto I've spotted 3 points of interest.
The first revolves around the Cypress C8YC_TMA touch-screen driver. This is the digitiser that handles touch input and I believe it is common to all WFS devices. I can see it being used in the first log, which if I don't miss my guess if from a happy functioning ROM boot, and it isn't complaining; however, in recovery it generates this:
Code:
<6>[ 6.278259] cy8c_ts_init: enter
<7>[ 6.278686] cy8c_ts_probe: enter
<6>[ 6.278869] marvel_ts_cy8c_power():
<6>[ 6.337188] CY8CTMA340 0-0067: buf: 11, 0, 0, 15
<6>[ 6.337402] CY8CTMA340 0-0067: application verion = 15, x_channel = F, y_channel = A
<6>[ 6.476348] CY8CTMA340 0-0067: orient: 0
<6>[ 6.476654] input_set_abs_params: mix_x 0, max_x 1023, min_y 0, max_y 940
<6>[ 6.477264] input: cy8c-touchscreen as /devices/virtual/input/input1
<6>[ 6.477905] CY8CTMA340 0-0067: Start touchscreen cy8c-touchscreen in interrupt mode
<3>[ 6.478393] msm_i2c msm_i2c.0: error, status c8 (48,81,00)(67,00,00)(cnt:1,pos:0)
<3>[ 6.478790] msm_i2c msm_i2c.0: Error during data xfer (-5)(48,81,00)
<3>[ 6.489501] msm_i2c msm_i2c.0: error, status c8 (48,81,00)(48,81,00)(cnt:1,pos:0)
<3>[ 6.490264] msm_i2c msm_i2c.0: Error during data xfer (-5)(48,81,00)
<3>[ 6.500762] msm_i2c msm_i2c.0: error, status 43c8 (48,81,00)(48,81,00)(cnt:1,pos:0)
<3>[ 6.501007] msm_i2c msm_i2c.0: Error during data xfer (-5)(48,81,00)
<3>[ 6.511474] msm_i2c msm_i2c.0: error, status 83c8 (48,81,00)(48,81,00)(cnt:1,pos:0)
<3>[ 6.511871] msm_i2c msm_i2c.0: Error during data xfer (-5)(48,81,00)
<3>[ 6.522186] msm_i2c msm_i2c.0: error, status 83c8 (48,81,00)(48,81,00)(cnt:1,pos:0)
<3>[ 6.522583] msm_i2c msm_i2c.0: Error during data xfer (-5)(48,81,00)
<3>[ 6.532867] msm_i2c msm_i2c.0: error, status 83c8 (48,81,00)(48,81,00)(cnt:1,pos:0)
<3>[ 6.533264] msm_i2c msm_i2c.0: Error during data xfer (-5)(48,81,00)
<3>[ 6.543762] msm_i2c msm_i2c.0: error, status 83c8 (48,81,00)(48,81,00)(cnt:1,pos:0)
<3>[ 6.543975] msm_i2c msm_i2c.0: Error during data xfer (-5)(48,81,00)
<3>[ 6.554443] msm_i2c msm_i2c.0: error, status 83c8 (48,81,00)(48,81,00)(cnt:1,pos:0)
<3>[ 6.554840] msm_i2c msm_i2c.0: Error during data xfer (-5)(48,81,00)
<3>[ 6.565155] msm_i2c msm_i2c.0: error, status 83c8 (48,81,00)(48,81,00)(cnt:1,pos:0)
<3>[ 6.565551] msm_i2c msm_i2c.0: Error during data xfer (-5)(48,81,00)
<3>[ 6.575866] msm_i2c msm_i2c.0: error, status 83c8 (48,81,00)(48,81,00)(cnt:1,pos:0)
<3>[ 6.576263] msm_i2c msm_i2c.0: Error during data xfer (-5)(48,81,00)
<3>[ 6.587097] i2c_write_block retry over 10
The second blob relates directly to the display. Sadly these are the only complaints I'm spotting and it doesn't help me pinpoint the problem.
Code:
<4>[ 10.137237] [DISP]msmfb_pan_display timeout rerequest vsync
<4>[ 10.467163] [DISP]msmfb_pan_display timeout waiting for frame start, 2 1
<4>[ 11.117218] [DISP]msmfb_pan_display timeout rerequest vsync
<4>[ 11.447174] [DISP]msmfb_pan_display timeout waiting for frame start, 2 1
The final group of issues that caught my eye is probably the least transparent.
Code:
<3>[ 65.897521] BUG: sleeping function called from invalid context at mm/slab.c:3102
<3>[ 65.897521] in_atomic(): 1, irqs_disabled(): 128, pid: 0, name: swapper
<4>[ 65.897521] Backtrace:
<4>[ 65.897521] [<c0036a3c>] (dump_backtrace+0x0/0x114) from [<c0405ea0>] (dump_stack+0x18/0x1c)
<4>[ 65.897521] r7:000000d0 r6:000080d0 r5:da8000c0 r4:c051ed70
<4>[ 65.897521] [<c0405e88>] (dump_stack+0x0/0x1c) from [<c006ac48>] (__might_sleep+0x108/0x128)
<4>[ 65.897521] [<c006ab40>] (__might_sleep+0x0/0x128) from [<c00d87f8>] (kmem_cache_alloc+0x34/0x108)
<4>[ 65.897521] r4:c051dde0
<4>[ 65.897521] [<c00d87c4>] (kmem_cache_alloc+0x0/0x108) from [<c00d4950>] (__get_vm_area_node+0xac/0x128)
<4>[ 65.897521] r7:000000d0 r6:00002000 r5:00000001 r4:c051dde0
<4>[ 65.897521] [<c00d48a4>] (__get_vm_area_node+0x0/0x128) from [<c00d4a68>](get_vm_area_caller+0x4c/0x58)
<4>[ 65.897521] [<c00d4a1c>] (get_vm_area_caller+0x0/0x58) from [<c0039718>] (__arm_ioremap_pfn_caller+0x64/0x164)
<4>[ 65.897521] [<c00396b4>] (__arm_ioremap_pfn_caller+0x0/0x164) from [<c0039898>] (__arm_ioremap_caller+0x60/0x68)
<4>[ 65.897521] [<c0039838>] (__arm_ioremap_caller+0x0/0x68) from [<c00398b4>] (__arm_ioremap+0x14/0x18)
<4>[ 65.897521] r5:00000001 r4:c055f9e4
<4>[ 65.897521] [<c00398a0>] (__arm_ioremap+0x0/0x18) from [<c003c250>] (__msm_ioremap+0x28/0x2c)
<4>[ 65.897521] [<c003c228>] (__msm_ioremap+0x0/0x2c) from [<c003d118>] (write_to_strongly_ordered_memory+0x48/0x6c)
<4>[ 65.897521] [<c003d0d0>] (write_to_strongly_ordered_memory+0x0/0x6c) from[<c003c220>] (l2x0_suspend+0x12c/0x134)
<4>[ 65.897521] r5:00000001 r4:00000002
<4>[ 65.897521] [<c003c0f4>] (l2x0_suspend+0x0/0x134) from [<c0058118>] (msm_sleep+0x2d4/0x598)
<4>[ 65.897521] [<c0057e44>] (msm_sleep+0x0/0x598) from [<c005869c>] (arch_idle+0x294/0x420)
<4>[ 65.897521] [<c0058408>] (arch_idle+0x0/0x420) from [<c0033a74>] (default_idle+0x28/0x30)
<4>[ 65.897521] [<c0033a4c>] (default_idle+0x0/0x30) from [<c02d1df4>] (cpufreq_idle+0x20/0x6c)
<4>[ 65.897521] [<c02d1dd4>] (cpufreq_idle+0x0/0x6c) from [<c0033d38>] (cpu_idle+0x50/0xa8)
<4>[ 65.897521] r7:c051fa00 r6:c055f844 r5:c051fa08 r4:c051c000
<4>[ 65.897521] [<c0033ce8>] (cpu_idle+0x0/0xa8) from [<c0402c1c>] (rest_init+0xc0/0xe4)
<4>[ 65.897521] r7:c051fa00 r6:c0028014 r5:00000000 r4:c051c000
<4>[ 65.897521] [<c0402b5c>] (rest_init+0x0/0xe4) from [<c0008a24>] (start_kernel+0x288/0x2ec)
<4>[ 65.897521] r5:00000000 r4:c05e7680
<4>[ 65.897521] [<c000879c>] (start_kernel+0x0/0x2ec) from [<12c08034>] (0x12c08034)
<3>[ 245.957336] INFO: task rpcrouter:18 blocked for more than 120 seconds.
<3>[ 245.957824] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
<6>[ 245.958679] rpcrouter D c04067cc 0 18 2 0x00000000
<4>[ 245.960021] Backtrace:
<4>[ 245.961364] [<c0406124>] (schedule+0x0/0x7d4) from [<c00471f4>] (rr_read+0x178/0x1a4)
<4>[ 245.961883] [<c004707c>] (rr_read+0x0/0x1a4) from [<c00473ac>] (do_read_data+0x1c/0x7d0)
<4>[ 245.962799] [<c0047390>] (do_read_data+0x0/0x7d0) from [<c0083ab8>] (worker_thread+0x18c/0x23c)
<4>[ 245.963653] r8:da0c5f84 r7:da0a3788 r6:c0047390 r5:da0a3780 r4:da0c4000
<4>[ 245.966400] [<c008392c>] (worker_thread+0x0/0x23c) from [<c00878b4>] (kthread+0x84/0x8c)
<4>[ 245.967346] [<c0087830>] (kthread+0x0/0x8c) from [<c0074184>] (do_exit+0x0/0x6b0)
<4>[ 245.968200] r7:00000013 r6:c0074184 r5:c0087830 r4:da82fd70
<3>[ 365.967346] INFO: task rpcrouter:18 blocked for more than 120 seconds.
<3>[ 365.968231] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
<6>[ 365.969085] rpcrouter D c04067cc 0 18 2 0x00000000
<4>[ 365.970428] Backtrace:
<4>[ 365.971405] [<c0406124>] (schedule+0x0/0x7d4) from [<c00471f4>] (rr_read+0x178/0x1a4)
<4>[ 365.972290] [<c004707c>] (rr_read+0x0/0x1a4) from [<c00473ac>] (do_read_data+0x1c/0x7d0)
<4>[ 365.973205] [<c0047390>] (do_read_data+0x0/0x7d0) from [<c0083ab8>] (worker_thread+0x18c/0x23c)
<4>[ 365.973693] r8:da0c5f84 r7:da0a3788 r6:c0047390 r5:da0a3780 r4:da0c4000
<4>[ 365.976806] [<c008392c>] (worker_thread+0x0/0x23c) from [<c00878b4>] (kthread+0x84/0x8c)
<4>[ 365.977752] [<c0087830>] (kthread+0x0/0x8c) from [<c0074184>] (do_exit+0x0/0x6b0)
<4>[ 365.978240] r7:00000013 r6:c0074184 r5:c0087830 r4:da82fd70
I have the original source code from HTC along with the newest code from the Cryptomilk git but, I could use more data to help me trace this issue back to it's origin.
Any update guys?
Caro332 said:
Any update guys?
Click to expand...
Click to collapse
I'd like to know, too. I have been looking every day through internet for the solution - all are quiet. Seems like there is a little amount of people with WFS 2012 who want custom roms... Others don't bother. Why then HTC offers us unlocking of our bootloader if there is no alternative left?
marchelius said:
Hey guys, was just wondering..
What hardware changes are made in new WFS's ??
I think, there is something new in screen or GPU, because:
- CWM recovery 5.0.2.x recovery is with blank screen
- CWM Recovey 6.0.x.x doesn't work at all
- CM7 and CM9 build-in kernels doesn't start
- after replace kernel CM's roms starts, but touchscreen and 4 bottom buttons doesn't work
- old versions of CM7 starts, but screen is blank all the time (rom and touch works - I see this in [email protected])
I think there are changes in BOOT section of CM's - I wonder if it is possible to replace boot section and kernel from stock 2.3.5 rom.
Maybe then touchscreen will be working.
Maybe HTC provides some technical data about hardware changes in WFS's ???
Click to expand...
Click to collapse
Marchelius try the CWM in this post http://forum.xda-developers.com/showthread.php?t=1997465&page=3 as it worked for me
I have a wfs 2011 but whenever I flash cm Rom it boots okay but the screen remain unresponsive to touch.
please someone should help me .
Hello,
today as i was accessing my email on Opera Mobile, the SuperSU window popped up by itself and asked me for root acces for a program called "debuggerd.exynosabuse". I dont know what this debuggerd.exynosabuse is and i didnt open any apk before the SU window suddenly popped up..so naturally i denied it root access...then I went into the SuperSU log file and I saw that it kept trying to get root access for two minutes continuously and about 15 tries... also it doesnt have any icon in the apps section of SuperSU. Any ideas what this is about?
Thanks
Look for the app in app drawer named exynos abuse.
Sent from my GT-N7100 using xda app-developers app
Ok. So I m looking for what exactly? I have already mentioned that it is called debuggerd.exynosabuse. it is not the exynos abuse apk, which I used to root my phone and patch the exploit. It is a different app that has no icon in the SU logfile. This debuggerd is always trying to get root access to modify some root files but I have it denied in SU. It tries to get root access 50 times a day or more. What is this program and where did it come from and what should I do with it. Thanks.
Maybe clear data...
Sent from my GT-N7100 using xda app-developers app
You are not alone
http://www.chainfire.eu/articles/126/ExynosAbuse_APK_released_/
may be malware
Try a full wipe including system cache and dalvik and data.
Then flash latest stock rom and root via cfautoroot.
Also backing up anything using any software is not recommended as malware might have infected it.
Sent from my GT-N7100 using xda app-developers app
I just had the same experience for the first time, unfortunately seeing it was a part of ExynosAbuse, I authorized it...
I then saw a lot going on, and in between SuperSU notifications, I saw Adblock Plus notifications too... Maybe related?
As I said try full wipe and flash latest stock rom.
Sent from my GT-N7100 using xda app-developers app
Well, I'd like to know before I wipe, it's not an easy thing to do for me right now, plus if it's something in the app and I reinstall the app after wiping, I'll have the same problem...
Than you for your input Dr Ketan. I see that this is a relatively new problem and its got people wondering/worried, I appreciate that this issue has come to your attention.
Dear UtkarshGupta, Sure anyone can nuke their phone and wipe all and flash new, but thats not what the xda community is about. We are here to share, communicate, support, enhance, develop, and learn.
Understanding the problem would be the first step in to solving it. When we know what is the size of the problem, we would then know how to deal with it appropriately. It might be something simple that can be cleaned easily, no nuke needed.
As for me, I am happy with my 4.1.1 jb. I dont want to flash any new firmware.
By now I have taken several screen shots of it trying to get root access to many files and even it was trying to change values and commands but all were denied ofcourse because I have it blocked in SU. If it would help the devs or anyone else, I can attach the screenshots if need be.
Well, I have some news.
I removed debuggerd from SuperSU authorizations. Later on, I used Chrome and I got all these requests again. This time, I refused (and took screenshots). At the end, Chrome didn't load the webpage. But mostly, I had no internet connection at all!
Then, I remembered that the first time I had the request, it was when using the web browser. And then, I realized it happened the day after I installed Android Adblock Plus.
I uninstalled it, rebooted, and then my connection worked. I'll try to remove debuggerd from the SuperSU blacklist to see if it still happens.
Anyone can correlate?
Hi,
I had the same problems :
- debuggerd.exynosabuse requested SU privileges
- enter in an infinite loop, use a lot of battery power, automatic reboot of the device more than twice a day
So I tried to remove these files. In order to do that you need :
- a rooted device (su installed and working)
- Android Terminal Emulator installed from Googleplay in the device
Launch Android Terminal Emulator
Enter the commands below :
su (accept su privileges, prompt disappears)
mount -o remount,rw /system
cd /system/bin
rm debuggerd
rm debuggerd.exynosabuse
reboot
It works for me. I hope it will work for you.
debuggerd.exynosabuse
From what I can see, the /system/bin/debugger has been replaced with a script that reads:
#!/system/bin/sh
chmod 0400 /dev/exynos-mem
/system/bin/debuggerd.exynosabuse
Then, debuggerd.exynosabuse seems to launch instead of the normal debuggerd. I suppose some applications may call debuggerd by design, which explains why there are some random popups. Here are the "strings" for debuggerd.exynosabuse which appears to be the renamed original (need to verify). This thread then shows that it appears to do the reported actions.. by design? Would be interesting to trace it down a bit more to determine if the carrier/app developer is sending process dumps back to home for analysis which could contain sensitive data.
ELF
p\4
/system/bin/linker
__aeabi_unwind_cpp_pr0
__dso_handle
__INIT_ARRAY__
__FINI_ARRAY__
memset
property_get
atoi
__stack_chk_fail
__stack_chk_guard
__android_log_vprint
open
close
__errno
strcmp
strlen
vsnprintf
__aeabi_unwind_cpp_pr1
snprintf
strcpy
fprintf
__sF
calloc
free
strdup
fputs
strftime
write
strerror
strtoul
_edata
__bss_start
_end
realloc
memmove
read
socket_local_client
socket_local_server
getsockopt
fopen
fgets
fclose
fcntl
poll
accept
usleep
ioctl
dump_tombstone
dump_backtrace_to_file
getpid
__isthreaded
memcmp
sprintf
__libc_init
fchown
chown
stat
mkdir
sigaction
inotify_init
inotify_add_watch
kill
ptrace
opendir
readdir
readdir_r
closedir
fileno
waitpid
bsd_signal
time
system
fflush
localtime_r
unwind_backtrace_ptrace
demangle_symbol_name
get_backtrace_symbols_ptrace
find_symbol_ptrace
free_backtrace_symbols
format_backtrace_line
try_get_word_ptrace
load_ptrace_context
free_ptrace_context
liblog.so
libcutils.so
libc.so
libcorkscrew.so
/proc/%d/cmdline
%F %T
----- pid %d at %s -----
Cmd line: %s
<unknown>
/proc/%d/comm
"%s" sysTid=%d
Could not attach to thread: %s
Could not obtain stack trace for thread.
%s
ptrace detach from %d failed: %s
/proc/%d/task
----- end %d -----
Sending request to dump task %d.
Error dumping backtrace.
Error dumping tombstone.
Tombstone written to: %s
cannot get credentials
timed out reading tid
read failure? %s
invalid crash request of size %d
/proc/%d/task/%d
tid %d does not exist in pid %d. ignoring debug request
/proc/%d/status
Tgid:
Uid:
Gid:
tid %d does not exist. ignoring explicit dump request
ptrace attach failed: %s
debug.db.uid
failed responding to client: %s
ptrace continue failed: %s
dumpstate -k -t -z -d -o /data/log/dumpstate_app_native -m %d
[email protected]%s
process stopped due to unexpected signal %d
********************************************************
* Process %d has been suspended while crashing. To
* attach gdbserver for a gdb connection on port 5039
* and start gdbclient:
* gdbclient app_process :5039 %d
* Wait for gdb to start, then press HOME or VOLUME DOWN key
* to let the process continue crashing.
********************************************************
/sys/class/leds/red/brightness
/sys/class/leds/green/brightness
/sys/class/leds/blue/brightness
/sys/class/leds/red/device/blink
/sys/class/leds/left/cadence
0,0
255
1,0
debuggerd resuming process %d
debuggerd committing suicide to free the zombie!
logd
android:debuggerd
debuggerd: Oct 4 2012 16:24:21
Usage: -b [<tid>]
-b dump backtrace to console, otherwise dump full tombstone file
If tid specified, sends a request to debuggerd to dump that task.
Otherwise, starts the debuggerd server.
out of memory
/dev/input
could not get event, %s
could not get event
SIGILL
SIGABRT
SIGBUS
SIGFPE
SIGSEGV
SIGPIPE
SIGSTKFLT
SIGSTOP
ILL_ILLOPC
ILL_ILLOPN
ILL_ILLADR
ILL_ILLTRP
ILL_PRVOPC
ILL_PRVREG
ILL_COPROC
ILL_BADSTK
BUS_ADRALN
BUS_ADRERR
BUS_OBJERR
FPE_INTDIV
FPE_INTOVF
FPE_FLTDIV
FPE_FLTOVF
FPE_FLTUND
FPE_FLTRES
FPE_FLTINV
FPE_FLTSUB
SEGV_MAPERR
SEGV_ACCERR
UNKNOWN
pid: %d, tid: %d, name: %s >>> %s <<<
pid: %d, tid: %d, name: %s
#%02d %08x %08x %s (%s+%u)
#%02d %08x %08x %s (%s)
%08x %08x %s (%s+%u)
%08x %08x %s (%s)
#%02d %08x %08x %s
%08x %08x %s
backtrace:
%s
stack:
........ ........
*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
ro.build.fingerprint
unknown
Build fingerprint: '%s'
cannot get siginfo: %s
signal %d (%s), code %d (%s), fault addr %08x
cannot get siginfo for %d: %s
memory map around fault addr %08x:
%08x-%08x %s
(no map below)
(no map for address)
(no map above)
--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- ---
signal %d (%s), code %d (%s), fault addr --------
/data/tombstones
/data/tombstones/tombstone_%02d
failed to open tombstone file '%s': %s
DEBUG
waitpid failed: %s
unexpected waitpid response: n=%d, status=%08x
timed out waiting for tid=%d to die
timed out waiting for tid=%d to stop
%08x
%08lx
%s %s
memory near %.2s:
code around pc:
code around lr:
cannot get registers: %s
r0 %08x r1 %08x r2 %08x r3 %08x
r4 %08x r5 %08x r6 %08x r7 %08x
r8 %08x r9 %08x sl %08x fp %08x
ip %08x sp %08x lr %08x pc %08x cpsr %08x
d%-2d %016llx d%-2d %016llx
scr %08lx
r0r1r2r3r4r5r6r7r8r9slfpipsp
GCC: (GNU) 4.6.x-google 20120106 (prerelease)
GNU
gold 1.10
aeabi
ARM v7
.shstrtab
.interp
.dynsym
.dynstr
.hash
.rel.dyn
.rel.plt
.text
.ARM.extab
.ARM.exidx
.rodata
.preinit_array
.init_array
.fini_array
.ctors
.dynamic
.got
.bss
.comment
.note.gnu.gold-version
.ARM.attributes
be careful 'RM'ing everything
tcharlier said:
Hi,
I had the same problems :
- debuggerd.exynosabuse requested SU privileges
- enter in an infinite loop, use a lot of battery power, automatic reboot of the device more than twice a day
So I tried to remove these files. In order to do that you need :
- a rooted device (su installed and working)
- Android Terminal Emulator installed from Googleplay in the device
Launch Android Terminal Emulator
Enter the commands below :
su (accept su privileges, prompt disappears)
mount -o remount,rw /system
cd /system/bin
rm debuggerd
rm debuggerd.exynosabuse
reboot
It works for me. I hope it will work for you.
Click to expand...
Click to collapse
should you remove 'debuggerd' & 'debuggerd.exynosabuse' they would simply return from the dead.
i believe they are trying to catch and identify a neardeath experience, in this case relating to exynosabuse. this could be the 4.1.2 upgrade and exynosabuse not sitting comfortably together or it may have been intended to work this way - chainfire is the best source for this answer.
debuggerd is called to examine the problem occurrence point on the source code from a crash dump before the main function is carried out. any prog's with dynamic links can automatically connect to debuggerd and generate crash dumps.
i do find it a bit unsettling when root privileges are asked for something that was never installed as an apk and then devours cpu and battery until nothing is left.
more research needs to be done as to what is really going on...
refer to Koba's blog - 'debuggerd of Android'
No more bugging
Got sick and tired of it requesting su privileges all the time. Copied debuggerd and debuggerd.exy to sd card just in case and then deleted the ones in system/bin, that are doing all the damage, via es file explorer with root access coz couldnt be deleted any other way and its been 3 days since and it didnt come back and all is clean on su logs no more requests from it.
By the way its got nothing to do with 4.1.2 sitting with exynosabuse.apk as im still running 4.1.1.
Problem solved...uptill now.
Noob.Saibot said:
Got sick and tired of it requesting su privileges all the time. Copied debuggerd and debuggerd.exy to sd card just in case and then deleted the ones in system/bin, that are doing all the damage, via es file explorer with root access coz couldnt be deleted any other way and its been 3 days since and it didnt come back and all is clean on su logs no more requests from it.
By the way its got nothing to do with 4.1.2 sitting with exynosabuse.apk as im still running 4.1.1.
Problem solved...uptill now.
Click to expand...
Click to collapse
apologies, i should have been clearer, as i too had root privy requests whilst on 4.1.1 - however the frequency of this increased noticeably once upgraded to 4.1.2. also i have no other apk's title being added to the debuggerd name in system/bin. i had only 2 files in system/bin - the 1st was "debuggerd" and the second "debuggerd.exynosabuse". this seems to be saying that something is specific enough about exynosabuse for the separately titled file to appear.
if anyone finds any other files identified in this way please comment.
so in all, i should have said, for me, that the debuggerd bugged me more, via the massive increase in root requests, when sitting with 4.1.2 than it did when i had 4.1.1 installed.
again, anyone with ideas as to what and why this debuggerd saga is taking place would be greatly appreciated.
I'm having the same issue, denying debuggerd.exynosabuse in SuperSU just causes my phone to reboot when the requests come through. This happens multiple times a day.
It is probably a malware.
Update to 4.1.2 asap.
Sent from my GT-N7100 using xda app-developers app
Noob.Saibot said:
Got sick and tired of it requesting su privileges all the time. Copied debuggerd and debuggerd.exy to sd card just in case and then deleted the ones in system/bin, that are doing all the damage, via es file explorer with root access coz couldnt be deleted any other way and its been 3 days since and it didnt come back and all is clean on su logs no more requests from it.
By the way its got nothing to do with 4.1.2 sitting with exynosabuse.apk as im still running 4.1.1.
Problem solved...uptill now.
Click to expand...
Click to collapse
I am getting "debuggered.exynosabuse cannot be deleted" when I try this method
EDIT: didn't have it set to write, got it to work. Will report back in a few days on whether or not it shows up again.
---------- Post added at 02:39 PM ---------- Previous post was at 02:23 PM ----------
UtkarshGupta said:
It is probably a malware.
Update to 4.1.2 asap.
Sent from my GT-N7100 using xda app-developers app
Click to expand...
Click to collapse
Others in this thread have said that updating doesn't fix the problem, and that it's actually more persistent on 4.1.2
I appreciate offering your assistance, but does anyone know for certain what's going on or are we all just speculating?
I have a rooted HTC Desire, running Cron Mod-1.0.7.
Ever since I rooted it whatever OS I install there is no bluetooth, I even tried reflashing the stock RUU for it but that didn't work.
I did some research on this page, and decided to update the radio to 32.49.00.32U_5.11.01.27, and have tried a few different RIL versions. All have done nothing.
So I ran a log while trying to enable bt, and discovered that this happens:
"E/bluedroid( 1010): bt_enable: Timeout waiting for HCI device to come up"
So i then ran this:
"$su
# bluetoothd -n
bluetoothd[4428]: Bluetooth deamon 4.69
bluetoothd[4428]: Starting SDP server
bluetoothd[4428]: opening L2CAP socket: Operation not permitted
bluetoothd[4428]: Server initialization failed
bluetoothd[4428]: Can't open HCI socket: Operation not permitted (1)
bluetoothd[4428]: adapter_ops_setup failed
#"
I then ran "#strace bluetoothd -nd" and have a very large output file. I can post if it would be helpful.
But basically the output was that permission was denied opening a few files (/ect/bluetooth/main.conf; /dev/kmsg; /dev/socket/dbus).
Does anyone have any ideas about what the problem is and how to fix it?
Any help will be appreciated!
After fiddling with every possible options available, I think my phones lagging has to be a problem caused by a corrupt partition table. I first ran this command :
[email protected]:/ # dmesg | grep mmc0
dmesg | grep mmc0
And when I ran :
1|[email protected]:/ # dmesg | grep mmc
dmesg | grep mmc , I got :::
<3>[ 102.344421] mmcblk0: timed out sending SET_BLOCK_COUNT command, card status 0x400d00
<3>[ 102.344482] mmcblk0: command error, retrying timeout
<3>[ 102.345764] mmcblk0: timed out sending SET_BLOCK_COUNT command, card status 0x400d00
<3>[ 102.345855] mmcblk0: command error, retrying timeout
<3>[ 102.346282] mmcblk0: timed out sending SET_BLOCK_COUNT command, card status 0x400d00
<3>[ 102.346405] mmcblk0: command error, retrying timeout
<3>[ 102.346893] mmcblk0: timed out sending SET_BLOCK_COUNT command, card status 0x400d00
<3>[ 102.347015] mmcblk0: command error, retrying timeout
<3>[ 102.347595] mmcblk0: timed out sending SET_BLOCK_COUNT command, card status 0x400d00
<3>[ 102.347747] mmcblk0: command error, retrying timeout and so on.
Full log available here : http://pastebin.com/9VRqRez8
I can access fastboot/Downloading mode without hassle. Making the adb working or getting past the first launch screen is a real pain.
I tried repartitioning using ODIN using I9250_partition-table-0915.pit and it was a success. Even I tried to flash stock ROM using ODIN v1.85. Even though it was a success, old ROM keeps loading up.
Is there anything I can do?
Is there anything that I can do?