Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

INFO: task blocked for more than 120 seconds

14 réponses
Avatar
steve
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. Dans les logs, j'ai ça:

1 box kernel: [ 3988.692306] INFO: task md1_raid1:406 blocked for more than 120 seconds.
1 box kernel: [ 3988.692314] Tainted: P OE 4.19.0-0.bpo.2-amd64 #1 Debian 4.19.16-1~bpo9+1
1 box kernel: [ 3988.692316] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
1 box kernel: [ 3988.692320] md1_raid1 D 0 406 2 0x80000000
1 box kernel: [ 3988.692324] Call Trace:
1 box kernel: [ 3988.692337] ? __schedule+0x3f5/0x880
1 box kernel: [ 3988.692342] schedule+0x32/0x80
1 box kernel: [ 3988.692356] md_super_wait+0x6e/0xa0 [md_mod]
1 box kernel: [ 3988.692365] ? remove_wait_queue+0x60/0x60
1 box kernel: [ 3988.692373] md_update_sb.part.61+0x4af/0x910 [md_mod]
1 box kernel: [ 3988.692381] md_check_recovery+0x312/0x530 [md_mod]
1 box kernel: [ 3988.692388] raid1d+0x60/0x8c0 [raid1]
1 box kernel: [ 3988.692394] ? schedule+0x32/0x80
1 box kernel: [ 3988.692398] ? schedule_timeout+0x1e5/0x350
1 box kernel: [ 3988.692405] ? md_thread+0x125/0x170 [md_mod]
1 box kernel: [ 3988.692411] md_thread+0x125/0x170 [md_mod]
1 box kernel: [ 3988.692416] ? remove_wait_queue+0x60/0x60
1 box kernel: [ 3988.692420] kthread+0xf8/0x130
1 box kernel: [ 3988.692427] ? md_rdev_init+0xc0/0xc0 [md_mod]
1 box kernel: [ 3988.692430] ? kthread_create_worker_on_cpu+0x70/0x70
1 box kernel: [ 3988.692433] ret_from_fork+0x35/0x40
1 box kernel: [ 3988.692438] INFO: task md0_raid1:411 blocked for more than 120 seconds.
1 box kernel: [ 3988.692441] Tainted: P OE 4.19.0-0.bpo.2-amd64 #1 Debian 4.19.16-1~bpo9+1
1 box kernel: [ 3988.692443] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
1 box kernel: [ 3988.692446] md0_raid1 D 0 411 2 0x80000000
[...]
1 box kernel: [ 3988.692539] INFO: task jbd2/md0-8:985 blocked for more than 120 seconds.
1 box kernel: [ 3988.692542] Tainted: P OE 4.19.0-0.bpo.2-amd64 #1 Debian 4.19.16-1~bpo9+1
1 box kernel: [ 3988.692544] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
1 box kernel: [ 3988.692546] jbd2/md0-8 D 0 985 2 0x80000000
1 box kernel: [ 3988.692549] Call Trace:
[...]
1 box kernel: [ 3988.692730] INFO: task jbd2/md1-8:994 blocked for more than 120 seconds.
1 box kernel: [ 3988.692733] Tainted: P OE 4.19.0-0.bpo.2-amd64 #1 Debian 4.19.16-1~bpo9+1
1 box kernel: [ 3988.692735] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
1 box kernel: [ 3988.692737] jbd2/md1-8 D 0 994 2 0x80000000
[...]
1 box kernel: [ 3988.692896] INFO: task uptimed:1161 blocked for more than 120 seconds.
1 box kernel: [ 3988.692899] Tainted: P OE 4.19.0-0.bpo.2-amd64 #1 Debian 4.19.16-1~bpo9+1
1 box kernel: [ 3988.692901] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
1 box kernel: [ 3988.692904] uptimed D 0 1161 1 0x00000080
1 box kernel: [ 3988.692906] Call Trace:
[...]
1 box kernel: [ 3988.693069] RIP: 0033:0x7fdf53aaa6f0
1 box kernel: [ 3988.693076] Code: Bad RIP value.
1 box kernel: [ 3988.693078] RSP: 002b:00007ffece358a28 EFLAGS: 00000246 ORIG_RAX: 0000000000000002
1 box kernel: [ 3988.693082] RAX: ffffffffffffffda RBX: 0000564ce8e167b0 RCX: 00007fdf53aaa6f0
1 box kernel: [ 3988.693083] RDX: 00000000000001b6 RSI: 0000000000000241 RDI: 00007fdf53d702b0
1 box kernel: [ 3988.693085] RBP: 0000000000000004 R08: 0000000000000004 R09: 0000000000000001
1 box kernel: [ 3988.693087] R10: 0000000000000240 R11: 0000000000000246 R12: 00007fdf53d7042d
1 box kernel: [ 3988.693088] R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000000
1 box kernel: [ 3988.693119] INFO: task fetchmail:3244 blocked for more than 120 seconds.
1 box kernel: [ 3988.693122] Tainted: P OE 4.19.0-0.bpo.2-amd64 #1 Debian 4.19.16-1~bpo9+1
1 box kernel: [ 3988.693124] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
1 box kernel: [ 3988.693127] fetchmail D 0 3244 1 0x00000080
1 box kernel: [ 3988.693129] Call Trace:
1 box kernel: [ 3988.693331] RIP: 0033:0x7ff77cd21970
[...]
1 box kernel: [ 3988.693335] Code: Bad RIP value.
1 box kernel: [ 3988.693336] RSP: 002b:00007ffd2b5b26f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
1 box kernel: [ 3988.693339] RAX: ffffffffffffffda RBX: 0000000000000050 RCX: 00007ff77cd21970
1 box kernel: [ 3988.693341] RDX: 0000000000000050 RSI: 000055b1c5456900 RDI: 0000000000000001
1 box kernel: [ 3988.693343] RBP: 000055b1c5456900 R08: 00007ff77cfe1760 R09: 00007ff77e682740
1 box kernel: [ 3988.693344] R10: 0000000000000073 R11: 0000000000000246 R12: 0000000000000050
1 box kernel: [ 3988.693346] R13: 0000000000000001 R14: 00007ff77cfe0600 R15: 0000000000000050
1 box kernel: [ 3988.693362] INFO: task kworker/u56:0:7704 blocked for more than 120 seconds.
1 box kernel: [ 3988.693365] Tainted: P OE 4.19.0-0.bpo.2-amd64 #1 Debian 4.19.16-1~bpo9+1
1 box kernel: [ 3988.693367] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
1 box kernel: [ 3988.693370] kworker/u56:0 D 0 7704 2 0x80000080
1 box kernel: [ 3988.693378] Workqueue: writeback wb_workfn (flush-9:0)
[...]
1 box kernel: [ 3988.693635] INFO: task kworker/u56:2:10260 blocked for more than 120 seconds.
1 box kernel: [ 3988.693639] Tainted: P OE 4.19.0-0.bpo.2-amd64 #1 Debian 4.19.16-1~bpo9+1
1 box kernel: [ 3988.693640] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
1 box kernel: [ 3988.693643] kworker/u56:2 D 0 10260 2 0x80000080
1 box kernel: [ 3988.693650] Workqueue: writeback wb_workfn (flush-9:1)
1 box kernel: [ 3988.693804] INFO: task lpqd:10309 blocked for more than 120 seconds.
[...]
1 box kernel: [ 3988.693806] Tainted: P OE 4.19.0-0.bpo.2-amd64 #1 Debian 4.19.16-1~bpo9+1
1 box kernel: [ 3988.693808] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
1 box kernel: [ 3988.693811] lpqd D 0 10309 2682 0x00000080
1 box kernel: [ 3988.693813] Call Trace:
[...]
1 box kernel: [ 3988.693949] RIP: 0033:0x7f98a07789e7
1 box kernel: [ 3988.693953] Code: Bad RIP value.
1 box kernel: [ 3988.693954] RSP: 002b:00007ffcce9c2e58 EFLAGS: 00000202 ORIG_RAX: 0000000000000031
1 box kernel: [ 3988.693957] RAX: ffffffffffffffda RBX: 0000564564def780 RCX: 00007f98a07789e7
1 box kernel: [ 3988.693959] RDX: 000000000000006e RSI: 00007ffcce9c2f40 RDI: 0000000000000007
1 box kernel: [ 3988.693960] RBP: 0000564564e17360 R08: 00007f98a0a28f78 R09: 0000000000000410
1 box kernel: [ 3988.693962] R10: 00000000000002f0 R11: 0000000000000202 R12: 0000000000000007
1 box kernel: [ 3988.693963] R13: 00007ffcce9c2f40 R14: 0000564564e177f8 R15: 0000564564e188b0
1 box kernel: [ 4109.529828] INFO: task systemd:1 blocked for more than 120 seconds.
1 box kernel: [ 4109.529836] Tainted: P OE 4.19.0-0.bpo.2-amd64 #1 Debian 4.19.16-1~bpo9+1
1 box kernel: [ 4109.529838] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
1 box kernel: [ 4109.529841] systemd D 0 1 0 0x00000000
1 box kernel: [ 4109.529846] Call Trace:
[...]
1 box kernel: [ 4109.530016] RIP: 0033:0x7fca74ec2687
1 box kernel: [ 4109.530023] Code: Bad RIP value.
1 box kernel: [ 4109.530025] RSP: 002b:00007ffc280fb378 EFLAGS: 00000246 ORIG_RAX: 0000000000000053
1 box kernel: [ 4109.530029] RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007fca74ec2687
1 box kernel: [ 4109.530030] RDX: 00000000000002ee RSI: 00000000000001c0 RDI: 000055d88ed7d220
1 box kernel: [ 4109.530032] RBP: 000000000003a2f8 R08: 0000000000000000 R09: 0000000000000070
1 box kernel: [ 4109.530034] R10: 0000000000000000 R11: 0000000000000246 R12: 000055d88ed7d272
1 box kernel: [ 4109.530036] R13: 8421084210842109 R14: 00000000000000c2 R15: 00007fca74f50540

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.

Je suis complètement à court d'idée.

Et vous ?

Merci d'avance,
Steve

10 réponses

1 2
Avatar
=c3
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
Avatar
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
Avatar
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.
Avatar
steve
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
Avatar
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.
Avatar
=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
Avatar
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
Avatar
=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
Avatar
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
Avatar
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).
1 2