On Fri, 16 Oct 2015, Josh Cartwright wrote: > 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. It can, but it calls some more functions with interrupts disabled which are taking regular spinlocks. So that does not cure it. Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
