0

I am seeing "Call Traces" on booting from Rhel * (4.18.0-235.el8.x86_64). The call traces appears after cold boot. I don't see any other issues. It is known issue

I see a thread stuck at the point, and dont know why it is stuck. Is it a known in RHEL8.

void percpu_ref_switch_to_atomic_sync(struct percpu_ref *ref)
{
    percpu_ref_switch_to_atomic(ref, NULL);
    wait_event(percpu_ref_switch_waitq, !ref->confirm_switch);
}

Therefore, once the thread initiates the request to switch to atomic, it waits for the "confirm_switch" to be reset to empty to indicate that the operation has completed.

Sep 26 14:40:59 dhcp-134-111-74-24 kernel: CPU: 32 PID: 2136 Comm: md126_raid1 Tainted: G           OE    --------- -  - 4.18.0-235.el8.x86_64 #1
...
Sep 26 14:40:59 dhcp-134-111-74-24 kernel: RIP: 0010:__percpu_ref_switch_mode+0x17d/0x190
Sep 26 14:40:59 dhcp-134-111-74-24 kernel: Code: 89 43 08 e9 7c ff ff ff 4d 85 e4 0f 84 73 ff ff ff 48 89 df e8 74 f6 7a 00 e9 66 ff ff ff f0 48 83 03 01 e9 4c ff ff ff 0f 0b <0f> 0b e9 53 ff ff ff e8 07 3c c6 ff 0f 1f 80 00 00 00 00 41 54 49
Sep 26 14:40:59 dhcp-134-111-74-24 kernel: RSP: 0018:ffffbc3d47d77cf0 EFLAGS: 00010046
Sep 26 14:40:59 dhcp-134-111-74-24 kernel: RAX: 000049454f61d951 RBX: ffff92f7ec9a0338 RCX: dead000000000200
Sep 26 14:40:59 dhcp-134-111-74-24 kernel: RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff92f7ec9a0338
Sep 26 14:40:59 dhcp-134-111-74-24 kernel: RBP: 000049454f61d950 R08: ffffffff95d23eb8 R09: 0000000000000000
Sep 26 14:40:59 dhcp-134-111-74-24 kernel: R10: 0000000000000000 R11: 00000008fe870580 R12: 0000000000000000
Sep 26 14:40:59 dhcp-134-111-74-24 kernel: R13: 0000000000000001 R14: ffff92efef718800 R15: ffffffff950b5d90
Sep 26 14:40:59 dhcp-134-111-74-24 kernel: FS:  0000000000000000(0000) GS:ffff92f01fa00000(0000) knlGS:0000000000000000
Sep 26 14:40:59 dhcp-134-111-74-24 kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Sep 26 14:40:59 dhcp-134-111-74-24 kernel: CR2: 000055aaad941250 CR3: 0000000f2fa0a002 CR4: 00000000007606a0
Sep 26 14:40:59 dhcp-134-111-74-24 kernel: DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
Sep 26 14:40:59 dhcp-134-111-74-24 kernel: DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Sep 26 14:40:59 dhcp-134-111-74-24 kernel: PKRU: 55555554
Sep 26 14:40:59 dhcp-134-111-74-24 kernel: Call Trace:
Sep 26 14:40:59 dhcp-134-111-74-24 kernel: ? percpu_ref_switch_to_atomic_sync+0x6a/0x90
Sep 26 14:40:59 dhcp-134-111-74-24 kernel: percpu_ref_switch_to_percpu+0x22/0x40
Sep 26 14:40:59 dhcp-134-111-74-24 kernel: set_in_sync+0xc4/0xd0
Sep 26 14:40:59 dhcp-134-111-74-24 kernel: md_check_recovery+0x49d/0x530
Sep 26 14:40:59 dhcp-134-111-74-24 kernel: raid1d+0x5c/0x12a0 [raid1]
Sep 26 14:40:59 dhcp-134-111-74-24 kernel: ? lock_timer_base+0x67/0x80
Sep 26 14:40:59 dhcp-134-111-74-24 kernel: ? try_to_del_timer_sync+0x4d/0x80
Sep 26 14:40:59 dhcp-134-111-74-24 kernel: ? del_timer_sync+0x25/0x40
Sep 26 14:40:59 dhcp-134-111-74-24 kernel: ? schedule_timeout+0x19b/0x2f0
Sep 26 14:40:59 dhcp-134-111-74-24 kernel: ? __next_timer_interrupt+0xf0/0xf0
Sep 26 14:40:59 dhcp-134-111-74-24 kernel: ? md_register_thread+0xd0/0xd0
Sep 26 14:40:59 dhcp-134-111-74-24 kernel: ? md_thread+0x94/0x150
Sep 26 14:40:59 dhcp-134-111-74-24 kernel: ? process_checks+0x4a0/0x4a0 [raid1]
Sep 26 14:40:59 dhcp-134-111-74-24 kernel: md_thread+0x94/0x150
Sep 26 14:40:59 dhcp-134-111-74-24 kernel: ? finish_wait+0x80/0x80
Sep 26 14:40:59 dhcp-134-111-74-24 kernel: kthread+0x112/0x130
Sep 26 14:40:59 dhcp-134-111-74-24 kernel: ? kthread_flush_work_fn+0x10/0x10
Sep 26 14:40:59 dhcp-134-111-74-24 kernel: ret_from_fork+0x35/0x40

Any insight is helpful, as I am stuck in this for almost a month. Thanks in advance

Regards, Srinivas

  • What is the state of your MD software RAID volume(s) on this system? Please show the output of cat /proc/mdstat if possible. Also, the kernel taint checking indicates you have an out-of-tree kernel module loaded. Is it something essential to the system, or could you try reproducing the problem without it? The module seems to be unsigned, so it is not following the best practices for RHEL 8; it might be out of date in other ways too. If the module is essential, see if there is a newer version of it available. – telcoM Oct 5 at 8:16
  • @telcoM : the module is a part on RHEL8 and it is required, the tainted appears only during the call traces. – user73636 Oct 5 at 11:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.