Recently, I have had to reinstall my OS (Ubuntu) several times due to a mix of filesystem and HDD corruption issues. This, invariably, has led me to a situation where Asus K450J’s wireless networking doesn’t work. My go to solution, so far, has been to look into an answer  in StackOverflow and fix the issue with the solution proposed. I have never given too much thought why this happens, or why the solutions resolves it, but it is intriguing that there are no explanations on the answer. The answer has no votes, wasn’t accepted and had no comments on it, which sparked my interest even further. Why does this work?!
The solution, presented in the answer, is the following block of code:
sudo tee /etc/modprobe.d/blacklist-acer.conf <<< "blacklist acer_wmi"
Run this on the terminal, reboot laptop and we are done.
Starting with the easier part of it, there are 2 clear commands on this answer:
sudo’s man page , we conclude the following:
sudo allows a permitted user to execute a command as the superuser or another user, as specified by the security policy.
Since the command doesn’t refer any other user, we can safely assumed that we are running the command as the superuser. This makes sense since, at least on Ubuntu’s fresh installation,
/etc is a directory not writable by any and every user.
tee is just a simple program that allows standard input (
STDIN) to be redirected to standard output (
STDOUT) and, at the same time, to send that output to some files. This can be easily confirmed in
tee’s man page . So far it has been fairly easy and straightforward.
The argument that is passed to
tee is for the file
/etc/modprobe.d/blacklist-acer.conf. What is this file and why might we care writing to it? A quick read over The Linux Documentation Project’s pages  makes me conclude that
/etc is mostly a directory where files, that several programs use, are stored. So…what program uses the
/etc/modprobe.d/ directory? As it might seem obvious by now, specially after reading TLDP’s pages, the program that uses this directory is
modprobe , which can be used “to add or remove modules from the Linux Kernel” . By reading  again, I figure out that writing
blacklist acer_wmi tells
modprobe to ignore this module. Tthe reasons for that are also described, in the documentation (emphasis mine):
Modules can contain their own aliases: usually these are aliases describing the devices they support, such as “pci:123…“. These “internal” aliases can be overridden by normal “alias” keywords, but there are cases where two or more modules both support the same devices, or a module invalidly claims to support a device: the blacklist keyword indicates that all of that particular module’s internal aliases are to be ignored
At this point I start to become suspicious that
acer_wmi is a Linux Kernel module that messes up Asus’ wireless configuration on a Ubuntu’s fresh installation, by claiming to support a device that it really doesn’t support. Another user, using a Lenovo Thinkpad E420 claims similar issues on Ubuntu 11.10 , on the grounds that:
The only glitch is the wifi drivers which don’t run by default, and it could be corrected easily
Another article also seems to point towards issues with
A certain kernel module, called acer_wmi, causes problems on some laptops. Because it has been loaded when it shouldn’t have been.
I have found other occurrences of this problem, in different laptops both from Lenovo and Asus. Which leads me to question: why is
acer_wmi loaded by default?
By reading the
acer-wmi.txt , which is a sort of
README of the
acer-wmi.c Linux kernel module , it says: “On Acer laptops, acer-wmi should already be autoloaded based on DMI matching.” Now, using this line of thinking, we have to look up what “DMI matching” actually stands for. Searching the Linux mailing list, we find a 2007 patch  that enabled “DMI-based module autoloading” with the following explanation:
The patch below adds DMI/SMBIOS based module autoloading to the Linux kernel. The idea is to load laptop drivers automatically (and other drivers which cannot be autoloaded otherwise), based on the DMI system identification information of the BIOS.
Interesting. Let’s look up what the DMI for my Asus laptop looks like (BIOS-wise):
BIOS Information Vendor: American Megatrends Inc. Version: 216 (...) System Information Manufacturer: ASUSTeK COMPUTER INC. Product Name: X450JF Version: 1.0 (...) BIOS Revision: 4.6 (...)
I redacted a lot of information to keep this simple. So, clearly my manufacturer is Asus and my model is X450JF…why would the kernel load up an Acer module?
Listing loaded modules, and searching for Asus drivers, using
lsmod | grep asus returns:
asus_nb_wmi 28672 0 asus_wmi 28672 1 asus_nb_wmi sparse_keymap 16384 1 asus_wmi asus_wireless 16384 0 wmi 24576 4 asus_wmi,wmi_bmof,mxm_wmi,nouveau video 40960 3 asus_wmi,nouveau,i915
So…Asus drivers are currently being loaded, which means they can be loaded, but why were the Acer ones selected to begin with? I have no idea.
For now, that’s okay. I have understood the high-level reason why it wasn’t working in the first place. I don’t really know why the kernel loads up the wrong module but, by looking at both modules’ code, they have very different approaches to verifying what type of machine it’s dealing with.
What started out as an investigation into a simple command-line expression, ended up being a fun investigation into the surface of kernel module loading. I didn’t find exactly the reason why it loads the incorrect module but, from searching, I see that this is an issue which has an open (although expired) bug in the Linux bug tracker.