Compile realtime kernel in Debian lenny (preemption patch)

This is how to compile a realtime kernel (preemptive kernel) in Debian Lenny. It should pretty much be cut and paste. I run a 64 bit Intel Q6600 system on a standard pc, and had a bit of hazzle before I got latencies down to a reasonable level.
I will use the directory /var/tmp/KERNEL to build in but that is not important.

• become root

• mkdir /var/tmp/KERNEL

• cd /var/tmp/KERNEL

• wget http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.26.6.tar.bz2

• wget
  http://www.kernel.org/pub/linux/kernel/projects/rt/patch-2.6.26.6-rt11.bz2

• tar xvjf linux-2.6.26.6.tar.bz2

• cd linux-2.6.26.6

• bzcat ../patch-2.6.26.6-rt11.bz2 |patch -p1

• make clean && make mrproper

• make menuconfig (select complete preemption, choose 1000 Hz timer frequency. High resolution timers and symmetric multiprocessing SMP were already enabled)
  

• make-kpkg clean

• fakeroot make-kpkg --initrd --append-to-version=-rt-200811111930 kernel_image kernel_headers

• dpkg -i ../linux-headers-2.6.26.6-rt11-rt-200811111930_2.6.26.6-rt11-rt-200811111930-10.00.Custom_amd64.deb ../linux-image-2.6.26.6-rt11-rt-200811111930_2.6.26.6-rt11-rt-200811111930-10.00.Custom_amd64.deb

To make sure everything works as intended, run cyclictest (see previous post here) and make sure the latencies are low. I get approximately 300 us max latency which is a bit high compared to other results I have seen, but low enough for me. Make sure you stress the computer when running the test. Without the preemption patch, I get 3000 us in latency when I open a web browser. I also had to turn off things in the bios to get down to 300 us.
I tried the ubuntu realtime kernel 2.6.24 which installs fine on debian lenny, but the latency would just not come down. This indicates the BIOS setting was the crook. I use noapic nolapic as boot settings, which seem to be needed.

Update 2008-11-12:
The frequency scaling is the crook! Running a preemptive kernel as compiled above works fine until the cpu frequency jumps. It has nothing to do with noapic or nolapic, it is sufficient to prevent the frequency to change. You can do this with either disabling frequency scaling in BIOS, or lock the frequency with

for i in `seq 0 3`; do cpufreq-set -c$i -g performance; done

to get constant full speed or

for i in `seq 0 3`; do cpufreq-set -c$i -g powersave; done

to get lowest speed. Both work fine and gets the latency down to 250 us (performance ) to 20 us (powersave) when I tested, as compared to 3000 us with ondemand frequncy scaling governor. I guess I should test with heavier load and longer time to be sure, but I am confident that the frequency scaling is the one to blame. To bad, because frequency scaling is a wonderful thing.
I tried to keep only one core constant speed and locking the processes to that core with taskset

echo `seq 6050 6056` |xargs -n1 taskset -p 0x1

where 6050 is the process id reported by cyclictest.