Bonjour,

Du nouveau concernant la prise en charge de la carte wifi BCM4322 de broadcom avec le module kmod-wl ou broadcom-wl ?

Je n'arrive toujours pas à la faire marcher. J'ai une connexion ethernet de dispo donc ce n'est pas un problème critique.

Merci.
As-tu essayé de télécharger et installer le driver qu'ils proposent en téléchargement sur leur site?
Oui.
Pour info, j'ai téléchargé le driver sur le site de broadcom.

Ensuite, j'ai suivie les instructions contenues dans le fichiers README mais j'ai un problème au moment de la commande make :
# make
KBUILD_NOPEDANTIC=1 make -C /lib/modules/`uname -r`/build M=`pwd`
make: *** /lib/modules/2.6.40.4-5.fc15.i686.PAE/build : Aucun fichier ou dossier de ce type. Arrêt.
que te donne:
yum provides /lib/modules/2.6.40.4-5.fc15*/build
?
Il manque de toute évidence les headers du noyau courant, en l'occurrence le paquet kernel-PAE-devel.
Au passage, une mise à jour des pilotes a été demandée sur RPM Fusion :
https://bugzilla.rpmfusion.org/show_bug.cgi?id=1907
Je vous invite à suivre ce rapport de bogue et à vous y inscrire, histoire de mettre la pression sur le mainteneur des pilotes...
@Nisaea :
# yum provides /lib/modules/2.6.40.4-5.fc15*/build
Modules complémentaires chargés : langpacks, presto, refresh-packagekit
adobe-linux-i386                                         |  951 B     00:00     
rpmfusion-free-updates                                   | 2.7 kB     00:00     
rpmfusion-nonfree-updates                                | 2.7 kB     00:00     
skype                                                    | 1.2 kB     00:00     
updates/metalink                                         |  23 kB     00:00     
updates                                                  | 4.7 kB     00:00     
updates/primary_db                                       | 3.5 MB     00:02     
updates/filelists_db                                     | 6.2 MB     00:04     
kernel-2.6.40.4-5.fc15.i686 : The Linux kernel
Dépôt         : updates
Correspondance depuis :
Nom de fichier      : /lib/modules/2.6.40.4-5.fc15.i686/build



kernel-PAE-2.6.40.4-5.fc15.i686 : The Linux kernel compiled for PAE capable
                                : machines
Dépôt         : updates
Correspondance depuis :
Nom de fichier      : /lib/modules/2.6.40.4-5.fc15.i686.PAE/build



kernel-2.6.40.4-5.fc15.i686 : The Linux kernel
Dépôt         : installed
Correspondance depuis :
Autre           :Correspondance fournie :
               : /lib/modules/2.6.40.4-5.fc15.i686/build



kernel-PAE-2.6.40.4-5.fc15.i686 : The Linux kernel compiled for PAE capable
                                : machines
Dépôt         : installed
Correspondance depuis :
Autre           :Correspondance fournie :
               : /lib/modules/2.6.40.4-5.fc15.i686.PAE/build

@Pikachu_2014:
Oui, effectivement il me manque ce paquet. Je viens de l'installer. Je me fais toujours avoir à installer les versions non PAE.
Je viens de m'inscrire sur Bugzilla. Comment fait-on pour s'inscrire à ce bug ?
Par ailleurs, après l'installation de "kernel-PAE-devel" je ne parviens toujours pas à compiler :
# make
KBUILD_NOPEDANTIC=1 make -C /lib/modules/`uname -r`/build M=`pwd`
make[1] : on entre dans le répertoire « /usr/src/kernels/2.6.40.4-5.fc15.i686.PAE »
  LD      /opt/hybrid_wl/built-in.o
  CC [M]  /opt/hybrid_wl/src/shared/linux_osl.o
  CC [M]  /opt/hybrid_wl/src/wl/sys/wl_linux.o
/opt/hybrid_wl/src/wl/sys/wl_linux.c: In function ‘wl_attach’:
/opt/hybrid_wl/src/wl/sys/wl_linux.c:485:3: erreur: implicit declaration of function ‘init_MUTEX’ [-Werror=implicit-function-declaration]
cc1: some warnings being treated as errors

make[2]: *** [/opt/hybrid_wl/src/wl/sys/wl_linux.o] Erreur 1
make[1]: *** [_module_/opt/hybrid_wl] Erreur 2
make[1] : on quitte le répertoire « /usr/src/kernels/2.6.40.4-5.fc15.i686.PAE »
make: *** [all] Erreur 2
1) On ne compile pas en root. Jamais. Et encore moins dans /opt, qui n'est certainement pas fait pour ça.
2) Sur le rapport de bogue que j'ai pointé plus haut, tu as un patch pour corriger cette erreur de compilation : https://bugzilla.rpmfusion.org/attachment.cgi?id=694
Je me demande même si au fond tu n'as pas intérêt à reconstruire le paquet proposé dans le rapport de bogue. Ce serait infiniment plus simple. À voir...
Pikachu_2014 wrote:On ne compile pas en root. Jamais. Et encore moins dans /opt, qui n'est certainement pas fait pour ça.
C'est vrai que les pilotes pour ma carte wifi n'ont rien à faire dans /opt.
Mais, ce répertoire est bien destiné à l'installation de programmes perso ?
Lorsque ces programmes ont besoin d'une compilation, on est bien obligé de compiler dans /opt, non ?
Pikachu_2014 wrote:Sur le rapport de bogue que j'ai pointé plus haut, tu as un patch pour corriger cette erreur de compilation : https://bugzilla.rpmfusion.org/attachment.cgi?id=694
Je me demande même si au fond tu n'as pas intérêt à reconstruire le paquet proposé dans le rapport de bogue. Ce serait infiniment plus simple. À voir...
Si tu le dis...
Peux-tu me guider sur la construction du paquet stp ?

Merci d'avance.
Flying Hermes wrote: C'est vrai que les pilotes pour ma carte wifi n'ont rien à faire dans /opt.
Mais, ce répertoire est bien destiné à l'installation de programmes perso ?
Lorsque ces programmes ont besoin d'une compilation, on est bien obligé de compiler dans /opt, non ?
Attention, ne confonds pas répertoire de compilation (là où tu lances effectivement les instructions de build) et répertoire d'installation (là où les fichiers seront finalement installés). /opt n'est certainement pas un répertoire de travail pour la compilation, privilégie ton dossier utilisateur voire /tmp pour ça.
Sur l'utilisation de /opt, tu n'as cependant pas tort : il est en effet dédié aux programmes "perso", dixit le FHS. En pratique, on privilégie néanmoins /usr/local/ ; la plupart des scripts de compilation définissent d'ailleurs cette racine d'installation par défaut, ainsi que tu l'auras peut-être constaté en compilant d'autres programmes.
Pour ce qui est des pilotes cependant, ils sont de toute façon installés dans l'arborescence des modules du noyau, toujours (/lib/modules/version noyau/kernel/).
Pikachu_2014 wrote:Sur le rapport de bogue que j'ai pointé plus haut, tu as un patch pour corriger cette erreur de compilation : https://bugzilla.rpmfusion.org/attachment.cgi?id=694
Je me demande même si au fond tu n'as pas intérêt à reconstruire le paquet proposé dans le rapport de bogue. Ce serait infiniment plus simple. À voir...
Si tu le dis...
C'est pour toi, personnellement ça m'est égal. N'étant pas sûr d'avoir la patience d'expliquer comment appliquer les patches qui devraient résoudre les problèmes de compilation que tu rencontres, je préfère une solution plus rapide de ce point de vue, et propre qui plus est, ce qui ne gâche rien. Accessoirement, avoir un paquet akmod prêt à être installé t'épargnera les affres de la recompilation manuelle des pilotes à chaque mise à jour du noyau.
Peux-tu me guider sur la construction du paquet stp ?
En d'autres circonstances, je t'aurais redirigé sans aucun état d'âme vers notre beau wiki. S'agissant ici d'un cas très particulier non couvert par la documentation --- des modules noyau --- je vais te faire une fleur et te proposer un akmod tout prêt à partir des fichiers postés sur le rapport de bogue RPM Fusion. Mais pas avant ce soir.
Pikachu_2014 wrote:C'est pour toi, personnellement ça m'est égal. N'étant pas sûr d'avoir la patience d'expliquer comment appliquer les patches qui devraient résoudre les problèmes de compilation que tu rencontres, je préfère une solution plus rapide de ce point de vue, et propre qui plus est, ce qui ne gâche rien. Accessoirement, avoir un paquet akmod prêt à être installé t'épargnera les affres de la recompilation manuelle des pilotes à chaque mise à jour du noyau.
Oui, je comprends.
J'avoue ne pas vraiment me rendre compte de la différence de travail à fournir entre l'application de patch ou la recompilation totale du paquet.
Pikachu_2014 wrote:je vais te faire une fleur et te proposer un akmod tout prêt à partir des fichiers postés sur le rapport de bogue RPM Fusion. Mais pas avant ce soir.
Merci
Chose promise, chose due :
http://pikachu.2014.free.fr/public/packages/wl/
Les RPM dans ce répertoire sont à télécharger et à installer ainsi :
yum localinstall --nogpgcheck akmod-wl-5.100.82.38-1.fc15.1.i686.rpm  broadcom-wl-5.100.82.38-1.fc15.noarch.rpm
Ne reste plus qu'à rebooter.
À noter que je n'assurerai pas de support de ces RPM ; s'il y a une mise à jour des pilotes, je ne ferai rien ; si ça ne marche plus après avoir fonctionné, ce ne sera plus mon problème non plus.
Merci, ça marche nickel !!!
Pikachu_2014 wrote:À noter que je n'assurerai pas de support de ces RPM ; s'il y a une mise à jour des pilotes, je ne ferai rien ; si ça ne marche plus après avoir fonctionné, ce ne sera plus mon problème non plus.
Pas de problème.
Pour être certain qu'une MAJ ne viennent pas corrompre nous wifi, je suppose qu'il faut que 'empèche les mise à jour du kernel et des paquets akmod-wl et broadcom-wl.
Y-a-t-il d'autre paquet à ne pas mettre à jour ?
Flying Hermes wrote:Merci, ça marche nickel !!!
Pikachu_2014 wrote:À noter que je n'assurerai pas de support de ces RPM ; s'il y a une mise à jour des pilotes, je ne ferai rien ; si ça ne marche plus après avoir fonctionné, ce ne sera plus mon problème non plus.
Pas de problème.
Pour être certain qu'une MAJ ne viennent pas corrompre nous wifi, je suppose qu'il faut que 'empèche les mise à jour du kernel et des paquets akmod-wl et broadcom-wl.
Y-a-t-il d'autre paquet à ne pas mettre à jour ?
Que dalle. C'est un akmod, recompilé à chaque mise à jour du noyau. Et bloquer les mises à jour du noyau, c'est mal, au passage. Surtout celles de sécurité.
Pikachu_2014 wrote:Et bloquer les mises à jour du noyau, c'est mal, au passage. Surtout celles de sécurité.
Oui, mais si je ne le fais pas, mon wifi sera in-opérationnel à la prochaine mise à jour du noyau. Que me conseilles-tu alors ?
Au passage, pourquoi les RPM que tu m'as compilé ne sont pas dans les dépôts ?
Sais-tu s'ils le seront prochainement ?
Merci.
Je vais recommencer doucement.
Je t'ai fait installer les pilotes, empaquetés sous la forme de paquet akmod : en cas de mise à jour du noyau, les pilotes seront automatiquement recompilés : tu n'as donc aucune raison de bloquer les mises à jour du noyau. Je ne me serais d'ailleurs pas permis de te proposer une solution qui t'imposerait de shunter des mises à jour. Par ailleurs, s'agissant de la dernière version des pilotes, aucune mise à jour ne risque d'écraser ceux-ci... A moins que les pilotes fournis par les dépôts soient enfin mis à jour, auquel cas mes RPM ne seraient plus utiles. En résumé, oublie les exclude et autres bêtises dans /etc/yum.conf, tu n'as rien à bloquer.
Je n'ai fait que reconstruire les RPM sous une forme utilisable, à partir des sources attachées au rapport de bogue demandant la mise à jour des pilotes sur RPM Fusion pour Fedora 15. Comme dit plus haut, je n'assurerai pas de suivi de ces RPM parce que :
- je n'en suis pas l'auteur original ;
- je n'ai pas l'usage de ces pilotes (et si c'était le cas, je me serais proposé sur RPM Fusion).
Autrement dit, si Broadcom devait mettre à jour ses pilotes, n'attends pas de moi que je te fournisse de nouveau des RPM à jour. De même, si à la suite d'une mise à jour du noyau l'akmod ne compilait plus (à cause de changements d'API dans le noyau, ce qui ne devrait pas arriver avant plusieurs mises à jour de ce dernier si ça peut te rassurer), inutile de me solliciter. Il ne tient qu'à toi (et à d'autres) de faire du forcing, en te manifestant sur le rapport de bogue susmentionné, pour que les paquets wl sur RPM Fusion soient enfin mis à jour et trouvent un mainteneur plus actif. C'est le problème des pilotes wl dans les dépôts : leur mainteneur ne répond pas, pour répondre à ta dernière question.