HOWTO: Use a jp14 enhanced kernel with Gentoo & gcc-3.2

[474]

This document is intended for you if you happen to fall into any of the following categories:

1. You're interested in trying the jp14 kernel patch set
   
2. You've already tried the jp14 patch set and couldn't get it to work (especially if you're running gcc 3)
   
3. You're not really happy with gentoo-sources custom kernel
   
4. You're not really happy with the stock 2.4.19 vanilla-sources
   
5. You run a desktop system (or otherwise) and want improved multitasking and latency
   
6. Insert your reason here: ________________
   

I have been able to compile a jp14 kernel 100% successfully using a Gentoo 1.4 (gcc 3.2) system. Unless stated otherwise, the following information applies to such a system and it should be noted that the validity of the information here can't be asserted for other systems. Some of the more noteable features of jp14 are (a few of which are used in the gentoo-sources kernels):

• Ingo Molnar's utlra scaleable O(1) process scheduler
  
• Jiffies (to increase task switching rapidity)
  
• Robert Love's preemptive and lock-breaking patches
  
• Minimalistic version of Andrew Morton's low-latency patches
  
• rmap (reverse mapped memory manager for more intelligent memory page allocation)
  
• Radix tree algorithm for the page cache (don't know what that means, just that is apparently better and that in this case it's been modified to work with the others )
  
• CryptoAPI and Free S/WAN
  
• grsecurity
  
• New filesystems: latest ext3/NTFS code, JFS, Reiserfs, XFS etc
  
• Various fixes including: mainboard chipset fixes, AMD CPU cache fix, Intel SpeedStep support, DMA support for audio CD ripping
  
• Supermount - provides automatic mounting of removeable media
  
• Support for IDE tagged command queueing on IBM Deskstar drives
  
• more ...
  

The homepage for the jp14 patch is here: http://infolinux.de/jp14/. Please note that the page lacks documentation, so have a look at http://infolinux.de/jp13/ if you're interested. Although jp13 is an older version of the patch, most of the information on that page adequately describes the major patches which are still present in jp14. Please be sure to read the notes on the jp14 page so that you are aware of any known issues! I make no claims to have tested every possible build choice with the jp14 set so perhaps some things aren't working as expected (have a look at the notes on the kbuild backport to see a warning about that).

In jp14, all of the individual patches have been carefully scrutinized and modified to work with one another. For this reason, one cannot be too selective about which patches to apply. However, if all of the patches are applied then the kernel build process will fail, at least with gcc 3.2. After a lot of testing, I have found that certain patches can be safely excluded, and that the absence of these patches will result in error-free compilation. They are as follows (where the first 3 digits of the patchname are shown - consult the jp site or the patches themselves to see what they are):

• 044 045 089 - These patches are supposed to update the ACPI portion of the kernel. They will apply succesfully but the kernel will not compile.
  
• 077 078 079 080 081 082 084 - These patches will remove OSS sound support completely from the kernel, replacing it with ALSA. These should be omitted because (a) The kernel doesn't build successfully (b) We should really use "emerge alsa-driver" instead which will build ALSA modules separately and will integrate the service extensions into your system in suitably Gentoo-like fashion. Thankfully the alsa-driver build works with the jp14 kernel, even though the build seems to be sensitive to modified kernels. Remember that you only need to select Soundcore Support (either statically as a module) to be able to compile the alsa-driver afterwards. There is no need to select any OSS sound driver modules. If you do, then make sure you choose them as modules if you are intending to use ALSA (otherwise they will probably conflict - horribly).
  

You may experiment with excluding other patches (I have found that many of the "extras", such as the filesystem related patches and supermount patches can be safely omitted also, if so desired), but if you remove one that is required for the set to work then you will end up getting hunk errors during the patching process. If that happens, then start again because the kernel will almost certainly not compile or work properly. With that out of the way, let's look at the process:

Creating and compiling a jp14 patched 2.4.19 kernel

1. Download the jp14 patch collection here: http://infolinux.de/jp14/patchset-2.4.19-jp14.tar.bz2
   
2. Assuming you have it in /usr/src/patches do:
   

   Code:

   bunzip2 -c patchset-2.4.19-jp14.tar.bz2 | tar -x

   
   whereupon the patches should be in /usr/src/patches/jp14
   
3. Make sure you have emerged vanilla-sources.
   
4. Copy the vanilla 2.4.19 tree to a custom directory and update the /usr/src/linux symlink:
   

   Code:

   cd /usr/src mkdir linux-jp rm -rf linux ln -s linux-jp linux cd linux cp -Rp ../linux-2.4.1.9/* ./

   
   
5. Apply the desired patches in turn, here's an example showing how to apply the first patch:
   

   Code:

   patch -p1 < ../patches/jp14/000_amd-cache-fix | grep fail

   
   The use of grep here means you won't see anything unless something went wrong. Repeat the process until you have done all of them (the last one being 100). Be sure to avoid applying the patches mentioned earlier on, and be sure to apply them strictly in numerical order.
   
   TIP: This step is dull. I have a script to do this, I'll edit the post soon and pop it in here ...
   
   
6. Better do this:
   

   Code:

   make mrproper

   
   
7. Now configure your kernel as desired using make menuconfig or make xconfig. Select the Preemptive Kernel ption if you want a more responsive system and select the Break Extra Locks option if you want an especially responsive system (maybe at the cost of overall performance though). The extra filesystem options (inculding supermount) are under the appropriate category. Don't forget to set the jiffies value to 1000 (it will be 100 by default).
   
8. Now just build the kernel in the usual fashion:
   

   Code:

   make dep && make clean bzImage modules modules_install

   
   There is no need to worry about /lib/modules because the jp14 patch appends the text "-jp14" to the end of the kernel identifier string. So any kernel modules will go in /lib/modules/2.4.19-jp14, whereas the modules for your original vanilla kernel would remain safely in /lib/modules/2.4.19.
   
9. Finish:
   

   Code:

   mount /boot mv /boot/bzImage /boot/bzImage.vanilla cp arch/i386/boot/bzImage /boot

   
   
10. If you really want to play it safe, You may wish to change Grub's menu.lst file and add an extra entry to point to the bzImage.vanilla kernel that you just backed up. That way you can choose to boot jp14 or vanilla in case you have any problems or you simply want to compare and contrast performance. The modules are kept in unique directories as mentioned above in step 8.
    
11. Reboot.
    

Compiling ALSA

Assuming all went well (check you're actually running the jp14 kernel with the uname -a command), here are the steps to compile ALSA:

1. Remove ALSA if you had emerged it on the kernel you were using before:
   

   Code:

   emerge -C alsa-utils emerge -C alsa-lib emerge -C alsa-driver

   
   
2. Simply emerge it again:
   

   Code:

   emerge alsa-driver emerge alsa-utils

   
   As Portage protects your /etc files, you shouldn't have to reconfigure your alsa devices again, assuming you had it correctly set up in the first place.
   
   Note that you should be able to save some time by compiling the ALSA driver for your specific card. For example, I use a Soundblaster AWE64 so I would perhaps want to issue:
   

   Code:

   env ALSA_CARDS='sbawe' emerge alsa-driver

   
   instead.
   

Using Supermount

If you compiled supermount into your kernel, you may be wondering how to use it. Well supermount appears to be available to the kernel as a filesystem, so you specify that as the type. Then you pass the actual device as part of the options for the mount command, *not* in the conventional fashion. Here's an example which will give supermount support for your CDROM drive:

[GreenCorduroy]

I tried out the jp14 patch per your instructions. The kernel compile works fine, however when I try to compile the alsa-driver I get "parallel make failed" errors irregardless of which ebuild of the alsa-driver I try to use.

If I try to disable parallel make (after searching the forums ppls said you can by either commenting out the MAKEOPT="-j2" in make.globals or replace emake with make in the ebuild), I still get parallel make errors.

Is there anything in specific that I should be aware of that I need to include/exclude so I don't get these errors?

Thanks

[474]

[Selkie]

Even without having the time to try your guide i respond with a "thank you" to let you know your work is appreciated

_the_ feature i need from the jp patches is XFS because my brand new gentoo kernel only says "kernel panic" when trying to mount my XFS "/"

[474]

Just to let everyone know that the work above has been superceded by LostLogic's (the Gentoo kernel maintainer) work on the newer gentoo-sources (r10) and lolo-sources ebuilds. The patches in r10 are more up-to-date and have, no doubt, been better tested. As of now, it probably makes a much better replacement for the kernel born of the above procedures. It's masked so you need to use the ebuild command to fetch and unpack it. I would invite readers to join me in testing it.

I believe that the lolo-sources are a little more on the 'cutting-edge' and will be desirable for those who want supermount support. For both these kernels, the following USE flags are worthy of note:

* crypt -> Compiles in crypto API and FreeS/WAN (for IPSec)
* acpi4linux -> Compiles in the very latest ACPI code (can be dangerous)

EDIT: gentoo-sources-r10 has supermount support too.

[rac]

The xfs USE flag will doubtless be of interest to some people as well.
_________________
For every higher wall, there is a taller ladder

[474]