From: Thomas Gleixner <tglx@linutronix.de>
To: Josh Cartwright <joshc@ni.com>
Cc: Christoph Mathys <eraserix@gmail.com>,
Linux RT Users <linux-rt-users@vger.kernel.org>
Subject: Re: [4.1.7-rt8][report] Very high cyclictest latency during glmark2 on i915 gpu
Date: Sat, 17 Oct 2015 12:59:34 +0200 (CEST) [thread overview]
Message-ID: <alpine.DEB.2.11.1510171258170.4212@nanos> (raw)
In-Reply-To: <20151016203629.GE12756@jcartwri.amer.corp.natinst.com>
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@gmail.com> 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
next prev parent reply other threads:[~2015-10-17 11:00 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-13 15:35 [4.1.7-rt8][report] Very high cyclictest latency during glmark2 on i915 gpu Christoph Mathys
2015-10-14 7:51 ` Matthias Meier
2015-10-14 8:42 ` Christoph Mathys
2015-10-14 9:08 ` Christoph Mathys
2015-10-16 20:36 ` Josh Cartwright
2015-10-17 10:59 ` Thomas Gleixner [this message]
2015-12-21 13:19 ` Christoph Mathys
2015-12-22 15:37 ` Sebastian Andrzej Siewior
2015-12-23 12:40 ` Christoph Mathys
2016-01-05 14:38 ` [Intel-gfx] " Daniel Vetter
2016-01-05 14:41 ` Daniel Vetter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.DEB.2.11.1510171258170.4212@nanos \
--to=tglx@linutronix.de \
--cc=eraserix@gmail.com \
--cc=joshc@ni.com \
--cc=linux-rt-users@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox