Contents
- Stable compat-wireless releases
- Case for support
- Legend
-
compat-wireless stable releases
- compat-wireless 3.5 stable releases
- compat-wireless 3.4 stable releases
- compat-wireless 3.3 stable releases
- compat-wireless 3.2 stable releases
- compat-wireless 3.1 stable releases
- compat-wireless 3.0 stable releases
- compat-wireless 2.6.39 stable releases
- compat-wireless 2.6.38 stable releases
- compat-wireless 2.6.37 stable releases
- compat-wireless 2.6.36 stable releases
- Older stable releases
- Recommended
- Prerequisites
- Unpacking source
- Building and installing
- Unloading
- Loading
- Linux distributions packaging compat-wireless
- Bugs
- Patches
- Maintaining of releases
- Additional patches to stable releases
Stable compat-wireless releases
This page is dedicated to the stable kernel compat-wireless releases. These releases are based on stable kernel versions. Our goal is to support stable releases on kernels at least as old as the oldest supported kernel listed on kernel.org, today that is 2.6.27 but we have done work to support even older kernels and each driver may also have additional work to support even older kernelsl
As of today every stable version should be compatible with every kernel >= 2.6.26, like the bleeding edge releases. This started with the announcement of work for 2.6.30-rc series and will continue for all stable kernels releases. These stable releases are intended for users looking for more stability than what bleeding edge daily compat-wireless releases provide.
Case for support
Wireless vendors are encouraged to use these releases for support purposes as no extra tree needs to be created and supported. Stable fixes must always be sent upstream as well. This ensures wireless vendors are testing with stable kernels and helping stabilize the kernels further.
Legend
Extra flag meanings:
- -s - get and apply pending-stable/ from linux-next.git
- -n - apply the patches linux-next-cherry-picks directory
- -p - apply the patches on the linux-next-pending directory
- -c - apply the patches on the crap directory
Release with no extra flags are simply vanilla releases of the kernel. Users are encouraged to use the -spn releases as these releases will have extra fixes not yet propagated. The -s flag for example indicates that the release has patches marked as stable which will be released by the next 2.6.x.y release of the kernel so you might as well get them now. Linux distributions are encouraged to use the extra flagged releases as well. We provide the vanilla releases for those Linux distributions which just want vanilla for whatever reason.
For more on this please see below.
compat-wireless stable releases
Here are the list of stable releases of compat-wireless.
NOTE: Please be aware that the releases below contain code from the given version of the Linux kernel. Therefore to add functionality, you should select a version that is later than your kernel version.
compat-wireless 3.5 stable releases
Kernel release |
sha1sum |
size |
ChangeLog-wireless |
ckmake.log.bz2 |
d5908382831a2fdb79a5078fcc2ffaf49e914a1b |
4.3 MB |
|||
77481b202cc0e3cceab72b7ba55b597f0da291f8 |
4.3 MB |
|||
c78eb6948d82f57fb2dbcfcdce33e212bbe01b7d |
4.3 MB |
compat-wireless 3.4 stable releases
Kernel release |
sha1sum |
size |
ChangeLog-wireless |
ckmake.log.bz2 |
0e2137bccce41cfb485e2554400d344413283f11 |
4.1 MB |
compat-wireless 3.3 stable releases
Kernel release |
sha1sum |
size |
ChangeLog-wireless |
e100832be6d157043cb927ba184380dbddb40387 |
4.0 MB |
||
dd18cfabbe705a75440fd7fbe50a09d5fe34bb70 |
4.0 MB |
compat-wireless 3.2 stable releases
Kernel release |
sha1sum |
size |
ChangeLog-wireless |
e7bcdc038b9f85e74308b175b41560b6d5a31c50 |
4.0 MB |
compat-wireless 3.1 stable releases
Kernel release |
sha1sum |
size |
ChangeLog-wireless |
d0bb37b9643e21873a0edbe3f8a99f48a826c6e8 |
4.1 MB |
compat-wireless 3.0 stable releases
Kernel release |
sha1sum |
size |
ChangeLog-wireless |
388d2a76d70b0671d65383e121e0078c3aa9cc69 |
4.1 MB |
compat-wireless 2.6.39 stable releases
Kernel release |
sha1sum |
size |
ChangeLog-wireless |
0a97215617be62cebe8cacd2228bc624716c9434 |
4.2 MB |
||
0c0a9d02a23153e31e3db84a84c1eb62a7615982 |
4.2 MB |
compat-wireless 2.6.38 stable releases
Kernel release |
sha1sum |
size |
ChangeLog-wireless |
07d1c99c5f9db3413c8ae8a58b8e9d57db78c576 |
3.9 MB |
||
c0470b3cbb3d9b31a1d9a98ea82f4fe344c8ea59 |
3.9 MB |
compat-wireless 2.6.37 stable releases
Kernel release |
sha1sum |
size |
ChangeLog-wireless |
e1b6432ce9e6738e320334b26e4adb68d3dd2a80 |
3.8 MB |
||
54b8d777287fdcc7a716d71cfb21884f1ae07157 |
3.8 MB |
compat-wireless 2.6.36 stable releases
Kernel release |
sha1sum |
size |
ChangeLog-wireless |
7b6e4e8314008cef7c6b132fd6925f1c2660f8d2 |
2.6 MB |
||
e2391cc37d762dab146c2e067534f3f20eb4469f |
2.6 MB |
Older stable releases
Kernel release |
sha1sum |
size |
ChangeLog-wireless |
4e33700b4200eca9c562b18b8f97992ab5edb544 |
1.9 MB |
||
95d3227cb79ac8a706994d6a5a6bff4e1c2c1a5d |
2.2 MB |
||
8692e5c21d907cebc31f8061171a7174dd89d99f |
2.3 MB |
||
95a44314284e68ea8902b42bd7a41e0b613efe64 |
2.5 MB |
Recommended
We recommend these the following userspace applications to be installed:
Prerequisites
You need kernel headers to compile compat-wireless. Ensure /lib/modules/$(uname -r)/build/ exists and points to the location where the kernel headers are installed. If you do not have them, read your distribution's documentation on getting help.
Unpacking source
After downloading, unpack the source by typing (as example: version 2.6.32-rc5):
tar -xf /path/to/compat-wireless-2.6.32-rc5.tar.bz2
Note: Modern tar selects decompressor automatically (otherwise add "–bzip2" or "-j").
Also, please unpack it to a path that does not contain space. The kernel build system is unable to handle spaces in the module tree's directory and will fail if there is any.
Building and installing
cd /path/to/compat-wireless-2.6.32-rc5 ./scripts/driver-select <driver-name> make sudo make install
Unloading
After build and installation unload modules and drivers:
sudo make unload
Loading
To load the new shiny drivers either reboot or just modprobe the module you want. To test whether or not the new drivers are being picked up you can use modprobe -l on the modules, you should see the wireless modules being picked up using the updates/ directory instead of the kernel/ directory. For example (ath9k driver):
$ modules="cfg80211 mac80211 ath9k" $ for i in $modules; do sudo modprobe -l $i; done /lib/modules/2.6.27-11-generic/updates/net/wireless/cfg80211.ko /lib/modules/2.6.27-11-generic/updates/net/mac80211/mac80211.ko /lib/modules/2.6.27-11-generic/updates/drivers/net/wireless/ath9k/ath9k.ko
Note that the make install command will output this for you so you can just look at that.
Note #2: If you got no network connection automatically, try to restart your network. For Debian systems do:
sudo /etc/init.d/networking restart
Linux distributions packaging compat-wireless
Please refer to the Linux distributions section for more details.
Bugs
If you find a bug, please ensure you are on the latest kernel for that series. Bugs should be reported upstream on the http://bugzilla.kernel.org/. You may also want to address this on the linux-wireless mailing list first. For more details please see our reporting bugs guidelines.
Patches
If you have a patch for an bug please also ensure you are using the latest release for the respective kernel. If unsure you can ask on the linux-wireless mailing list. If you are sure its a fix you can send the patches to:
To: stable@kernel.org Cc: linux-wireless@vger.kernel.org
Maintaining of releases
Refer to the maintenance section for details on how the stable releases are made and how to checkout the compat-wireless code for those releases. You can also refer to the Generating stable releases section.
Additional patches to stable releases
compat-wireless prioritizes pushing software to be upstreamed into respective Linux subsystem development trees. The stable compat-wireless releases are based on vanilla stable kernels and extra version stable releases as published through the linux-stable.git tree. Stable fixes are propagated through the stable kernel fix propagation mechanism. At times however the stable kernel fix propagation mechanism may not allow OEMs/OSVs/users to get the latest stable patches in time for their own needs. Other times, some patches which are not necessarily "stable" fixes may be desired to be integrated into a stable release by a hardware manufacturer, for one reason or another. At times, a subsystem maintainer may be on vacation and stable fix patches may take a while to get to users. In the worst case scenario some patches may not have been submitted for public review yet, for whatever reason, but it may be desired to merge some temporary patches on a stable release. Because of all these reasons compat-wireless has extended the stable kernel fix propagation mechanism by enabling additional types of patches to be merged into a stable release. Upstream first is still prioritized by categorizing these patches.
There are four categories to compat-wireless' extra patches:
- pending-stable
- linux-next-cherry-picks
- linux-next-pending
- crap
We document these below.
If you want to annotate that a patch should be considered for inclusion into the stable releases of compat-wireless under linux-next-cherry-picks/ you can annotate it by adding a tag on the commit log line, Cc: compat@orbit-lab.org. An example follows. By annotating these patch a script can be used to scrape linux-next for extracting these patches when building a stable release.
commit 061acaae76dfb760f4f3fddf0cde43915b7d673c Author: Luis R. Rodriguez <rodrigue@qca.qualcomm.com> Date: Wed Dec 7 21:50:07 2011 +0530 cfg80211: allow following country IE power for custom regdom cards By definition WIPHY_FLAG_STRICT_REGULATORY was intended to allow the wiphy to adjust itself to the country IE power information if the card had no regulatory data but we had no way to tell cfg80211 that if the card also had its own custom regulatory domain (these are typically custom world regulatory domains) that we want to follow the country IE's noted values for power for each channel. We add support for this and document it. This is not a critical fix but a performance optimization for cards with custom regulatory domains that associate to an AP with sends out country IEs with a higher EIRP than the one on the custom regulatory domain. In practice the only driver affected right now are the Atheros drivers as they are the only drivers using both WIPHY_FLAG_STRICT_REGULATORY and WIPHY_FLAG_CUSTOM_REGULATORY -- used on cards that have an Atheros world regulatory domain. Cards that have been programmed to follow a country specifically will not follow the country IE power. So although not a stable fix distributions should consider cherry picking this. Cc: compat@orbit-lab.org Cc: Paul Stewart <pstew@google.com> Cc: Rajkumar Manoharan <rmanohar@qca.qualcomm.com> Cc: Senthilkumar Balasubramanian <senthilb@qca.qualcomm.com> Reported-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com> Signed-off-by: Luis R. Rodriguez <mcgrof@qca.qualcomm.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
pending-stable patches
These are patches merged into linux-next.git but that have not yet been merged into the linux-stable.git tree.
From the pending-stable/README:
Often right before the merge window we get a block on non oops/regression fixes for stable fixes. Some stable fixes often get propagated afterwards during the extraversion maintenance of the kernels. Right before the merge window circa rc4 and rc5 subsystem maintainers get pegged if they throw in non oops/regression fixes for Linus or their respective upstream maintainer. While this makes sense for tree management and stable release considerations we still need to get users some stable patches propagated. This directory is there to help with that. Only patches which have been merged into linux-next.git will be included in this directory which means you must post it and the maintainer should have merged it and Stephen would have picked it up. This directory will always be empty for bleeding edge releases as bleeding edge releases are always based on linux-next already. This directory only makes sense for stable release of the kernel, and it we will always try to use it, in case there are stable fixes not yet propagated.
linux-next-cherry-picks patches
From the linux-next-cherry-picks/README:
We work hard to get patches in time onto the stable tree but sometimes a few things slip out, and sometimes a stable fix is simply too big in size to be merged into stable. In such cases though we do believe some of these patches are still relatively important to either enable new hardware which escaped the late rc cycles or to correct some behaviour which might be too late for stable. We apply these patches by default as they will be supported on these releases. The larger the number of patches you see in this directory the more we should be ashamed. We should strive to reduce this to 0 all the time. This directory will always be empty for bleeding edge releases as bleeding edge releases are always based on linux-next already.
linux-next-pending patches
From the linux-next-pending/README:
You must have a really good reason to be adding files in this directory. The requirement is your patches must have been posted to a public mailing list for the subsystem you are working on. Each patch you add here must have a really good explanation on the top of the file which clarifies why the patch has not yet been merged OR specify it on the commit log when you add it on compat-wireless. We try to avoid having patch files because but we understand if you might because you need to test code posted but not yet merged into linux-next or a stable kernel release. This can happen often during the merge window, when the maintainers are unavailable, on vacation, suck at what they do, or for any other uncontrollable reasons.
crap patches
From the crap/README:
If you are including patches into this directory you must be fixing some critical bug for a customer which needs immediate release or immediate testing. Alternatively you would use this to apply some sort of crap code you are maintaining. You must have a really good reason to be adding files in this directory. If possible you should explain your reasoning of why the patch is getting included here and not upstream and why it hasn't even yet been posted. You should avoid these patches at all costs.