Bonjour à Tous,

Juste quelques mots pour vous faire part de ma dernière mésaventure...
Et pour aider ceux qui rencontreraient le même problème.

La mise à jour vers le noyau 2.6.24.3-12 a provoqué une petite catastrophe sur ma bécane :
plus de connexion internet ! 🙁

Le coupable a vite été identifié : la carte wifi, de type RaLink RT2561/RT61 rev B802.11g
Dès que je tentais d'activer la connexion wifi, la machine se gelait.

Cette (...) de connexion wifi est décidément bien le seul point qui me fasse vraiment suer
depuis mon passage à linux...

Le retour en arrière a été un peu compliqué...
Relancer la version précédente du noyau, ça va, c'est facile (grub est là pour ça !)

Seul hic : même en revenant à la version précédente du noyau, je n'ai pas retrouvé
ma connexion internet !

Pour la récupérer, j'ai dû supprimer les entrées relatives à ma carte wifi dans la configuration
Réseau (MenuK -> Système -> Réseau) et les re-créer.

Cordialement,
Stefan
Bonjour,

Sans avoir à recréer les fichier dans /etc/sysconfig/network-scripts, j'ai subi aussi le gel du système avec le noyau 2.6.24.3-12.
J'ai quand même remarqué que le pilote rt61pci était passé en version 2.1.0.
Hormis le freeze, je ne sais pas encore ce que cette nouvelle version du pilote apporte de neuf.
Le bug et connu avec le noyau 2.6.24 :il est en cours de correction avec le 2.6.25.
Seule solution : attendre ...
Merci beaucoup pour cette réponse qui me rassure. 😉

Si je peux profiter de l'occasion pour poser une question (stupide ?)
qui me démange...

Par défaut, fedora conserve les deux dernières versions du noyau
dans boot... Ce nombre de versions conservées est-il configurable ?
Par quel fichier ?

Des fois que, par excès de prudence, je souhaiterai l'augmenter un petit rien 😉

Cordialement,
Stefan
tapioca wrote:Le bug et connu avec le noyau 2.6.24 :il est en cours de correction avec le 2.6.25.
Seule solution : attendre ...
Le noyau 2.6.24 semble maintenant pleinement intégrer le driver rt2x00 (http://rt2x00.serialmonkey.com/wiki/index.php?title=Main_Page).

Mon cas:

* USB Wifi HERCULES chipset Ralink (voir http://ralink.rapla.net/ )
* sortie de lsusb: Bus 001 Device 004: ID 06f8:e010 Guillemot Corp. HWGUSB2-54-LB

Par défaut, le système charge le module rt73usb qui appelle les ressources rt2x00. Avec les noyaux 2.6.23, pas de difficulté. Avec le nouveau noyau, le chargement du module conduit à des erreurs qui gèlent le système. Le message (en boucle) est: 
phy0 -> rt2x00usb_write_tx_data: Error - Arrived at non-free entry in the non-full queue 2
Le point est connu (voir le forum serialmonkey et particulièrement ce fil).

Pour faire fonctionner la connexion WiFi en environnement 2.6.24, un contournement possible est présenté ci-après (pour experts). Le principe consiste à compiler et installer un driver "legacy". La description qui suit prend l'exemple du module rt73.

1- Les préparations:

Sous un noyau de version inférieure, disposant de la connexion, télécharger le driver "legacy" (c'est à dire antérieur à rt2x00, qui vise à réécrire les drivers en les unifiant) depuis la page suivante: http://rt2x00.serialmonkey.com/wiki/index.php/Downloads

Dans mon cas, il s'agit du rt73.

Bien évidemment, installer l'environnement de développement du 2.6.24:
kernel-devel.x86_64                      2.6.24.3-12.fc8   
kernel-headers.x86_64                    2.6.24.3-12.fc8
Toujours en environnement 'noyau antérieur', interdire le chargement ultérieure de rt73usb et rt2x00:
 à la fin de /etc/modprobe.d/blacklist, ajouter:
blacklist rt73usb
blacklist rt2570
blacklist rt2x00lib
Arrêter les services NetworkManager (ils ne seront pas compatibles avec le rt73). Activer le service Network.

2- La compilation et l'installation du module:

Lancer le noyau 2.6.24. Normalement, le module rt73usb n'est pas chargé. Sinon, le décharger par:
# rmmod rt73usb
Compiler et installer le module:
# gunzip rt73-cvs-daily.tar.gz
# tar xvf rt73-cvs-daily.tar
# cd rt73-cvs-2008030723/Module
# make
# strip -S rt73.ko
# make install  (qui installe correctement le firmware notamment)
# modprobe rt73
Le module est normalement chargé (le vérifier par un lsmod | grep rt73).

3- Le paramétrage de la connexion:

Dans mon cas, system-config-services a échoué. J'ai donc lancé la connexion "manuellement":

Vérifier que le matériel est reconnu en utilisant system-config-network (onglet matériel). Il doit normalement être reconnu. Repérer l'interface allouée (dans l'exemple: wlan0).

Supprimer toute configuration de périphérique (il semble que system-config-network ne supporte pas rt73 ...) en sorte que le lancement du service network se borne à l'activation de lookup.

Configurer la liaison Wifi: 
 # /sbin/iwconfig wlan0 essid "le Nom du Réseau" channel Le_Numéro_du_Canal key La_Clé_WEP
# /sbin/ifconfig wlan0 up
# /sbin/dhclient
Normalement, la connexion est active.

4- L'amélioration de la procédure:

Il suffit de créer un script intégrant la séquence des commandes passées et de l'activer au démarrage du système.

A noter qu'à chaque modification de noyau, il faudra penser à recompiler le module et à l'installer. Par contre, les scripts de connexion resteront inchangés.
@Ambelliance : regarde le man yum.conf, les paramètres installonly_limit et installonlypkgs.

@herrib : j'ai fait un test avec un RT73USB et le noyau 2.6.23 il y a 8 jours : connexion impossible.
La solution du driver legacy pour le RT73 est toujours réalisable, même si ces pilotes ne sont plus maintenus. Se pose aussi la question de la gestion du cryptage WPA avec des outils non standards sous Fedora.
Le vrai dilemme c'est que Fedora fournit le RT2x00 pour des raisons de cohérence avec l'ensemble des pilotes Ralink et avec la couche mac80211, même si ils ne fonctionnent pas correctement selon les versions du noyau.
Il est à souhaiter que la période d'instabilité se termine au plus vite car les composants Ralink sont vraiment des produits très complets (mode Monitor, injection, ...)
J'aurais plutot tendance à proposer de prendre un kernel en updates-testing...voire le kernel précédant plutot...
(même raison que tapioca)
kwizart wrote:J'aurais plutot tendance à proposer de prendre un kernel en updates-testing...voire le kernel précédant plutot...
(même raison que tapioca)
Updates-testing: l'aventure aussi ...

Kernel précédent: la rupture 2.6.23 - 24 est importante et il faut aussi tenir compte d'autres éléments (drivers graphiques par exemple). Je recommande simplement de ne pas passer en 2.6.24 dans l'immédiat sauf à accepter la bidouille et l'impossibilité d'un retour arrière.
je suis d'accord pour repousser la mise à jours à un kernel 2.6.24 dans certains cas, (wifi et gpu intel)
Pour les autres pas de soucis

kwizart uname -r = 2.6.24.3-21.fc8
tapioca wrote:regarde le man yum.conf, les paramètres installonly_limit et installonlypkgs.
Merci, c'est exactement ce que je cherchais : j'utilise à peine 15 % de l'espace réservé à mon dossier boot...
C'est bête de ne pas utiliser plus comme filet de sécurité (d'autant que j'avais augmenté sa taille à cet effet lors de l'install de fc8).
herrib wrote:A noter qu'à chaque modification de noyau, il faudra penser à recompiler le module et à l'installer.
Merci pour toutes ces précisions.
Je suis heureux d'apprendre que le problème est connu et en cours de résolution.

Pour ma part, je pense que je vais rester avec le noyau 2.6.23 jusqu'à ce que vienne une version où le problème sera résolu. L'idée de trainer un module à recompiler à chaque modification ne m'enthousiasme pas...
J'ai assez souffert avec cette connexion wifi, quand je l'ai installée il y a bientôt un an !

C'est toutefois rassurant de voir que la situation progresse au niveau de ces chipsets RaLink et de se dire que l'on finira par avoir quelque chose qui restera stable...
C'est cool aussi de voir que des solutions sont proposées pour les plus impatients 🙂

Cordialement,
Stefan
8 jours plus tard
Bonjour,

bonne nouvelle : avec le noyau 2.6.24.3-34.fc8 les pilotes RT2x00 passent en version 2.1.4.
Ma carte Hercules avec RT2561PCI fonctionne correctement.
Le noyau 2.6.24.3-34.fc8 corrige effectivement certains pbs de support de chipsets Ralink (ex USB Wifi HERCULES).

Pour supprimer le contournement proposé, il suffit, depuis une session sur l'ancien noyau, de sortir de /etc/modprobe.d/blacklist les items rt73usb, rt2570, rt2x00lib -> rt73usb dans l'exemple pris).

Le module rt73 ne peut être déchargé.

On relance et rt73usb monte alors sans pb (bref, le nouveau noyau prend correctement en charge le support rt2x00.
Tous les problèmes ne sont pas réglé avec le rt61pci sous noyau 2.6.24.3-34
Quelques messages d'erreur au dénarrage des services network et wpa_supplicant mais sans autre conséquence sur le fonctionnement qu'une authentification plus longue à obtenir.
Le téléchargement d'une ISO de CD va à son terme 🙂, par contre un "service network restart" gèle la machine.🙁
Est ce que ces erreurs ne seraient pas du à la coexistence de fichiers de configuration différents (issue tu rt61?)
Non, je n'ai jamais installé le pilote legacy sur FC8.
De mon côté, le passage au noyau 2.6.24.3-34 s'est (presque) bien passé...

Il semble que cette version supporte sans problème les chipsets Ralink RT2561/RT61

Jute un petit détail...
Pour que ça fonctionne, j'ai dû à nouveau supprimer toutes les entrées dans système - > réseau
et les re-créer

J'vais finir par connaître ma clé par coeur :lol:

A part ça, ça roule... un vrai bonheur 😉

Cordialement,
Stefan
15 jours plus tard
Je viens d'installer une Ovislink EVO-W542PCI à base de rt2561 (j'ai vu le chipset avant d'installer) en WPA/TKIP, sur une Fedora 8 i386 :
- noyau 2.6.24.3-50, mis à part un message d'erreur (j'ai pas eu le temps de le noter), la connexion se fait en quelques secondes et elle semble stable (environs 100Mo de yum update sans problème) ;
- noyau 2.6.24.4-64, freeze au moment de l'obtention de l'IP au boot !!!

Mon routeur/modem wifi est un Linksys WAG200G
Dekkard wrote:Je viens d'installer une Ovislink EVO-W542PCI à base de rt2561 (...)
- noyau 2.6.24.4-64, freeze au moment de l'obtention de l'IP au boot !!!
Mon routeur/modem wifi est un Linksys WAG200G
Salut Dekkard (fan de Diablo ? 😉 )

Visiblement nous possédons la même carte wifi (enfin, comme dénomination exacte,
moi j'ai Ovislink EVO-W54PCIv2) ou en tout cas très similaire.

Par contre, en modem routeur, j'ai un Philips (avec un dessus rouge... j'ai pas la référence
sous la main).

Merci pour la remontée d'info, concernant le freeze au moment du boot.
Cela dit, j'ai une petite question : est-ce que tu utilises le DHCP ?

Parce que si c'est le cas, je ne serais sans doute pas concerné puisque je suis en IP statique.
Cela dit, je me souviens avoir fait ce choix parce que j'ai un tout petit réseau... et que j'ai
constaté que ça me permettant d'avoir la connexion plus vite au boot.

Très cordialement,
Stefan
Malheureusement, même en IP statique, le chargement du pilote provoque le freeze de la machine.
Bizarre, puisqu'il s'agit toujours de la version 2.1.4 utilisée par le noyau 2.6.24.3-50 : le problème est peut-être ailleurs.
6 jours plus tard
Salut à Tous,

Je confirme en effet également le freeze lors du boot après le passage au noyau 2.6.24.4-64
même en IP statique : je viens de faire l'expérience 🙁

Heureusement, il suffit de rebooter avec le noyau 2.6.24.3-50 pour avoir à nouveau une machine
fonctionnelle...
J'espère que ces problèmes de cartes wifi finiront par se régler.

Cordialement,
Stefan