Re: Problème carte réseau sur serveur dédié

[Yahoo]

Bonjour,

ravi que la solution fonctionne,

pour informations supplémentaire, mais je ne pense pas que tu en es 
besoin, mais les optimisations sur Linux peuvent aller beaucoup plus 
loin, grâce au "SMP affinty", qui permet sur des processeurs multicœur 
de répartir la gestion des interruptions entre cœur, soit en modifiant 
soit même les valeurs d'IRQ dans /proc/irq (et en vérifiant dans 
/proc/interrupts), ou en utilisant le daemon irqbalance qui permet de 
faire la répartition des interruptions entre cœurs.


Dans le cas du réseau, cela peux être intéressant lorsque que le 
contrôleur réseau (NIC)  à plusieurs file (queue) d'envois (tx) et de 
réception (rx), il est alors possible de répartir les interruptions 
entre cœurs.


un exemple sur un serveurs qui à une contrôleur réseau avec deux files :

/$ cat /proc/interrupts | egrep  "CPU|12[6-9]"
    CPU0   CPU1   CPU2   CPU3
 126: 21   11003583    5731788    7610247  IR-PCI-MSI 
1048577-edge  enp2s0-rx-0
 127:  4 120315    185 196090  IR-PCI-MSI 
1048578-edge  enp2s0-rx-1
 128: 24    1734333    3689960    2396735  IR-PCI-MSI 
1048579-edge  enp2s0-tx-0
 129: 23    1021631    3880657    2893540  IR-PCI-MSI 
1048580-edge  enp2s0-tx-1/


On peux voir, dans mon cas, que pour une file "rx-0" la répartition est 
faite sur les 4 cœurs, mais il serait possible de réserver le CPU0 à 
rx-0, le CPU1 à rx-1, le CPU2 à tx-0 et bien sur CPU3 à tx-1.


Enfin pour dire que les solutions d'optimisation sous Linux sont 
gigantesques, mais pas toujours très simple à appréhender (je parle pour 
moi :) ), et surtout à utiliser dans les bonnes situations.


Bonne fin d’années à tous.

Loïc

Le 29/12/2018 à 08:53, JUPIN Alain a écrit :

Bonjour,

Loin de moi l'idée de ne pas vouloir donner de retour, mais 
j'attendais que le temps passe pour voir si la solution est pérenne 
dans le temps. Et c'est le cas.
A priori, le seul fait d'avoir passé la gestion des tso, gso et gro 
par le CPU suffit à résoudre mon problème.


Pour l'uso, il ne semble pas poser de problème, mais il faut dire 
qu'hormis le DNS (qui n'est qu'un cache local pour le serveur), je 
n'en fais pas usage.


Merci à vous

Alain JUPIN
Lumières d'Ici ... et d'Ailleurs 
Le 18/12/2018 à 14:29, Yahoo a écrit :


Bonjour,

je n'avais pas encore vue cette erreur, mais en modifiant le gso 
(generic-segmentation-offload) gro (generic-receive-offload) et tso 
(tcp-segmentation-offload:),


tu n'as pas touché a (ufo) udp-fragmentation-offload settings

Tu peux quand même vérifier si les options sont bien à off avec 
ethtool -K  .


Sinon, pour info, mais c'est sûrement déjà fait, il faut bien 
inscrire les modifications au démarrage du serveur, sinon les 
modifications seront perdus après "reboot",


pour ma part je les ajoute en post-up dans le fichiers des interfaces.

Tiens nous au courant si cela à fonctionné.

Loïc

Le 18/12/2018 à 10:26, JUPIN Alain a écrit :

Bonjour,

Merci pour le retour, j'avais effectivement lu sur des forums la 
même chose (chez un autre hébergeur).

Et en effet, les gro et gso sont gérés par la carte NIC
Features for eno1:
Cannot get device udp-fragmentation-offload settings: Operation not 
supported

tcp-segmentation-offload: on
generic-segmentation-offload: on
generic-receive-offload: on

L'opération a été effectuée cette nuit, je vais voir si cela est 
efficace ou pas dans le temps (çà plantait ou bout de 2 ou 3 jours) !
Pour info, j'ai quand même eu le retour suivant à la commande 
ethtool -K eno1 gso off gro off tso off
Cannot get device udp-fragmentation-offload settings: Operation not 
supported
Cannot get device udp-fragmentation-offload settings: Operation not 
supported


Alain JUPIN

Le 17/12/2018 à 16:42, Yahoo a écrit :


Bonjour,

Il semble que la carte réseau à du mal à gérer la segmentation des 
paquets,


dans ce cas là, il peux être bien de décharger cette opération au CPU.

d'après les logs ton serveur hébergé, tu est sur une carte NIC 
intel (e1000e), qui as du mal a décharger.


Vérifie si ta carte NIC gère le déchargement de la segmentation de 
paquets :


/ethtool -k /

pour le savoir vérifier les ligne (gso et gro) :

/tcp-segmentation-offload: on
/

/generic-segmentation-offload: on
generic-receive-offload: on/

si elles sont à on c'est que c'est la carte NIC qui le gére,

essaye de les passer à off pour que ce soit le CPU qui le gérent

|ethtool -K  gso off gro off tso off|

(attention cela peux engendre une perte de connexion, à faire en KVM)

J'ai dèjà eu le soucis sur des serveurs, mais avec l'utilisation de 
QoS.


En espérant pouvoir aider

Loïc

Le 17/12/2018 à 14:26, JUPIN Alain a écrit :

Bonjour,

Sur un serveur dédié chez OVH, sous Debian 9.4 qui fait tourner 
Proxmox 5.2-5 qui héberge 4 VM (toutes sous Linux aussi).
Régulièrement (au bout de quelques jours), le serveur plante, plus 
de réponse au ping sur l'IP principale du serveur, d'où le 
déclenchement 

Re: Problème carte réseau sur serveur dédié

[JUPIN Alain]

Bonjour,

Loin de moi l'idée de ne pas vouloir donner de retour, mais j'attendais
que le temps passe pour voir si la solution est pérenne dans le temps.
Et c'est le cas.
A priori, le seul fait d'avoir passé la gestion des tso, gso et gro par
le CPU suffit à résoudre mon problème.

Pour l'uso, il ne semble pas poser de problème, mais il faut dire
qu'hormis le DNS (qui n'est qu'un cache local pour le serveur), je n'en
fais pas usage.

Merci à vous

Alain JUPIN
Lumières d'Ici ... et d'Ailleurs 
Le 18/12/2018 à 14:29, Yahoo a écrit :
>
> Bonjour,
>
> je n'avais pas encore vue cette erreur, mais en modifiant le gso
> (generic-segmentation-offload) gro (generic-receive-offload) et tso
> (tcp-segmentation-offload:),
>
> tu n'as pas touché a (ufo) udp-fragmentation-offload settings
>
> Tu peux quand même vérifier si les options sont bien à off avec
> ethtool -K  .
>
> Sinon, pour info, mais c'est sûrement déjà fait, il faut bien inscrire
> les modifications au démarrage du serveur, sinon les modifications
> seront perdus après "reboot",
>
> pour ma part je les ajoute en post-up dans le fichiers des interfaces.
>
> Tiens nous au courant si cela à fonctionné.
>
> Loïc
>
> Le 18/12/2018 à 10:26, JUPIN Alain a écrit :
>> Bonjour,
>>
>> Merci pour le retour, j'avais effectivement lu sur des forums la même
>> chose (chez un autre hébergeur).
>> Et en effet, les gro et gso sont gérés par la carte NIC
>> Features for eno1:
>> Cannot get device udp-fragmentation-offload settings: Operation not
>> supported
>> tcp-segmentation-offload: on
>> generic-segmentation-offload: on
>> generic-receive-offload: on
>>
>> L'opération a été effectuée cette nuit, je vais voir si cela est
>> efficace ou pas dans le temps (çà plantait ou bout de 2 ou 3 jours) !
>> Pour info, j'ai quand même eu le retour suivant à la commande 
>> ethtool -K eno1 gso off gro off tso off
>> Cannot get device udp-fragmentation-offload settings: Operation not
>> supported
>> Cannot get device udp-fragmentation-offload settings: Operation not
>> supported
>>
>> Alain JUPIN
>>
>> Le 17/12/2018 à 16:42, Yahoo a écrit :
>>>
>>> Bonjour,
>>>
>>> Il semble que la carte réseau à du mal à gérer la segmentation des
>>> paquets,
>>>
>>> dans ce cas là, il peux être bien de décharger cette opération au CPU.
>>>
>>> d'après les logs ton serveur hébergé, tu est sur une carte NIC intel
>>> (e1000e), qui as du mal a décharger.
>>>
>>> Vérifie si ta carte NIC gère le déchargement de la segmentation de
>>> paquets :
>>>
>>> /ethtool -k /
>>>
>>> pour le savoir vérifier les ligne (gso et gro) :
>>>
>>> /tcp-segmentation-offload: on
>>> /
>>>
>>> /generic-segmentation-offload: on
>>> generic-receive-offload: on/
>>>
>>> si elles sont à on c'est que c'est la carte NIC qui le gére,
>>>
>>> essaye de les passer à off pour que ce soit le CPU qui le gérent
>>>
>>> |ethtool -K  gso off gro off tso off|
>>>
>>> (attention cela peux engendre une perte de connexion, à faire en KVM)
>>>
>>> J'ai dèjà eu le soucis sur des serveurs, mais avec l'utilisation de QoS.
>>>
>>> En espérant pouvoir aider
>>>
>>> Loïc
>>>
>>> Le 17/12/2018 à 14:26, JUPIN Alain a écrit :
 Bonjour,

 Sur un serveur dédié chez OVH, sous Debian 9.4 qui fait tourner
 Proxmox 5.2-5 qui héberge 4 VM (toutes sous Linux aussi).
 Régulièrement (au bout de quelques jours), le serveur plante, plus
 de réponse au ping sur l'IP principale du serveur, d'où le
 déclenchement d'un reset "Hard".

 Évidemment j'essaye de trouver la cause de ce plantage.
 Je n'ai rien trouvé du coté du disque dur (via smartctl).

 Mais j'ai ceci dans le log "syslog". Lors du plantage, cette
 séquence a débuté à 10h57 (heure du serveur qui est en UTC), à
 11h03 j'ai perdu le ping, elle a perdurée jusqu'à 11h08, heure du
 reboot par OVH.

 Dec 17 11:02:33 cygnus kernel: [408638.686407] e1000e :00:19.0
 eno1: Detected Hardware Unit Hang:
 Dec 17 11:02:33 cygnus kernel: [408638.686407]  
 TDH  <0>
 Dec 17 11:02:33 cygnus kernel: [408638.686407]  
 TDT  <2>
 Dec 17 11:02:33 cygnus kernel: [408638.686407]  
 next_to_use  <2>
 Dec 17 11:02:33 cygnus kernel: [408638.686407]  
 next_to_clean    <0>
 Dec 17 11:02:33 cygnus kernel: [408638.686407]
 buffer_info[next_to_clean]:
 Dec 17 11:02:33 cygnus kernel: [408638.686407]  
 time_stamp   <10615a7a6>
 Dec 17 11:02:33 cygnus kernel: [408638.686407]  
 next_to_watch    <0>
 Dec 17 11:02:33 cygnus kernel: [408638.686407]  
 jiffies  <10615b058>
 Dec 17 11:02:33 cygnus kernel: [408638.686407]  
 next_to_watch.status <0>
 Dec 17 11:02:33 cygnus kernel: [408638.686407] MAC
 Status <40080083>
 Dec 17 11:02:33 cygnus kernel: [408638.686407] PHY
 Status <796d>
 Dec 17 11:02:33 cygnus kernel: [408638.686407] PHY 1000BASE-T
 Status  <3800>

Re: Problème carte réseau sur serveur dédié

[Yahoo]

Bonjour,

je n'avais pas encore vue cette erreur, mais en modifiant le gso 
(generic-segmentation-offload) gro (generic-receive-offload) et tso 
(tcp-segmentation-offload:),


tu n'as pas touché a (ufo) udp-fragmentation-offload settings

Tu peux quand même vérifier si les options sont bien à off avec ethtool 
-K  .


Sinon, pour info, mais c'est sûrement déjà fait, il faut bien inscrire 
les modifications au démarrage du serveur, sinon les modifications 
seront perdus après "reboot",


pour ma part je les ajoute en post-up dans le fichiers des interfaces.

Tiens nous au courant si cela à fonctionné.

Loïc

Le 18/12/2018 à 10:26, JUPIN Alain a écrit :

Bonjour,

Merci pour le retour, j'avais effectivement lu sur des forums la même 
chose (chez un autre hébergeur).

Et en effet, les gro et gso sont gérés par la carte NIC
Features for eno1:
Cannot get device udp-fragmentation-offload settings: Operation not 
supported

tcp-segmentation-offload: on
generic-segmentation-offload: on
generic-receive-offload: on

L'opération a été effectuée cette nuit, je vais voir si cela est 
efficace ou pas dans le temps (çà plantait ou bout de 2 ou 3 jours) !
Pour info, j'ai quand même eu le retour suivant à la commande ethtool 
-K eno1 gso off gro off tso off
Cannot get device udp-fragmentation-offload settings: Operation not 
supported
Cannot get device udp-fragmentation-offload settings: Operation not 
supported


Alain JUPIN

Le 17/12/2018 à 16:42, Yahoo a écrit :


Bonjour,

Il semble que la carte réseau à du mal à gérer la segmentation des 
paquets,


dans ce cas là, il peux être bien de décharger cette opération au CPU.

d'après les logs ton serveur hébergé, tu est sur une carte NIC intel 
(e1000e), qui as du mal a décharger.


Vérifie si ta carte NIC gère le déchargement de la segmentation de 
paquets :


/ethtool -k /

pour le savoir vérifier les ligne (gso et gro) :

/tcp-segmentation-offload: on
/

/generic-segmentation-offload: on
generic-receive-offload: on/

si elles sont à on c'est que c'est la carte NIC qui le gére,

essaye de les passer à off pour que ce soit le CPU qui le gérent

|ethtool -K  gso off gro off tso off|

(attention cela peux engendre une perte de connexion, à faire en KVM)

J'ai dèjà eu le soucis sur des serveurs, mais avec l'utilisation de QoS.

En espérant pouvoir aider

Loïc

Le 17/12/2018 à 14:26, JUPIN Alain a écrit :

Bonjour,

Sur un serveur dédié chez OVH, sous Debian 9.4 qui fait tourner 
Proxmox 5.2-5 qui héberge 4 VM (toutes sous Linux aussi).
Régulièrement (au bout de quelques jours), le serveur plante, plus 
de réponse au ping sur l'IP principale du serveur, d'où le 
déclenchement d'un reset "Hard".


Évidemment j'essaye de trouver la cause de ce plantage.
Je n'ai rien trouvé du coté du disque dur (via smartctl).

Mais j'ai ceci dans le log "syslog". Lors du plantage, cette 
séquence a débuté à 10h57 (heure du serveur qui est en UTC), à 11h03 
j'ai perdu le ping, elle a perdurée jusqu'à 11h08, heure du reboot 
par OVH.


Dec 17 11:02:33 cygnus kernel: [408638.686407] e1000e :00:19.0 
eno1: Detected Hardware Unit Hang:

Dec 17 11:02:33 cygnus kernel: [408638.686407] TDH  <0>
Dec 17 11:02:33 cygnus kernel: [408638.686407] TDT  <2>
Dec 17 11:02:33 cygnus kernel: [408638.686407] next_to_use  <2>
Dec 17 11:02:33 cygnus kernel: [408638.686407] next_to_clean    <0>
Dec 17 11:02:33 cygnus kernel: [408638.686407] 
buffer_info[next_to_clean]:
Dec 17 11:02:33 cygnus kernel: [408638.686407] time_stamp   
<10615a7a6>

Dec 17 11:02:33 cygnus kernel: [408638.686407] next_to_watch    <0>
Dec 17 11:02:33 cygnus kernel: [408638.686407] jiffies  
<10615b058>

Dec 17 11:02:33 cygnus kernel: [408638.686407] next_to_watch.status <0>
Dec 17 11:02:33 cygnus kernel: [408638.686407] MAC 
Status <40080083>
Dec 17 11:02:33 cygnus kernel: [408638.686407] PHY 
Status <796d>
Dec 17 11:02:33 cygnus kernel: [408638.686407] PHY 1000BASE-T 
Status  <3800>
Dec 17 11:02:33 cygnus kernel: [408638.686407] PHY Extended 
Status    <3000>
Dec 17 11:02:33 cygnus kernel: [408638.686407] PCI 
Status <10>

Dec 17 11:02:33 cygnus systemd-networkd[924]: eno1: Lost carrier
Dec 17 11:02:33 cygnus kernel: [408638.849717] e1000e :00:19.0 
eno1: Reset adapter unexpectedly
Dec 17 11:02:33 cygnus kernel: [408638.849756] vmbr0: port 1(eno1) 
entered disabled state

Dec 17 11:02:37 cygnus systemd-networkd[924]: eno1: Gained carrier
Dec 17 11:02:37 cygnus systemd-networkd[924]: eno1: could not set 
address: Permission denied
Dec 17 11:02:37 cygnus kernel: [408642.507741] e1000e: eno1 NIC Link 
is Up 1000 Mbps Full Duplex, Flow Control: None
Dec 17 11:02:37 cygnus kernel: [408642.507786] vmbr0: port 1(eno1) 
entered blocking state
Dec 17 11:02:37 cygnus kernel: [408642.507791] vmbr0: port 1(eno1) 
entered forwarding state


Par contre, bien que je sois en train d'investiguer, j'ai bien 
compris qu'un problème ce produit sur 

Re: Problème carte réseau sur serveur dédié

[JUPIN Alain]

Bonjour,

Merci pour le retour, j'avais effectivement lu sur des forums la même
chose (chez un autre hébergeur).
Et en effet, les gro et gso sont gérés par la carte NIC
Features for eno1:
Cannot get device udp-fragmentation-offload settings: Operation not
supported
tcp-segmentation-offload: on
generic-segmentation-offload: on
generic-receive-offload: on

L'opération a été effectuée cette nuit, je vais voir si cela est
efficace ou pas dans le temps (çà plantait ou bout de 2 ou 3 jours) !
Pour info, j'ai quand même eu le retour suivant à la commande  ethtool
-K eno1 gso off gro off tso off
Cannot get device udp-fragmentation-offload settings: Operation not
supported
Cannot get device udp-fragmentation-offload settings: Operation not
supported

Alain JUPIN

Le 17/12/2018 à 16:42, Yahoo a écrit :
>
> Bonjour,
>
> Il semble que la carte réseau à du mal à gérer la segmentation des
> paquets,
>
> dans ce cas là, il peux être bien de décharger cette opération au CPU.
>
> d'après les logs ton serveur hébergé, tu est sur une carte NIC intel
> (e1000e), qui as du mal a décharger.
>
> Vérifie si ta carte NIC gère le déchargement de la segmentation de
> paquets :
>
> /ethtool -k /
>
> pour le savoir vérifier les ligne (gso et gro) :
>
> /tcp-segmentation-offload: on
> /
>
> /generic-segmentation-offload: on
> generic-receive-offload: on/
>
> si elles sont à on c'est que c'est la carte NIC qui le gére,
>
> essaye de les passer à off pour que ce soit le CPU qui le gérent
>
> |ethtool -K  gso off gro off tso off|
>
> (attention cela peux engendre une perte de connexion, à faire en KVM)
>
> J'ai dèjà eu le soucis sur des serveurs, mais avec l'utilisation de QoS.
>
> En espérant pouvoir aider
>
> Loïc
>
> Le 17/12/2018 à 14:26, JUPIN Alain a écrit :
>> Bonjour,
>>
>> Sur un serveur dédié chez OVH, sous Debian 9.4 qui fait tourner
>> Proxmox 5.2-5 qui héberge 4 VM (toutes sous Linux aussi).
>> Régulièrement (au bout de quelques jours), le serveur plante, plus de
>> réponse au ping sur l'IP principale du serveur, d'où le déclenchement
>> d'un reset "Hard".
>>
>> Évidemment j'essaye de trouver la cause de ce plantage.
>> Je n'ai rien trouvé du coté du disque dur (via smartctl).
>>
>> Mais j'ai ceci dans le log "syslog". Lors du plantage, cette séquence
>> a débuté à 10h57 (heure du serveur qui est en UTC), à 11h03 j'ai
>> perdu le ping, elle a perdurée jusqu'à 11h08, heure du reboot par OVH.
>>
>> Dec 17 11:02:33 cygnus kernel: [408638.686407] e1000e :00:19.0
>> eno1: Detected Hardware Unit Hang:
>> Dec 17 11:02:33 cygnus kernel: [408638.686407]   TDH  <0>
>> Dec 17 11:02:33 cygnus kernel: [408638.686407]   TDT  <2>
>> Dec 17 11:02:33 cygnus kernel: [408638.686407]   next_to_use  <2>
>> Dec 17 11:02:33 cygnus kernel: [408638.686407]   next_to_clean    <0>
>> Dec 17 11:02:33 cygnus kernel: [408638.686407]
>> buffer_info[next_to_clean]:
>> Dec 17 11:02:33 cygnus kernel: [408638.686407]   time_stamp  
>> <10615a7a6>
>> Dec 17 11:02:33 cygnus kernel: [408638.686407]   next_to_watch    <0>
>> Dec 17 11:02:33 cygnus kernel: [408638.686407]   jiffies 
>> <10615b058>
>> Dec 17 11:02:33 cygnus kernel: [408638.686407]   next_to_watch.status <0>
>> Dec 17 11:02:33 cygnus kernel: [408638.686407] MAC Status
>> <40080083>
>> Dec 17 11:02:33 cygnus kernel: [408638.686407] PHY Status
>> <796d>
>> Dec 17 11:02:33 cygnus kernel: [408638.686407] PHY 1000BASE-T Status 
>> <3800>
>> Dec 17 11:02:33 cygnus kernel: [408638.686407] PHY Extended Status   
>> <3000>
>> Dec 17 11:02:33 cygnus kernel: [408638.686407] PCI Status
>> <10>
>> Dec 17 11:02:33 cygnus systemd-networkd[924]: eno1: Lost carrier
>> Dec 17 11:02:33 cygnus kernel: [408638.849717] e1000e :00:19.0
>> eno1: Reset adapter unexpectedly
>> Dec 17 11:02:33 cygnus kernel: [408638.849756] vmbr0: port 1(eno1)
>> entered disabled state
>> Dec 17 11:02:37 cygnus systemd-networkd[924]: eno1: Gained carrier
>> Dec 17 11:02:37 cygnus systemd-networkd[924]: eno1: could not set
>> address: Permission denied
>> Dec 17 11:02:37 cygnus kernel: [408642.507741] e1000e: eno1 NIC Link
>> is Up 1000 Mbps Full Duplex, Flow Control: None
>> Dec 17 11:02:37 cygnus kernel: [408642.507786] vmbr0: port 1(eno1)
>> entered blocking state
>> Dec 17 11:02:37 cygnus kernel: [408642.507791] vmbr0: port 1(eno1)
>> entered forwarding state
>>
>> Par contre, bien que je sois en train d'investiguer, j'ai bien
>> compris qu'un problème ce produit sur l'interface Ethernet, mais je
>> ne sais pas quoi précisément.
>> Avez vous une idée sur ce qui peut être à l'origine de ceci ?
>>
>> PS : J'attends aussi une réponse d'OVH sur la question.
>>
>> -- 
>> Alain JUPIN
>> Lumières d'Ici ... et d'Ailleurs 

Re: Problème carte réseau sur serveur dédié

[Yahoo]

Bonjour,

Il semble que la carte réseau à du mal à gérer la segmentation des paquets,

dans ce cas là, il peux être bien de décharger cette opération au CPU.

d'après les logs ton serveur hébergé, tu est sur une carte NIC intel 
(e1000e), qui as du mal a décharger.


Vérifie si ta carte NIC gère le déchargement de la segmentation de paquets :

/ethtool -k /

pour le savoir vérifier les ligne (gso et gro) :

/tcp-segmentation-offload: on
/

/generic-segmentation-offload: on
generic-receive-offload: on/

si elles sont à on c'est que c'est la carte NIC qui le gére,

essaye de les passer à off pour que ce soit le CPU qui le gérent

|ethtool -K  gso off gro off tso off|

(attention cela peux engendre une perte de connexion, à faire en KVM)

J'ai dèjà eu le soucis sur des serveurs, mais avec l'utilisation de QoS.

En espérant pouvoir aider

Loïc

Le 17/12/2018 à 14:26, JUPIN Alain a écrit :

Bonjour,

Sur un serveur dédié chez OVH, sous Debian 9.4 qui fait tourner 
Proxmox 5.2-5 qui héberge 4 VM (toutes sous Linux aussi).
Régulièrement (au bout de quelques jours), le serveur plante, plus de 
réponse au ping sur l'IP principale du serveur, d'où le déclenchement 
d'un reset "Hard".


Évidemment j'essaye de trouver la cause de ce plantage.
Je n'ai rien trouvé du coté du disque dur (via smartctl).

Mais j'ai ceci dans le log "syslog". Lors du plantage, cette séquence 
a débuté à 10h57 (heure du serveur qui est en UTC), à 11h03 j'ai perdu 
le ping, elle a perdurée jusqu'à 11h08, heure du reboot par OVH.


Dec 17 11:02:33 cygnus kernel: [408638.686407] e1000e :00:19.0 
eno1: Detected Hardware Unit Hang:

Dec 17 11:02:33 cygnus kernel: [408638.686407] TDH  <0>
Dec 17 11:02:33 cygnus kernel: [408638.686407] TDT  <2>
Dec 17 11:02:33 cygnus kernel: [408638.686407] next_to_use  <2>
Dec 17 11:02:33 cygnus kernel: [408638.686407] next_to_clean    <0>
Dec 17 11:02:33 cygnus kernel: [408638.686407] buffer_info[next_to_clean]:
Dec 17 11:02:33 cygnus kernel: [408638.686407] time_stamp   
<10615a7a6>

Dec 17 11:02:33 cygnus kernel: [408638.686407] next_to_watch    <0>
Dec 17 11:02:33 cygnus kernel: [408638.686407] jiffies  
<10615b058>

Dec 17 11:02:33 cygnus kernel: [408638.686407] next_to_watch.status <0>
Dec 17 11:02:33 cygnus kernel: [408638.686407] MAC Status 
<40080083>
Dec 17 11:02:33 cygnus kernel: [408638.686407] PHY Status 
<796d>
Dec 17 11:02:33 cygnus kernel: [408638.686407] PHY 1000BASE-T Status  
<3800>
Dec 17 11:02:33 cygnus kernel: [408638.686407] PHY Extended Status    
<3000>

Dec 17 11:02:33 cygnus kernel: [408638.686407] PCI Status <10>
Dec 17 11:02:33 cygnus systemd-networkd[924]: eno1: Lost carrier
Dec 17 11:02:33 cygnus kernel: [408638.849717] e1000e :00:19.0 
eno1: Reset adapter unexpectedly
Dec 17 11:02:33 cygnus kernel: [408638.849756] vmbr0: port 1(eno1) 
entered disabled state

Dec 17 11:02:37 cygnus systemd-networkd[924]: eno1: Gained carrier
Dec 17 11:02:37 cygnus systemd-networkd[924]: eno1: could not set 
address: Permission denied
Dec 17 11:02:37 cygnus kernel: [408642.507741] e1000e: eno1 NIC Link 
is Up 1000 Mbps Full Duplex, Flow Control: None
Dec 17 11:02:37 cygnus kernel: [408642.507786] vmbr0: port 1(eno1) 
entered blocking state
Dec 17 11:02:37 cygnus kernel: [408642.507791] vmbr0: port 1(eno1) 
entered forwarding state


Par contre, bien que je sois en train d'investiguer, j'ai bien compris 
qu'un problème ce produit sur l'interface Ethernet, mais je ne sais 
pas quoi précisément.

Avez vous une idée sur ce qui peut être à l'origine de ceci ?

PS : J'attends aussi une réponse d'OVH sur la question.

--
Alain JUPIN
Lumières d'Ici ... et d'Ailleurs 

Re: Problème carte réseau sur serveur dédié

[Haricophile]

Le Mon, 17 Dec 2018 14:26:17 +0100,
JUPIN Alain  a écrit :

> Dec 17 11:02:33 cygnus systemd-networkd[924]: eno1: Lost carrier
> Dec 17 11:02:33 cygnus kernel: [408638.849717] e1000e :00:19.0 eno1:
> Reset adapter unexpectedly
> Dec 17 11:02:33 cygnus kernel: [408638.849756] vmbr0: port 1(eno1)
> entered disabled state
> Dec 17 11:02:37 cygnus systemd-networkd[924]: eno1: Gained carrier
> Dec 17 11:02:37 cygnus systemd-networkd[924]: eno1: could not set
> address: Permission denied

Ça me parait être un truc pour le support OVH. carrier c'est la porteuse du
réseau, et une réinitialisation "inattendue" de la carte, a mon humble avis ça
sent un peu le problème matériel (alim ou réseau).

Problème carte réseau sur serveur dédié

[JUPIN Alain]

Bonjour,

Sur un serveur dédié chez OVH, sous Debian 9.4 qui fait tourner Proxmox
5.2-5 qui héberge 4 VM (toutes sous Linux aussi).
Régulièrement (au bout de quelques jours), le serveur plante, plus de
réponse au ping sur l'IP principale du serveur, d'où le déclenchement
d'un reset "Hard".

Évidemment j'essaye de trouver la cause de ce plantage.
Je n'ai rien trouvé du coté du disque dur (via smartctl).

Mais j'ai ceci dans le log "syslog". Lors du plantage, cette séquence a
débuté à 10h57 (heure du serveur qui est en UTC), à 11h03 j'ai perdu le
ping, elle a perdurée jusqu'à 11h08, heure du reboot par OVH.

Dec 17 11:02:33 cygnus kernel: [408638.686407] e1000e :00:19.0 eno1:
Detected Hardware Unit Hang:
Dec 17 11:02:33 cygnus kernel: [408638.686407]   TDH  <0>
Dec 17 11:02:33 cygnus kernel: [408638.686407]   TDT  <2>
Dec 17 11:02:33 cygnus kernel: [408638.686407]   next_to_use  <2>
Dec 17 11:02:33 cygnus kernel: [408638.686407]   next_to_clean    <0>
Dec 17 11:02:33 cygnus kernel: [408638.686407] buffer_info[next_to_clean]:
Dec 17 11:02:33 cygnus kernel: [408638.686407]   time_stamp  
<10615a7a6>
Dec 17 11:02:33 cygnus kernel: [408638.686407]   next_to_watch    <0>
Dec 17 11:02:33 cygnus kernel: [408638.686407]   jiffies 
<10615b058>
Dec 17 11:02:33 cygnus kernel: [408638.686407]   next_to_watch.status <0>
Dec 17 11:02:33 cygnus kernel: [408638.686407] MAC Status
<40080083>
Dec 17 11:02:33 cygnus kernel: [408638.686407] PHY Status <796d>
Dec 17 11:02:33 cygnus kernel: [408638.686407] PHY 1000BASE-T Status  <3800>
Dec 17 11:02:33 cygnus kernel: [408638.686407] PHY Extended Status    <3000>
Dec 17 11:02:33 cygnus kernel: [408638.686407] PCI Status <10>
Dec 17 11:02:33 cygnus systemd-networkd[924]: eno1: Lost carrier
Dec 17 11:02:33 cygnus kernel: [408638.849717] e1000e :00:19.0 eno1:
Reset adapter unexpectedly
Dec 17 11:02:33 cygnus kernel: [408638.849756] vmbr0: port 1(eno1)
entered disabled state
Dec 17 11:02:37 cygnus systemd-networkd[924]: eno1: Gained carrier
Dec 17 11:02:37 cygnus systemd-networkd[924]: eno1: could not set
address: Permission denied
Dec 17 11:02:37 cygnus kernel: [408642.507741] e1000e: eno1 NIC Link is
Up 1000 Mbps Full Duplex, Flow Control: None
Dec 17 11:02:37 cygnus kernel: [408642.507786] vmbr0: port 1(eno1)
entered blocking state
Dec 17 11:02:37 cygnus kernel: [408642.507791] vmbr0: port 1(eno1)
entered forwarding state

Par contre, bien que je sois en train d'investiguer, j'ai bien compris
qu'un problème ce produit sur l'interface Ethernet, mais je ne sais pas
quoi précisément.
Avez vous une idée sur ce qui peut être à l'origine de ceci ?

PS : J'attends aussi une réponse d'OVH sur la question.

-- 
Alain JUPIN
Lumières d'Ici ... et d'Ailleurs