Journal : Fin du freeze avec le driver re(4) sous OpenBSD
Posté par Nicolas (page perso, ) le 18 mars 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 :
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 :-)
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/NetBSDTheo 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 :-)
> Lire le journal (18 commentaires, moyenne: 2,6).
Vous avez demandé le commentaire #914717.
Run by 
Cette page a été générée par Templeet en 0.0554s (dont 0.0098 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Ah bah ouais...
... 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.
Le meilleur hébergeur de forums, gratuit et sans pub !
[^]Re: Ah bah ouais...
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...
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...
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.
Le wiki de l'association culture libre : collection d'œuvres sous licence art libre.
[^]Re: Ah bah ouais...
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...)