Je suis confronté à un petit problème avec une sparc64 qui tourne
sous Debian/squeeze. Sa configuration est spéciale (routeur) et je
compile un noyau avec ce qu'il faut en dur. J'ai donc recompilé un
2.6.28, puis un 2.6.28.7 officiel. Je m'aperçois que tcpdump ne
fonctionne plus. Idem pour iftop. Pourtant, les informations sont bien
dans :
J'avoue ne pas savoir par où chercher. Une idée ? Je n'ai pou
l'instant pas trouvé d'information pertinente (mais ceci étant dit, les
cartes réseau fonctionnent bien).
Cordialement,
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Pascal Hambourg
Salut,
JKB a écrit :
Je suis confronté à un petit problème avec une sparc64 qui tourne sous Debian/squeeze. Sa configuration est spéciale (routeur) et je compile un noyau avec ce qu'il faut en dur. J'ai donc recompilé un 2.6.28, puis un 2.6.28.7 officiel.
Pourquoi pas un 2.6.26 à partir des sources du noyau Debian ?
Je m'aperçois que tcpdump ne fonctionne plus. Idem pour iftop.
Mais encore ?
Salut,
JKB a écrit :
Je suis confronté à un petit problème avec une sparc64 qui tourne
sous Debian/squeeze. Sa configuration est spéciale (routeur) et je
compile un noyau avec ce qu'il faut en dur. J'ai donc recompilé un
2.6.28, puis un 2.6.28.7 officiel.
Pourquoi pas un 2.6.26 à partir des sources du noyau Debian ?
Je m'aperçois que tcpdump ne fonctionne plus. Idem pour iftop.
Je suis confronté à un petit problème avec une sparc64 qui tourne sous Debian/squeeze. Sa configuration est spéciale (routeur) et je compile un noyau avec ce qu'il faut en dur. J'ai donc recompilé un 2.6.28, puis un 2.6.28.7 officiel.
Pourquoi pas un 2.6.26 à partir des sources du noyau Debian ?
Je m'aperçois que tcpdump ne fonctionne plus. Idem pour iftop.
Mais encore ?
JKB
Le 17-03-2009, ? propos de Re: Linux 2.6.28 et réseau, Pascal Hambourg ?crivait dans fr.comp.os.linux.configuration :
Salut,
JKB a écrit :
Je suis confronté à un petit problème avec une sparc64 qui tourne sous Debian/squeeze. Sa configuration est spéciale (routeur) et je compile un noyau avec ce qu'il faut en dur. J'ai donc recompilé un 2.6.28, puis un 2.6.28.7 officiel.
Pourquoi pas un 2.6.26 à partir des sources du noyau Debian ?
Pour une sombre histoire de netdev watchdog error dont le patch pour les noyaux pre 2.6.27 est à la limite du patch foireux...
Je m'aperçois que tcpdump ne fonctionne plus. Idem pour iftop.
Mais encore ?
Root rayleigh:[~] > tcpdump -i eth1 -vv tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes ^C 0 packets captured 63 packets received by filter 0 packets dropped by kernel Root rayleigh:[~] >
Rien... iftop reste à zéro. Je m'en suis aperçu parce que p0f occupait 100% d'un processeur de la bête.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Le 17-03-2009, ? propos de
Re: Linux 2.6.28 et réseau,
Pascal Hambourg ?crivait dans fr.comp.os.linux.configuration :
Salut,
JKB a écrit :
Je suis confronté à un petit problème avec une sparc64 qui tourne
sous Debian/squeeze. Sa configuration est spéciale (routeur) et je
compile un noyau avec ce qu'il faut en dur. J'ai donc recompilé un
2.6.28, puis un 2.6.28.7 officiel.
Pourquoi pas un 2.6.26 à partir des sources du noyau Debian ?
Pour une sombre histoire de netdev watchdog error dont le patch pour
les noyaux pre 2.6.27 est à la limite du patch foireux...
Je m'aperçois que tcpdump ne fonctionne plus. Idem pour iftop.
Mais encore ?
Root rayleigh:[~] > tcpdump -i eth1 -vv
tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
^C
0 packets captured
63 packets received by filter
0 packets dropped by kernel
Root rayleigh:[~] >
Rien... iftop reste à zéro. Je m'en suis aperçu parce que p0f
occupait 100% d'un processeur de la bête.
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Le 17-03-2009, ? propos de Re: Linux 2.6.28 et réseau, Pascal Hambourg ?crivait dans fr.comp.os.linux.configuration :
Salut,
JKB a écrit :
Je suis confronté à un petit problème avec une sparc64 qui tourne sous Debian/squeeze. Sa configuration est spéciale (routeur) et je compile un noyau avec ce qu'il faut en dur. J'ai donc recompilé un 2.6.28, puis un 2.6.28.7 officiel.
Pourquoi pas un 2.6.26 à partir des sources du noyau Debian ?
Pour une sombre histoire de netdev watchdog error dont le patch pour les noyaux pre 2.6.27 est à la limite du patch foireux...
Je m'aperçois que tcpdump ne fonctionne plus. Idem pour iftop.
Mais encore ?
Root rayleigh:[~] > tcpdump -i eth1 -vv tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes ^C 0 packets captured 63 packets received by filter 0 packets dropped by kernel Root rayleigh:[~] >
Rien... iftop reste à zéro. Je m'en suis aperçu parce que p0f occupait 100% d'un processeur de la bête.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Pascal Hambourg
JKB a écrit :
Je m'aperçois que tcpdump ne fonctionne plus. Idem pour iftop.
Mais encore ?
Root rayleigh:[~] > tcpdump -i eth1 -vv tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes ^C 0 packets captured 63 packets received by filter 0 packets dropped by kernel Root rayleigh:[~] >
Pourtant il indique avoir reçu 63 paquets... Question subsidiaire : tu as écrit "ne marche plus", donc j'en déduis que ça marchait avant. Dans quelle configuration ?
JKB a écrit :
Je m'aperçois que tcpdump ne fonctionne plus. Idem pour iftop.
Mais encore ?
Root rayleigh:[~] > tcpdump -i eth1 -vv
tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
^C
0 packets captured
63 packets received by filter
0 packets dropped by kernel
Root rayleigh:[~] >
Pourtant il indique avoir reçu 63 paquets...
Question subsidiaire : tu as écrit "ne marche plus", donc j'en déduis
que ça marchait avant. Dans quelle configuration ?
Je m'aperçois que tcpdump ne fonctionne plus. Idem pour iftop.
Mais encore ?
Root rayleigh:[~] > tcpdump -i eth1 -vv tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes ^C 0 packets captured 63 packets received by filter 0 packets dropped by kernel Root rayleigh:[~] >
Pourtant il indique avoir reçu 63 paquets... Question subsidiaire : tu as écrit "ne marche plus", donc j'en déduis que ça marchait avant. Dans quelle configuration ?
JKB
Le 17-03-2009, ? propos de Re: Linux 2.6.28 et réseau, Pascal Hambourg ?crivait dans fr.comp.os.linux.configuration :
JKB a écrit :
Je m'aperçois que tcpdump ne fonctionne plus. Idem pour iftop.
Mais encore ?
Root rayleigh:[~] > tcpdump -i eth1 -vv tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes ^C 0 packets captured 63 packets received by filter 0 packets dropped by kernel Root rayleigh:[~] >
Pourtant il indique avoir reçu 63 paquets...
Certes. Mais aucune trace.
Question subsidiaire : tu as écrit "ne marche plus", donc j'en déduis que ça marchait avant. Dans quelle configuration ?
Cette machine est régulièrement mise à jour. J'ai néanmoins l'impression que ça correspond au passage du 2.6.27 au 2.6.28 (je ne peux pas retourner au 2.6.27 pour faire des tests, la machine est en production et il est hors de question de la rebooter).
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Le 17-03-2009, ? propos de
Re: Linux 2.6.28 et réseau,
Pascal Hambourg ?crivait dans fr.comp.os.linux.configuration :
JKB a écrit :
Je m'aperçois que tcpdump ne fonctionne plus. Idem pour iftop.
Mais encore ?
Root rayleigh:[~] > tcpdump -i eth1 -vv
tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
^C
0 packets captured
63 packets received by filter
0 packets dropped by kernel
Root rayleigh:[~] >
Pourtant il indique avoir reçu 63 paquets...
Certes. Mais aucune trace.
Question subsidiaire : tu as écrit "ne marche plus", donc j'en déduis
que ça marchait avant. Dans quelle configuration ?
Cette machine est régulièrement mise à jour. J'ai néanmoins
l'impression que ça correspond au passage du 2.6.27 au 2.6.28 (je ne
peux pas retourner au 2.6.27 pour faire des tests, la machine est en
production et il est hors de question de la rebooter).
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Le 17-03-2009, ? propos de Re: Linux 2.6.28 et réseau, Pascal Hambourg ?crivait dans fr.comp.os.linux.configuration :
JKB a écrit :
Je m'aperçois que tcpdump ne fonctionne plus. Idem pour iftop.
Mais encore ?
Root rayleigh:[~] > tcpdump -i eth1 -vv tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes ^C 0 packets captured 63 packets received by filter 0 packets dropped by kernel Root rayleigh:[~] >
Pourtant il indique avoir reçu 63 paquets...
Certes. Mais aucune trace.
Question subsidiaire : tu as écrit "ne marche plus", donc j'en déduis que ça marchait avant. Dans quelle configuration ?
Cette machine est régulièrement mise à jour. J'ai néanmoins l'impression que ça correspond au passage du 2.6.27 au 2.6.28 (je ne peux pas retourner au 2.6.27 pour faire des tests, la machine est en production et il est hors de question de la rebooter).
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
JKB
Le 17-03-2009, ? propos de Linux 2.6.28 et réseau, JKB ?crivait dans fr.comp.os.linux.configuration :
Bonjour à tous,
Je suis confronté à un petit problème avec une sparc64 qui tourne sous Debian/squeeze. Sa configuration est spéciale (routeur) et je compile un noyau avec ce qu'il faut en dur. J'ai donc recompilé un 2.6.28, puis un 2.6.28.7 officiel. Je m'aperçois que tcpdump ne fonctionne plus. Idem pour iftop. Pourtant, les informations sont bien dans :
J'avoue ne pas savoir par où chercher. Une idée ? Je n'ai pou l'instant pas trouvé d'information pertinente (mais ceci étant dit, les cartes réseau fonctionnent bien).
Suite du problème... Je viens de tester sur une U1 (sparc64) avec un 2.6.28.7, même motif, même punition. Un amd64 se comporte bien. Le bug semble donc lié à l'architecture sparc64.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Le 17-03-2009, ? propos de
Linux 2.6.28 et réseau,
JKB ?crivait dans fr.comp.os.linux.configuration :
Bonjour à tous,
Je suis confronté à un petit problème avec une sparc64 qui tourne
sous Debian/squeeze. Sa configuration est spéciale (routeur) et je
compile un noyau avec ce qu'il faut en dur. J'ai donc recompilé un
2.6.28, puis un 2.6.28.7 officiel. Je m'aperçois que tcpdump ne
fonctionne plus. Idem pour iftop. Pourtant, les informations sont bien
dans :
J'avoue ne pas savoir par où chercher. Une idée ? Je n'ai pou
l'instant pas trouvé d'information pertinente (mais ceci étant dit, les
cartes réseau fonctionnent bien).
Suite du problème... Je viens de tester sur une U1 (sparc64) avec un
2.6.28.7, même motif, même punition. Un amd64 se comporte bien. Le bug
semble donc lié à l'architecture sparc64.
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Le 17-03-2009, ? propos de Linux 2.6.28 et réseau, JKB ?crivait dans fr.comp.os.linux.configuration :
Bonjour à tous,
Je suis confronté à un petit problème avec une sparc64 qui tourne sous Debian/squeeze. Sa configuration est spéciale (routeur) et je compile un noyau avec ce qu'il faut en dur. J'ai donc recompilé un 2.6.28, puis un 2.6.28.7 officiel. Je m'aperçois que tcpdump ne fonctionne plus. Idem pour iftop. Pourtant, les informations sont bien dans :
J'avoue ne pas savoir par où chercher. Une idée ? Je n'ai pou l'instant pas trouvé d'information pertinente (mais ceci étant dit, les cartes réseau fonctionnent bien).
Suite du problème... Je viens de tester sur une U1 (sparc64) avec un 2.6.28.7, même motif, même punition. Un amd64 se comporte bien. Le bug semble donc lié à l'architecture sparc64.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Pascal Hambourg
JKB a écrit :
Suite du problème... Je viens de tester sur une U1 (sparc64) avec un 2.6.28.7, même motif, même punition.
Et avec un noyau 2.6.27.* ?
Un amd64 se comporte bien.
Ça ne m'étonne pas beaucoup, je pense qu'un bug aussi gros se serait vu sur les architectures les plus populaires.
Le bug semble donc lié à l'architecture sparc64.
Peut-être un bug lié au boutisme ou à la taille de types de données (j'ai cru comprendre que l'architecture sparc de Debian utilise un noyau 64 bits mais des applications userland 32 bits).
Ou bien ça pourrait être lié au pilote de l'interface ethernet. As-tu testé avec d'autres types d'interface réseau (loopback, dummy, PPP, tunnel IPIP, TUN/TAP...) ?
JKB a écrit :
Suite du problème... Je viens de tester sur une U1 (sparc64) avec un
2.6.28.7, même motif, même punition.
Et avec un noyau 2.6.27.* ?
Un amd64 se comporte bien.
Ça ne m'étonne pas beaucoup, je pense qu'un bug aussi gros se serait vu
sur les architectures les plus populaires.
Le bug semble donc lié à l'architecture sparc64.
Peut-être un bug lié au boutisme ou à la taille de types de données
(j'ai cru comprendre que l'architecture sparc de Debian utilise un noyau
64 bits mais des applications userland 32 bits).
Ou bien ça pourrait être lié au pilote de l'interface ethernet. As-tu
testé avec d'autres types d'interface réseau (loopback, dummy, PPP,
tunnel IPIP, TUN/TAP...) ?
Suite du problème... Je viens de tester sur une U1 (sparc64) avec un 2.6.28.7, même motif, même punition.
Et avec un noyau 2.6.27.* ?
Un amd64 se comporte bien.
Ça ne m'étonne pas beaucoup, je pense qu'un bug aussi gros se serait vu sur les architectures les plus populaires.
Le bug semble donc lié à l'architecture sparc64.
Peut-être un bug lié au boutisme ou à la taille de types de données (j'ai cru comprendre que l'architecture sparc de Debian utilise un noyau 64 bits mais des applications userland 32 bits).
Ou bien ça pourrait être lié au pilote de l'interface ethernet. As-tu testé avec d'autres types d'interface réseau (loopback, dummy, PPP, tunnel IPIP, TUN/TAP...) ?
JKB
Le 19-03-2009, ? propos de Re: Linux 2.6.28 et réseau, Pascal Hambourg ?crivait dans fr.comp.os.linux.configuration :
JKB a écrit :
Suite du problème... Je viens de tester sur une U1 (sparc64) avec un 2.6.28.7, même motif, même punition.
Et avec un noyau 2.6.27.* ?
De mémoire, ça fonctionnait (mais je ne peux pas tester là, tout de suite).
Un amd64 se comporte bien.
Ça ne m'étonne pas beaucoup, je pense qu'un bug aussi gros se serait vu sur les architectures les plus populaires.
Le bug semble donc lié à l'architecture sparc64.
Peut-être un bug lié au boutisme ou à la taille de types de données (j'ai cru comprendre que l'architecture sparc de Debian utilise un noyau 64 bits mais des applications userland 32 bits).
Oui, comme toutes les OS standard sur cette architecture. On peut compiler en 64 bits, mais c'est un tantinet plus lent.
Ou bien ça pourrait être lié au pilote de l'interface ethernet. As-tu testé avec d'autres types d'interface réseau (loopback, dummy, PPP, tunnel IPIP, TUN/TAP...) ?
Non, seulement avec l'interface Ethernet basique (mais plusieurs pilotes). Et je n'ai pas l'occasion de tester rapidement avec autre chose.
Cordialement,
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Le 19-03-2009, ? propos de
Re: Linux 2.6.28 et réseau,
Pascal Hambourg ?crivait dans fr.comp.os.linux.configuration :
JKB a écrit :
Suite du problème... Je viens de tester sur une U1 (sparc64) avec un
2.6.28.7, même motif, même punition.
Et avec un noyau 2.6.27.* ?
De mémoire, ça fonctionnait (mais je ne peux pas tester là, tout de
suite).
Un amd64 se comporte bien.
Ça ne m'étonne pas beaucoup, je pense qu'un bug aussi gros se serait vu
sur les architectures les plus populaires.
Le bug semble donc lié à l'architecture sparc64.
Peut-être un bug lié au boutisme ou à la taille de types de données
(j'ai cru comprendre que l'architecture sparc de Debian utilise un noyau
64 bits mais des applications userland 32 bits).
Oui, comme toutes les OS standard sur cette architecture. On peut
compiler en 64 bits, mais c'est un tantinet plus lent.
Ou bien ça pourrait être lié au pilote de l'interface ethernet. As-tu
testé avec d'autres types d'interface réseau (loopback, dummy, PPP,
tunnel IPIP, TUN/TAP...) ?
Non, seulement avec l'interface Ethernet basique (mais plusieurs
pilotes). Et je n'ai pas l'occasion de tester rapidement avec autre
chose.
Cordialement,
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Le 19-03-2009, ? propos de Re: Linux 2.6.28 et réseau, Pascal Hambourg ?crivait dans fr.comp.os.linux.configuration :
JKB a écrit :
Suite du problème... Je viens de tester sur une U1 (sparc64) avec un 2.6.28.7, même motif, même punition.
Et avec un noyau 2.6.27.* ?
De mémoire, ça fonctionnait (mais je ne peux pas tester là, tout de suite).
Un amd64 se comporte bien.
Ça ne m'étonne pas beaucoup, je pense qu'un bug aussi gros se serait vu sur les architectures les plus populaires.
Le bug semble donc lié à l'architecture sparc64.
Peut-être un bug lié au boutisme ou à la taille de types de données (j'ai cru comprendre que l'architecture sparc de Debian utilise un noyau 64 bits mais des applications userland 32 bits).
Oui, comme toutes les OS standard sur cette architecture. On peut compiler en 64 bits, mais c'est un tantinet plus lent.
Ou bien ça pourrait être lié au pilote de l'interface ethernet. As-tu testé avec d'autres types d'interface réseau (loopback, dummy, PPP, tunnel IPIP, TUN/TAP...) ?
Non, seulement avec l'interface Ethernet basique (mais plusieurs pilotes). Et je n'ai pas l'occasion de tester rapidement avec autre chose.
Cordialement,
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
