On Wed, Oct 14, 2015 at 11:08:38AM +0200, Christoph Mathys wrote: > On Tue, Oct 13, 2015 at 5:35 PM, Christoph Mathys <eraserix@xxxxxxxxx> wrote: > > Can anyone reproduce this? Any ideas? dmesg does not contain any funny > > reports... > > It is actually not true that there are no funny reports. After > enabling more debug options I now get the BUG below once per second. > There are other callpaths than the one below that trigger this > message, but they all go through the function > intel_pipe_update_start(). > > [ 17.694307] BUG: sleeping function called from invalid context at > kernel/locking/rtmutex.c:917 > [ 17.694308] in_atomic(): 0, irqs_disabled(): 1, pid: 102, name: kworker/3:1 [..] > [ 17.694347] hardirqs last disabled at (21082): [<ffffffffa02fabf3>] intel_pipe_update_start+0x113/0x640 [i915] [..] > [ 17.694367] Call Trace: > [ 17.694370] [<ffffffff817f961d>] dump_stack+0x4a/0x61 > [ 17.694372] [<ffffffff8108785a>] ___might_sleep+0x13a/0x200 > [ 17.694373] [<ffffffff81800f24>] rt_spin_lock+0x24/0x60 > [ 17.694374] [<ffffffff8108bbac>] ? migrate_disable+0x6c/0xe0 > [ 17.694375] [<ffffffff810a9bab>] prepare_to_wait+0x2b/0xa0 > [ 17.694386] [<ffffffffa02faca8>] intel_pipe_update_start+0x1c8/0x640 [i915] Looks like intel_pipe_update_start() is trying to queue the caller up on the drm_crtc_vblank_waitqueue() from an local_irq_disable()'d region, which doesn't fly on -rt, as the internal waitqueue lock is a converted rt_mutex w/ PREEMPT_RT (and thus can sleep if contended). Perhaps this driver is a candidate for a simple waitqueue conversion. Josh
Attachment:
signature.asc
Description: PGP signature
