net-wireless/iwl5000-ucode-8.83.5.1 changes API/ABI and is not compatible with 2.6.37 kernel. If someone have not updated kernel for any reason the update makes system not connecting to WiFi (thus making the downgrade painful). I cannot find changes since previous version so I am not sure if it should be keyworded, masked etc. but probably there should be some safeguards as even ~arch does not necessary have newest kernels. Reproducible: Always
Thilo, please take maintainership of this package. I am now on IWL6000 hardware.
I'm wondering whether this package should be slotted in this case to let people run different kernel versions.
2.6.32.40 adds support for =net-wireless/iwl5000-ucode-8.83.5.1. I suspect other "stable" series kernels released around this time do the same. This bug relates a bit to bug #363807. =net-wireless/iwl5000-ucode-8.83.5.1 should have incremented SLOT, the two can be safely installed in parallel. iwlagn in any given kernel will attempt to load latest it supports first and traverse downward (by API version) until a supported firmware is found.
I learned this awhile ago, forgot to note it here. So it ends up 2.6.32.x is still not usable with latest ucode. That makes it a bad example for the all remaining recommendations about parallel installability, but they still remain valid going forward and for current kernels. Sorry for the minor hijack, but this also serves purpose to explain the situation/correction of my previous comments. CC'ing gregkh here as 2.6.32.x longterm-series kernel maintainer (will ping him via other means if he does not acknowledge receipt of this comment soonish). This patch[1] alone is not sufficient to support API v5 firmware. Looked into it a bit and the firmware format changed entirely between 2 and 5. The API version is even stored in a different place and the new firmware is entirely zero'd where the API version information was previously kept. This triggers newer kernels to use an alternate loader method (that knows the new firmware format), but the 2.6.32.x does not have these additional patches/routines backported. It simply reads it as API v0 firmware and fails to load. So when both firmwares are installed, this can break previously working setups because iwlwifi-5000-5 named ucode takes precedence over iwl5000-2 when loading. Here's someone else who's noticed: https://bugs.archlinux.org/task/24302 I'm clearly not the longterm maintainer, so I defer entirely to you Greg, but fwiw it looked fairly hairy to bring the alternate loader back into 2.6.32.x -- so its a revert-the-patch-situation I suspect. [1] http://git.kernel.org/?p=linux/kernel/git/longterm/linux-2.6.32.y.git;a=commitdiff;h=41504cce240f791f1e16561db95728c5537fbad9
Quick update: Kernel 2.6.32.42 fixes the aforementioned problems with attempting to load greater than API v2 firmwares. It is once again safe/possible to install multiple firmware versions in parallel on the 2.6.32.x kernel series (it just won't use what it doesn't recognize).
*** Bug 363807 has been marked as a duplicate of this bug. ***
+*iwl5000-ucode-8.83.5.1-r1 (15 Dec 2012) + + 15 Dec 2012; Pacho Ramos <pacho@gentoo.org> +iwl5000-ucode-8.83.5.1-r1.ebuild, + -iwl5000-ucode-5.4.0.11.ebuild, -iwl5000-ucode-8.83.5.1.ebuild: + Version bump using updated tarball (#383541 by Toralf Förster), using its own + SLOT as it's for kernels >= 2.6.38 (#359445 by Maciej Piechotka). Drop old + versions, including old slot for kernels < 2.6.30. +
