Related
I don't have data to spare to test things myself until next month, and have a fairly stable PPP setup anyway.
But I figured if someone wants to experiment the following might be worth a shot.
What I've done is attach a zip with 4 sample options files for pppd that attempt to address issues I've seen with pppd. Specifically the crash with memory issues due to compression, and pppd dying when disconnected and needing to be restarted (eg by LeTama's v0.3 wrapper). If you want to try these out I would suggest using them in conjunction with his wrapper as I'm unsure how other versions may work: http://forum.xda-developers.com/showthread.php?t=824413
The 4 versions for testing are as follows:
option1
- Makes the buffer size used for compression as small as possible.
- Tries to make the connection persistant.
option2
- Disables compression.
- Tries to make the connection persistant.
option3
- Makes the buffer size used for compression as small as possible.
option4
- Disables compression.
To use them they will need to be copied to your /etc/ppp/ folder as "options" and you'll need to ensure it's readable.
If you don't know what I mean I suggest you don't bother trying this.
If you do know what you're doing then you can try experimenting with the different options and see if they make things better/worse.
option3 is probably the safest, option4 may be needed if things still crash due to memory issues with option3.
option1 would be the ideal, but I can't guarantee the persist option is possible.
If option1 or option3 prove to improve things and prevent the crash, then the values used could be slowly increased (to a max of 15) to see if crashes start happening again.
Anyway, just something else the more adventurous and tech savvy users out there with PPP issues can try.
Can I copy these over via ADB push while Android is running, or do I need to put them in the Android root folder so they'll get copied into place on reboot?
Well with Option 1 the data connections drops almost instantly, Option 2 is doing without drops for 10 min now, but it is too early to say if it's an improvement over the old options.
Does compression influence the connection speed? Option 2 works as fast as possible on HSDPA... Option 2 dropped after about 15 minutes when downloading from the market, but downloading from the market was much faster than before.
Should we be copying it as "options" with no file extension or "options.smd"?
Probably as options.smd, that's what I did and it seemed to have some effect...
Now testing option3, will mess with it for the rest of the day and see what happens. At first glance, it seems a bit slow, but that's anecdotal at best.
MAsterokki said:
Well with Option 1 the data connections drops almost instantly, Option 2 is doing without drops for 10 min now, but it is too early to say if it's an improvement over the old options.
Does compression influence the connection speed? Option 2 works as fast as possible on HSDPA... Option 2 dropped after about 15 minutes when downloading from the market, but downloading from the market was much faster than before.
Click to expand...
Click to collapse
Seems like I drew my conclusion from Option 1 too early, after a reboot it works great, I have been downloading MDJ newest rom for 10 min now which resulted 20% of 170mb (from multiupload). No drops untill now, definitely a huge improvement over the old options.smd. Thanks alot Hastarin!
question when i get to the ppp file in i see options.smd and a options.smd1 do i just add this new option to it or delete the old ones and replace with this one?
imphoking said:
question when i get to the ppp file in i see options.smd and a options.smd1 do i just add this new option to it or delete the old ones and replace with this one?
Click to expand...
Click to collapse
I would backup your original files first, although the orig options.smd is probably blank anyhow.
Replace the options.smd with the renamed options from hastarin.
Hastarin, do you happen to know the default options when we were using the default "blank" options.smd? Does it use compression etc. Thanks for your efforts!
noellenchris said:
Hastarin, do you happen to know the default options when we were using the default "blank" options.smd? Does it use compression etc. Thanks for your efforts!
Click to expand...
Click to collapse
The wrapper supplies nodetach, debug and something I can't recall atm (should be in IRC logs).
Compression will be used by pppd by default but I couldn't find information on what size buffer it uses by default.
Google pppd man page for more information.
You are right about options.smd being the safest option. Using options file may affect other things that use pppd if there are any.
Sent from my HTC HD2
Option1 seems to be working fine for me right now. I will report more in a few hours while I'm out.
Hey just wanted to say that I am checking out these options also. So far using option1 and I haven't had any data drops or freezes. Haven't been able to test it extensively yet but will over the next few hours.
With option 1 can you make sure you can switch between WiFi and data and back again? And that you can turn mobile data off and on? And perhaps airplane mode and back to be thorough?
Thanks
Sent from my HTC HD2
It seems after some time options.smd gets reset to blank by itself? Anyone noticed?
Sent from my HTC HD2 using XDA App
memin1857 said:
It seems after some time options.smd gets reset to blank by itself? Anyone noticed?
Sent from my HTC HD2 using XDA App
Click to expand...
Click to collapse
I haven't rebooted yet, but mine is still there and not blank. I will try to toggle wifi etc next. Otherwise it's still rolling well, no disconnects yet or hangs.
memin1857 said:
It seems after some time options.smd gets reset to blank by itself? Anyone noticed?
Sent from my HTC HD2 using XDA App
Click to expand...
Click to collapse
I set mine to read only in case this actually happens lol.
noellenchris said:
I haven't rebooted yet, but mine is still there and not blank. I will try to toggle wifi etc next. Otherwise it's still rolling well, no disconnects yet or hangs.
Click to expand...
Click to collapse
Lucky.. I still can't get mine to last longer than 5 seconds.
Ok with option1 I started experiencing some data freeze again. It happened while downloading a large file and then again when I switched to wifi tethering. The freeze actually freezes my entire system and then my phone runs really really slow. It may be the build that I am using so I am going to try an older build that did not seem to have this problem. I will run option1 for a while again and then try the others.
Option 1 is no good - I think the persist option keeps 3g "connected" even though I'm getting timeouts, instead of dropping and reestablishing data connection.
Will test the other options once I upgrade to 0.4 ril wrapper and S4 mdeejay kernel.
EDIT: oh yeah, I noticed though the default options.smd is blank, when pppd is running it creates a options1.smd in /etc/ and it has the words "user dummy" in it?
I'm using CM, at the moment rc1, and am quite happy with it. There are only a very few things I'm missing from the official HTC-release. So I tried the vodafone-FroYo. Most things worked ok, but streaming AAC-internet-radio at low bandwith sounds terrible. I'm listening to the following stream via "A Online Radio": http://listen.di.fm/public2/house.pls
With CM rc1 this stream sounds very ok, even if it is only 40k. Same when I play it on my notebook. When I try to listen to this stream with the new FroYo, it sounds as if it was a 40k mp3-stream. I've tried also XiiaLive to be sure, that it isn't a problem of the app.
For now I restored to cm rc1, but I wonder if this problem can be reproduced on other handsets as well, and if yes, if there could be any solution to this.
*Bump*
160 Views an none could at least say "Yeah, it's the same here" or "Nope. check your handset, non problems here"?
Same here, looks like AAC+ is being decoded as plain AAC-LC, missing the SBR, even at 64kbps you can head the difference
Thanks a lot for testing! So this seems to be really a problem with htc FroYo. Next question would be, if it would be possible to install the missing parts. This should be a job for the chefs in here... Anybody?
Googled now a little more, this is an issue with FroYo in general and is fixed in git since august this year. See:
http://code.google.com/p/android/issues/detail?id=9308
Fix: http://android.git.kernel.org/?p=pl...it;h=16263d9f8cc01392c2f3678b381ce897647c8c81
It seems, that cyanogenmod has implemented this fix already in their source, so thats why I have no problems there.
does not work for me
i get a "cannot find path" when i try
"adb shell curl http://android.git.kernel.org/repo > ~/bin/repo" (mentioned in http://android.git.kernel.org/?p=pla...1ce897647c8c81)
i tried to install blay0's system overlay script but it didn't work out. ROM Manager reboots into the red "!" in the triangle.
i dont want to S-OFF, any ideas?
While poking around today, I discovered that I could deterministically cause "rild" to segfault - every time I tried it.
The method I used was to turn on WiFi with the Mobile Data network already running, and then I would launch the app "Wifi Analyzer" (farproc). Almost immediately the "rild" (Radio Interface Layer Daemon) would segfault. (Strictly speaking, I don't know if using WiFi Analyzer was necessary - my WiFi has beacons turned off, and sometimes I can't establish a session straight away; using a scanner seems to get my AP to come out of it's sleep).
That consistency convinced me to use strace to attach to the already-running "rild" daemon, and spew to a log file.
Note that historically, the SIGSEGV faults that were logged to the logcat output at the moment of the "undead call" implicated a problem in the fclose() call - almost as if something was trying to close a file that had not been opened correctly.
So, there in the strace output, was this:
Code:
16:43:23 writev(6, [{"\3", 1}, {"HTC_RIL\0", 8}, {"(t=1297817003)%% $HTC_3GIND:0\\r\\n\0", 35}], 3) = 44
16:43:23 open("/data/data/com.android.dmportread/history", O_WRONLY|O_CREAT|O_APPEND, 0666) = -1 ENOENT (No such file or directory)
16:43:23 chmod("/data/data/com.android.dmportread/history", 0666) = -1 ENOENT (No such file or directory)
16:43:23 writev(6, [{"\3", 1}, {"HTC_RIL\0", 8}, {"at_notify_cdma_g23_data_entry():Can't open /data/data/com.android.dmportread/history successfully \r\n\n\0",102}], 3) = 111
16:43:23 --- SIGSEGV (Segmentation fault) @ 0 (c) ---
a quick peek at /system/lib/libhtc_ril.so shows that - yep - buried in there is a reference to
/data/data/com.android.dmportread/history
So, I tried the following:
Code:
[COLOR=green][B]
mkdir /data/data/com.android.dmportread
chown radio:radio /data/data/com.android.dmportread
touch /data/data/com.android.dmportread/history
chown radio:radio /data/data/com.android.dmportread/history
[/B][/COLOR]
and guess what - no more segfaults. [SIZE=+3]YES![/SIZE]
If this is the cause of the "undead" call (seems highly likely), the explanation appears to be due to a bug in the HTC vendor library lbhtc_ril.so : a file open() fails, but the corresponding "close()" operation takes place anyway, and that is where the fault (segmentation violation) occurs. There is a stupid dependency of the libhtc_ril.so file on the DMPortRead.apk app.
Probably the only reason that this bug does not express itself in HTC "factory" 2.1 ROMs is because of the presence of DMPortRead.apk app - presumably that creates/maintains the history file.
[SIZE=+1]See the 3rd post of this thread for downloadable patch/script files[/SIZE]
If any of you are consistently experiencing the "undead call" problem, please consider testing the above to see if you think it is the fix. (I believe it is.)
bftb0
I knew I liked you!
I'll have to try this out when I get home.
Here's a flashable .zip and also a shell script which may be used in Gscript lite - you need to unpack the "unpackme.zip" file to get to them. ("unpackme" is NOT flashable).
I realized after I was 95% of the way through putting together the installer script that there was absolutely no reason to do this in an offline fashion (that is, "overflashing" it during a recovery boot) - it is perfectly fine to do what needs to be done in a shell script any time you please with the regular OS is running. Oh well, the ROM devs can look at it and use whatever they want from it (or nothing at all).
You can run the CureUndead_v0.9.sh script either from within the Gscript Lite app (you need to give the script root privilege), or you could use adb to push it to /data/local and chmod it and execute it by hand. Note that Gscript Lite on GingerBread has this annoying bug where it prints "stderr:" for every line in the original script. It's not my script that's doing that - it's either a problem with Gscript Lite, or something unusual about GSB.
Oh, yeah - the way the script is written, you can run it as many times as you want; as a side effect, this will truncate to zero length any prior history file.
MD5's and sizes of contents of "unpackme.zip":
0bf8c49312e61c436d379a24255b12f3 CureUndead_v0.9.sh - 421 bytes
9d459f9f598f51fffa98cf832c524e50 CureUndead_v0.9.zip - 2,678 bytes (this one is flashable)
Going to try it out... Thanks for this!
nice work...
Very interesting... so this is something that would need to be done post flash, what do you think...
... we use that lights.sh script conap put together in /system/xbin/ that runs @ every boot to initialize the lights for trackball/notifications... would it work if I added the lines to that? I'm not sure if it would cause issues running it @ each boot or not?
Trying to figure out a different way to add this pre-build too.
This is huge if it's the fix. Incredible work.
oceanminded said:
This is huge if it's the fix. Incredible work.
Click to expand...
Click to collapse
I think it is the fix
workshed said:
Very interesting... so this is something that would need to be done post flash, what do you think...
... we use that lights.sh script conap put together in /system/xbin/ that runs @ every boot to initialize the lights for trackball/notifications... would it work if I added the lines to that? I'm not sure if it would cause issues running it @ each boot or not?
Trying to figure out a different way to add this pre-build too.
Click to expand...
Click to collapse
Well, I'm putting together a flashable "fix" file that just uses the installer script, so it could be rolled up into a ROM install as well.
The one thing you might want at boot (rather than only at ROM install time) is some kind of zero-ing out of the history file every once in a while, so that it doesn't grow without bound. I only watched it for a short period of time, and it was only 4 lines long; it might not ever grow big, but that seems like the right thing to do.
So I guess I'll wait until one of you genuises makes this "point and click" simple. I don't have a clue how to implement this on my own. Awesome work bftb0 !
Sheesh you're a brain OP. Awesome job!
Sent from my Ginger Tazz using XDA App
Interesting... what's the undead call bug you're talking about? I've been getting this funny bug on long calls where sometimes the phone app just crashes after 15-30mins or so. I get the crash window, and if I force quit, it shows no signal until I reboot the phone. If that's the one, a fix would be really nice. Running KaosFroyo v39 and never flashed a new radio BTW.
I've also seen the same thing on the WiFi signal. I have SSID broadcast turned off, and it takes it's sweet time picking it up on its own, but running WiFi analyzer seems to wake it up.
ufmace said:
Interesting... what's the undead call bug you're talking about? I've been getting this funny bug on long calls where sometimes the phone app just crashes after 15-30mins or so. I get the crash window, and if I force quit, it shows no signal until I reboot the phone. If that's the one, a fix would be really nice. Running KaosFroyo v39 and never flashed a new radio BTW.
I've also seen the same thing on the WiFi signal. I have SSID broadcast turned off, and it takes it's sweet time picking it up on its own, but running WiFi analyzer seems to wake it up.
Click to expand...
Click to collapse
What he is referring to is during a call you get the tones and vibration like the call has been dropped but then you can hear the person on the other end again and the call was never dropped. What you are describing is a new one to me...
CondemnedSoul said:
What he is referring to is during a call you get the tones and vibration like the call has been dropped but then you can hear the person on the other end again and the call was never dropped. What you are describing is a new one to me...
Click to expand...
Click to collapse
Ah yeah, I've had that happen too. I didn't think of it, though, since it wasn't all that annoying to me. I already ran the fix anyways, so I'll see if it helps either problem.
I haven't had the problem for some reason, but I just entered all that in a terminal window on my phone (and wasn't that tedious). Thanks!
Scott586 said:
So I guess I'll wait until one of you genuises makes this "point and click" simple. I don't have a clue how to implement this on my own. Awesome work bftb0 !
Click to expand...
Click to collapse
I put up a script in the 3rd post in this thread which you could use in the Gscript Lite app. You will still need to figure out how to use Gscript Lite, but at least no "adb" or command-prompt typing is needed.
Everybody else - I would appreciate hearing back from you after you try this, especially if you have been experiencing the "undead call" bug frequently. (I've used my phone for calling so little recently I don't think it has happened to me in more than 5 weeks.) The more often it was happening to you in the past, the more valuable your feedback is now.
bftb0
bftb0 said:
I put up a script in the 3rd post in this thread which you could use in the Gscript Lite app. You will still need to figure out how to use Gscript Lite, but at least no "adb" or command-prompt typing is needed.
Everybody else - I would appreciate hearing back from you after you try this, especially if you have been experiencing the "undead call" bug frequently. (I've used my phone for calling so little recently I don't think it has happened to me in more than 5 weeks.) The more often it was happening to you in the past, the more valuable your feedback is now.
bftb0
Click to expand...
Click to collapse
thanks for the script bf, that's all I needed to add it in the rom. I'll be a tester also, as I do experience the bug quite often, but only on long calls which isn't as frequent for me currently. Bravo sir!
P.S. I will be sure to add "# Undead call fix by bftb0" in the rom and OP page
workshed said:
thanks for the script bf, that's all I needed to add it in the rom. I'll be a tester also, as I do experience the bug quite often, but only on long calls which isn't as frequent for me currently. Bravo sir!
P.S. I will be sure to add "# Undead call fix by bftb0" in the rom and OP page
Click to expand...
Click to collapse
dope
this is good news. great job op and workshed if u add it to your gb rom lol
love you both!
flashed it on gsb1.4. i'll let you know how it goes.
:O OMG! That always happens, but I thought I was crazy XD So I'm going to try this.
Sent from my Droid Eris ♥ (running Ginger Tazz v5 [eat your heart out Jobs])
i am running cm7 nightly 44 on my DX and ive installed the v6 surpercharger with awesome results, when i tried out the 3g turbocharger, and kernel tweaks, i reboot like SM says and when i do, i get no data no cell signal wifi wont work, and airplane mode wont toggle. ive tried a few times with the same results. Ive searched and found nothing specific to my setup either. what am i doing wrong? any help would be appreciated! thanks!
You probably have 2.3.4 and its made for 2.3.3.
Sent from my DROIDX using XDA App
Actually I'm on 2.3.5 so that explains it too
It's weird... on the same phone wifi will be fine with stock but not okay with a custom rom.
Android version doesn't matter.
But I made a change to 3g TurboCharger that needs testing...
Edits to build.prop...
Code:
ro.ril.hsxpa=3
ro.ril.gprsclass=34
ro.ril.hep=1
ro.ril.enable.dtm=1
ro.ril.hsdpa.category=28
ro.ril.enable.a53=1
ro.ril.enable.a52=0
ro.ril.enable.3g.prefix=1
ro.ril.htcmaskw1.bitmask=4294967295
ro.ril.htcmaskw1=268449905
ro.ril.hsupa.category=9
ro.ril.def.agps.mode=2
ro.ril.def.agps.feature=1
ro.ril.enable.sdr=1
ro.ril.enable.gea3=1
ro.ril.enable.fd.plmn.prefix=23402,23410,23411
ro.ril.disable.power.collapse=0
Difference between this and update 2:
ro.ril.gprsclass=34 (instead of 12)
ro.ril.htcmaskw1=268449905 (instead of 14449)
I've actually seen gprsclass=32 in the past but 12 is the most common setting so I had used 12.
After researching today, seems that 32 would indeed be better than 12 BUT there is a new gprs class 34 so this would be a first for testing it at 34! (as far as I know) lol
So, I'd be interested in seeing if this is better than the 3G TurboCharger update 2 tweak
Ill try the update ill let you know. Thanks.
Or how would I implement that? Editing the build.prop?
yes.. if you have update 2 applied it only involved changing 2 entries
I applied both tweaks and edited the build.prop with the new values you suggested and with 34 I got no 3g no cell signal airplane wouldn't toggle and error when turning on wifi. I then tried 32 and no 3g no cell signal and error for wifi but airplane would toggle then.
ok.. 34 is out of the equation...
At 32 its the same as before
Well I wonder what's not working then I apply the kernal tweaks first then 3g Turbo then reboot. All with script manager
Does the baseband matter?
Does the 3g turbocharge work on all android devices or strictly the DX? I want to do this on my Evo 4g, but the process seems a bit over my head.
Is the increased 3g speed attributed to ONLY the changed values in the build.prob? If so, can this be done manually by editing build.prop with a text editor, to achieve the same results?
Evo! said:
Does the 3g turbocharge work on all android devices or strictly the DX? I want to do this on my Evo 4g, but the process seems a bit over my head.
Is the increased 3g speed attributed to ONLY the changed values in the build.prob? If so, can this be done manually by editing build.prop with a text editor, to achieve the same results?
Click to expand...
Click to collapse
I don't know about all android devices, but I have an EVO 4g, and it seems to work fine for me. Still messing with it cause i think the 98kickasskerneltweak isn't working, but I'm working on that now
Dramanis420 said:
I don't know about all android devices, but I have an EVO 4g, and it seems to work fine for me. Still messing with it cause i think the 98kickasskerneltweak isn't working, but I'm working on that now
Click to expand...
Click to collapse
Me too...
FYI...
Updated September 3: - V6 SuperCharger Update9 Beta3
Fixed - Cleaning of local.prop. It was leaving a mess behind.
Enhanced - User notification of events a little more
Updated September 3: - 98KickAssKernelTweaksInstallerUpdate3 test3
Fixed - A big error (I doubt the io scheduling tweaks were being applied in Update 3 test 2)
Improved - Application of io scheduling tweaks so that it is much more selective and safer
Runs - 98kickasskernel after creating 98kickasskernel!
Notifies - You of the I/O Scheduler in use - Before AND After running 98kickasskernel
Defaults - To using Deadline (of available) instead of Noop io schedular.
Updated September 3: - 3GTurboChargerInstallerUpdate3 test 9
Added - Complete menu with 4 configurations!
Installs - /sdcard/3GTurboCharger.txt which has specific details of the 4 options.
This is what it looks like:
Code:
================================================
\\\\ 3 G T U R B O C H A R G E R - M E N U ////
==============================================
1. Fast?
2. Faster?
3. Fastest?
4. Experimental!
5. UnTurboCharger
6. REBOOT! (WARNING - There is NO Warning!)
7. Exit
Your Mileage WILL Vary!
View settings in /sdcard/3GTurboCharger.txt!
Test all 4 to see which works best for you!
The SpeedTest.Net app is highly recommended :)
Please enter option [1 - 7]:
Download from the usual place http://forum.xda-developers.com/showpost.php?p=15948434&postcount=1127
All 4 updated files are 100% untested by me... so good luck
How much speed increase does this actually help
Sent from my DROIDX using xda premium
Ok a couple of more updates... on account of me being a n00b
Updated September 4: - 98KickAssKernelTweaksInstallerUpdate3 test4
Tweaked - io scheduling tweaks some more so that it is even more selective and safer
Updated September 4: - 3GTurboChargerInstallerUpdate3 test 10
Fixed - Yesterday's file (Update 3 test9) didn't apply ANY variations so now it's fixed.
Added - Another configuration. Some people reported great results with yesterday's version (removes limits?) so added a "nulled" configuration.
what does 98KickAssKernelTweaks do?
I just bought a new nook simple touch and had assumed it would come with version 1.2.1 so I followed the instructions from this article on MakeUseOf.
As it turns out my Nook was on 1.1.0. Rooting seemed to go fine but I don't seem to have multi-touch. I haven't tried the 174 or 176 kernel instead taking the recommendation and using the one that jptiger put together in this thread.
So my question is: did I screw this up by not upgrading to 1.2.1 first? If I go to settings it still shows the software version as 1.1.0 even though I've rooted. How can I ensure I've got the latest/greatest kernel?
EDIT: Ok, I upgraded to 1.2.1 and then rooted again. Multi-touch still doesn't seem to work for me. Did I miss something?
Do you have the right kernel? (I've lost track of them.)
Did you modify /system/etc/permissions/required_hardware.xml:
Code:
<feature name="android.hardware.touchscreen" />
[b]<feature name="android.hardware.touchscreen.multitouch" />[/b]
Renate NST said:
Do you have the right kernel? (I've lost track of them.)
Did you modify /system/etc/permissions/required_hardware.xml:
Code:
<feature name="android.hardware.touchscreen" />
[b]<feature name="android.hardware.touchscreen.multitouch" />[/b]
Click to expand...
Click to collapse
I do have both those lines in my required_hardware.xml file. As for the kernel, I read on another forum that this was the latest/greatest.. if there's another recommendation I would love to have it!
Thank you!
Hmm.. I wonder if it actually works but it's not supported in the default browser app or Opera Mobile. Possible?
Yes, that's possible.
Load UsbMode.apk from the signature.
Among the things it does, it shows you touches.
Just touch anywhere that isn't buttons.
(On my cell phone, it will show that it tracks 5).
I installed your app and when I touch the screen two places I see that it's captured and two sets of coordinates show up.
But when I use an app like reddit is fun I can't zoom in on images or anything although this works with the same app on the my Nexus 4.
It's obviously not critical but it's confusing me as to why it registers in your app and yet I can't seem to use the functionality. Bad choice of kernel?
UsbMode is just showing what should be available to any app.
Are you certain that the exact same apk is running on both devices?
I don't know that application at all.
Renate NST said:
UsbMode is just showing what should be available to any app.
Are you certain that the exact same apk is running on both devices?
I don't know that application at all.
Click to expand...
Click to collapse
Most likely different versions of the same app. Also it turns out I had Opera Mini installed instead of Opera Classic. The latter supports multi-touch zooming just fine so it's definitely an app level issue. Mystery solved - thanks for the guidance!