On Tue, Jul 09, 2013 at 04:00:31PM -0700, Guenter Roeck wrote:
This patch partially reverts commit 36ec8f877481449bdfa072e6adf2060869e2b970
for
IvyBridge CPUs.
The original commit results in repeated 'Timed out waiting for forcewake old
ack to clear' messages on a Supermicro C7H61 board
The current code won't report any fifo underruns on cpt if just one
pipe has fifo underrun reporting disabled. We can't enable the
interrupts, but we can still check the per-transcoder bits and so
report the underrun delayed if:
- We always clear the transcoder's bit (and none of the other bits)
On Tue, Jul 09, 2013 at 07:58:03PM -0700, Ben Widawsky wrote:
CC: Chad Versace chad.vers...@linux.intel.com
CC: Bryan Bell bryan.j.b...@intel.com
Signed-off-by: Ben Widawsky b...@bwidawsk.net
So I think we should run this from igt and check its return value. And
since we've had a few bugs with
With a few days of uptime on my i5-2500K desktop (which I don't
suspend), I hit a GPU hang in GNOME3 with 3.10 (Ubuntu mainline).
Captured state is at http://quora.org/2013/i915_error_state ; let me
know if collecting any more state would be useful next time.
Thanks,
Daniel
--
Daniel J Blueman
On Tue, Jul 09, 2013 at 10:43:11PM +0200, Daniel Vetter wrote:
On Tue, Jul 09, 2013 at 05:54:39PM +0100, Chris Wilson wrote:
This hopefully fixes the root cause behind the workaround from
commit 25ff1195f8a0b3724541ae7bbe331b4296de9c06
Author: Chris Wilson ch...@chris-wilson.co.uk
On Tue, Jul 09, 2013 at 09:22:39AM +0100, Chris Wilson wrote:
Daniel noticed a problem where is we wrote to an object with ring A in
the middle of a very long running batch, then executed a quick batch on
ring B before a batch that reads from the same object, its obj-ring would
now point to
On Tue, Jul 09, 2013 at 07:58:02PM -0700, Ben Widawsky wrote:
The algorithm/information was originally written by Chad, though I
changed the control flow, and I think his original code had a couple of
bugs, though I didn't look very hard before rewriting. That could have
also been different
On Tue, Jul 09, 2013 at 02:00:51PM +0100, Chris Wilson wrote:
On Tue, Jul 09, 2013 at 11:45:04AM +0200, Daniel Vetter wrote:
In kernel modeset driver mode we're in full control of the chip,
always. So there's no need at all to set mm.suspended in
i915_gem_idle. Hence move that out into the
This reverts commit 25ff119 and the follow on for Valleyview commit 2dc8aae.
commit 25ff1195f8a0b3724541ae7bbe331b4296de9c06
Author: Chris Wilson ch...@chris-wilson.co.uk
Date: Thu Apr 4 21:31:03 2013 +0100
drm/i915: Workaround incoherence between fences and LLC across multiple CPUs
This hopefully fixes the root cause behind the workaround added in
commit 25ff1195f8a0b3724541ae7bbe331b4296de9c06
Author: Chris Wilson ch...@chris-wilson.co.uk
Date: Thu Apr 4 21:31:03 2013 +0100
drm/i915: Workaround incoherence between fences and LLC across multiple CPUs
Thanks to
On Wed, Jul 10, 2013 at 01:36:24PM +0100, Chris Wilson wrote:
This reverts commit 25ff119 and the follow on for Valleyview commit 2dc8aae.
commit 25ff1195f8a0b3724541ae7bbe331b4296de9c06
Author: Chris Wilson ch...@chris-wilson.co.uk
Date: Thu Apr 4 21:31:03 2013 +0100
drm/i915:
suspend complete.
I can start bi-sect of this problem on intel-display scope if you
would like me to. Please let me know if the bisect scope should be larger.
-- Shuah
I got finally an older system where this reproduces consistently, I'm trying
to
root cause that now.
As soon I
On Tue, Jul 09, 2013 at 08:37:45AM +0200, Daniel Vetter wrote:
On Mon, Jul 08, 2013 at 11:08:32PM -0700, Ben Widawsky wrote:
The GTT and PPGTT can be thought of more generally as GPU address
spaces. Many of their actions (insert entries), state (LRU lists) and
many of their characteristics
On Tue, Jul 09, 2013 at 09:16:54AM +0200, Daniel Vetter wrote:
On Mon, Jul 08, 2013 at 11:08:38PM -0700, Ben Widawsky wrote:
formerly: drm/i915: Create VMAs (part 3.5) - map and fenceable
tracking
The map_and_fenceable tracking is per object. GTT mapping, and fences
only apply to
On Tue, Jul 09, 2013 at 09:18:46AM +0200, Daniel Vetter wrote:
On Mon, Jul 08, 2013 at 11:08:39PM -0700, Ben Widawsky wrote:
formerly: drm/i915: Create VMAs (part 5) - move mm_list
The mm_list is used for the active/inactive LRUs. Since those LRUs are
per address space, the link should
On Tue, Jul 09, 2013 at 09:45:09AM +0200, Daniel Vetter wrote:
On Mon, Jul 08, 2013 at 11:08:42PM -0700, Ben Widawsky wrote:
Probably need to squash whole thing, or just the inactive part, tbd...
Signed-off-by: Ben Widawsky b...@bwidawsk.net
I agree that we need vma-active, but I'm not
On Wed, Jul 10, 2013 at 09:59:01AM +0100, Chris Wilson wrote:
On Tue, Jul 09, 2013 at 07:58:02PM -0700, Ben Widawsky wrote:
The algorithm/information was originally written by Chad, though I
changed the control flow, and I think his original code had a couple of
bugs, though I didn't look
On Wed, Jul 10, 2013 at 08:34:18AM +0200, Daniel Vetter wrote:
On Tue, Jul 09, 2013 at 07:58:03PM -0700, Ben Widawsky wrote:
CC: Chad Versace chad.vers...@linux.intel.com
CC: Bryan Bell bryan.j.b...@intel.com
Signed-off-by: Ben Widawsky b...@bwidawsk.net
So I think we should run this
Looks good,
Can you update the comment? The pdf Intel Processor Identification and the
CPUID Instruction is no longer available and the description of
the CPUID instruction is now in the Intel 64 and IA32
Architectures Developer's Manual: Vol. 2A - section 3.2 - CPUID
-Original Message-
On Wed, Jul 10, 2013 at 09:36:58AM -0700, Ben Widawsky wrote:
On Tue, Jul 09, 2013 at 08:37:45AM +0200, Daniel Vetter wrote:
On Mon, Jul 08, 2013 at 11:08:32PM -0700, Ben Widawsky wrote:
The GTT and PPGTT can be thought of more generally as GPU address
spaces. Many of their actions
On Wed, Jul 10, 2013 at 09:39:00AM -0700, Ben Widawsky wrote:
On Tue, Jul 09, 2013 at 09:16:54AM +0200, Daniel Vetter wrote:
On Mon, Jul 08, 2013 at 11:08:38PM -0700, Ben Widawsky wrote:
formerly: drm/i915: Create VMAs (part 3.5) - map and fenceable
tracking
The map_and_fenceable
On Wed, Jul 10, 2013 at 09:40:18AM -0700, Ben Widawsky wrote:
On Wed, Jul 10, 2013 at 09:59:01AM +0100, Chris Wilson wrote:
On Tue, Jul 09, 2013 at 07:58:02PM -0700, Ben Widawsky wrote:
The algorithm/information was originally written by Chad, though I
changed the control flow, and I
On Wed, Jul 10, 2013 at 09:39:30AM -0700, Ben Widawsky wrote:
On Tue, Jul 09, 2013 at 09:45:09AM +0200, Daniel Vetter wrote:
On Mon, Jul 08, 2013 at 11:08:42PM -0700, Ben Widawsky wrote:
Probably need to squash whole thing, or just the inactive part, tbd...
Signed-off-by: Ben Widawsky
On Wed, Jul 10, 2013 at 09:58:38AM -0700, Ben Widawsky wrote:
On Wed, Jul 10, 2013 at 08:34:18AM +0200, Daniel Vetter wrote:
On Tue, Jul 09, 2013 at 07:58:03PM -0700, Ben Widawsky wrote:
CC: Chad Versace chad.vers...@linux.intel.com
CC: Bryan Bell bryan.j.b...@intel.com
Signed-off-by:
On Wed, Jul 10, 2013 at 07:15:43PM +0200, Daniel Vetter wrote:
On Wed, Jul 10, 2013 at 09:58:38AM -0700, Ben Widawsky wrote:
On Wed, Jul 10, 2013 at 08:34:18AM +0200, Daniel Vetter wrote:
On Tue, Jul 09, 2013 at 07:58:03PM -0700, Ben Widawsky wrote:
CC: Chad Versace
On Wed, Jul 10, 2013 at 09:40:18AM -0700, Ben Widawsky wrote:
On Wed, Jul 10, 2013 at 09:59:01AM +0100, Chris Wilson wrote:
On Tue, Jul 09, 2013 at 07:58:02PM -0700, Ben Widawsky wrote:
The algorithm/information was originally written by Chad, though I
changed the control flow, and I
On 07/10/2013 09:18 AM, Winkler, Tomas wrote:
suspend complete.
I can start bi-sect of this problem on intel-display scope if you
would like me to. Please let me know if the bisect scope should be larger.
-- Shuah
I got finally an older system where this reproduces consistently, I'm trying
On Wed, Jul 10, 2013 at 10:24:27AM -0700, Ben Widawsky wrote:
On Wed, Jul 10, 2013 at 07:15:43PM +0200, Daniel Vetter wrote:
On Wed, Jul 10, 2013 at 09:58:38AM -0700, Ben Widawsky wrote:
On Wed, Jul 10, 2013 at 08:34:18AM +0200, Daniel Vetter wrote:
On Tue, Jul 09, 2013 at 07:58:03PM
On Wed, Jul 10, 2013 at 06:40:02PM +0100, Chris Wilson wrote:
On Wed, Jul 10, 2013 at 09:40:18AM -0700, Ben Widawsky wrote:
On Wed, Jul 10, 2013 at 09:59:01AM +0100, Chris Wilson wrote:
On Tue, Jul 09, 2013 at 07:58:02PM -0700, Ben Widawsky wrote:
The algorithm/information was originally
On Wed, Jul 10, 2013 at 10:46:47AM -0700, Ben Widawsky wrote:
On Wed, Jul 10, 2013 at 06:40:02PM +0100, Chris Wilson wrote:
On Wed, Jul 10, 2013 at 09:40:18AM -0700, Ben Widawsky wrote:
On Wed, Jul 10, 2013 at 09:59:01AM +0100, Chris Wilson wrote:
On Tue, Jul 09, 2013 at 07:58:02PM
On Wed, Jul 10, 2013 at 07:00:53PM +0100, Chris Wilson wrote:
On Wed, Jul 10, 2013 at 10:46:47AM -0700, Ben Widawsky wrote:
On Wed, Jul 10, 2013 at 06:40:02PM +0100, Chris Wilson wrote:
On Wed, Jul 10, 2013 at 09:40:18AM -0700, Ben Widawsky wrote:
On Wed, Jul 10, 2013 at 09:59:01AM
2013/7/10 Daniel Vetter daniel.vet...@ffwll.ch:
The current code won't report any fifo underruns on cpt if just one
pipe has fifo underrun reporting disabled. We can't enable the
interrupts, but we can still check the per-transcoder bits and so
report the underrun delayed if:
- We always
2013/7/9 Daniel Vetter daniel.vet...@ffwll.ch:
Same treatment as for SERR_INT: If we clear only the bit for the pipe
we're enabling (but unconditionally) then we can always check for
possible underruns after having disabled the interrupt. That way pipe
underruns won't be lost, but at worst
2013/7/9 Daniel Vetter daniel.vet...@ffwll.ch:
Since the addition of VECS we have a slightly different enable
sequence for PM interrupts on ivb/hsw vs snb and vlv. Usually that
will end up in hard to track down surprises.
Hence unifiy things and since we have copies of this code in 3 places
On Wed, Jul 10, 2013 at 04:47:08PM -0300, Paulo Zanoni wrote:
2013/7/9 Daniel Vetter daniel.vet...@ffwll.ch:
Same treatment as for SERR_INT: If we clear only the bit for the pipe
we're enabling (but unconditionally) then we can always check for
possible underruns after having disabled the
On Wed, Jul 10, 2013 at 05:05:07PM -0300, Paulo Zanoni wrote:
2013/7/9 Daniel Vetter daniel.vet...@ffwll.ch:
Since the addition of VECS we have a slightly different enable
sequence for PM interrupts on ivb/hsw vs snb and vlv. Usually that
will end up in hard to track down surprises.
2013/7/4 Daniel Vetter daniel.vet...@ffwll.ch:
Again extract a common helper. For the postinstall hook things are a
bit more complicated since we have more cases on ilk-hsw/vlv here.
But since vlv was clearly broken by failing to initialize
dev_priv-gt_irq_mask correclty (mayb that explains
2013/7/10 Daniel Vetter dan...@ffwll.ch:
On Wed, Jul 10, 2013 at 05:05:07PM -0300, Paulo Zanoni wrote:
2013/7/9 Daniel Vetter daniel.vet...@ffwll.ch:
Since the addition of VECS we have a slightly different enable
sequence for PM interrupts on ivb/hsw vs snb and vlv. Usually that
will end
2013/7/4 Daniel Vetter daniel.vet...@ffwll.ch:
This just unifies the vlv code with the snb-hsw code which matched
exactly before the VECS enabling.
So now the VLV code is behaving differently. Is that intentional? You
could write about the implications here.
Signed-off-by: Daniel Vetter
On 07/09/2013 07:58 PM, Ben Widawsky wrote:
The algorithm/information was originally written by Chad, though I
changed the control flow, and I think his original code had a couple of
bugs, though I didn't look very hard before rewriting. That could have
also been different interpretations of the
40 matches
Mail list logo
