Active Topics

 


Page 293 of 335 « First 283291292 293 294295303 Last »
Poll: Delet the values from the speedpatch?
Poll Options
Delet the values from the speedpatch?

Reply
Thread Tools
demolition is offline demolition
2012-01-25 , 00:19
Posts: 560 | Thanked: 422 times | Joined on Mar 2011
#2921
@Woody: Must have mis-understood. Thanks for clarity.

Originally Posted by freemangordon View Post
TBH I have no idea why 125 is not used by Nokia (and Titan and others). I've never seen reports of 125 being unstable and I am using it on my device. The same for SR and 125 - actually efuse value for 125 is very high, almost enough voltage to run 250.

And for speedpatch doing nothing - well, it does, it ruins all the cgroups setup done by Nokia.
The case to avoid BatteryPatch (BP) was made by Woody but if SpeedPatch (SP) is also questionable, I'll stay well clear of that too. Based on the potential damage it's quite important these stay in the -devel repositories. Being in -testing implies "even though the programme might not work that well, it won't cause untoward or unadvertised things to happen the device" but BP and SP clearly do!
 
Ken-Young's Avatar
Ken-Young is offline Ken-Young
2012-01-25 , 02:50
Posts: 387 | Thanked: 1,700 times | Joined on Feb 2010 @ Cambridge, MA, USA
#2922
Originally Posted by woody14619 View Post
Since you said you wanted to have this discussion here, and aren't replying in the other thread, fine. I'll bring it here.
[...]
I very much appreciate the work you put into track these issues down. I had the "power kernel" installed on my N900, but I did not want to overclock. I was puzzled by why my phone was spending lots of time clocked above 600 MHz when I had not tried to enable overclocking. I finally re-installed the stock kernel. Now I see changes were made by these scripts. I agree wholeheartedly that the fact that these scripts change your clock settings should be very prominently disclosed.
 

The Following User Says Thank You to Ken-Young For This Useful Post:
Seker_94 is offline Seker_94
2012-01-25 , 04:17
Posts: 195 | Thanked: 96 times | Joined on May 2011
#2923
OMG people you are making it world war 3
i see woody14619 only writing disadvantages of karam's posts while ignoring all advantangs

this is not fair

will reflash now and test the phone with in speedpatch installed/uninstalled and report
 

The Following 4 Users Say Thank You to Seker_94 For This Useful Post:
karam is offline karam
2012-01-25 , 12:30
Posts: 856 | Thanked: 1,681 times | Joined on Apr 2010 @ Aleppo ,Syria
#2924
Originally Posted by woody14619 View Post
Why not restore them if they exist? You go out of your way to back them up, and then don't restore them? If there were files, you're not restoring them on uninstall. That's a change.
i will explain why
because restoring them for people who have used the script version before (+10000) will cause the xterm message to appear
because the backed up ones have the speedpatch modifications
and by default there are no .profile nor .bashrc at /home/user
unless created by user and they are already backed up as *.bak

Originally Posted by woody14619 View Post
I also see you never addressed one key point of what I was saying. Your description (both here and in the deb) says you're creating cgroups for the desktop and for apps, when in fact you're doing neither. They only cgroup you're making is for bash and shell scripts using bash. The desktop and user apps are already in a cgroup, created by Nokia as part of the kernel compile.
Can you please address why you're lying about what you're doing?
pr1.3 the actual update when nokia used to take care of N900 was released on October/2010
while speedpatch (cgroup patch) was first mentioned by the original author on November/2010 .. after a month of the update

and check what's inside /dev/cgroup folder+ tell me something which has been effected *badly* with speedpatch after removing what nokia did
not only theoretical b*llsh*t

Originally Posted by woody14619 View Post
The kernel already does that if there's a lockup, even if you default it to something else. If you load a profile as default, and the system reboots twice in the span of a couple minutes, the kernel automatically rejects loading the default config and uses the built-in Nokia-based values (250-600, high-voltage). That's been in there since Titan's kernels, well before KP. The fact that you don't know this, shows how little you know about this whole process.
are you kidding me ?
of course i know this
it also says that *unexpected reboot ...etc your settings were not loaded* or so

but actually i did kernel-config default to default as an Reserve method

Originally Posted by woody14619 View Post
Again, you show you have no idea what you're talking about. A missing default kernel profile will never cause a reboot loop. A missing module or kernel file may, but a profile never will. It will simply stick with the built-in Nokia defaults if the profile it's instructed to read is not present, or is corrupt in some way.
again i tell you : are you kidding me .. of course i know this too
i say again it's a Reserve method

Originally Posted by woody14619 View Post
Nokia, as part of the phone app, triggers the phone app to get real-time priority, and locks the kernel at a set speed (600 as I recall). At that speed, the phone app takes about 60% of the CPU and allows enough background time for apps to continue to function if needed. I made plenty of calls using the stock 250-600 kernel and noticed no quality issues. If you're seeing issues, it's probably because you're either running something highly CPU intensive in the background, or because you've installed a speedpatch that's screwing around with cgroups and letting shell scripts take higher priority than they should!
now this is pretty funny
first i didn't have any problems or lack of quality as well
AND USING BOTH PATCHES
BUT
i made an update that included the change to 7x0-805 when a call is received only !!! (the couple a minutes you see the *who is calling you screen*)
after putting your ear .. normal overclock profile will get activated (250-805)
and users told me it really get more responsive with it especially the time when changing from portrait to landscape accidentally on when N900 is ringing

Originally Posted by woody14619 View Post
Also, you again show ignorance on your own scripts. In the postinst for batterypatch, you check for version 42, 47, and 48 of KP, and copy the config settings from /opt/dbus-scripts/ to /usr/share/kernel-power-settings. The config files put in place for those kernels is:
call: 750-850 non-call:250-805 sleep:125-600 (all with SR2 set)
For all other kernels, the files used are
call: 720-850 non-call:250-805 sleep:125-600 (all with SR1 & 2 set!)
as i said above
this OC lasts until you answer the cal
and what the h*ll does it have to do with ignorance

Originally Posted by woody14619 View Post
Also, for all but 42, 47, and 48, you're enabling SR1, another problem. You do know that with K49 (and 43, 44, 45, & 46) that SR1 is not always stable, right? The patch to handle that is slated for K50, and only those doing kernel testing have a version of K49 that might be recent enough to allow this in a stable way. Did you know SR1 is also never stable for 125Mhz, since Nokia never enabled it and never setup the e-fuse stuff for that? Yet you tinker with it.
no no no no that's not true
i have VDD1 disabled in BP4 with KP42-46-47-48 !!!
check with *larger screen to see well*

Originally Posted by woody14619 View Post
The biggest issues are the crazy (7X0-850) overclocking, use of SR1, and use of unstable 125Mhz. If you took those issues out, it wouldn't be all that bad. But those alone, yet alone staked with other mods, make the whole deck of cards wobbly.
after seeing the post from freemangordon saying that him self uses 125mhz and i have been using it too since 1 year
it's stable

and overclocking normally is 250-805
only when a call is received : 7X0 - 805 (not 850)
it's stable too

and if you have a sh*tty N900 then use the package (batterypatch-for-unstable)

Originally Posted by ed_boner View Post
maybe mohammad is karam evil twin..dont know and dont care...just want a solution to get rid of these patches efectively without reflash...
believe me
i'm far away from being evil


Originally Posted by demolition View Post

ps Karam: you need to sort out your Karma. Single figures makes you look like a proper shady character!
honestly i can't
i don't have the time doing any of it
this year i have a bakaloriat

i'm actually spending time i don't have @ tmo





.......... now let me explain everything clearly about patches:

explaining of what batterypatch does:

1- when installing :
postins : it stets kernel-config to default
same as prerm
reason : some users reported having reboots loops after uninstalling BP
after this it's solved (as i said before it's a Reserve method)
it totally doesn't effect anything
because after locking /unlocking overclock or underclock profiles will be loaded

when installing : it detects the kerne-power installed
so it can put the profile with 750 or 720 mhz

and for stablity :
KPv49 OC with 805 + vdd1 is stable for most devices
also freemangordon said 125 is OK

KPv49> sets 805 + vdd1 = 0
is it unstable here ?

now why OC to 805 ?
well because conversative module is slow but it saves more battery than ondemand so it needs to be OCed to be usable

PS : there is a version batterypatch-for-unstable check that (already mentioned that)

all clear about installing process and it's stability ?

2- when using N900
if you lock the screen with keyboard in
it will renice background processes and mlodest , browser, image-viewer
it sets vfs to 10 which saves battery in standby
.and loads underclolck profile
which has nothing unstable in it

3- when unlocking
everything above is reversed to normal
but loading overclock profile which has conversative module in use
anything unstable here ?

4- when uninstalling :
As for speedpatch :
it removes all the files it added and backs up .profile and .bashrc (if any are existed by user)
and by default there are no .profile nor .bashrc at /home/user
(i have already said this)

i can't see anything that does a permanent change


As for batterypatch:

it removes every file it added and sets kernel-config to use default profile avoiding any possible problems

any permanent change here ?
there are not any
...
can you now explain what are the unstable or changes that cause permanent damage

PS again i may not have time to reply another post

oh almost forgot
@seker_94
when finished
reply what happens with you
AND FOR NOW ... ONLY TRY WITH SPEEDPATCH AS WE WILL GET TO BATTERYPATCH LATER

and believe me .. when i get convinced of the harm of them
i will remove from extras

Thank you
__________________
My Projects:
Speed Patch & Battery patch
Task-Swapper
Wifi-Pwner (MDK3 GUI)
Hacking Tools

Tutorials
How To Increase Camera Image Quality
How To Unblock Repositories In Forbidden Countries [Like Mine]
Last edited by karam; 2012-01-25 at 12:36.
 

The Following 2 Users Say Thank You to karam For This Useful Post:
Seker_94 is offline Seker_94
2012-01-25 , 12:52
Posts: 195 | Thanked: 96 times | Joined on May 2011
#2925
eh took 10 minutes to read
ok karam i will do that
reporting in 6 > 10 hours after testings
 
ed_boner is offline ed_boner
2012-01-25 , 14:31
Posts: 336 | Thanked: 129 times | Joined on Jan 2011 @ portugal
#2926
i said mohammad could be your evil twin, because of his atitude kind of agressive deffending u..never said you were evil karam
 
woody14619's Avatar
woody14619 is offline woody14619
2012-01-25 , 22:32
Posts: 1,455 | Thanked: 3,309 times | Joined on Dec 2009 @ Rochester, NY
#2927
Originally Posted by freemangordon View Post
TBH I have no idea why 125 is not used by Nokia (and Titan and others). I've never seen reports of 125 being unstable and I am using it on my device.
There were tons of reports of it being unstable back when Lehto and Titan were running it. In particular if you were in 125Mhz when calls and sms came in, random reboots were not uncommon. For a long while it was actually black-listed in the Titan kernel, as it is in the default Nokia kernel.

Most people didn't care about it anyway, especially when Titan and friends found that the most efficient speed was closer to 500Mhz, and started using that a min-speed.

While it may be more stable in KP, for various reasons, it was not back in the day.

Originally Posted by freemangordon View Post
The same for SR and 125 - actually efuse value for 125 is very high, almost enough voltage to run 250.
Which means you're getting effectively 0 savings from using it. If you're using the same voltage for a slower speed, what are you gaining?

Originally Posted by freemangordon View Post
And for speedpatch doing nothing - well, it does, it ruins all the cgroups setup done by Nokia.
I'm not so sure about that. The script isn't removing existing cgroups that I can tell (at least the current version isn't). It's simply adding another one, and stuffing everything shell-based into it.

Something you may know that I can't seem to track down: Are cgroups inherited across fork/exec? I would assume they are, but I can't seem to find any documentation that clarifies if they are or not. If they are, then it could cause desktop/apps to share in the cgroup (which could screw up existing groupings). If not, then it's only affecting shell-scripts, which would make the change rather useless.
 
woody14619's Avatar
woody14619 is offline woody14619
2012-01-26 , 00:04
Posts: 1,455 | Thanked: 3,309 times | Joined on Dec 2009 @ Rochester, NY
#2928
Originally Posted by Seker_94 View Post
OMG people you are making it world war 3
i see woody14619 only writing disadvantages of karam's posts while ignoring all advantangs

this is not fair
Is it fair to silently overclock people's devices without telling them? Is it fair to make changes that affect several peoples devices, telling them you're doing one thing when you're in fact not, but doing another entirely?

I am in fact noting that some of what's being done does work. Enabling SR2 (and SR1) can save lots of battery. Doing so in ways that are known to cause some people's devices to go into reboot loops is not. And not being able to explain what you're doing, and what effect it's having (or claiming effects that are counter to or not related to what you're doing) is also not good.

And no, it's not fair. But then it's not about being fair.

You want to do a fair test? Load up your system with stock PR 1.3, then load KP49 and load an overclock profile of 250-805. Run with that for a while, say a day.

Then, load up his patches, and tell me you can see any difference. I'm willing to bet you see 0 difference between a stock system with K49 overclocked, and the scripted special crap being done in these packages. I'm betting 100% of the gains you're seeing are coming from KP49, overclocked, with SR1/2 enabled.

Do that test... that should convince you if nothing else does.
 

The Following User Says Thank You to woody14619 For This Useful Post:
woody14619's Avatar
woody14619 is offline woody14619
2012-01-26 , 00:09
Posts: 1,455 | Thanked: 3,309 times | Joined on Dec 2009 @ Rochester, NY
#2929
Originally Posted by karam View Post
i will explain why
because restoring them for people who have used the script version before (+10000) will cause the xterm message to appear
because the backed up ones have the speedpatch modifications
and by default there are no .profile nor .bashrc at /home/user
unless created by user and they are already backed up as *.bak
Nice assumption you're making there. You're assuming that no other package, in any repository, anywhere, is modifying or creating a .bashrc or .profile. (There are a few that do...) You're also assuming the owner didn't make their own changes.

And tell me how, exactly, the backed up ones have speedpatch changes? Oh, right.. because you're not doing it right. You see, the right way to do this is to have a script that *injects* what you need into the files. Then on an uninstall, you can use another script (or sed/awk) to remove those lines.

Instead you copy files into a backup file, without checking to see if they already exist. So if someone re-configures their speedpatch (which you tell them to do if they update the kernel) it copies the speedpatch version over top of their existing backup, causing an issue on restore. It also obliterates their backup in the process. So much for not making permanent changes...

Originally Posted by karam View Post
and check what's inside /dev/cgroup folder+ tell me something which has been effected *badly* with speedpatch after removing what nokia did
not only theoretical b*llsh*t
So wait... you want me to blindly accept your theoretical b*llsh*t, that your patch does something good. But when I claim that all it does it put shell scripts into a separate cgroup (which is what it does), you're calling my statement bull? Really?

And lets be clear: I never said it "effected *badly*" anything. I said I don't see what advantage one would gain by putting all shell script processes into a separate cgroup. In fact, in my overview above, I noted that speedpatch, on it's own, probably has little to no effect on anything. Which begs the question: Why bother with it?

Originally Posted by karam View Post
are you kidding me ?
of course i know this
it also says that *unexpected reboot ...etc your settings were not loaded* or so

but actually i did kernel-config default to default as an Reserve method
I see, so again rather than doing it the right way, finding out from the config files which profile was enabled during install, and then restoring to that profile, you instead force the default. Again, you take the easy way out instead of taking a small extra step to make sure your uninstall reverses what it did to install things.

**** IF YOU READ NOTHING ELSE, READ THIS PART ****

Originally Posted by karam View Post
now this is pretty funny
first i didn't have any problems or lack of quality as well
AND USING BOTH PATCHES
BUT
i made an update that included the change to 7x0-805 when a call is received only !!! (the couple a minutes you see the *who is calling you screen*)
after putting your ear .. normal overclock profile will get activated (250-805)
I would say this is funny, but it's not. You're WRONG.

From the script "cpu_normal", part of the deb in the repository (where most will probably get it from):

Code:
if [ "`dbus-send --system --print-reply --dest=com.nokia.csd.Call /com/nokia/csd/call/1 com.nokia.csd.Call.Instance.GetStatus | tail -1 | sed 's/.* //'`" != "0" ]; then
...
kernel-config load overclock-call
else
...
kernel-config load overclock
fi
You're parsing the value here and using overclock-call (7X0-850) when it's not 0. GetStatus returns 0 for not in a call, 1-5 for call ringing, 8 for ongoing call, and >8 while the call is hanging up. The code as it stands right now, is overclocking for the duration of the call, because it's 8 (not 0) for the duration of the call. Don't believe me? Open an xterm, place a call (or answer it) and run that command.

The fact that you don't know that is sad. The fact that your putting other people's devices in danger because you're severely overclocking them for the duration of a call when you think it's not... that's worse.

**** ------------------------------------------------------------- ****

Originally Posted by karam View Post
and users told me it really get more responsive with it especially the time when changing from portrait to landscape accidentally on when N900 is ringing
I'm sure they do, since you're severely overclocking the device. This also explains why some people get random reboots when people try to call them with your patches installed. Their systems can't handle SR1 enabled at 720Mhz, and you're running it at that every time the phone is about to ring!

Originally Posted by karam View Post
as i said above
this OC lasts until you answer the cal
and what the h*ll does it have to do with ignorance
Ignorance: Not knowing a key value you rely on has a value != 0 when a call is on-going. Again, you're overclocking for the duration, not just until the call is answered.

Originally Posted by karam View Post
no no no no that's not true
i have VDD1 disabled in BP4 with KP42-46-47-48 !!!
check with *larger screen to see well*
Yes, but you leave it enabled in KP 43-44-45-49, and all <K42, where it is still unstable! Try reading what I write...

The only people that have a stable K49 with SR1 enabled are either lucky owners with valid e-fuse settings, or people running the beta "K49" that's actually a pre-release of K50. Not all devices are stable on K49 with SR1, and almost NO devices are stable on K43-44-45, or K<42 with SR1, yet the way your install script is setup, it runs with those settings.

Had you parsed the value out ("49") in your postinst file, and then did a simple mathematical compare of less-than, it would all be good. But you don't. Your script tests for four specific uname strings, for only those versions. Again, you cut corners, and other suffer.

Originally Posted by karam View Post
after seeing the post from freemangordon saying that him self uses 125mhz and i have been using it too since 1 year
it's stable
On your device it may be. My device can run at 1100Mhz, can yours? Most of them can't. Some can't even overclock above 900Mhz reliably, regardless of SR1/2 settings. Testing done back when Titan/Lehto found and enable the 125Mhz speed found that many people's devices were not stable at that speed. I seem to recall one of them contacting someone at Nokia, and got confirmation that Nokia dropped the speed because they found it wasn't reliable. I also recall something about the phone app reverting to 125 if it was in the configed list. PowerSearch shows this and this.

Again... This isn't about you and just your device. This is something going on to several people's devices. It's fine to say "it may not work on your device", just like the KP overclock stuff says. But you're not saying that. You're saying this is safe for all devices, when what you're doing has historically been proven to not be stable on all devices.

Originally Posted by karam View Post
and overclocking normally is 250-805
only when a call is received : 7X0 - 805 (not 850)
it's stable too
Again, on your device... Overclocking is not stable or guaranteed on ANY device. Even if it were:
WHERE ARE YOU TELLING PEOPLE YOU ARE OVERCLOCKING THEIR DEVICES?

You're not! You're overclocking people's devices, in ways you don't even realize you're doing it (for full call duration), without telling them you're doing it!

Originally Posted by karam View Post
now why OC to 805 ?
well because conversative module is slow but it saves more battery than ondemand so it needs to be OCed to be usable
As I already noted, the maximum speed has almost no effect on the governor. The governor (what you're calling "conversative module") only regulates how quickly it changes from one speed to another. What then end top speed is has no effect on how fast that change occurs!

Originally Posted by karam View Post
i can't see anything that does a permanent change
Except for the things you already mentioned, like it changing the default kernel config.... Oh... And overclocking your device without telling you. And on speed patch: removing any .profile and .bashrc file the user or any other app may have created, and not restoring those at uninstall, and overwriting their backups on a reconfig...

I call those permanent changes. I also call overclocking the device for the duration of every call to (750-850), and the heat/wear/damage that can potentially cause, a permanent change. One that I'll note one last time, you NEVER warn the user about, anywhere.

If this post doesn't show you that what this script does is dangerous, and that the person maintaining it doesn't know what he's doing, then there's no hope for you. Because this person can't be bothered to learn proper script programming methods, he's overclocking your device for the duration of a call to >700Mhz. And he's doing so without warning you that he's overclocking your device, yet alone super-overclocking it. When told he's doing it, he denies it, and attempts to attack/belittle those who call him on his own ignorance. That, all by itself should make you distrust using anything created by this author.

Those speeds cause lots of heat and rapid battery drain, potentially to the point of doing actual real long-term damage to your device and/or battery.
Last edited by woody14619; 2012-01-26 at 00:39.
 

The Following 4 Users Say Thank You to woody14619 For This Useful Post:
ed_boner is offline ed_boner
2012-01-26 , 01:21
Posts: 336 | Thanked: 129 times | Joined on Jan 2011 @ portugal
#2930
damn..i am seriously divided between trying to calm things down or get a good seat to watch the circus burn...
 
Reply
Page 293 of 335 « First 283291292 293 294295303 Last »

Tags
autobrick, awesome-script, do no install, f***epitaph, install it now, perfect_ n900, script-a-brick, very safe

« Previous Thread | Next Thread »

 
Forum Jump


All times are GMT. The time now is 20:13.

Contact Us - Home - Archive - Top