linux-kernel - [PATCH 3.0-rc3] i915: Fix gen6 (SNB) GPU stalling

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 15 Jun 2011 00:51:47 +0800
From:	Daniel J Blueman <daniel.blueman@...il.com>
To:	Eric Anholt <eric@...olt.net>
Cc:	Keith Packard <keithp@...thp.com>,
	Dave Airlie <airlied@...hat.com>,
	Chris Wilson <chris@...is-wilson.co.uk>,
	intel-gfx@...ts.freedesktop.org, linux-kernel@...r.kernel.org,
	Daniel J Blueman <daniel.blueman@...il.com>
Subject: [PATCH 3.0-rc3] i915: Fix gen6 (SNB) GPU stalling

On 14 June 2011 13:23, Eric Anholt <eric@...olt.net> wrote:
> On Tue, 14 Jun 2011 12:18:36 +0800, Daniel J Blueman <daniel.blueman@...il.com> wrote:
>> Hi Eric,
>>
>> The frequent ~1.5s pauses I hit with SNB hardware in the gnome3 UI (eg
>> whenever you hit the top-left of the screen to show all windows) are
>> nicely addressed by your recent wake patch [1] (ported to -rc3). Thus
>> I see no 'missed IRQ' kernel messages.
>>
>> As this addresses a significant usability regression, are you happy to
>> add it to the 3.0-rc queue? I think it has very good value in -stable
>> also (assuming correctness). What do you think?
>
> This one had significant performance impacts, and later hacks in this
> series worked around the problem to approximately the same level of
> success with less impact, and we don't actually have a justification of
> why any of them work.  We were still hoping to come up with some clue,
> and haven't yet.

True; that is quite heavy handed delay looping.

It's a pity the usual Intel font didn't make it to the programmer's
reference manuals. Anyway, unmasking the blitter user interrupt in the hardware
status mask register addresses the root cause. Out of reset it's FFFFFFFFh,
so we don't need to read it here.

It would be good to get this into -rc4. -stable probably needs some additional
tweaks.

Signed-off-by: Daniel J Blueman <daniel.blueman@...il.com>
---
 drivers/gpu/drm/i915/i915_irq.c |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index b9fafe3..9a98c1b 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1827,6 +1827,12 @@ int ironlake_irq_postinstall(struct drm_device *dev)
 		ironlake_enable_display_irq(dev_priv, DE_PCU_EVENT);
 	}
 
+	if (IS_GEN6(dev))
+		/* allow blitter user interrupt to generate a MSI write from
+		   the ISR */
+		I915_WRITE(GEN6_BLITTER_HWSTAM,
+			0xffffffff & ~GEN6_BLITTER_USER_INTERRUPT);
+
 	return 0;
 }
 
-- 
1.7.4.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/