I used ftrace to do some duration measuring of the timer function
fb_flashcursor(). I noticed several places where this timer takes around
98 ms to complete. This time seems to be due to multiple calls to
__memcpy_toio() in ast_dirty_update():
for (i = y; i <= y2; i++) {
/* assume equal stride for now */
src_offset = dst_offset = i * afbdev->afb.base.pitches[0] + (x
* bpp);
memcpy_toio(bo->kmap.virtual + src_offset, afbdev->sysram +
src_offset, (x2 - x + 1) * bpp);
My theory is that this is causing mod_timer() to block on the other CPU,
resulting in the soft lockup.
Also - I built a custom d-i using pristine 4.6-rc7, and I am able to
easily reproduce this. I think the next step here is to report this to
upstream.
--
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
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
