Whoa, lots of activity in this thread since I've gone offline. Please people, do know what you're actually doing before trying stuff out. Most questions are not kernel-bfs specific. I'll however try to answer the most commonly asked questions.

I'll update the first post with some common misconceptions when I get back home this evening.

Yes, you can have only one kernel flashed to your NAND at the same time. Therefore, kernel-bfs-flashers conflicts with kernel-power-flasher.
If you want to use multiple kernels, either use uBoot or multiboot.

About the 'compatibility' issue: This is a different kernel than kernel-power/omap, so drivers probably need to be recompiled. This is expected behaviour. Fcam-drivers for kernel-bfs are linked to in the first post, but there are no bleeding-wlan drivers for kernel-bfs yet.

Kernel-bfs is a different (as in: replacing) product than kernel-power, compatibility between them is irrelevant. If you mean feature-compatible, then yes, kernel-bfs provides the same features as kernel-power does.

Maemo tends to need several boots when switching to a different (not just updated) kernel. Subsequent boots after the first succeeded one will work fine all the time though. This seems to be not related to kernel-bfs specifically. We're only exposing this issue by introducing a new kernel variant.

If you want to use kernel-power: yes. You'll need kernel-bfs-bootimg instead of kernel-bfs-flasher to use multiboot.

See my answer to an earlier post above. Co-existence tests have been performed, and this is (unfortunately) expected behaviour. Changing to different (not just updated) kernels appears to make Maemo reboot a few times before it actually loads the new one.

This can be experienced as being scary indeed. There's not too much to worry about though as far as I know.

I've got no experience with speedpatch; Personally, I'm avoiding it. The speedpatch seems to work by using cgroups, which isn't supported by kernel-bfs. Someone else will need to confirm this though.

This is a known issue, it can be even found in the very first pages of the old "BFS for the power kernel" thread. It appears to be specific to Opera. There's no fix for this currently, unfortunately.

You need to install kernel-bfs-bootimg, not kernel-bfs-flasher. Kernel-bfs-bootimg can be used alongside kernel-power since it uses multiboot.

The uninstalling procedure is the exact same one as kernel-power's one. Did you uninstall it via the menu entry "Uninstall kernel-bfs" (like you should), or via an application manager/xterm, which should not be done?

maemo kernel is removed as a conflicting package.. but it leaves the .item file in /etc/multiboot.d or something.. jus delete the maemo .item file from there..

u can jus use the kernel image to boot up..
use flasher. 3.5 thingy *google it up* and download kernel image from somewhere.. anykernel image works.. just boot up and reinstall kernel-power
u dont have to completely reflash ur device..

I found bfs is incompatible with speedpatch, xterminal will get cgroup error, sorry for my off topic

guys, if you want try bfs, you better deinstall speedpatch see see.
I got speedpatch, because I need to solve the qtlockscreen problem -.-

i didn't uninstal speedpatch.. and it works pretty ok with me..

nvm.. jus went to xterm.. installed speedpatch.. doesnt work

I am not using multiboot but was using speedpatch. I went ahead and installed kernel bfs using faster app mgr and got the compatibility error message and one about speedpatch. I ignored them and didn't install the bootimage version and all seems fine. I was never a particular fan of speedpatch anyway.

i have just installed bfs with speedpatch
but speedpatch isn't working any more

i prefer to stay with speedpatch so i will uninstall bfs

@iDont can't you make it compatible on some way with speedpatch ?
thanks for your effort

speedpatch is depreciated, placebo-like solution, so requesting support for it here is a little ridiculous. Anyway, you can always ask speedpath developers to make it compatible with kernel-bfs - I wonder how "magical" fixes would be introduced there, cause cgroups are not supported by bfs-kernel. Anyway, it is off-topic here.

While I'm big enthusiast of kernel-bfs and would love bigger audience for it, I strongly discourage non-experienced people to install this. As iDont clearly stated, it may be rough at the edges, and some features - like bq27x00_battery - even dangerous (although, only theoretically, unless someone fill trustworthy damage report ). Use at own risk, and please don't complain it it doesn't work for You - at least if You're not able to provide debug info of verbose report about problem.

Disclaimer - this is my personal opinion, I'm not a part of kernel-bfs team)
Disclaimer 2 - it's not about "elitarity", I just think newbie people should start kernel-adventure somewhere else.

// Edit

There was a heated discussion on IRC today (joerg_rw, I'm looking at You ), and I think it's worth to mention some conclusions here. The *optional* way of enabling dangerous path for bme and other i2c sucker coexistence, is considered really dangerous, and *don't* touch it, if You don't know what you're doing. iDont already stated it clear way, but I would like to mention that some believe (for good reasons) that possible conflict on i2c bus may cause serious hardware damage, as kernel is talking with power chip via i2c thousand of times per second. Really, really avoid it if you don't know for sure what enabling this means.

has anyone seen this weird bug... it was like the desktop had crashed however the phone was still working and all of the apps i was running atm were layered on top of each other... sadly no screen shot

As Estel has correctly stated, cgroups aren't supported by the BFS scheduler. For what I see, the speedpatch is implemented via cgroups. Therefore it can not be made compatible.

The hildon-desktop process appears to have crashed. I haven't heard of any other reports of kernel-bfs users, nor have I ever experienced something similar myself. A lot of factors can trigger such an event (e.g. widgets) or an unstable overclock.

If applicable, try removing suspicious widgets (if you have any) and remove/lower your overclock. Please report back if it happens again.

iDont, from irc logs I see you're planning to reverse way to enable co-exist of bq27x00_battery.ko with bme, and make it accessible only from garage page.

Of course it's up to you, but I strongly advocate for not doing so. Method that joerg_rw advocate (open/close of i2cget access) was described by 412b (author of well-respected advanced-interface-switcher and advanced-power-monitor), as very resource intensive.

I will try to settle a conclusion about it, cause joerg_rw seems to think otherwise, but I would advocate waiting for proper fix - in any way - instead of disabling it all-together "just in case someone may enable well-described as dangerous feature and f*ck her/his device".

/Estel

// Edit

It seems that joerg_rw proposed some alternative, safe solution - and that's great, but I would wait with reverting patch in repos version, before someone actually implement it. IMO, theoretical solution isn't enough to ban current, only one available solution.