Journal Fin du freeze avec le driver re(4) sous OpenBSD

Posté par Anonyme le 18 mars 2008 à 21:16.

Étiquettes : aucune

mar.

2008

Sur certaines machines, l'utilisation du driver re(4) (chipset ethernet Realtek) freezait complètement la machine au bout d'un certain temps avec OpenBSD. Certains n'avaient pas le problèmes, d'autres oui. Certains ont pu le corriger en négociant la carte en base100TX. Mais le problème persistait encore chez beaucoup, en particulier sur les bus pcie.

Des traces ont pu isoler que c'était dû à l'utilisation de ping en multicast, et un "fix à l'arrache" a été trouvé au début, qui consistait à désactiver le ping multicast dans le source du driver. Bien entendu, hors de question de commiter ça (alors que c'est une solution qui aurait apparemment été utilisée dans le kernel Linux), mais ça dépannait toujours de manière non officielle.

Mais il y a quelques jours, Brad@ a réussi à trouver le problème et le résoudre. Ca fait plaisir de voir passer ça dans le CVS :

Modified files:

	sys/dev/ic     : re.c rtl81x9reg.h 



Log message:

Set the RX FIFO threshold to no RX threshold for re(4) adapters.

This resolves a number of various bad symptoms experienced by

numerous users especially with the adapters at Gig speed.



Tested by quite a few users.



From FreeBSD/NetBSD

Theo a également ajouté ce fichier sur OPENBSD_4_3. Ca vallait le coup d'effectuer un changement de dernière minute et d'intégrer ce correctif dans la nouvelle release à paraître bientôt :-)

# C'est quoi le "RX FIFO threshold" ?

Posté par Victor STINNER (site web personnel) le 18 mars 2008 à 21:33. Évalué à 2.

La question est dans le titre.
- [^] # Re: C'est quoi le "RX FIFO threshold" ?
  
  Posté par Jerome Herman le 18 mars 2008 à 21:45. Évalué à 7.
  
  Quand la réception de la carte (RX) est en mode FIFO (First In First Out, premier arrivé, premier parti) elle fonctionne comme un pipe. Si le système n'est pas assez rapide pour récupérer les données que lui envoie la carte réseau, le tampon mémoire de réception se remplit. Quand il est plein on a deux solution : soit on envoie un paquet "pause" pour expliquer gentiment au routeur/switch/ordi à l'origine des données qu'il faut laisser la carte réseau respirer un peu, soit on ne fait rien et on retourne une erreur si un paquet arrive alors que le tampon est plein.
  
  Le RX FIFO threshold (niveau FIFO de reception) est le moment ou l'on juge que le tampon est trop rempli et qu'il faut dire pouce (envoyer un paquet pause)
  - [^] # Re: C'est quoi le "RX FIFO threshold" ?
    
    Posté par Hank Lords le 19 mars 2008 à 02:49. Évalué à 1.
    
    J'ai eu ce soucis avec ma carte. Le symptome était que dès qu'un pc (win ou linux) démarrait sur le meme reseau que la machine, celle ci freezait completement : reboot hard necessaire.
    
    Le RX FIFO threshold (niveau FIFO de reception) est le moment ou l'on juge que le tampon est trop rempli et qu'il faut dire pouce (envoyer un paquet pause)
    
    Ca me parait etre important comme comportement :) alors est-ce que quelqu'un connait les conséquences de supprimer cette fonction ? (a part de résoudre le problème).
    - [^] # Re: C'est quoi le "RX FIFO threshold" ?
      
      Posté par psychoslave__ (site web personnel) le 19 mars 2008 à 10:41. Évalué à 2.
      
      Je voudrais pas dire de connerie, mais il me semble qu'aucune fonction à été supprimé ici.
      
      Moi ce que j'ai compris c'est qu'avant le pilote ne prévoyais pas le cas où la FIFO était pleine. Et maintenant quand elle est pleine elle envoie un paquet pour dire "laisse moi déjà digérer ça".
      - [^] # Re: C'est quoi le "RX FIFO threshold" ?
        
        Posté par Jerome Herman le 19 mars 2008 à 11:12. Évalué à 2.
        
        Moi ce que j'ai compris c'est qu'avant le pilote ne prévoyais pas le cas où la FIFO était pleine. Et maintenant quand elle est pleine elle envoie un paquet pour dire "laisse moi déjà digérer ça".
        
        C'est l'inverse, avant on envoyait une interruption à la carte pour qu'elle envoie un paquet "pause", mais l'interruption en question est mal supportée par la carte ce qui peut entrainer un freeze.
        Maintenant la carte se met en erreur réception quand elle reçoit un paquet de trop.
        Le seul problème avec cette méthode est que la machine qui a émit le paquet va alors le réémettre en boucle jusqu'à ce qu'il passe
# Euh...

Posté par Zenitram (site web personnel) le 18 mars 2008 à 21:59. Évalué à 1.

En tous cas, un driver d'un matériel "non vital" qui freeze une machine, ça ne fait pas classe... Je croyais que c'était uniquement pour les utilisateurs de Windows, les pro-BSD/Linux m'auraient menti?
- [^] # Re: Euh...
  
  Posté par Guillaume Knispel le 19 mars 2008 à 00:34. Évalué à 5.
  
  N'importe quel driver kernel space (et c'est le cas de la très grande majorité) peut freezer complètement toute la machine sous BSD, Linux, Windows, etc si l'envie lui prend. Donc oui on a probablement du te mentir précédemment.
  
  Et c'est sans même compter sur les cartes et chips eux-même, qui s'ils pètent vraiment les plombs peuvent faire exactement la même chose.
  - [^] # Re: Euh...
    
    Posté par Zenitram (site web personnel) le 19 mars 2008 à 00:40. Évalué à 2.
    
    C'était plus une boutade envers les anti-Microsoft et leur "Linux et/ou BSD c'est génial, ça plante jamais, Windows ça pue" etc..
    
    Plus sérieusement, question idiote : sous Windows, j'ai déjà fait planter des drivers (wifi en l'occurrence), sans mettre à mal l'OS, desactivation/réactivation du pilote et c'était reparti. Certes, ce n'est pas toujours comme ça, mais ça arrive.
    Qu'est-ce qui empêche de mettre un driver réseau ailleurs que dans le kernel space très vulnérable pour Linux et/ou BSD? Perf?
    - [^] # Re: Euh...
      
      Posté par khivapia le 19 mars 2008 à 01:39. Évalué à 2.
      
      Il me semble parfois avoir réussi à être resté à peu près stable sous Linux simplement en déchargeant puis rechargeant un module qui avait planté (genre la carte graphique), bon pas souvent...
      
      Qu'est-ce qui empêche de mettre un driver réseau ailleurs que dans le kernel space très vulnérable pour Linux et/ou BSD?
      
      Rien, ça s'appelle un micro-noyau (par exemple).
      C'est un choix de conception pour le noyau Linux si j'ai de bons souvenirs de réponses de Linus Torvalds à ce genre de question (on pourra même se rapporter au débat avec Andrew Tanenbaum aux tous débuts de Linux ;-) )
      
      Perf?
      sans aucun doute pour les micro-noyaux, le problème est que mettre un pilote en espace utilisateur va en gros lui faire générer un grand nombre d'appels systèmes, ce qui est une problème pour les performances (passage du mode noyau au mode protégé, etc. etc.)
      
      voir le paragraphe sur les micro-noyaux sur wikipedia, qui est très instructif et très clair : http://fr.wikipedia.org/wiki/Micro-noyau
      - [^] # Re: Euh...
        
        Posté par khivapia le 19 mars 2008 à 01:40. Évalué à 3.
        
        En lisant plus attentivement la page wikipedia je me rends compte que le schéma présenté montre le pilote réseau comme étant relativement indépendant du noyau, mon argumentation ne tient sans doute pas debout, est-ce qu'un expert qui passe dans le coin pourrait me corriger ?
        
        Merci
  - [^] # Re: Euh...
    
    Posté par psychoslave__ (site web personnel) le 19 mars 2008 à 10:43. Évalué à 2.
    
    En fait y a qu'avec une architecture en micro-noyau où les pilotes sont en espace utilisateur que ça ferait pas geler tout le système, non?
    - [^] # Re: Euh...
      
      Posté par Guillaume Knispel le 31 mars 2008 à 03:55. Évalué à 2.
      
      En théorie, oui, en pratique c'est très compliqué car il n'y a pas beaucoup de pilotes qui ne sont pas critiques, et en redémarrer un sans rien perturber par ailleurs n'est pas une chose aisée ; on risque une réaction en chaîne qui aboutisse à l'effondrement de toute façon.
      
      Il faut à mon avis plus se concentrer sur de l'informatique fiable à priori (modèles exécutables, langages de très haut niveau performants, preuves formelles, etc...) que sur uniquement des mesures de sûreté mais construites sur du sable !
# Ah bah ouais...

Posté par Sufflope (site web personnel) le 18 mars 2008 à 22:08. Évalué à 8.

... désactiver le tampon, ça fait plus classe que désactiver le ping multicast, c'est clair que c'est un fix idéal, pas comme ces cochons de linuxiens.
Bientôt le commit du fix suprême : retirer le câble d'alim. Plus de freezes intempestifs.
- [^] # Re: Ah bah ouais...
  
  Posté par fat_cartman le 18 mars 2008 à 22:42. Évalué à 5.
  
  Je crois plutot que la solution choisie est aucune limite de tampon, et non pas pas de tampon...
  Mais bon c'est pas mieux!!!!
  - [^] # Re: Ah bah ouais...
    
    Posté par Anonyme le 19 mars 2008 à 10:09. Évalué à 4.
    
    C'est toujours mieux que de désactiver une feature (ping multicast). Cette solution a été adoptée pour les autres BSDs en tout cas.
  - [^] # Re: Ah bah ouais...
    
    Posté par psychoslave__ (site web personnel) le 19 mars 2008 à 10:49. Évalué à 3.
    
    Bon bah alors c'est que j'ai pas compris. Moi j'avais compris qu'il y avais un tampon, avec une limite, et que dans le cas où la limite est atteinte, un paquet est envoyé pour signaler de ne plus envoyer de donnée le temps que le tampon ce vide un peu.
    - [^] # Re: Ah bah ouais...
      
      Posté par Anonyme le 19 mars 2008 à 11:30. Évalué à 1.
      
      C'est bien ça le problème, le paquet 'pause' n'est plus envoyé. C'est toujours mieux que de désactiver la feature du ping multicast, mais c'est pas encore la solution idéale...
      
      Après, faut voir la carte en elle-même si c'est pas dû à elle (genre à des fonctions limitées, etc...)
# Re:

Posté par IsNotGood le 18 mars 2008 à 22:59. Évalué à -5.

Une information aussi important mérite une dépêche en première page.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.