Sounds fair.

WPA2 stops working as soon as I reload cx3110x. It doesn't matter whether I use the old or the new module. At first I thought this was a reinitialisation issue so I replaced the modules in initfs and rebooted. During boot up the device froze (at ~85 % of blue bar phase; I no longer remember what it does during that time) and rebooted. Luckily the second attempt was more successful. Still, network didn't work. I restored the old kernel in initfs, rebooted and got network back. Still, the second I reload the module, WPA2 fails.

In other news, I haven't experienced any unexpected behaviour with the kernel. I have observed the battely applet not to be redraws instantly after undimming the screen but that's about it.

Hi,

I have installed and tested the latest sd preempt 256 kernel. The install.sh script is very useful to go back and forth. Everything I have tried works.

The only annoyance that prevents me from keeping using it is that graphics updates are clearly slower than when using the kernel I have compiled (http://talk.maemo.org/showthread.php?p=927613), for instance when pressing the home button (the cpu governor is set to performance in both cases), which is what pleases me so much with my kernel. I as far as I understand, this could come from either the sd or the preempt patches or the 256Hz timer. How can I debug that?

Do your kernels use the mmc high speed patch?

Thanks again for the good work.

Thanks
I think it could be a cosmetic effect of the SD scheduler fairness, and kernel preemption and the 256 timer can increase it a bit. Possibly the same effect that can be seen at boot when the hildon desktop appears. With the O1 kernel it seems to appear "faster", while with the SD kernel it seems to appear "slowly" and "take longer" to boot. What really happens is that both take the same time to boot (70 seconds in my N810), but the hildon desktop start drawing sooner.
I think it could be explained as follows:
The O1 scheduler is very unfair, and a high priority task will starve any lower priority task, and even same priority tasks.
SD is very fair, and will guarantee that every task gets its cpu share in a given time, ensuring no starvation happens.
At the end of the boot process, several tasks are competing for cpu. Under O1, the high priority tasks will starve hildon-desktop until they finish, then hildon-desktop will receive the cpu and will paint the desktop in one go, just before the end. On the other hand, under SD, hildon will receive a bit of cpu as soon as it starts, the the cpu goes for another task, then a while later another bit..., and so it will paint the desktop during a longer period.
When pressing the menu button, top shows at least 3 processes competing for cpu: dbus-daemon (nice -5), xomap and hildon-desktop (both nice -1). Under O1, dbus will monopolize the cpu until it finish, then xomap and hildon-desktop will be able to do their job and paint the menu. Under SD, dbus get a chunk of cpu, hildon-desktop and xomap a bit, then dbus, then hildon desktop, then xomap.... Overall time to draw the menu is about the same, visual effect is different.
To debug this, a more objective measure would be desirable, like a camcorder. I think on Friday I'll be able to sort, package and upload the source patches, then you'll be able to build any kernel variant.
But, if you wish to save some time (building all kernel combinations takes TIME), you can compare the kernels in the first big package (just avoid the cfs ones, I don't think they are safe):
Stock/community ssu == O1 non-preempt 128 HZ
Then you can check the effect of preemption with the O1-preempt-128
Then the effect of the 256 HZ timer with the O1-preempt-256
Then the effect of the SD scheduler with the SD-preempt compared with O1-preempt (either 128 or 256)
Yes.

Ok, all that you maacruz have wrote sounds difficult for me because of my English knowledge.
I want you to answer in simple words on three my questions:
1. Should I install whatever you've created and described here in this topic?
2. How can I install it?
3. I have no dog to be killed if something will go wrong. Do I really need one?

LOL.
I'm not native either, so I could have made some *unwanted* sounds
I guess you should. It is safe and easy to undo. Or you can wait for the next update, that's up to you.
I'm building deb packages but have been delayed by a couple of issues. I have just solved one of them (and proved it to be unrelated to my packages), and the remaining one is fairly minor, so it seems I'll finally will be able to finish the packaging without more delay.
Download the latest sd-preempt-256 package. Make a directory somewhere (may be in mmc) and untar it there. Run the installation script by typing "sh install.sh sd-preemptnovermagic 256" there.
When installing, it will create a backup of your current kernel and modules. If you wish to uninstall later, run the installation script by typing "sh install.sh backup"
I actually like dogs. I would be very sad if you get one and the poor creature gets killed as a consequence of any software failure, so as far as I'm concerned, it is better if you don't get one for this purpose.

Ok then. I certainly going to wait until deb package will be released because it looks like it will be available shortly and provide some more features.

If It is really important I can borrow my neighbor's hamster but I hope I will be alright without it.

Thank you very much.

Of course it can be, the key word is "community" ;-) In fact I was trying to add the swap notification patch myself, but hit some problems (kernel oops during swapon) that I haven't managed to track down yet. Which brings me to

Any ETA on sources?

Between tomorrow and the weekend. Today I'm too tired and making mistakes, testing the kernel deb ended in a boot loop just now, had to reflash kernel with usb cable.

i tried the install script and got this error : tar: /lib/modules/2.6.21-omap1: Cannot chdir: No such file or directory
edit£ I'm a noob. I created the directory no installing i will report when done :P

ONLY N8x0 DEVICES RUNNING DIABLO OR COMMUNITY SSU!