Logo

Miscellaneous Patches

On this page I would like to collect all sorts of patches I am using in the context of my Linux systems. The list may be incoherent and incomplete, but anyway, I wanted to record them somewhere. Unlike a blog, I will simply attach new articles at the end of the page.

This article has been updated on 2011-05-21

Desktop Theme

Lately I have spent some time on customizing the visual appearance of my KDE desktop, and I believe by putting together bits and pieces from various sources I managed to create a slick and appealing design that makes most standard Linux and Windows desktops look dated. And yes, this statement includes Vista. You can download the KDE desktop theme I am using from here. The images have been optimized for the 1280x1024 resolution I am using on my flat panel screen.

However, for the full effect you also need to choose the right window decorations (Smooth Blend), install a suitable icon theme from www.kde-look.org (Amaranth) and configure your console and explorer windows similar to the following screenshot:

KDE Desktop

KDE Splash

Having created an appealing desktop appearance, there was the whish to have the KDE startup and logon follow the same theme. After a brief search I found a suitable splash for download on www.kde-look.org. I have just taken the liberty to adapt the background image and the fonts according to my desktop theme. You can download my KDE splash from here. You will also need to install a package called moodin if it is not already part of your distro.

KDE Splash

For the actual logon screen you can specify the background image and the icon of the logon box from the KDE control centre (root password required). In my case I chose them to match the background image and font used in the desktop theme. On single-user machines you can also choose to log in automatically.

Boot Splash

So far so good. Pushing the limits further, I now wanted to display the background image from the beginning of the boot process. To some extent this can be achieved using a well-known kernel modification called "bootsplash" which makes use of the framebuffer device to display images and overlay them with console output. In order to display the picture as early as possible in the boot process, the bootsplash extension reads a jpeg file from the initrd ramdisk if one is provided. I do not provide an extensive howto on the bootsplash extension here, but there are plenty available on the web.

Please observe that bootsplash comes in two parts: one is a kernel patch and the other consists of user mode applications. The kernel patches are available from bootsplash.org. The latest version of the kernel patches that I found was version 3.1.6 patched against the 2.6.21 kernel.

The source code of the user space utilities is also available on the site. However, in most cases you can find a binary package ready-made for your Linux distribution.

Update: Since maintenance for bootsplash has ceased, and the latest kernel patch on bootsplash.org is for 2.6.21, I have taken it upon me to create patches for later kernels. Use at your own risk. Please note that I cannot maintain the actual bootsplash code. I just adapt it to kernel changes. If you need the patch for a kernel version not listed below, try the closest match but pay attention whether the patch applies without rejects.

Bootsplash 3.1.6 patch for kernel 2.6.21

Bootsplash 3.1.6 patch for kernel 2.6.23

Bootsplash 3.1.6 patch for kernel 2.6.25

Bootsplash 3.1.6 patch for kernel 2.6.31

Bootsplash 3.1.6 patch for kernel 2.6.36

Bootsplash 3.1.6 patch for kernel 2.6.37

Bootsplash 3.1.6 patch for kernel 2.6.38

Originally I had great ambitions for customizing the boot process. I wanted to present the final desktop to the user, starting immediately after uncompressing the kernel. The screen looked like this (with the diagnostic messages srolling by in a fake Konsole window):

Desktop Boot Splash

In order to achieve this effect I had to use the same video mode for the framebuffer console that would later be switched to by the X server. I found I could not use the VESA frame buffer device (vesafb). Reason being that vesafb can only switch to BIOS modes, and no suitable mode is offered by my BIOS. So I had to patch the bootsplash code to run with other framebuffer devices, in particular the ATI Rage frame buffer device (aty128fb).

Next I ran into the problem that aty128fb can only switch to video modes pre-defined in the kernel coding, and there was no suitable video mode defined. In fact, most of the pre-defined video modes looked rather weird and outdated. Eventually I decided to patch the entry closest to my needs and fine tune the parameters manually to provide an output identical to the X server.

The final problem was that of corrupted colours. Apparently the bootsplash extension and the ATI Rage frame buffer device disagreed on the colour representation of pixels in 16 bit mode - maybe this is simply an error in the coding of the ATI Rage frame buffer driver. I tried to understand the driver coding and fixed it in a way that appeared correct to me. However, since I am no expert for ATI hardware nor for Linux kernel code this is nothing I would consider safe to use for a wider public.

Anyway, since the idea of presenting the final desktop during startup is causing so much trouble I have gone off the idea. Nowadays I use vesafb showing a Slackware theme I downloaded from somewhere. (More precisely, it is the package bootsplash-12.0-1kta from linuxpackages.net).

Slack Boot Splash

Boot Image

For the icing on the cake, the only work left was to create a graphical theme for the boot loader (lilo). At that stage there are only video modes available provided by the BIOS. I used a scanned image of myself in my younger days and created the following lilo boot image:

Boot Image

Please note that the corresponding headers have been updated in the image file (check out man lilo for the -E option) so that all you need to enter in lilo.conf is

bitmap = /path/to/mrboot.bmp
bmp-retain

In the next three sections I am going to describe the aforementioned patches that I no longer use. They are provided here just in case someone is interested.

Making bootsplash work with framebuffer drivers other than vesafb

Apparently the bootsplash code contained a check against the framebuffer driver at some point. This check has been commented out in version 3.1.6. The only reference to the vesafb driver I found in the parameters for the kernel configuration. This can be easily removed using the following patch:

bootsplash-3.1.6-enable-all-fb.patch

Instructions: the patch is applied with flag -p0 to the bootsplash-modified kernel sources in their base directory, often /usr/src/linux.

Note: The patch only removes the remaining protection of bootsplash against non-vesafb drivers. Use it at your own risk. If bootsplash does not work with another framebuffer driver, do not blame me!

Fixing the 1280x1024 mode of the aty128fb driver

The built-in screen modes used by aty128fb and some other framebuffer drivers are defined in file drivers/video/modedb.c. My assumption is, this file has been created in the early framebuffer days, maybe when the framebuffer was still an exclusive m68k project. The source and the purpose of those built-in screen modes is not clear, and they have not been kept in sync with screen modes of the corresponding XFree or Xorg drivers.

So ideally, an overhaul of the whole mode data base is in order. Failing the necessary normative power, I have resigned to fixing the one screen mode I am interested in (1280x1024 pixels at 60 Hz) and to make it run with the same monitor parameters as the corresponding mode of the Xorg rage128 driver. The patch is this:

linux-2.6.21-modedb-1280x1024@60.patch

Instructions: the patch is applied with flag -p0 to the kernel sources in their base directory, often /usr/src/linux.

Note: The patch is independent of bootsplash and might make sense for you even without using bootsplash. If the timing does not work for you, or if you are interested in changing another built-in screen mode, just go and modify drivers/video/modedb.c directly.

Changing the colour coding used by the aty128fb driver

This patch could be considered controversial since it changes the behaviour of a standard driver (irrespective of bootsplash). Maybe I should discuss it with the current maintainer, should I be able to locate him (or her ;-). However, before that I would like to gain more understanding of driver and hardware and do more testing outside of the bootsplash environment.

The patch works well for me with bootsplash and its 16 bit colour representation mode. It has not been tested in 8 bit, 15 bit, 24 bit or 32 bit modes. Without the patch, the bootsplash image would appear in weird colours on the screen, whereas a screen shot of the framebuffer content would almost always be fine.

To be honest, I was not able to understand the original code setting up the colour registers. I therefore replaced the code based on my (possibly incomplete or wrong) understanding. My understanding is that the video card is configured to use a direct colour mode when using a 15 bit or 16 bit colour representation. I believe this means, the pixel values for each colour channel are translated using a colour lookup table implemented by the colour registers. Therefore, unless you want to do fancy things like gamma control, the colour registers of the video card should implement an identical mapping. That is what my patch implements.

My untested hope is that 24 bit and 32 bit modes either use the same mechanism or use a true colour mode bypassing colour lookup. In either case the 24 bit and 32 bit modes should work with my patch.

The only problem could be the 8 bit mode since this typically requires setting up an application specific colour lookup table which is currently not implemented in my coding.

Be it as it may, my coding makes bootsplash work, which is good enough for me for the time being. Without further ado, here is the patch:

linux-2.6.21-aty128fb-colour.patch

Instructions: the patch is applied with flag -p0 to the kernel sources in their base directory, often /usr/src/linux.

Note: The patch is independent of bootsplash, but required for correct visual output of the latter.

So much for the patches related to desktop themes and bootsplash. I will now present other odds and sods collected over time.

Djbdns

The DNS resolver of the Djbdns package is named dnscache, pun intended. ["named" - got it?] It reads the list of DNS forwarders when it is started. If the DNS forwarders change, for instance after reconnection of a DSL line, you would have to stop and restart dnscache. My patch makes it accept a SIGHUP signal and re-read the list of DNS forwarders. The patch provided here was created from the djbdns version 1.05.

dnscache-1.05-sighup.patch

Instructions: the patch is applied to the file dnscache.c in the djbdns source directory prior to compilation.

Pppd

The PPP daemon pppd offers a mechanism that closes down the current connection after a certain idle time. Both incoming and outgoing packets reset the idle timer. Unfortunately, these days there is a constant stream of unsolicited packets coming in from the internet - only to be filtered out by the firewall in a subsequent step. This makes the pppd idle function almost useless. The easiest way of fixing it is to make pppd ignore incoming packets when counting the idle time. Here is a patch for pppd version 2.4.4:

pppd-2.4.4-xmit-idle.patch

Instructions: the patch is applied to the file auth.c in the pppd source tree prior to compilation.

SCSI authorisation

At some point in 2.6 development, an additional check was introduced to limit the list of SCSI commands a non-root user could issue to a SCSI device. At the time it caused some trouble since it broke the burning of CDs and DVDs for non-root users. I believe the standard solution is to make the affected programs setuid root, but here is a patch disabling the authorisation check anyway.

linux-2.6.21-scsi-auth.patch

Instructions: the patch is applied with flag -p0 to the kernel sources in their base directory, often /usr/src/linux.

2G:2G user/kernel split

During the execution of a user process, the 4G logical address space of a 32 bit CPU is organised as follows: 3G are available to the user process and 1G is available to the kernel. In particular, the top 1G always contain the same data for quick access by the kernel, whereas the lower 3G are remapped at the time of context switch to contain the address space of the next active user process.

Please observe, logical address space is a concept different from physical memory. The logical address space is organised in pages or tiles

Also note that the same physical page can be mapped to different pages in the logical address space of more than one user process.

Under normal circumstances, the kernel maps the physical memory into his own address space a second time. This means the physical memory needs to share the 1G kernel address space with other items. As a result, the kernel cannot address more than 896MB physical memory!

In the past, if you had more physical memory than 896MB you had to enable "High Memory Support" in the kernel options. This has a minor performance drawback: the kernel then has to map the correct window of physical memory into the kernel address space every time before accessing it.

With the following patch you can enable a different split between user and kernel address space to enable 1G, 2G or even 3G of physical memory without having to enable "High Memory Support".

Note, however, that you pay a price: if for instance you select a 2G:2G split the maximum logical address space of a user process will be limited to 2G (not 3G as before). This may be too little for some applications. The only application known to me with that sort of problem is wine (a runtime environment for MS Windows applications under Linux). Wine needs the whole 3G address space in order to create a suitable mapping to the memory layout under MS Windows.

linux-2.6.21-user-kernel-split.patch

Instructions: the patch is applied with flag -p0 to the kernel sources in their base directory, often /usr/src/linux.

Note: the patch does not actually do much. It simply enables kernel options that are normally hidden (unless the kernel option EMBEDDED is set).

Credit: the patch originates from Con Kolivas' kernel patches.

Kernel 2.6.25 and ATI driver fglrx 8.476

Update: The ATI driver has been updated since writing the original article. The driver fglrx 8.501 (ie. catalyst 8-6) suports kernel 2.6.25 natively. Nontheless, I shall keep the section below for reference.

Both the Linux kernel 2.6.25 and the ATI driver fglrx 8.476 were released at about the same time. Unfortunately the video driver does not compile with the kernel due to changes in the kernel API. However, all is not lost. With a few minor patches to the wrapper code of the driver, and with setting a suitable kernel option you can get it to work.

First you need to prepare the kernel. There are two issues. First, we need to make the symbol init_mm available to the driver module. The easiest method is to set the kernel option CONFIG_UNUSED_SYMBOLS. This option is located in section Kernel Hacking of Kconfig. However, this might not be an option any more in the next kernel version. Therefore the safer option is to patch the kernel in the following way:

kernel-2.6.25-export-init_mm.patch

Instructions: the patch is applied with flag -p0 to the kernel sources in their base directory, often /usr/src/linux.

The second kernel issue is about licenses. During the work on making RCU routines preemptible, new symbols have been introduced and marked GPL only. This means, only modules adhering to the GPL are allowed to call those routines. Obviously there are two ways out of this: we can change the license of the ATI driver to GPL, or we can lessen the RCU requirements. In my first version I had chosen to change the ATI driver. However, changing a coded license statement of a third party driver is legally dubious, particularly when you consider giving the changed driver to other people. On the other hand, changing the coding of a kernel source is perfectly legal under the GPL, even if the coding expresses a request about its intended callers. For that reason I will clearly advocate patching the kernel to solve the issue.

kernel-2.6.25-rcu-license.patch

Instructions: the patch is applied with flag -p0 to the kernel sources in their base directory, often /usr/src/linux.

One final remark on open source licenses: I usually try to avoid the heated discussions about this topic, but some open source proponents really need to think about whether they shoot themselves into their own foot with those ideological restrictions. If we want to advance Linux and free software in general, we must co-exist with the world of proprietary software and make it easy to interface. That's what openness is really about. In the long run - as proprietary solutions come and go - the open software will prevail and glue everything together.

Next, compile and install the kernel. Reboot into console mode and log on as root. We are now ready to install the fglrx driver. But before we continue, make sure you have downloaded the patch

ati-fglrx-8-4-kernel-2.6.25.patch

The fglrx driver is shipped in an executable archive called ati-driver-installer-8-4-x86.x86-64.run. Normally the archive will extract the files and install the driver all in one go. We need to break up this procedure in order to modify the source code. So first we extraxt the files. For illustration purposes I use the work directory /usr/src/ati.

sh ati-driver-installer-8-4-x86.x86-64.run --extract /usr/src/ati

Next we change into the work directory and apply the patch.

cd /usr/src/ati
patch -p0 < ati-fglrx-8-4-kernel-2.6.25.patch

Finally we continue the installation process as if nothing had happened. ;-)

./ati-installer.sh 8.476 --install

Kernel 2.6.25 and Nvidia driver 96.43.05

Update: I have been informed that there is an official patch issued by Nvidia. It is available here. That is probably where you should go. I shall keep the section below only for reference.

Similar to the proprietary ATI driver, the proprietary Nvidia driver will not compile with the new kernel 2.6.25. This is due to changes in the kernel API. Luckily, with a few minor patches to the wrapper code of the driver and the kernel we can get it to work.

First you need to prepare the kernel. We we need to make the symbol init_mm available to the driver module, just as we have to for the ATI fglrx driver. The easiest method is to set the kernel option CONFIG_UNUSED_SYMBOLS. This option is located in section Kernel Hacking of Kconfig. However, this might not be an option any more in the next kernel version. Therefore the safer option is to patch the kernel in the following way:

kernel-2.6.25-export-init_mm.patch

Instructions: the patch is applied with flag -p0 to the kernel sources in their base directory, often /usr/src/linux.

After that, we need to compile and install the kernel. Reboot into console mode and log on as root. We are now ready to install the nvidia driver. Before we continue, download the patch

nvidia-96.43.05-kernel-2.6.25.patch

The nvidia driver is shipped in an executable archive called NVIDIA-Linux-x86-96.43.05-pkg0.run. Normally the archive will extract the files and install the driver all in one go. We need to break up this procedure in order to modify the source code. So first we extraxt the files. For illustration purposes I use the work directory /usr/src.

cd /usr/src
sh NVIDIA-Linux-x86-96.43.05-pkg0.run -x

Next we change into the newly created directory and apply the patch.

cd NVIDIA-Linux-x86-96.43.05-pkg0
patch -p0 < nvidia-96.43.05-kernel-2.6.25.patch

Finally we continue the installation process as if nothing had happened. ;-)

./nvidia-installer

Kernel 2.6.26 and Nvidia driver 96.43.05

Kernel 2.6.26 has been released, and again the Nvidia driver will not compile out of the box. I could get it to work, however, by applying the following patches:

  1. the aforementioned patch by Nvidia, designed for use with kernel 2.6.25. It is available here
  2. a third-party patch to be applied to the nvidia driver, available here
  3. my own kernel patch from above, called kernel-2.6.25-export-init_mm.patch

Kernel 2.6.39 and Nvidia driver 96.43.19

A similar situation has arisen with the release of kernel version 2.6.39: the kernel module of the legacy driver will not compile. The following one line fix will do the trick: just unpack the driver as described above, and apply this patch before continuing the installation process.

Slackware Upgrade Tools

Upgrading a Slackware installation is a manual process that involves the assessment of the installed packages and software installed by means other than the package management. I use the following set of tools to ease the process: upgrade_slack_20110428.tar.xz. Those tools are a great help to get a grip on the installed software, and to plan and perform the upgrade. You are welcome to try them out and give me feedback.

A Note on Suspend-to-RAM

I have recently spent some time playing with Suspend-to-RAM on my Slackware installations. The results have been mixed. But more on this later. Let us first consider the difficulties inherent in this topic.

Sending a system to sleep is generally the easier part since we start from a well defined running state under control of the operating system (OS). What is required first is for all system devices to be brought into a recoverable state. This requires device drivers to comply. Next the OS passes control to the BIOS to shut down parts of the system in a recoverable way. For instance, in the case of the ACPI sleep states S1 and S3 the power supply must continue to run in order to supply the system memory with power, whereas the hard disks can be safely powered down. The main theoretical difference between sleep states S1 and S3 is the treatment of the CPU: in state S1 the CPU still runs (in a sleep mode), whereas in S3 it is powered off completely. For a more detailed explanation please refer to Wikipedia.

The tricky part is the recovery process, since all parties involved (the hardware on the motherboard, the BIOS, the device drivers of the OS as well as the OS kernel) must co-operate to recover the system state. It starts as simple as getting the system to accept a wake-up call in the first place. The wake-up event is usually a short stroke on the power button. In some cases the system accepts a key stroke on the keyboard. However, one of my systems would not reliably accept any wake-up event.

The recovery process then involves the realisation that the system is not actually booting from cold but requires basic initialisation of devices and recovery of CPU state on BIOS side, before passing control to the OS via a standardized interface. The OS kernel then continues to recover system state (MMU, file systems, devices etc.). This involves calling all device drivers to recover the state of their respective device. Anything can go wrong during that process, and if you rely on closed-source device drivers (eg. for video cards and WLAN) the road may well end here.

After this lengthy intro, let us now consider my observations on the four Slackware installations I tried. In all cases I was running a system-specific 2.6.32.2 kernel with a couple of patches (Bootsplash and the Con Kolivas kernel patch CK2 which includes a new scheduler). Apart from the laptop, the hardware is not current by any means. I am still running single and dual Pentium-3 processors with Tualatin core, which requires some hardware modification on those boards with the legendary i440 BX chip set.

On the non-laptop machines I found it pays to enable the sleep state S1 instead of S3 to implement Suspend-to-RAM. This can be achieved by applying the following patch to the file /usr/lib/pm-utils/pm-functions: pm-functions-standby.patch. The power management functions will then fall back to S1 should S3 not be availabe. The availabiltiy of S3 can often be controlled in the BIOS setup. Talking about which, the power management and wake-up functions are set up there as well.

If the power management functions work unsatisfactorily, and you wish to prevent the accidental trigger of those, they can be disabled altogether using the following patch: pm-functions-disable.patch.

Finally, these are the results I achieved on my systems:

I hope you could find something of interest in my patch collection. Feel free to send me an email if you have any questions or comments.

Martin