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
Fred
Je pense que c'est une erreur due à une non- confirmation des signaux ACK en TCP/IP . Tu devrais essayer de rallonger le timeout du watchdog avec un paramétrage plus long sur l'interface eth0 avec ifconfig , je pense. Ce genre de panne est effectivement souvent d'origine matérielle ...
Hello,
j'ai de temps en temps une "desactivation" de mon interface ethernet eth0 avec dans les logs:
NETDEV WATCHDOG: eth0: transmit timed out NETDEV WATCHDOG: eth0: transmit timed out NETDEV WATCHDOG: eth0: transmit timed out NETDEV WATCHDOG: eth0: transmit timed out NETDEV WATCHDOG: eth0: transmit timed out NETDEV WATCHDOG: eth0: transmit timed out NETDEV WATCHDOG: eth0: transmit timed out
pour la relancer, obliger de faire ifdown et ifup eth0 ... les autres interfaces ne sont pas touches,
une idee du probleme ? carte reseau defecteuse ?
a+
Je pense que c'est une erreur due à une non-
confirmation des signaux ACK en TCP/IP .
Tu devrais essayer de rallonger le
timeout du watchdog avec un paramétrage plus
long sur l'interface eth0 avec ifconfig , je pense.
Ce genre de panne est effectivement souvent d'origine matérielle ...
Hello,
j'ai de temps en temps une "desactivation" de mon interface ethernet
eth0 avec dans les logs:
NETDEV WATCHDOG: eth0: transmit timed out
NETDEV WATCHDOG: eth0: transmit timed out
NETDEV WATCHDOG: eth0: transmit timed out
NETDEV WATCHDOG: eth0: transmit timed out
NETDEV WATCHDOG: eth0: transmit timed out
NETDEV WATCHDOG: eth0: transmit timed out
NETDEV WATCHDOG: eth0: transmit timed out
pour la relancer, obliger de faire ifdown et ifup eth0 ...
les autres interfaces ne sont pas touches,
Je pense que c'est une erreur due à une non- confirmation des signaux ACK en TCP/IP . Tu devrais essayer de rallonger le timeout du watchdog avec un paramétrage plus long sur l'interface eth0 avec ifconfig , je pense. Ce genre de panne est effectivement souvent d'origine matérielle ...
Hello,
j'ai de temps en temps une "desactivation" de mon interface ethernet eth0 avec dans les logs:
NETDEV WATCHDOG: eth0: transmit timed out NETDEV WATCHDOG: eth0: transmit timed out NETDEV WATCHDOG: eth0: transmit timed out NETDEV WATCHDOG: eth0: transmit timed out NETDEV WATCHDOG: eth0: transmit timed out NETDEV WATCHDOG: eth0: transmit timed out NETDEV WATCHDOG: eth0: transmit timed out
pour la relancer, obliger de faire ifdown et ifup eth0 ... les autres interfaces ne sont pas touches,
une idee du probleme ? carte reseau defecteuse ?
a+
Pascal
Salut,
j'ai de temps en temps une "desactivation" de mon interface ethernet eth0 avec dans les logs:
NETDEV WATCHDOG: eth0: transmit timed out
Je pense que c'est une erreur due à une non- confirmation des signaux ACK en TCP/IP .
Pas d'accord. Je ne vois pas comment une erreur au niveau TCP pourrait provoquer un time-out à l'émission et une désactivation de l'interface ethernet.
PS: pour une meilleure lisibilité, merci de répondre après le texte cité.
Salut,
j'ai de temps en temps une "desactivation" de mon interface ethernet
eth0 avec dans les logs:
NETDEV WATCHDOG: eth0: transmit timed out
Je pense que c'est une erreur due à une non-
confirmation des signaux ACK en TCP/IP .
Pas d'accord. Je ne vois pas comment une erreur au niveau TCP pourrait
provoquer un time-out à l'émission et une désactivation de l'interface
ethernet.
PS: pour une meilleure lisibilité, merci de répondre après le texte cité.
j'ai de temps en temps une "desactivation" de mon interface ethernet eth0 avec dans les logs:
NETDEV WATCHDOG: eth0: transmit timed out
Je pense que c'est une erreur due à une non- confirmation des signaux ACK en TCP/IP .
Pas d'accord. Je ne vois pas comment une erreur au niveau TCP pourrait provoquer un time-out à l'émission et une désactivation de l'interface ethernet.
PS: pour une meilleure lisibilité, merci de répondre après le texte cité.
l'indien
On Fri, 03 Jun 2005 11:50:54 +0200, Fred wrote:
Je pense que c'est une erreur due à une non- confirmation des signaux ACK en TCP/IP . Tu devrais essayer de rallonger le timeout du watchdog avec un paramétrage plus long sur l'interface eth0 avec ifconfig , je pense. Ce genre de panne est effectivement souvent d'origine matérielle ...
Ce n'est pas un problème TCP, mais un problème du driver. Le mesage provient du système de watchdog interne de la couche qui gère les envois de paquets au niveau ethernet. Ce qu'il se passe, c'est que cette couche a transmis un paquet au driver ethernet et ne reçoit jamais la confirmation que le paquet est effectivement perdue. En général, ce qui se passe c'est que le paquet ethernet est transmis au hardware ethernet et on lui demande de générer une interruption quand la transmission du paquet sera finie. Si cette interruption n'arrive pas dans un temps "raisonable", on a le message en question et la couche réseau de Linux tente de renvoyer le paquet en erreur. La cause de l'erreur peut être multiple: - il y a des interruptions perdues. C'est toujours possible, notement si un autre driver passe beaucoup de temps dans son handler d'interruptions. Avec un CPU rapide (c.a.d > 300 ou 400 Mhz), c'est très peu probable. - très probablement, il y a une erreur au niveau de l'interface physique ethernet (le PHY) qui est mal gérée dans le driver. Je pense que le problème vient de là, car dans ce cas, le fait de faire ifdown puis ifup remettra effectivement le PHY en état de marche. En effet, ifdown appelle un "close" de l'interface ethernet et ifup fait ensuite un "open". Or, généralement le "open" d'une interface ethernet fait une réinitialisation complète du PHY. - autre possibilité: le chip ethernet est en erreur et le driver oublie de traiter celle-ci. C'est une possibilité, dans le cas ou le "open" de ce driver réinitialise effectivement tout le chip ethernet (et pas seulement le PHY).
Donc, 2 solutions: - tenter de débugger le driver - envoyer un rapport de bug au mainteneur du driver (dont l'addresse mail est dans /usr/src/linux/MAINTAINERS ou dans les sources de celui-ci).
Hello,
j'ai de temps en temps une "desactivation" de mon interface ethernet eth0 avec dans les logs:
NETDEV WATCHDOG: eth0: transmit timed out NETDEV WATCHDOG: eth0: transmit timed out NETDEV WATCHDOG: eth0: transmit timed out NETDEV WATCHDOG: eth0: transmit timed out NETDEV WATCHDOG: eth0: transmit timed out NETDEV WATCHDOG: eth0: transmit timed out NETDEV WATCHDOG: eth0: transmit timed out
pour la relancer, obliger de faire ifdown et ifup eth0 ... les autres interfaces ne sont pas touches,
une idee du probleme ? carte reseau defecteuse ?
a+
On Fri, 03 Jun 2005 11:50:54 +0200, Fred wrote:
Je pense que c'est une erreur due à une non-
confirmation des signaux ACK en TCP/IP .
Tu devrais essayer de rallonger le
timeout du watchdog avec un paramétrage plus
long sur l'interface eth0 avec ifconfig , je pense.
Ce genre de panne est effectivement souvent d'origine matérielle ...
Ce n'est pas un problème TCP, mais un problème du driver.
Le mesage provient du système de watchdog interne de la couche qui gère
les envois de paquets au niveau ethernet.
Ce qu'il se passe, c'est que cette couche a transmis un paquet au driver
ethernet et ne reçoit jamais la confirmation que le paquet est
effectivement perdue. En général, ce qui se passe c'est que le paquet
ethernet est transmis au hardware ethernet et on lui demande de générer
une interruption quand la transmission du paquet sera finie.
Si cette interruption n'arrive pas dans un temps "raisonable", on a le
message en question et la couche réseau de Linux tente de renvoyer le
paquet en erreur.
La cause de l'erreur peut être multiple:
- il y a des interruptions perdues. C'est toujours possible, notement
si un autre driver passe beaucoup de temps dans son handler
d'interruptions. Avec un CPU rapide (c.a.d > 300 ou 400 Mhz), c'est
très peu probable.
- très probablement, il y a une erreur au niveau de l'interface physique
ethernet (le PHY) qui est mal gérée dans le driver. Je pense que le
problème vient de là, car dans ce cas, le fait de faire ifdown puis ifup
remettra effectivement le PHY en état de marche. En effet, ifdown appelle
un "close" de l'interface ethernet et ifup fait ensuite un "open". Or,
généralement le "open" d'une interface ethernet fait une
réinitialisation complète du PHY.
- autre possibilité: le chip ethernet est en erreur et le driver oublie
de traiter celle-ci. C'est une possibilité, dans le cas ou le "open" de
ce driver réinitialise effectivement tout le chip ethernet (et pas
seulement le PHY).
Donc, 2 solutions:
- tenter de débugger le driver
- envoyer un rapport de bug au mainteneur du driver (dont l'addresse mail
est dans /usr/src/linux/MAINTAINERS ou dans les sources de celui-ci).
Hello,
j'ai de temps en temps une "desactivation" de mon interface ethernet
eth0 avec dans les logs:
NETDEV WATCHDOG: eth0: transmit timed out
NETDEV WATCHDOG: eth0: transmit timed out
NETDEV WATCHDOG: eth0: transmit timed out
NETDEV WATCHDOG: eth0: transmit timed out
NETDEV WATCHDOG: eth0: transmit timed out
NETDEV WATCHDOG: eth0: transmit timed out
NETDEV WATCHDOG: eth0: transmit timed out
pour la relancer, obliger de faire ifdown et ifup eth0 ...
les autres interfaces ne sont pas touches,
Je pense que c'est une erreur due à une non- confirmation des signaux ACK en TCP/IP . Tu devrais essayer de rallonger le timeout du watchdog avec un paramétrage plus long sur l'interface eth0 avec ifconfig , je pense. Ce genre de panne est effectivement souvent d'origine matérielle ...
Ce n'est pas un problème TCP, mais un problème du driver. Le mesage provient du système de watchdog interne de la couche qui gère les envois de paquets au niveau ethernet. Ce qu'il se passe, c'est que cette couche a transmis un paquet au driver ethernet et ne reçoit jamais la confirmation que le paquet est effectivement perdue. En général, ce qui se passe c'est que le paquet ethernet est transmis au hardware ethernet et on lui demande de générer une interruption quand la transmission du paquet sera finie. Si cette interruption n'arrive pas dans un temps "raisonable", on a le message en question et la couche réseau de Linux tente de renvoyer le paquet en erreur. La cause de l'erreur peut être multiple: - il y a des interruptions perdues. C'est toujours possible, notement si un autre driver passe beaucoup de temps dans son handler d'interruptions. Avec un CPU rapide (c.a.d > 300 ou 400 Mhz), c'est très peu probable. - très probablement, il y a une erreur au niveau de l'interface physique ethernet (le PHY) qui est mal gérée dans le driver. Je pense que le problème vient de là, car dans ce cas, le fait de faire ifdown puis ifup remettra effectivement le PHY en état de marche. En effet, ifdown appelle un "close" de l'interface ethernet et ifup fait ensuite un "open". Or, généralement le "open" d'une interface ethernet fait une réinitialisation complète du PHY. - autre possibilité: le chip ethernet est en erreur et le driver oublie de traiter celle-ci. C'est une possibilité, dans le cas ou le "open" de ce driver réinitialise effectivement tout le chip ethernet (et pas seulement le PHY).
Donc, 2 solutions: - tenter de débugger le driver - envoyer un rapport de bug au mainteneur du driver (dont l'addresse mail est dans /usr/src/linux/MAINTAINERS ou dans les sources de celui-ci).
Hello,
j'ai de temps en temps une "desactivation" de mon interface ethernet eth0 avec dans les logs:
NETDEV WATCHDOG: eth0: transmit timed out NETDEV WATCHDOG: eth0: transmit timed out NETDEV WATCHDOG: eth0: transmit timed out NETDEV WATCHDOG: eth0: transmit timed out NETDEV WATCHDOG: eth0: transmit timed out NETDEV WATCHDOG: eth0: transmit timed out NETDEV WATCHDOG: eth0: transmit timed out
pour la relancer, obliger de faire ifdown et ifup eth0 ... les autres interfaces ne sont pas touches,