Re: BFS for the power kernel
 

I've followed this post and installed multiboot and

kernel-bfs-headers_2.6.28-bfs5_armel.deb
kernel-bfs-bootimg_2.6.28-bfs5_armel.deb
kernel-bfs-flasher_2.6.28-bfs5_armel.deb
kernel-bfs-modules_2.6.28-bfs5_armel.deb
kernel-bfs_2.6.28-bfs5_armel.deb

It's seems to work but I have 2 questions:

1) Do I need this file kernel-bfs-flasher_2.6.28-bfs5_armel.deb?
It seems to flash the device? Why do I need this when I have already a zImage with this file kernel-bfs_2.6.28-bfs5_armel.deb?
2) I have run this file kernel-bfs-flasher_2.6.28-bfs5_armel.deb. Does this mean my device is flashed with 2.6.28-bfs5? I can't boot the default kernel 2.6.28-omap gives with multiboot. I can only select kernel 2.6.28-bfs5 ( because I have a BFS.item in multiboot ).

BTW. It seems to be very responsive! Almost double the base speed! I like it. Nice work!

Re: BFS for the power kernel
 

Sry for this post.

Re: BFS for the power kernel
 

@Tigerite

first off thanks for you work:) (we all don't have to... we choose to)
i used to follow this project (and i did see improvements..and i would like to see some now:D)

anyway im having a problem downing the headers. could you please fix your link
this one http://ifile.it/93xaj2f/kernel-bfs-h...bfs5_armel.deb , thanks


Edit: it working now sry.. 1 question thou will you be uploading to maemo repository?

Re: BFS for the power kernel
 

Kernel BFS has its own garage page, so it's never been released into the repos. I am considering releasing a v6 with zram/compcache (I haven't fully decided whether to go with zram, which isn't fully supported on 2.6.28 and requires lines commenting out to compile, or stick with compcache which is compatible) but I'd have to discuss it with the other BFS moderators first. We've recently discovered distortions when making and receiving calls, and need to isolate the patch causing it - I have my suspicions that it's the two voltage patches that aren't present in power46, but I may be mistaken. It needs testing either way first, before anything can be released.

Oh, and you don't need to install the headers, or the linux ones, on-device. The only debs that are needed are the modules (always) and the main kernel-bfs package, which is used when flashing the kernel (via the flasher deb) or for dependency issues when using the zImage for multiboot/u-boot (within the bootimg deb). There is a dummy kernel-bfs package for the latter case, to save some space in rootfs, as the actual image within the kernel-bfs deb is only used by the flasher, not multiboot or u-boot.

Re: BFS for the power kernel
 

I'm still a bit confused about your post but there is 2 way to install?

with multiboot:
===========
kernel-bfs-bootimg_2.6.28-bfs5_armel.deb
kernel-bfs-modules_2.6.28-bfs5_armel.deb
kernel-bfs_2.6.28-bfs5_armel.deb

without multiboot:
==============
kernel-bfs-flasher_2.6.28-bfs5_armel.deb
kernel-bfs-modules_2.6.28-bfs5_armel.deb

Re: BFS for the power kernel
 

Without multiboot, you still need kernel-bfs_2.6.28-bfs5_armel.deb too, but otherwise, that's about the size of it. You don't install the bootimg deb though - you should use dpkg-deb to extract the zImage-2.6.28-bfs5 and then use that with multiboot (I've never installed multiboot so don't know all the ins and outs of it).

Re: BFS for the power kernel
 

How do I use zRam? Do I need some configuration files? I would like to test it with BFS, because BFS seems to solve my problems!

Re: BFS for the power kernel
 

You'll need the compiled module for BFS, and ideally the config script to set it up (although not strictly necessary). I've compiled a deb with those but I am not sure zram is stable enough, as I've had some lock-ups lately where the CPU has simply been flooded with requests, and I can only assume zram has been the culprit. I'm considering patching compcache instead, to use my kernel patch and its related disk parameters, as it's definitely compatible with 2.6.28 (whereas zram is designed for 2.6.33 and above).

Re: BFS for the power kernel
 

So compcache is only for swap-space? And zRam for everything else?
When you compile what flag do use in the makefile? I assume it is gcc and you use something like -O3 -fomit-frame-pointer -ffast-math? Does compcache works with BFS and power-kernel?

Re: BFS for the power kernel
 

Yes that's right, compcache is only for swap-space, and with the patches as they are (disabling all the remapping that Nokia included) I wouldn't recommend using backing swap with it either. I haven't been able to get zram to work with normal block devices anyway, by the way - it just crashes the device, so we wouldn't be losing anything.

Do you mean compiling compcache/zram, or BFS/power-kernel? I just use the Makefile for both so I don't honestly know. Compcache should work with both, as zram certainly does - it just needs to be compiled against the correct kernel and associated headers (but that's for me to worry about!)

Re: BFS for the power kernel
 

Started noticing some issues with freezing and bad priority allocating when using BFS. What is this attributed to? I'm guessing the dropping of cgroups? What kernel tunes actually compliment BFS?

I have noticed a significant decrease in lag and "stuttering" as uptime increases, when compared to CFS.

Re: BFS for the power kernel
 

That's a good question, unfortunately not one I know the answer to. However, I have included this patch since the posted debs, which may help. I'm planning to post an updated version later today - still working on compcache at the moment, it's a little more work than I thought as it's very different compared to zram (which uses a nice sysfs interface).



You may also try (from Dennis - I haven't tested it yet) the following:

Finally there is schedtool, which has been compiled for the N900 (I think it's been posted previously on this thread?), and can be used within a startup script. Mine has

Re: BFS for the power kernel
 

I will have a go with schedtool tasking. Thanks for the post, as well as providing the kernels and modules. Really appreciated time/cycle saver :)

Re: BFS for the power kernel
 

This makes my device unusable. I did tried it only once but it is the same with hw-vsync enabled.

Re: BFS for the power kernel
 

yeah i compile schedtool (its good) but i also did chrt (in util-linux) which im using right now(i find it easyer). if you give Xorg policy:SCHED_FIFO and priority:99 i notice better performance. (i messing with some others too but on this process i notice improvement.)

here's a good read http://ck.kolivas.org/patches/bfs/bfs-faq.txt

its also nice to having the device run at 1000 MHz


so far no freezing on my end, not sure if its because my watchdogs are down.

Re: BFS for the power kernel
 

My device absolutely didnt feel faster after installing this kernel, maybe ive done something wrong.

And another thing, in Opera 11 when u tap the red O the pop-up is all buggy which wasnt in the original kernel

Sorry if my english is bad

Re: BFS for the power kernel
 

In terminal you can type uname -a or cat /proc/version to see what kernel you are using. If you are right then you should see the suffix -bfs attached to the kernel-name.

Re: BFS for the power kernel
 

uname -a returned 2.6.28-bfs5, so thats ok

Maybe i just expect to much:rolleyes:

Re: BFS for the power kernel
 

Hmm, I haven't noticed any freezing myself. Try to see if there is a spike in CPU usage when you experience a freeze. Also, could you provide an example of the bad priority allocation?

BFS doesn't got much to tune. From the FAQ: "The only tunable for the
scheduler itself is the rr_interval value (see documentation)". The same FAQ states you won't have to tune BFS virtually ever :)

If I may add my reasoning to do that ;):
BFS doesn't support cgroups and I've read somewhere that some important applications are mlocked by default anyway. Because of this, I don't think the ohmd module has that much effect anymore. I've been running my device without /syspart mounted for a few months already and hadn't experienced any problems.

Here it is. I'll upload it to the kernel-bfs garage page later so that it'll be easier to find.

Some other people in this thread noticed strange behavior using Opera too, see http://talk.maemo.org/showpost.php?p...9&postcount=19 and http://talk.maemo.org/showpost.php?p...5&postcount=31. Opera seems to be the only application affected though.

Using a different CPU scheduler only changes the way CPU time slices are distributed amongst the running processes; in the end your device has still got the same amount of them. When idle, you won't nice much difference with different schedulers as there are plenty of slices to go around anyway. However, at load there are the gains to be found; at least when talking about responsiveness. Try running the kernel for a little longer :)

Re: BFS for the power kernel
 

Hard locks occurs very randomly and I've yet to experience it in such a manner when using CFS, but I am able to lock up the device on CFS, in any fashion.

With BFS, sometimes it'll lock up when it's under medium load, other times under no load whatsoever. I'll open the status menu, it'll completely halt. Playing a game, reject an incoming call and it'll be hosed. Both the power key and the light sensor (controlling keyboard LED) are unresponsive and I have to battery pull.

Re: BFS for the power kernel
 

i can confirm this, and replicate it. if you set too many high priority's.... i tried with SCHED_RR, but its not normal.

this kernel is about stable as power (good).

and i see the gains especially with scheduling pulseaudio, Xorg

Re: BFS for the power kernel
 

FWIW, I'm gone ahead and disabled the watchdogs and have been happy ever since.

Re: BFS for the power kernel
 

I've noticed this is the only kernel that has been giving me issues with voice calls.

There's a static white noise overlay over calls that comes in randomly. I've done a lot of testing versus other kernels and it's always present with BFS only. Anybody else notice this or have any insight? I can only assume it's an issue with slicing pulseaudio or another process is getting interrupted?

Re: BFS for the power kernel
 

I can confirm this. It isn't consistent and usually disappears after I hang up and call again.

Re: BFS for the power kernel
 

We know about this problem (see this post). We had lots of fun compiling kernels last weeks ;). It seems that bfs-350-to-357.patch is responsible. Here's a summary I've sent to Tigerite in a PM:
(We already determined the voltage patches in the tree weren't responsible, so the problem was either in a BFS patch or the sched_reset_on_fork patch)

We isolated the changes between our bfs-350-to-357.patch and Con's original bfs330-bfs350.patch. These changes weren't responsible, so we're still not done.

Unfortunately, other projects have been keeping me busy lately and still are. I'm very eager to find the exact piece of code responsible though and will pick the debugging up later.

On other news: the kernel-bfs tree has got BFS v0.401 in it for a while now. Kernel-power v47 will be integrated soon too. These two things combined (or even separately) make a great new kernel-bfs release, but we want to get the distortion sorted out first (or at least have tried the more easier possible fixes).

Re: BFS for the power kernel
 

Any chance of reverting the bluetooth patch that was introduced in power46? It seems to cause issues with hand-off with my A2DP headphones when a call comes in. It drops the transfer but holds the connection still.

Really appreciate the work going into this.

Re: BFS for the power kernel
 

I've noticed some other negative comments about that patch in the kernel-power v47 thread as well. As a result, I've disabled the patch in our tree for now.

Kernel-bfs has also been updated to reflect the changes kernel-power v47 brought. Furthermore, Reiser4* support has been included. No updates on the distortion though.

*Reiser4progs & libaal are in Maemo's extras-devel

Re: BFS for the power kernel
 

Hi! Just asking is it possible to reupdate the bfs kernel with wl1251 driver support? The previous version is already too outdated and would really want the new patches specially Reiser4 support. And the disabled bluetooth patch as it causes problems with me also :/

Re: BFS for the power kernel
 

As it was mentioned here:
http://talk.maemo.org/showpost.php?p...&postcount=556

The bluetooth patch introduced in kp46 (and remain the same in kp47) is probably not the cause of problems, so removing it with such a haste may be fail move, only breaking compatibility with many bluetooth mouses.

Re: BFS for the power kernel
 

Kernel-bfs already contains the wl1251 driver, just like the default kernel and kernel-power. If you mean updating it to the bleeding edge wifi drivers from lxp: I'm afraid I don't have the time to do that.
I'm also not sure whether they should be integrated at all, considering how nicely they can be distributed as stand alone packages (but that's just my opinion).

Thanks for the pointer. I don't have any bluetooth hardware to verify any problems, so I have to rely on reports from other people. Even though the bluetooth patch may not be related to those problems at all, I am still seeing posts stating they do experience problems with it (whether those are false or not). I'll re-enable the patch if it either is proven OK or updated.

Re: BFS for the power kernel
 

No problem - glad that i could help.

I'm not kernel specialist in any case, so this time i may be wrong - but as far as i know bleeding edge wifi modules can't be distributed as standalone package - that's why it is now in kernel-power v47. When modules are present, then indeed - You can just install them and load/unload as You wish. Sorry for any technical mistakes I'm probably writing here - the point is that this is 1st time someone write that using bleeding-edge doesn't need any kernel-side part.

Also, if i remember correctly, lxp created patches to allow quick integration with other kernels.

If bfs-kernel is developed such way that it already got code from kp47 - i.e kernel-side things need to use bleeding-edge wifi drivers, then ignore this post ;)

Re: BFS for the power kernel
 

You can distribute them as a standalone, although of course you need a script to then insert them or disable them. However, this has its uses should the bleeding-edge ones fail or cause issues then you can't revert to the standard ones if they are bundled with the kernel.

Re: BFS for the power kernel
 

I can say that without a shadow of a doubt it is the cause of the problems I have because I built a modified v47 without that patch and it fixed my problem, I can't speak for anyone else's problems though. I suppose the issue is do more people need bluetooth mice support than have problems with bluetooth audio because of the patch?

Re: BFS for the power kernel
 

Retsaw, if You got no problems using kp46, that this is NOT source of errors- cause path is exact same as in kp46. I'm not saying that definitely this path cause no problems. Ho ever, I agree with freemangordon, that this may be similar case to both CSSU and kp47 beign blamed for A/V problems, that - what was finally discovered - were cause by gstreamer error in ogg-support package.

By the way, freemangordon is developer of on-topic bluetooth path, so we can ask him directly. Anyway, he said in other topic that he would be glad for any info/debug data considering possible relation of his path with Your BT headset problems - on this moment he can't find any relation.

simply said, can't anyone who's experiencing such problems grab new version of BFS kernel with bluetooth path disabled, and then, test if problems are gone?

Re: BFS for the power kernel
 

Who said I didn't have problems with kernel-power v46, I did, I just didn't end up using it for long, so I put off doing a bug report at the time, and consequently forgot about it until v47 came along. And if you read what I just posted, I just said I have a build of v47 with just that one patch removed and it fixed the problem. Please try reading what I write before arguing with me. The "patch", I'm quoting it because it isn't much of a patch it just removes some code from the bluetooth stack, it doesn't add anything, so it isn't surprising that when you remove code that has been put in for a reason that things break. As to the debugging info, Freemangordon didn't tell me specifically what I need to enable to get it, so when I have some spare time and feel like it I'll have a go at working it out for myself. As it is I'm just sharing the information I do know for certain.

Re: BFS for the power kernel
 

Retsaw, I;m not arguing You - just asked, cause 99% times when someone say "kp47 bluetooth broke my bluetooth [whatever]", he got it working nicely with kp46.

also, I'm not quite sure if we even talk about same path, cause i can't imagine how deleting some code would allow so many bluetooth mices to work.

Anyway, instead of complaining that freemangordon didn't provided point-blank directions, I'll contact him and mention about this topic. I'm also interested in clearing things about bluetooth compatibility - even, when this bug doesn't affect me directly. So, please don't disrespect my even small contribution to ensure max possible quality, either or kp47, or bfs-kernel ;)

Re: BFS for the power kernel
 

It seems you're not understanding what I was saying, try taking a little more time to read posts you intend to respond to, and if you don't understand ask for clarification. Then it might not seem like you are disagreeing with my statement, hence you coming across as arguing even if you don't mean to. And yes, I do respect that you are trying to help.

I did not ask anything in this thread, I made a statement of fact

We are talking about the same patch, download the source and have a look for yourself, I didn't understand what the code was doing, so I don't know why removing it made bluetooth mice work, but I could see it was a simple code deletion.

And the bit you took as a complaint about freemangordon not providing step-by-step instructions, wasn't meant as a complaint rather an explanation as to why I haven't investigated further. And I don't need step-by-step instructions, I'm an old-hand when it comes to linux, just something a little less vague than enable debugging in the kernel bluetooth stack when there appears to be no such option to do so. If I had missed something obvious then pointing it out would be fine. Since I didn't get a second response from him, I assumed he wasn't too bothered about this issue, which is fine by me, and I put the problem aside for the moment. I could post a thread asking for assistance if I really wanted it, but I've got a couple of ideas to investigate before saying I need help getting useful debug info, I just haven't got round to trying them.

Re: BFS for the power kernel
 

Guys, I start feeling in position to prove that my sister is not a whore.

@estel The post you mention earlier is in answer to an user which has broken bluetooth car audio (if I remember correctly) after upgrading from KP46 to KP47, that is why it is obvious that bt mice PATCH is not the cause for his problems (as it exists in KP46 too). On the other hand it seems that retsaw really has problems with this patch (at least from his explanations).

@retsaw I would define patch as "modification of source code to fix bug or to bring new functionality". I does not matter if one removes or adds lines of source code ;) . Sometimes it could cause regression. Anyway I will appreciate debug info when you find time to compile KP46 (not KP47) with BT debugging enabled (as we discussed) .

I will stop here, lets not hijack this thread. If anyone think thread "KP46 bt mice patch problem" is needed - it is easy to be opened.

Re: BFS for the power kernel
 

Regarding audio issues and the sched_reset_on_fork patch - child/daughter spawns don't pull high priority and since we no longer have cgroups or omhd working to split up and assign, a process for audio isn't inheriting FIFO or RT scheduling and is taking a back-burner to something else?

Dropping audio I/O to anything other than the highest priority on a phone is just bad news, IMHO.

Re: BFS for the power kernel
 

I've built the newest kernel without the aforementioned patch -- seems to be working fine, but only time will tell.

Only issue I'm having is building the new fcam-drivers as something seems to have changed again.

EDIT: Nevermind. Noticed some changes from Tigerite's recent bfs5 post didn't make it upstream? lxp wl12xx patches not incorporated either?