From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
Jani Nikula <jani.nikula@linux.intel.com>,
Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
Rodrigo Vivi <rodrigo.vivi@intel.com>,
David Airlie <airlied@linux.ie>, Daniel Vetter <daniel@ffwll.ch>,
Thomas Gleixner <tglx@linutronix.de>,
Luca Abeni <lucabe72@gmail.com>,
Steven Rostedt <rostedt@goodmis.org>
Subject: Re: [Intel-gfx] [PATCH 3/8] drm/i915: Disable tracing points on PREEMPT_RT
Date: Wed, 6 Oct 2021 12:34:19 +0300 [thread overview]
Message-ID: <YV1tm8bNEBbPeU6/@intel.com> (raw)
In-Reply-To: <20211005150046.1000285-4-bigeasy@linutronix.de>
On Tue, Oct 05, 2021 at 05:00:41PM +0200, Sebastian Andrzej Siewior wrote:
> Luca Abeni reported this:
> | BUG: scheduling while atomic: kworker/u8:2/15203/0x00000003
> | CPU: 1 PID: 15203 Comm: kworker/u8:2 Not tainted 4.19.1-rt3 #10
> | Call Trace:
> | rt_spin_lock+0x3f/0x50
> | gen6_read32+0x45/0x1d0 [i915]
> | g4x_get_vblank_counter+0x36/0x40 [i915]
> | trace_event_raw_event_i915_pipe_update_start+0x7d/0xf0 [i915]
>
> The tracing events use trace_i915_pipe_update_start() among other events
> use functions acquire spinlock_t locks which are transformed into
> sleeping locks on PREEMPT_RT. A few trace points use
> intel_get_crtc_scanline(), others use ->get_vblank_counter() wich also
> might acquire a sleeping locks on PREEMPT_RT.
> At the time the arguments are evaluated within trace point, preemption
> is disabled and so the locks must not be acquired on PREEMPT_RT.
>
> Based on this I don't see any other way than disable trace points on
> PREMPT_RT.
I think the correct answer is to make uncore.lock a raw_spinlock.
Without the tracepoints deubgging any of this is stuff pretty much
impossible. We also take that lock a lot.
The horrible truth is that some of the hardware just keels over
if two CPUs access the same mmio cacheline simultanously, so
pretty much all mmio accesses need to be performed under uncore.lock.
The vblank locking situation is a lot more self inflicted. As in
there are something like three different spinlocks in there for
some reason. Not sure what to do about that. I guess one option
would be to skip the vblank timestamp based stuff in the
tracepoints for the time being. Most hardware should have
a hardware vblank counter so the fallback isn't super common.
>
> Reported-by: Luca Abeni <lucabe72@gmail.com>
> Cc: Steven Rostedt <rostedt@goodmis.org>
> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> ---
> drivers/gpu/drm/i915/i915_trace.h | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_trace.h b/drivers/gpu/drm/i915/i915_trace.h
> index 806ad688274bf..773e7362c4442 100644
> --- a/drivers/gpu/drm/i915/i915_trace.h
> +++ b/drivers/gpu/drm/i915/i915_trace.h
> @@ -2,6 +2,10 @@
> #if !defined(_I915_TRACE_H_) || defined(TRACE_HEADER_MULTI_READ)
> #define _I915_TRACE_H_
>
> +#ifdef CONFIG_PREEMPT_RT
> +#define NOTRACE
> +#endif
> +
> #include <linux/stringify.h>
> #include <linux/types.h>
> #include <linux/tracepoint.h>
> --
> 2.33.0
--
Ville Syrjälä
Intel
WARNING: multiple messages have this Message-ID (diff)
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
Jani Nikula <jani.nikula@linux.intel.com>,
Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
Rodrigo Vivi <rodrigo.vivi@intel.com>,
David Airlie <airlied@linux.ie>, Daniel Vetter <daniel@ffwll.ch>,
Thomas Gleixner <tglx@linutronix.de>,
Luca Abeni <lucabe72@gmail.com>,
Steven Rostedt <rostedt@goodmis.org>
Subject: Re: [PATCH 3/8] drm/i915: Disable tracing points on PREEMPT_RT
Date: Wed, 6 Oct 2021 12:34:19 +0300 [thread overview]
Message-ID: <YV1tm8bNEBbPeU6/@intel.com> (raw)
In-Reply-To: <20211005150046.1000285-4-bigeasy@linutronix.de>
On Tue, Oct 05, 2021 at 05:00:41PM +0200, Sebastian Andrzej Siewior wrote:
> Luca Abeni reported this:
> | BUG: scheduling while atomic: kworker/u8:2/15203/0x00000003
> | CPU: 1 PID: 15203 Comm: kworker/u8:2 Not tainted 4.19.1-rt3 #10
> | Call Trace:
> | rt_spin_lock+0x3f/0x50
> | gen6_read32+0x45/0x1d0 [i915]
> | g4x_get_vblank_counter+0x36/0x40 [i915]
> | trace_event_raw_event_i915_pipe_update_start+0x7d/0xf0 [i915]
>
> The tracing events use trace_i915_pipe_update_start() among other events
> use functions acquire spinlock_t locks which are transformed into
> sleeping locks on PREEMPT_RT. A few trace points use
> intel_get_crtc_scanline(), others use ->get_vblank_counter() wich also
> might acquire a sleeping locks on PREEMPT_RT.
> At the time the arguments are evaluated within trace point, preemption
> is disabled and so the locks must not be acquired on PREEMPT_RT.
>
> Based on this I don't see any other way than disable trace points on
> PREMPT_RT.
I think the correct answer is to make uncore.lock a raw_spinlock.
Without the tracepoints deubgging any of this is stuff pretty much
impossible. We also take that lock a lot.
The horrible truth is that some of the hardware just keels over
if two CPUs access the same mmio cacheline simultanously, so
pretty much all mmio accesses need to be performed under uncore.lock.
The vblank locking situation is a lot more self inflicted. As in
there are something like three different spinlocks in there for
some reason. Not sure what to do about that. I guess one option
would be to skip the vblank timestamp based stuff in the
tracepoints for the time being. Most hardware should have
a hardware vblank counter so the fallback isn't super common.
>
> Reported-by: Luca Abeni <lucabe72@gmail.com>
> Cc: Steven Rostedt <rostedt@goodmis.org>
> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> ---
> drivers/gpu/drm/i915/i915_trace.h | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_trace.h b/drivers/gpu/drm/i915/i915_trace.h
> index 806ad688274bf..773e7362c4442 100644
> --- a/drivers/gpu/drm/i915/i915_trace.h
> +++ b/drivers/gpu/drm/i915/i915_trace.h
> @@ -2,6 +2,10 @@
> #if !defined(_I915_TRACE_H_) || defined(TRACE_HEADER_MULTI_READ)
> #define _I915_TRACE_H_
>
> +#ifdef CONFIG_PREEMPT_RT
> +#define NOTRACE
> +#endif
> +
> #include <linux/stringify.h>
> #include <linux/types.h>
> #include <linux/tracepoint.h>
> --
> 2.33.0
--
Ville Syrjälä
Intel
next prev parent reply other threads:[~2021-10-06 9:34 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-05 15:00 [Intel-gfx] [PATCH 0/8] drm/i915: PREEMPT_RT related fixups Sebastian Andrzej Siewior
2021-10-05 15:00 ` Sebastian Andrzej Siewior
2021-10-05 15:00 ` [Intel-gfx] [PATCH 1/8] drm/i915: Use preempt_disable/enable_rt() where recommended Sebastian Andrzej Siewior
2021-10-05 15:00 ` Sebastian Andrzej Siewior
2021-10-05 15:00 ` [Intel-gfx] [PATCH 2/8] drm/i915: Don't disable interrupts on PREEMPT_RT during atomic updates Sebastian Andrzej Siewior
2021-10-05 15:00 ` Sebastian Andrzej Siewior
2021-10-06 9:16 ` [Intel-gfx] " Ville Syrjälä
2021-10-05 15:00 ` [Intel-gfx] [PATCH 3/8] drm/i915: Disable tracing points on PREEMPT_RT Sebastian Andrzej Siewior
2021-10-05 15:00 ` Sebastian Andrzej Siewior
2021-10-06 9:34 ` Ville Syrjälä [this message]
2021-10-06 9:34 ` Ville Syrjälä
2021-10-06 10:15 ` [Intel-gfx] " Sebastian Andrzej Siewior
2021-10-06 10:15 ` Sebastian Andrzej Siewior
2021-10-06 16:46 ` [Intel-gfx] " Sebastian Andrzej Siewior
2021-10-06 16:46 ` Sebastian Andrzej Siewior
2021-10-05 15:00 ` [Intel-gfx] [PATCH 4/8] drm/i915: skip DRM_I915_LOW_LEVEL_TRACEPOINTS with NOTRACE Sebastian Andrzej Siewior
2021-10-05 15:00 ` Sebastian Andrzej Siewior
2021-10-05 15:00 ` [Intel-gfx] [PATCH 5/8] drm/i915/gt: Queue and wait for the irq_work item Sebastian Andrzej Siewior
2021-10-05 15:00 ` Sebastian Andrzej Siewior
2021-10-05 15:00 ` [Intel-gfx] [PATCH 6/8] drm/i915/gt: Use spin_lock_irq() instead of local_irq_disable() + spin_lock() Sebastian Andrzej Siewior
2021-10-05 15:00 ` Sebastian Andrzej Siewior
2021-10-05 15:00 ` [Intel-gfx] [PATCH 7/8] drm/i915: Drop the irqs_disabled() check Sebastian Andrzej Siewior
2021-10-05 15:00 ` Sebastian Andrzej Siewior
2021-10-05 15:00 ` [Intel-gfx] [PATCH 8/8] drm/i915: Don't disable interrupts and pretend a lock as been acquired in __timeline_mark_lock() Sebastian Andrzej Siewior
2021-10-05 15:00 ` Sebastian Andrzej Siewior
2021-10-05 19:16 ` [Intel-gfx] " Peter Zijlstra
2021-10-05 19:16 ` Peter Zijlstra
2021-10-06 6:58 ` [Intel-gfx] " Sebastian Andrzej Siewior
2021-10-06 6:58 ` Sebastian Andrzej Siewior
2021-10-08 6:21 ` [Intel-gfx] [drm/i915] 511e5fb0c3: WARNING:suspicious_RCU_usage kernel test robot
2021-10-08 6:21 ` kernel test robot
2021-10-08 6:21 ` kernel test robot
2021-10-05 16:12 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: PREEMPT_RT related fixups Patchwork
2021-10-05 16:48 ` [Intel-gfx] ✗ Fi.CI.BAT: failure " Patchwork
2021-10-06 17:41 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915: PREEMPT_RT related fixups. (rev2) Patchwork
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=YV1tm8bNEBbPeU6/@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=airlied@linux.ie \
--cc=bigeasy@linutronix.de \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jani.nikula@linux.intel.com \
--cc=joonas.lahtinen@linux.intel.com \
--cc=lucabe72@gmail.com \
--cc=rodrigo.vivi@intel.com \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.