https://bugzilla.kernel.org/show_bug.cgi?id=217965 --- Comment #10 from Ojaswin Mujoo (ojaswin.mujoo@xxxxxxx) --- Hi Ivan, So unfortunately I'm not able to replicate it yet at my end. While I try that, wanted to check if you can give a few things a try, So it seems like the CPU is stuck at mb_find_order_for_block() called from mb_find_extent(). I do see a while loop in mb_find_order_for_block() but its not obvious if its stuck there and if so why. If possible can you: 1. Recompile the kernel with CONFIG_DEBUG_INFO=y CONFIG_SOFTLOCKUP_DETECTOR=y and CONFIG_HARDLOCKUP_DETECTOR=y which might provide more information in dmesg when the lockup happens. 2. Replicate it once more and note the RIP value in the trace of stuck CPU, for example in the above trace it was mb_find_order_for_block+0x68 for CPU2. 3. Run the following kernel's source dir to get the corresponding line number (CONFIG_DEBUG_INFO needed): $ ./scripts/faddr2line vmlinux mb_find_order_for_block+0x68 Maybe you can share the code you see in and around those lines as well as the exact kernel version. This will help pinpoint the location where the code might be stuck (for example in a loop), which can help root cause this. Also, you mentioned that the CPU gets stuck at 100% util for 10-15mins, does it ever come back to normal or does it stay stuck? Regards, ojaswin -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
