BlackGravity
Android Enthusiast
it works... 3 reboots and 3 sleep/wake's
settings stick...
i renamed as well,just in case something acts up.
settings stick...
i renamed as well,just in case something acts up.
-
After 15+ years, we've made a big change: Android Forums is now Early Bird Club. Learn more here.
Root v1.1 up for testing ***Umph Kernelv1 Now With Oddball***
- Thread starter pwnyourace
- Start date
-
- Tags
- motorola triumph
streetpounder
Well-Known Member
I`m going to dig and see if I can find what is keeping me and a handful of others from booting umph v1... Does anyone have any clues to what partitions might be different that aren`t touched by nandroid restore. I have a hard time believing that there is a hardware variance that is stopping it.
Pwn - If you don`t mind me asking what was changed to allow v1.1 and v1.2 to boot on us oddball devices?
Pwn - If you don`t mind me asking what was changed to allow v1.1 and v1.2 to boot on us oddball devices?
pwnyourace
Well-Known Member
definitely posting that in the OP thanks b_randon! gunna look into how to delete a file through the updater script and see if i can have it delete that file when it flashes the kernel. and getting it to run init.d scripts is in the ramdisk of the boot.img. and streetpounder um i dont know exactly what it was, i changed like 3 or 4 things like how doomlords was that i thought were causing it, when i get up tomarrow im gunna make a few tests for the "oddball" devices and see if we can pinpoint exactly what it is, thinking back on what i changed it explains the drop in performance and messed up behavior, one of the things i turned off (like doomlords) was group cpu scheduling. but like i said it was like 3 or 4 things so it shouldnt be that hard to figure out what it was and turn it off/on and have a release for those certain devices
streetpounder
Well-Known Member
Not trying to create more work for you, but thanks a million for keeping us in play! It`s just nagging at me that it doesn`t work the technician in me wants to understand the mechanics of why haha.
idbl_fanatic
Android Enthusiast
You need to reboot after rename/delete, mine would not stick but does after reboot.
pwnyourace
Well-Known Member
its no problem at all, im still trying to understand it myself, the only things i changed (i think lol) were 3 ARM workarounds, preallocating wifi buffers, and turning off cpu grouping (thinking this one isnt it tho cuz thats enabled on the stock kernel)
streetpounder
Well-Known Member
maybe start with adding back in the cpu grouping on a test, then the wifi buffers deal and then on to the next and so. If it bombs along the series I guess we`d have an answer. It is still odd that any of the 4 things would be that touchy between like devices.
pwnyourace
Well-Known Member
i took v1 and turned off the ARM workarounds and made a test, turned them back on and turned off the wifi thing and made a test, turned it back on then turned off group cpu scheduling and made a test, so opposite of what u said
lol..ur route seems like it wouldve been a better idea but too late XD if none boot then it means one of 2 things, its a combination of 2 things or i changed something else and forgot about it and in that case ill have to compare the configs in the morning cuz im finishing up these tests and heading to bed, please posts your guys's results. Tests below are only for the "oddball devices" if your phone boots v1 these dont matter to youhttp://dev-host.org/e8tydtqfd83j/Umph-Oddball_test1.zip
Download Umph Oddball test2 zip
Download Umph Oddball test3 zip
streetpounder
Well-Known Member
i took v1 and turned off the ARM workarounds and made a test, turned them back on and turned off the wifi thing and made a test, turned it back on then turned off group cpu scheduling and made a test, so opposite of what u said
Download Umph Oddball test1 zip
Download Umph Oddball test2 zip
Download Umph Oddball test3 zip
Neither of the three booted. I will double check them again in the morning.
beaviskob1
Member
I put the thanks on the wrong post. I am using the original umph v1 so thanks for it !
So what do you guys use to test the stability of your overclocks? Does setting it to a certain governor affects the result of your stability test ex. using smartass over performance while stress testing. How long should i test my overclock to call it stable? I have a little experience overclocking cpu for computers but i heard android phones are a totally different beast when it comes to overclocking. Thanks also for this working kernel 
So what do you guys use to test the stability of your overclocks? Does setting it to a certain governor affects the result of your stability test ex. using smartass over performance while stress testing. How long should i test my overclock to call it stable? I have a little experience overclocking cpu for computers but i heard android phones are a totally different beast when it comes to overclocking. Thanks also for this working kernel
I just set it highest, and do normal use. If it reboots, lower frequency and repeat. I don't think you should run it with performance governor...because obviously any overclock will then cause a reboot at some point (and it's not real world use; I don't know any program that will use max 100% of the time on android).
pwnyourace
Well-Known Member
Just to be sure before I start thoroughly comparing these side by side checking over them 20x, v1.1 and 1.2 booted for you right?
ok i guess i changed two more things in 1.2 that i forgot about, 3 tests incoming, 1 with ext4 on, 2 with FUSE off, 3 with ext4 on and FUSE off, if thats not it its gotta be a combination of 2 things or im looking over something
Well I tried playing the Dungeon defender game I heard its a good way to test overclock at 1800,1700 it reboots but at 1600 it runs well no booth played for about 2hrs. All other functions work well also. I hope i can go higher than 1600 in the future but I will change my governor to something else than performance. What you think is the best governor to use? THanks for the tip by the way about the governors.
streetpounder
Well-Known Member
Yes both 1.1 and 1.2 booted fine... Both had massive stability and performance issues (sudden reboots even at stock speed, horrible benchmarks compared to stock, freeze ups, etc). I`ll test the new test kernels as soon as you post them up (or as soon as possible as I`ll likely be mowing grass here shortly. haha)
pwnyourace
Well-Known Member
Download Umph Oddball test4 zip
Download Umph Oddball test5 zip
Download Umph Oddball test6 zip
those are from looking at 1.2s config if they dont boot ill look at 1.1s
streetpounder
Well-Known Member
Looks like a no go on those three tests as well.
pwnyourace
Well-Known Member
ugh theres no wtf face in the smiley list..alright ill take a look at 1.1 and look for the difference
streetpounder
Well-Known Member
after I mow the grass I may backtrack and double check those, but I`ve been pretty consistent with my process of trying them. the twisted kernel 11 works flawlessly, and the umph v1.1 and 1.2 booted consistently... these all sit at the M.
pwnyourace
Well-Known Member
i think im gunna go section by section again but this time just for the "oddball" devices so i can find out where exactly the problem is instead of guessing what to turn back on or off
http://dev-host.org/3pbx6unaxbmp/Umph-Oddball_test7.zip
http://dev-host.org/bnlulmhqx1ok/Umph-Oddball_test8.zip
http://dev-host.org/jnsauovmmknu/Umph-Oddball_test9.zip
http://dev-host.org/uvnw629bg5nm/Umph-Oddball_test10.zip
For whoever asked (too lazy to go find the post) wifi tethering does not work with 1.2 test 2. Tried from quick settings and pressing the button does nothing. I do have instructions on how to fix the mtu size error thing from a HoFo post if you feel like including that too so we dont have to do the annoying command prompt commands every time.
There is an option in wifi tether that allows you to turn on mss clamping, which will in theory tell iptables (the kernel module in the phone that does the tethered routing and NAT) to start all network conversations with a maximum MTU size.
Here's the command in /data/data/com.googlecode.android.wifi.tether/conf/tether.edify to turn this clamping ON.
/data/data/com.googlecode.android.wifi.tether/bin/iptables -t mangle -I FORWARD -s " + getdfg("ip.network") + "/24 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
If you try the setting manually at a shell prompt you get:
iptables v1.3.7: can't initialize iptables table 'mangle': Table does not exist (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
OK more research indicates that the kernel must support the
CONFIG_NETFILTER_XT_TARGET_TCPMSS and CONFIG_IP_NF_MANGLE for this command to work. The TCPMSS extension is only valid in the "mangle" table.
Looking in /proc/config.gz we see that neither of these is supported. This is also why the mss clamping option does not exist in the wifi-tether user interface (it checks for the features before showing their config).
To make a long story short, we need a loadable kernel module or a custom kernel to enable this automatic MTU clamping functionality via the mangle table.
That said, you can still set your max MTU on your tethered devices. In fact, I think ppan76 is right:
I didn't have to do any changes to the MT. I just changed the MTU size on the client (my iPad) to 1472 and everything worked.
I don't think setting the MTU on the triumph is necessary at all, the MT will obey the MTU your client sends. I just checked my Triumph and the MTU's are set as rmnet0=1472 and wlan0=1500. Then I set my laptop MTU to 1472 and tried several non-google sites. They all worked fine. Can anyone else confirm this? That sure would make things simpler.
Setting a lower MTU doesn't hurt much, it lowers the maximum data payload of a TCP packet, so it will create more overhead and thus slow things down a bit for your other non-Triumph connections if you don't set it back to 1500. You can be the judge on whether a 28 byte smaller packet important to you or not
I have no idea what any of this means, but just by skimming it it looks like it could be helpful to you, but please dont try to start doing 2 things at once. Your already doing awesome things and if you start to try this too with the OC not working on a select few devices still i fear you might be overwhelmed.
also one other thing, if i know anything about the fix above, it will not fix the problem with built in tethering not working, but instead make it so 3rd party programs work (barnacle, etc) We need a rom and kernel to fix the problem with the tethering option not being there since its removed from the phone currently
Thanks for all your effort!
There is an option in wifi tether that allows you to turn on mss clamping, which will in theory tell iptables (the kernel module in the phone that does the tethered routing and NAT) to start all network conversations with a maximum MTU size.
Here's the command in /data/data/com.googlecode.android.wifi.tether/conf/tether.edify to turn this clamping ON.
/data/data/com.googlecode.android.wifi.tether/bin/iptables -t mangle -I FORWARD -s " + getdfg("ip.network") + "/24 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
If you try the setting manually at a shell prompt you get:
iptables v1.3.7: can't initialize iptables table 'mangle': Table does not exist (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
OK more research indicates that the kernel must support the
CONFIG_NETFILTER_XT_TARGET_TCPMSS and CONFIG_IP_NF_MANGLE for this command to work. The TCPMSS extension is only valid in the "mangle" table.
Looking in /proc/config.gz we see that neither of these is supported. This is also why the mss clamping option does not exist in the wifi-tether user interface (it checks for the features before showing their config).
To make a long story short, we need a loadable kernel module or a custom kernel to enable this automatic MTU clamping functionality via the mangle table.
That said, you can still set your max MTU on your tethered devices. In fact, I think ppan76 is right:
I didn't have to do any changes to the MT. I just changed the MTU size on the client (my iPad) to 1472 and everything worked.
I don't think setting the MTU on the triumph is necessary at all, the MT will obey the MTU your client sends. I just checked my Triumph and the MTU's are set as rmnet0=1472 and wlan0=1500. Then I set my laptop MTU to 1472 and tried several non-google sites. They all worked fine. Can anyone else confirm this? That sure would make things simpler.
Setting a lower MTU doesn't hurt much, it lowers the maximum data payload of a TCP packet, so it will create more overhead and thus slow things down a bit for your other non-Triumph connections if you don't set it back to 1500. You can be the judge on whether a 28 byte smaller packet important to you or not
I have no idea what any of this means, but just by skimming it it looks like it could be helpful to you, but please dont try to start doing 2 things at once. Your already doing awesome things and if you start to try this too with the OC not working on a select few devices still i fear you might be overwhelmed.
also one other thing, if i know anything about the fix above, it will not fix the problem with built in tethering not working, but instead make it so 3rd party programs work (barnacle, etc) We need a rom and kernel to fix the problem with the tethering option not being there since its removed from the phone currently
Thanks for all your effort!
AtticTRON
Android Enthusiast
pwnyourace
Well-Known Member
if 7 wont boot 8 and so on shouldnt..hmm this is the part where i scratch my head..do u know what i changed in 7? i changed the default panic timeout from 10 to 5 and enabled swap support..both of which were done in 1.1 and 1.2..going to make a test with just OC and default config and see if that even boots cuz if it doesnt its the OC table on the oddball devices..but they booted with it on 1.1 and 1.2..ugh very confused..so if this does boot then that means it has to be either the swap or the panic timeout..i have no clue why either of those would make it not boot tho
http://dev-host.org/16kvm127v7pm/Umph-Oddball_test11.zip
whoa whoa whoa i might have it, if that doesnt boot i think i know what it was! in both 1.1 and 1.2 i enabled set min/max frequencies and set them thats the only other thing i can think of maybe that was it!