im in the process of wanting to reflash as i have installed a heap of crap like that to achieve nothing miraculous and indeed slow my phone down

is there anything out there that can help?
i know MohamadAG done some hildon stuff...?

this getting pretty common in here

every god damn problem is thrown to *miracle patches* as mentioned in almost every freemangordon's post

oh and btw to solve your problem
just open up swappolube then restore default settings before installing *HEAVY* debian apps
however i recommend setting a partition for it

and check this thread
http://talk.maemo.org/showthread.php?t=72818&page=2
PS: i was ultra noob (unable to package a deb) so that clear your doubts about patches


//EDIT
and for other question i saw in here

you don't have to reflash to remove the patches
simply for HAM

You mean, as common as problems raising it's ugly head as soon as your "patches" have been applied by the user?

You can blame freemangordon, but he/she is not the person who's posting "miracle" patches as a modern equivalent of turning water into wine.

Why a noob who's not able to supply a .deb would think to tinker with other people's devices is way beyond me.

You mean your patches finally remove/restore the values they changed?

Don't blame karam
its we who are installing it

well karam you are really a great person

thanks for all your efforts

Karam's personality is not what's been discussed here, Sourav dubey. It's the usefulness of the help he claims to provide.

Let me put it this way: As an autodidact guitar player, I could decide to start teaching my girlfriend, who's just bought her first guitar. But rather than teaching her methods that are unavoidably wrong (being an autodidact does that to your playing more often so than not), I'd send her to someone who really knows what he or she is talking about.

So: Yes, it's the user that ends up installing the "patches". But it's the supplier who is responsible for those "patches" to be found anywhere.

I didn't say this

i only mean to say that it isn't his fault too

sorry but still i am thankful for his contribution
at least he tried to make something
to help us in some or the other way
i appreciate your point of view

well done karam
at last i only say this

if u find these patches faulty don't install them alright
Have a nice day

@Sourav.dubey
thank you

and

nope i mean that those problems are not caused by those patches
just an example : did you check the link i gave before
oh it appeared that marmistrz problem wasn't caused by them
now that's a miracle

who said i'm blamming him? , instead i own him lot of respect
to his work, if not his acts against mine

hmm i'm not sure you saw a word *WAS* but i'm not a guru now
aiming to be
and i said that to clear the doubts about marmistrz problems that i didn't make those patches when having that problem

and in other thread as i remember ,there was a call lag problem
first some boneheads said it was by speedpatch
then it turned out the problem was caused by maxcpu app

yes they do
and oh wait as long as you think they are magical .. n900 will need a reversed magical spell

---now after replyed your questions
bottom line
i think it would be an easy debug if you just say all n900 bugs are caused by those patches ?

however i'm really wondering why do i have a 25 gb partition of /opt
and have almost every app from the repositories (with speed and battery patches)
and i'm not having any problem
now this is magic

this is all what i'm going to say

Yeah I've got maxcpu installed
But now I cannot boot my N900,,,
only Nokia screen, no multiboot menu

EDIT: fixed by reflashing kernel. now removing maxcpu

WTF? I am acting against you ?!? Boy, I don't know you and I don't have nothing in personal against you. period.

On the other hand lets have a look at your so called patches:

speedpatch - I've asked you several times on your dedicated thread for an explanation what exactly it does. Your answer was either none or a hyperlinks to sites with explanation what cgroups do and how moving a terminal launched applications into a cgroup will give them more CPU shares (the famous 200 lines patch). Which means nothing in the context of n900 and the fact that cgroups are already mounted(by Nokia) under /syspart. And there is system daemon written by Nokia which uses settings in /usr/share/policy/current/syspart.conf for process distribution among /syspart subdirectories. While it is not impossible an individual to gain better results in cgroups process distribution than the whole Nokia Maemo team (which have had experience from 4 or so Maemo iterations) I highly doubt that is the case.

The other problem with your speedpatch is the fact that it makes priority management incompatible with vanilla, i.e. if tomorrow CSSU team makes a decision to move camera-ui into a higher-priority cgroup while a video is recorded, all users who have CSSU and your patch will have broken systems and will complain "booo, my video stutters, you stupid CSSU developers".

And while I understand and agree that things like responsiveness are hard to measure, why it is so hard to put an explanation in you "magic patch" thread OP how is your process distribution done? No, the kernel does not automatically distribute newly created processes under different cgroup (as it is written in speedpatch description). The truth is that newly created processes are put in the "root" cgroup directory (even if not visible there) and someone has to move the process into a different cgroup so restrictions (as CPU shares and memory limit) to apply. I still fail to find who and how moves processes between cgroups. And there is not a word in your explanations about that. At least there was no by the time I stopped to follow your "miracle patch" thread.

What could be the reason for placebo effect (i.e. speedup of the system reported by some users) is that speedpatch (along with batterypatch) has a new version almost every day and as it requires a reboot, here it is, speedpatch/batterypatch users have uptime no more than 48 hours, so effects like swap fragmentation does not appear.

batterypatch - AIUI those scripts play with two things based on whether device is locked or not:

1. vfs_cache_pressure
2. CPU clocks

vfs_cache_pressure - what is the rationale behind that? I think it was Estel the last one to explain why it has nothing to do with battery life at all. And I don't see your explanation why messing up with file cache will decrease battery consumption. Care to explain?

cpu clocks - well, I don't think it is userland job to mess with CPU frequencies, but could be wrong. Anyway, AFAIK your entire work on batterypatch is based on trial/error way. Which would not be a problem, if you were playing with your device only, but you are playing with the devices of all users who had this installed from extras-devel. Every single day (or so) there is a new version, with slightly changed parameters on a WFM basis.

And I fail to see any measurement proving that batterypatch actually reduces idle current or current under load. Your latest batterypatch requires KP49, ain't? And enables SmartReflex? Well, it is SmartReflex that increases battery life, not your trickery with CPU frequencies and dbus-monitoring whether device is locked or not. Prove me wrong, please, make some measurement,i.e.

in offline mode,device with KP49, dsp profile 125-805 has standby current of:

xx mA without batterypatch
xx mA with batterypatch

the same device running abc background task has current of:

xx mA without batterypatch
xx mA with batterypatch

and finishes the job for:

xx s without batterypatch
xx s with batterypatch

etc.

Only by making such measurements you can prove batterypatch does anything but problems.

I should point to my thread. http://talk.maemo.org/showthread.php...717#post888717