From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sebastian Andrzej Siewior Subject: Re: [PATCH] drm/i915: move i915_trace_irq_get() out of the tracing macro Date: Fri, 21 Jun 2013 14:51:07 +0200 Message-ID: <51C44C3B.1090604@linutronix.de> References: <1371809753-16052-1-git-send-email-bigeasy@linutronix.de> <20130621110849.GQ14531@cantiga.alporthouse.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20130621110849.GQ14531@cantiga.alporthouse.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org Errors-To: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org To: Chris Wilson , Daniel Vetter , David Airlie , intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org List-Id: intel-gfx@lists.freedesktop.org On 06/21/2013 01:08 PM, Chris Wilson wrote: > On Fri, Jun 21, 2013 at 12:15:53PM +0200, Sebastian Andrzej Siewior wrote: >> There is a report on RT about "BUG: scheduling while atomic" because the >> sleeping lock is taken in tracing context. This patch simply moves >> locking operation out of the tracing macro. > > No. This enables the IRQ, as well as making a number of > very expensively serialised read, unconditionally. Ach in case CONFIG_TRACING is enabled but the tracepoint itself is disabled. In that case it is probably best to drop this tracepoint from -RT. > -Chris > Sebastian