kanotix.com

General Support - Building a realtime Linux kernel the Debian way.

mzilikazi - 30.06.2006, 22:44 Uhr
Titel: Building a realtime Linux kernel the Debian way.
Edits
10-1-06 Updated patch name
10-5-06 Added prebuilt RT kernel for download.
11-16-06 small changes w/ libpam-modules
11-16-06 New rt kernel Debian repo available.

You can still use this how to if you want to build your own realtime kernel.
Please check for latest realtime patch here.

If not I am now providing some precompiled RT kernels here:

http://mzilikazi.sexypenguins.com/

You can actually use this howto for any sort of Debian kernel real time or otherwise as the procedure is the same.

I use a realtime kernel for low latency audio. Neither The Kanotix kernels nor Debian kernels are patched for rt. Get the source, get the patch(es), apply the patch(es) and build.

Tradition has us building kernels in /usr/src but it's makes no difference whatsoever where you build it. In fact you should problably not do it in /usr/src but somewhere that is writable for $USER. I do it in ~/Kernel.

Code:
cd ~/Kernel
wget -Nc http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.18.tar.bz2
wget -Nc http://people.redhat.com/mingo/realtime-preempt/patch-2.6.18-rt5
wget -Nc http://www.bootsplash.de/files/bootsplash-3.1.6-2.6.15.diff
unp linux-2.6.18.tar.bz2
mv linux-2.6.18 linux-2.6.18-rt5
cd linux-2.6.18-rt5
patch -p1 < ../patch-2.6.18-rt5
patch -p1 < ../bootsplash-3.1.6-2.6.15.diff


Now you have the 2.6.18 kernel source with realtime & bootsplash patches applied. Apply any other patches you need at this time.

You can go ahead and configure the kernel from here using your old config if you like.
Code:
make oldconfig
make menuconfig

Use gconfig or xconfig if you prefer and have the necessary pkgs installed.

Build the kernel:

Code:
fakeroot make-kpkg binary -rev (your version here) kernel_image


I do it like this:
Code:
fakeroot make-kpkg binary -rev mz1 kernel_image


Now you have several debs to install.
Code:
cd ..


Install your new kernel & headers (at least):
Code:
dpkg -i linux-image-2.6.18-rt5_mz1_i386.deb  linux-headers-2.6.18-rt5_mz1_i386.deb


I usually wait on installing the rest of the debs that were built (source, docs etc) until I know that the new kernel is working OK. Of course you'll need to reinstall Nvidia & ATI drivers (if you use them) after booting the new kernel.

libpam-modules-0.79-4 in Debian testing/sid is perfectly fine for realtime BUT
you must edit /etc/security/limits.conf.
Append the following to the end:

@audio - rtprio 99
@audio - nice -10
@audio - memlock 250000

Here
is a rather generic .config file for you to download if you like. Sorry - not confirmed that it works for latest 2.6.19 series. I'll get one up eventually.



Post if you have any issues with these instructions.
mzilikazi - 01.07.2006, 21:57 Uhr
Titel:
I just thought I might add that you can simply get a Kanotix kernel, unpack the kernel and run the source build script included therein. The script is named kanotix-source.sh or similar. Execute the script, cd into the source directory that is built there and apply the rt patch. I can confirm that the patch-2.6.17-rt5 does indeed apply cleanly to linux-2.6.17-kanotix-1.
op4latino - 02.07.2006, 05:52 Uhr
Titel: Really nice post
Nice post, mzilikazi.

I've heard a lot of making your own kernel. 50% of the time they say is something easy to do and 50% is hard. but now, it doesn't seen something out of this world.
I think the best way to learn is by example. you already explain the plain debian way. I know kano and slh put some special spicy on their kernels, so a plain debian kernel for beginners woudn't be something good to do. You explained briefly how to use a kanotix kernel. Do you mind give a full example as you did with the debian one? like for example. slh's are always the lastest kernels. however, the bootsplash patch is not inclueded. So a slh one processor with bootsplash patch example would be really appreciated Sehr glücklich

P.S. I tried to do it to figure it out myself, but slh's zip doesn't have kanotix-source.sh :\. I checked the zip I used to update to 2.6.17-kanotix-1 and indeed kanotix-source.sh was there.
mzilikazi - 02.07.2006, 09:12 Uhr
Titel: Re: Really nice post
op4latino hat folgendes geschrieben::
Do you mind give a full example as you did with the debian one? like for example. slh's are always the lastest kernels. however, the bootsplash patch is not inclueded. So a slh one processor with bootsplash patch example would be really appreciated Sehr glücklich

P.S. I tried to do it to figure it out myself, but slh's zip doesn't have kanotix-source.sh :\. I checked the zip I used to update to 2.6.17-kanotix-1 and indeed kanotix-source.sh was there.


slh uses a slightly differently named script is all.
Code:
 unp kernel-2.6.17.2-slh-up-1.zip
./slh-source.sh
cd linux-2.6.17.2-slh-up-1
patch -p1 < ../bootsplash-3.1.6-2.6.15.diff
patch -p1 < ../patch-2.6.17-rt5


Again, I can confirm that both the bootsplash patch & the rt patch apply cleanly to 2.6.17.2-slh-up-1.

*TIP* Read the slh-source.sh script. The bootsplash patch is simply commented out.
op4latino - 02.07.2006, 15:33 Uhr
Titel: RE: Re: Really nice post
Thank you, that clarify my doubts
jackiebrown - 02.07.2006, 15:45 Uhr
Titel: RE: Re: Really nice post
The only thing to remeber is to either remeber to make a intrid or do make sure you do not make the root filesytem as a module.
DeepDayze - 03.07.2006, 01:07 Uhr
Titel: RE: Re: Really nice post
Any good tweaks to make to this RT kernel, mzilikazi? if so, what would you suggest? I was able to build and run this kernel successfully.
op4latino - 03.07.2006, 03:52 Uhr
Titel: Re: RE: Re: Really nice post
jackiebrown hat folgendes geschrieben::
The only thing to remeber is to either remeber to make a intrid or do make sure you do not make the root filesytem as a module.


Okay. you kinda lost me there. I have an idea of what intrid is: when you use bootsplash, it creates/modifies one. if it isn't that what you meant, I'd be totally lost.

PS: 2.6.17.3-slh-up-1 is out, yay. thx slh Sehr glücklich
jackiebrown - 03.07.2006, 04:02 Uhr
Titel: RE: Re: RE: Re: Really nice post
That is not all that does. Just mark the filestem to be compiled instead of made as a module and you will be fine. Or you will get the dreaded cannot mount root filesystem while trying to boot.
mzilikazi - 03.07.2006, 20:31 Uhr
Titel:
DeepDayze hat folgendes geschrieben::
Any good tweaks to make to this RT kernel, mzilikazi? if so, what would you suggest? I was able to build and run this kernel successfully.


Sure plenty of tweaks. You should compile for your specific CPU

Processor Type & Features> Processor Family
OR if you want SMP
Processor Type & Features>Symmetric multi-processing support.
And BTW the realtime kernel config option lives in:
Processor Type & Features>Preemption Mode>Complete Preemption

If you want to learn more about make-kpkg do:
Code:
make-kpkg -targets


If using the genreic .config I posted you could really remove ALOT of crap that most people will simply never need like SCSI drivers, network drivers & such. For example, how many people are still using Token ring adapters or Dallas-1wire bus? It all depends on how much time you want to spend going through config options. Keep in mind that turning off an option in one place may require you to also disable another option elsewhere. If your kernel won't compile you'll have to figure out what you tweaked and untweak it or find the solution. Usually the error will give you enough of a hint that you can figure it out.

I use a .config that's specific to my own particular hardware configuration. Initially I spent a great deal of time honing it to my own preferences and now I just use it everytime I build and edit only the NEW options presented to me. My only intention w/ the generic .config was to get people kickstarted w/ something that would (should) compile without issues and run on most hardware and get the Linux geeks the ability to record some music. Smilie

It might be a very good idea to make sure you have the latest kernel version too since there are some serious security issues that needed to be addressed. My advice would be to simply use the latest slh kernel source since (thankfully) he's a security fanatic. You could always edit the source build script and forget some of the patches if you don't feel you need them but make sure you understand what they do before commenting.
floogy - 25.09.2006, 09:16 Uhr
Titel:
Sorry, that I enter this thread this way, but has someone a solution for this problem with the nvidia driver 8774 and 2.6.18-rt3 on ubuntu/debian? How can I use the original nvidia package, and turn it into a package that fits to my distro (ubuntu/dapper)?
mzilikazi - 25.09.2006, 13:03 Uhr
Titel:
floogy hat folgendes geschrieben::
Sorry, that I enter this thread this way, but has someone a solution for this problem with the nvidia driver 8774 and 2.6.18-rt3 on ubuntu/debian?


I see no problem at all, Nvidia 8774 & 2.6.18-rt3 both work just fine here but this is real Debian Sid not Ubuntu. Winken
Code:
$ dpkg -l|grep nvidia
ii  nvidia-glx                            1.0.8774-3                NVIDIA binary XFree86 4.x driver
ii  nvidia-kernel-2.6.18-rt3              1.0.8774-1+mz1            NVIDIA binary kernel module for Linux 2.6.18
ii  nvidia-kernel-common                  20051028+1                NVIDIA binary kernel module common files
ii  nvidia-kernel-source                  1.0.8774-3                NVIDIA binary kernel module source
ii  nvidia-settings                       1.0+20060516-1            Tool of configuring the NVIDIA graphics driver


Maybe it's the jaxxon patch (whatever that is).
Zitat:
How can I use the original nvidia package, and turn it into a package that fits to my distro (ubuntu/dapper)?

Surely we are not expected to support Ubuntu here now are we? That my friend will not happen.
floogy - 26.09.2006, 09:14 Uhr
Titel:
Yes it's the jaxxon patch 1), and he offered yesterday a workaround, that I didn't tested yet. (Please see the link in my last post above).

I don't think that debian/kanotix/ubuntu or whatever debianflavor packaging is that different, but I'll gonna post that question on a more appropriate list, anyway.

Sorry for the noise, but this thread seamed to be the only one where people use 2.6.18-rt3 on a debian flavored os.


1)
http://www.nvnews.net/vbulletin/showthread.php?t=70776
http://www.nvnews.net/vbulletin/showpos ... stcount=86
http://www.nvnews.net/vbulletin/showthread.php?t=67430
mzilikazi - 26.09.2006, 18:09 Uhr
Titel:
floogy hat folgendes geschrieben::

I don't think that debian/kanotix/ubuntu or whatever debianflavor packaging is that different, but I'll gonna post that question on a more appropriate list, anyway.


Kanotix IS Debian Sid. Ubuntu is NOT Debian but it is based on Debian. Their packages have been forked, patched, rewritten and who knows what else. Notice that Ubuntu does not use standard Debian repositories? There is a reason for that and it is incompatibility. Sure some packages from Debian install on Ubuntu and visa-versa but there is no effort made toward that compatibilty goal. You wanted nvidia-glx from Debian but apparently it does not work on Ubuntu. Well that's to be expected. Why not just use Kanotix? Gnome installs fine to Kanotix if that's your preferred desktop.
hey_ian - 02.10.2006, 20:33 Uhr
Titel:
I think this procedure can be used to build any type of kernel, not only the Debian one (except the kpgk command). Is it right? What if I would like to build a kernel on an RPM based system, would the procedure be different?
Oktyabr - 03.10.2006, 05:32 Uhr
Titel:
Another important tweak is to set the kernel system timer to 1000Hz. This is important for serious MIDI work anyway and apps like Rosegarden will choke out of the box if it finds you are running a kernel with a lower setting.

http://www.rosegardenmusic.com/resources/faq/#toc31

As for the validity of a realtime kernel option? Here are a few reasons:

Music creation is one of the #1 reasons people like me use linux. There are quite a few excellent music software packages out there for linux ( http://www.linux-sound.org/one-page.html ) and while most of you don't realize it a similarly equipt studio in Windows or Mac OS would cost well over US$1000... just for the software!

A realtime kernel in linux with the right software is actually much higher performance than Windows or Mac on the same hardware... for music creation/manipulation anyway. No messing around with ASIO drivers and software compatibilities either. Extremely low latencies even with average hardware... extremely important if you are going to try and do anything halfway serious in regards to recording live sound in *time* with prerecorded tracks... "layering".

This is an important niche for linux to fill. So important that there are at least a half dozen different distros out there targeted at "realtime" media production including at least one commercial distro ($$$). As Kanotix is, IMHO, the very best path to Debian it would be highly desirable to many people if an RT kernel option (available even as a seperate download) were available. This can do nothing to hurt Kanotix's popularity and even help bring more windoze users over to the penguin side.

Thanks for the how-to!

Would also love to see a more detailed one describing how to build a true "Kanotix" kernel with full preempt (realtime) capabilities.
mzilikazi - 03.10.2006, 13:21 Uhr
Titel:
hey_ian hat folgendes geschrieben::
I think this procedure can be used to build any type of kernel, not only the Debian one (except the kpgk command). Is it right? What if I would like to build a kernel on an RPM based system, would the procedure be different?


Ask Redhat. Winken
mzilikazi - 03.10.2006, 13:25 Uhr
Titel:
Oktyabr hat folgendes geschrieben::

Would also love to see a more detailed one describing how to build a true "Kanotix" kernel with full preempt (realtime) capabilities.


Already done! Please read my post from Jul 02, 2006.

Zitat:

Code:
unp kernel-2.6.17.2-slh-up-1.zip
./slh-source.sh
cd linux-2.6.17.2-slh-up-1
patch -p1 < ../bootsplash-3.1.6-2.6.15.diff
patch -p1 < ../patch-2.6.17-rt5



Again, I can confirm that both the bootsplash patch & the rt patch apply cleanly to 2.6.17.2-slh-up-1.

*TIP* Read the slh-source.sh script. The bootsplash patch is simply commented out.


I have not tried patching any of the latest Kanotix kernels for RT.
mzilikazi - 06.10.2006, 14:01 Uhr
Titel:
OK now you can get your very own precompiled rt kernel.
Kernel 2.6.18-mz-rt5 can be downloaded from here.
This is packaged just like the Kanotix kernels. It is patched with the same patchset used on 2.6.18-slh-up-2. ALso included is the PAM module needed for RT. It's installed with the script.

All modules plus kernel image, headers and doc are in a zip file.
Download the .zip archive, unpack and run the install-realtime-kernel.sh.

Only problem so far is that lirc modules failed to build for me. No chance to figure out why just yet so if you really need lirc you would need to build that module yourself until I get it fixed.

Please test the mz-source.sh script as well.

Please test and report back. Enjoy! Cool
op4latino - 10.10.2006, 20:39 Uhr
Titel:
Hi, I've already compiled 3 kernels with bootsplash and all of them have worked using a mod kanitix/slh-source.sh
Code:
2.6.18*)
      PATCH[1]="http://gaugusch.at/acpi-dsdt-initrd-patches/acpi-dsdt-initrd-v0.8.2-2.6.18.patch"
      PATCH[2]="http://kanotix.com/files/patches/t-sinus_111card-2.6.16.diff"
      PATCH[3]="$KERNELMIRROR/people/akpm/patches/2.6/2.6.18-rc7/2.6.18-rc7-mm1/broken-out/2.6-sony_acpi4.patch"
      PATCH[3]="$KERNELMIRROR/people/akpm/patches/2.6/2.6.18/2.6.18-mm3/broken-out/2.6-sony_acpi4.patch"
      PATCH[4]="http://kanotix.com/files/patches/ip1000a-2.6.18-rc5-git6-20060831-49.diff.bz2"
      PATCH[5]="http://kanotix.com/files/patches/2.6.17-rc2-usb_serial.diff"
      PATCH[6]="http://kanotix.com/files/patches/2.6.18-rc7_bcm43xx_fix-lockups-netdev_timeouts.diff"
      PATCH[7]="http://kanotix.com/files/patches/2.6.18_ieee80211-quiet_replay_messages.diff"
      PATCH[8]="http://kanotix.com/files/patches/2.6.18-via-quirks.patch"
      PATCH[9]="$KERNELMIRROR/people/akpm/patches/2.6/2.6.18/2.6.18-mm3/broken-out/non-libata-driver-for-jmicron-devices.patch"
      PATCH[10]="$KERNELMIRROR/people/akpm/patches/2.6/2.6.18/2.6.18-mm3/broken-out/jmicron-warning-fix.patch"
                PATCH[11]="http://www.bootsplash.de/files/bootsplash-3.1.6-2.6.15.diff" ##### This is all I've added ############
      CUSTOM_URL[1]="http://at-mirror.suspend2.net/downloads/all/suspend2-2.2.8-for-2.6.18.tar.bz2"
      CUSTOM_CMD[1]="tar jxf $PATCH_DIR/suspend2-2.2.8-for-2.6.18.tar.bz2"
      CUSTOM_CMD[2]="sed -i s/KERN_ALERT/KERN_WARNING/ suspend2-2.2.8-for-2.6.18/900-2.2.8-for-2.6.18.patch"
      CUSTOM_CMD[3]="sed -i s/KERN_ERR\ \"Suspend2:/\"Suspend2:/ suspend2-2.2.8-for-2.6.18/900-2.2.8-for-2.6.18.patch"
      CUSTOM_CMD[4]="suspend2-2.2.8-for-2.6.18/apply"
      CUSTOM_CMD[5]="rm -rf suspend2-2.2.8-for-2.6.18"
      ;;
Now, my question is: What are the PATCH[1-10] and CUSTOM_CMD[1-5] for? my understanding is that those patches are for supporting differentes hardware configuration. The more patches I put the better my kernel would handler situations. However, the less patches it has, the smaller and faster the kernel would compile (my guess). Is there somewhere where I can learn if I need all those patches? or a description of them?

My first guess would be eleminate PATCH[6] since this is desktop and it doesn't have any wireless NIC
kelmo - 11.10.2006, 07:23 Uhr
Titel:
CUSTOM_* crap was put in that nice script to support unofficial patches distributed in non-standard ways, such as within a tarball. Therefore, CUSTOM_URL points to some tarball containing a patch, and CUSTOM_CMD[@] are a bunch of commands preparing and applying the patch.

HTH
op4latino - 11.10.2006, 07:48 Uhr
Titel:
k, at least in this case those CUSTOM_CMD are preparing suspend2. I'll keep them because at least if I'm out of X, hibernate works for me. (hibernates is on d-u today, maybe it works under X now). Thank you kelmo, let see who knows about PATCH[1-10]
mzilikazi - 11.10.2006, 22:30 Uhr
Titel:
op4latino hat folgendes geschrieben::
k, at least in this case those CUSTOM_CMD are preparing suspend2. I'll keep them because at least if I'm out of X, hibernate works for me. (hibernates is on d-u today, maybe it works under X now). Thank you kelmo, let see who knows about PATCH[1-10]


Read the patch or ask google. The Sony ACPI patch for example explains it well:
Zitat:
+This mini-driver drives the ACPI SNC device present in the
+ACPI BIOS of the Sony Vaio laptops.
+
+It gives access to some extra laptop functionalities. In
+its current form, this driver is mainly useful for controlling the
+screen brightness, but it may do more in the future.
+
+You should probably start by trying the sonypi driver, and try
+sony_acpi only if sonypi doesn't work for you.


If you're not using a Sony you don't need this patch.

The bcm43xx patch is not so descriptive but you can see that it's a wireless NIC driver. No Broadcom wireless NIC? Then you don't need that either.
Zitat:
In 2.6.18-rc7, the section that prepares for preemptible periodic work
has two bugs. The first is due to an improper locking sequence that leads
to frozen systems. The second causes netdev watchdog timeouts. Both
are fixed.

Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>

Index: linux-2.6/drivers/net/wireless/bcm43xx/bcm43xx_main.c

op4latino - 12.10.2006, 03:44 Uhr
Titel:
mzilikazi hat folgendes geschrieben::
Read the patch
Doh!, easy enough. Thx
op4latino - 27.10.2006, 02:58 Uhr
Titel: linux-custom-patches-2.6.18.1-slhup2-lat_2_i386.deb
hi, after using another modified version of slh-source.sh a linux-custom-patches-2.6.18.1-slhup2-lat_2_i386.deb appeared. I dug in it and I saw it's the same content that the patches/ folder. I think I can ignore it and just install hearders and image, right?

Code:
ls *deb
linux-custom-patches-2.6.18.1-slhup2-lat_2_i386.deb
linux-doc-2.6.18.1-slhup2-lat_2_all.deb
linux-headers-2.6.18.1-slhup2-lat_2_i386.deb
linux-image-2.6.18.1-slhup2-lat_2_i386.deb
linux-manual-2.6.18.1-slhup2-lat_2_all.deb
linux-source-2.6.18.1-slhup2-lat_2_all.deb

mzilikazi - 27.10.2006, 04:35 Uhr
Titel: Re: linux-custom-patches-2.6.18.1-slhup2-lat_2_i386.deb
op4latino hat folgendes geschrieben::
hi, after using another modified version of slh-source.sh a linux-custom-patches-2.6.18.1-slhup2-lat_2_i386.deb appeared. I dug in it and I saw it's the same content that the patches/ folder. I think I can ignore it and just install hearders and image, right?

Code:
ls *deb
linux-custom-patches-2.6.18.1-slhup2-lat_2_i386.deb
linux-doc-2.6.18.1-slhup2-lat_2_all.deb
linux-headers-2.6.18.1-slhup2-lat_2_i386.deb
linux-image-2.6.18.1-slhup2-lat_2_i386.deb
linux-manual-2.6.18.1-slhup2-lat_2_all.deb
linux-source-2.6.18.1-slhup2-lat_2_all.deb


Sure.
michaa - 21.11.2006, 22:19 Uhr
Titel: Re: linux-custom-patches-2.6.18.1-slhup2-lat_2_i386.deb
@ mzilikazi

1st. Thanks for this description and for keeping it up to date. It's now easy to built a kernel and I am doing it know the third time.
My question does not concern the rt-kernel itself but problems with more than one kernel installed: Did you ever expirience the problem that you could use X only with the last kernel you reinstalled the nvidia/ati driver for? i. e. you have two kernels installed, K1 and K2. After you install the nvidia driver with K2 you don't have X when booting K1 and vice versa.
Although there is a solution ( you have to built the nvidia modul in a certain manner ) I would like to now whether or not this problem is common, and if so, whether you know a solution to avoid this.
mzilikazi - 02.12.2006, 23:54 Uhr
Titel: Re: linux-custom-patches-2.6.18.1-slhup2-lat_2_i386.deb
michaa hat folgendes geschrieben::
@ mzilikazi

1st. Thanks for this description and for keeping it up to date. It's now easy to built a kernel and I am doing it know the third time.
My question does not concern the rt-kernel itself but problems with more than one kernel installed: Did you ever expirience the problem that you could use X only with the last kernel you reinstalled the nvidia/ati driver for? i. e. you have two kernels installed, K1 and K2. After you install the nvidia driver with K2 you don't have X when booting K1 and vice versa.
Although there is a solution ( you have to built the nvidia modul in a certain manner ) I would like to now whether or not this problem is common, and if so, whether you know a solution to avoid this.


This is simple. Install the nvidia driver the Debian way. Don't use Kano's nvidia script.

Try this.
Of course you should always read any script before just executing it.

The basics are this:
Code:
update-pciids ; apt-get install module-assistant && m-a prepare && m-a a-i nvidia
apt-get install nvidia-settings && modprobe nvidia && echo nvidia >> /etc/modules && apt-get install nvidia-glx


Now you have installed the nvida driver the Debian way. This allows you to boot multiple kernels AND have nvidia drivers for each one.
op4latino - 04.12.2006, 19:46 Uhr
Titel: Re: Building a realtime Linux kernel the Debian way.
mzilikazi hat folgendes geschrieben::
Here
is a rather generic .config file for you to download if you like. Sorry - not confirmed that it works for latest 2.6.19 series.

Yeah, 2.6.19 has a lot of changes (I was told), I couldn't create my kernel with bootsplash. It still works for 2.6.18.5, tho.
Alle Zeiten sind GMT + 1 Stunde
PNphpBB2 © 2003-2007