Need advice: kmod-wl and akmod-wl with kernel >= 3.6.0

Nicolas Viéville nicolas.vieville at univ-valenciennes.fr
Fri Nov 9 20:11:47 CET 2012


Hello Nicolas,

> 2012/11/7 Nicolas Viéville <nicolas.vieville at 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=commitdiff;h=10bab00afed042c1a38ed5ffb135e2aea5ce1277).
> >
> > 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


More information about the rpmfusion-developers mailing list