Depuis que j'ai changé de machine, j'ai des problèmes de freeze
intempestifs. Mais tout n'est pas gelé. Un 'ls' gèle alors que d'autres
processus fonctionne normalement. La souris n'est pas touchée ni le
clavier. Dans les logs, j'ai ça:
J'ai supprimé les détails des call trace ([...]) afin de ne pas faire trop long.
On voit que plusieurs processus bloquent (md1_raid1, md0_raid1, uptimed,
fetchmail, kworker, lpqd et systemd). Je pensais à un disque défectueux
dans une grappe RAID 1, alors je l'ai enlevé, ce qui a eu pour effet de
d'augmenter la durée entre deux freeze. J'ai également essayé avec des
versions de noyaux inférieurs, mais même résultat. J'ai lu quelque part
sur Internet que cela pouvait être dû à une machine lente, mais c'est
loin d'être mon cas.
Bonjour, C'est dommage que chaque sortie de noyau soit sur une seule ligne: ça rend la lecture des listings vraiment très désagréable. :( Ceci étant, j'ai cru voir un truc peut-être intéressant (ou peut-être impertinent, dépendant de la causes.) steve, au 2019-04-12 :
1 box kernel: [ 3988.692314] Tainted: P OE ...
^~~~~~~ Le noyau est teinté, quelle en est la cause ? (ce devrait être indiqué quelque part dans la sortie de `dmesg`.) Si un sous système corrompt le noyau, alors il n'est peut-être pas nécessaire de chercher plus loin, et juste de le désactiver. Bien à vous, -- Étienne Mollier
Bonjour,
C'est dommage que chaque sortie de noyau soit sur une seule
ligne: ça rend la lecture des listings vraiment très
désagréable. :(
Ceci étant, j'ai cru voir un truc peut-être intéressant (ou
peut-être impertinent, dépendant de la causes.)
steve, au 2019-04-12 :
1 box kernel: [ 3988.692314] Tainted: P OE ...
^~~~~~~
Le noyau est teinté, quelle en est la cause ? (ce devrait être
indiqué quelque part dans la sortie de `dmesg`.)
Si un sous système corrompt le noyau, alors il n'est peut-être
pas nécessaire de chercher plus loin, et juste de le désactiver.
Bien à vous,
--
Étienne Mollier <etienne.mollier@mailoo.org>
Bonjour, C'est dommage que chaque sortie de noyau soit sur une seule ligne: ça rend la lecture des listings vraiment très désagréable. :( Ceci étant, j'ai cru voir un truc peut-être intéressant (ou peut-être impertinent, dépendant de la causes.) steve, au 2019-04-12 :
1 box kernel: [ 3988.692314] Tainted: P OE ...
^~~~~~~ Le noyau est teinté, quelle en est la cause ? (ce devrait être indiqué quelque part dans la sortie de `dmesg`.) Si un sous système corrompt le noyau, alors il n'est peut-être pas nécessaire de chercher plus loin, et juste de le désactiver. Bien à vous, -- Étienne Mollier
Stephane Ascoet
Le 12/04/2019 à 10:41, steve a écrit :
Et vous ?
Bonjour, tu n'aurais pas une recherche Ldap qui serait lancee lors de certains acces? J'avais le meme souci sur mon portable du travail, j'avais trouve une solution de contournement sur le Web. Un patch a ete fait mais n'a toujours pas ete implemente, il faut donc faire les modifications dans le code par nous memes(il y a deux conditions a modifier). J'aurais du mal a te donner des indications plus precises car le portable en question a ete vole et j'etais tombe sur ces forums en cherchant autre chose... -- Cordialement, Stephane Ascoet
Le 12/04/2019 à 10:41, steve a écrit :
Et vous ?
Bonjour, tu n'aurais pas une recherche Ldap qui serait lancee lors de
certains acces? J'avais le meme souci sur mon portable du travail,
j'avais trouve une solution de contournement sur le Web. Un patch a ete
fait mais n'a toujours pas ete implemente, il faut donc faire les
modifications dans le code par nous memes(il y a deux conditions a
modifier).
J'aurais du mal a te donner des indications plus precises car le
portable en question a ete vole et j'etais tombe sur ces forums en
cherchant autre chose...
--
Cordialement, Stephane Ascoet
Bonjour, tu n'aurais pas une recherche Ldap qui serait lancee lors de certains acces? J'avais le meme souci sur mon portable du travail, j'avais trouve une solution de contournement sur le Web. Un patch a ete fait mais n'a toujours pas ete implemente, il faut donc faire les modifications dans le code par nous memes(il y a deux conditions a modifier). J'aurais du mal a te donner des indications plus precises car le portable en question a ete vole et j'etais tombe sur ces forums en cherchant autre chose... -- Cordialement, Stephane Ascoet
steve
Hello, Le 12-04-2019, à 20:01:17 +0200, Étienne Mollier a écrit :
Bonjour, C'est dommage que chaque sortie de noyau soit sur une seule ligne: ça rend la lecture des listings vraiment très désagréable. :(
Vraiment désolé, à l'envoi ça semblait correct.
Ceci étant, j'ai cru voir un truc peut-être intéressant (ou peut-être impertinent, dépendant de la causes.) steve, au 2019-04-12 :
1 box kernel: [ 3988.692314] Tainted: P OE ...
^~~~~~~ Le noyau est teinté, quelle en est la cause ? (ce devrait être indiqué quelque part dans la sortie de `dmesg`.)
driver nvidia proprio.
Si un sous système corrompt le noyau, alors il n'est peut-être pas nécessaire de chercher plus loin, et juste de le désactiver.
Je pourrais en effet essayer le driver libre « nouveau ». Mais la dernière fois que j'ai essayé, ce n'était vraiment pas très concluant. Merci.
Hello,
Le 12-04-2019, à 20:01:17 +0200, Étienne Mollier a écrit :
Bonjour,
C'est dommage que chaque sortie de noyau soit sur une seule
ligne: ça rend la lecture des listings vraiment très
désagréable. :(
Vraiment désolé, à l'envoi ça semblait correct.
Ceci étant, j'ai cru voir un truc peut-être intéressant (ou
peut-être impertinent, dépendant de la causes.)
steve, au 2019-04-12 :
1 box kernel: [ 3988.692314] Tainted: P OE ...
^~~~~~~
Le noyau est teinté, quelle en est la cause ? (ce devrait être
indiqué quelque part dans la sortie de `dmesg`.)
driver nvidia proprio.
Si un sous système corrompt le noyau, alors il n'est peut-être
pas nécessaire de chercher plus loin, et juste de le désactiver.
Je pourrais en effet essayer le driver libre « nouveau ». Mais la
dernière fois que j'ai essayé, ce n'était vraiment pas très concluant.
Le 15-04-2019, à 10:59:21 +0200, Stephane Ascoet a écrit :
Le 12/04/2019 à 10:41, steve a écrit :
Et vous ?
Bonjour, tu n'aurais pas une recherche Ldap qui serait lancee lors de certains acces? J'avais le meme souci sur mon portable du travail,
Nope. Ou alors planqué sous un autre nom. Merci
steve
Le 15-04-2019, à 17:11:22 +0200, Daniel Caillibaud a écrit :
Le 12/04/19 à 10:41, steve a écrit :
Bonjour à tous, Depuis que j'ai changé de machine, j'ai des problèmes de freeze intempestifs. Mais tout n'est pas gelé. Un 'ls' gèle alors que d'autres processus fonctionne normalement. La souris n'est pas touchée ni le clavier.
C'est l'accès au disque qui bloque ls, mais ni la souris ni le clavier.
C'est ça. Avec un message du style (ça vient d'arriver à nouveau): INFO: task kworker/u56:4:379 blocked for more than 120 seconds
On voit que plusieurs processus bloquent (md1_raid1, md0_raid1, uptimed, fetchmail, kworker, lpqd et systemd).
C'est effectivement mdadm qui semble coincer, et du coup bloque tous ceux qui veulent accéder au disque à ce moment là.
Je pensais à un disque défectueux dans une grappe RAID 1, alors je l'ai enlevé, ce qui a eu pour effet de d'augmenter la durée entre deux freeze. J'ai également essayé avec des versions de noyaux inférieurs, mais même résultat.
Il faudrait demander à mdadm d'être plus bavard quand il a un pb, mais je sais pas trop comment.
Rien dans la page man.
mdadm --detail --scan --verbose ne remonte rien d'anormal ?
Non.
smartctl non plus ? # lister les disques smartctl --scan # afficher les infos le concernant smartctl --all /dev/sdX
Déjà essayé tout ça. J'ai également lancé des fsck depuis un OS live qui a détecté quelques problèmes (et corrigés), mais le freeze apparaît encore, à des intervalles totalement irréguliers.
Tu utilises quel filesystem ?
ext4.
Le 15-04-2019, à 17:11:22 +0200, Daniel Caillibaud a écrit :
Le 12/04/19 à 10:41, steve <dlist@bluewin.ch> a écrit :
Bonjour à tous,
Depuis que j'ai changé de machine, j'ai des problèmes de freeze
intempestifs. Mais tout n'est pas gelé. Un 'ls' gèle alors que d'autres
processus fonctionne normalement. La souris n'est pas touchée ni le
clavier.
C'est l'accès au disque qui bloque ls, mais ni la souris ni le clavier.
C'est ça. Avec un message du style (ça vient d'arriver à nouveau):
INFO: task kworker/u56:4:379 blocked for more than 120 seconds
On voit que plusieurs processus bloquent (md1_raid1, md0_raid1, uptimed,
fetchmail, kworker, lpqd et systemd).
C'est effectivement mdadm qui semble coincer, et du coup bloque tous ceux
qui veulent accéder au disque à ce moment là.
Je pensais à un disque défectueux
dans une grappe RAID 1, alors je l'ai enlevé, ce qui a eu pour effet de
d'augmenter la durée entre deux freeze. J'ai également essayé avec des
versions de noyaux inférieurs, mais même résultat.
Il faudrait demander à mdadm d'être plus bavard quand il a un pb, mais je
sais pas trop comment.
Rien dans la page man.
mdadm --detail --scan --verbose
ne remonte rien d'anormal ?
Non.
smartctl non plus ?
# lister les disques
smartctl --scan
# afficher les infos le concernant
smartctl --all /dev/sdX
Déjà essayé tout ça. J'ai également lancé des fsck depuis un OS live qui
a détecté quelques problèmes (et corrigés), mais le freeze apparaît
encore, à des intervalles totalement irréguliers.
Le 15-04-2019, à 17:11:22 +0200, Daniel Caillibaud a écrit :
Le 12/04/19 à 10:41, steve a écrit :
Bonjour à tous, Depuis que j'ai changé de machine, j'ai des problèmes de freeze intempestifs. Mais tout n'est pas gelé. Un 'ls' gèle alors que d'autres processus fonctionne normalement. La souris n'est pas touchée ni le clavier.
C'est l'accès au disque qui bloque ls, mais ni la souris ni le clavier.
C'est ça. Avec un message du style (ça vient d'arriver à nouveau): INFO: task kworker/u56:4:379 blocked for more than 120 seconds
On voit que plusieurs processus bloquent (md1_raid1, md0_raid1, uptimed, fetchmail, kworker, lpqd et systemd).
C'est effectivement mdadm qui semble coincer, et du coup bloque tous ceux qui veulent accéder au disque à ce moment là.
Je pensais à un disque défectueux dans une grappe RAID 1, alors je l'ai enlevé, ce qui a eu pour effet de d'augmenter la durée entre deux freeze. J'ai également essayé avec des versions de noyaux inférieurs, mais même résultat.
Il faudrait demander à mdadm d'être plus bavard quand il a un pb, mais je sais pas trop comment.
Rien dans la page man.
mdadm --detail --scan --verbose ne remonte rien d'anormal ?
Non.
smartctl non plus ? # lister les disques smartctl --scan # afficher les infos le concernant smartctl --all /dev/sdX
Déjà essayé tout ça. J'ai également lancé des fsck depuis un OS live qui a détecté quelques problèmes (et corrigés), mais le freeze apparaît encore, à des intervalles totalement irréguliers.
Tu utilises quel filesystem ?
ext4.
=c3
Bonjour, steve, au 2019-04-15 :
Vraiment désolé, à l'envoi ça semblait correct.
Ce n'est pas très grave; on a qu'a dire que ça a justifié le démarrage de mon éditeur de texte préféré. :)
Le 12-04-2019, à 20:01:17 +0200, Étienne Mollier a écrit :
steve, au 2019-04-12 : > 1 box kernel: [ 3988.692314] Tainted: P OE ... ^~~~~~~ Le noyau est teinté, quelle en est la cause ? (ce devrait être indiqué quelque part dans la sortie de `dmesg`.)
driver nvidia proprio.
Bon, au moins on en a le cœur net, la teinture n'avait rien de vraiment pertinent, sauf malchance.
Si un sous système corrompt le noyau, alors il n'est peut-être pas nécessaire de chercher plus loin, et juste de le désactiver.
Je pourrais en effet essayer le driver libre « nouveau ». Mais la dernière fois que j'ai essayé, ce n'était vraiment pas très concluant.
Ça vaudrait peut-être quand même le coup de voir si le noyau est toujours teinté sans ce pilote, et si le problème se pose à nouveau. Sinon, plus prosaïquement, dans quel état se trouve le Raid actuellement ? Est-il toujours partiel ou bien le remplacement du disque en panne a eu lieu ? (cat /proc/mdstat)
Le 15-04-2019, à 17:11:22 +0200, Daniel Caillibaud a écrit :
Il faudrait demander à mdadm d'être plus bavard quand il a un pb, mais je sais pas trop comment.
Rien dans la page man.
L'essentiel du verbe provient surtout de la sortie de `dmesg`. Peut-être que des messages intéressants apparaissent au moment de l'assemblage ? Amicalement, -- Étienne Mollier
Bonjour,
steve, au 2019-04-15 :
Vraiment désolé, à l'envoi ça semblait correct.
Ce n'est pas très grave; on a qu'a dire que ça a justifié le
démarrage de mon éditeur de texte préféré. :)
Le 12-04-2019, à 20:01:17 +0200, Étienne Mollier a écrit :
> steve, au 2019-04-12 :
> > 1 box kernel: [ 3988.692314] Tainted: P OE ...
> ^~~~~~~
> Le noyau est teinté, quelle en est la cause ? (ce devrait être
> indiqué quelque part dans la sortie de `dmesg`.)
driver nvidia proprio.
Bon, au moins on en a le cœur net, la teinture n'avait rien de
vraiment pertinent, sauf malchance.
> Si un sous système corrompt le noyau, alors il n'est peut-être
> pas nécessaire de chercher plus loin, et juste de le
> désactiver.
Je pourrais en effet essayer le driver libre « nouveau ». Mais la
dernière fois que j'ai essayé, ce n'était vraiment pas très concluant.
Ça vaudrait peut-être quand même le coup de voir si le noyau est
toujours teinté sans ce pilote, et si le problème se pose à
nouveau.
Sinon, plus prosaïquement, dans quel état se trouve le Raid
actuellement ? Est-il toujours partiel ou bien le remplacement
du disque en panne a eu lieu ? (cat /proc/mdstat)
Le 15-04-2019, à 17:11:22 +0200, Daniel Caillibaud a écrit :
> Il faudrait demander à mdadm d'être plus bavard quand il a un pb, mais je
> sais pas trop comment.
Rien dans la page man.
L'essentiel du verbe provient surtout de la sortie de `dmesg`.
Peut-être que des messages intéressants apparaissent au moment
de l'assemblage ?
Ce n'est pas très grave; on a qu'a dire que ça a justifié le démarrage de mon éditeur de texte préféré. :)
Le 12-04-2019, à 20:01:17 +0200, Étienne Mollier a écrit :
steve, au 2019-04-12 : > 1 box kernel: [ 3988.692314] Tainted: P OE ... ^~~~~~~ Le noyau est teinté, quelle en est la cause ? (ce devrait être indiqué quelque part dans la sortie de `dmesg`.)
driver nvidia proprio.
Bon, au moins on en a le cœur net, la teinture n'avait rien de vraiment pertinent, sauf malchance.
Si un sous système corrompt le noyau, alors il n'est peut-être pas nécessaire de chercher plus loin, et juste de le désactiver.
Je pourrais en effet essayer le driver libre « nouveau ». Mais la dernière fois que j'ai essayé, ce n'était vraiment pas très concluant.
Ça vaudrait peut-être quand même le coup de voir si le noyau est toujours teinté sans ce pilote, et si le problème se pose à nouveau. Sinon, plus prosaïquement, dans quel état se trouve le Raid actuellement ? Est-il toujours partiel ou bien le remplacement du disque en panne a eu lieu ? (cat /proc/mdstat)
Le 15-04-2019, à 17:11:22 +0200, Daniel Caillibaud a écrit :
Il faudrait demander à mdadm d'être plus bavard quand il a un pb, mais je sais pas trop comment.
Rien dans la page man.
L'essentiel du verbe provient surtout de la sortie de `dmesg`. Peut-être que des messages intéressants apparaissent au moment de l'assemblage ? Amicalement, -- Étienne Mollier
steve
Le 15-04-2019, à 22:24:20 +0200, Étienne Mollier a écrit :
Bonjour, steve, au 2019-04-15 :
Vraiment désolé, à l'envoi ça semblait correct.
Ce n'est pas très grave; on a qu'a dire que ça a justifié le démarrage de mon éditeur de texte préféré. :)
Sympa de le prendre comme ça :)
Le 12-04-2019, à 20:01:17 +0200, Étienne Mollier a écrit :
steve, au 2019-04-12 : > 1 box kernel: [ 3988.692314] Tainted: P OE ... ^~~~~~~ Le noyau est teinté, quelle en est la cause ? (ce devrait être indiqué quelque part dans la sortie de `dmesg`.)
driver nvidia proprio.
Bon, au moins on en a le cœur net, la teinture n'avait rien de vraiment pertinent, sauf malchance.
Si un sous système corrompt le noyau, alors il n'est peut-être pas nécessaire de chercher plus loin, et juste de le désactiver.
Je pourrais en effet essayer le driver libre « nouveau ». Mais la dernière fois que j'ai essayé, ce n'était vraiment pas très concluant.
Ça vaudrait peut-être quand même le coup de voir si le noyau est toujours teinté sans ce pilote, et si le problème se pose à nouveau.
Oui.
Sinon, plus prosaïquement, dans quel état se trouve le Raid actuellement ? Est-il toujours partiel ou bien le remplacement du disque en panne a eu lieu ? (cat /proc/mdstat)
J'avais trois disques dans la grappe dont un spare qui a pris du service quand j'ai débranché le disque défectueux. $ cat /proc/mdstat Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] md1 : active raid1 sdb5[2] sde5[3] 117120896 blocks super 1.2 [2/2] [UU] md2 : active raid1 sdb6[2] sde6[3] 97589120 blocks super 1.2 [2/2] [UU] md0 : active raid1 sdb1[2] sde1[3] 19514240 blocks super 1.2 [2/2] [UU] unused devices: <none> Donc ok. J'ai acheté un disque supplémentaire mais n'ai pas encore eu le temps de l'installer.
Le 15-04-2019, à 17:11:22 +0200, Daniel Caillibaud a écrit :
Il faudrait demander à mdadm d'être plus bavard quand il a un pb, mais je sais pas trop comment.
Rien dans la page man.
L'essentiel du verbe provient surtout de la sortie de `dmesg`. Peut-être que des messages intéressants apparaissent au moment de l'assemblage ?
$ dmesg | grep -i raid [ 2.196649] md/raid1:md2: active with 2 out of 2 mirrors [ 2.196906] md/raid1:md1: active with 2 out of 2 mirrors [ 2.197262] md/raid1:md0: active with 2 out of 2 mirrors [ 3.505941] raid6: sse2x1 gen() 11776 MB/s [ 3.573938] raid6: sse2x1 xor() 11147 MB/s [ 3.641939] raid6: sse2x2 gen() 18466 MB/s [ 3.709938] raid6: sse2x2 xor() 12826 MB/s [ 3.777939] raid6: sse2x4 gen() 20535 MB/s [ 3.845938] raid6: sse2x4 xor() 14214 MB/s [ 3.913939] raid6: avx2x1 gen() 29727 MB/s [ 3.981936] raid6: avx2x1 xor() 21553 MB/s [ 4.049938] raid6: avx2x2 gen() 34915 MB/s [ 4.117936] raid6: avx2x2 xor() 23875 MB/s [ 4.185936] raid6: avx2x4 gen() 37470 MB/s [ 4.253936] raid6: avx2x4 xor() 23632 MB/s [ 4.321939] raid6: avx512x1 gen() 35605 MB/s [ 4.389937] raid6: avx512x1 xor() 19965 MB/s [ 4.457938] raid6: avx512x2 gen() 44244 MB/s [ 4.525937] raid6: avx512x2 xor() 24960 MB/s [ 4.593937] raid6: avx512x4 gen() 50744 MB/s [ 4.661938] raid6: avx512x4 xor() 20318 MB/s [ 4.661938] raid6: using algorithm avx512x4 gen() 50744 MB/s [ 4.661939] raid6: .... xor() 20318 MB/s, rmw enabled [ 4.661939] raid6: using avx512x2 recovery algorithm Rien qui semble anormal (à part ces mentions de raid6 que je n'utilise pas). Merci encore. Steve
Le 15-04-2019, à 22:24:20 +0200, Étienne Mollier a écrit :
Bonjour,
steve, au 2019-04-15 :
Vraiment désolé, à l'envoi ça semblait correct.
Ce n'est pas très grave; on a qu'a dire que ça a justifié le
démarrage de mon éditeur de texte préféré. :)
Sympa de le prendre comme ça :)
Le 12-04-2019, à 20:01:17 +0200, Étienne Mollier a écrit :
> steve, au 2019-04-12 :
> > 1 box kernel: [ 3988.692314] Tainted: P OE ...
> ^~~~~~~
> Le noyau est teinté, quelle en est la cause ? (ce devrait être
> indiqué quelque part dans la sortie de `dmesg`.)
driver nvidia proprio.
Bon, au moins on en a le cœur net, la teinture n'avait rien de
vraiment pertinent, sauf malchance.
> Si un sous système corrompt le noyau, alors il n'est peut-être
> pas nécessaire de chercher plus loin, et juste de le
> désactiver.
Je pourrais en effet essayer le driver libre « nouveau ». Mais la
dernière fois que j'ai essayé, ce n'était vraiment pas très concluant.
Ça vaudrait peut-être quand même le coup de voir si le noyau est
toujours teinté sans ce pilote, et si le problème se pose à
nouveau.
Oui.
Sinon, plus prosaïquement, dans quel état se trouve le Raid
actuellement ? Est-il toujours partiel ou bien le remplacement
du disque en panne a eu lieu ? (cat /proc/mdstat)
J'avais trois disques dans la grappe dont un spare qui a pris du service
quand j'ai débranché le disque défectueux.
md2 : active raid1 sdb6[2] sde6[3]
97589120 blocks super 1.2 [2/2] [UU]
md0 : active raid1 sdb1[2] sde1[3]
19514240 blocks super 1.2 [2/2] [UU]
unused devices: <none>
Donc ok.
J'ai acheté un disque supplémentaire mais n'ai pas encore eu le temps de
l'installer.
Le 15-04-2019, à 17:11:22 +0200, Daniel Caillibaud a écrit :
> Il faudrait demander à mdadm d'être plus bavard quand il a un pb, mais je
> sais pas trop comment.
Rien dans la page man.
L'essentiel du verbe provient surtout de la sortie de `dmesg`.
Peut-être que des messages intéressants apparaissent au moment
de l'assemblage ?
Le 15-04-2019, à 22:24:20 +0200, Étienne Mollier a écrit :
Bonjour, steve, au 2019-04-15 :
Vraiment désolé, à l'envoi ça semblait correct.
Ce n'est pas très grave; on a qu'a dire que ça a justifié le démarrage de mon éditeur de texte préféré. :)
Sympa de le prendre comme ça :)
Le 12-04-2019, à 20:01:17 +0200, Étienne Mollier a écrit :
steve, au 2019-04-12 : > 1 box kernel: [ 3988.692314] Tainted: P OE ... ^~~~~~~ Le noyau est teinté, quelle en est la cause ? (ce devrait être indiqué quelque part dans la sortie de `dmesg`.)
driver nvidia proprio.
Bon, au moins on en a le cœur net, la teinture n'avait rien de vraiment pertinent, sauf malchance.
Si un sous système corrompt le noyau, alors il n'est peut-être pas nécessaire de chercher plus loin, et juste de le désactiver.
Je pourrais en effet essayer le driver libre « nouveau ». Mais la dernière fois que j'ai essayé, ce n'était vraiment pas très concluant.
Ça vaudrait peut-être quand même le coup de voir si le noyau est toujours teinté sans ce pilote, et si le problème se pose à nouveau.
Oui.
Sinon, plus prosaïquement, dans quel état se trouve le Raid actuellement ? Est-il toujours partiel ou bien le remplacement du disque en panne a eu lieu ? (cat /proc/mdstat)
J'avais trois disques dans la grappe dont un spare qui a pris du service quand j'ai débranché le disque défectueux. $ cat /proc/mdstat Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] md1 : active raid1 sdb5[2] sde5[3] 117120896 blocks super 1.2 [2/2] [UU] md2 : active raid1 sdb6[2] sde6[3] 97589120 blocks super 1.2 [2/2] [UU] md0 : active raid1 sdb1[2] sde1[3] 19514240 blocks super 1.2 [2/2] [UU] unused devices: <none> Donc ok. J'ai acheté un disque supplémentaire mais n'ai pas encore eu le temps de l'installer.
Le 15-04-2019, à 17:11:22 +0200, Daniel Caillibaud a écrit :
Il faudrait demander à mdadm d'être plus bavard quand il a un pb, mais je sais pas trop comment.
Rien dans la page man.
L'essentiel du verbe provient surtout de la sortie de `dmesg`. Peut-être que des messages intéressants apparaissent au moment de l'assemblage ?
$ dmesg | grep -i raid [ 2.196649] md/raid1:md2: active with 2 out of 2 mirrors [ 2.196906] md/raid1:md1: active with 2 out of 2 mirrors [ 2.197262] md/raid1:md0: active with 2 out of 2 mirrors [ 3.505941] raid6: sse2x1 gen() 11776 MB/s [ 3.573938] raid6: sse2x1 xor() 11147 MB/s [ 3.641939] raid6: sse2x2 gen() 18466 MB/s [ 3.709938] raid6: sse2x2 xor() 12826 MB/s [ 3.777939] raid6: sse2x4 gen() 20535 MB/s [ 3.845938] raid6: sse2x4 xor() 14214 MB/s [ 3.913939] raid6: avx2x1 gen() 29727 MB/s [ 3.981936] raid6: avx2x1 xor() 21553 MB/s [ 4.049938] raid6: avx2x2 gen() 34915 MB/s [ 4.117936] raid6: avx2x2 xor() 23875 MB/s [ 4.185936] raid6: avx2x4 gen() 37470 MB/s [ 4.253936] raid6: avx2x4 xor() 23632 MB/s [ 4.321939] raid6: avx512x1 gen() 35605 MB/s [ 4.389937] raid6: avx512x1 xor() 19965 MB/s [ 4.457938] raid6: avx512x2 gen() 44244 MB/s [ 4.525937] raid6: avx512x2 xor() 24960 MB/s [ 4.593937] raid6: avx512x4 gen() 50744 MB/s [ 4.661938] raid6: avx512x4 xor() 20318 MB/s [ 4.661938] raid6: using algorithm avx512x4 gen() 50744 MB/s [ 4.661939] raid6: .... xor() 20318 MB/s, rmw enabled [ 4.661939] raid6: using avx512x2 recovery algorithm Rien qui semble anormal (à part ces mentions de raid6 que je n'utilise pas). Merci encore. Steve
=c3
steve, au 2018-04-16 :
Le 15-04-2019, à 22:24:20 +0200, Étienne Mollier a écrit :
steve, au 2019-04-15 : > Le 12-04-2019, à 20:01:17 +0200, Étienne Mollier a écrit : > > Si un sous système corrompt le noyau, alors il n'est peut-être > > pas nécessaire de chercher plus loin, et juste de le désactiver. > > Je pourrais en effet essayer le driver libre « nouveau ». Mais la > dernière fois que j'ai essayé, ce n'était vraiment pas très concluant. Ça vaudrait peut-être quand même le coup de voir si le noyau est toujours teinté sans ce pilote, et si le problème se pose à nouveau.
Oui.
Bonjour, Au début, j'ai compris « Oui ça vaudrait le coup d'essayer! » Mais peut-être qu'il s'agit plutôt de « Oui, le problème se reproduit avec un noyau non teinté! »
Sinon, plus prosaïquement, dans quel état se trouve le Raid actuellement ? Est-il toujours partiel ou bien le remplacement du disque en panne a eu lieu ? (cat /proc/mdstat)
J'avais trois disques dans la grappe dont un spare qui a pris du service quand j'ai débranché le disque défectueux. $ cat /proc/mdstat Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] md1 : active raid1 sdb5[2] sde5[3] 117120896 blocks super 1.2 [2/2] [UU] md2 : active raid1 sdb6[2] sde6[3] 97589120 blocks super 1.2 [2/2] [UU] md0 : active raid1 sdb1[2] sde1[3] 19514240 blocks super 1.2 [2/2] [UU] unused devices: <none> Donc ok.
En dehors des freezes et des traces dans `dmesg`, tout me semble correct, donc la piste du bug noyau me semble envisageable. En jetant un œil aux changelogs, j'ai remarqué que Linux 4.19.24 a été publié avec une correction relative à la reconstruction de Raid 1 [0] indiquant notamment des risques de corruption, en cas d'interruption de la reconstruction notamment. [0] https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.19.24 Toutefois, je ne sais pas si vous vous êtes retrouvé dans la situation décrite par le changelog, ni si corruption il y a ; je crois qu'il y aurait aussi des erreurs relatives à votre système de fichier dans `dmesg` dans ce cas.
J'ai acheté un disque supplémentaire mais n'ai pas encore eu le temps de l'installer.
Si cette histoire de corruption à la reconstruction est avérée, alors je délayerais la reconstruction au moins à après mise à jour vers la dernière version de Linux 4.19 mise à disposition dans les backports. Amicalement, -- Étienne Mollier
steve, au 2018-04-16 :
Le 15-04-2019, à 22:24:20 +0200, Étienne Mollier a écrit :
> steve, au 2019-04-15 :
> > Le 12-04-2019, à 20:01:17 +0200, Étienne Mollier a écrit :
> > > Si un sous système corrompt le noyau, alors il n'est peut-être
> > > pas nécessaire de chercher plus loin, et juste de le désactiver.
> >
> > Je pourrais en effet essayer le driver libre « nouveau ». Mais la
> > dernière fois que j'ai essayé, ce n'était vraiment pas très concluant.
>
> Ça vaudrait peut-être quand même le coup de voir si le noyau est
> toujours teinté sans ce pilote, et si le problème se pose à nouveau.
Oui.
Bonjour,
Au début, j'ai compris « Oui ça vaudrait le coup d'essayer! »
Mais peut-être qu'il s'agit plutôt de « Oui, le problème se
reproduit avec un noyau non teinté! »
> Sinon, plus prosaïquement, dans quel état se trouve le Raid
> actuellement ? Est-il toujours partiel ou bien le remplacement
> du disque en panne a eu lieu ? (cat /proc/mdstat)
J'avais trois disques dans la grappe dont un spare qui a pris du service
quand j'ai débranché le disque défectueux.
md2 : active raid1 sdb6[2] sde6[3]
97589120 blocks super 1.2 [2/2] [UU]
md0 : active raid1 sdb1[2] sde1[3]
19514240 blocks super 1.2 [2/2] [UU]
unused devices: <none>
Donc ok.
En dehors des freezes et des traces dans `dmesg`, tout me semble
correct, donc la piste du bug noyau me semble envisageable. En
jetant un œil aux changelogs, j'ai remarqué que Linux 4.19.24 a
été publié avec une correction relative à la reconstruction de
Raid 1 [0] indiquant notamment des risques de corruption, en cas
d'interruption de la reconstruction notamment.
Toutefois, je ne sais pas si vous vous êtes retrouvé dans la
situation décrite par le changelog, ni si corruption il y a ;
je crois qu'il y aurait aussi des erreurs relatives à votre
système de fichier dans `dmesg` dans ce cas.
J'ai acheté un disque supplémentaire mais n'ai pas encore eu le temps de
l'installer.
Si cette histoire de corruption à la reconstruction est avérée,
alors je délayerais la reconstruction au moins à après mise à
jour vers la dernière version de Linux 4.19 mise à disposition
dans les backports.
Le 15-04-2019, à 22:24:20 +0200, Étienne Mollier a écrit :
steve, au 2019-04-15 : > Le 12-04-2019, à 20:01:17 +0200, Étienne Mollier a écrit : > > Si un sous système corrompt le noyau, alors il n'est peut-être > > pas nécessaire de chercher plus loin, et juste de le désactiver. > > Je pourrais en effet essayer le driver libre « nouveau ». Mais la > dernière fois que j'ai essayé, ce n'était vraiment pas très concluant. Ça vaudrait peut-être quand même le coup de voir si le noyau est toujours teinté sans ce pilote, et si le problème se pose à nouveau.
Oui.
Bonjour, Au début, j'ai compris « Oui ça vaudrait le coup d'essayer! » Mais peut-être qu'il s'agit plutôt de « Oui, le problème se reproduit avec un noyau non teinté! »
Sinon, plus prosaïquement, dans quel état se trouve le Raid actuellement ? Est-il toujours partiel ou bien le remplacement du disque en panne a eu lieu ? (cat /proc/mdstat)
J'avais trois disques dans la grappe dont un spare qui a pris du service quand j'ai débranché le disque défectueux. $ cat /proc/mdstat Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] md1 : active raid1 sdb5[2] sde5[3] 117120896 blocks super 1.2 [2/2] [UU] md2 : active raid1 sdb6[2] sde6[3] 97589120 blocks super 1.2 [2/2] [UU] md0 : active raid1 sdb1[2] sde1[3] 19514240 blocks super 1.2 [2/2] [UU] unused devices: <none> Donc ok.
En dehors des freezes et des traces dans `dmesg`, tout me semble correct, donc la piste du bug noyau me semble envisageable. En jetant un œil aux changelogs, j'ai remarqué que Linux 4.19.24 a été publié avec une correction relative à la reconstruction de Raid 1 [0] indiquant notamment des risques de corruption, en cas d'interruption de la reconstruction notamment. [0] https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.19.24 Toutefois, je ne sais pas si vous vous êtes retrouvé dans la situation décrite par le changelog, ni si corruption il y a ; je crois qu'il y aurait aussi des erreurs relatives à votre système de fichier dans `dmesg` dans ce cas.
J'ai acheté un disque supplémentaire mais n'ai pas encore eu le temps de l'installer.
Si cette histoire de corruption à la reconstruction est avérée, alors je délayerais la reconstruction au moins à après mise à jour vers la dernière version de Linux 4.19 mise à disposition dans les backports. Amicalement, -- Étienne Mollier
steve
Le 16-04-2019, à 21:09:29 +0200, Étienne Mollier a écrit :
> Je pourrais en effet essayer le driver libre « nouveau ». Mais la > dernière fois que j'ai essayé, ce n'était vraiment pas très concluant. Ça vaudrait peut-être quand même le coup de voir si le noyau est toujours teinté sans ce pilote, et si le problème se pose à nouveau.
Oui.
Bonjour, Au début, j'ai compris « Oui ça vaudrait le coup d'essayer! » Mais peut-être qu'il s'agit plutôt de « Oui, le problème se reproduit avec un noyau non teinté! »
Non :) Je n'ai pas encore essayé avec un noyau non teinté, mais je vais le faire quand j'aurais un peu plus de temps. Là j'ai besoin de la machine pour travailler.
En dehors des freezes et des traces dans `dmesg`, tout me semble correct, donc la piste du bug noyau me semble envisageable. En jetant un œil aux changelogs, j'ai remarqué que Linux 4.19.24 a été publié avec une correction relative à la reconstruction de Raid 1 [0] indiquant notamment des risques de corruption, en cas d'interruption de la reconstruction notamment. [0] https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.19.24
Merci pour le lien. Mais il ne me semble pas que ça soit proche de ma situation.
Toutefois, je ne sais pas si vous vous êtes retrouvé dans la situation décrite par le changelog, ni si corruption il y a ; je crois qu'il y aurait aussi des erreurs relatives à votre système de fichier dans `dmesg` dans ce cas.
J'ai bien peur que non. J'aimerais bien avoir plus d'information dans les différents fichiers journaux mais je ne sais pas trop comment et quoi activer.
J'ai acheté un disque supplémentaire mais n'ai pas encore eu le temps de l'installer.
Si cette histoire de corruption à la reconstruction est avérée, alors je délayerais la reconstruction au moins à après mise à jour vers la dernière version de Linux 4.19 mise à disposition dans les backports.
uname -a Linux box.maison.mrs 4.19.0-0.bpo.4-amd64 #1 SMP Debian 4.19.28-2~bpo9+1 (2019-03-27) x86_64 GNU/Linux Encore merci pour l'intérêt et les discussions intéressantes. Steve
Le 16-04-2019, à 21:09:29 +0200, Étienne Mollier a écrit :
> > Je pourrais en effet essayer le driver libre « nouveau ». Mais la
> > dernière fois que j'ai essayé, ce n'était vraiment pas très concluant.
>
> Ça vaudrait peut-être quand même le coup de voir si le noyau est
> toujours teinté sans ce pilote, et si le problème se pose à nouveau.
Oui.
Bonjour,
Au début, j'ai compris « Oui ça vaudrait le coup d'essayer! »
Mais peut-être qu'il s'agit plutôt de « Oui, le problème se
reproduit avec un noyau non teinté! »
Non :)
Je n'ai pas encore essayé avec un noyau non teinté, mais je vais le
faire quand j'aurais un peu plus de temps. Là j'ai besoin de la machine
pour travailler.
En dehors des freezes et des traces dans `dmesg`, tout me semble
correct, donc la piste du bug noyau me semble envisageable. En
jetant un œil aux changelogs, j'ai remarqué que Linux 4.19.24 a
été publié avec une correction relative à la reconstruction de
Raid 1 [0] indiquant notamment des risques de corruption, en cas
d'interruption de la reconstruction notamment.
Merci pour le lien. Mais il ne me semble pas que ça soit proche de ma
situation.
Toutefois, je ne sais pas si vous vous êtes retrouvé dans la
situation décrite par le changelog, ni si corruption il y a ;
je crois qu'il y aurait aussi des erreurs relatives à votre
système de fichier dans `dmesg` dans ce cas.
J'ai bien peur que non. J'aimerais bien avoir plus d'information dans
les différents fichiers journaux mais je ne sais pas trop comment et
quoi activer.
J'ai acheté un disque supplémentaire mais n'ai pas encore eu le temps de
l'installer.
Si cette histoire de corruption à la reconstruction est avérée,
alors je délayerais la reconstruction au moins à après mise à
jour vers la dernière version de Linux 4.19 mise à disposition
dans les backports.
uname -a
Linux box.maison.mrs 4.19.0-0.bpo.4-amd64 #1 SMP Debian 4.19.28-2~bpo9+1 (2019-03-27) x86_64 GNU/Linux
Encore merci pour l'intérêt et les discussions intéressantes.
Le 16-04-2019, à 21:09:29 +0200, Étienne Mollier a écrit :
> Je pourrais en effet essayer le driver libre « nouveau ». Mais la > dernière fois que j'ai essayé, ce n'était vraiment pas très concluant. Ça vaudrait peut-être quand même le coup de voir si le noyau est toujours teinté sans ce pilote, et si le problème se pose à nouveau.
Oui.
Bonjour, Au début, j'ai compris « Oui ça vaudrait le coup d'essayer! » Mais peut-être qu'il s'agit plutôt de « Oui, le problème se reproduit avec un noyau non teinté! »
Non :) Je n'ai pas encore essayé avec un noyau non teinté, mais je vais le faire quand j'aurais un peu plus de temps. Là j'ai besoin de la machine pour travailler.
En dehors des freezes et des traces dans `dmesg`, tout me semble correct, donc la piste du bug noyau me semble envisageable. En jetant un œil aux changelogs, j'ai remarqué que Linux 4.19.24 a été publié avec une correction relative à la reconstruction de Raid 1 [0] indiquant notamment des risques de corruption, en cas d'interruption de la reconstruction notamment. [0] https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.19.24
Merci pour le lien. Mais il ne me semble pas que ça soit proche de ma situation.
Toutefois, je ne sais pas si vous vous êtes retrouvé dans la situation décrite par le changelog, ni si corruption il y a ; je crois qu'il y aurait aussi des erreurs relatives à votre système de fichier dans `dmesg` dans ce cas.
J'ai bien peur que non. J'aimerais bien avoir plus d'information dans les différents fichiers journaux mais je ne sais pas trop comment et quoi activer.
J'ai acheté un disque supplémentaire mais n'ai pas encore eu le temps de l'installer.
Si cette histoire de corruption à la reconstruction est avérée, alors je délayerais la reconstruction au moins à après mise à jour vers la dernière version de Linux 4.19 mise à disposition dans les backports.
uname -a Linux box.maison.mrs 4.19.0-0.bpo.4-amd64 #1 SMP Debian 4.19.28-2~bpo9+1 (2019-03-27) x86_64 GNU/Linux Encore merci pour l'intérêt et les discussions intéressantes. Steve
steve
Logwatch me sort aussi: --------------------- Kernel Begin ------------------------ WARNING: Segmentation Faults in these executables sendmail : 3 Time(s) WARNING: Kernel Errors Present ACPI BIOS Error (bug): Failure c ...: 1 Time(s) ACPI Error: AE_ALREADY_EXIS ...: 1 Time(s) ACPI Error: Skip parsing op ...: 1 Time(s) [Firmware Bug]: TSC ADJUST differs within socket(s), fixing all errors ...: 1 Time(s) wil6210 0000:02:00.0: Direct firmware load for wil6210.fw failed with error -2 ...: 1 Time(s) ---------------------- Kernel End ------------------------- Le sendmail du segfault est celui du paquet dma (Dragonfly mail agent). Les erreurs BIOS, et bien, sont des erreurs BIOS (mis à jour très récemment, ce qui a diminué leur nombre). L'erreur sur le driver wil6210 n'a plus lieu d'être car j'ai désactivé le wifi dans le BIOS vu que je ne l'utilise pas (encore).
Logwatch me sort aussi:
--------------------- Kernel Begin ------------------------
WARNING: Segmentation Faults in these executables
sendmail : 3 Time(s)
WARNING: Kernel Errors Present
ACPI BIOS Error (bug): Failure c ...: 1 Time(s)
ACPI Error: AE_ALREADY_EXIS ...: 1 Time(s)
ACPI Error: Skip parsing op ...: 1 Time(s)
[Firmware Bug]: TSC ADJUST differs within socket(s), fixing all errors ...: 1 Time(s)
wil6210 0000:02:00.0: Direct firmware load for wil6210.fw failed with error -2 ...: 1 Time(s)
---------------------- Kernel End -------------------------
Le sendmail du segfault est celui du paquet dma (Dragonfly mail agent).
Les erreurs BIOS, et bien, sont des erreurs BIOS (mis à jour très
récemment, ce qui a diminué leur nombre).
L'erreur sur le driver wil6210 n'a plus lieu d'être car j'ai désactivé
le wifi dans le BIOS vu que je ne l'utilise pas (encore).
Logwatch me sort aussi: --------------------- Kernel Begin ------------------------ WARNING: Segmentation Faults in these executables sendmail : 3 Time(s) WARNING: Kernel Errors Present ACPI BIOS Error (bug): Failure c ...: 1 Time(s) ACPI Error: AE_ALREADY_EXIS ...: 1 Time(s) ACPI Error: Skip parsing op ...: 1 Time(s) [Firmware Bug]: TSC ADJUST differs within socket(s), fixing all errors ...: 1 Time(s) wil6210 0000:02:00.0: Direct firmware load for wil6210.fw failed with error -2 ...: 1 Time(s) ---------------------- Kernel End ------------------------- Le sendmail du segfault est celui du paquet dma (Dragonfly mail agent). Les erreurs BIOS, et bien, sont des erreurs BIOS (mis à jour très récemment, ce qui a diminué leur nombre). L'erreur sur le driver wil6210 n'a plus lieu d'être car j'ai désactivé le wifi dans le BIOS vu que je ne l'utilise pas (encore).
