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.
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++) { >afb.base. pitches[ 0] + (x * bpp); toio(bo- >kmap.virtual + src_offset, afbdev->sysram + src_offset, (x2 - x + 1) * bpp);
/* assume equal stride for now */
src_offset = dst_offset = i * afbdev-
memcpy_
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.