Linux Kernel Module / Hardware Tinkering

When I first got into the Linux world (5-6 years ago), I was a beginner at the time and as usual if something didn’t work out of the box (hardware / software) I used to blame the distro and move on to the next one. I thought it was a “fair” way to do things coming from the Windows world as a Windows user. Given that there were so many distros out there at the time it wasn’t actually a bad move though, but I knew that I’d have to change my mentality if I were to survive in the Linux world.

Slowly, as my experience and skills with Linux matured I realized that I actually enjoyed if things didn’t work and I wanted things to not work as expected so that I can learn how to fix it and make it better.

In most cases just a simple google will work, but if the problem is complex; like something related to hardware perhaps the only way to go about fixing it is by being really persistent. Like the old saying goes “If there’s a will, there’s a way”.

Today I will share some of the little things I’ve learned as a Linux user on how to mess around with kernel modules, learn what features of your hardware are supported by the module and how to disable / enable them.

Mainly I’m documenting this as a self reference in case I forget somethings in the near future.

Okay first of all, if you want to see what hardware you have; which kernel modules are being used by them or in general learn more about what’s happening with your hardware you can use the following commands:

1) lspci -k
2) lshw -short
3) inxi -b
4) lsusb
5) dmesg | grep -i “keyword” //Replace keyword with something specific to your hardware / kernel module

Note that you may have to install inxi and lshw, they’re by default not installed on most distros.

Okay now, let’s say you’ve found the kernel module being used by the hardware you want to debug (Command #1).

You can see what options are supported by the kernel module with the command below.

modinfo -p [module name]

In my case, I wanted to debug my internal atheros wireless card ath9k.

To see what parameters / options are enabled / disabled by the module at the moment you can try:

systool -v -m [module name]


Note that in the section parameters, 1 means enabled and 0 means disabled.

By default most distributions try to have some basic module configs so that your hardware works as expected or so that some other module doesn’t interfere with your hardware by blacklisting them. But it’s not practical to predict what kind of hardware you might have and there’s so many different types of hardware, so it’s better to debug your own hardware and tune the configs to something that is optimal for you.

At the time when I was debugging my wireless card, the powersaving option was disabled (ps_enable=0) and hardware crypt was enabled (nohwcrypt=0) which is why my wireless card was using a lot of power and was slow at the same time.

You can configure them to use the parameters that you want by writing a config file in the /etc/modprobe.d/ directory. What you name the file doesn’t matter, but it needs to have a .conf extension for it to be recognized as a config file.

Usually it’s a good practice to name the file according to the module name, in my case it’s ath9k.conf.

This is the format of how you enter the parameters in the config file:

options [module name] [parameter=value]


You can have multiple parameters side by side separated by space.

After the changes have been written, you can simply remove the module and reload it to have the changes implemented or a reboot works fine too like in windows 🙂

Removing module:
modprobe -r [module name]

Reloading module:
modprobe [module name]

Another thing that was interesting to learn was that let’s say there are some hardware or module that you want to disable or don’t want running.

For example, I find that I never really use the webcam and bluetooth devices on my laptop so disabling them is also a good way to save power and increase battery life.

You can blacklist modules by just having a config file with they key word blacklist followed by the module name. But in some cases, a module may be a dependency to another module and therefore blacklist feature might not work as expected and the module might end up being loaded anyway.

So to prevent that you can write the config file this way:

install [module name] /bin/false

For those wondering the bluetooth module by default is btusb and webcam module being uvcvideo.

Anyway, that’s it for today. I really didn’t wanna make this post since a lot of this info can be found publicly or in Arch Wiki.

But a part of me insisted that I do since a lot of stuff I learned were by trial and error. Usually Arch Wiki tells you what to do but not why, it is up to you to figure out why and that’s the most important part of the learning process in my opinion.

Hopefully this might be helpful to some of you 🙂


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s