Dear All,
I modified libhtc_ril_wrapper to possibly fix the pppd disconnection problem.
As I don't have 3G at home, I'd appreciate some feedback to help me diagnose potential issues with it.
WARNING, there are reports of crash at boot, do a backup of your whole android directory before trying this!
Don't run this if don't have adb and know how to use it.
See post #2 for history and more information
To keep the thread clean, please only report problems and try to avoid unnecessary talking about it.
Don't report problem without logs, it won't help.
This is highly experimental, don't use it if you don't know what you're doing.
To install, just rename your previous wrapper and copy the attached libhtc_ril_wrapper.so to the same location.
Here are the logs I need:
Code:
logcat -d -v time -b radio > /sdcard/pppd_radiolog.txt
logcat -d -v time -s pppd:v > /sdcard/pppd_mainlog.txt
dmesg > /sdcard/pppd_dmesg.txt
/bin/ifconfig > /sdcard/pppd_if.txt
ps > /sdcard/pppd_ps.txt
Please review pppd_radiolog.txt before posting, it could show some personal stuff like phone numbers, feel free to remove these lines or refrain to post them
Wait 20 seconds to let the wrapper relaunch pppd and check connection again. If it doesn't work, please send the logs.
Grab the three files from sdcard root and post them back here.
I'm also experimenting some kernel tuning that can be activated with this:
Code:
echo 8 8 > /proc/sys/vm/lowmem_reserve_ratio
echo 8192 > /proc/sys/vm/min_free_kbytes
Nothing conclusive yet, but it seems to help.
Thanks to Hastarin, I also attached his root package that includes wrapper with ppp options and tweaks.
Thanks,
LeTama
History
2010/11/24 Hastarin root package (ppp_tweaks_root.zip) added, it includes wrapper, ppp options and kernel tweaks.
2010/11/18 new kernel and wrapper v0.7
new test kernel with smd_tty trimmed to 2K.
wrapper fake data call list has now active=1
v0.6 - 2010/11/17
same as 0.5 without the stupid bug that trashed the code.
2010/11/16
Test kernel to diagnose the "tty_prepare_flip_string fail" error with high cpu usage, please check post here for detail
v0.5: delay changed for deactivate and fake data call list added.
v 0.4 - 2010/11/14
Changed tag to RIL_WRAP to improve log reading
Improved log messages
Signal tracking to try to find who kills wrapper monitor
Lower delay between AT commands
Sleep delays and sequence reworked
Tentative improvement to re-establish ppp
Tentative fix for wrapper monitor death with extra debug messages
Memory leak on deactivate fixed
v 0.3 - 2010/11/02
added network state detection to avoid doing ATD too early resulting in getting stuck.
changed nand handling, proper initialization for nand is now done by adding "nand_init" to wrapper command line in init.rc.
(Ex: service ril-daemon /system/bin/rild -l /system/lib/libhtc_ril_wrapper.so -- -d /dev/smd0 nand_init)
added a wrapper command line switch "rmnet_mode" for rmnet, "active" file in /etc/ppp is no longer used nor required for ppp.
v 0.2 - 2010/10/31, first release
restarts pppd when it dies
Troubleshooting
How to verify if wrapper is running:
In radio log (logcat -b radio -d), my wrapper write this at startup (do it quickly after boot, it disappears quite quickly over time):
Code:
----------- HTC Ril Wrapper v0.7 starting ------------
and you should have debug messages there starting with RIL_WRAP, not RILW.
Crash on boot (v0.2):
Check if your kernel command line in startup.txt has "nand_boot=0". If it still doesn't boot, try to remove any other option and only keep "nand_boot=0"
Troubleshooting crash on boot
Even if it crashes very early, it should be possible to grab early logs. To do that, start adb *before* starting android with this command:
adb logcat -b radio -v time
adb should say *waiting for device*, you can then start Android. Adb will show some logs before the device crashes. Please send me the logs if you are able to do so.
If you see [email protected]=0 in the log, it means that the wrapper thinks you are on nand, and that's why you device crashes.
pppd-fix
I saw in some logs that some are using Cass pppd-fix script with the wrapper. Cass script and wrapper are doing the same thing and are conflicting. So, if you have installed the pppd-fix, please remove it, it won't play nice with the wrapper.
Known issues
2010/11/14: pppd first launch fails after boot. wrapper catch it, however it would be nice to have it working the first time. It adds few seconds to re-establish data, so be patient!
2010/11/14: high cpu consumption. The issue comes from memory management in kernel, we still have to figure out what's happening.
2010/11/04: pppd monitor process seems to die from time to time. I don't know why yet, looking at the code it doesn't seem possible. I'll look into it and maybe release a new version with more debug traces. You can see it in terminal by doing a 'ps', it will show one of the rild as zombie ( Z instead of S just before process name). The easiest way to restart it is to do a data off/on.
Hi letama,
Currently i'm using ppp-fix. Can I contribute here? or I have to remove the script from init.rc then I reboot the device so I can contribute?
nice
try now
Hi LeTama,
thank you for your work.
It seems that your fix work. I don't notice any dropouts.
But that could be a reason of the issue that the phone does not start android.
It boots WM then haret and then it freezes on the black screen with the green HTC logo...
I use [UPD][BUILD][30.10.10] MDJ FroYo Revolution v.1.1 [kernel: hastarin R8] and after copying your file with ES explorer I've rebooted the phone and now it hangs on the htc screen after running haret...
But the good news are, the dropouts are gone
Sorry but I can't post logcat messages without booting android complete
Which build do you recommend?
funky81 said:
Hi letama,
Currently i'm using ppp-fix. Can I contribute here? or I have to remove the script from init.rc then I reboot the device so I can contribute?
Click to expand...
Click to collapse
Hi Funky81,
Well, it's better to remove ppp-fix as I do the same thing in the wrapper now. The way it's done in the wrapper is cleaner and should have the same effect.
You can just comment it in your init.rc if you want to keep it, but keeping it active could have side effects.
Crusoe86 said:
Hi LeTama,
thank you for your work.
It seems that your fix work. I don't notice any dropouts.
But that could be a reason of the issue that the phone does not start android.
It boots WM then haret and then it freezes on the black screen with the green HTC logo...
I use [UPD][BUILD][30.10.10] MDJ FroYo Revolution v.1.1 [kernel: hastarin R8] and after copying your file with ES explorer I've rebooted the phone and now it hangs on the htc screen after running haret...
But the good news are, the dropouts are gone
Sorry but I can't post logcat messages without booting android complete
Which build do you recommend?
Click to expand...
Click to collapse
You have adb on you pc ? You should be able to run adb even if android is not fully started.
With it, you can get logcat and even rename back the old wrapper to see if it starts booting again.
So far it's working very nice, I will be out and about today and will try to crash your masterpiece...
I just wanted to publicly say a big "THANKS" for helping everyone out with the PPP issues, you have always listened when I've popped in on the IRC and asked questions and relayed info from XDA. Thanks for your time and expertise. Your DEV work has not gone unnoticed!
Now get ready to fix the wrapper after we all crash it. Or read all the post on how your wrapper has made their microwave burn their popcorn and how their wifi can now communicate with the satellites....bla....bla.......
noellenchris said:
So far it's working very nice, I will be out and about today and will try to crash your masterpiece...
I just wanted to publicly say a big "THANKS" for helping everyone out with the PPP issues, you have always listened when I've popped in on the IRC and asked questions and relayed info from XDA. Thanks for your time and expertise. Your DEV work has not gone unnoticed!
Now get ready to fix the wrapper after we all crash it. Or read all the post on how your wrapper has made their microwave burn their popcorn and how their wifi can now communicate with the satellites....bla....bla.......
Click to expand...
Click to collapse
Hehe...that may not happen. At least for my copy. I am giving mine a thorough flogging with Speed Test and can't make the data freeze. And I'm seeing over 3000Kb/s HSDPA speeds...with the common, single APN settings. By the way, I'd like to thank both of you for your hard efforts.
testing...
testing now... thanks!
letama said:
You have adb on you pc ? You should be able to run adb even if android is not fully started.
With it, you can get logcat and even rename back the old wrapper to see if it starts booting again.
Click to expand...
Click to collapse
Sadly I got the same problem and it's the initial logo screen it's hanging at, not the boot animation, so no adb shell is possible. I did get you a dmesg via andlog though (attached).
Time to restore a copy of system.ext2 that I backed up before... Oh wait, I didn't. Oh well, time to restore the copy from the original build.
To anyone trying this I suggest first taking a copy of the system.ext2 from your Android folder, just in case. At least if you'd tweaked anything in it already (build.prop for example) like I had.
On the plus side I did setup a gscript with the commands you noted and test it before I rebooted the phone. From that I noticed I had some errors in my logs already. I've attached them in case they help. NOTE: This is on my kernel and it almost seems like your patch to hi/lo-mem and my patch to move ppp compression to hi-mem have countered each other. It's getting late here so I'll have to continue experiments tomorrow after work.
Hope this helps
Here you go. I had a disconnect and sync fail (Exchange Server).
And Another
Same as before
Dr Nicky said:
Here you go. I had a disconnect and sync fail (Exchange Server).
Click to expand...
Click to collapse
Dr Nicky said:
Same as before
Click to expand...
Click to collapse
crashes when your on exchange? were you doing anything else. Hmm, sounds like the same used to happen to me sometimes. But it's working ok now with this wrapper. Did you try to repush the wrapper on reboot?
hastarin said:
Time to restore a copy of system.ext2 that I backed up before... Oh wait, I didn't. Oh well, time to restore the copy from the original build.
Click to expand...
Click to collapse
Hastarin, you can mount the ext2 on your pc and replace the file ?
Your log show a modem crash, weird.
letama said:
Hastarin, you can mount the ext2 on your pc and replace the file ?
Your log show a modem crash, weird.
Click to expand...
Click to collapse
Yeah, mdeejay even sent me a whole build he had working with the wrapper and I got the same crash.
I'm back up and running now. Restored the original system.ext2 from the build and reapplied my few tweaks.
FYI I'm going to try the following in my init.rc
Code:
# Tweak inode caches
write /proc/sys/vm/vfs_cache_pressure 200
Based on this:
http://www.cyberciti.biz/faq/linux-page-allocation-failure-erro/
But now it's approaching 4am here and I really must sleep.
PS Giving up on testing your wrapper for now. It just really doesn't like me.
noellenchris said:
crashes when your on exchange? were you doing anything else. Hmm, sounds like the same used to happen to me sometimes. But it's working ok now with this wrapper. Did you try to repush the wrapper on reboot?
Click to expand...
Click to collapse
They were both forced repush. The only way I could get the radio back on line was to do a Hot Reboot.
Dr Nicky said:
Same as before
Click to expand...
Click to collapse
Thanks for the logs! Unfortunately, they are showing that the wrapper restarts pppd and it doesn't seem to go bad. Could you give me the dmesg also ?
Could you also show me /bin/ifconfig result ?
LeTama
I'm having the same issue as Hastarin - well, I've been using his latest kernel. Doesn't even boot.
Instead of restoring system.ext2, I just pushed an older lib and went back to the old method of restarting pppd.
My own logs for a dropout that just occurred (3G/H icon vanished while loading a web page). For me, the wrapper didn't work with Hastarin r8, but does with r7.7.
Thanks for looking into this!
Hey all,
running CM7 (in particular this), and have always experienced these random reboots since I rooted/ROM'd etc.
I have worked out it is to do with 3G/4G data connection and/or swapping back to 2G to save battery or something along those lines. I have tried different radios, but not other ROMs (dont particularly want to change ROM).
My question is, is there a log file or some sort of diagnostic i can run to see exactly the cause so i can better find a fix/report the bug?
Cheers.
Ye, just write su than logcat > /sdcard/logcat.txt in terminal emulator this will save the logcat to the logcat.txt file, you can than copy that to your pc and see what happened before the reboot.
I'm going to try and provide a log too. Problem is, I usually only notice it after a while, when I take my phone and see that it has rebooted and waiting for PIN.
crnkoj said:
Ye, just write su than logcat > /sdcard/logcat.txt in terminal emulator this will save the logcat to the logcat.txt file, you can than copy that to your pc and see what happened before the reboot.
Click to expand...
Click to collapse
Thanks man, will do this very soon and post my log (if thats ok? and if there isnt anything personal in there)
EDIT: Holy c***. its 14,500 lines of code... what should I be looking for?
I have found there are several errors relating to GTalk (which i never/cant use). I didnt realise I hadnt Frozen this with Titanium Backup, so I have done that now.
I was also getting errors relating to sqlite and the Market, but not sure this is causing any reboots as yet, the error was as follows:
Code:
I/Database(12351): sqlite returned: error code = 0, msg = Recovered 8 frames from WAL file /data/data/com.android.providers.downloads/databases/downloads.db-wal
I will see if I get any more reboots and let everyone know, but I suggest freezing GTalk as a start if you are getting reboots.
FWIW the culprit in my case was SKYPE
wintermute000 said:
FWIW the culprit in my case was SKYPE
Click to expand...
Click to collapse
Really! Interesting. Did you uninstall or freeze?
Also, I can tell you that freezing GTalk definitely has reduced the number of reboots, but not eliminated it. I have just tried uninstalling Skype (I never use it anyway) as wintermute000 suggested, and will follow up again in a few days.
Uninstalling Skype has greatly helped. Thanks wintermute000!
No worries. I just run skype when I need and exit fully when done, no need to freeze or uninstall
Sent from my Sony Tablet S using Tapatalk
You can redirect stdio (will increase logcat events):
http://developer.android.com/guide/developing/tools/adb.html
sometimes dmesg it's useful too...
OK, so here's the problem:
Twice now in short succession my Nexus 4 has frozen when exiting a particular game ("The Room" by Fireproof, as it happens) and, upon performing a reset the device has come back up in a bootloop - stuck on the animated "X" icon. To cut to the short of it, in both cases I ended up having to go into recovery and perform a data wipe to get the device operating again. The device is more or less stock, rooted with Franco's kernel (which I've never had /any/ problems like this with before!).
I'm not precious about my device, so this is little more than an inconvenience, but happening twice in a week means that that the engineer in me wants to understand /why/ it happened.
So, what advice do people have for diagnosing a failed boot? Let me get this clear, I'm not wanting help to get the device working again (I can do that myself) but more a discussion regarding how to find the underlying cause of this issue.
So, there's the dilemma. Anyone got any thoughts?
(ps. I don't want to put people off The Room. The game itself is absolutely marvelous and for the moment, I've switched to playing it on the N7 instead )
OK, so have a Nandroid of the failing image. Logcat is in memory, so is there anything to be learnt from the contents of this backup?
daern said:
OK, so have a Nandroid of the failing image. Logcat is in memory, so is there anything to be learnt from the contents of this backup?
Click to expand...
Click to collapse
OK, so it seems that there is likely no persistent logs, so I've restored the image back and then booted while capturing logcat. It isn't actually bootlooping, but rather it's just failing to boot. Logcat output attached. I've also attached a "good" logcat from a more or less clean image.
Looking at the logs, the last thing of consequence in the bad log is:
I/SystemServer( 498): Account Manager
...where as the good log continues:
I/SystemServer( 498): Account Manager
I/SystemServer( 498): Content Manager
I/SystemServer( 498): System Content Providers
So, any magic thoughts?
Anyone got any insight?
Noone?
Hi - I was wondering if I could get some assistance in an issue I'm experiencing please.
I'm trying to diagnose a particular "Unfortunately, Settings has stopped" error message and why I'm getting it - and I'm trying to use this as a stepping stone into getting back into Android programming.
I've had a look at the logcat logs and can't see anything that particularly matches that particular string, but I see a section that starts with
"[ 02-27 23:55:51.509 28773:29176 E/AndroidRuntime ]
FATAL EXCEPTION: pool-1-thread-1
java.lang.OutOfMemoryError"
Could someone tell me if this is indicative of that "Settings has stopped" error please ?
If so, then I do not see a line that gives a "Caused by" reason - is there any further diagnostics that I can do without having to resort to a full system restore ?
Thanks in advance.
downrange914 said:
Hi - I was wondering if I could get some assistance in an issue I'm experiencing please.
I'm trying to diagnose a particular "Unfortunately, Settings has stopped" error message and why I'm getting it - and I'm trying to use this as a stepping stone into getting back into Android programming.
I've had a look at the logcat logs and can't see anything that particularly matches that particular string, but I see a section that starts with
"[ 02-27 23:55:51.509 28773:29176 E/AndroidRuntime ]
FATAL EXCEPTION: pool-1-thread-1
java.lang.OutOfMemoryError"
Could someone tell me if this is indicative of that "Settings has stopped" error please ?
If so, then I do not see a line that gives a "Caused by" reason - is there any further diagnostics that I can do without having to resort to a full system restore ?
Thanks in advance.
Click to expand...
Click to collapse
Well an Out of memory error will cause a force close, so it should be the cause for the message you see. Out of memory means your app is trying to get more ram that it is allowed by the system. Most of the time this happens when dealing with large bitmaps (perhaps forgot to recycle them?) or in an infinite loop.
You'll have to manually debug the thread to see where the problem is.
SimplicityApks said:
Well an Out of memory error will cause a force close, so it should be the cause for the message you see. Out of memory means your app is trying to get more ram that it is allowed by the system. Most of the time this happens when dealing with large bitmaps (perhaps forgot to recycle them?) or in an infinite loop.
You'll have to manually debug the thread to see where the problem is.
Click to expand...
Click to collapse
Hi - many thanks for responding.
I'm sort of cheating a bit as I'm trying to diagnose a bug not of my own making - i.e. I haven't actually written an application - I've downloaded a few apps from the Google Play store and one (or more !) is causing them to crash with the aforementioned error when I go into Settings->Apps and I'm trying to localise which application it is.
As it was really bugging me I've since factory reset my phone, and the problem appeared when I installed the latest version of the Shazam app. More worrying is that I've uninstalled the app and carried out a power cycle of the phone and the issue is still appearing - which means either that :
a) Shazam has somehow corrupted the OS and the phone requires another rebuild
b) It's not Shazam
Unfortunately I have no idea on how to take this further
After working without a glitch for four years, my Nexus 7 (grouper) got stuck in a bootloop after I started it today. Thinking that something is probably wrong with cashe or dalvik cache I've cleared them. Now the bootloop is gone, but the device gets stuck on "Starting apps" after it finishes "optimizing" (filling in the dalvik cache). I would like to see what's going on but I have a problem doing that.
The problem is that I can't get the logcat to do the job. I've tried two "solutions" that seemed obvious, but (for some reason), none of them works.
First "solution": make a simple script and put it in /system/etc/init.d/:
#!/system/bin/sh
logcat > /sdcard/log.txt (set to 755)
I get the file, but even if I leave "Starting apps" to run for some time, when I turn off the tablet and look at the file it only has 65 lines and it still didn't finish initializing the hardware part. No information about started apps or anything. I can retrieve dmesg log from recovery but nothing interesting there as well.
Second "solution": I've tried to make it work trough init.rc, by following this https://stackoverflow.com/questions/17406209/enabling-logcat-in-init-rc (switched /cache/ to /sdcard/). But this also produces no results. Txt file is not generated at all
I don't know what I'm doing wrong.
I don't want to do a factory reset unless absolutely necessary (bunch of games with save files and other apps as well).
I can't do logcat trough adb since device is "unauthorized".
Any help is appreciated.
Thx in advance!
P.S. Using OmniROM (4.4.4)
Boot into TWRP and see if you can create or edit a text file. Reboot back into TWRP again and see if the change you made is still there. If it isn't, your flash memory has gone bad and you are in read only mode. This cant be fixed without a new motherboard. Hopefully this is not your issue.
Sent from my LGLS992 using Tapatalk
Sorry for the late reply, I was on vacation and I left the tablet at home.
The script I've mentioned was inserted trough TWRP so I think this confirms that you can write.
Also there is a log file created, as I've mentioned, it's just super short (I guess if it's in read-only mode there would be no output).