Sur mon serveur de news (FreeBSD 5.3), j'ai périodiquement des erreurs,
dont le message repris en objet :
| Jan 31 23:49:13 talisker innd: SERVER cant select: No buffer space available
Une autre qui revient fréquemment est la suivante :
| Jan 31 21:27:52 talisker innd: SERVER cant accept RCreader Software caused connection abort
On dirait des problèmes de ressources pour la gestion des connexions
réseau, mais j'aimerais bien réussir à diagnostiquer un peu mieux ce qui
se passe.
Quels outils pourrais-je utiliser pour trouver ce qui cloche, ou,
éventuellement, quelles sont les valeurs que je devrais vérifier et
tuner pour éviter ça ?
Fred
--
Et dans tout le long des courants d'air On voit des amoureux Qui
savent encore changer leurs nerfs En un bouquet délicieux On en aura
des saisons Des torrides et des blèmes Je peux encore garder ton nom
Je peux aussi dire que j'l'aime (Noir Désir, Comme elle vient)
Sur mon serveur de news (FreeBSD 5.3), j'ai périodiquement des erreurs, dont le message repris en objet : | Jan 31 23:49:13 talisker innd: SERVER cant select: No buffer space available
Que dit « netstat -m » ? C'est certainement un problème de mbuf (un buffer utilisé pour le passage des paquets dans la pile IP). Normalement, c'est géré automatiquement en FreeBSD 5, et on n'a pas besoin de s'en occuper.
Une autre qui revient fréquemment est la suivante : | Jan 31 21:27:52 talisker innd: SERVER cant accept RCreader Software caused connection abort
Je ne vois pas ce que ça peut être. C'est une tentative de connexion d'un client ? Ça a l'air spécifique à INN ce truc.
Sur mon serveur de news (FreeBSD 5.3), j'ai périodiquement des erreurs,
dont le message repris en objet :
| Jan 31 23:49:13 talisker innd: SERVER cant select: No buffer space available
Que dit « netstat -m » ? C'est certainement un problème de mbuf (un
buffer utilisé pour le passage des paquets dans la pile IP).
Normalement, c'est géré automatiquement en FreeBSD 5, et on n'a pas
besoin de s'en occuper.
Une autre qui revient fréquemment est la suivante :
| Jan 31 21:27:52 talisker innd: SERVER cant accept RCreader Software caused connection abort
Je ne vois pas ce que ça peut être. C'est une tentative de connexion
d'un client ? Ça a l'air spécifique à INN ce truc.
Sur mon serveur de news (FreeBSD 5.3), j'ai périodiquement des erreurs, dont le message repris en objet : | Jan 31 23:49:13 talisker innd: SERVER cant select: No buffer space available
Que dit « netstat -m » ? C'est certainement un problème de mbuf (un buffer utilisé pour le passage des paquets dans la pile IP). Normalement, c'est géré automatiquement en FreeBSD 5, et on n'a pas besoin de s'en occuper.
Une autre qui revient fréquemment est la suivante : | Jan 31 21:27:52 talisker innd: SERVER cant accept RCreader Software caused connection abort
Je ne vois pas ce que ça peut être. C'est une tentative de connexion d'un client ? Ça a l'air spécifique à INN ce truc.
F. Senault
Sur mon serveur de news (FreeBSD 5.3), j'ai périodiquement des erreurs, dont le message repris en objet : | Jan 31 23:49:13 talisker innd: SERVER cant select: No buffer space available
Que dit « netstat -m » ?
En ce moment :
| 14:11 talisker:~# netstat -m | 466113 mbufs in use | 20939/32768 mbuf clusters in use (current/max) | 0/159/6656 sfbufs in use (current/peak/max) | 158406 KBytes allocated to network | 0 requests for sfbufs denied | 0 requests for sfbufs delayed | 231057 requests for I/O initiated by sendfile | 56623 calls to protocol drain routines
Whoah. Je compare ça à mes autres serveurs du travail, c'est à peu près 100 plus de mbufs en cours d'utilisation que toutes les machines de mon parc réunies. Ca n'a pas vraiment l'air normal...
Il y a un moyen de rectifier le tir sans redémarrer tout ?
(Et ça n'a pas l'air de diminuer.)
Fred -- "I'm not a twit, I am actually a superhero. My quest is to wipe stupidity from the world and, wouldn't you know it? Every time you post, that damn little red phone rings." (Stolen from Ciro, SDM)
Sur mon serveur de news (FreeBSD 5.3), j'ai périodiquement des erreurs,
dont le message repris en objet :
| Jan 31 23:49:13 talisker innd: SERVER cant select: No buffer space available
Que dit « netstat -m » ?
En ce moment :
| 14:11 talisker:~# netstat -m
| 466113 mbufs in use
| 20939/32768 mbuf clusters in use (current/max)
| 0/159/6656 sfbufs in use (current/peak/max)
| 158406 KBytes allocated to network
| 0 requests for sfbufs denied
| 0 requests for sfbufs delayed
| 231057 requests for I/O initiated by sendfile
| 56623 calls to protocol drain routines
Whoah. Je compare ça à mes autres serveurs du travail, c'est à peu près
100 plus de mbufs en cours d'utilisation que toutes les machines de mon
parc réunies. Ca n'a pas vraiment l'air normal...
Il y a un moyen de rectifier le tir sans redémarrer tout ?
(Et ça n'a pas l'air de diminuer.)
Fred
--
"I'm not a twit, I am actually a superhero. My quest is to wipe
stupidity from the world and, wouldn't you know it? Every time you post,
that damn little red phone rings." (Stolen from Ciro, SDM)
Sur mon serveur de news (FreeBSD 5.3), j'ai périodiquement des erreurs, dont le message repris en objet : | Jan 31 23:49:13 talisker innd: SERVER cant select: No buffer space available
Que dit « netstat -m » ?
En ce moment :
| 14:11 talisker:~# netstat -m | 466113 mbufs in use | 20939/32768 mbuf clusters in use (current/max) | 0/159/6656 sfbufs in use (current/peak/max) | 158406 KBytes allocated to network | 0 requests for sfbufs denied | 0 requests for sfbufs delayed | 231057 requests for I/O initiated by sendfile | 56623 calls to protocol drain routines
Whoah. Je compare ça à mes autres serveurs du travail, c'est à peu près 100 plus de mbufs en cours d'utilisation que toutes les machines de mon parc réunies. Ca n'a pas vraiment l'air normal...
Il y a un moyen de rectifier le tir sans redémarrer tout ?
(Et ça n'a pas l'air de diminuer.)
Fred -- "I'm not a twit, I am actually a superhero. My quest is to wipe stupidity from the world and, wouldn't you know it? Every time you post, that damn little red phone rings." (Stolen from Ciro, SDM)
talon
F. Senault wrote:
Hello.
Sur mon serveur de news (FreeBSD 5.3), j'ai périodiquement des erreurs, dont le message repris en objet :
| Jan 31 23:49:13 talisker innd: SERVER cant select: No buffer space available
Ce message est produit par if (errno != EINTR) { syslog(L__ERROR, "%s cant select %m", LogName); dans innd/chan.c Ici LogName est SERVER et %m est le contenu de errno, soit donc "No buffer space available".
Ce qui ne semble pas être un problème de réseau. Select de la libc renvoie à une fonction select dans le noyau dans /sys/kern/sys_generic.c où tu peux voir qu'il alloue un gros buffer avec malloc() pour stocker tous les decripteurs qu'il veut surveiller et d'autres choses. Probablement cette allocation de mémoire échoue parceque tu n'as plus de mémoire.
Une autre qui revient fréquemment est la suivante :
| Jan 31 21:27:52 talisker innd: SERVER cant accept RCreader Software caused connection abort
Ici, c'est dans innd/rc.c /* Get the connection. */ size = sizeof remote; if ((fd = accept(cp->fd, (struct sockaddr *)&remote, &size)) < 0) { if (errno != EWOULDBLOCK && errno != EAGAIN) syslog(L_ERROR, "%s cant accept RCreader %m", LogName); return; } avec LogName= SERVER et errno = Software caused connection abort
Ici il s'agit bien d'un problème réseau, la fonction accept() échoue à accepter une connection sur socket. J'ai déjà eu des messages comme ça à la suite de problèmes de carte réseau, et spécialement sous FreeBSD-5. Il y avait apparemment un bug dans le drivers de fxp qui me causait ça, je n'ai plus revu le problème au moins depuis FreeBSD-6.1.
On dirait des problèmes de ressources pour la gestion des connexions réseau, mais j'aimerais bien réussir à diagnostiquer un peu mieux ce qui se passe.
Quels outils pourrais-je utiliser pour trouver ce qui cloche, ou, éventuellement, quelles sont les valeurs que je devrais vérifier et tuner pour éviter ça ?
Fred
--
Michel TALON
F. Senault <fred@lacave.net> wrote:
Hello.
Sur mon serveur de news (FreeBSD 5.3), j'ai périodiquement des erreurs,
dont le message repris en objet :
| Jan 31 23:49:13 talisker innd: SERVER cant select: No buffer space available
Ce message est produit par
if (errno != EINTR) {
syslog(L__ERROR, "%s cant select %m", LogName);
dans innd/chan.c
Ici LogName est SERVER et %m est le contenu de errno, soit donc
"No buffer space available".
Ce qui ne semble pas être un problème de réseau. Select de la libc
renvoie à une fonction select dans le noyau dans /sys/kern/sys_generic.c
où tu peux voir qu'il alloue un gros buffer avec malloc() pour stocker
tous les decripteurs qu'il veut surveiller et d'autres choses.
Probablement cette allocation de mémoire échoue parceque tu n'as plus de
mémoire.
Une autre qui revient fréquemment est la suivante :
| Jan 31 21:27:52 talisker innd: SERVER cant accept RCreader Software caused connection abort
Ici, c'est dans innd/rc.c
/* Get the connection. */
size = sizeof remote;
if ((fd = accept(cp->fd, (struct sockaddr *)&remote, &size)) < 0) {
if (errno != EWOULDBLOCK && errno != EAGAIN)
syslog(L_ERROR, "%s cant accept RCreader %m", LogName);
return;
}
avec LogName= SERVER et errno = Software caused connection abort
Ici il s'agit bien d'un problème réseau, la fonction accept() échoue à
accepter une connection sur socket. J'ai déjà eu des messages comme ça à
la suite de problèmes de carte réseau, et spécialement sous FreeBSD-5.
Il y avait apparemment un bug dans le drivers de fxp qui me causait ça,
je n'ai plus revu le problème au moins depuis FreeBSD-6.1.
On dirait des problèmes de ressources pour la gestion des connexions
réseau, mais j'aimerais bien réussir à diagnostiquer un peu mieux ce qui
se passe.
Quels outils pourrais-je utiliser pour trouver ce qui cloche, ou,
éventuellement, quelles sont les valeurs que je devrais vérifier et
tuner pour éviter ça ?
Sur mon serveur de news (FreeBSD 5.3), j'ai périodiquement des erreurs, dont le message repris en objet :
| Jan 31 23:49:13 talisker innd: SERVER cant select: No buffer space available
Ce message est produit par if (errno != EINTR) { syslog(L__ERROR, "%s cant select %m", LogName); dans innd/chan.c Ici LogName est SERVER et %m est le contenu de errno, soit donc "No buffer space available".
Ce qui ne semble pas être un problème de réseau. Select de la libc renvoie à une fonction select dans le noyau dans /sys/kern/sys_generic.c où tu peux voir qu'il alloue un gros buffer avec malloc() pour stocker tous les decripteurs qu'il veut surveiller et d'autres choses. Probablement cette allocation de mémoire échoue parceque tu n'as plus de mémoire.
Une autre qui revient fréquemment est la suivante :
| Jan 31 21:27:52 talisker innd: SERVER cant accept RCreader Software caused connection abort
Ici, c'est dans innd/rc.c /* Get the connection. */ size = sizeof remote; if ((fd = accept(cp->fd, (struct sockaddr *)&remote, &size)) < 0) { if (errno != EWOULDBLOCK && errno != EAGAIN) syslog(L_ERROR, "%s cant accept RCreader %m", LogName); return; } avec LogName= SERVER et errno = Software caused connection abort
Ici il s'agit bien d'un problème réseau, la fonction accept() échoue à accepter une connection sur socket. J'ai déjà eu des messages comme ça à la suite de problèmes de carte réseau, et spécialement sous FreeBSD-5. Il y avait apparemment un bug dans le drivers de fxp qui me causait ça, je n'ai plus revu le problème au moins depuis FreeBSD-6.1.
On dirait des problèmes de ressources pour la gestion des connexions réseau, mais j'aimerais bien réussir à diagnostiquer un peu mieux ce qui se passe.
Quels outils pourrais-je utiliser pour trouver ce qui cloche, ou, éventuellement, quelles sont les valeurs que je devrais vérifier et tuner pour éviter ça ?
Fred
--
Michel TALON
F. Senault
Probablement cette allocation de mémoire échoue parceque tu n'as plus de mémoire.
Ici il s'agit bien d'un problème réseau, la fonction accept() échoue à accepter une connection sur socket. J'ai déjà eu des messages comme ça à la suite de problèmes de carte réseau, et spécialement sous FreeBSD-5. Il y avait apparemment un bug dans le drivers de fxp qui me causait ça, je n'ai plus revu le problème au moins depuis FreeBSD-6.1.
Si je dois passer par une réinstall de la machine, je suis un peu dans la mouise (c'est une bécane en colocation).
D'un autre côté, ces problèmes sont _relativement_ récents, par rapport à l'uptime de la machine (un an et une chique).
Fred -- Do you ever get tired of the waiting ? Do you ever get tired of being in there ? Don't worry, nobody lives forever, Nobody lives forever (Pink Floyd, A New Machine, part I)
Probablement cette allocation de mémoire échoue parceque tu n'as plus de
mémoire.
Ici il s'agit bien d'un problème réseau, la fonction accept() échoue à
accepter une connection sur socket. J'ai déjà eu des messages comme ça à
la suite de problèmes de carte réseau, et spécialement sous FreeBSD-5.
Il y avait apparemment un bug dans le drivers de fxp qui me causait ça,
je n'ai plus revu le problème au moins depuis FreeBSD-6.1.
Si je dois passer par une réinstall de la machine, je suis un peu dans
la mouise (c'est une bécane en colocation).
D'un autre côté, ces problèmes sont _relativement_ récents, par rapport
à l'uptime de la machine (un an et une chique).
Fred
--
Do you ever get tired of the waiting ?
Do you ever get tired of being in there ?
Don't worry, nobody lives forever,
Nobody lives forever (Pink Floyd, A New Machine, part I)
Ici il s'agit bien d'un problème réseau, la fonction accept() échoue à accepter une connection sur socket. J'ai déjà eu des messages comme ça à la suite de problèmes de carte réseau, et spécialement sous FreeBSD-5. Il y avait apparemment un bug dans le drivers de fxp qui me causait ça, je n'ai plus revu le problème au moins depuis FreeBSD-6.1.
Si je dois passer par une réinstall de la machine, je suis un peu dans la mouise (c'est une bécane en colocation).
D'un autre côté, ces problèmes sont _relativement_ récents, par rapport à l'uptime de la machine (un an et une chique).
Fred -- Do you ever get tired of the waiting ? Do you ever get tired of being in there ? Don't worry, nobody lives forever, Nobody lives forever (Pink Floyd, A New Machine, part I)
talon
Patrick Lamaizière wrote:
Michel Talon écrivait
Ce qui ne semble pas être un problème de réseau. Select de la libc renvoie à une fonction select dans le noyau dans /sys/kern/sys_generic.c où tu peux voir qu'il alloue un gros buffer avec malloc() pour stocker tous les decripteurs qu'il veut surveiller et d'autres choses. Probablement cette allocation de mémoire échoue parceque tu n'as plus de mémoire.
Je ne pense pas, « No buffer space available » correspond à ENOBUFS et ce n'est utilisé que pour les mbufs. J'ai qu'une 4.11 sous la main, ça a peut- être bougé remarque.
Tu as peut être raison, mais select() peut surveiller toutes sortes de choses, par exemple des pipes pour voir s'il y a quelque chose dedans, ce qui ne concerne en rien le réseau. Quand je regarde l'implémentation dans le noyau, je vois que ça commence par un gros malloc() de 2048 descripteurs plus d'autres variables. Si pour une raison quelconque, les select() se mettent à proliférer on peut imaginer arriver à une limite de mémoire, par processus, ce qui est, je crois, de 512Megs en standard.
et je crois que ça ne peut se modifier que dans le noyau.
--
Michel TALON
Patrick Lamaizière <adresse@est.invalid> wrote:
Michel Talon écrivait
Ce qui ne semble pas être un problème de réseau. Select de la libc
renvoie à une fonction select dans le noyau dans
/sys/kern/sys_generic.c où tu peux voir qu'il alloue un gros buffer
avec malloc() pour stocker tous les decripteurs qu'il veut surveiller
et d'autres choses. Probablement cette allocation de mémoire échoue
parceque tu n'as plus de mémoire.
Je ne pense pas, « No buffer space available » correspond à ENOBUFS et ce
n'est utilisé que pour les mbufs. J'ai qu'une 4.11 sous la main, ça a peut-
être bougé remarque.
Tu as peut être raison, mais select() peut surveiller toutes sortes de
choses, par exemple des pipes pour voir s'il y a quelque chose dedans,
ce qui ne concerne en rien le réseau. Quand je regarde l'implémentation
dans le noyau, je vois que ça commence par un gros malloc() de 2048
descripteurs plus d'autres variables. Si pour une raison quelconque, les
select() se mettent à proliférer on peut imaginer arriver à une limite
de mémoire, par processus, ce qui est, je crois, de 512Megs en
standard.
Ce qui ne semble pas être un problème de réseau. Select de la libc renvoie à une fonction select dans le noyau dans /sys/kern/sys_generic.c où tu peux voir qu'il alloue un gros buffer avec malloc() pour stocker tous les decripteurs qu'il veut surveiller et d'autres choses. Probablement cette allocation de mémoire échoue parceque tu n'as plus de mémoire.
Je ne pense pas, « No buffer space available » correspond à ENOBUFS et ce n'est utilisé que pour les mbufs. J'ai qu'une 4.11 sous la main, ça a peut- être bougé remarque.
Tu as peut être raison, mais select() peut surveiller toutes sortes de choses, par exemple des pipes pour voir s'il y a quelque chose dedans, ce qui ne concerne en rien le réseau. Quand je regarde l'implémentation dans le noyau, je vois que ça commence par un gros malloc() de 2048 descripteurs plus d'autres variables. Si pour une raison quelconque, les select() se mettent à proliférer on peut imaginer arriver à une limite de mémoire, par processus, ce qui est, je crois, de 512Megs en standard.
et je crois que ça ne peut se modifier que dans le noyau.
--
Michel TALON
F. Senault
F. Senault wrote:
Hello.
Sur mon serveur de news (FreeBSD 5.3), j'ai périodiquement des erreurs, dont le message repris en objet :
par ailleurs, et réponse /un peu/ facile : ne serait-il pas possible de
mettre à jour cette machine (5.5 doit être la version à jour sur la branche releng_5 et 6.2 qui vient de sortir *me* semble bien stable)
Le serveur est en colo à 120 bornes d'ici, et il accueille plusieurs dizaines d'utilisateurs. Je travaille sous le grand principe de "if it ain't broke, don't fix it". Et je cherche toujours la solution la plus sûre avant de me lancer dans une opération qui va me coûter une soirée de week-end...
(En plus, il y a toujours le petit stress de savoir si la machine va ou pas redémarrer ; c'est du vieux matos, et elle fonctionne quasi sans interruption depuis des années.)
Mais j'envisage de plus en plus cette solution (l'upgrade se ferait en 6.2, plus que certainement, avec un CD de la 5.5 sous le coude en cas de paille).
Fred -- Je regarde le bleu profond se voiler Parfois, un point lumineux se charge de me rappeler Que je ne suis pas ici pour paresser Et que quelque part on a besoin de moi pour aider (Merzhin, Par delà)
F. Senault wrote:
Hello.
Sur mon serveur de news (FreeBSD 5.3), j'ai périodiquement des erreurs,
dont le message repris en objet :
par ailleurs, et réponse /un peu/ facile : ne serait-il pas possible de
mettre à jour cette machine (5.5 doit être la version à jour sur la branche
releng_5 et 6.2 qui vient de sortir *me* semble bien stable)
Le serveur est en colo à 120 bornes d'ici, et il accueille plusieurs
dizaines d'utilisateurs. Je travaille sous le grand principe de "if it
ain't broke, don't fix it". Et je cherche toujours la solution la plus
sûre avant de me lancer dans une opération qui va me coûter une soirée
de week-end...
(En plus, il y a toujours le petit stress de savoir si la machine va ou
pas redémarrer ; c'est du vieux matos, et elle fonctionne quasi sans
interruption depuis des années.)
Mais j'envisage de plus en plus cette solution (l'upgrade se ferait en
6.2, plus que certainement, avec un CD de la 5.5 sous le coude en cas de
paille).
Fred
--
Je regarde le bleu profond se voiler
Parfois, un point lumineux se charge de me rappeler
Que je ne suis pas ici pour paresser
Et que quelque part on a besoin de moi pour aider (Merzhin, Par delà)
Sur mon serveur de news (FreeBSD 5.3), j'ai périodiquement des erreurs, dont le message repris en objet :
par ailleurs, et réponse /un peu/ facile : ne serait-il pas possible de
mettre à jour cette machine (5.5 doit être la version à jour sur la branche releng_5 et 6.2 qui vient de sortir *me* semble bien stable)
Le serveur est en colo à 120 bornes d'ici, et il accueille plusieurs dizaines d'utilisateurs. Je travaille sous le grand principe de "if it ain't broke, don't fix it". Et je cherche toujours la solution la plus sûre avant de me lancer dans une opération qui va me coûter une soirée de week-end...
(En plus, il y a toujours le petit stress de savoir si la machine va ou pas redémarrer ; c'est du vieux matos, et elle fonctionne quasi sans interruption depuis des années.)
Mais j'envisage de plus en plus cette solution (l'upgrade se ferait en 6.2, plus que certainement, avec un CD de la 5.5 sous le coude en cas de paille).
Fred -- Je regarde le bleu profond se voiler Parfois, un point lumineux se charge de me rappeler Que je ne suis pas ici pour paresser Et que quelque part on a besoin de moi pour aider (Merzhin, Par delà)
talon
F. Senault wrote:
Le serveur est en colo à 120 bornes d'ici, et il accueille plusieurs dizaines d'utilisateurs. Je travaille sous le grand principe de "if it ain't broke, don't fix it". Et je cherche toujours la solution la plus sûre avant de me lancer dans une opération qui va me coûter une soirée de week-end...
Tant que j'y pense, parmi les choses qui ont fait disparaître mes problèmes d'erreurs avec fxp, il y a aussi les choses suivantes. - j'ai recompilé un noyau sans IPV6, je doute que ça joue un rôle, mais qui sait. Toujours est-il qu'avec le noyau non générique il y avait tout de suite beaucoup moins d'erreurs. Avec le noyau générique je ne pouvais pas faire un gros download sans qu'il s'interrompe. - je fais charger le microcode de la carte en utilisant ceci dans rc.conf: ifconfig_fxp0="inet 134.157.10.41 netmask 255.255.255.0 link0" Toujours est-il qu'avec ces mesures et une version récente de FreeBSD je n'ai plus jamais ce phénomène. Pour référence la carte est: fxp0: <Intel 82559 Pro/100 Ethernet> port 0xb400-0xb43f mem 0xeb800000-0xeb800fff,0xeb000000-0xeb0fffff irq 20 at device 12.0 on pci2 J'ai 2 machines avec les mêmes cartes qui avaient exactement le même problème.
--
Michel TALON
F. Senault <fred@lacave.net> wrote:
Le serveur est en colo à 120 bornes d'ici, et il accueille plusieurs
dizaines d'utilisateurs. Je travaille sous le grand principe de "if it
ain't broke, don't fix it". Et je cherche toujours la solution la plus
sûre avant de me lancer dans une opération qui va me coûter une soirée
de week-end...
Tant que j'y pense, parmi les choses qui ont fait disparaître mes
problèmes d'erreurs avec fxp, il y a aussi les choses suivantes.
- j'ai recompilé un noyau sans IPV6, je doute que ça joue un rôle, mais
qui sait. Toujours est-il qu'avec le noyau non générique il y avait
tout de suite beaucoup moins d'erreurs. Avec le noyau générique je ne
pouvais pas faire un gros download sans qu'il s'interrompe.
- je fais charger le microcode de la carte en utilisant ceci dans
rc.conf:
ifconfig_fxp0="inet 134.157.10.41 netmask 255.255.255.0 link0"
Toujours est-il qu'avec ces mesures et une version récente de FreeBSD je
n'ai plus jamais ce phénomène. Pour référence la carte est:
fxp0: <Intel 82559 Pro/100 Ethernet> port 0xb400-0xb43f mem
0xeb800000-0xeb800fff,0xeb000000-0xeb0fffff irq 20 at device 12.0 on
pci2
J'ai 2 machines avec les mêmes cartes qui avaient exactement le même
problème.
Le serveur est en colo à 120 bornes d'ici, et il accueille plusieurs dizaines d'utilisateurs. Je travaille sous le grand principe de "if it ain't broke, don't fix it". Et je cherche toujours la solution la plus sûre avant de me lancer dans une opération qui va me coûter une soirée de week-end...
Tant que j'y pense, parmi les choses qui ont fait disparaître mes problèmes d'erreurs avec fxp, il y a aussi les choses suivantes. - j'ai recompilé un noyau sans IPV6, je doute que ça joue un rôle, mais qui sait. Toujours est-il qu'avec le noyau non générique il y avait tout de suite beaucoup moins d'erreurs. Avec le noyau générique je ne pouvais pas faire un gros download sans qu'il s'interrompe. - je fais charger le microcode de la carte en utilisant ceci dans rc.conf: ifconfig_fxp0="inet 134.157.10.41 netmask 255.255.255.0 link0" Toujours est-il qu'avec ces mesures et une version récente de FreeBSD je n'ai plus jamais ce phénomène. Pour référence la carte est: fxp0: <Intel 82559 Pro/100 Ethernet> port 0xb400-0xb43f mem 0xeb800000-0xeb800fff,0xeb000000-0xeb0fffff irq 20 at device 12.0 on pci2 J'ai 2 machines avec les mêmes cartes qui avaient exactement le même problème.
--
Michel TALON
F. Senault
Thierry Herbelot écrivait
j'avais fait des tests rapides avec un kernel current et un monde 6.x (il y a aussi kris@ qui fait/faisait tourner des "vieux" userlands dans des jails avec un kernel -current).
J'ai cassé mon INN comme ça lors du passage de 5.4 en 6.0. Il s'est crashé deux ou trois jours plus tard avec des "no space left on device". C'est le genre d'appli qu'il vaut mieux recompiler (enfin maintenant je le fais).
Je n'envisage pas le passage sans le portupgrade -af qui va bien, et la recompilation de ma version d'INN.
Au passage, il n'y a personne dans le coin qui aurait une ou deux barrettes de SDRAM Registered ECC en PC133 ? Pas trop cher ?
Fred -- Toujours des fleuves qui remontent Et des vomissures qui me comptent Parmi elles L'or c'est sûr n'est pas loin Cherche bien Des sutures et des points N'y font rien D'où vient cette créature en robe longue Et cette fusée encore oblongue Qui se dresse (Noir Désir, A la longue)
Thierry Herbelot écrivait
j'avais fait des tests rapides avec un kernel current et un monde 6.x
(il y a aussi kris@ qui fait/faisait tourner des "vieux" userlands
dans des jails avec un kernel -current).
J'ai cassé mon INN comme ça lors du passage de 5.4 en 6.0. Il s'est crashé
deux ou trois jours plus tard avec des "no space left on device". C'est le
genre d'appli qu'il vaut mieux recompiler (enfin maintenant je le fais).
Je n'envisage pas le passage sans le portupgrade -af qui va bien, et la
recompilation de ma version d'INN.
Au passage, il n'y a personne dans le coin qui aurait une ou deux
barrettes de SDRAM Registered ECC en PC133 ? Pas trop cher ?
Fred
--
Toujours des fleuves qui remontent Et des vomissures qui me comptent
Parmi elles L'or c'est sûr n'est pas loin Cherche bien Des sutures
et des points N'y font rien D'où vient cette créature en robe longue
Et cette fusée encore oblongue Qui se dresse (Noir Désir, A la longue)
j'avais fait des tests rapides avec un kernel current et un monde 6.x (il y a aussi kris@ qui fait/faisait tourner des "vieux" userlands dans des jails avec un kernel -current).
J'ai cassé mon INN comme ça lors du passage de 5.4 en 6.0. Il s'est crashé deux ou trois jours plus tard avec des "no space left on device". C'est le genre d'appli qu'il vaut mieux recompiler (enfin maintenant je le fais).
Je n'envisage pas le passage sans le portupgrade -af qui va bien, et la recompilation de ma version d'INN.
Au passage, il n'y a personne dans le coin qui aurait une ou deux barrettes de SDRAM Registered ECC en PC133 ? Pas trop cher ?
Fred -- Toujours des fleuves qui remontent Et des vomissures qui me comptent Parmi elles L'or c'est sûr n'est pas loin Cherche bien Des sutures et des points N'y font rien D'où vient cette créature en robe longue Et cette fusée encore oblongue Qui se dresse (Noir Désir, A la longue)
Marwan Burelle
On Thu, 1 Feb 2007 16:23:00 +0000 (UTC) (Michel Talon) wrote:
et je crois que ça ne peut se modifier que dans le noyau.
Hum ... non à priori, root peut, via setrlimit(2), changer la limite max (hard limit) tout autant que la limite courante (soft limite.)
En théorie en processus a droit à la totalité de l'espace d'adressage soit 2^(sizeof (size_t)) octets.
-- BOFH excuse #240:
Too many little pins on CPU confusing it, bend back and forth until 10-20% are neatly removed. Do _not_ leave metal bits visible!
On Thu, 1 Feb 2007 16:23:00 +0000 (UTC)
talon@lpthe.jussieu.fr (Michel Talon) wrote:
et je crois que ça ne peut se modifier que dans le noyau.
Hum ... non à priori, root peut, via setrlimit(2), changer la limite
max (hard limit) tout autant que la limite courante (soft limite.)
En théorie en processus a droit à la totalité de l'espace d'adressage
soit 2^(sizeof (size_t)) octets.
--
BOFH excuse #240:
Too many little pins on CPU confusing it, bend back and forth until
10-20% are neatly removed. Do _not_ leave metal bits visible!
La lecture de /usr/src/sys/conf/NOTES permet de découvrir ceci: # The options in /boot/loader.conf override anything in the kernel # configuration file. See the function init_param1 in # sys/kern/subr_param.c for more details. #
La lecture de /usr/src/sys/conf/NOTES permet de découvrir ceci:
# The options in /boot/loader.conf override anything in the kernel
# configuration file. See the function init_param1 in
# sys/kern/subr_param.c for more details.
#
La lecture de /usr/src/sys/conf/NOTES permet de découvrir ceci: # The options in /boot/loader.conf override anything in the kernel # configuration file. See the function init_param1 in # sys/kern/subr_param.c for more details. #
