On Wed, Feb 01, 2012 at 10:26:45PM +0100, Daniel Vetter wrote:
> Chris Wilson and me have again stared at funny error states and it's
> been pretty clear from the start that something was seriously amiss.
> The seqnos last seen by the cpu were a few hundred behind those that
> the gpu could have po
On Fri, Feb 03, 2012 at 11:10:09PM +, Chris Wilson wrote:
> On Fri, 3 Feb 2012 14:31:41 -0800, Ben Widawsky wrote:
> > This is similar to a patch I wrote several months ago. It's been updated
> > for the new FORCEWAKE_MT, and it also no longer clears the debug
> > register as it may be helpfu
On 02/03/2012 12:22 PM, Eugeni Dodonov wrote:
This adds the workaround for WaCatErrorRejectionIssue which could result in a
system hang..
Signed-off-by: Eugeni Dodonov
---
drivers/gpu/drm/i915/i915_reg.h |4
drivers/gpu/drm/i915/intel_display.c |4
2 files changed, 8 i
On 02/03/2012 12:22 PM, Eugeni Dodonov wrote:
This adds two cache-related workarounds for Ivy Bridge which can lead to 3D
ring hangs and corruptions.
Signed-off-by: Eugeni Dodonov
---
drivers/gpu/drm/i915/i915_reg.h |7 +++
drivers/gpu/drm/i915/intel_display.c |6 ++
2 f
On 02/03/2012 12:22 PM, Eugeni Dodonov wrote:
This adds two cache-related workarounds for Ivy Bridge which can lead to 3D
ring hangs and corruptions.
Signed-off-by: Eugeni Dodonov
---
drivers/gpu/drm/i915/i915_reg.h |7 +++
drivers/gpu/drm/i915/intel_display.c |6 ++
2 f
Hi!
I'm one of the users affected by video corruption with RC6 enabled on Sandy
Bridge mobile.
My machine is a Dell Inspiron 15R N5110 powered by an i3-2310M. No
additional graphic card, the HD3000 is enough for my needs.
What I experience can be found in this bug report:
https://bugs.freedesktop.
On Fri, 3 Feb 2012 14:31:41 -0800, Ben Widawsky wrote:
> This is similar to a patch I wrote several months ago. It's been updated
> for the new FORCEWAKE_MT, and it also no longer clears the debug
> register as it may be helpful to get that for the error state. Also
> recommended by Chris Wilson
On Fri, 3 Feb 2012 14:31:40 -0800, Ben Widawsky wrote:
> - Add register definitions for GTFIFODBG.
> - Capture it at error time.
> - Print it from debugfs (with whitespace fix).
>
> This register tells us if either a read, or a write occured while the
> fifo was full.
>
> Signed-off-by: Ben
- Add register definitions for GTFIFODBG.
- Capture it at error time.
- Print it from debugfs (with whitespace fix).
This register tells us if either a read, or a write occured while the
fifo was full.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_debugfs.c |3 ++-
drivers/g
This is similar to a patch I wrote several months ago. It's been updated
for the new FORCEWAKE_MT, and it also no longer clears the debug
register as it may be helpful to get that for the error state. Also
recommended by Chris Wilson, use WARN() instead of DRM_ERROR, so we can
get a backtrace.
Si
Add the WaDisableEUInstructionShootdown workaround for Ivy Bridge.
Signed-off-by: Eugeni Dodonov
---
drivers/gpu/drm/i915/i915_reg.h |5 +
drivers/gpu/drm/i915/intel_display.c |9 +
2 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915
This adds the workaround for WaCatErrorRejectionIssue which could result in a
system hang..
Signed-off-by: Eugeni Dodonov
---
drivers/gpu/drm/i915/i915_reg.h |4
drivers/gpu/drm/i915/intel_display.c |4
2 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/drivers
This adds two cache-related workarounds for Ivy Bridge which can lead to 3D
ring hangs and corruptions.
Signed-off-by: Eugeni Dodonov
---
drivers/gpu/drm/i915/i915_reg.h |7 +++
drivers/gpu/drm/i915/intel_display.c |6 ++
2 files changed, 13 insertions(+), 0 deletions(-)
di
This is yet another workaround related to clock gating which we need on Gen7.
Signed-off-by: Eugeni Dodonov
---
drivers/gpu/drm/i915/i915_reg.h |1 +
drivers/gpu/drm/i915/intel_display.c |4
2 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/i91
The combination of those 4 workarounds seem to solve random hand-hangs observed
in GLBenchmark Egypt and (much more rarely) in World of Padman and Unigine
demos.
Eugeni Dodonov (4):
drm/i915: gen7: implement rczunit workaround
drm/i915: gen7: add two more IVB workarounds
drm/i915: gen7: work
From: Paulo Zanoni
My laptop has two 1440x900 modes: one is the fixed_mode and the other
has different timings. If I use xrandr to switch from the fixed mode to
the "other" 1440x900 mode, xrandr will tell me the change was
successful, but nothing was actually done: I'm still using the
fixed_mode.
From: Paulo Zanoni
I'm not sure why they are needed (I didn't notice any difference in my
tests), but these bits are in our documentation and they are also set by
the Windows driver.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_reg.h |2 ++
drivers/gpu/drm/i915/intel_disp
On Fri, 03 Feb 2012 10:39:18 -0800, Ben Widawsky wrote:
> On 02/03/12 08:44, Paulo Zanoni wrote:
> > 2012/2/3 Chris Wilson:
> >> I don't this should an installable tool for use by end-users. Direct
> >> register access from userspace to registers that the driver owns? I'm
> >> wary of installing e
On 02/03/12 08:44, Paulo Zanoni wrote:
2012/2/3 Chris Wilson:
I don't this should an installable tool for use by end-users. Direct
register access from userspace to registers that the driver owns? I'm
wary of installing even root-only tools that can screw us over in
unpredictable ways.
-Chris
On Fri, 3 Feb 2012 12:43:25 -0200, Eugeni Dodonov
wrote:
> This allows to hopefully find out who was responsible for the GPU death.
> We record the 1st and last process to touch each object, to keep track of
> the process which created the object originally and the last process to
> touch it.
>
2012/2/3 Chris Wilson :
> I don't this should an installable tool for use by end-users. Direct
> register access from userspace to registers that the driver owns? I'm
> wary of installing even root-only tools that can screw us over in
> unpredictable ways.
> -Chris
My idea is to write a patch that
On Fri, 3 Feb 2012 13:09:26 -0200, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> The tool allows you to change the panel fitter settings, so you can
> change the size of the screen being displayed on your monitor without
> changing the real pixel size of your desktop. The biggest use case for
>
On Fri, Feb 03, 2012 at 01:31:39PM -0200, Eugeni Dodonov wrote:
> This allows to hopefully find out who was responsible for the GPU death.
> We record the 1st and last process to touch each object, to keep track of
> the process which created the object originally and the last process to
> touch it
This allows to hopefully find out who was responsible for the GPU death.
We record the 1st and last process to touch each object, to keep track of
the process which created the object originally and the last process to
touch it.
To simplify post-mortem analysis, we also search for the processes na
On Fri, Feb 03, 2012 at 12:43:25PM -0200, Eugeni Dodonov wrote:
> This allows to hopefully find out who was responsible for the GPU death.
> We record the 1st and last process to touch each object, to keep track of
> the process which created the object originally and the last process to
> touch it
From: Paulo Zanoni
The tool allows you to change the panel fitter settings, so you can
change the size of the screen being displayed on your monitor without
changing the real pixel size of your desktop. The biggest use case for
this tool is to work around overscan done by TVs and some monitors in
This allows to hopefully find out who was responsible for the GPU death.
We record the 1st and last process to touch each object, to keep track of
the process which created the object originally and the last process to
touch it.
To simplify post-mortem analysis, we also search for the processes na
On Thu, 2 Feb 2012 14:52:22 -0200, Eugeni Dodonov
wrote:
> This allows to hopefully find out who was responsible for the GPU death.
>
> To simplify post-portem analysis, we also search for the the processes
> names when gathering the i915_error_state and when peeking at the list of
> active gem
On Fri, Jan 27, 2012 at 9:40 PM, Daniel Vetter wrote:
> CEA actually specifies an interlaced mode with even vtotal and
> supplies a diagram showing how this is supposed to work.
>
> Note that interlaced modes with an even vtotal seem to be a fairly
> recent invention. All modelines lore I could di
Am 30.01.2012 22:19, schrieb Stefan G. Weichinger:
> Am 2012-01-12 23:45, schrieb Jesse Barnes:
>
>>> Tested with the (attached, hopefully correct) patch and it still works. :-)
>>
>> Yay, thanks a lot! I'll send it upstream now.
>
> The gentoo-devs still haven't fixed that yet ... in their
> ge
30 matches
Mail list logo
