From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Wilson Subject: Re: [PATCH] drm/i915: rip out the PM_IIR WARN Date: Thu, 21 Jun 2012 14:15:13 +0100 Message-ID: <1340284544_31347@CP5-2952> References: <1340283322-7313-1-git-send-email-daniel.vetter@ffwll.ch> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from fireflyinternet.com (smtp.fireflyinternet.com [109.228.6.236]) by gabe.freedesktop.org (Postfix) with ESMTP id 83ABA9E7F1 for ; Thu, 21 Jun 2012 06:15:51 -0700 (PDT) In-Reply-To: <1340283322-7313-1-git-send-email-daniel.vetter@ffwll.ch> 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: Intel Graphics Development Cc: Daniel Vetter , stable@vger.kernel.org List-Id: intel-gfx@lists.freedesktop.org On Thu, 21 Jun 2012 14:55:22 +0200, Daniel Vetter wrote: > After banging my head against this for the past few months, I still > don't see how this could possible race under the premise that once an > irq bit is masked in PM_IMR and reset in PM_IIR it won't show up again > until we unmask it in PM_IMR. > > Still, we have reports of this being seen in the wild. Now Bspec has > this little bit of lovely language in the PMIIR register: > > Public SNB Docs, Vol3Part2, 2.5.14 "PMIIR": > > "For each bit, the IIR can store a second pending interrupt if two or > more of the same interrupt conditions occur before the first condition > is cleared. Upon clearing the interrupt, the IIR bit will momentarily > go low, then return high to indicate there is another interrupt > pending." > > Now if we presume that PMIMR only prevent new interrupts from being > queued, we could easily end up masking an interrupt and clearing it, > but the 2nd pending interrupt setting the bit in PMIIR right away > again. Which leads, the next time the irq handler runs, to hitting the > WARN. Ok, if we suppose that the PMIMR is only applied when the interrupt is asserted in the double-buffered register rather than on transfer of that backing register into PMIIR, I can see how that would lead to hitting the WARN as you outlined. > Also, no bad side effects of this have ever been reported. And we've > tracked down our issues with the gpu turbo getting stuck to bogus > interrupt generation limits in th RPLIMIT register. True, our current usage is simply to poke the rps up/down, and so if we miss an interrupt we simply get another one a few milliseconds later (presumably) in the same direction. > So let's just rip out this WARN as bogus and call it a day. The only > shallow thing here is that this 2-deep irq queue in the hw makes you > wonder how racy the windows irq handler is ... > > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=42907 > Cc: stable@vger.kernel.org > Signed-Off-by: Daniel Vetter Acked-by: Chris Wilson If we cared we could request a BUN to clarify when the mask is applied. -Chris -- Chris Wilson, Intel Open Source Technology Centre