On Wed, Oct 14, 2015 at 11:08:38AM +0200, Christoph Mathys wrote:

On Tue, Oct 13, 2015 at 5:35 PM, Christoph Mathys [off-list ref] wrote:

quoted

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