Disky s vysokým loadem způsobí „kernel tainted“

Disky s vysokým loadem způsobí „kernel tainted“
« kdy: 01. 06. 2023, 15:05:38 »
Ahoj,

řeším technický problém na serveru dell t320, kde mám připojené, mimojiné, dva 8TB SATA disky v mdadm RAID1. Pokoušel jsem se změřit rychlost disů pomocí příkazu

Kód: [Vybrat]
fio --name=random-write --ioengine=posixaio --rw=randwrite --bs=4k --size=4g --numjobs=1 --iodepth=1 --runtime=60 --time_based --end_fsync=1

Po chvíli mi do logu naskáče následující sada chybových zpráv a server má vysoký load a je do rebootu nepoužitelný. Snažím se to vyřešit, ale nedaří se mi přijít na to v čem je problém.

Zkoušel jsem vyměnit disky a je to stále to samé. Kam byste mi doporučili se obrátit s reportem chyby? Na vývojáře jádra, mdadm, xfs? Případně nenapadá vás, co dál s tím?

Kód: [Vybrat]
May 31 22:01:31 datel kernel: INFO: task kworker/u96:1:12 blocked for more than 122 seconds.
May 31 22:01:31 datel kernel:       Tainted: G           OE    --------  ---  5.14.0-284.11.1.el9_2.x86_64 #1
May 31 22:01:31 datel kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
May 31 22:01:31 datel kernel: task:kworker/u96:1   state:D stack:    0 pid:   12 ppid:     2 flags:0x00004000
May 31 22:01:31 datel kernel: Workqueue: xfs-cil/md0 xlog_cil_push_work [xfs]
May 31 22:01:31 datel kernel: Call Trace:
May 31 22:01:31 datel kernel:  <TASK>
May 31 22:01:31 datel kernel:  __schedule+0x248/0x620
May 31 22:01:31 datel kernel:  schedule+0x5a/0xc0
May 31 22:01:31 datel kernel:  xlog_state_get_iclog_space+0x10d/0x340 [xfs]
May 31 22:01:31 datel kernel:  ? wake_up_q+0x90/0x90
May 31 22:01:31 datel kernel:  xlog_write+0x144/0x6f0 [xfs]
May 31 22:01:31 datel kernel:  xlog_cil_push_work+0x3b5/0x5a0 [xfs]
May 31 22:01:31 datel kernel:  ? pick_next_task_fair+0x41/0x490
May 31 22:01:31 datel kernel:  ? xfs_swap_extents+0x630/0x630 [xfs]
May 31 22:01:31 datel kernel:  process_one_work+0x1e8/0x3c0
May 31 22:01:31 datel kernel:  ? rescuer_thread+0x3a0/0x3a0
May 31 22:01:31 datel kernel:  worker_thread+0x50/0x3b0
May 31 22:01:31 datel kernel:  ? rescuer_thread+0x3a0/0x3a0
May 31 22:01:31 datel kernel:  kthread+0xd9/0x100
May 31 22:01:31 datel kernel:  ? kthread_complete_and_exit+0x20/0x20
May 31 22:01:31 datel kernel:  ret_from_fork+0x22/0x30
May 31 22:01:31 datel kernel:  </TASK>
May 31 22:01:31 datel kernel: INFO: task kworker/u96:6:121 blocked for more than 122 seconds.
May 31 22:01:31 datel kernel:       Tainted: G           OE    --------  ---  5.14.0-284.11.1.el9_2.x86_64 #1
May 31 22:01:31 datel kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
May 31 22:01:31 datel kernel: task:kworker/u96:6   state:D stack:    0 pid:  121 ppid:     2 flags:0x00004000
May 31 22:01:31 datel kernel: Workqueue: xfs-cil/md0 xlog_cil_push_work [xfs]
May 31 22:01:31 datel kernel: Call Trace:
May 31 22:01:31 datel kernel:  <TASK>
May 31 22:01:31 datel kernel:  __schedule+0x248/0x620
May 31 22:01:31 datel kernel:  schedule+0x5a/0xc0
May 31 22:01:31 datel kernel:  xlog_cil_order_write+0x19b/0x1c0 [xfs]
May 31 22:01:31 datel kernel:  ? wake_up_q+0x90/0x90
May 31 22:01:31 datel kernel:  xlog_cil_push_work+0x325/0x5a0 [xfs]
May 31 22:01:31 datel kernel:  ? pick_next_task_fair+0x41/0x490
May 31 22:01:31 datel kernel:  ? xfs_swap_extents+0x630/0x630 [xfs]
May 31 22:01:31 datel kernel:  process_one_work+0x1e8/0x3c0
May 31 22:01:31 datel kernel:  worker_thread+0x50/0x3b0
May 31 22:01:31 datel kernel:  ? rescuer_thread+0x3a0/0x3a0
May 31 22:01:31 datel kernel:  kthread+0xd9/0x100
May 31 22:01:31 datel kernel:  ? kthread_complete_and_exit+0x20/0x20
May 31 22:01:31 datel kernel:  ret_from_fork+0x22/0x30
May 31 22:01:31 datel kernel:  </TASK>
May 31 22:01:31 datel kernel: INFO: task kworker/u96:8:123 blocked for more than 122 seconds.
May 31 22:01:31 datel kernel:       Tainted: G           OE    --------  ---  5.14.0-284.11.1.el9_2.x86_64 #1
May 31 22:01:31 datel kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
May 31 22:01:31 datel kernel: task:kworker/u96:8   state:D stack:    0 pid:  123 ppid:     2 flags:0x00004000
May 31 22:01:31 datel kernel: Workqueue: xfs-cil/md0 xlog_cil_push_work [xfs]
May 31 22:01:31 datel kernel: Call Trace:
May 31 22:01:31 datel kernel:  <TASK>
May 31 22:01:31 datel kernel:  __schedule+0x248/0x620
May 31 22:01:31 datel kernel:  schedule+0x5a/0xc0
May 31 22:01:31 datel kernel:  xlog_cil_order_write+0x19b/0x1c0 [xfs]
May 31 22:01:31 datel kernel:  ? wake_up_q+0x90/0x90
May 31 22:01:31 datel kernel:  xlog_cil_push_work+0x325/0x5a0 [xfs]
May 31 22:01:31 datel kernel:  ? pick_next_task_fair+0x41/0x490
May 31 22:01:31 datel kernel:  ? xfs_swap_extents+0x630/0x630 [xfs]
May 31 22:01:31 datel kernel:  process_one_work+0x1e8/0x3c0
May 31 22:01:31 datel kernel:  worker_thread+0x50/0x3b0
May 31 22:01:31 datel kernel:  ? rescuer_thread+0x3a0/0x3a0
May 31 22:01:31 datel kernel:  kthread+0xd9/0x100
May 31 22:01:31 datel kernel:  ? kthread_complete_and_exit+0x20/0x20
May 31 22:01:31 datel kernel:  ret_from_fork+0x22/0x30
May 31 22:01:31 datel kernel:  </TASK>
May 31 22:01:31 datel kernel: INFO: task kworker/u96:13:128 blocked for more than 122 seconds.
May 31 22:01:31 datel kernel:       Tainted: G           OE    --------  ---  5.14.0-284.11.1.el9_2.x86_64 #1
May 31 22:01:31 datel kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
May 31 22:01:31 datel kernel: task:kworker/u96:13  state:D stack:    0 pid:  128 ppid:     2 flags:0x00004000
May 31 22:01:31 datel kernel: Workqueue: xfs-cil/md0 xlog_cil_push_work [xfs]
May 31 22:01:31 datel kernel: Call Trace:
May 31 22:01:31 datel kernel:  <TASK>
May 31 22:01:31 datel kernel:  __schedule+0x248/0x620
May 31 22:01:31 datel kernel:  schedule+0x5a/0xc0
May 31 22:01:31 datel kernel:  xlog_cil_order_write+0x19b/0x1c0 [xfs]
May 31 22:01:31 datel kernel:  ? wake_up_q+0x90/0x90
May 31 22:01:31 datel kernel:  xlog_cil_push_work+0x325/0x5a0 [xfs]
May 31 22:01:31 datel kernel:  ? pick_next_task_fair+0x41/0x490
May 31 22:01:31 datel kernel:  ? xfs_swap_extents+0x630/0x630 [xfs]
May 31 22:01:31 datel kernel:  process_one_work+0x1e8/0x3c0
May 31 22:01:31 datel kernel:  worker_thread+0x50/0x3b0
May 31 22:01:31 datel kernel:  ? rescuer_thread+0x3a0/0x3a0
May 31 22:01:31 datel kernel:  kthread+0xd9/0x100
May 31 22:01:31 datel kernel:  ? kthread_complete_and_exit+0x20/0x20
May 31 22:01:31 datel kernel:  ret_from_fork+0x22/0x30
May 31 22:01:31 datel kernel:  </TASK>
May 31 22:01:31 datel kernel: INFO: task kworker/5:1:330 blocked for more than 122 seconds.
May 31 22:01:31 datel kernel:       Tainted: G           OE    --------  ---  5.14.0-284.11.1.el9_2.x86_64 #1
May 31 22:01:31 datel kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
May 31 22:01:31 datel kernel: task:kworker/5:1     state:D stack:    0 pid:  330 ppid:     2 flags:0x00004000
May 31 22:01:31 datel kernel: Workqueue: xfs-sync/md0 xfs_log_worker [xfs]
May 31 22:01:31 datel kernel: Call Trace:
May 31 22:01:31 datel kernel:  <TASK>
May 31 22:01:31 datel kernel:  __schedule+0x248/0x620
May 31 22:01:31 datel kernel:  schedule+0x5a/0xc0
May 31 22:01:31 datel kernel:  schedule_timeout+0x11d/0x160
May 31 22:01:31 datel kernel:  ? load_balance+0x492/0x6d0
May 31 22:01:31 datel kernel:  __wait_for_common+0x93/0x1d0
May 31 22:01:31 datel kernel:  ? usleep_range_state+0x90/0x90
May 31 22:01:31 datel kernel:  __flush_workqueue+0x13a/0x3f0
May 31 22:01:31 datel kernel:  xlog_cil_push_now.isra.0+0x63/0xa0 [xfs]
May 31 22:01:31 datel kernel:  xlog_cil_force_seq+0x73/0x240 [xfs]
May 31 22:01:31 datel kernel:  ? pick_next_task+0x854/0x940
May 31 22:01:31 datel kernel:  ? __update_idle_core+0x1b/0xb0
May 31 22:01:31 datel kernel:  xfs_log_force+0x7a/0x230 [xfs]
May 31 22:01:31 datel kernel:  xfs_log_worker+0x35/0x80 [xfs]
May 31 22:01:31 datel kernel:  process_one_work+0x1e8/0x3c0
May 31 22:01:31 datel kernel:  ? rescuer_thread+0x3a0/0x3a0
May 31 22:01:31 datel kernel:  worker_thread+0x50/0x3b0
May 31 22:01:31 datel kernel:  ? rescuer_thread+0x3a0/0x3a0
May 31 22:01:31 datel kernel:  kthread+0xd9/0x100
May 31 22:01:31 datel kernel:  ? kthread_complete_and_exit+0x20/0x20
May 31 22:01:31 datel kernel:  ret_from_fork+0x22/0x30
May 31 22:01:31 datel kernel:  </TASK>
May 31 22:01:31 datel kernel: INFO: task fio:7198 blocked for more than 122 seconds.
May 31 22:01:31 datel kernel:       Tainted: G           OE    --------  ---  5.14.0-284.11.1.el9_2.x86_64 #1
May 31 22:01:31 datel kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
May 31 22:01:31 datel kernel: task:fio             state:D stack:    0 pid: 7198 ppid:  7101 flags:0x00000002
May 31 22:01:31 datel kernel: Call Trace:
May 31 22:01:31 datel kernel:  <TASK>
May 31 22:01:31 datel kernel:  __schedule+0x248/0x620
May 31 22:01:31 datel kernel:  schedule+0x5a/0xc0
May 31 22:01:31 datel kernel:  io_schedule+0x42/0x70
May 31 22:01:31 datel kernel:  folio_wait_bit_common+0x147/0x380
May 31 22:01:31 datel kernel:  ? find_get_pages_range_tag+0x19e/0x220
May 31 22:01:31 datel kernel:  ? file_check_and_advance_wb_err+0xd0/0xd0
May 31 22:01:31 datel kernel:  folio_wait_writeback+0x28/0x80
May 31 22:01:31 datel kernel:  write_cache_pages+0x12a/0x4c0
May 31 22:01:31 datel kernel:  ? iomap_writepage_map+0x530/0x530
May 31 22:01:31 datel kernel:  iomap_writepages+0x1c/0x40
May 31 22:01:31 datel kernel:  xfs_vm_writepages+0x7a/0xb0 [xfs]
May 31 22:01:31 datel kernel:  do_writepages+0xcf/0x1d0
May 31 22:01:31 datel kernel:  ? __schedule+0x250/0x620
May 31 22:01:31 datel kernel:  ? timerqueue_del+0x2a/0x50
May 31 22:01:31 datel kernel:  filemap_fdatawrite_wbc+0x66/0x90
May 31 22:01:31 datel kernel:  file_write_and_wait_range+0x9c/0x100
May 31 22:01:31 datel kernel:  xfs_file_fsync+0x5a/0x220 [xfs]
May 31 22:01:31 datel kernel:  ? __x64_sys_futex+0x73/0x1d0
May 31 22:01:31 datel kernel:  __x64_sys_fsync+0x33/0x60
May 31 22:01:31 datel kernel:  do_syscall_64+0x5c/0x90
May 31 22:01:31 datel kernel:  ? do_syscall_64+0x69/0x90
May 31 22:01:31 datel kernel:  ? __rseq_handle_notify_resume+0x32/0x50
May 31 22:01:31 datel kernel:  ? exit_to_user_mode_loop+0xd0/0x130
May 31 22:01:31 datel kernel:  ? exit_to_user_mode_prepare+0xec/0x100
May 31 22:01:31 datel kernel:  ? syscall_exit_to_user_mode+0x12/0x30
May 31 22:01:31 datel kernel:  ? do_syscall_64+0x69/0x90
May 31 22:01:31 datel kernel:  ? do_syscall_64+0x69/0x90
May 31 22:01:31 datel kernel:  ? do_syscall_64+0x69/0x90
May 31 22:01:31 datel kernel:  ? do_syscall_64+0x69/0x90
May 31 22:01:31 datel kernel:  ? do_syscall_64+0x69/0x90
May 31 22:01:31 datel kernel:  ? sysvec_apic_timer_interrupt+0x3c/0x90
May 31 22:01:31 datel kernel:  entry_SYSCALL_64_after_hwframe+0x63/0xcd
May 31 22:01:31 datel kernel: RIP: 0033:0x7fb3d5d452db
May 31 22:01:31 datel kernel: RSP: 002b:00007fb3d5f02e80 EFLAGS: 00000293 ORIG_RAX: 000000000000004a
May 31 22:01:31 datel kernel: RAX: ffffffffffffffda RBX: 0000555e78ef2f28 RCX: 00007fb3d5d452db
May 31 22:01:31 datel kernel: RDX: 0000000000000002 RSI: 0000000000000002 RDI: 0000000000000006
May 31 22:01:31 datel kernel: RBP: 0000000000000006 R08: 0000000000000000 R09: 00007fb3d5e00ba8
May 31 22:01:31 datel kernel: R10: 0000000000000000 R11: 0000000000000293 R12: 00007fb3d5dfa2c0
May 31 22:01:31 datel kernel: R13: 00007fb3d5f03740 R14: 00007fb3d5f02eb8 R15: 0000555e78ecf340
May 31 22:01:31 datel kernel:  </TASK>
« Poslední změna: 01. 06. 2023, 15:25:44 od Petr Krčmář »


RDa

  • *****
  • 2 467
    • Zobrazit profil
    • E-mail
Re:disy s vysokym loadem "kernel tained" - kam s reportem chyby?
« Odpověď #1 kdy: 01. 06. 2023, 15:17:27 »
Imho to je chyba v XFS, google nachazi nekolik reportu na:

xfs hung task
xfs cil hung task

tak mrkni zda to neni neco existujiciho.

Ale kdyz to je RHEL 9.2 nejspis (soude dle kernelu..) tak to muzes primo omlatit o hlavu RedHat-u.. kdyz se tak vzorne staraji o to stare "stabilni" jadro :)

Re:Disky s vysokým loadem způsobí „kernel tainted“
« Odpověď #2 kdy: 01. 06. 2023, 19:45:36 »
Diky za radu. Je to AlmaLinux 9.2 (tzn. spravne rikas Red Hat). V XFS to nebude, zkusil jsem ext4 a vysledek je stejny. Nemuze to byt diskama? Resp. jak bych prisel na to, ze nektery z tech disku spatny? Smart mi nic zajimaveho asi nerika. Nebo treba kabely? Je to mozne? Moc se mi to nezda, protoze mam dve dvojice disku pripojene do desky a do radice (perc h310) a ruzne to prehazuju...



[19907.466844] INFO: task jbd2/md0-8:7177 blocked for more than 122 seconds.
[19907.466917]       Tainted: G           OE    --------  ---  5.14.0-284.11.1.el9_2.x86_64 #1
[19907.466979] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[19907.467036] task:jbd2/md0-8      state:D stack:    0 pid: 7177 ppid:     2 flags:0x00004000
[19907.467104] Call Trace:
[19907.467126]  <TASK>
[19907.467147]  __schedule+0x248/0x620
[19907.467191]  schedule+0x5a/0xc0
[19907.467223]  io_schedule+0x42/0x70
[19907.467255]  bit_wait_io+0xd/0x60
[19907.467287]  __wait_on_bit+0x4b/0x150
[19907.467320]  ? bit_wait+0x60/0x60
[19907.467352]  out_of_line_wait_on_bit+0x92/0xb0
[19907.467393]  ? __ia32_sys_membarrier+0x20/0x20
[19907.467437]  jbd2_journal_commit_transaction+0x145f/0x1870 [jbd2]
[19907.467514]  kjournald2+0xaf/0x280 [jbd2]
[19907.467568]  ? cpuacct_percpu_seq_show+0x10/0x10
[19907.467609]  ? jbd2_journal_release_jbd_inode+0x150/0x150 [jbd2]
[19907.467673]  kthread+0xd9/0x100
[19907.467703]  ? kthread_complete_and_exit+0x20/0x20
[19907.467744]  ret_from_fork+0x22/0x30
[19907.467798]  </TASK>
[19907.467825] INFO: task dd:7293 blocked for more than 122 seconds.
[19907.467872]       Tainted: G           OE    --------  ---  5.14.0-284.11.1.el9_2.x86_64 #1
[19907.467933] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[19907.467990] task:dd              state:D stack:    0 pid: 7293 ppid:  7263 flags:0x00004006
[19907.468054] Call Trace:
[19907.468075]  <TASK>
[19907.468096]  __schedule+0x248/0x620
[19907.468132]  schedule+0x5a/0xc0
[19907.468163]  jbd2_log_wait_commit+0xa3/0x110 [jbd2]
[19907.468223]  ? cpuacct_percpu_seq_show+0x10/0x10
[19907.468264]  ext4_sync_file+0xd4/0x370 [ext4]
[19907.468374]  ext4_buffered_write_iter+0xe8/0x110 [ext4]
[19907.468472]  new_sync_write+0xff/0x190
[19907.468515]  vfs_write+0x1ef/0x280
[19907.468547]  ksys_write+0x5f/0xe0
[19907.468577]  do_syscall_64+0x5c/0x90
[19907.468612]  ? __rseq_handle_notify_resume+0x32/0x50
[19907.468654]  ? exit_to_user_mode_loop+0xd0/0x130
[19907.468696]  ? exit_to_user_mode_prepare+0xec/0x100
[19907.468738]  ? syscall_exit_to_user_mode+0x12/0x30
[19907.468788]  ? do_syscall_64+0x69/0x90
[19907.468826]  ? exc_page_fault+0x62/0x150
[19907.468863]  entry_SYSCALL_64_after_hwframe+0x63/0xcd
[19907.470513] RIP: 0033:0x7f910cd3eb97
[19907.472151] RSP: 002b:00007fff72788ba8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
[19907.473829] RAX: ffffffffffffffda RBX: 0000000040000000 RCX: 00007f910cd3eb97
[19907.475509] RDX: 0000000040000000 RSI: 00007f90ccbfe000 RDI: 0000000000000001
[19907.477212] RBP: 00007f90ccbfe000 R08: 00007f90ccbfe000 R09: 0000000000000000
[19907.478916] R10: 0000000000000022 R11: 0000000000000246 R12: 0000000000000000
[19907.480615] R13: 0000000000000000 R14: 0000000000000000 R15: 00007f90ccbfe000
[19907.482304]  </TASK>
[\tt]

Re:Disky s vysokým loadem způsobí „kernel tainted“
« Odpověď #3 kdy: 01. 06. 2023, 21:57:53 »
Pokud připojím disk bez raidu, můžu s ním dělat co chci a nevyfailuje (ani jeden). Tak co mi zbývá? Mdadm a kombinace mdadm a kernel a filesystem. Takže kam jít reportovat problém s mdadm? To je přímo v jádře, že, takže asi na kernel.org?

RDa

  • *****
  • 2 467
    • Zobrazit profil
    • E-mail
Re:Disky s vysokým loadem způsobí „kernel tainted“
« Odpověď #4 kdy: 02. 06. 2023, 10:38:36 »
Vidim.. zkus nechatt ten Raid1 jen s jednim diskem , druhy vypni pres mdadm --fail, zda tam neni nejaky problem v soubehu. V logu je chyba u zapisu, ale treba u cteni mdadm pouziva oba disky v pripade vicevlaknove zateze.

Jina chyba tam neni drive? (protoze tohle co vidim neni ani o discich ci raidu). Zachytny bod je zde:  "task jbd2/md0 hung" ... takze pokud umira proces zurnalu.. muze za to jeho disk - tj. md ... ale proc by umiral ten?


Re:Disky s vysokým loadem způsobí „kernel tainted“
« Odpověď #5 kdy: 02. 06. 2023, 17:32:21 »
Tak jsem zkusil Almalinux 8 live a tam to funguje. Takže je to nejspíš v mdadm/jádře almalinuxu 9.2. Počkám pár dnů a updatuju balíky, třeba to bude opravené.

Děkuju RDa za pomoc. Vyzkouším i poslední tvoje doporučení s rozpadlým raidem. Jiná chyba v logu není.


Re:Disky s vysokým loadem způsobí „kernel tainted“
« Odpověď #6 kdy: 02. 06. 2023, 17:46:48 »
1. "kernel tainted" nezpůsobila ta zátěž, ve vašem případě to znamená jen tolik, že tam máte nějaký out of tree modul, a to dávno předtím, než jste pustil tu zátěž, jak si můžete snadno ověřit čtením /proc/sys/kernel/tainted

2. Co se opravdu stalo při té zátěži, je, že hung task detector vyhodnotil, že nějaká úloha "visí", přesněji, že proces ve stavu "D" (uninterruptible sleep) nedostal po určitou dobu procesor. Za normálních okolností to může skutečně znamenat, že "se něco kouslo", ale při extrémní zátěži to docela dobře může být jen vedlejší efekt celkového přetížení. Takže bych prostě počkal, jestli se z toho systém nakonec zotaví; pokud ne, je to chyba, pokud ano, je to prostě jen dočasný stav, který je důsledkem toho testu. Mimochodem, přímo v tom logu máte návod, jak ten detektor vypnout.

Re:Disky s vysokým loadem způsobí „kernel tainted“
« Odpověď #7 kdy: 02. 06. 2023, 18:59:47 »
1) Aha, takže to, že je kernel tained je tam vypsáno protože je to nestandardní a když už se vyskytla ta chyba, tak se to vypsalo jako varování a hint. On je totiž "tained" ihned po restartu, a to proto, že používám modul mpt3sas z elrepo. Ovšem "hang task detector" zasahuje i v případě, že ho v jádře nemám.

2) Je tedy dost možné, že ten "hang task detector" vyhodnotí poměrně správně, že  je systém přetížený a "zavěsí". V mém případě má po "zavěšení" systém neustále vysoký load bez zjevné příčiny a ten neklesá několik hodin.

Spuštěním příkazu `echo 0 > /proc/sys/kernel/hung_task_timeout_secs"` dojde pouze k vypnutí té chybovky, nikoliv k zamezení "zavěšení", že?

Je nějaké snadné vysvětlení, proč mi to na Alma8.7 nedělá a na Alma9.2 ano? Jinak nastavené parametry jádra nebo hang task detectoru či jiná magie?

Re:Disky s vysokým loadem způsobí „kernel tainted“
« Odpověď #8 kdy: 02. 06. 2023, 23:19:45 »
1. Taint flags jsou pomocný příznak upozorňující, na něco nestandardního, proto se vypisují u všech varování a paniců, aby. Out of tree modul je možná nejčastější, ale je i spousta dalších, hodně užitečný je i třeba W, který znamená, že už tam nějaký warning byl předtím, takže to, co vidíme v logu, může být až důsledek úplně jiného primárního problému.

2. Pozor, load average je trochu matoucí ukazatel, který automaticky neznamená, že je systém opravdu zatížený. Každý proces, který je ve stavu "D" (uninterruptible sleep), se započítá jako jednička, i kdyby nedělal vůbec nic a jen čekal na nějaký zámek, dokončení operace apod. Pokud je odchytil hung task detector, tak to téměř určitě znamená, že je to přesně tenhle případ. Může to být bug, kdy někdo ten zámek vůbec neuvolnil, když měl, může to být deadlock atd. Pokud se z toho ten systém vůbec nevzpamatuje ani po několika hodinách, tak to pravděpodobně nějaký takový případ bude.

3. Ano, potlačení hung task detektoru má smysl, pokud jde o falešný poplach, pokud je ten stav trvalý, nic to neřeší.

4. Může to být bug, který se vyskytuje jen v konkrétní verzi jádra. To by se někdo musel pořádně podívat na stav systému ve chvíli, kdy k tomu dojde. Ideálním prostředkem k tomu je crash dump, jednodušší (ale méně informačně hodnotnou) alternativou je výpis zásobníků všech tasků pomocí Alt-SysRq-T. V každém případě by bylo dobré, aby se na to podíval někdo, kdo se vyzná v příslušné části jádra, v tomto případě bych tipoval filesystém (spíš ne, pokud se to dá reprodukovat na dvou různých, leda že by to byla přímo obecná vrstva VFS), block layer nebo konkrétní storage.

Re:Disky s vysokým loadem způsobí „kernel tainted“
« Odpověď #9 kdy: 05. 06. 2023, 15:47:23 »
Michale děkuji Vám za opdovědi a vysvětlení. Moc mě odpovědi posunuly a pročetl jsem se díky nim k mnoha dalším tématům a získal přestavu o tom, jak moc toho neumím :).

Crashdumpem nebudu otravovat, sysrq ještě zkusím, ale víc pozornosti už tomu problému věnovat nebudu.

Děkuju