[PATCH 11/12] i915: Move i915_read/write out of line

[Ben Widawsky]

On Thu, 13 Oct 2011 16:08:51 -0700
Andi Kleen  wrote:

> From: Andi Kleen 
> 
> With the tracing code in there they are far too big to inline.
> 
> .text savings compared to a non force inline kernel:
> 
> i915_restore_display4393   12036   +7643
> i915_save_display   4295   11459   +7164
> i915_handle_error   2979   +3687
> i915_driver_irq_handler 29235086   +2163
> i915_ringbuffer_info 4581661   +1203
> i915_save_vga  -1200   +1200
> i915_driver_irq_uninstall4531624   +1171
> i915_driver_irq_postinstall  9132078   +1165
> ironlake_enable_drps 7191872   +1153
> i915_restore_vga   -1142   +1142
> intel_display_capture_error_state7842030   +1246
> intel_init_emon  7192016   +1297
> 
> and more ...
> 
> [AK: these are older numbers, with the new SNB forcewake checks
> it will be even worse]
> 
> Cc: keithp at keithp.com
> Signed-off-by: Andi Kleen 
> ---
>  drivers/gpu/drm/i915/i915_drv.c |   40 
> +++
>  drivers/gpu/drm/i915/i915_drv.h |   22 ++--
>  2 files changed, 43 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index f07e425..c2de142 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -895,3 +895,43 @@ module_exit(i915_exit);
>  MODULE_AUTHOR(DRIVER_AUTHOR);
>  MODULE_DESCRIPTION(DRIVER_DESC);
>  MODULE_LICENSE("GPL and additional rights");
> +
> +/* We give fast paths for the really cool registers */
> +#define NEEDS_FORCE_WAKE(dev_priv, reg) \
> + (((dev_priv)->info->gen >= 6) && \
> + ((reg) < 0x4) && \
> + ((reg) != FORCEWAKE))
> +
> +#define __i915_read(x, y) \
> +u##x i915_read##x(struct drm_i915_private *dev_priv, u32 reg) { \
> + u##x val = 0; \
> + if (NEEDS_FORCE_WAKE((dev_priv), (reg))) { \
> + gen6_gt_force_wake_get(dev_priv); \
> + val = read##y(dev_priv->regs + reg); \
> + gen6_gt_force_wake_put(dev_priv); \
> + } else { \
> + val = read##y(dev_priv->regs + reg); \
> + } \
> + trace_i915_reg_rw(false, reg, val, sizeof(val)); \
> + return val; \
> +}
> +
> +__i915_read(8, b)
> +__i915_read(16, w)
> +__i915_read(32, l)
> +__i915_read(64, q)
> +#undef __i915_read
> +
> +#define __i915_write(x, y) \
> +void i915_write##x(struct drm_i915_private *dev_priv, u32 reg, u##x val) { \
> + trace_i915_reg_rw(true, reg, val, sizeof(val)); \
> + if (NEEDS_FORCE_WAKE((dev_priv), (reg))) { \
> + __gen6_gt_wait_for_fifo(dev_priv); \
> + } \
> + write##y(val, dev_priv->regs + reg); \
> +}
> +__i915_write(8, b)
> +__i915_write(16, w)
> +__i915_write(32, l)
> +__i915_write(64, q)
> +#undef __i915_write
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 7916bd9..7d171ea 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1354,18 +1354,7 @@ void __gen6_gt_wait_for_fifo(struct drm_i915_private 
> *dev_priv);
>   ((reg) != FORCEWAKE))
>  
>  #define __i915_read(x, y) \
> -static inline u##x i915_read##x(struct drm_i915_private *dev_priv, u32 reg) 
> { \
> - u##x val = 0; \
> - if (NEEDS_FORCE_WAKE((dev_priv), (reg))) { \
> - gen6_gt_force_wake_get(dev_priv); \
> - val = read##y(dev_priv->regs + reg); \
> - gen6_gt_force_wake_put(dev_priv); \
> - } else { \
> - val = read##y(dev_priv->regs + reg); \
> - } \
> - trace_i915_reg_rw(false, reg, val, sizeof(val)); \
> - return val; \
> -}
> + u##x i915_read##x(struct drm_i915_private *dev_priv, u32 reg);
>  
>  __i915_read(8, b)
>  __i915_read(16, w)
> @@ -1374,13 +1363,8 @@ __i915_read(64, q)
>  #undef __i915_read
>  
>  #define __i915_write(x, y) \
> -static inline void i915_write##x(struct drm_i915_private *dev_priv, u32 reg, 
> u##x val) { \
> - trace_i915_reg_rw(true, reg, val, sizeof(val)); \
> - if (NEEDS_FORCE_WAKE((dev_priv), (reg))) { \
> - __gen6_gt_wait_for_fifo(dev_priv); \
> - } \
> - write##y(val, dev_priv->regs + reg); \
> -}
> + void i915_write##x(struct drm_i915_private *dev_priv, u32 reg, u##x 
> val);
> +
>  __i915_write(8, b)
>  __i915_write(16, w)
>  __i915_write(32, l)

Acked-by: Ben Widawsky 

The forcewake increased size should have been fixed a bit with the
forcewake struct encapsulation patch I posted to intel-gfx mailing list.
Keith, if you take this, could you also look into that patch?
<1315951648-5380-1-git-send-email-ben at bwidawsk.net>

[PATCH 1/2] Give up on edid retries when i2c tells us that bus is not there

[Eugeni Dodonov]

On Mon, Oct 17, 2011 at 20:41, Keith Packard  wrote:

> On Mon, 17 Oct 2011 19:07:51 -0200, Eugeni Dodonov 
> wrote:
>
> > From what I've checked, the other return error value in this context
> could
> > be -EREMOTEIO, which could be caused by transmission error so it should
> be
> > retried.
>
> Oh, there's -ENOMEM, -EINVAL and probably a few others down in the
> bowels of the kernel i2c bits. Starting with the obvious (ENXIO) seems
> safest to me.
>

Yes, of course, but I was referring to the values which could be returned
through the i2c-algo-bit call used in this edid detection call.

-- 
Eugeni Dodonov
 <http://eugeni.dodonov.net/>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20111017/d37c73a6/attachment.htm>

[Bug 41698] [r300g] Flickering user interface in WoW

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=41698

--- Comment #3 from Chris Rankin  2011-10-17 
14:09:13 PDT ---
(In reply to comment #2)
> This problem does not happen with my RV790.

Actually, I'm not so sure about this now. Although the effect is certainly a
lot less visible that with the RV350 and M66GL.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

Problems with videos and i915 driver

[Daniel Vetter]

On Mon, Oct 17, 2011 at 02:19:22PM -0400, Steven Rostedt wrote:
> On Mon, 2011-10-17 at 19:52 +0200, Daniel Vetter wrote:
> > On Mon, Oct 17, 2011 at 01:06:59PM -0400, Steven Rostedt wrote:
> > > It's running Fedora 14, and I rather avoid Gnome3 and systemd, which
> > > prevents me from moving her to Fedora 15. If F14 does not provide the
> > > necessary updates, I'll move her over to a Debian system.
> > 
> > Generally we're (unfortunately) only now cracking down on a few
> > long-standing Sandybdrige gpu hang issues, so you want something that
> > tracks upstream (and sometimes even git master) pretty closely.
> > 
> 
> What git tree is this? I could try it out.

Just for these fixes you'd need libdrm and xf86-video-intel. Git repos for
these two:

git://anongit.freedesktop.org/git/xorg/driver/xf86-video-intel
git://anongit.freedesktop.org/git/mesa/drm

See

http://intellinuxgraphics.org/download.html

for the entire stack.

Cheers, Daniel
-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48

No subject

be -EREMOTEIO, which could be caused by transmission error so it should be
retried.

-- 
Eugeni Dodonov


--bcaec51f8fc3b70e6504af85018a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Mon, Oct 17, 2011 at 18:41, Keith Packard 

Problems with videos and i915 driver

[Daniel Vetter]

On Mon, Oct 17, 2011 at 01:06:59PM -0400, Steven Rostedt wrote:
> It's running Fedora 14, and I rather avoid Gnome3 and systemd, which
> prevents me from moving her to Fedora 15. If F14 does not provide the
> necessary updates, I'll move her over to a Debian system.

Generally we're (unfortunately) only now cracking down on a few
long-standing Sandybdrige gpu hang issues, so you want something that
tracks upstream (and sometimes even git master) pretty closely.

Cheers, Daniel
-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48

[PATCH 1/2] Give up on edid retries when i2c tells us that bus is not there

[Eugeni Dodonov]

On Mon, Oct 17, 2011 at 18:41, Keith Packard  wrote:

> On Mon, 17 Oct 2011 11:12:29 -0200, Eugeni Dodonov <
> eugeni.dodonov at intel.com> wrote:
>
> > + if (ret == -ENXIO) {
> > + DRM_DEBUG_KMS("drm: skipping non-existent adapter
> %s\n",
> > + adapter->name);
> > + break;
> > + }
>
> This seems good to me; are there additional error values which should
> also be considered fatal and not subject to retry?
>

Problems with videos and i915 driver

[Daniel Vetter]

On Mon, Oct 17, 2011 at 07:40:27AM -0400, Steven Rostedt wrote:
> On Mon, 2011-10-17 at 10:55 +0200, Daniel Vetter wrote:
> > On Sun, Oct 16, 2011 at 02:01:08PM -0400, Steven Rostedt wrote:
> > > [  102.695526] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer 
> > > elapsed... GPU hung
> > > [  102.695538] [drm] capturing error event; look for more information in 
> > > /debug/dri/0/i915_error_state
> > > [  102.699680] [drm:i915_wait_request] *ERROR* i915_wait_request returns 
> > > -11 (awaiting 1 at 0, next 2)
> > 
> > Can you please attach i915_error_state? It contains the gpu crashdump we
> > need to diagnose gpu hangs.
> > 
> 
> As stated you can download the entire drm debug directory from here:

Oops, sorry about missing that.

> For the /debug/drm directory:
> 
> http://rostedt.homelinux.com/private/vid-crash/debugfs-i915.tar.bz2
> 
> 
> But for your convenience I'm also attaching the error state file.

Thanks. Your userspace is issueing MI_WAIT_SCANLINES cmds to the gpu,
which just doesn't work. Can you please upgrade xf86-video-intel to the
latest released version and check whether it works.

Generally userspace with that bug is extremely old (and if the other
things are equally outdated) rather buggy for Sandybridge. I highly
suggest updating the entire graphics stack to something modern
(Sandybridge-wise).

Yours, Daniel
-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48

[PATCH] drm: avoid switching to text console if there is no panic timeout

[Stéphane Marchesin]

On Mon, Oct 17, 2011 at 17:06, Mandeep Singh Baines  wrote:
> From: Hugh Dickins 
>
> Add a check for panic_timeout in the drm_fb_helper_panic() notifier: if
> we're going to reboot immediately, the user will not be able to see the
> messages anyway, and messing with the video mode may display artifacts,
> and certainly get into several layers of complexity (including mutexes and
> memory allocations) which we shall be much safer to avoid.
>
> Signed-off-by: Hugh Dickins 
> [ Edited commit message and modified to short-circuit panic_timeout < 0
> ?instead of testing panic_timeout >= 0. ?-Mandeep ]
> Signed-off-by: Mandeep Singh Baines 

Acked-by: St?phane Marchesin 

> Cc: Dave Airlie 
> Cc: Andrew Morton 
> Cc: dri-devel at lists.freedesktop.org
> ---
> ?drivers/gpu/drm/drm_fb_helper.c | ? ?7 +++
> ?1 files changed, 7 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index f7c6854..0e62c93 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -254,6 +254,13 @@ bool drm_fb_helper_force_kernel_mode(void)
> ?int drm_fb_helper_panic(struct notifier_block *n, unsigned long ununsed,
> ? ? ? ? ? ? ? ? ? ? ? ?void *panic_str)
> ?{
> + ? ? ? /*
> + ? ? ? ?* It's a waste of time and effort to switch back to text console
> + ? ? ? ?* if the kernel should reboot before panic messages can be seen.
> + ? ? ? ?*/
> + ? ? ? if (panic_timeout < 0)
> + ? ? ? ? ? ? ? return 0;
> +
> ? ? ? ?printk(KERN_ERR "panic occurred, switching back to text console\n");
> ? ? ? ?return drm_fb_helper_force_kernel_mode();
> ?}
> --
> 1.7.3.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>

[Bug 38452] ETQW: Renders garbage in some places

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=38452

--- Comment #8 from almos  2011-10-17 10:27:51 PDT ---
(In reply to comment #3)

> The bug is reproducible here with r600g (garbage or freeze), swrastg (crash),
> and catalyst 11.5 (garbage or freeze). I'm using demo and you are using full
> game, so some differences are possible, but afaics its not the case.
> 
> I think r_useIndexBuffers=0 was intended only for ancient low-end hw and was
> tested with lowest settings only. If it is default on some configurations for
> modern hw, then I think it is just autodetection fail in the game.

I already reported this for r300g about a year ago, and the resolution was to
always make sure that r_useIndexBuffers=1 in your config. Otherwise, on r300g
it crashes with any detail setting. The game sets it to 0 whenever the gl
renderer string changes (AFAICT). See comment 85 on RadeonProgram.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH] drm: avoid switching to text console if there is no panic timeout

[David Rientjes]

On Mon, 17 Oct 2011, Mandeep Singh Baines wrote:

> From: Hugh Dickins 
> 
> Add a check for panic_timeout in the drm_fb_helper_panic() notifier: if
> we're going to reboot immediately, the user will not be able to see the
> messages anyway, and messing with the video mode may display artifacts,
> and certainly get into several layers of complexity (including mutexes and
> memory allocations) which we shall be much safer to avoid.
> 
> Signed-off-by: Hugh Dickins 
> [ Edited commit message and modified to short-circuit panic_timeout < 0
>   instead of testing panic_timeout >= 0.  -Mandeep ]
> Signed-off-by: Mandeep Singh Baines 
> Cc: Dave Airlie 
> Cc: Andrew Morton 
> Cc: dri-devel at lists.freedesktop.org

Acked-by: David Rientjes 

[PATCH] drm: avoid switching to text console if there is no panic timeout

[Mandeep Singh Baines]

From: Hugh Dickins 

Add a check for panic_timeout in the drm_fb_helper_panic() notifier: if
we're going to reboot immediately, the user will not be able to see the
messages anyway, and messing with the video mode may display artifacts,
and certainly get into several layers of complexity (including mutexes and
memory allocations) which we shall be much safer to avoid.

Signed-off-by: Hugh Dickins 
[ Edited commit message and modified to short-circuit panic_timeout < 0
  instead of testing panic_timeout >= 0.  -Mandeep ]
Signed-off-by: Mandeep Singh Baines 
Cc: Dave Airlie 
Cc: Andrew Morton 
Cc: dri-devel at lists.freedesktop.org
---
 drivers/gpu/drm/drm_fb_helper.c |7 +++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index f7c6854..0e62c93 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -254,6 +254,13 @@ bool drm_fb_helper_force_kernel_mode(void)
 int drm_fb_helper_panic(struct notifier_block *n, unsigned long ununsed,
void *panic_str)
 {
+   /*
+* It's a waste of time and effort to switch back to text console
+* if the kernel should reboot before panic messages can be seen.
+*/
+   if (panic_timeout < 0)
+   return 0;
+
printk(KERN_ERR "panic occurred, switching back to text console\n");
return drm_fb_helper_force_kernel_mode();
 }
-- 
1.7.3.1

[PATCH 1/2] Give up on edid retries when i2c tells us that bus is not there

[Keith Packard]

On Mon, 17 Oct 2011 19:07:51 -0200, Eugeni Dodonov  
wrote:

> From what I've checked, the other return error value in this context could
> be -EREMOTEIO, which could be caused by transmission error so it should be
> retried.

Oh, there's -ENOMEM, -EINVAL and probably a few others down in the
bowels of the kernel i2c bits. Starting with the obvious (ENXIO) seems
safest to me.

-- 
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20111017/97368ce3/attachment.pgp>

[Bug 38022] ATI Radeon 6950 (Cayman): r600g texture / pixmap corruption

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=38022

--- Comment #14 from Michel D?nzer  2011-10-17 08:41:37 
PDT ---
(In reply to comment #13)
> The symptoms are essentially the same as Harald described, although on a 
> radeon
> 9600xt, [...]

That's probably a different issue from this one (which really seems Cayman
specific) then. If you can still reproduce the problem with radeon.agpmode=-1,
please file your own bug if there isn't one for your card (generation) yet.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 34218] [r300g] Unigine: some surfaces are reflecting too much light

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=34218

Pavel Ondra?ka  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #12 from Pavel Ondra?ka  2011-10-17 
08:24:41 PDT ---
(In reply to comment #11)
> The reg rename pass has be re-enabled, can you try again with the latest code
> from git.

Well, Sanctuary with low shaders seems fine, can't test other setting due to
bug 40448. Closing for now.

Some surfaces in Oilrush still seems little bit overbright, however I can't
compare because with RADEON_DEBUG=noopt both Sanctuary and Oilrush are now
completely broken. And this may be a different bug, will test more. 

BTW the optimizations are now needed for correct output or should I bisect and
report it?

Will also do some benchmarks, IIRC there were some slowdowns last time with reg
rename pass.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

Problems with videos and i915 driver

[Steven Rostedt]

On Mon, 2011-10-17 at 19:52 +0200, Daniel Vetter wrote:
> On Mon, Oct 17, 2011 at 01:06:59PM -0400, Steven Rostedt wrote:
> > It's running Fedora 14, and I rather avoid Gnome3 and systemd, which
> > prevents me from moving her to Fedora 15. If F14 does not provide the
> > necessary updates, I'll move her over to a Debian system.
> 
> Generally we're (unfortunately) only now cracking down on a few
> long-standing Sandybdrige gpu hang issues, so you want something that
> tracks upstream (and sometimes even git master) pretty closely.
> 

What git tree is this? I could try it out.

-- Steve

[Bug 41744] Unigine Heaven shows black textures (Radeon HD4250)

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=41744

--- Comment #4 from Alex Deucher  2011-10-17 06:57:32 PDT 
---
(In reply to comment #3)
> 
> Probably some error with kernel?

You need a newer kernel to use that feature.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 39145] screen goes dark when the graphics driver (radeon) is loaded

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=39145

Alex Deucher  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH 1/2] Give up on edid retries when i2c tells us that bus is not there

[Keith Packard]

On Mon, 17 Oct 2011 11:12:29 -0200, Eugeni Dodonov  wrote:

> + if (ret == -ENXIO) {
> + DRM_DEBUG_KMS("drm: skipping non-existent adapter %s\n",
> + adapter->name);
> + break;
> + }

This seems good to me; are there additional error values which should
also be considered fatal and not subject to retry?

Reviewed-by: Keith Packard 

-keith
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20111017/645b97c2/attachment.pgp>

[Bug 39145] screen goes dark when the graphics driver (radeon) is loaded

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=39145

--- Comment #9 from mikhail.v.gavrilov at gmail.com 2011-10-17 06:41:06 PDT ---
>
> Thanks for testing; that's good news. ?You can configure the choice of
> drivers for a linux build with "make nconfig".
>
> Administrivia:
>
> ?- can you reproduce the bug with a 2.6.39 kernel on squeeze?
> ? If not, that would mean there is some complicating factor other
> ? than the kernel.
>
> ?- does a distro 3.x kernel[1] also avoid the bug? ?If not, please
> ? attach the .config file from the 3.1.0-rc9+ build you tested with.
>
> [1] e.g. from . ?It would
> include usb and networking support. :)
>

I has downloaded from this location
http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.39.4.tar.bz2
linux kernel compiled and works fine! Also without issue with screen
and with usb and network support.

Seems this is not problem in kernel.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH -fixes] ttm: Fix error-path using an uninitialized value

[Thomas Hellstrom]

Pointed out by Michel Daenzer.

Signed-off-by: Thomas Hellstrom 
---
 drivers/gpu/drm/ttm/ttm_bo_util.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c 
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index 6135f58..eeba838 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -321,7 +321,7 @@ int ttm_bo_move_memcpy(struct ttm_buffer_object *bo,
struct ttm_mem_type_manager *man = >man[new_mem->mem_type];
struct ttm_tt *ttm = bo->ttm;
struct ttm_mem_reg *old_mem = >mem;
-   struct ttm_mem_reg old_copy;
+   struct ttm_mem_reg old_copy = *old_mem;
void *old_iomap;
void *new_iomap;
int ret;
-- 
1.7.4.4

[Bug 41698] [r300g] Flickering user interface in WoW

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=41698

--- Comment #2 from Chris Rankin  2011-10-17 
06:26:19 PDT ---
This problem does not happen with my RV790. Possibly this is due to the amount
of GTT/VRAM that this card has:

ATOM BIOS: RV790
radeon :02:00.0: VRAM: 1024M 0x - 0x3FFF (1024M
used)
radeon :02:00.0: GTT: 512M 0x4000 - 0x5FFF
mtrr: type mismatch for d000,1000 old: write-back new: write-combining
[drm] Detected VRAM RAM=1024M, BAR=256M
[drm] RAM width 256bits DDR
[TTM] Zone  kernel: Available graphics memory: 3058994 kiB.
[TTM] Zone   dma32: Available graphics memory: 2097152 kiB.
[TTM] Initializing pool allocator.
[drm] radeon: 1024M of VRAM memory ready
[drm] radeon: 512M of GTT memory ready.

Compare this to both my RV350 and M66GL, each of which has only 256M of VRAM
and 256M of GTT memory.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

Problems with videos and i915 driver

[Steven Rostedt]

On Mon, 2011-10-17 at 19:02 +0200, Daniel Vetter wrote:

> Thanks. Your userspace is issueing MI_WAIT_SCANLINES cmds to the gpu,
> which just doesn't work. Can you please upgrade xf86-video-intel to the
> latest released version and check whether it works.
> 
> Generally userspace with that bug is extremely old (and if the other
> things are equally outdated) rather buggy for Sandybridge. I highly
> suggest updating the entire graphics stack to something modern
> (Sandybridge-wise).

Thanks for the quick response.

OK, I'll wait till after KS to do more on my wife's box. It is currently
useable, and I hate to make it worse and leave her computer in a broken
state ;)


It's running Fedora 14, and I rather avoid Gnome3 and systemd, which
prevents me from moving her to Fedora 15. If F14 does not provide the
necessary updates, I'll move her over to a Debian system.

Thanks!

-- Steve

[PATCH 3/3] vmwgfx: Add vblank stubs

[Thomas Hellstrom]

From: Jakob Bornecrantz 

This fixes kernel panics when running the vbltest from the drm repo. We
can't just skip initializing the vblank system since it sets up certain
state for us, see: "vmwgfx: Enable use of the vblank system."

Signed-off-by: Jakob Bornecrantz 
Signed-off-by: Thomas Hellstrom 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c |2 ++
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.h |2 ++
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c |   19 +++
 3 files changed, 23 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index e07dcf4..b8eb8cd 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -1069,6 +1069,8 @@ static struct drm_driver driver = {
.irq_uninstall = vmw_irq_uninstall,
.irq_handler = vmw_irq_handler,
.get_vblank_counter = vmw_get_vblank_counter,
+   .enable_vblank = vmw_enable_vblank,
+   .disable_vblank = vmw_disable_vblank,
.reclaim_buffers_locked = NULL,
.ioctls = vmw_ioctls,
.num_ioctls = DRM_ARRAY_SIZE(vmw_ioctls),
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h 
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
index 0e9b2ce..30589d0 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
@@ -618,6 +618,8 @@ bool vmw_kms_validate_mode_vram(struct vmw_private 
*dev_priv,
uint32_t pitch,
uint32_t height);
 u32 vmw_get_vblank_counter(struct drm_device *dev, int crtc);
+int vmw_enable_vblank(struct drm_device *dev, int crtc);
+void vmw_disable_vblank(struct drm_device *dev, int crtc);
 int vmw_kms_present(struct vmw_private *dev_priv,
struct drm_file *file_priv,
struct vmw_framebuffer *vfb,
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index 2421d0c..39b99db 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -1459,11 +1459,30 @@ bool vmw_kms_validate_mode_vram(struct vmw_private 
*dev_priv,
return ((u64) pitch * (u64) height) < (u64) dev_priv->vram_size;
 }

+
+/**
+ * Function called by DRM code called with vbl_lock held.
+ */
 u32 vmw_get_vblank_counter(struct drm_device *dev, int crtc)
 {
return 0;
 }

+/**
+ * Function called by DRM code called with vbl_lock held.
+ */
+int vmw_enable_vblank(struct drm_device *dev, int crtc)
+{
+   return -ENOSYS;
+}
+
+/**
+ * Function called by DRM code called with vbl_lock held.
+ */
+void vmw_disable_vblank(struct drm_device *dev, int crtc)
+{
+}
+

 /*
  * Small shared kms functions.
-- 
1.7.4.4


--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
--
___
Dri-devel mailing list
Dri-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

[PATCH 2/3] vmwgfx: Whitespace & code style in display unit

[Thomas Hellstrom]

From: Jakob Bornecrantz 

Signed-off-by: Jakob Bornecrantz 
Signed-off-by: Thomas Hellstrom 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c  |4 +---
 drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c |5 ++---
 2 files changed, 3 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
index a8830d7..92f56bc 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
@@ -362,8 +362,7 @@ static int vmw_ldu_init(struct vmw_private *dev_priv, 
unsigned unit)
 int vmw_kms_init_legacy_display_system(struct vmw_private *dev_priv)
 {
struct drm_device *dev = dev_priv->dev;
-   int i;
-   int ret;
+   int i, ret;

if (dev_priv->ldu_priv) {
DRM_INFO("ldu system already on\n");
@@ -371,7 +370,6 @@ int vmw_kms_init_legacy_display_system(struct vmw_private 
*dev_priv)
}

dev_priv->ldu_priv = kmalloc(sizeof(*dev_priv->ldu_priv), GFP_KERNEL);
-
if (!dev_priv->ldu_priv)
return -ENOMEM;

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
index 319516f..477b2a9 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
@@ -502,8 +502,7 @@ static int vmw_sou_init(struct vmw_private *dev_priv, 
unsigned unit)
 int vmw_kms_init_screen_object_display(struct vmw_private *dev_priv)
 {
struct drm_device *dev = dev_priv->dev;
-   int i;
-   int ret;
+   int i, ret;

if (dev_priv->sou_priv) {
DRM_INFO("sou system already on\n");
@@ -530,7 +529,7 @@ int vmw_kms_init_screen_object_display(struct vmw_private 
*dev_priv)
if (unlikely(ret != 0))
goto err_free;

-   ret = drm_mode_create_dirty_info_property(dev_priv->dev);
+   ret = drm_mode_create_dirty_info_property(dev);
if (unlikely(ret != 0))
goto err_vblank_cleanup;

-- 
1.7.4.4


--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
--
___
Dri-devel mailing list
Dri-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

[PATCH 1/3] vmwgfx: Fix display system init & close functions

[Thomas Hellstrom]

From: Jakob Bornecrantz 

Make sure we null the display private, make sure we catch and
handle vblank failing to init and don't call vblank_cleanup if
we haven't initialized the display system.

Signed-off-by: Jakob Bornecrantz 
Signed-off-by: Thomas Hellstrom 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c  |   30 ++
 drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c |4 +++-
 2 files changed, 25 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
index 7fc8e7d..a8830d7 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
@@ -380,18 +380,31 @@ int vmw_kms_init_legacy_display_system(struct vmw_private 
*dev_priv)
dev_priv->ldu_priv->last_num_active = 0;
dev_priv->ldu_priv->fb = NULL;

-   drm_mode_create_dirty_info_property(dev_priv->dev);
+   /* for old hardware without multimon only enable one display */
+   if (dev_priv->capabilities & SVGA_CAP_MULTIMON)
+   ret = drm_vblank_init(dev, VMWGFX_NUM_DISPLAY_UNITS);
+   else
+   ret = drm_vblank_init(dev, 1);
+   if (ret != 0)
+   goto err_free;

-   if (dev_priv->capabilities & SVGA_CAP_MULTIMON) {
+   ret = drm_mode_create_dirty_info_property(dev);
+   if (ret != 0)
+   goto err_vblank_cleanup;
+
+   if (dev_priv->capabilities & SVGA_CAP_MULTIMON)
for (i = 0; i < VMWGFX_NUM_DISPLAY_UNITS; ++i)
vmw_ldu_init(dev_priv, i);
-   ret = drm_vblank_init(dev, VMWGFX_NUM_DISPLAY_UNITS);
-   } else {
-   /* for old hardware without multimon only enable one display */
+   else
vmw_ldu_init(dev_priv, 0);
-   ret = drm_vblank_init(dev, 1);
-   }

+   return 0;
+
+err_vblank_cleanup:
+   drm_vblank_cleanup(dev);
+err_free:
+   kfree(dev_priv->ldu_priv);
+   dev_priv->ldu_priv = NULL;
return ret;
 }

@@ -399,10 +412,11 @@ int vmw_kms_close_legacy_display_system(struct 
vmw_private *dev_priv)
 {
struct drm_device *dev = dev_priv->dev;

-   drm_vblank_cleanup(dev);
if (!dev_priv->ldu_priv)
return -ENOSYS;

+   drm_vblank_cleanup(dev);
+
BUG_ON(!list_empty(_priv->ldu_priv->active));

kfree(dev_priv->ldu_priv);
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
index 347e406..319516f 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
@@ -545,6 +545,7 @@ err_vblank_cleanup:
drm_vblank_cleanup(dev);
 err_free:
kfree(dev_priv->sou_priv);
+   dev_priv->sou_priv = NULL;
 err_no_mem:
return ret;
 }
@@ -553,10 +554,11 @@ int vmw_kms_close_screen_object_display(struct 
vmw_private *dev_priv)
 {
struct drm_device *dev = dev_priv->dev;

-   drm_vblank_cleanup(dev);
if (!dev_priv->sou_priv)
return -ENOSYS;

+   drm_vblank_cleanup(dev);
+
if (!list_empty(_priv->sou_priv->active))
DRM_ERROR("Still have active outputs when unloading driver");

-- 
1.7.4.4


--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
--
___
Dri-devel mailing list
Dri-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

[PATCH -next 0/3] vmwgfx fixes

[Thomas Hellstrom]

A couple of vmwgfx fixes on top of drm-next / drm-core-next.


--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
--
___
Dri-devel mailing list
Dri-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

[PATCH 2/2] Check if the bus is valid prior to discovering edid.

[Eugeni Dodonov]

This adds a new function intel_drm_get_valid_edid, which attempts to detect
EDID values from available devices and returns quickly in case no connection
is present.  We detect non-existing devices by checking the i2c_transfer
status, and if it fails with the -ENXIO result, we know that the
i2c_algo_bit was unable to locate the hardware, so we give up on further
edid discovery.

This should improve the edid detection timeouts by about 10-30% in most
cases, and by a much larger margin in case of broken or phantom outputs
https://bugs.freedesktop.org/show_bug.cgi?id=41059.

This also removes intel_ddc_probe, whose functionality is now done by
intel_drm_get_valid_edid.

Signed-off-by: Eugeni Dodonov 
---
 drivers/gpu/drm/i915/intel_crt.c   |   46 ++--
 drivers/gpu/drm/i915/intel_dp.c|4 +-
 drivers/gpu/drm/i915/intel_drv.h   |3 +-
 drivers/gpu/drm/i915/intel_hdmi.c  |4 +-
 drivers/gpu/drm/i915/intel_i2c.c   |   42 
 drivers/gpu/drm/i915/intel_lvds.c  |2 +-
 drivers/gpu/drm/i915/intel_modes.c |   29 +--
 drivers/gpu/drm/i915/intel_sdvo.c  |4 +-
 8 files changed, 75 insertions(+), 59 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c
index 0979d88..3b55fdf 100644
--- a/drivers/gpu/drm/i915/intel_crt.c
+++ b/drivers/gpu/drm/i915/intel_crt.c
@@ -273,36 +273,36 @@ static bool intel_crt_detect_ddc(struct drm_connector 
*connector)
 {
struct intel_crt *crt = intel_attached_crt(connector);
struct drm_i915_private *dev_priv = crt->base.base.dev->dev_private;
+   struct edid *edid = NULL;
+   bool is_digital = false;

/* CRT should always be at 0, but check anyway */
if (crt->base.type != INTEL_OUTPUT_ANALOG)
return false;

-   if (intel_ddc_probe(>base, dev_priv->crt_ddc_pin)) {
-   struct edid *edid;
-   bool is_digital = false;
+   edid = intel_drm_get_valid_edid(connector,
+   _priv->gmbus[dev_priv->crt_ddc_pin].adapter);
+   if (!edid)
+   return false;

-   edid = drm_get_edid(connector,
-   _priv->gmbus[dev_priv->crt_ddc_pin].adapter);
-   /*
-* This may be a DVI-I connector with a shared DDC
-* link between analog and digital outputs, so we
-* have to check the EDID input spec of the attached device.
-*
-* On the other hand, what should we do if it is a broken EDID?
-*/
-   if (edid != NULL) {
-   is_digital = edid->input & DRM_EDID_INPUT_DIGITAL;
-   connector->display_info.raw_edid = NULL;
-   kfree(edid);
-   }
+   /*
+* This may be a DVI-I connector with a shared DDC
+* link between analog and digital outputs, so we
+* have to check the EDID input spec of the attached device.
+*
+* On the other hand, what should we do if it is a broken EDID?
+*/
+   if (edid != NULL) {
+   is_digital = edid->input & DRM_EDID_INPUT_DIGITAL;
+   connector->display_info.raw_edid = NULL;
+   kfree(edid);
+   }

-   if (!is_digital) {
-   DRM_DEBUG_KMS("CRT detected via DDC:0x50 [EDID]\n");
-   return true;
-   } else {
-   DRM_DEBUG_KMS("CRT not detected via DDC:0x50 [EDID 
reports a digital panel]\n");
-   }
+   if (!is_digital) {
+   DRM_DEBUG_KMS("CRT detected via DDC:0x50 [EDID]\n");
+   return true;
+   } else {
+   DRM_DEBUG_KMS("CRT not detected via DDC:0x50 [EDID reports a 
digital panel]\n");
}

return false;
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 44fef5e..dd0d8b1 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1715,7 +1715,7 @@ intel_dp_detect(struct drm_connector *connector, bool 
force)
if (intel_dp->force_audio) {
intel_dp->has_audio = intel_dp->force_audio > 0;
} else {
-   edid = drm_get_edid(connector, _dp->adapter);
+   edid = intel_drm_get_valid_edid(connector, _dp->adapter);
if (edid) {
intel_dp->has_audio = drm_detect_monitor_audio(edid);
connector->display_info.raw_edid = NULL;
@@ -1772,7 +1772,7 @@ intel_dp_detect_audio(struct drm_connector *connector)
struct edid *edid;
bool has_audio = false;

-   edid = drm_get_edid(connector, _dp->adapter);
+   edid = intel_drm_get_valid_edid(connector, _dp->adapter);
if (edid) {
has_audio = drm_detect_monitor_audio(edid);

diff --git a/drivers/gpu/drm/i915/intel_drv.h 

[PATCH 1/2] Give up on edid retries when i2c tells us that bus is not there

[Eugeni Dodonov]

This allows to avoid talking to a non-existent bus repeatedly until we
finally timeout. The non-existent bus is signalled by -ENXIO error,
provided by i2c_algo_bit:bit_doAddress call.

As the advantage of such change, all the other routines which use
drm_get_edid would benefit for this timeout.

This change should fix
https://bugs.freedesktop.org/show_bug.cgi?id=41059 and improve overall
edid detection timing by 10-30% in most cases, and by a much larger margin
in case of phantom outputs.

Signed-off-by: Eugeni Dodonov 
---
 drivers/gpu/drm/drm_edid.c |5 +
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 7425e5c..1bca6d7 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -265,6 +265,11 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter, 
unsigned char *buf,
}
};
ret = i2c_transfer(adapter, msgs, 2);
+   if (ret == -ENXIO) {
+   DRM_DEBUG_KMS("drm: skipping non-existent adapter %s\n",
+   adapter->name);
+   break;
+   }
} while (ret != 2 && --retries);

return ret == 2 ? 0 : -1;
-- 
1.7.7

[PATCH] Improvements in edid detection timings (final)

[Eugeni Dodonov]

Those are two identical fixes for improving EDID detection timings, which
also fix extremely slow xrandr queries in case of phantom outputs
(https://bugs.freedesktop.org/show_bug.cgi?id=41059)

The first fix is a small change to drm_edid, which prevents it from talking to
non-existent adapters by detecting them faster.

The second fix replicates the first one within the i915 driver. It does the
same thing, but without touching core DRM files.

Those are some of the testing results from our QA team:

Regressions and functional testing:
 Machine+ports  result
Ironlake(mobile) eDP/VGApass
Ironlake(desktop) DP/VGApass
Ironlake(mobile) LVDS/VGA/DPpass
G45(desktop) VGA/HDMI   pass
Pineview(mobile) LVDS/VGA   pass

xrandr performance:
   Without patch   with patch
E6510(Ironlake mobile) 0.119   0.111
PK1(Ironlake desktop)  0.101   0.080
T410b(Ironlake mobile) 0.406   0.114
G45b( G45 desktop) 0.121   0.091
Pnv1(Pineview mobile)  0.043   0.040

Those are the results for machines affected by phantom outputs issue, based on
fd.o #41059 feedback:

xrandr performance:
   Without patch   with patch
System 1   0.840   0.290
System 2   0.690   0.140
System 3   0.315   0.280
System 4   0.175   0.140
System 6 (original issue)  4s  0.184

We have observed no regressions in any cases, and performance improvements
of 20-30% for edid detection timing. Combining it with the results obtained
at https://bugs.freedesktop.org/show_bug.cgi?id=41059, besides those
improvements it also improves xrandr timing by up to 20x in the worst case
of phantom outputs.

I believe that the better way to fix this is via the drm_get_edid() fix, as
it is a one-line fix and could benefit all other chipsets. And we won't have
to reinvent the wheel with intel_drm_get_edid, which only duplicates the
existent functionality with no additional benefits.

Could we have any feedback or reviewed-by or from non-intel drm maintainers?

Thanks!

Eugeni Dodonov (2):
  Give up on edid retries when i2c tells us that bus is not there
  Check if the bus is valid prior to discovering edid.

 drivers/gpu/drm/drm_edid.c |5 
 drivers/gpu/drm/i915/intel_crt.c   |   46 ++--
 drivers/gpu/drm/i915/intel_dp.c|4 +-
 drivers/gpu/drm/i915/intel_drv.h   |3 +-
 drivers/gpu/drm/i915/intel_hdmi.c  |4 +-
 drivers/gpu/drm/i915/intel_i2c.c   |   42 
 drivers/gpu/drm/i915/intel_lvds.c  |2 +-
 drivers/gpu/drm/i915/intel_modes.c |   29 +--
 drivers/gpu/drm/i915/intel_sdvo.c  |4 +-
 9 files changed, 80 insertions(+), 59 deletions(-)

-- 
1.7.7

[Bug 41846] hitting software fallbacks when using xorg state tracker

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=41846

--- Comment #3 from Michel D?nzer  2011-10-17 04:08:37 
PDT ---
Please attach the Xorg.0.log file.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

Problems with videos and i915 driver

[Daniel Vetter]

On Sun, Oct 16, 2011 at 02:01:08PM -0400, Steven Rostedt wrote:
> [  102.695526] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer 
> elapsed... GPU hung
> [  102.695538] [drm] capturing error event; look for more information in 
> /debug/dri/0/i915_error_state
> [  102.699680] [drm:i915_wait_request] *ERROR* i915_wait_request returns -11 
> (awaiting 1 at 0, next 2)

Can you please attach i915_error_state? It contains the gpu crashdump we
need to diagnose gpu hangs.

Thanks, Daniel
-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48

Problems with videos and i915 driver

[Steven Rostedt]

On Mon, 2011-10-17 at 10:55 +0200, Daniel Vetter wrote:
> On Sun, Oct 16, 2011 at 02:01:08PM -0400, Steven Rostedt wrote:
> > [  102.695526] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer 
> > elapsed... GPU hung
> > [  102.695538] [drm] capturing error event; look for more information in 
> > /debug/dri/0/i915_error_state
> > [  102.699680] [drm:i915_wait_request] *ERROR* i915_wait_request returns 
> > -11 (awaiting 1 at 0, next 2)
> 
> Can you please attach i915_error_state? It contains the gpu crashdump we
> need to diagnose gpu hangs.
> 

As stated you can download the entire drm debug directory from here:

For the /debug/drm directory:

http://rostedt.homelinux.com/private/vid-crash/debugfs-i915.tar.bz2


But for your convenience I'm also attaching the error state file.

-- Steve

-- next part --
A non-text attachment was scrubbed...
Name: i915_error_state.gz
Type: application/x-gzip
Size: 277157 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20111017/4ced536e/attachment-0001.bin>

[Bug 41744] Unigine Heaven shows black textures (Radeon HD4250)

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=41744

--- Comment #3 from Ga?per Sedej  2011-10-17 00:02:20 PDT 
---
gsedej at seraph:~/Prenosi/Unigine_Heaven$ dpkg -l | grep libtxc
ii libtxc-dxtn0 1.0.1-0.2 S3 Texture Compression (S3TC) library

glxinfo:
http://pastebin.com/96JdRUQp

I found out that I need to use R600_ENABLE_S3TC=1
But then I get: 

radeon: The kernel rejected CS, see dmesg for more information.
radeon: The kernel rejected CS, see dmesg for more information.
radeon: The kernel rejected CS, see dmesg for more information.
radeon: The kernel rejected CS, see dmesg for more information.
...
dmesg:
[577112.943190] radeon :01:05.0: r600_check_texture_resource:1214 texture
invalid format 49
[577112.943196] [drm:radeon_cs_ioctl] *ERROR* Invalid command stream !
[577112.945640] radeon :01:05.0: r600_check_texture_resource:1214 texture
invalid format 49
[577112.945650] [drm:radeon_cs_ioctl] *ERROR* Invalid command stream !
[577112.946185] radeon :01:05.0: r600_check_texture_resource:1214 texture
invalid format 52
[577112.946190] [drm:radeon_cs_ioctl] *ERROR* Invalid command stream !
[577112.946467] radeon :01:05.0: r600_check_texture_resource:1214 texture
invalid format 51
[577112.946469] [drm:radeon_cs_ioctl] *ERROR* Invalid command stream !
[577112.947521] radeon :01:05.0: r600_check_texture_resource:1214 texture
invalid format 51

so formats are 49 51 and 52

Probably some error with kernel?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 41740] Mesa 7.12-devel gallium/state_trackers/d3d1x compilation error

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=41740

Jos van Wolput  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |

--- Comment #3 from Jos van Wolput  2011-10-16 
19:33:06 PDT ---
(In reply to comment #1)
> Fixed in mesa/master with f1f7645f23bd11fb54a992cdbe9ef0a6ee0136f3.
I downloaded a fresh git clone of mesa and still get d3dlx compilation errors:
---
d3d11.cpp: In function ?HRESULT GalliumD3D11DeviceCreate(pipe_screen*,
pipe_context*, BOOL, unsigned int, IDXGIAdapter*, ID3D11Device**)?:
d3d11.cpp:224:200: error: new declaration ?HRESULT
GalliumD3D11DeviceCreate(pipe_screen*, pipe_context*, BOOL, unsigned int,
IDXGIAdapter*, ID3D11Device**)?
../gd3dapi/galliumd3d11.h:65:10: error: ambiguates old declaration ?HRESULT
GalliumD3D11DeviceCreate(pipe_screen*, pipe_context*, BOOL, unsigned int,
IDXGIAdapter*, ID3D11Device**)?
In file included from d3d11.cpp:220:0:
d3d11_context.h: In member function ?HRESULT
GalliumD3D11DeviceContext::Map(ID3D11Resource*, unsigned int,
D3D11_MAP, unsigned int, D3D11_MAPPED_SUBRESOURCE*) [with PtrTraits =
nonatomic_device_child_ptr_traits, HRESULT = int, ID3D11Resource =
ID3D11Resource, D3D11_MAP = D3D11_MAP, D3D11_MAPPED_SUBRESOURCE =
D3D11_MAPPED_SUBRESOURCE]?:
d3d11.cpp:231:1:   instantiated from here
d3d11_context.h:1482:12: warning: unused variable ?face? [-Wunused-variable]
d3d11_context.h: In member function ?void
GalliumD3D11DeviceContext::CopySubresourceRegion(ID3D11Resource*,
unsigned int, unsigned int, unsigned int, unsigned int, ID3D11Resource*,
unsigned int, const D3D11_BOX*) [with PtrTraits =
nonatomic_device_child_ptr_traits, ID3D11Resource = ID3D11Resource, D3D11_BOX =
D3D11_BOX]?:
d3d11.cpp:231:1:   instantiated from here
d3d11_context.h:1543:12: warning: unused variable ?dst_face?
[-Wunused-variable]
d3d11_context.h:1545:12: warning: unused variable ?src_face?
[-Wunused-variable]
make[5]: *** [d3d11.o] Error 1
make[5]: Leaving directory
`/home/jos/src/xorg/git-master/mesa/src/gallium/state_trackers/d3d1x/gd3d11'
make[4]: *** [all] Error 2
make[4]: Leaving directory
`/home/jos/src/xorg/git-master/mesa/src/gallium/state_trackers/d3d1x'
make[3]: *** [subdirs] Error 1
---

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 39145] screen goes dark when the graphics driver (radeon) is loaded

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=39145

--- Comment #8 from Jonathan Nieder  2011-10-16 16:52:35 
PDT ---
bugzilla-daemon at freedesktop.org wrote:

> Debian 6.0.3 (squeeze) can boot without described issue with linux
> kernel 3.1.0-rc9+ but without usb and network support :(
> How enabling usb and network support???

Thanks for testing; that's good news.  You can configure the choice of
drivers for a linux build with "make nconfig".

Administrivia:

 - can you reproduce the bug with a 2.6.39 kernel on squeeze?
   If not, that would mean there is some complicating factor other
   than the kernel.

 - does a distro 3.x kernel[1] also avoid the bug?  If not, please
   attach the .config file from the 3.1.0-rc9+ build you tested with.

[1] e.g. from .  It would
include usb and networking support. :)

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 38740] [i915g] Ocular view in Stellarium have wrong colour

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=38740

--- Comment #2 from Stephane Marchesin  
2011-10-16 16:47:36 PDT ---
Ah I see what you mean, nevermind the bug is still there.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 38740] [i915g] Ocular view in Stellarium have wrong colour

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=38740

--- Comment #1 from Stephane Marchesin  
2011-10-16 16:44:25 PDT ---
Works for me on ToT. Can you please test & close?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 41849] New: Mesa error megaglest

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=41849

 Bug #: 41849
   Summary: Mesa error megaglest
Classification: Unclassified
   Product: Mesa
   Version: 7.11
  Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/DRI/Radeon
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: korchoi at mail.ru


Mesa 7.11 implementation error: Unexpected texture format in
radeon_update_wrapper()
Please report at bugs.freedesktop.org

Megaglest crashes entering game, reports the error above.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 39145] screen goes dark when the graphics driver (radeon) is loaded

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=39145

--- Comment #7 from mikhail.v.gavrilov at gmail.com 2011-10-16 16:03:40 PDT ---
> 1. Grab the latest mainline source:
>
> ?# apt-get install git build-essential
> ?$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> ?$ cd linux
>
> 2. Minimal configuration.
>
> ?$ make localmodconfig
>
> 3. Test.
>
> ?$ make deb-pkg
> ?# dpkg -i ../
> ?# reboot
>
> 4. If it works, let us know and declare victory. Otherwise:

Debian 6.0.3 (squeeze) can boot without described issue with linux
kernel 3.1.0-rc9+ but without usb and network support :(
How enabling usb and network support???

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

Re: Problems with videos and i915 driver

[Steven Rostedt]

On Sun, 2011-10-16 at 14:01 -0400, Steven Rostedt wrote:

 For the full dmesg:
 
 http://rostedt.homelinux.com/private/vid-crash/dmesg

Another clue that looks nasty is this line:

[0.427196] pci_root PNP0A08:00: address space collision: host bridge window 
[mem 0x000c8000-0x000d] conflicts with Video ROM [mem 0x000c-0x000cd7ff]

-- Steve


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Problems with videos and i915 driver

[Steven Rostedt]

Hi Keith,

I just upgraded my wife's computer with a new motherboard which has a
(lspci -vv):

Intel Corporation Sandy Bridge Integrated Graphics Controller (rev 09) (prog-if 
00 [VGA controller])
Subsystem: ASUSTeK Computer Inc. Device 844d
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- 
MAbort- SERR- PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 45
Region 0: Memory at fe00 (64-bit, non-prefetchable) [size=4M]
Region 2: Memory at c000 (64-bit, prefetchable) [size=256M]
Region 4: I/O ports at f000 [size=64]
Expansion ROM at unassigned [disabled]
Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
Address: fee0200c  Data: 4191
Capabilities: [d0] Power Management version 2
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA 
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [a4] PCI Advanced Features
AFCap: TP+ FLR+
AFCtrl: FLR-
AFStatus: TP-
Kernel driver in use: i915


With the standard F14 kernel, running any videos locked up the display.
I upgraded her kernel to 3.0.6 and now display no longer locks up but
the videos still do not play. Just sound, but the video is a blank
screen. Here's some of the dmesg:

[1.777679] [drm] Initialized drm 1.1.0 20060810
[1.780689] i915 :00:02.0: PCI INT A - GSI 16 (level, low) - IRQ 16
[1.780693] i915 :00:02.0: setting latency timer to 64
[1.810351] i915 :00:02.0: irq 45 for MSI/MSI-X
[1.810355] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[1.810356] [drm] Driver supports precise vblank timestamp query.
[1.810383] vgaarb: device changed decodes: 
PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem


[2.151171] input: Video Bus as 
/devices/LNXSYSTM:00/device:00/PNP0A08:00/LNXVIDEO:00/input/input2
[2.151197] ACPI: Video Device [GFX0] (multi-head: yes  rom: no  post: no)
[2.151212] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on minor 0


[  102.695526] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... 
GPU hung
[  102.695538] [drm] capturing error event; look for more information in 
/debug/dri/0/i915_error_state
[  102.699680] [drm:i915_wait_request] *ERROR* i915_wait_request returns -11 
(awaiting 1 at 0, next 2)
[  104.490507] [ cut here ]
[  104.490529] WARNING: at drivers/gpu/drm/i915/i915_drv.c:322 
gen6_gt_force_wake_get+0x29/0x48 [i915]()
[  104.490533] Hardware name: System Product Name
[  104.490535] Modules linked in: vfat fat fuse nfs lockd fscache auth_rpcgss 
nfs_acl sunrpc cpufreq_ondemand acpi_cpufreq freq_table mperf ip6t_REJECT 
nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables ipv6 uinput 
snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep 
snd_seq snd_seq_device snd_pcm ppdev iTCO_wdt parport_pc r8169 pcspkr serio_raw 
snd_timer snd soundcore snd_page_alloc parport i2c_i801 iTCO_vendor_support 
xhci_hcd mii microcode usblp joydev pata_acpi ata_generic pata_via wmi 
usb_storage i915 drm_kms_helper drm i2c_algo_bit i2c_core video [last unloaded: 
scsi_wait_scan]
[  104.490579] Pid: 0, comm: swapper Not tainted 3.0.6 #1
[  104.490581] Call Trace:
[  104.490583]  IRQ  [8104a9de] warn_slowpath_common+0x83/0x9b
[  104.490595]  [8104aa10] warn_slowpath_null+0x1a/0x1c
[  104.490605]  [a006753a] gen6_gt_force_wake_get+0x29/0x48 [i915]
[  104.490617]  [a006afd9] i915_read32+0x33/0x6b [i915]
[  104.490629]  [a006dfdf] i915_hangcheck_elapsed+0xbb/0x1eb [i915]
[  104.490634]  [8105781d] run_timer_softirq+0x19b/0x280
[  104.490640]  [8100e95d] ? paravirt_read_tsc+0x9/0xd
[  104.490651]  [a006df24] ? i915_vblank_swap+0x10/0x10 [i915]
[  104.490657]  [81050645] __do_softirq+0xc9/0x1b5
[  104.490661]  [8100e95d] ? paravirt_read_tsc+0x9/0xd
[  104.490665]  [8147269c] call_softirq+0x1c/0x30
[  104.490669]  [8100aba1] do_softirq+0x46/0x81
[  104.490673]  [81050922] irq_exit+0x52/0xaf
[  104.490677]  [81472fb1] smp_apic_timer_interrupt+0x7c/0x8a
[  104.490682]  [81471e53] apic_timer_interrupt+0x13/0x20
[  104.490684]  EOI  [8100e95d] ? paravirt_read_tsc+0x9/0xd
[  104.490692]  [812664fc] ? intel_idle+0xd8/0x100
[  104.490696]  [812664de] ? intel_idle+0xba/0x100
[  104.490700]  [8138ad2d] cpuidle_idle_call+0xd7/0x168
[  104.490705]  [81008307] cpu_idle+0xa5/0xdf
[  104.490711]  [81449b7e] rest_init+0x72/0x74
[  104.490716]  [81b5ab8b] start_kernel+0x3ca/0x3d5
[  104.490720]  [81b5a2c4] x86_64_start_reservations+0xaf/0xb3
[  104.490724]  

[Bug 41744] Unigine Heaven shows black textures (Radeon HD4250)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=41744

--- Comment #3 from Gašper Sedej gse...@gmail.com 2011-10-17 00:02:20 PDT ---
gsedej@seraph:~/Prenosi/Unigine_Heaven$ dpkg -l | grep libtxc
ii libtxc-dxtn0 1.0.1-0.2 S3 Texture Compression (S3TC) library

glxinfo:
http://pastebin.com/96JdRUQp

I found out that I need to use R600_ENABLE_S3TC=1
But then I get: 

radeon: The kernel rejected CS, see dmesg for more information.
radeon: The kernel rejected CS, see dmesg for more information.
radeon: The kernel rejected CS, see dmesg for more information.
radeon: The kernel rejected CS, see dmesg for more information.
...
dmesg:
[577112.943190] radeon :01:05.0: r600_check_texture_resource:1214 texture
invalid format 49
[577112.943196] [drm:radeon_cs_ioctl] *ERROR* Invalid command stream !
[577112.945640] radeon :01:05.0: r600_check_texture_resource:1214 texture
invalid format 49
[577112.945650] [drm:radeon_cs_ioctl] *ERROR* Invalid command stream !
[577112.946185] radeon :01:05.0: r600_check_texture_resource:1214 texture
invalid format 52
[577112.946190] [drm:radeon_cs_ioctl] *ERROR* Invalid command stream !
[577112.946467] radeon :01:05.0: r600_check_texture_resource:1214 texture
invalid format 51
[577112.946469] [drm:radeon_cs_ioctl] *ERROR* Invalid command stream !
[577112.947521] radeon :01:05.0: r600_check_texture_resource:1214 texture
invalid format 51

so formats are 49 51 and 52

Probably some error with kernel?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Problems with videos and i915 driver

[Daniel Vetter]

On Sun, Oct 16, 2011 at 02:01:08PM -0400, Steven Rostedt wrote:
 [  102.695526] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer 
 elapsed... GPU hung
 [  102.695538] [drm] capturing error event; look for more information in 
 /debug/dri/0/i915_error_state
 [  102.699680] [drm:i915_wait_request] *ERROR* i915_wait_request returns -11 
 (awaiting 1 at 0, next 2)

Can you please attach i915_error_state? It contains the gpu crashdump we
need to diagnose gpu hangs.

Thanks, Daniel
-- 
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/3] vmwgfx: Whitespace code style in display unit

[Thomas Hellstrom]

From: Jakob Bornecrantz ja...@vmware.com

Signed-off-by: Jakob Bornecrantz ja...@vmware.com
Signed-off-by: Thomas Hellstrom thellst...@vmware.com
---
 drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c  |4 +---
 drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c |5 ++---
 2 files changed, 3 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
index a8830d7..92f56bc 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
@@ -362,8 +362,7 @@ static int vmw_ldu_init(struct vmw_private *dev_priv, 
unsigned unit)
 int vmw_kms_init_legacy_display_system(struct vmw_private *dev_priv)
 {
struct drm_device *dev = dev_priv-dev;
-   int i;
-   int ret;
+   int i, ret;
 
if (dev_priv-ldu_priv) {
DRM_INFO(ldu system already on\n);
@@ -371,7 +370,6 @@ int vmw_kms_init_legacy_display_system(struct vmw_private 
*dev_priv)
}
 
dev_priv-ldu_priv = kmalloc(sizeof(*dev_priv-ldu_priv), GFP_KERNEL);
-
if (!dev_priv-ldu_priv)
return -ENOMEM;
 
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
index 319516f..477b2a9 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
@@ -502,8 +502,7 @@ static int vmw_sou_init(struct vmw_private *dev_priv, 
unsigned unit)
 int vmw_kms_init_screen_object_display(struct vmw_private *dev_priv)
 {
struct drm_device *dev = dev_priv-dev;
-   int i;
-   int ret;
+   int i, ret;
 
if (dev_priv-sou_priv) {
DRM_INFO(sou system already on\n);
@@ -530,7 +529,7 @@ int vmw_kms_init_screen_object_display(struct vmw_private 
*dev_priv)
if (unlikely(ret != 0))
goto err_free;
 
-   ret = drm_mode_create_dirty_info_property(dev_priv-dev);
+   ret = drm_mode_create_dirty_info_property(dev);
if (unlikely(ret != 0))
goto err_vblank_cleanup;
 
-- 
1.7.4.4


--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
--
___
Dri-devel mailing list
dri-de...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH -next 0/3] vmwgfx fixes

[Thomas Hellstrom]

A couple of vmwgfx fixes on top of drm-next / drm-core-next.


--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
--
___
Dri-devel mailing list
dri-de...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 3/3] vmwgfx: Add vblank stubs

[Thomas Hellstrom]

From: Jakob Bornecrantz ja...@vmware.com

This fixes kernel panics when running the vbltest from the drm repo. We
can't just skip initializing the vblank system since it sets up certain
state for us, see: vmwgfx: Enable use of the vblank system.

Signed-off-by: Jakob Bornecrantz ja...@vmware.com
Signed-off-by: Thomas Hellstrom thellst...@vmware.com
---
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c |2 ++
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.h |2 ++
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c |   19 +++
 3 files changed, 23 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index e07dcf4..b8eb8cd 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -1069,6 +1069,8 @@ static struct drm_driver driver = {
.irq_uninstall = vmw_irq_uninstall,
.irq_handler = vmw_irq_handler,
.get_vblank_counter = vmw_get_vblank_counter,
+   .enable_vblank = vmw_enable_vblank,
+   .disable_vblank = vmw_disable_vblank,
.reclaim_buffers_locked = NULL,
.ioctls = vmw_ioctls,
.num_ioctls = DRM_ARRAY_SIZE(vmw_ioctls),
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h 
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
index 0e9b2ce..30589d0 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
@@ -618,6 +618,8 @@ bool vmw_kms_validate_mode_vram(struct vmw_private 
*dev_priv,
uint32_t pitch,
uint32_t height);
 u32 vmw_get_vblank_counter(struct drm_device *dev, int crtc);
+int vmw_enable_vblank(struct drm_device *dev, int crtc);
+void vmw_disable_vblank(struct drm_device *dev, int crtc);
 int vmw_kms_present(struct vmw_private *dev_priv,
struct drm_file *file_priv,
struct vmw_framebuffer *vfb,
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index 2421d0c..39b99db 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -1459,11 +1459,30 @@ bool vmw_kms_validate_mode_vram(struct vmw_private 
*dev_priv,
return ((u64) pitch * (u64) height)  (u64) dev_priv-vram_size;
 }
 
+
+/**
+ * Function called by DRM code called with vbl_lock held.
+ */
 u32 vmw_get_vblank_counter(struct drm_device *dev, int crtc)
 {
return 0;
 }
 
+/**
+ * Function called by DRM code called with vbl_lock held.
+ */
+int vmw_enable_vblank(struct drm_device *dev, int crtc)
+{
+   return -ENOSYS;
+}
+
+/**
+ * Function called by DRM code called with vbl_lock held.
+ */
+void vmw_disable_vblank(struct drm_device *dev, int crtc)
+{
+}
+
 
 /*
  * Small shared kms functions.
-- 
1.7.4.4


--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
--
___
Dri-devel mailing list
dri-de...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/3] vmwgfx: Fix display system init close functions

[Thomas Hellstrom]

From: Jakob Bornecrantz ja...@vmware.com

Make sure we null the display private, make sure we catch and
handle vblank failing to init and don't call vblank_cleanup if
we haven't initialized the display system.

Signed-off-by: Jakob Bornecrantz ja...@vmware.com
Signed-off-by: Thomas Hellstrom thellst...@vmware.com
---
 drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c  |   30 ++
 drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c |4 +++-
 2 files changed, 25 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
index 7fc8e7d..a8830d7 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
@@ -380,18 +380,31 @@ int vmw_kms_init_legacy_display_system(struct vmw_private 
*dev_priv)
dev_priv-ldu_priv-last_num_active = 0;
dev_priv-ldu_priv-fb = NULL;
 
-   drm_mode_create_dirty_info_property(dev_priv-dev);
+   /* for old hardware without multimon only enable one display */
+   if (dev_priv-capabilities  SVGA_CAP_MULTIMON)
+   ret = drm_vblank_init(dev, VMWGFX_NUM_DISPLAY_UNITS);
+   else
+   ret = drm_vblank_init(dev, 1);
+   if (ret != 0)
+   goto err_free;
 
-   if (dev_priv-capabilities  SVGA_CAP_MULTIMON) {
+   ret = drm_mode_create_dirty_info_property(dev);
+   if (ret != 0)
+   goto err_vblank_cleanup;
+
+   if (dev_priv-capabilities  SVGA_CAP_MULTIMON)
for (i = 0; i  VMWGFX_NUM_DISPLAY_UNITS; ++i)
vmw_ldu_init(dev_priv, i);
-   ret = drm_vblank_init(dev, VMWGFX_NUM_DISPLAY_UNITS);
-   } else {
-   /* for old hardware without multimon only enable one display */
+   else
vmw_ldu_init(dev_priv, 0);
-   ret = drm_vblank_init(dev, 1);
-   }
 
+   return 0;
+
+err_vblank_cleanup:
+   drm_vblank_cleanup(dev);
+err_free:
+   kfree(dev_priv-ldu_priv);
+   dev_priv-ldu_priv = NULL;
return ret;
 }
 
@@ -399,10 +412,11 @@ int vmw_kms_close_legacy_display_system(struct 
vmw_private *dev_priv)
 {
struct drm_device *dev = dev_priv-dev;
 
-   drm_vblank_cleanup(dev);
if (!dev_priv-ldu_priv)
return -ENOSYS;
 
+   drm_vblank_cleanup(dev);
+
BUG_ON(!list_empty(dev_priv-ldu_priv-active));
 
kfree(dev_priv-ldu_priv);
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
index 347e406..319516f 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
@@ -545,6 +545,7 @@ err_vblank_cleanup:
drm_vblank_cleanup(dev);
 err_free:
kfree(dev_priv-sou_priv);
+   dev_priv-sou_priv = NULL;
 err_no_mem:
return ret;
 }
@@ -553,10 +554,11 @@ int vmw_kms_close_screen_object_display(struct 
vmw_private *dev_priv)
 {
struct drm_device *dev = dev_priv-dev;
 
-   drm_vblank_cleanup(dev);
if (!dev_priv-sou_priv)
return -ENOSYS;
 
+   drm_vblank_cleanup(dev);
+
if (!list_empty(dev_priv-sou_priv-active))
DRM_ERROR(Still have active outputs when unloading driver);
 
-- 
1.7.4.4


--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
--
___
Dri-devel mailing list
dri-de...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 41846] hitting software fallbacks when using xorg state tracker

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=41846

--- Comment #3 from Michel Dänzer mic...@daenzer.net 2011-10-17 04:08:37 PDT 
---
Please attach the Xorg.0.log file.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH -fixes] ttm: Fix error-path using an uninitialized value

[Thomas Hellstrom]

Pointed out by Michel Daenzer.

Signed-off-by: Thomas Hellstrom thellst...@vmware.com
---
 drivers/gpu/drm/ttm/ttm_bo_util.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c 
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index 6135f58..eeba838 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -321,7 +321,7 @@ int ttm_bo_move_memcpy(struct ttm_buffer_object *bo,
struct ttm_mem_type_manager *man = bdev-man[new_mem-mem_type];
struct ttm_tt *ttm = bo-ttm;
struct ttm_mem_reg *old_mem = bo-mem;
-   struct ttm_mem_reg old_copy;
+   struct ttm_mem_reg old_copy = *old_mem;
void *old_iomap;
void *new_iomap;
int ret;
-- 
1.7.4.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] Improvements in edid detection timings (final)

[Eugeni Dodonov]

Those are two identical fixes for improving EDID detection timings, which
also fix extremely slow xrandr queries in case of phantom outputs
(https://bugs.freedesktop.org/show_bug.cgi?id=41059)

The first fix is a small change to drm_edid, which prevents it from talking to
non-existent adapters by detecting them faster.

The second fix replicates the first one within the i915 driver. It does the
same thing, but without touching core DRM files.

Those are some of the testing results from our QA team:

Regressions and functional testing:
 Machine+ports  result
Ironlake(mobile) eDP/VGApass
Ironlake(desktop) DP/VGApass
Ironlake(mobile) LVDS/VGA/DPpass
G45(desktop) VGA/HDMI   pass
Pineview(mobile) LVDS/VGA   pass

xrandr performance:
   Without patch   with patch
E6510(Ironlake mobile) 0.119   0.111
PK1(Ironlake desktop)  0.101   0.080
T410b(Ironlake mobile) 0.406   0.114
G45b( G45 desktop) 0.121   0.091
Pnv1(Pineview mobile)  0.043   0.040

Those are the results for machines affected by phantom outputs issue, based on
fd.o #41059 feedback:

xrandr performance:
   Without patch   with patch
System 1   0.840   0.290
System 2   0.690   0.140
System 3   0.315   0.280
System 4   0.175   0.140
System 6 (original issue)  4s  0.184

We have observed no regressions in any cases, and performance improvements
of 20-30% for edid detection timing. Combining it with the results obtained
at https://bugs.freedesktop.org/show_bug.cgi?id=41059, besides those
improvements it also improves xrandr timing by up to 20x in the worst case
of phantom outputs.

I believe that the better way to fix this is via the drm_get_edid() fix, as
it is a one-line fix and could benefit all other chipsets. And we won't have
to reinvent the wheel with intel_drm_get_edid, which only duplicates the
existent functionality with no additional benefits.

Could we have any feedback or reviewed-by or from non-intel drm maintainers?

Thanks!

Eugeni Dodonov (2):
  Give up on edid retries when i2c tells us that bus is not there
  Check if the bus is valid prior to discovering edid.

 drivers/gpu/drm/drm_edid.c |5 
 drivers/gpu/drm/i915/intel_crt.c   |   46 ++--
 drivers/gpu/drm/i915/intel_dp.c|4 +-
 drivers/gpu/drm/i915/intel_drv.h   |3 +-
 drivers/gpu/drm/i915/intel_hdmi.c  |4 +-
 drivers/gpu/drm/i915/intel_i2c.c   |   42 
 drivers/gpu/drm/i915/intel_lvds.c  |2 +-
 drivers/gpu/drm/i915/intel_modes.c |   29 +--
 drivers/gpu/drm/i915/intel_sdvo.c  |4 +-
 9 files changed, 80 insertions(+), 59 deletions(-)

-- 
1.7.7

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/2] Give up on edid retries when i2c tells us that bus is not there

[Eugeni Dodonov]

This allows to avoid talking to a non-existent bus repeatedly until we
finally timeout. The non-existent bus is signalled by -ENXIO error,
provided by i2c_algo_bit:bit_doAddress call.

As the advantage of such change, all the other routines which use
drm_get_edid would benefit for this timeout.

This change should fix
https://bugs.freedesktop.org/show_bug.cgi?id=41059 and improve overall
edid detection timing by 10-30% in most cases, and by a much larger margin
in case of phantom outputs.

Signed-off-by: Eugeni Dodonov eugeni.dodo...@intel.com
---
 drivers/gpu/drm/drm_edid.c |5 +
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 7425e5c..1bca6d7 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -265,6 +265,11 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter, 
unsigned char *buf,
}
};
ret = i2c_transfer(adapter, msgs, 2);
+   if (ret == -ENXIO) {
+   DRM_DEBUG_KMS(drm: skipping non-existent adapter %s\n,
+   adapter-name);
+   break;
+   }
} while (ret != 2  --retries);
 
return ret == 2 ? 0 : -1;
-- 
1.7.7

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/2] Check if the bus is valid prior to discovering edid.

[Eugeni Dodonov]

This adds a new function intel_drm_get_valid_edid, which attempts to detect
EDID values from available devices and returns quickly in case no connection
is present.  We detect non-existing devices by checking the i2c_transfer
status, and if it fails with the -ENXIO result, we know that the
i2c_algo_bit was unable to locate the hardware, so we give up on further
edid discovery.

This should improve the edid detection timeouts by about 10-30% in most
cases, and by a much larger margin in case of broken or phantom outputs
https://bugs.freedesktop.org/show_bug.cgi?id=41059.

This also removes intel_ddc_probe, whose functionality is now done by
intel_drm_get_valid_edid.

Signed-off-by: Eugeni Dodonov eugeni.dodo...@intel.com
---
 drivers/gpu/drm/i915/intel_crt.c   |   46 ++--
 drivers/gpu/drm/i915/intel_dp.c|4 +-
 drivers/gpu/drm/i915/intel_drv.h   |3 +-
 drivers/gpu/drm/i915/intel_hdmi.c  |4 +-
 drivers/gpu/drm/i915/intel_i2c.c   |   42 
 drivers/gpu/drm/i915/intel_lvds.c  |2 +-
 drivers/gpu/drm/i915/intel_modes.c |   29 +--
 drivers/gpu/drm/i915/intel_sdvo.c  |4 +-
 8 files changed, 75 insertions(+), 59 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c
index 0979d88..3b55fdf 100644
--- a/drivers/gpu/drm/i915/intel_crt.c
+++ b/drivers/gpu/drm/i915/intel_crt.c
@@ -273,36 +273,36 @@ static bool intel_crt_detect_ddc(struct drm_connector 
*connector)
 {
struct intel_crt *crt = intel_attached_crt(connector);
struct drm_i915_private *dev_priv = crt-base.base.dev-dev_private;
+   struct edid *edid = NULL;
+   bool is_digital = false;
 
/* CRT should always be at 0, but check anyway */
if (crt-base.type != INTEL_OUTPUT_ANALOG)
return false;
 
-   if (intel_ddc_probe(crt-base, dev_priv-crt_ddc_pin)) {
-   struct edid *edid;
-   bool is_digital = false;
+   edid = intel_drm_get_valid_edid(connector,
+   dev_priv-gmbus[dev_priv-crt_ddc_pin].adapter);
+   if (!edid)
+   return false;
 
-   edid = drm_get_edid(connector,
-   dev_priv-gmbus[dev_priv-crt_ddc_pin].adapter);
-   /*
-* This may be a DVI-I connector with a shared DDC
-* link between analog and digital outputs, so we
-* have to check the EDID input spec of the attached device.
-*
-* On the other hand, what should we do if it is a broken EDID?
-*/
-   if (edid != NULL) {
-   is_digital = edid-input  DRM_EDID_INPUT_DIGITAL;
-   connector-display_info.raw_edid = NULL;
-   kfree(edid);
-   }
+   /*
+* This may be a DVI-I connector with a shared DDC
+* link between analog and digital outputs, so we
+* have to check the EDID input spec of the attached device.
+*
+* On the other hand, what should we do if it is a broken EDID?
+*/
+   if (edid != NULL) {
+   is_digital = edid-input  DRM_EDID_INPUT_DIGITAL;
+   connector-display_info.raw_edid = NULL;
+   kfree(edid);
+   }
 
-   if (!is_digital) {
-   DRM_DEBUG_KMS(CRT detected via DDC:0x50 [EDID]\n);
-   return true;
-   } else {
-   DRM_DEBUG_KMS(CRT not detected via DDC:0x50 [EDID 
reports a digital panel]\n);
-   }
+   if (!is_digital) {
+   DRM_DEBUG_KMS(CRT detected via DDC:0x50 [EDID]\n);
+   return true;
+   } else {
+   DRM_DEBUG_KMS(CRT not detected via DDC:0x50 [EDID reports a 
digital panel]\n);
}
 
return false;
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 44fef5e..dd0d8b1 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1715,7 +1715,7 @@ intel_dp_detect(struct drm_connector *connector, bool 
force)
if (intel_dp-force_audio) {
intel_dp-has_audio = intel_dp-force_audio  0;
} else {
-   edid = drm_get_edid(connector, intel_dp-adapter);
+   edid = intel_drm_get_valid_edid(connector, intel_dp-adapter);
if (edid) {
intel_dp-has_audio = drm_detect_monitor_audio(edid);
connector-display_info.raw_edid = NULL;
@@ -1772,7 +1772,7 @@ intel_dp_detect_audio(struct drm_connector *connector)
struct edid *edid;
bool has_audio = false;
 
-   edid = drm_get_edid(connector, intel_dp-adapter);
+   edid = intel_drm_get_valid_edid(connector, intel_dp-adapter);
if (edid) {
has_audio = drm_detect_monitor_audio(edid);
 
diff --git 

[Bug 41698] [r300g] Flickering user interface in WoW

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=41698

--- Comment #2 from Chris Rankin ranki...@googlemail.com 2011-10-17 06:26:19 
PDT ---
This problem does not happen with my RV790. Possibly this is due to the amount
of GTT/VRAM that this card has:

ATOM BIOS: RV790
radeon :02:00.0: VRAM: 1024M 0x - 0x3FFF (1024M
used)
radeon :02:00.0: GTT: 512M 0x4000 - 0x5FFF
mtrr: type mismatch for d000,1000 old: write-back new: write-combining
[drm] Detected VRAM RAM=1024M, BAR=256M
[drm] RAM width 256bits DDR
[TTM] Zone  kernel: Available graphics memory: 3058994 kiB.
[TTM] Zone   dma32: Available graphics memory: 2097152 kiB.
[TTM] Initializing pool allocator.
[drm] radeon: 1024M of VRAM memory ready
[drm] radeon: 512M of GTT memory ready.

Compare this to both my RV350 and M66GL, each of which has only 256M of VRAM
and 256M of GTT memory.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 39145] screen goes dark when the graphics driver (radeon) is loaded

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=39145

--- Comment #9 from mikhail.v.gavri...@gmail.com 2011-10-17 06:41:06 PDT ---

 Thanks for testing; that's good news.  You can configure the choice of
 drivers for a linux build with make nconfig.

 Administrivia:

  - can you reproduce the bug with a 2.6.39 kernel on squeeze?
   If not, that would mean there is some complicating factor other
   than the kernel.

  - does a distro 3.x kernel[1] also avoid the bug?  If not, please
   attach the .config file from the 3.1.0-rc9+ build you tested with.

 [1] e.g. from http://wiki.debian.org/DebianExperimental.  It would
 include usb and networking support. :)


I has downloaded from this location
http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.39.4.tar.bz2
linux kernel compiled and works fine! Also without issue with screen
and with usb and network support.

Seems this is not problem in kernel.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 39145] screen goes dark when the graphics driver (radeon) is loaded

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=39145

Alex Deucher ag...@yahoo.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 41744] Unigine Heaven shows black textures (Radeon HD4250)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=41744

--- Comment #4 from Alex Deucher ag...@yahoo.com 2011-10-17 06:57:32 PDT ---
(In reply to comment #3)
 
 Probably some error with kernel?

You need a newer kernel to use that feature.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 34218] [r300g] Unigine: some surfaces are reflecting too much light

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=34218

Pavel Ondračka pavel.ondra...@email.cz changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #12 from Pavel Ondračka pavel.ondra...@email.cz 2011-10-17 
08:24:41 PDT ---
(In reply to comment #11)
 The reg rename pass has be re-enabled, can you try again with the latest code
 from git.

Well, Sanctuary with low shaders seems fine, can't test other setting due to
bug 40448. Closing for now.

Some surfaces in Oilrush still seems little bit overbright, however I can't
compare because with RADEON_DEBUG=noopt both Sanctuary and Oilrush are now
completely broken. And this may be a different bug, will test more. 

BTW the optimizations are now needed for correct output or should I bisect and
report it?

Will also do some benchmarks, IIRC there were some slowdowns last time with reg
rename pass.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 38022] ATI Radeon 6950 (Cayman): r600g texture / pixmap corruption

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=38022

--- Comment #14 from Michel Dänzer mic...@daenzer.net 2011-10-17 08:41:37 PDT 
---
(In reply to comment #13)
 The symptoms are essentially the same as Harald described, although on a 
 radeon
 9600xt, [...]

That's probably a different issue from this one (which really seems Cayman
specific) then. If you can still reproduce the problem with radeon.agpmode=-1,
please file your own bug if there isn't one for your card (generation) yet.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Problems with videos and i915 driver

[Daniel Vetter]

On Mon, Oct 17, 2011 at 07:40:27AM -0400, Steven Rostedt wrote:
 On Mon, 2011-10-17 at 10:55 +0200, Daniel Vetter wrote:
  On Sun, Oct 16, 2011 at 02:01:08PM -0400, Steven Rostedt wrote:
   [  102.695526] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer 
   elapsed... GPU hung
   [  102.695538] [drm] capturing error event; look for more information in 
   /debug/dri/0/i915_error_state
   [  102.699680] [drm:i915_wait_request] *ERROR* i915_wait_request returns 
   -11 (awaiting 1 at 0, next 2)
  
  Can you please attach i915_error_state? It contains the gpu crashdump we
  need to diagnose gpu hangs.
  
 
 As stated you can download the entire drm debug directory from here:

Oops, sorry about missing that.

 For the /debug/drm directory:
 
 http://rostedt.homelinux.com/private/vid-crash/debugfs-i915.tar.bz2
 
 
 But for your convenience I'm also attaching the error state file.

Thanks. Your userspace is issueing MI_WAIT_SCANLINES cmds to the gpu,
which just doesn't work. Can you please upgrade xf86-video-intel to the
latest released version and check whether it works.

Generally userspace with that bug is extremely old (and if the other
things are equally outdated) rather buggy for Sandybridge. I highly
suggest updating the entire graphics stack to something modern
(Sandybridge-wise).

Yours, Daniel
-- 
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 38452] ETQW: Renders garbage in some places

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=38452

--- Comment #8 from almos aaalmo...@gmail.com 2011-10-17 10:27:51 PDT ---
(In reply to comment #3)

 The bug is reproducible here with r600g (garbage or freeze), swrastg (crash),
 and catalyst 11.5 (garbage or freeze). I'm using demo and you are using full
 game, so some differences are possible, but afaics its not the case.
 
 I think r_useIndexBuffers=0 was intended only for ancient low-end hw and was
 tested with lowest settings only. If it is default on some configurations for
 modern hw, then I think it is just autodetection fail in the game.

I already reported this for r300g about a year ago, and the resolution was to
always make sure that r_useIndexBuffers=1 in your config. Otherwise, on r300g
it crashes with any detail setting. The game sets it to 0 whenever the gl
renderer string changes (AFAICT). See comment 85 on RadeonProgram.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Problems with videos and i915 driver

[Steven Rostedt]

On Mon, 2011-10-17 at 19:02 +0200, Daniel Vetter wrote:

 Thanks. Your userspace is issueing MI_WAIT_SCANLINES cmds to the gpu,
 which just doesn't work. Can you please upgrade xf86-video-intel to the
 latest released version and check whether it works.
 
 Generally userspace with that bug is extremely old (and if the other
 things are equally outdated) rather buggy for Sandybridge. I highly
 suggest updating the entire graphics stack to something modern
 (Sandybridge-wise).

Thanks for the quick response.

OK, I'll wait till after KS to do more on my wife's box. It is currently
useable, and I hate to make it worse and leave her computer in a broken
state ;)


It's running Fedora 14, and I rather avoid Gnome3 and systemd, which
prevents me from moving her to Fedora 15. If F14 does not provide the
necessary updates, I'll move her over to a Debian system.

Thanks!

-- Steve


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Problems with videos and i915 driver

[Daniel Vetter]

On Mon, Oct 17, 2011 at 01:06:59PM -0400, Steven Rostedt wrote:
 It's running Fedora 14, and I rather avoid Gnome3 and systemd, which
 prevents me from moving her to Fedora 15. If F14 does not provide the
 necessary updates, I'll move her over to a Debian system.

Generally we're (unfortunately) only now cracking down on a few
long-standing Sandybdrige gpu hang issues, so you want something that
tracks upstream (and sometimes even git master) pretty closely.

Cheers, Daniel
-- 
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Problems with videos and i915 driver

[Daniel Vetter]

On Mon, Oct 17, 2011 at 02:19:22PM -0400, Steven Rostedt wrote:
 On Mon, 2011-10-17 at 19:52 +0200, Daniel Vetter wrote:
  On Mon, Oct 17, 2011 at 01:06:59PM -0400, Steven Rostedt wrote:
   It's running Fedora 14, and I rather avoid Gnome3 and systemd, which
   prevents me from moving her to Fedora 15. If F14 does not provide the
   necessary updates, I'll move her over to a Debian system.
  
  Generally we're (unfortunately) only now cracking down on a few
  long-standing Sandybdrige gpu hang issues, so you want something that
  tracks upstream (and sometimes even git master) pretty closely.
  
 
 What git tree is this? I could try it out.

Just for these fixes you'd need libdrm and xf86-video-intel. Git repos for
these two:

git://anongit.freedesktop.org/git/xorg/driver/xf86-video-intel
git://anongit.freedesktop.org/git/mesa/drm

See

http://intellinuxgraphics.org/download.html

for the entire stack.

Cheers, Daniel
-- 
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/2] Give up on edid retries when i2c tells us that bus is not there

[Keith Packard]

On Mon, 17 Oct 2011 11:12:29 -0200, Eugeni Dodonov eugeni.dodo...@intel.com 
wrote:

 + if (ret == -ENXIO) {
 + DRM_DEBUG_KMS(drm: skipping non-existent adapter %s\n,
 + adapter-name);
 + break;
 + }

This seems good to me; are there additional error values which should
also be considered fatal and not subject to retry?

Reviewed-by: Keith Packard kei...@keithp.com

-keith


pgpFsUdLzQUmW.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/2] Give up on edid retries when i2c tells us that bus is not there

[Eugeni Dodonov]

On Mon, Oct 17, 2011 at 18:41, Keith Packard kei...@keithp.com wrote:

 On Mon, 17 Oct 2011 11:12:29 -0200, Eugeni Dodonov 
 eugeni.dodo...@intel.com wrote:

  + if (ret == -ENXIO) {
  + DRM_DEBUG_KMS(drm: skipping non-existent adapter
 %s\n,
  + adapter-name);
  + break;
  + }

 This seems good to me; are there additional error values which should
 also be considered fatal and not subject to retry?


From what I've checked, the other return error value in this context could
be -EREMOTEIO, which could be caused by transmission error so it should be
retried.

-- 
Eugeni Dodonov
http://eugeni.dodonov.net/
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 41698] [r300g] Flickering user interface in WoW

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=41698

--- Comment #3 from Chris Rankin ranki...@googlemail.com 2011-10-17 14:09:13 
PDT ---
(In reply to comment #2)
 This problem does not happen with my RV790.

Actually, I'm not so sure about this now. Although the effect is certainly a
lot less visible that with the RV350 and M66GL.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/2] Give up on edid retries when i2c tells us that bus is not there

[Keith Packard]

On Mon, 17 Oct 2011 19:07:51 -0200, Eugeni Dodonov eug...@dodonov.net wrote:

 From what I've checked, the other return error value in this context could
 be -EREMOTEIO, which could be caused by transmission error so it should be
 retried.

Oh, there's -ENOMEM, -EINVAL and probably a few others down in the
bowels of the kernel i2c bits. Starting with the obvious (ENXIO) seems
safest to me.

-- 
keith.pack...@intel.com


pgpBgH8gSeXmr.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 30412] opengl doesn't work when using gallium and xorg state tracker

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=30412

Martin Stolpe martinsto...@gmail.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 41846] hitting software fallbacks when using xorg state tracker

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=41846

--- Comment #4 from Martin Stolpe martinsto...@gmail.com 2011-10-17 16:39:11 
PDT ---
Created attachment 52448
  -- https://bugs.freedesktop.org/attachment.cgi?id=52448
Xorg.0.log

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 41846] hitting software fallbacks when using xorg state tracker

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=41846

--- Comment #5 from Martin Stolpe martinsto...@gmail.com 2011-10-17 16:39:40 
PDT ---
Created attachment 52449
  -- https://bugs.freedesktop.org/attachment.cgi?id=52449
xorg.conf

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/2] Give up on edid retries when i2c tells us that bus is not there

[Eugeni Dodonov]

On Mon, Oct 17, 2011 at 20:41, Keith Packard kei...@keithp.com wrote:

 On Mon, 17 Oct 2011 19:07:51 -0200, Eugeni Dodonov eug...@dodonov.net
 wrote:

  From what I've checked, the other return error value in this context
 could
  be -EREMOTEIO, which could be caused by transmission error so it should
 be
  retried.

 Oh, there's -ENOMEM, -EINVAL and probably a few others down in the
 bowels of the kernel i2c bits. Starting with the obvious (ENXIO) seems
 safest to me.


Yes, of course, but I was referring to the values which could be returned
through the i2c-algo-bit call used in this edid detection call.

-- 
Eugeni Dodonov
 http://eugeni.dodonov.net/
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: avoid switching to text console if there is no panic timeout

[David Rientjes]

On Mon, 17 Oct 2011, Mandeep Singh Baines wrote:

 From: Hugh Dickins hu...@chromium.org
 
 Add a check for panic_timeout in the drm_fb_helper_panic() notifier: if
 we're going to reboot immediately, the user will not be able to see the
 messages anyway, and messing with the video mode may display artifacts,
 and certainly get into several layers of complexity (including mutexes and
 memory allocations) which we shall be much safer to avoid.
 
 Signed-off-by: Hugh Dickins hu...@google.com
 [ Edited commit message and modified to short-circuit panic_timeout  0
   instead of testing panic_timeout = 0.  -Mandeep ]
 Signed-off-by: Mandeep Singh Baines m...@chromium.org
 Cc: Dave Airlie airl...@redhat.com
 Cc: Andrew Morton a...@linux-foundation.org
 Cc: dri-devel@lists.freedesktop.org

Acked-by: David Rientjes rient...@google.com
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: avoid switching to text console if there is no panic timeout

[Stéphane Marchesin]

On Mon, Oct 17, 2011 at 17:06, Mandeep Singh Baines m...@chromium.org wrote:
 From: Hugh Dickins hu...@chromium.org

 Add a check for panic_timeout in the drm_fb_helper_panic() notifier: if
 we're going to reboot immediately, the user will not be able to see the
 messages anyway, and messing with the video mode may display artifacts,
 and certainly get into several layers of complexity (including mutexes and
 memory allocations) which we shall be much safer to avoid.

 Signed-off-by: Hugh Dickins hu...@google.com
 [ Edited commit message and modified to short-circuit panic_timeout  0
  instead of testing panic_timeout = 0.  -Mandeep ]
 Signed-off-by: Mandeep Singh Baines m...@chromium.org

Acked-by: Stéphane Marchesin marc...@chromium.org

 Cc: Dave Airlie airl...@redhat.com
 Cc: Andrew Morton a...@linux-foundation.org
 Cc: dri-devel@lists.freedesktop.org
 ---
  drivers/gpu/drm/drm_fb_helper.c |    7 +++
  1 files changed, 7 insertions(+), 0 deletions(-)

 diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
 index f7c6854..0e62c93 100644
 --- a/drivers/gpu/drm/drm_fb_helper.c
 +++ b/drivers/gpu/drm/drm_fb_helper.c
 @@ -254,6 +254,13 @@ bool drm_fb_helper_force_kernel_mode(void)
  int drm_fb_helper_panic(struct notifier_block *n, unsigned long ununsed,
                        void *panic_str)
  {
 +       /*
 +        * It's a waste of time and effort to switch back to text console
 +        * if the kernel should reboot before panic messages can be seen.
 +        */
 +       if (panic_timeout  0)
 +               return 0;
 +
        printk(KERN_ERR panic occurred, switching back to text console\n);
        return drm_fb_helper_force_kernel_mode();
  }
 --
 1.7.3.1

 ___
 dri-devel mailing list
 dri-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel