J'ai mon serveur qui est passé sous Open 3.6 depuis quelques jours.
Tout marche pour l'instant bien (sauf un étrance pb avec la carte son
qui n'a d'abord pas fonctionné comme il faut puis qui s'est remise à
bien fonctionner).
Et voila que j'ai eu ce message :
/bsd: WARNING: mclpool limit reached; increase kern.maxclusters
Je ne pouvais plus, entre autre, me connecter via ssh sur le serveur.
J'ai bien sur suivi le conseil du warning :
sysctl kern.maxclusters=65536
Et là, je peux me connecter à nouveau.
Par contre, j'aimerais bien avoir des explications.
En effet, ça fait plus de 3 ans que j'utilise Open et je n'avais jamais
eu ce warning.
A+
--
Nicolas BERNE - mailto:nicolas.berne@wanadoo.fr
HTML lesson #42: The only legitimate use of the greatly loathed <BLINK> tag.
Schroedinger's Cat is <BLINK>NOT</BLINK> dead.
Je ne pouvais plus, entre autre, me connecter via ssh sur le serveur. J'ai bien sur suivi le conseil du warning : sysctl kern.maxclusterse536
Et là, je peux me connecter à nouveau.
Par contre, j'aimerais bien avoir des explications. En effet, ça fait plus de 3 ans que j'utilise Open et je n'avais jamais eu ce warning.
Et pour cause : il est apparu avec la version 3.6.
Jusqu'à la version 3.5 et quelques semaines, la mémoire allouée aux structures mbuf (qui contiennent tous les paquets en cours de traitement par la pile IP) était une zone figée, allouée au démarrage du noyau ; sa taille était contrôlée par la valeur NMBCLUSTERS.
Quand cet espace était plein, il n'était pas possible de l'aggrandir : la seule possibilité était de recompiler un noyau avec une valeur de NMBCLUSTERS plus importante.
A l'inverse, quand cet espace était relativement inoccupé, cette mémoire inutilisée ne pouvait pas être empruntée pour d'autres usages.
Depuis OpenBSD 3.6 (et quelques mois avant), cette organisation figée a été remplacée par une structure "pool" du noyau. Les pool apportent les avantages suivants : - quand un pool est plutôt inoccupé, la mémoire dont il ne se sert pas peut être utilisée par d'autres pool. Ceci permet de mieux utiliser la mémoire, et de ne pas bloquer inutilement des ressources. - quand un pool est plein, il est possible de le faire grossir (à condition qu'il reste de la mémoire physique disponible pour le noyau, bien entendu). Ce procédé n'est pas automatique ; dans le cas du pool de mbufs, cela se fait via le sysctl kern.maxclusters, comme l'indiquait le message d'avertissement. - quand un pool se remplit et devient _presque_ plein, il est possible de déclencher des actions préventives (histoire de retarder la saturation complète, par exemple). - enfin, il est possible de définir une taille minimale de mémoire qui reste toujours acquise à un pool, de façon à ce que, si un pool particulier grossit énormément et finit par consommer la totalité de la mémoire que se partagent tous les pools, les autres pools ont tout de même la possibilité de contenir un certain nombre d'éléments.
Dans le cas qui t'intéresse, l'avantage essentiel est qu'il n'est plus nécessaire de devoir recompiler un nouveau noyau si la taille initiale du pool calculée par le noyau s'avère insuffisante : il suffit de rajouter une ligne dans /etc/sysctl.conf...
Je ne pouvais plus, entre autre, me connecter via ssh sur le serveur.
J'ai bien sur suivi le conseil du warning :
sysctl kern.maxclusterse536
Et là, je peux me connecter à nouveau.
Par contre, j'aimerais bien avoir des explications.
En effet, ça fait plus de 3 ans que j'utilise Open et je n'avais jamais
eu ce warning.
Et pour cause : il est apparu avec la version 3.6.
Jusqu'à la version 3.5 et quelques semaines, la mémoire allouée aux
structures mbuf (qui contiennent tous les paquets en cours de traitement
par la pile IP) était une zone figée, allouée au démarrage du noyau ; sa
taille était contrôlée par la valeur NMBCLUSTERS.
Quand cet espace était plein, il n'était pas possible de l'aggrandir :
la seule possibilité était de recompiler un noyau avec une valeur de
NMBCLUSTERS plus importante.
A l'inverse, quand cet espace était relativement inoccupé, cette mémoire
inutilisée ne pouvait pas être empruntée pour d'autres usages.
Depuis OpenBSD 3.6 (et quelques mois avant), cette organisation figée a
été remplacée par une structure "pool" du noyau. Les pool apportent les
avantages suivants :
- quand un pool est plutôt inoccupé, la mémoire dont il ne se sert pas
peut être utilisée par d'autres pool. Ceci permet de mieux utiliser la
mémoire, et de ne pas bloquer inutilement des ressources.
- quand un pool est plein, il est possible de le faire grossir (à
condition qu'il reste de la mémoire physique disponible pour le noyau,
bien entendu). Ce procédé n'est pas automatique ; dans le cas du pool
de mbufs, cela se fait via le sysctl kern.maxclusters, comme
l'indiquait le message d'avertissement.
- quand un pool se remplit et devient _presque_ plein, il est possible
de déclencher des actions préventives (histoire de retarder la
saturation complète, par exemple).
- enfin, il est possible de définir une taille minimale de mémoire qui
reste toujours acquise à un pool, de façon à ce que, si un pool
particulier grossit énormément et finit par consommer la totalité de
la mémoire que se partagent tous les pools, les autres pools ont tout
de même la possibilité de contenir un certain nombre d'éléments.
Dans le cas qui t'intéresse, l'avantage essentiel est qu'il n'est plus
nécessaire de devoir recompiler un nouveau noyau si la taille initiale
du pool calculée par le noyau s'avère insuffisante : il suffit de
rajouter une ligne dans /etc/sysctl.conf...
Je ne pouvais plus, entre autre, me connecter via ssh sur le serveur. J'ai bien sur suivi le conseil du warning : sysctl kern.maxclusterse536
Et là, je peux me connecter à nouveau.
Par contre, j'aimerais bien avoir des explications. En effet, ça fait plus de 3 ans que j'utilise Open et je n'avais jamais eu ce warning.
Et pour cause : il est apparu avec la version 3.6.
Jusqu'à la version 3.5 et quelques semaines, la mémoire allouée aux structures mbuf (qui contiennent tous les paquets en cours de traitement par la pile IP) était une zone figée, allouée au démarrage du noyau ; sa taille était contrôlée par la valeur NMBCLUSTERS.
Quand cet espace était plein, il n'était pas possible de l'aggrandir : la seule possibilité était de recompiler un noyau avec une valeur de NMBCLUSTERS plus importante.
A l'inverse, quand cet espace était relativement inoccupé, cette mémoire inutilisée ne pouvait pas être empruntée pour d'autres usages.
Depuis OpenBSD 3.6 (et quelques mois avant), cette organisation figée a été remplacée par une structure "pool" du noyau. Les pool apportent les avantages suivants : - quand un pool est plutôt inoccupé, la mémoire dont il ne se sert pas peut être utilisée par d'autres pool. Ceci permet de mieux utiliser la mémoire, et de ne pas bloquer inutilement des ressources. - quand un pool est plein, il est possible de le faire grossir (à condition qu'il reste de la mémoire physique disponible pour le noyau, bien entendu). Ce procédé n'est pas automatique ; dans le cas du pool de mbufs, cela se fait via le sysctl kern.maxclusters, comme l'indiquait le message d'avertissement. - quand un pool se remplit et devient _presque_ plein, il est possible de déclencher des actions préventives (histoire de retarder la saturation complète, par exemple). - enfin, il est possible de définir une taille minimale de mémoire qui reste toujours acquise à un pool, de façon à ce que, si un pool particulier grossit énormément et finit par consommer la totalité de la mémoire que se partagent tous les pools, les autres pools ont tout de même la possibilité de contenir un certain nombre d'éléments.
Dans le cas qui t'intéresse, l'avantage essentiel est qu'il n'est plus nécessaire de devoir recompiler un nouveau noyau si la taille initiale du pool calculée par le noyau s'avère insuffisante : il suffit de rajouter une ligne dans /etc/sysctl.conf...
Manuel Sabban
Miod Vallat writes:
Et pour cause : il est apparu avec la version 3.6.
Jusqu'à la version 3.5 et quelques semaines, la mémoire allouée aux structures mbuf (qui contiennent tous les paquets en cours de traitement par la pile IP) était une zone figée, allouée au démarrage du noyau ; sa taille était contrôlée par la valeur NMBCLUSTERS.
Quand cet espace était plein, il n'était pas possible de l'aggrandir : la seule possibilité était de recompiler un noyau avec une valeur de NMBCLUSTERS plus importante.
A l'inverse, quand cet espace était relativement inoccupé, cette mémoire inutilisée ne pouvait pas être empruntée pour d'autres usages.
Depuis OpenBSD 3.6 (et quelques mois avant), cette organisation figée a été remplacée par une structure "pool" du noyau. Les pool apportent les avantages suivants : - quand un pool est plutôt inoccupé, la mémoire dont il ne se sert pas peut être utilisée par d'autres pool. Ceci permet de mieux utiliser la mémoire, et de ne pas bloquer inutilement des ressources. - quand un pool est plein, il est possible de le faire grossir (à condition qu'il reste de la mémoire physique disponible pour le noyau, bien entendu). Ce procédé n'est pas automatique ; dans le cas du pool de mbufs, cela se fait via le sysctl kern.maxclusters, comme l'indiquait le message d'avertissement. - quand un pool se remplit et devient _presque_ plein, il est possible de déclencher des actions préventives (histoire de retarder la saturation complète, par exemple). - enfin, il est possible de définir une taille minimale de mémoire qui reste toujours acquise à un pool, de façon à ce que, si un pool particulier grossit énormément et finit par consommer la totalité de la mémoire que se partagent tous les pools, les autres pools ont tout de même la possibilité de contenir un certain nombre d'éléments.
Dans le cas qui t'intéresse, l'avantage essentiel est qu'il n'est plus nécessaire de devoir recompiler un nouveau noyau si la taille initiale du pool calculée par le noyau s'avère insuffisante : il suffit de rajouter une ligne dans /etc/sysctl.conf...
J'ai aussi le problème. Mais quand j'augmente la limite le pool se remplit quand même, et quand j'augmente encore la limite, je finis par obtenir un panic. La question que je me pose est la suivante: Y-a-t il moyen de trouver quel est le processus fautif (plus simplement qu'en tuant les services les uns après les autres) ?
Sinon j'ai vu dans un message de misc@ que c'est sans doute du à un défaut matériel. La question qui me vient alors à l'esprit est quel est le bidule que je dois changer ? -- If God wishes thee to perish, He causes thy steps to lead thee to the place of thy demise.
-- Cant of the Shariat
Miod Vallat <miod@online.fr> writes:
Et pour cause : il est apparu avec la version 3.6.
Jusqu'à la version 3.5 et quelques semaines, la mémoire allouée aux
structures mbuf (qui contiennent tous les paquets en cours de traitement
par la pile IP) était une zone figée, allouée au démarrage du noyau ; sa
taille était contrôlée par la valeur NMBCLUSTERS.
Quand cet espace était plein, il n'était pas possible de l'aggrandir :
la seule possibilité était de recompiler un noyau avec une valeur de
NMBCLUSTERS plus importante.
A l'inverse, quand cet espace était relativement inoccupé, cette mémoire
inutilisée ne pouvait pas être empruntée pour d'autres usages.
Depuis OpenBSD 3.6 (et quelques mois avant), cette organisation figée a
été remplacée par une structure "pool" du noyau. Les pool apportent les
avantages suivants :
- quand un pool est plutôt inoccupé, la mémoire dont il ne se sert pas
peut être utilisée par d'autres pool. Ceci permet de mieux utiliser la
mémoire, et de ne pas bloquer inutilement des ressources.
- quand un pool est plein, il est possible de le faire grossir (à
condition qu'il reste de la mémoire physique disponible pour le noyau,
bien entendu). Ce procédé n'est pas automatique ; dans le cas du pool
de mbufs, cela se fait via le sysctl kern.maxclusters, comme
l'indiquait le message d'avertissement.
- quand un pool se remplit et devient _presque_ plein, il est possible
de déclencher des actions préventives (histoire de retarder la
saturation complète, par exemple).
- enfin, il est possible de définir une taille minimale de mémoire qui
reste toujours acquise à un pool, de façon à ce que, si un pool
particulier grossit énormément et finit par consommer la totalité de
la mémoire que se partagent tous les pools, les autres pools ont tout
de même la possibilité de contenir un certain nombre d'éléments.
Dans le cas qui t'intéresse, l'avantage essentiel est qu'il n'est plus
nécessaire de devoir recompiler un nouveau noyau si la taille initiale
du pool calculée par le noyau s'avère insuffisante : il suffit de
rajouter une ligne dans /etc/sysctl.conf...
J'ai aussi le problème. Mais quand j'augmente la limite le pool se
remplit quand même, et quand j'augmente encore la limite, je finis par
obtenir un panic. La question que je me pose est la suivante: Y-a-t il
moyen de trouver quel est le processus fautif (plus simplement qu'en
tuant les services les uns après les autres) ?
Sinon j'ai vu dans un message de misc@ que c'est sans doute du à un
défaut matériel. La question qui me vient alors à l'esprit est quel
est le bidule que je dois changer ?
--
If God wishes thee to perish, He causes thy steps to
lead thee to the place of thy demise.
Et pour cause : il est apparu avec la version 3.6.
Jusqu'à la version 3.5 et quelques semaines, la mémoire allouée aux structures mbuf (qui contiennent tous les paquets en cours de traitement par la pile IP) était une zone figée, allouée au démarrage du noyau ; sa taille était contrôlée par la valeur NMBCLUSTERS.
Quand cet espace était plein, il n'était pas possible de l'aggrandir : la seule possibilité était de recompiler un noyau avec une valeur de NMBCLUSTERS plus importante.
A l'inverse, quand cet espace était relativement inoccupé, cette mémoire inutilisée ne pouvait pas être empruntée pour d'autres usages.
Depuis OpenBSD 3.6 (et quelques mois avant), cette organisation figée a été remplacée par une structure "pool" du noyau. Les pool apportent les avantages suivants : - quand un pool est plutôt inoccupé, la mémoire dont il ne se sert pas peut être utilisée par d'autres pool. Ceci permet de mieux utiliser la mémoire, et de ne pas bloquer inutilement des ressources. - quand un pool est plein, il est possible de le faire grossir (à condition qu'il reste de la mémoire physique disponible pour le noyau, bien entendu). Ce procédé n'est pas automatique ; dans le cas du pool de mbufs, cela se fait via le sysctl kern.maxclusters, comme l'indiquait le message d'avertissement. - quand un pool se remplit et devient _presque_ plein, il est possible de déclencher des actions préventives (histoire de retarder la saturation complète, par exemple). - enfin, il est possible de définir une taille minimale de mémoire qui reste toujours acquise à un pool, de façon à ce que, si un pool particulier grossit énormément et finit par consommer la totalité de la mémoire que se partagent tous les pools, les autres pools ont tout de même la possibilité de contenir un certain nombre d'éléments.
Dans le cas qui t'intéresse, l'avantage essentiel est qu'il n'est plus nécessaire de devoir recompiler un nouveau noyau si la taille initiale du pool calculée par le noyau s'avère insuffisante : il suffit de rajouter une ligne dans /etc/sysctl.conf...
J'ai aussi le problème. Mais quand j'augmente la limite le pool se remplit quand même, et quand j'augmente encore la limite, je finis par obtenir un panic. La question que je me pose est la suivante: Y-a-t il moyen de trouver quel est le processus fautif (plus simplement qu'en tuant les services les uns après les autres) ?
Sinon j'ai vu dans un message de misc@ que c'est sans doute du à un défaut matériel. La question qui me vient alors à l'esprit est quel est le bidule que je dois changer ? -- If God wishes thee to perish, He causes thy steps to lead thee to the place of thy demise.
-- Cant of the Shariat
Nicolas BERNE
Thus Spoke Miod Vallat :
Par contre, j'aimerais bien avoir des explications. En effet, ça fait plus de 3 ans que j'utilise Open et je n'avais jamais eu ce warning.
Et pour cause : il est apparu avec la version 3.6. ARF :o)
<SNIP>
Dans le cas qui t'intéresse, l'avantage essentiel est qu'il n'est plus nécessaire de devoir recompiler un nouveau noyau si la taille initiale du pool calculée par le noyau s'avère insuffisante : il suffit de rajouter une ligne dans /etc/sysctl.conf... OK. Merci pour toutes ces infos.
A+
-- Nicolas BERNE - mailto:
HTML lesson #42: The only legitimate use of the greatly loathed <BLINK> tag. Schroedinger's Cat is <BLINK>NOT</BLINK> dead.
Thus Spoke Miod Vallat <miod@online.fr>:
Par contre, j'aimerais bien avoir des explications.
En effet, ça fait plus de 3 ans que j'utilise Open et je n'avais jamais
eu ce warning.
Et pour cause : il est apparu avec la version 3.6.
ARF :o)
<SNIP>
Dans le cas qui t'intéresse, l'avantage essentiel est qu'il n'est plus
nécessaire de devoir recompiler un nouveau noyau si la taille initiale
du pool calculée par le noyau s'avère insuffisante : il suffit de
rajouter une ligne dans /etc/sysctl.conf...
OK. Merci pour toutes ces infos.
A+
--
Nicolas BERNE - mailto:nicolas.berne@wanadoo.fr
HTML lesson #42: The only legitimate use of the greatly loathed <BLINK> tag.
Schroedinger's Cat is <BLINK>NOT</BLINK> dead.
Par contre, j'aimerais bien avoir des explications. En effet, ça fait plus de 3 ans que j'utilise Open et je n'avais jamais eu ce warning.
Et pour cause : il est apparu avec la version 3.6. ARF :o)
<SNIP>
Dans le cas qui t'intéresse, l'avantage essentiel est qu'il n'est plus nécessaire de devoir recompiler un nouveau noyau si la taille initiale du pool calculée par le noyau s'avère insuffisante : il suffit de rajouter une ligne dans /etc/sysctl.conf... OK. Merci pour toutes ces infos.
A+
-- Nicolas BERNE - mailto:
HTML lesson #42: The only legitimate use of the greatly loathed <BLINK> tag. Schroedinger's Cat is <BLINK>NOT</BLINK> dead.
Miod Vallat
J'ai aussi le problème. Mais quand j'augmente la limite le pool se remplit quand même, et quand j'augmente encore la limite, je finis par obtenir un panic. La question que je me pose est la suivante: Y-a-t il moyen de trouver quel est le processus fautif (plus simplement qu'en tuant les services les uns après les autres) ?
Pas que je sache. Ou alors à la main, en surveillant régulièrement ce que donne "netstat -m" en parallèle avec top...
Sinon j'ai vu dans un message de misc@ que c'est sans doute du à un défaut matériel. La question qui me vient alors à l'esprit est quel est le bidule que je dois changer ?
Cela ressemble aux symptômes d'une fuite de mbuf dans un pilote de carte réseau. Une façon simple de vérifier si c'est le cas consiste à remplacer une à une, chacune des cartes réseau par une carte utilisant un pilote différent (par exemple, remplacer une rl par une xl ou une fxp), et observer si le phénomène se reproduit.
J'ai aussi le problème. Mais quand j'augmente la limite le pool se
remplit quand même, et quand j'augmente encore la limite, je finis par
obtenir un panic. La question que je me pose est la suivante: Y-a-t il
moyen de trouver quel est le processus fautif (plus simplement qu'en
tuant les services les uns après les autres) ?
Pas que je sache. Ou alors à la main, en surveillant régulièrement
ce que donne "netstat -m" en parallèle avec top...
Sinon j'ai vu dans un message de misc@ que c'est sans doute du à un
défaut matériel. La question qui me vient alors à l'esprit est quel
est le bidule que je dois changer ?
Cela ressemble aux symptômes d'une fuite de mbuf dans un pilote de carte
réseau. Une façon simple de vérifier si c'est le cas consiste à
remplacer une à une, chacune des cartes réseau par une carte utilisant
un pilote différent (par exemple, remplacer une rl par une xl ou une
fxp), et observer si le phénomène se reproduit.
J'ai aussi le problème. Mais quand j'augmente la limite le pool se remplit quand même, et quand j'augmente encore la limite, je finis par obtenir un panic. La question que je me pose est la suivante: Y-a-t il moyen de trouver quel est le processus fautif (plus simplement qu'en tuant les services les uns après les autres) ?
Pas que je sache. Ou alors à la main, en surveillant régulièrement ce que donne "netstat -m" en parallèle avec top...
Sinon j'ai vu dans un message de misc@ que c'est sans doute du à un défaut matériel. La question qui me vient alors à l'esprit est quel est le bidule que je dois changer ?
Cela ressemble aux symptômes d'une fuite de mbuf dans un pilote de carte réseau. Une façon simple de vérifier si c'est le cas consiste à remplacer une à une, chacune des cartes réseau par une carte utilisant un pilote différent (par exemple, remplacer une rl par une xl ou une fxp), et observer si le phénomène se reproduit.
Manuel Sabban
Miod Vallat writes:
Cela ressemble aux symptômes d'une fuite de mbuf dans un pilote de carte réseau. Une façon simple de vérifier si c'est le cas consiste à remplacer une à une, chacune des cartes réseau par une carte utilisant un pilote différent (par exemple, remplacer une rl par une xl ou une fxp), et observer si le phénomène se reproduit.
Tu as l'air de dire que les drivers xl sont "sûrs". Actuellement dans la machine en question, j'ai deux xl. Ça vaut le coup que j'essaie de changer de cartes ? -- Challenge: Time? Answer: A brilliant, many-faceted gem.
Challenge: Time? Answer: A dark stone, reflecting no visible light.
-- Fremen wisdom, from The Riddle Game
Miod Vallat <miod@online.fr> writes:
Cela ressemble aux symptômes d'une fuite de mbuf dans un pilote de carte
réseau. Une façon simple de vérifier si c'est le cas consiste à
remplacer une à une, chacune des cartes réseau par une carte utilisant
un pilote différent (par exemple, remplacer une rl par une xl ou une
fxp), et observer si le phénomène se reproduit.
Tu as l'air de dire que les drivers xl sont "sûrs". Actuellement dans
la machine en question, j'ai deux xl. Ça vaut le coup que j'essaie de
changer de cartes ?
--
Challenge: Time?
Answer: A brilliant, many-faceted gem.
Challenge: Time?
Answer: A dark stone, reflecting no visible light.
Cela ressemble aux symptômes d'une fuite de mbuf dans un pilote de carte réseau. Une façon simple de vérifier si c'est le cas consiste à remplacer une à une, chacune des cartes réseau par une carte utilisant un pilote différent (par exemple, remplacer une rl par une xl ou une fxp), et observer si le phénomène se reproduit.
Tu as l'air de dire que les drivers xl sont "sûrs". Actuellement dans la machine en question, j'ai deux xl. Ça vaut le coup que j'essaie de changer de cartes ? -- Challenge: Time? Answer: A brilliant, many-faceted gem.
Challenge: Time? Answer: A dark stone, reflecting no visible light.
-- Fremen wisdom, from The Riddle Game
Miod Vallat
Tu as l'air de dire que les drivers xl sont "sûrs". Actuellement dans la machine en question, j'ai deux xl. Ça vaut le coup que j'essaie de changer de cartes ?
Euh, je ne dis rien de tel, je donnais juste un exemple de nom. Et justement, le driver xl en 3.6 a des fuites de mbuf sur les 3C905B et 3C905C ; il me semblait que le correctif avait été fait avant 3.6, mais je viens de me rendre compte que non ; et il n'est pas encore dans 3.6-STABLE, je vais donc houspiller la personne en charge de -STABLE de ce pas...
En attendant, mettre à jour src/sys/dev/ic/xl.c en version 1.58 et recompiler un noyau devrait suffire pour éliminer le problème.
Tu as l'air de dire que les drivers xl sont "sûrs". Actuellement dans
la machine en question, j'ai deux xl. Ça vaut le coup que j'essaie de
changer de cartes ?
Euh, je ne dis rien de tel, je donnais juste un exemple de nom. Et
justement, le driver xl en 3.6 a des fuites de mbuf sur les 3C905B et
3C905C ; il me semblait que le correctif avait été fait avant 3.6, mais
je viens de me rendre compte que non ; et il n'est pas encore dans
3.6-STABLE, je vais donc houspiller la personne en charge de -STABLE de
ce pas...
En attendant, mettre à jour src/sys/dev/ic/xl.c en version 1.58 et
recompiler un noyau devrait suffire pour éliminer le problème.
Tu as l'air de dire que les drivers xl sont "sûrs". Actuellement dans la machine en question, j'ai deux xl. Ça vaut le coup que j'essaie de changer de cartes ?
Euh, je ne dis rien de tel, je donnais juste un exemple de nom. Et justement, le driver xl en 3.6 a des fuites de mbuf sur les 3C905B et 3C905C ; il me semblait que le correctif avait été fait avant 3.6, mais je viens de me rendre compte que non ; et il n'est pas encore dans 3.6-STABLE, je vais donc houspiller la personne en charge de -STABLE de ce pas...
En attendant, mettre à jour src/sys/dev/ic/xl.c en version 1.58 et recompiler un noyau devrait suffire pour éliminer le problème.
Vincent Bernat
OoO Lors de la soirée naissante du mercredi 10 novembre 2004, vers 18:05, Miod Vallat disait:
Tu as l'air de dire que les drivers xl sont "sûrs". Actuellement dans la machine en question, j'ai deux xl. Ça vaut le coup que j'essaie de changer de cartes ?
Euh, je ne dis rien de tel, je donnais juste un exemple de nom. Et justement, le driver xl en 3.6 a des fuites de mbuf sur les 3C905B et 3C905C ; il me semblait que le correctif avait été fait avant 3.6, mais je viens de me rendre compte que non ; et il n'est pas encore dans 3.6-STABLE, je vais donc houspiller la personne en charge de -STABLE de ce pas...
C'est possible que ce soit pareil sur une em ? -- panic("huh?n"); 2.2.16 /usr/src/linux/arch/i386/kernel/smp.c
OoO Lors de la soirée naissante du mercredi 10 novembre 2004, vers
18:05, Miod Vallat <miod@online.fr> disait:
Tu as l'air de dire que les drivers xl sont "sûrs". Actuellement dans
la machine en question, j'ai deux xl. Ça vaut le coup que j'essaie de
changer de cartes ?
Euh, je ne dis rien de tel, je donnais juste un exemple de nom. Et
justement, le driver xl en 3.6 a des fuites de mbuf sur les 3C905B et
3C905C ; il me semblait que le correctif avait été fait avant 3.6, mais
je viens de me rendre compte que non ; et il n'est pas encore dans
3.6-STABLE, je vais donc houspiller la personne en charge de -STABLE de
ce pas...
C'est possible que ce soit pareil sur une em ?
--
panic("huh?n");
2.2.16 /usr/src/linux/arch/i386/kernel/smp.c
OoO Lors de la soirée naissante du mercredi 10 novembre 2004, vers 18:05, Miod Vallat disait:
Tu as l'air de dire que les drivers xl sont "sûrs". Actuellement dans la machine en question, j'ai deux xl. Ça vaut le coup que j'essaie de changer de cartes ?
Euh, je ne dis rien de tel, je donnais juste un exemple de nom. Et justement, le driver xl en 3.6 a des fuites de mbuf sur les 3C905B et 3C905C ; il me semblait que le correctif avait été fait avant 3.6, mais je viens de me rendre compte que non ; et il n'est pas encore dans 3.6-STABLE, je vais donc houspiller la personne en charge de -STABLE de ce pas...
C'est possible que ce soit pareil sur une em ? -- panic("huh?n"); 2.2.16 /usr/src/linux/arch/i386/kernel/smp.c
Miod Vallat
C'est possible que ce soit pareil sur une em ?
Oui, c'est possible (au sens «il y a toujours un bug de plus»), mais pour autant que je sache aucune fuite de mbuf n'a été signalée sur em et il n'y a eu aucun changement en ce sens.
C'est possible que ce soit pareil sur une em ?
Oui, c'est possible (au sens «il y a toujours un bug de plus»), mais
pour autant que je sache aucune fuite de mbuf n'a été signalée sur em et
il n'y a eu aucun changement en ce sens.
Oui, c'est possible (au sens «il y a toujours un bug de plus»), mais pour autant que je sache aucune fuite de mbuf n'a été signalée sur em et il n'y a eu aucun changement en ce sens.
Manuel Sabban
Miod Vallat writes:
En attendant, mettre à jour src/sys/dev/ic/xl.c en version 1.58 et recompiler un noyau devrait suffire pour éliminer le problème.
Apparement ça a reglé le problème. Merci beaucoup. -- You carve wounds upon my flesh and write there in salt!
-- Fremen Lament
Miod Vallat <miod@online.fr> writes:
En attendant, mettre à jour src/sys/dev/ic/xl.c en version 1.58 et
recompiler un noyau devrait suffire pour éliminer le problème.
Apparement ça a reglé le problème.
Merci beaucoup.
--
You carve wounds upon my flesh and write there in salt!
En attendant, mettre à jour src/sys/dev/ic/xl.c en version 1.58 et recompiler un noyau devrait suffire pour éliminer le problème.
Apparement ça a reglé le problème. Merci beaucoup. -- You carve wounds upon my flesh and write there in salt!
-- Fremen Lament
Nicolas BERNE
Thus Spoke Miod Vallat :
Tu as l'air de dire que les drivers xl sont "sûrs". Actuellement dans la machine en question, j'ai deux xl. Ça vaut le coup que j'essaie de changer de cartes ?
Euh, je ne dis rien de tel, je donnais juste un exemple de nom. Et justement, le driver xl en 3.6 a des fuites de mbuf sur les 3C905B et 3C905C ; il me semblait que le correctif avait été fait avant 3.6, mais Arg, j'ai justement une 3C905C.
Mais bon, en ce qui me concerne, il ne semble pas y avoir de fuites : netstat -m 20454 mbufs in use: 13320 mbufs allocated to data 7105 mbufs allocated to packet headers 29 mbufs allocated to socket names and addresses 6141/6204/16384 mbuf clusters in use (current/peak/max) 17564 Kbytes allocated to network (99% in use) 0 requests for memory denied 0 requests for memory delayed 1330712 calls to protocol drain routines
je viens de me rendre compte que non ; et il n'est pas encore dans 3.6-STABLE, je vais donc houspiller la personne en charge de -STABLE de ce pas...
En attendant, mettre à jour src/sys/dev/ic/xl.c en version 1.58 et recompiler un noyau devrait suffire pour éliminer le problème. Et comment on fait pour obtenir la version 1.58 juste pour ce fichier ?
A+
-- Nicolas BERNE - mailto:
HTML lesson #42: The only legitimate use of the greatly loathed <BLINK> tag. Schroedinger's Cat is <BLINK>NOT</BLINK> dead.
Thus Spoke Miod Vallat <miod@online.fr>:
Tu as l'air de dire que les drivers xl sont "sûrs". Actuellement dans
la machine en question, j'ai deux xl. Ça vaut le coup que j'essaie de
changer de cartes ?
Euh, je ne dis rien de tel, je donnais juste un exemple de nom. Et
justement, le driver xl en 3.6 a des fuites de mbuf sur les 3C905B et
3C905C ; il me semblait que le correctif avait été fait avant 3.6, mais
Arg, j'ai justement une 3C905C.
Mais bon, en ce qui me concerne, il ne semble pas y avoir de fuites :
netstat -m
20454 mbufs in use:
13320 mbufs allocated to data
7105 mbufs allocated to packet headers
29 mbufs allocated to socket names and addresses
6141/6204/16384 mbuf clusters in use (current/peak/max)
17564 Kbytes allocated to network (99% in use)
0 requests for memory denied
0 requests for memory delayed
1330712 calls to protocol drain routines
je viens de me rendre compte que non ; et il n'est pas encore dans
3.6-STABLE, je vais donc houspiller la personne en charge de -STABLE de
ce pas...
En attendant, mettre à jour src/sys/dev/ic/xl.c en version 1.58 et
recompiler un noyau devrait suffire pour éliminer le problème.
Et comment on fait pour obtenir la version 1.58 juste pour ce fichier ?
A+
--
Nicolas BERNE - mailto:nicolas.berne@wanadoo.fr
HTML lesson #42: The only legitimate use of the greatly loathed <BLINK> tag.
Schroedinger's Cat is <BLINK>NOT</BLINK> dead.
Tu as l'air de dire que les drivers xl sont "sûrs". Actuellement dans la machine en question, j'ai deux xl. Ça vaut le coup que j'essaie de changer de cartes ?
Euh, je ne dis rien de tel, je donnais juste un exemple de nom. Et justement, le driver xl en 3.6 a des fuites de mbuf sur les 3C905B et 3C905C ; il me semblait que le correctif avait été fait avant 3.6, mais Arg, j'ai justement une 3C905C.
Mais bon, en ce qui me concerne, il ne semble pas y avoir de fuites : netstat -m 20454 mbufs in use: 13320 mbufs allocated to data 7105 mbufs allocated to packet headers 29 mbufs allocated to socket names and addresses 6141/6204/16384 mbuf clusters in use (current/peak/max) 17564 Kbytes allocated to network (99% in use) 0 requests for memory denied 0 requests for memory delayed 1330712 calls to protocol drain routines
je viens de me rendre compte que non ; et il n'est pas encore dans 3.6-STABLE, je vais donc houspiller la personne en charge de -STABLE de ce pas...
En attendant, mettre à jour src/sys/dev/ic/xl.c en version 1.58 et recompiler un noyau devrait suffire pour éliminer le problème. Et comment on fait pour obtenir la version 1.58 juste pour ce fichier ?
A+
-- Nicolas BERNE - mailto:
HTML lesson #42: The only legitimate use of the greatly loathed <BLINK> tag. Schroedinger's Cat is <BLINK>NOT</BLINK> dead.
