I captured a perf data file, starting just before the NMI kicked in - in
this case, it again occurred on CPU 11. I found that CPU 11 had spent a
lot of its time in cursor_timer_handler():
- 16.92% swapper [kernel.kallsyms] [k] _raw_spin_unlock_irqrestore
▒
- _raw_spin_unlock_irqrestore
▒
+ 16.87% mod_timer
▒
+ 0.05% cursor_timer_handler
▒
- 12.15% swapper [kernel.kallsyms] [k] queue_work_on
▒
- queue_work_on
▒
+ 12.00% cursor_timer_handler
▒
+ 0.15% call_timer_fn
▒
+ 10.98% swapper [kernel.kallsyms] [k] run_timer_softirq
▒
- 2.23% swapper [kernel.kallsyms] [k] mod_timer
▒
- mod_timer
▒
+ 1.97% cursor_timer_handler
▒
+ 0.26% call_timer_fn
Looking at the profile of the other CPUs, I found one that was
interesting - CPU #12 - which appears to be the one actually running the
cursor update code CPU 11 is scheduling:
- 42.18% kworker/u96:2 [kernel.kallsyms] [k] ww_mutex_unlock
▒
- ww_mutex_unlock
▒
- 40.70% ast_dirty_update
▒
ast_imageblit
▒
soft_cursor
▒
bit_cursor
▒
fb_flashcursor
▒
process_one_work
▒
worker_thread
▒
kthread
▒
ret_from_fork
▒
+ 1.48% ast_imageblit
▒
- 40.15% kworker/u96:2 [kernel.kallsyms] [k] __memcpy_toio
▒
- __memcpy_toio
▒
+ 31.54% ast_dirty_update
▒
+ 8.61% ast_imageblit
I wonder if this path is blocking, preventing the timer handler on CPU
#11 from rescheduling. Indeed, when I time how long the handler takes
from start to finish, I am seeing occasional times around ~.1s.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1574814
Title:
ThunderX: soft lockup in cursor_timer_handler() Edit
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1574814/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
