Wednesday, September 30, 2015

Compiling and Using Custom Arch Linux Kernel

In my previous post, I have the need to downgrade my Arch Linux kernel version in order to alleviate ACPI bug in Linux kernel 4.X. After a bit of searching through AUR, I stumbled upon a still maintained kernel 3.X, at least until 2017. This kernel is Linux kernel 3.18. Because it resides in AUR, you must compile this kernel version yourself and install it with pacman. In this post, I will explain the process of compiling and installing custom kernel 3.18 from AUR. These are the steps I carried out to do that:
  1. Clone the kernel git repository with: git clone to directory where you're going to build the kernel.
  2. Add Linus Torvalds and Greg KH keys to list of trusted keys in pacman "database" of trusted keys:
    $ sudo pacman-key -r  00411886
    $ sudo pacman-key -r  6092693E
  3. Import Linus Torvalds and Greg KH public key to your machine if you haven't done that already.
    $ gpg --recv-keys 79BE3E4300411886
    $ gpg --recv-keys 38DBBDC86092693E
    Be patient, as it could take a while searching and importing the keys.
  4. Now, you can proceed to build the kernel in the git-cloned directory in step 1. cd into the directory and makepkg:
    $ makepkg -s
    The -s flag is to make sure that all dependencies are downloaded while building the custom kernel package.
  5. Assuming the kernel package build is finished, you can proceed to install the kernel headers and the kernel itself:
    # pacman -U linux-lts318-headers-3.18.20-1-x86_64.pkg.tar.xz
    # pacman -U linux-lts318-3.18.20-1-x86_64.pkg.tar.xz
    You are advised to install kernel header first before installing the kernel as mentioned in
  6. Once the kernel is installed, the remaining step is to update your machine bootloader. If you are using systemd bootloader (a.k.a gummiboot), all you need to do is modify /boot/loader/entries directory to include entry for the new kernel. For example: Create a new arch-lts.conf file in /boot/loader/entries with the following contents:
    title  Arch Linux 3.18 LTS AUR
    linux  /vmlinuz-linux-lts318
    initrd  /initramfs-linux-lts318.img
    options  root=PARTUUID=[your_root_partition_UUID] rw
That's all you need to do to compile and install custom kernel from AUR. If you want to create your own custom kernel, you need to build your own Arch Linux package. The compilation and installation steps should be similar to what's explained above. 

Friday, September 11, 2015 "option subdir-objects is disabled" Warning and Fix

The "option subdir-objects is disabled" warning is thrown-up by GNU autotools when builds a source file in a subdirectory located beneath the's file. This is an example warning:
.. warning: source file '$(srcdir)/test.c' is in a subdirectory,
.. but option 'subdir-objects' is disabled
This warning is not fatal. What it means roughly: the generated object file will not be placed inside the same directory as the source code. The full explanation is at (scroll-down to subdir-objects option). This is the important excerpt:

If this option is specified, then objects are placed into the subdirectory of the build directory corresponding to the subdirectory of the source file. For instance, if the source file is subdir/file.cxx, then the output file would besubdir/file.o.
Fixing this problem is not hard, you just need to add the subdir-objects option to Below is an example taken from in one of my project. I placed the statement as the first entry in
AUTOMAKE_OPTIONS = subdir-objects
### ...
### Other statements
### ...
Hopefully, this helps out those experiencing this problem.

Saturday, September 5, 2015

Multithreaded Libevent/Libevent2 Server (Code Commentary)

I've been playing with libevent v2.x for a while. In the course of the "experiments", I come across Ron Cemer's  multithreaded libevent implementation (see and and also an updated version from Qi Huang (see and

These multithreaded libevent code are mostly just fine except in one department, i.e. in signal handling. Both versions calls pthread functions from inside the signal handler (albeit not directly). The said practice is unsafe. It should have handle signals in synchronous pattern instead of asynchronous pattern. What I meant by this is the code should have used sigwait() in a dedicated thread to wait for signal(s) and call pthread functions from there instead of calling pthread function inside signal handler which is unsafe.

If you've been "system" programmer, you should already know that signal handler in *NIX runs in a different execution context compared to "normal" threads execution context. Therefore, you shouldn't call anything not prescribed beforehand outside of that "not-normal" execution context.

Now, let's see what exactly I mean (see echoserver_threaded.c and workqueue.c in Qi Huang code):
int runServer(void) {
    /* Set signal handlers */
    sigset_t sigset;
    struct sigaction siginfo = {
        .sa_handler = sighandler,
        .sa_mask = sigset,
        .sa_flags = SA_RESTART,
    sigaction(SIGINT, &siginfo, NULL);
    sigaction(SIGTERM, &siginfo, NULL);
static void sighandler(int signal) {
    fprintf(stdout, "Received signal %d: %s.  Shutting down.\n", signal,
void killServer(void) {
    fprintf(stdout, "Stopping socket listener event loop.\n");
    if (event_base_loopexit(evbase_accept, NULL)) {
        perror("Error shutting down server");
    fprintf(stdout, "Stopping workers.\n");
void workqueue_shutdown(workqueue_t *workqueue) {
    worker_t *worker = NULL;
    /* Remove all workers and jobs from the work queue.
     * wake up all workers so that they will terminate. */
As you can see in the excerpt above, the sighandler() function calls pthread functions indirectly. This practice is discouraged for sure because as per POSIX standard, pthread calls from signal handler is undefined. Therefore, it's unsafe to do so.

Anyway, feel free to challenge this view :-)

Sunday, August 30, 2015

Arch Linux Brightness Button Problem in Kernel 4.X

Ever since I updated my Arch Linux installation to version using kernel 4.X series, the brightness button in my Lenovo laptop (Ideapad Flex 14) is not working properly anymore. At first, I thought it's merely a configuration problem, but it turns out there's more to it than that. Let's break it down..
  • First and foremost, the laptop uses Nvidia Optimus configuration, i.e. Intel integrated graphics + NVidia discrete GPU. However, this doesn't preclude the (ACPI) brightness buttons from working just fine under Linux kernel 3.X. 
  • Upon boot, only intel_backlight is loaded. In kernel 3.X both intel_backlight and acpi_backlight "modules" are loaded. However, after trying this workaround, it's still not working as expected. Note: I used this to modify the kernel boot parameter. 
  • The symptoms of the brightness button malfunction as follows: The button is not exactly not working, it's merely the response time for a button press to be registered in the kernel takes a few seconds. As for the brightness-level setting in /sys/class/backlight/intel_backlight is just fine. 
This bug is not entirely a bad thing, but it's irritating. For the time being, I stay away from using bleeding-edge Arch Linux with kernel 4.X and uses LTS kernel instead ( However, Greg KH mentioned that the LTS kernel will ceases support next year. We'll see what option I have by then. Maybe, I'll just remap other Laptop keys or find some other work around.


Arch Linux LTS Kernel has moved to kernel 4.1.X over the weekend. I tried to use this recommended kernel version. But it turns out the ACPI-related problem I mentioned above also exists in this kernel version. I've been thinking to use one of the kernels from from AUR, but then ultimately decided to just downgrade the kernel. It turns out that it's much easier than what I thought before. This is what I did (in chronological order):
  1. I have upgraded my Arch Linux to kernel 4.1.X LTS. Therefore, I boot into this LTS kernel version. 
  2. Log in as root and then carry-out the downgrade procedure as explained at There are only two packages that I need to downgrade, i.e. the Linux kernel and the Linux kernel headers. Therefore, I use this command:
    pacman -U linux-lts-3.14.52-1-x86_64.pkg.tar.xz linux-lts-headers-3.14.52-1-x86_64.pkg.tar.xz
    and everything went without a hitch. The machine works just like before the upgrade. The ACPI hot-keys which were not functioning properly in kernel 4.X are now working like it used to be. I'm a bit worried about systemd compatibility at this point but it seems that everything works as they should.