On Mon, Aug 22, 2016 at 06:15:53PM +0100, Chris Wilson wrote: > Hmm, prepare_to_wait() itself has a might_sleep() check, preventing the > preempt fun. The challenge is that we do not want to be interrupted > once we decide to apply the update (reading the scanline) - but that > read has to be after prepare_to_wait to prevent any races before > sleeping. Scratch that, didn't read the warning carefully enough and was thrown by an unreliable frame: [ 32.616197] [<ffffffff8104583a>] warn_slowpath_fmt+0x4a/0x50 [ 32.616208] [<ffffffff8107ff6b>] ? prepare_to_wait+0x2b/0x90 [ 32.616222] [<ffffffff8107ff6b>] ? prepare_to_wait+0x2b/0x90 [ 32.616229] [<ffffffff810686b7>] __might_sleep+0x77/0x80 That of course is the wrong way around for prepare_to_wait to be doing the might_sleep. The issue was just not rearranging the control flow correctly to finish_wait. -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
