I wanna remove Speedpatch by typing apt-get purge speedpatch.
But after rebooting I'm getting

BusyBox v1.10.2 (Debian 3:1.10.2.legal-1osso30+0m5) built-in shell (ash)
Enter 'help' for a list of built-in commands.

-sh: /home/user/.bashrc: line 5: cannot create /dev/cgroup/cpu/user/2686/tasks: nonexistent directory
-sh: /home/user/.bashrc: line 5: cannot create /dev/cgroup/cpu/user/2686/notify_on_release: nonexistent directory
~ $

How can I solve this?!

use the script in the first post, for people who have messed up with the verions, it helped for me.

hmm i can now see why people are still having this problem after removing speedpatch

@willi6868
you must have used the script version before right ?

if so :
1st post updated

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 find great irony that you're instructing people how to repair one of the permanent changes done in the post above this, while in other threads saying:

The current version does, in fact, do permanent changes. On install it replaces your .profile and .bashrc files, but fails to restore them when uninstalling. (See prerm and postinst for the deb if you don't believe me.) It also sets your kernel config to "default" which on most systems is (250-600), without mentioning it anywhere.

So, since I bothered to grab the latest versions to see what it actually does, lets take a look-see shall we?

All "speedpatch 2.0" seems to do is add a separate cgroup for CLI commands and adds shell-scripts to that cgroup as they run. Nowhere do I see it adding groups for desktop and applications, as stated in it's description. Which means it's not really doing anything but lumping shell scripts and xterms together into a shared cgroup. How does that help speed? Since most apps are not shell scripts, I don't see how that helps anything. Further, it depends on KP without specifying it as a pre-req. Everything I'm seeing would indicate that speedpatch has a better chance of slowing things down by setting the kernel back to default than it does speed things up.

As for Batterypatch 4.0: The current version also sets your config to default kernel config, on install and on uninstall. All it seems to do is set the nice levels on a few apps and loads a kernel config if your close the keyboard and it goes into sleep mode. Namely, it renices modest, browserd, image-viewer to a value of 1 and ignores nice loads. It loads a separate config for when you open it, and when a call is going on. I note that it tries to renice "background apps" via a call into /dev/cgroups, but unless you have speedpatch installed (not a pre-req!) it will find nothing there, as cgroups aren't mounted by default.

The "speed" from battery patch comes from the fact that you're heavily overclocking the system (705-850!) when the system is awake. For calls, you're using a (250-805) config that's closer to stock, but still overclocking. (Are you telling people that your scripts overclock their devices?) And for the sleeping system a (125-600) config that ignores nice loads.

This means when an app in the nice list (modest, browserd, etc) wake the system up to do something, when it's closed, it will run at 125Mhz until done. Weather this is even saving battery or not is questionable, since it's against the "race to finish" idea in multiple ways. Also, it's enabling 125Mhz, which just about everyone including Nokia, Titan, and Lehto believe is unstable.

So what does the combo of these two do? From what I'm seeing, next to nothing, except that it screws with your configuration, enables a kernel speed that Nokia and others avoid because it's unstable, and adds a user cgroup to lump scripts and shells together for sharing resources. Not something I'd care to inflict on anyone.

You've been asked, on several occasions (even on your dedicated thread) to explain what these patches are doing, and why it's helpful. You've declined to give much information at all, and what information you have given (the package description, for example) is patently false. So maybe that's where you should start in your "proof" of what either package does.

The fact that the entire install is nothing but scripts that tinker with kernel settings in a way you're incorrectly describing doesn't lend any confidence that anything you're saying about this is correct.

As for speedpatch

first point is :

permanate changes :
first by default there are no .profile nor .bashrc at /home/user (reflash and see by your self)

so when uninstalling speedpatch
it leaves .profile.bak and .bashrc.bak (if there any created by user)


----

second point : what the hell has speedpatch to do with kernel-config ?
it doesn't touch it

----

thrid point : i'm not sure it depend on KP..

-------

As for batterypatch

first point :

it sets kernel-config default default in postinst
you know why ?

well so if any unexpected reboot happen
the user can uninstall batterypatch saftly
and btw default profile will be changed to overclock after the first lock of a boot up

and in prerm it sets to default
so if overclock profile is removed
there will be no reboot loop

---
second point :

actually you did discover a bug (it wasn't in previous versions)

just fixed it .. thank you
it should detect if speedpatch installed or not

and i saw at other threads you said overlcock 750-850 when a call is recieved
actually it's 720-805 (KP49) and 700-905 (KP49>)
and this will noticably improve the response on calls

and i set 805 as max because overclock uses conservative module which require such oc (leaving it 600 will cause lags with conservative module)


PS: i may not be able to write any replies till tomorrow

listen up woody boy
i have just reflashed my n900 and tested the speed without speedpatch

transmission lags to hell
nokia panorama lags to hell
multitask 8+ browser windows lags to hell

with installed speedpatch

transmission lags are reduced by half
nokia panorama doesn't lag at all while precess a pic
multitask is way improved

woody14619 got a point
also karam got a point
trying to be fair here

speedpatch 100% it improves multi tasking and the torrent application
batterypatch watching my old battery graphs ! it does increase batterylife compaired to dsp profile

IMO
IMO
IMO

so anyway..if i remove these files is like i never installed speedpatch and batterypatch right?

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.

No, batterypatch does. I was reviewing both at once, since you clearly have the assumption that both are installed together. (Batterypatch having an implicit reliance on speedpatch being around to mount cgroups as an example.)

Fair enough. Can you mount cgroups with base PR1.3? I don't know, because I never tried.

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?

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.

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.

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!

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!)

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.

It's no wonder people are having problems with their devices using these patches.

Conservative module? Do you mean the config setting for the governor? All that does is tweak how quickly the system jumps from one frequency to the next. The "ondemand" setting sets up the governor so it quickly ramps up to top speed (>50% cpu use for a short time ups the clock). Where "conservative" requires >80% use for a moderatly longer time to up the clock. Upping the max frequency has no effect, since the "lag" you're seeing is caused by the governor not moving the clock speed up quickly enough. The only thing you can do to make the system more responsive with the conservative governor is to up the minimum frequency, so you start out at a higher basis.

How is it you're tweaking values when you don't even understand the basic concepts of what they do?

Also, are you mentioning it anywhere that you're overclocking people's devices? Are you warning people that your script, notably the batterypatch, is not only silently installing kernel-power (HAM installs prereqs silently), but is overclocking their device? Don't you think that's worth mentioning on the top post, or in the description?

And you're not just overclocking them... you're severely overclocking peoples devices, placing the minimum clock speed well above the maximum limit deemed "safe" by TI and Nokia. It suddenly makes sense now why so many people with your patches were complaining about how hot their phone gets when they use it to call people. You're locking it into a severely over-clocked state. It's getting hotter, and using more energy for calls for the sake some perceived "clarity". That's the opposite of battery savings...

And you're turning SR1 on in several kernel versions where it's known to have issues. And enabling a frequency known to be unstable by Nokia and all overclock developers.

So, lets address the key items here in a nice little list:

• You're overclocking peoples devices without telling them. (BP)
• You're setting a minimum clock of >700 when Nokia max is 600. (BP)
• You're using a known-defective frequency (125Mhz) when asleep. (BP)
• You're not remembering/restoring actual kernel config settings at install/uninstall (BP)
• You're causing a few apps to not trigger cpu raise when active, removing any "race to idle" benefits.
• You're claiming to setup cgroups that you're not actually setting up. (SP)
• You're setting up a cgroup for shell scripts, for no real reason. (SP)
• You're removing any other user/app settings placed in .profile & .bashrc (SP)
• And not restoring those when uninstalling. (SP)
• You're calling on cgroups in BP, which is mounted only in SP. (Mix)

The real irony I see here is that speedpatch does frankly almost nothing. Most of the speed increases are coming from batterypatch, which are a mix of sever overclocking, and renice-ing a few apps with a config setup to ignore load caused by them for governing purposes. Battery savings is coming almost exclusively from the fact that you're forcing KP install, with a very small margin possibly coming from renice-ing a few processes in a couple situations. (And even that's debatable.)

Side effects include heat and quicker battery drain while making calls (from sever overclocking), instability (from overclocking, SR1, and using unstable frequencies), and perhaps slightly faster script execution.

I also read in this thread something about a "completely fare scheduler". Where exactly is that being installed and enabled? I see nothing affecting the scheduling algorithm of processes, outside of the minor tampering with cgroups done in speedpatch (which is a far throw from changing the scheduler).

Sorry, but you're full of it. I can list for you the scripts installed by speedpatch. I downloaded the package, extracted it by hand, and looked at every script it runs, everything it installs, every action it takes.

The only thing speedpatch does is adds a cgroup for shell scripts, and puts a mechanism in place so shells scripts add themselves to the cgroup as they start up. Now it may be that some parts of what you're looking at are actually run (or lagged by the use of) shell scripts. That's fine. But it's not doing anything claimed by the install description of the package. It doesn't setup cgroups for the desktop or applications as stated. Nor does this speed-up apply to all applications, only ones that are or rely on shell scripts.

Now if you installed batterypatch too, that starts to make sense, since batterypatch also installs KP, which is where you'll see real speed and battery performance changes happening. But that has next to 0 to do with these patches. I can make a nearly empty deb that just depends on KP49 and adds a profile to load on as default and get the same results.

As for callings someone a boy... Shows what an ignorant person you are. But then I would expect that from you, given your past posts, ramblings, and pontifications on topics you are clearly not educated on.