8:04 p.m.
Hello community,
I currently have to face some bug reports against the Broadcom kmod-wl
package for kernel >= 3.6.0 in F-16 and F-17, since I switched that
module to the new kernel wireless API CFG80211. The old one, aka WEXT,
will be dropped in future kernels
(https://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commi...).
The problem is that some platforms work out of the box with the current
packages, and some others need some tweaks.
The two tweaks are:
- include lib80211 lib80211_crypt_tkip wl modules in kernel initramfs in
order to avoid a kernel panic at boot time.
- revert to WEXT API.
The first one seems to be relatively direct to handle. Add
a /etc/dracut.conf.d/20-wl.conf file with correct directive in it
(add_drivers+="lib80211 lib80211_crypt_tkip wl") in the package, and
appropriate %post and %postun section containing dracut command in the
package spec file.
Any tips on this part of the packaging are welcome.
The second one is not so trivial to handle as to be complete on this
subject same Broadcom devices (lspci reports) on different laptops give
different results. So I imagined that it would be left to the user to
choose the correct module API to install. But as the choice between the
two API is made at build time, the only way to achieve this goal for the
user is to install only the akmod-wl package (no kmod-wl package),
modify a configuration file manually, relaunch akmods command to get the
correct API for that module. The Makefile included in the sources will
be modified to include the configuration file at build time and to
adjust build settings correctly.
My question:
Do you think this method to resolve the issue is the good one?
How long the WEXT API will be available?
Any comments on this are welcome.
One caveat of these two methods is that dracut configuration file and
akmod API configuration file would be provided with standard kmod-wl
packages.
I provide as attachments the fedora.readme file and the dracut
configuration file I intend to add to the package if I opt for these
solutions. Thanks for reviewing them since my natural language is not
English.
What are the other precautions that I could have missed?
Thanks in advance for your responses.
Cordially,
--
Nicolas Viéville
10:16 p.m.
2012/11/7 Nicolas Viéville <nicolas.vieville(a)univ-valenciennes.fr>:
Hello community,
I currently have to face some bug reports against the Broadcom kmod-wl
package for kernel >= 3.6.0 in F-16 and F-17, since I switched that
module to the new kernel wireless API CFG80211. The old one, aka WEXT,
will be dropped in future kernels
(https://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commi...).
The problem is that some platforms work out of the box with the current
packages, and some others need some tweaks.
The two tweaks are:
- include lib80211 lib80211_crypt_tkip wl modules in kernel initramfs in
order to avoid a kernel panic at boot time.
modinfo -F depends wl shows
lib80211 but not lib80211_crypt_tkip is is possible to avoid the crash
by explicitely listing the lib80211_crypt_tkip module in depends
instead ?
I tried to avoid the need of recreating the initramfs for the nvidia
case. That's a very critical operation.
If you cannot workaround the issue, the best would be to run the
dracut command in %posttrans of the broadcom-wl so it avoids a run
condition with the kmod-wl. (like what is done with plymouth).
Now maybe your issue is related to the blacklisting of the b44 and
others drivers, in which case better would be to use
/usr/lib/modprobe.d or rd.driver.blacklist when it get fixed.
See https://bugzilla.redhat.com/873220
Nicolas (kwizart)
7:11 p.m.
Hello Nicolas,
2012/11/7 Nicolas Viéville
<nicolas.vieville(a)univ-valenciennes.fr>:
> Hello community,
>
> I currently have to face some bug reports against the Broadcom kmod-wl
> package for kernel >= 3.6.0 in F-16 and F-17, since I switched that
> module to the new kernel wireless API CFG80211. The old one, aka WEXT,
> will be dropped in future kernels
>
(https://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commi...).
>
> The problem is that some platforms work out of the box with the current
> packages, and some others need some tweaks.
>
> The two tweaks are:
> - include lib80211 lib80211_crypt_tkip wl modules in kernel initramfs in
> order to avoid a kernel panic at boot time.
modinfo -F depends wl shows
lib80211 but not lib80211_crypt_tkip is is possible to avoid the crash
by explicitely listing the lib80211_crypt_tkip module in depends
instead ?
First, thank you for all your comments on these questions.
The lib80211_crypt_tkip module is loaded on the fly via the
request_module preprocessor macro. So I guess it is the reason why it
doesn't show-up with modinfo. But In the sources of this driver, I
didn't found any MODULE_DEPEND directive for the others modules cited
(lib80211 and cfg80211). Maybe the binary file shipped by Broadcom in
the sources tree include it?
I tried to avoid the need of recreating the initramfs for the nvidia
case. That's a very critical operation.
If you cannot workaround the issue, the best would be to run the
dracut command in %posttrans of the broadcom-wl so it avoids a run
condition with the kmod-wl. (like what is done with plymouth).
Thanks for pointing the plymouth example. This helped me to understand
how to achieve such a thing.
After a moment thinking about it, I tend to prefer providing all the
necessary files to help the user to get the correct initramfs, if
needed. Modifying by hand the /etc/dracut.conf.d/20-wl.conf file
provided in the package must be done before the first new initramfs
built. So the first time, users have to do it themselves. Once this file
has been modified, new kernels installations will upgrade their
corresponding initramfs correctly.
Do you think this would be sufficient as a workaround for this problem?
Now maybe your issue is related to the blacklisting of the b44 and
others drivers, in which case better would be to use
/usr/lib/modprobe.d or rd.driver.blacklist when it get fixed.
See https://bugzilla.redhat.com/873220
Thanks for the link. I didn't noticed in the bug reports, and the files
provided by the users some direct problems with blacklisting other
modules. Maybe I missed them. I'll check that again.
To conclude on this, I preferred to let the user make explicitly the
choice of using WEXT API instead of default CFG80211 one, by modifying
by hand a configuration file and using akmod-wl package only.
As the two workarounds proposed here seems to be needed by a few users
(for the moment), and others seem to use the kmod-wl packages without
such problems, I think that this solution is not so bad, for the moment.
Maybe I should add a Web page on the RPMFusion Web site, in the HowTo
section, to explain how and when to use these files.
Before, I'll wait for feedback from users who reported bugs and who are
willing to test new packages (when kernel 3.6.6 will be pushed and mock
will agreed to build these packages on my laptop).
Thank you very much for your response.
Cordially,
--
Nicolas Viéville
4192
days inactive
4194
days old
rpmfusion-developers@lists.rpmfusion.org
2 comments
2 participants
participants (2)
-
Nicolas Chauvet -
Nicolas Viéville