R500 Wifi and ACPI

The wireless card is an Intel 4965AGN and needs drivers from http://intellinuxwireless.org

Applying this patch to 2.6.22 from kernel.org works, but causes suspend to no longer work. Turns out Ubuntu provided the patch from http://memebeam.org in their kernel.

Initially, though, I discounted this patch because the version number did not match the one in the Ubuntu code. Attempting to build the Ubuntu kernel with the Intel wireless patch proved to be quite a challenge, which is chronicled below for the amusement of others.

In the end, I have decided to use my own build of the 2.6.22 kernel with patches for ACPI and Wifi. I just can't trust the Ubuntu kernel source after my experiences with it.

Patching Ubuntu

First, get the kernel source, unpack it, and make sure it compiles:

apt-get install linux-source-2.6.20 cd /usr/src tar -jxf linux-source-2.6.20.tar.bz2 cd linux-source-2.6.20 make menuconfig make-kpkg --initrd --append-to-version=-mkfs kernel_image

The first thing you will notice (assuming you modified the kernel config) is that Ubuntu does not ship working kernel source. I ran into the following two bugs:

https://lists.ubuntu.com/archives/ubuntu-bugs/2007-March/456610.html
https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/86725

Note that Ubuntu has fixed neither of them, trivial as they are, and gives the following excuses:

We don't use this because it is marked experimental. We do not guarantee that our source compiles for users with alternate configurations from what we use to build our own kernels.

It fails because you enabled an option that is broken. We don't guarantee alternate builds of our source. (Note: the config option is not marked as broken or experimental, and is in fact in the Ubuntu Additional Drivers section.)

This is without a doubt the most mind-numbingly inane response to a bug that I have ever heard. Why ship the kernel source at all if changing a single option in the config file (to optimize for a specific process, for example) can cause the build to fail? Talk about following the letter of the law, not the spirit!

In any event, fixing those bugs as documented (one by adding a #define in C, the other my simply not using the driver) lets the kernel compile successfully. Now to for the wireless driver.

ln -s /usr/src/linux-source-2.6.20 /lib/modules/`uname -r`/source cd /usr/src/mac80211-10.0.0 make SHELL=/bin/bash patch_kernel

That went well, let's rebuild kernel...

net/built-in.o: In function `__crc_iw_handler_get_thrspy': (*ABS*+0x8f9b701d): multiple definition of `__crc_iw_handler_get_thrspy' net/built-in.o: In function `iw_handler_set_spy': (.text+0x6d810): multiple definition of `iw_handler_set_spy' ubuntu/built-in.o:(.text+0x1090): first defined here net/built-in.o: In function `__crc_wireless_send_event': (*ABS*+0xeb8cff4e): multiple definition of `__crc_wireless_send_event' net/built-in.o: In function `iw_handler_get_thrspy': ...

Oh, bitter defeat!
It looks like Ubuntu's added in MAC80211 code is conflicting with the Intel MAC80211 patch. Disabling either in the config has no effect.

Let's trust the Ubuntu MAC80211 to be the same and hope everything just works. Using an unpatched version of the kernel, apply the IWL-Wifi patch

cd iwlwifi-1.1.0 make SHELL=/bin/bash patch_kernel

Turns out this doesn't work, because the Ubuntu MAC80211 code is not where the IWL-Wifi patch expects it to be. After a bit of poking around in the IWL-Wifi scripts and Makefile, it looks like the following changes will work:

1. In the Makefile, change the line 'export KSRC ?= /lib/modules/$(shell uname -r)/source' to 'export KSRC ?= /lib/modules/$(shell uname -r)/source/ubuntu'
2. ln -s /lib/modules/2.6.20-16-generic/source/drivers /lib/modules/2.6.20-16-generic/source/ubuntu/

The first change causes the patch to look in the ubuntu directory for the MAC80211 code, the second causes the driver code to be installed in the correct location.

This builds successfully. Suspend-to-RAM and Wifi now work correctly. No good news on the suspend-to-disk front, which is unusual as that should be the easiest suspend option to make work (it's just a file on the swap partition fer chrissake!).

Update: The main problem with suspend-to-disk is reported here : https://bugs.launchpad.net/ubuntu/+source/udev/+bug/105490
Unfortunately, even after fixing the swap partition in /etc/fstab, the system locks up on resume unless using 'Recovery Mode'.