[Bug 64220] GPU lockup in L4D2 on SUMO and TURKS

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

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

Andreas Boll  changed:

   What|Removed |Added

Version|7.10|9.1
  Component|Drivers/DRI/R600|Drivers/Gallium/r600

--- Comment #4 from Andreas Boll  ---
Does setting the env var R600_HYPERZ=0 help?
If yes, an upgrade to mesa 9.1.2, where hyperz is disabled by default, should
fix your issue.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130504/38f55d6c/attachment-0001.html>

[Bug 64201] OpenCL usage result segmentation fault on r600g with HD6850.

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

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

--- Comment #7 from Tom Stellard  ---
(In reply to comment #4)
> Hi friends,
> 
> @Vincent, I will add output as an attachment.
> 
> @Tom Stellard
> 
> For pyrit : svn checkout http://pyrit.googlecode.com/svn/trunk/
> pyrit-read-only
> 
> I don't patched it. Will report with your patch asap.
> 
> Other programs are cgminer : https://github.com/ckolivas/cgminer
> 

I would recommend using bfgminer for bitcoin mining.  It auto-detects the mesa
platform, and disabled unsupported features.  All you need to do to get it to
work is pass the -v1 flag.

> And python-opencl package from suse repo that give  pipe_r600.so fault.
> 

Can you open a separate bug for this or any other programs you've tried.

> Any other program that I trued doesn't work on my card, yet.



> 
> Thanks.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130504/91002b11/attachment.html>

[Bug 60553] [trine2] wrong colors when executed fullscreen

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

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

--- Comment #8 from letharion at gmail.com ---
Created attachment 78862
  --> https://bugs.freedesktop.org/attachment.cgi?id=78862=edit
Trine 2 windowed. Proper rendering.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130504/956aa27f/attachment.html>

[Bug 60553] [trine2] wrong colors when executed fullscreen

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

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

letharion at gmail.com changed:

   What|Removed |Added

  Attachment #78860|0   |1
is obsolete||

--- Comment #7 from letharion at gmail.com ---
Created attachment 78861
  --> https://bugs.freedesktop.org/attachment.cgi?id=78861=edit
Trine 2 in fullscreen, heavy miss rendering.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130504/11d15d6f/attachment.html>

DMA mapping API abuse in exynos-drm

[Tomasz Figa]

Hi,

Recently I've been working a bit on a DRM driver for the GPU of Samsung 
S3C6410 SoCs, which required me to familiarize a bit with exynos-drm, as 
it already contains a KMS driver which is compatible with the SoC I'm 
working with, making it a good place to put my driver in.

Reading through exynos_drm_buf.c I stumbled across following (a bit long) 
piece of code:

dma_set_attr(DMA_ATTR_NO_KERNEL_MAPPING, >dma_attrs);

nr_pages = buf->size >> PAGE_SHIFT;

if (!is_drm_iommu_supported(dev)) {
dma_addr_t start_addr;
unsigned int i = 0;

buf->pages = kzalloc(sizeof(struct page) * nr_pages,
GFP_KERNEL);
if (!buf->pages) {
DRM_ERROR("failed to allocate pages.\n");
return -ENOMEM;
}

buf->kvaddr = dma_alloc_attrs(dev->dev, buf->size,
>dma_addr, GFP_KERNEL,
>dma_attrs);
if (!buf->kvaddr) {
DRM_ERROR("failed to allocate buffer.\n");
kfree(buf->pages);
return -ENOMEM;
}

start_addr = buf->dma_addr;
while (i < nr_pages) {
buf->pages[i] = phys_to_page(start_addr);
start_addr += PAGE_SIZE;
i++;
}
} else {

buf->pages = dma_alloc_attrs(dev->dev, buf->size,
>dma_addr, GFP_KERNEL,
>dma_attrs);
if (!buf->pages) {
DRM_ERROR("failed to allocate buffer.\n");
return -ENOMEM;
}
}

buf->sgt = drm_prime_pages_to_sg(buf->pages, nr_pages);
if (!buf->sgt) {
DRM_ERROR("failed to get sg table.\n");
ret = -ENOMEM;
goto err_free_attrs;
}

Notice that the value returned by dma_alloc_attrs() is assumed by this 
code to be either a kernel virtual address (in !is_drm_iommu_supported() 
case) or struct pages ** (in is_drm_iommu_supported() case), which seemed 
a bit worrying to me, making me do a more in depth research on how 
dma_alloc_attrs works.

This, in turn, led me to following excerpt of Documentation/DMA-
attributes.txt :

DMA_ATTR_NO_KERNEL_MAPPING
--

DMA_ATTR_NO_KERNEL_MAPPING lets the platform to avoid creating a kernel
virtual mapping for the allocated buffer. On some architectures creating
such mapping is non-trivial task and consumes very limited resources
(like kernel virtual address space or dma consistent address space).
Buffers allocated with this attribute can be only passed to user space
by calling dma_mmap_attrs(). By using this API, you are guaranteeing
that you won't dereference the pointer returned by dma_alloc_attr(). You
can threat it as a cookie that must be passed to dma_mmap_attrs() and
dma_free_attrs(). Make sure that both of these also get this attribute
set on each call.

of which the following sentence is the most relevant:

By using this API, you are guaranteeing that you won't dereference the 
pointer returned by dma_alloc_attr().

This statement is obviously ignored by buffer allocation code of exynos-
drm.

A simple git blame revealed that this brokenness has been introduced by 
commit:

4744ad2 drm/exynos: use DMA_ATTR_NO_KERNEL_MAPPING attribute


and later fixed a bit by following depending patches (because the original 
patch apparently broke any allocations without IOMMU):

c704f1b drm/exynos: consider no iommu support to console framebuffer
694be45 drm/exynos: consider buffer allocation without iommu


Now, the real question is whether my reasoning is incorrect (sorry for the 
noise then) or this is really a bug which needs to be fixed?

Best regards,
Tomasz

[Bug 60553] [trine2] wrong colors when executed fullscreen

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

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

--- Comment #6 from letharion at gmail.com ---
Created attachment 78860
  --> https://bugs.freedesktop.org/attachment.cgi?id=78860=edit
Trine 2 in fullscreen, heavy miss rendering.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130504/edea8e5c/attachment.html>

[Bug 60553] [trine2] wrong colors when executed fullscreen

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

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

letharion at gmail.com changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #5 from letharion at gmail.com ---
Running with mesa as of c4150123aa9c2a71a62fed800d7c4424e9b948f2 I do not see
this fixed.

The problems in the main menu, as shows in the screenshots already attached,
remain. I'll attach images of gameplay as well, as the effect is shown more
clearly there.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130504/c8a340d3/attachment.html>

[Bug 64220] GPU lockup in L4D2 on SUMO and TURKS

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

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

--- Comment #3 from runetmember at gmail.com ---
This GPU lockup is also reproducible on Radeon HD 6650M.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130504/766c5efb/attachment.html>

[Bug 64220] GPU lockup in L4D2 on SUMO and TURKS

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

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

runetmember at gmail.com changed:

   What|Removed |Added

Summary|GPU lockup in L4D2 on SUMO  |GPU lockup in L4D2 on SUMO
   ||and TURKS

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130504/ece96419/attachment-0001.html>

[PULL] drm-intel-fixes

[Daniel Vetter]

Hi Dave,

A few intel fixes for smaller issues and one revert for an sdv hack which
we've wanted to kill anyway. Plus two drm patches included for your
convenience, both regression fixers for mine own screw-ups.

Cheers, Daniel

The following changes since commit 43b27290dd42b40f3f23f49677a7faa5a4eb1eff:

  drm/i915: correct the calculation of first_pd_entry_in_global_pt (2013-04-27 
14:07:16 +0200)

are available in the git repository at:

  git://people.freedesktop.org/~danvet/drm-intel drm-intel-fixes

for you to fetch changes up to 3ab9c63705cb7b1b9f83ddce725d8bd9ef7c66a9:

  drm/i915: hsw: fix link training for eDP on port-A (2013-05-04 10:24:56 +0200)


Chris Wilson (1):
  drm/i915: Always normalize return timeout for wait_timeout_ioctl

Daniel Vetter (3):
  drm/mm: fix dump table BUG
  drm: don't check modeset locks in panic handler
  Revert "drm/i915: revert eDP bpp clamping code changes"

Imre Deak (1):
  drm/i915: hsw: fix link training for eDP on port-A

Ville Syrj?l? (1):
  drm/i915: Fix pipe enabled mask for pipe C in WM calculations

 drivers/gpu/drm/drm_crtc.c   |4 ++
 drivers/gpu/drm/drm_mm.c |   34 +
 drivers/gpu/drm/i915/i915_gem.c  |8 ++--
 drivers/gpu/drm/i915/intel_ddi.c |5 +++
 drivers/gpu/drm/i915/intel_dp.c  |   77 --
 drivers/gpu/drm/i915/intel_drv.h |1 +
 drivers/gpu/drm/i915/intel_pm.c  |   44 +++---
 7 files changed, 101 insertions(+), 72 deletions(-)
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[Bug 56659] DRI_PRIME: triangle, rendering inside of which occurs with a noticeable delay

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

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

--- Comment #4 from runetmember at gmail.com ---
Still reproducible with radeon 7.1.0. Tested on native Left 4 Dead 2.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130504/384746a8/attachment.html>

[Bug 64220] GPU lockup in L4D2 on SUMO

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

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

--- Comment #2 from runetmember at gmail.com ---
Created attachment 78858
  --> https://bugs.freedesktop.org/attachment.cgi?id=78858=edit
Xorg log

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130504/de165c8a/attachment.html>

[Bug 64220] GPU lockup in L4D2 on SUMO

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

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

--- Comment #1 from runetmember at gmail.com ---
Created attachment 78857
  --> https://bugs.freedesktop.org/attachment.cgi?id=78857=edit
dmesg

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130504/98647fc1/attachment.html>

[Bug 64220] New: GPU lockup in L4D2 on SUMO

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

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

  Priority: medium
Bug ID: 64220
  Assignee: dri-devel at lists.freedesktop.org
   Summary: GPU lockup in L4D2 on SUMO
  Severity: normal
Classification: Unclassified
OS: All
  Reporter: runetmember at gmail.com
  Hardware: Other
Status: NEW
   Version: 7.10
 Component: Drivers/DRI/R600
   Product: Mesa

To reproduce this issue start L4D2, load any campaign, kill few zombies. It'll
take less than a minute to GPU hang happen. Logs attached.

Software:
Linux 3.8.0-19
libdrm 2.4.43
Mesa 9.1.1
xserver-xorg-video-radeon 7.1.0
Xserver 1.13.3
Kubuntu 13.04 x86_64

Hardware:
A8-3500M with Radeon HD 6620G.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130504/212c38d4/attachment.html>

[Bug 61747] [r600g] GPU lockup when playing WoW with HD6450 with htile enabled

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

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

--- Comment #13 from Chris Rankin  ---
This version of Mesa is a lot more promising!

OpenGL vendor string: X.Org
OpenGL renderer string: Gallium 0.4 on AMD CAICOS
OpenGL core profile version string: 3.1 (Core Profile) Mesa 9.2.0 (git-8c347d4)
OpenGL core profile shading language version string: 1.40
OpenGL core profile context flags: (none)

No lock-ups so far!

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130504/f51a1398/attachment.html>

[PATCH 2/7] drm (ast, cirrus, mgag200, nouveau, savage, vmwgfx): Rework drm_mtrr_{add, del}

[Daniel Vetter]

On Fri, May 03, 2013 at 04:00:30PM -0700, Andy Lutomirski wrote:
> This replaces drm_mtrr_{add,del} with drm_mtrr_{add,del}_wc.  The
> interface is simplified (because the base and size parameters to
> drm_mtrr_del never did anything) and it uses
> mtrr_{add,del}_wc_if_needed to avoid allocating MTRRs on systems
> that don't need them.
> 
> Signed-off-by: Andy Lutomirski 
> ---

[snip]

> diff --git a/include/drm/drmP.h b/include/drm/drmP.h
> index 2d94d74..2a3e1fd 100644
> --- a/include/drm/drmP.h
> +++ b/include/drm/drmP.h
> @@ -1250,18 +1250,15 @@ static inline int drm_core_has_MTRR(struct drm_device 
> *dev)
>   return drm_core_check_feature(dev, DRIVER_USE_MTRR);
>  }
>  
> -#define DRM_MTRR_WC  MTRR_TYPE_WRCOMB
> -
> -static inline int drm_mtrr_add(unsigned long offset, unsigned long size,
> -unsigned int flags)
> +static inline int __must_check drm_mtrr_add_wc(unsigned long offset,
> +unsigned long size)
>  {
> - return mtrr_add(offset, size, flags, 1);
> + return mtrr_add_wc_if_needed(offset, size);
>  }
>  
> -static inline int drm_mtrr_del(int handle, unsigned long offset,
> -unsigned long size, unsigned int flags)
> +static inline void drm_mtrr_del_wc(int handle)
>  {
> - return mtrr_del(handle, offset, size);
> + mtrr_del_wc_if_needed(handle);
>  }
>  
>  #else
> @@ -1269,16 +1266,14 @@ static inline int drm_mtrr_del(int handle, unsigned 
> long offset,
>  
>  #define DRM_MTRR_WC  0
>  
> -static inline int drm_mtrr_add(unsigned long offset, unsigned long size,
> -unsigned int flags)
> +static inline int __must_check drm_mtrr_add_wc(unsigned long offset,
> +unsigned long size)
>  {
> - return 0;
> + return -1;
>  }
>  
> -static inline int drm_mtrr_del(int handle, unsigned long offset,
> -unsigned long size, unsigned int flags)
> +static inline void drm_mtrr_del_wc(int handle)
>  {
> - return 0;
>  }

Tbh I'm not a big fan of the drm_ indirection. Historically that was
useful as an OS abstraction layer so that the same drivers could be used
unchanged on Linux and the *BSD. But those days are long gone and drm
drivers are now proper Linux drivers, and generally OS HALs seem to be
frowned upon.

Is there another reason than just being consistent with the historic stuff
here? If we need dummy functions for !CONFIG_MTRR I think those should
simply be in the core.

And if the inconsistency bugs you I'd volunteer myself to ditch the old
drm_ mtrr helpers.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[Bug 64193] LLVM RV670 regression since R600: Packetize instructions

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

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

--- Comment #7 from Andy Furniss  ---
Created attachment 78855
  --> https://bugs.freedesktop.org/attachment.cgi?id=78855=edit
R600_DEBUG=vs,ps,fs glxgears rendering dark on heads

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130504/e1122375/attachment.html>

[Bug 64193] LLVM RV670 regression since R600: Packetize instructions

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

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

--- Comment #6 from Andy Furniss  ---
Created attachment 78854
  --> https://bugs.freedesktop.org/attachment.cgi?id=78854=edit
R600_DEBUG=vs,ps,fs glxgears rendering OK on packetize with patch

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130504/ac1635dd/attachment.html>

[Bug 64193] LLVM RV670 regression since R600: Packetize instructions

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

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

--- Comment #5 from Andy Furniss  ---
(In reply to comment #4)
> Can you cherry pick this patch :
> https://bugs.freedesktop.org/attachment.cgi?id=78786 (from bugid 64096) on
> top of 25f259cde28860ea76c2f5628010968945a28edb and post the output of
> R600_DEBUG=vs,ps,fs again please ?

glxgears looks normal with the patch, though it doesn't fix other demos/games
eg.
nexuiz just hung and gloss renders almost OK but the sides are matt with no
reflection.

I'll attach the debug as requested and one from heads I did this morning as
well where it is rendering dark.

FWIW when llvm is on packetize mesa doesn't build on head so for these it's
been (random choice) set on 

e2b985dc0f93a195d984aa7c88669ab67160c6c4

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130504/fb349cc9/attachment.html>

[Bug 63935] TURKS [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!!

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

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

--- Comment #7 from Parag  ---
I am getting the same error on HD6750M - I verified the kernel (Linus git from
today) I am running has the raise clocks patch. I've also replaced everything
in /lib/firmware/radeon from
http://people.freedesktop.org/~agd5f/radeon_ucode/. 

lspci | grep -i radeon
--
01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI
Whistler [Radeon HD 6600M/6700M/7600M Series]
01:00.1 Audio device: Advanced Micro Devices [AMD] nee ATI Turks/Whistler HDMI
Audio [Radeon HD 6000 Series]

dmesg
-
dmesg |grep -i uvd
[   17.676387] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset
the VCPU!!!
[   18.697587] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset
the VCPU!!!
[   19.718765] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset
the VCPU!!!
[   20.739957] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset
the VCPU!!!
[   21.761139] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset
the VCPU!!!
[   22.782347] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset
the VCPU!!!
[   23.803569] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset
the VCPU!!!
[   24.824728] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset
the VCPU!!!
[   25.845904] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset
the VCPU!!!
[   26.867070] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset
the VCPU!!!
[   26.887096] [drm:r600_uvd_init] *ERROR* UVD not responding, giving up!!!
[   26.887102] [drm:evergreen_startup] *ERROR* radeon: error initializing UVD
(-1).

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130504/e6aa9d56/attachment.html>

[Bug 63730] UVD broken on HD5470 by "drm/radeon: raise UVD clocks only on demand"

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

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

Parag  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #19 from Parag  ---
Ugh, wrong status and wrong bug looks like. I will leave this closed and
comment on 63935 which seems more appropriate. Sorry about the noise.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130504/6d436c9f/attachment.html>

[Bug 63730] UVD broken on HD5470 by "drm/radeon: raise UVD clocks only on demand"

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

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

Parag  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #18 from Parag  ---
I am getting the same error on HD6750M - I verified the kernel (Linus git from
today) I am running has the raise clocks patch. I've also replaced everything
in /lib/firmware/radeon from
http://people.freedesktop.org/~agd5f/radeon_ucode/. 

lspci | grep -i radeon
--
01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI
Whistler [Radeon HD 6600M/6700M/7600M Series]
01:00.1 Audio device: Advanced Micro Devices [AMD] nee ATI Turks/Whistler HDMI
Audio [Radeon HD 6000 Series]

dmesg
-
dmesg |grep -i uvd
[   17.676387] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset
the VCPU!!!
[   18.697587] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset
the VCPU!!!
[   19.718765] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset
the VCPU!!!
[   20.739957] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset
the VCPU!!!
[   21.761139] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset
the VCPU!!!
[   22.782347] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset
the VCPU!!!
[   23.803569] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset
the VCPU!!!
[   24.824728] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset
the VCPU!!!
[   25.845904] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset
the VCPU!!!
[   26.867070] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset
the VCPU!!!
[   26.887096] [drm:r600_uvd_init] *ERROR* UVD not responding, giving up!!!
[   26.887102] [drm:evergreen_startup] *ERROR* radeon: error initializing UVD
(-1).

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130504/dcbb6f60/attachment-0001.html>

[Bug 64193] LLVM RV670 regression since R600: Packetize instructions

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

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

--- Comment #4 from vincent  ---
Can you cherry pick this patch :
https://bugs.freedesktop.org/attachment.cgi?id=78786 (from bugid 64096) on top
of 25f259cde28860ea76c2f5628010968945a28edb and post the output of
R600_DEBUG=vs,ps,fs again please ?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130504/fc0a916d/attachment.html>

[Bug 64201] OpenCL usage result segmentation fault on r600g with HD6850.

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

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

--- Comment #6 from Erdem U. Altinyurt  ---
Created attachment 78839
  --> https://bugs.freedesktop.org/attachment.cgi?id=78839=edit
Pyrit Debug log with Patched LLVM-trunk

Hi again,
I attached debug log with patch for examination.
Regards,
Erdem

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130504/bd40685c/attachment.html>

[Bug 64201] OpenCL usage result segmentation fault on r600g with HD6850.

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

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

--- Comment #5 from Erdem U. Altinyurt  ---
Created attachment 78838
  --> https://bugs.freedesktop.org/attachment.cgi?id=78838=edit
Pyrit Error log with Debug

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130504/8c645914/attachment-0001.html>

[Bug 64201] OpenCL usage result segmentation fault on r600g with HD6850.

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

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

--- Comment #4 from Erdem U. Altinyurt  ---
Hi friends,

@Vincent, I will add output as an attachment.

@Tom Stellard

For pyrit : svn checkout http://pyrit.googlecode.com/svn/trunk/ pyrit-read-only

I don't patched it. Will report with your patch asap.

Other programs are cgminer : https://github.com/ckolivas/cgminer

And python-opencl package from suse repo that give  pipe_r600.so fault.

Any other program that I trued doesn't work on my card, yet.

Thanks.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130504/8c571afe/attachment.html>

[Intel-gfx] [PATCH] [TRIVIAL] Fix declaration of intel_gmbus_{is_forced_bit/is_port_falid} in i915 driver.

[PaX Team]

On 3 May 2013 at 15:03, Jani Nikula wrote:

> >> This fixes a compilation issue with clang. An initial version of this patch
> >> was developed by PaX Team .
> >> This is respin of this patch.
> >> 
> >> Signed-off-by: Jan-Simon M?ller 
> >> CC: pageexec at freemail.hu
> >> CC: daniel.vetter at ffwll.ch
> >> CC: airlied at linux.ie
> >> CC: intel-gfx at lists.freedesktop.org
> >> CC: dri-devel at lists.freedesktop.org
> >> CC: linux-kernel at vger.kernel.org
> > Picked up for -fixes, thanks for the patch.
> 
> Please drop it.
> 
> The patch removes the inline keyword, creating dozens of copies of the
> functions, and consequently loads of warnings:

in my original patch they were both static inline, not sure where the
inline got lost...

[PATCH 2/7] drm (ast, cirrus, mgag200, nouveau, savage, vmwgfx): Rework drm_mtrr_{add, del}

[Andy Lutomirski]

On Sat, May 4, 2013 at 10:45 AM, Daniel Vetter  wrote:
> On Fri, May 03, 2013 at 04:00:30PM -0700, Andy Lutomirski wrote:
>> This replaces drm_mtrr_{add,del} with drm_mtrr_{add,del}_wc.  The
>> interface is simplified (because the base and size parameters to
>> drm_mtrr_del never did anything) and it uses
>> mtrr_{add,del}_wc_if_needed to avoid allocating MTRRs on systems
>> that don't need them.
>>
>> Signed-off-by: Andy Lutomirski 
>> ---
>
>
> Tbh I'm not a big fan of the drm_ indirection. Historically that was
> useful as an OS abstraction layer so that the same drivers could be used
> unchanged on Linux and the *BSD. But those days are long gone and drm
> drivers are now proper Linux drivers, and generally OS HALs seem to be
> frowned upon.
>
> Is there another reason than just being consistent with the historic stuff
> here? If we need dummy functions for !CONFIG_MTRR I think those should
> simply be in the core.


I admit to a bit of cargo-culting.  There was a layer of indirection,
so I kept it.  I'll just call mtrr_add/del_wc_if_needed directly in v2
(I added those functions in patch 1 of this series).

I'd assume you're okay with skipping mtrr addition if PAT is available
since i915 already does it :)  (Although the current logic is buggy --
cpu_has_pat is the wrong flag to check -- I think pat_enabled is
better.)

Note to self: I should remove #include  in i915_dma.c in v2.

--Andy

[git pull] drm for 3.10-rc1

[Daniel Vetter]

On Sat, May 4, 2013 at 3:18 AM, Josh Boyer  wrote:
> On Fri, May 03, 2013 at 10:40:17PM +0200, Daniel Vetter wrote:
>>On Fri, May 3, 2013 at 10:31 PM, Josh Boyer  wrote:
>>> OK.  Git bisect tells me this:
>>>
>>> 57c219633275c7e7413f8bc7be250dc092887458 is the first bad commit
>>> commit 57c219633275c7e7413f8bc7be250dc092887458
>>> Author: Daniel Vetter 
>>> Date:   Thu Apr 4 17:19:37 2013 +0200
>>>
>>> drm/i915: revert eDP bpp clamping code changes
>>
>>Yeah, that commit is a bit dubios and for 3.11 we've already planned
>>to kick it out. It tries to work around an issue on a funky
>>pre-release hw. Does reverting this commit fix your issue?
>
> Yes, seems so.  I reverted it on top of Linus tree as of commit
> ce857229e0c3adc2 and things boot normally on the machine after that.

Thanks for confirming, I've reverted the patch and will foward my
current drm-intel-fixes tree soon to Dave.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCHv5 0/2] Speed Cap fixes for ppc64

[Benjamin Herrenschmidt]

On Fri, 2013-05-03 at 19:43 -0300, Kleber Sacilotto de Souza wrote:

> This patch series does:
>   1. max_bus_speed is used to set the device to gen2 speeds
>   2. on power there's no longer a conflict between the pseries call and other
> architectures, because the overwrite is done via a ppc_md hook
>   3. radeon is using bus->max_bus_speed instead of drm_pcie_get_speed_cap_mask
> for gen2 capability detection
> 
> The first patch consists of some architecture changes, such as adding a hook 
> on
> powerpc for pci_root_bridge_prepare, so that pseries will initialize it to a
> function, while all other architectures get a NULL pointer. So that whenever
> pci_create_root_bus is called, we'll get max_bus_speed properly setup from
> OpenFirmware.
> 
> The second patch consists of simple radeon changes not to call
> drm_get_pcie_speed_cap_mask anymore. I assume that on x86 machines,
> the max_bus_speed property will be properly set already.

So I'm ok with the approach now and I might even put the powerpc patch
in for 3.10 since arguably we are fixing a nasty bug (uninitialized
max_bus_speed).

David, what's your feeling about the radeon change ? It would be nice if
that could go in soon for various distro targets :-) On the other hand
I'm not going to be pushy if you are not comfortable with it.

Cheers,
Ben.

[Bug 64201] OpenCL usage result segmentation fault on r600g with HD6850.

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

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

--- Comment #3 from Tom Stellard  ---
Created attachment 78831
  --> https://bugs.freedesktop.org/attachment.cgi?id=78831=edit
Possible fix

This patch should fix the error you were seeing with pyrit.  However, it's
possible you will now see a different error.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130504/c6712c0b/attachment.html>

[Bug 63973] Regression in WebGL gl-vertexattribpointer.html by commit 5649f886f7602

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

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

Bryan Quigley  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #1 from Bryan Quigley  ---
This was reverted in commit: c4bea00fb39fb1813d220b95f0bc94e6fce8c84a

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130504/3c9e0362/attachment.html>

[Bug 64201] OpenCL usage result segmentation fault on r600g with HD6850.

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

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

--- Comment #2 from Tom Stellard  ---
For pyrit it looks like we aren't handling one of the intrinsics produced by
the AMDILPeephole optimizer, but can you still post the output with the
RADEON_DEBUG=cs env variable set.

Do you have a link to where can I download this program?

Also, what other programs didn't work for you?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

[Bug 64201] OpenCL usage result segmentation fault on r600g with HD6850.

[bugzilla-daemon]

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

--- Comment #3 from Tom Stellard tstel...@gmail.com ---
Created attachment 78831
  -- https://bugs.freedesktop.org/attachment.cgi?id=78831action=edit
Possible fix

This patch should fix the error you were seeing with pyrit.  However, it's
possible you will now see a different error.

-- 
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: [git pull] drm for 3.10-rc1

[Daniel Vetter]

On Sat, May 4, 2013 at 3:18 AM, Josh Boyer jwbo...@gmail.com wrote:
 On Fri, May 03, 2013 at 10:40:17PM +0200, Daniel Vetter wrote:
On Fri, May 3, 2013 at 10:31 PM, Josh Boyer jwbo...@gmail.com wrote:
 OK.  Git bisect tells me this:

 57c219633275c7e7413f8bc7be250dc092887458 is the first bad commit
 commit 57c219633275c7e7413f8bc7be250dc092887458
 Author: Daniel Vetter daniel.vet...@ffwll.ch
 Date:   Thu Apr 4 17:19:37 2013 +0200

 drm/i915: revert eDP bpp clamping code changes

Yeah, that commit is a bit dubios and for 3.11 we've already planned
to kick it out. It tries to work around an issue on a funky
pre-release hw. Does reverting this commit fix your issue?

 Yes, seems so.  I reverted it on top of Linus tree as of commit
 ce857229e0c3adc2 and things boot normally on the machine after that.

Thanks for confirming, I've reverted the patch and will foward my
current drm-intel-fixes tree soon to Dave.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 64201] OpenCL usage result segmentation fault on r600g with HD6850.

[bugzilla-daemon]

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

--- Comment #5 from Erdem U. Altinyurt spamjunkea...@gmail.com ---
Created attachment 78838
  -- https://bugs.freedesktop.org/attachment.cgi?id=78838action=edit
Pyrit Error log with Debug

-- 
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/4] drm/exynos: hdmi: move hdmi subsystem registration to drm common hdmi

[Sean Paul]

On Fri, May 3, 2013 at 2:04 AM, Rahul Sharma r.sh.o...@gmail.com wrote:
 On Mon, Apr 29, 2013 at 10:06 PM, Sean Paul seanp...@google.com wrote:
 On Mon, Apr 29, 2013 at 10:50 AM, Rahul Sharma rahul.sha...@samsung.com 
 wrote:
 Exynos hdmi sub-system consists of mixer, hdmi ip, hdmi-phy and hdmi-ddc
 components. Currently, drivers for these components are getting registered
 in exynos_drm_drv.c, which is meant for registration of drm sub-drivers.

 In this patch, registration of drm hdmi sub-driver and device, drivers for
 hdmi sub-system components are moved to exynos_drm_hdmi.c. This ensures
 limited  relevant exposure of hdmi-sub-system components to 
 exynos_drm_drv.c.
 It will also help in handling the hdmi-sub-system diversities within the
 exynos-common-hdmi.

 Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
 ---
  drivers/gpu/drm/exynos/exynos_drm_drv.c  |   25 ++--
  drivers/gpu/drm/exynos/exynos_drm_drv.h  |   14 -
  drivers/gpu/drm/exynos/exynos_drm_hdmi.c |   46 
 --
  drivers/gpu/drm/exynos/exynos_drm_hdmi.h |3 ++
  4 files changed, 49 insertions(+), 39 deletions(-)

 diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
 b/drivers/gpu/drm/exynos/exynos_drm_drv.c
 index ba6d995..4eabb6e 100644
 --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
 +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
 @@ -331,19 +331,9 @@ static int __init exynos_drm_init(void)
  #endif

  #ifdef CONFIG_DRM_EXYNOS_HDMI
 -   ret = platform_driver_register(hdmi_driver);
 +   ret = exynos_common_hdmi_register();
 if (ret  0)
 goto out_hdmi;
 -   ret = platform_driver_register(mixer_driver);
 -   if (ret  0)
 -   goto out_mixer;
 -   ret = platform_driver_register(exynos_drm_common_hdmi_driver);
 -   if (ret  0)
 -   goto out_common_hdmi;
 -
 -   ret = exynos_platform_device_hdmi_register();
 -   if (ret  0)
 -   goto out_common_hdmi_dev;
  #endif

  #ifdef CONFIG_DRM_EXYNOS_VIDI
 @@ -436,13 +426,7 @@ out_vidi:
  #endif

  #ifdef CONFIG_DRM_EXYNOS_HDMI
 -   exynos_platform_device_hdmi_unregister();
 -out_common_hdmi_dev:
 -   platform_driver_unregister(exynos_drm_common_hdmi_driver);
 -out_common_hdmi:
 -   platform_driver_unregister(mixer_driver);
 -out_mixer:
 -   platform_driver_unregister(hdmi_driver);
 +   exynos_common_hdmi_unregister();
  out_hdmi:
  #endif

 @@ -483,10 +467,7 @@ static void __exit exynos_drm_exit(void)
  #endif

  #ifdef CONFIG_DRM_EXYNOS_HDMI
 -   exynos_platform_device_hdmi_unregister();
 -   platform_driver_unregister(exynos_drm_common_hdmi_driver);
 -   platform_driver_unregister(mixer_driver);
 -   platform_driver_unregister(hdmi_driver);
 +   exynos_common_hdmi_unregister();
  #endif

  #ifdef CONFIG_DRM_EXYNOS_VIDI
 diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
 b/drivers/gpu/drm/exynos/exynos_drm_drv.h
 index eaa1966..34aa36d 100644
 --- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
 +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
 @@ -319,15 +319,16 @@ int exynos_drm_subdrv_open(struct drm_device *dev, 
 struct drm_file *file);
  void exynos_drm_subdrv_close(struct drm_device *dev, struct drm_file 
 *file);

  /*
 - * this function registers exynos drm hdmi platform device. It ensures 
 only one
 - * instance of the device is created.
 + * this function registers exynos drm hdmi platform driver and singleton
 + * device. It also registers subdrivers like mixer, hdmi and hdmiphy.
   */
 -int exynos_platform_device_hdmi_register(void);
 +int exynos_common_hdmi_register(void);

  /*
 - * this function unregisters exynos drm hdmi platform device if it exists.
 + * this function unregisters exynos drm hdmi platform driver and device,
 + * subdrivers for mixer, hdmi and hdmiphy.
   */
 -void exynos_platform_device_hdmi_unregister(void);
 +void exynos_common_hdmi_unregister(void);

  /*
   * this function registers exynos drm ipp platform device.
 @@ -340,9 +341,6 @@ int exynos_platform_device_ipp_register(void);
  void exynos_platform_device_ipp_unregister(void);

  extern struct platform_driver fimd_driver;
 -extern struct platform_driver hdmi_driver;
 -extern struct platform_driver mixer_driver;
 -extern struct platform_driver exynos_drm_common_hdmi_driver;
  extern struct platform_driver vidi_driver;
  extern struct platform_driver g2d_driver;
  extern struct platform_driver fimc_driver;
 diff --git a/drivers/gpu/drm/exynos/exynos_drm_hdmi.c 
 b/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
 index 060fbe8..7ab5f9f 100644
 --- a/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
 +++ b/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
 @@ -41,6 +41,8 @@ static struct exynos_drm_hdmi_context *mixer_ctx;
  static struct exynos_hdmi_ops *hdmi_ops;
  static struct exynos_mixer_ops *mixer_ops;

 +struct platform_driver exynos_drm_common_hdmi_driver;

 What's the point of even having this driver? It doesn't do anything.
 You call 

[PATCH 0/7] Clean up write-combining MTRR addition

[Andy Lutomirski]

A fair number of drivers (mostly graphics) add write-combining MTRRs.
Most ignore errors and most add the MTRR even on PAT systems which don't
need to use MTRRs.

This series adds new functions mtrr_{add,del}_wc_if_needed and
drm_mtrr_{add,del}_wc that report errors and do nothing if PAT is
enabled.

I've only tested the radeon driver, since I don't have test hardware
easily available for the other drivers.

Benefits include:
 - Simpler code
 - No more complaints about MTRR conflict warnings on PAT systems
 - Eventual unexporting of the MTRR API?

This series eliminates about half of the mtrr_add calls in drivers/.

The series is also at:
https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/log/?h=mtrr_cleanup

Andy Lutomirski (7):
  x86: Add mtrr_{add,del}_wc_if_needed
  drm (ast,cirrus,mgag200,nouveau,savage,vmwgfx): Rework
drm_mtrr_{add,del}
  drm: Update drm_addmap and drm_mmap to use PAT WC instead of MTRRs
  drm: Use drm_mtrr_add_wc for the AGP aperture
  i915: Use drm_mtrr_{add,del}_wc
  radeon: Switch to drm_mtrr_add_wc and add a missing drm_mtrr_del_wc
  uvesafb: Clean up MTRR code

 Documentation/fb/uvesafb.txt   | 16 +++-
 arch/x86/include/asm/mtrr.h| 21 ++
 arch/x86/kernel/cpu/mtrr/main.c| 53 +
 drivers/gpu/drm/ast/ast_ttm.c  | 14 ++-
 drivers/gpu/drm/cirrus/cirrus_ttm.c| 15 ++--
 drivers/gpu/drm/drm_bufs.c | 11 ++
 drivers/gpu/drm/drm_pci.c  |  8 ++--
 drivers/gpu/drm/drm_stub.c | 10 +
 drivers/gpu/drm/drm_vm.c   | 13 ---
 drivers/gpu/drm/i915/i915_dma.c| 43 +++--
 drivers/gpu/drm/mgag200/mgag200_ttm.c  | 14 ++-
 drivers/gpu/drm/nouveau/nouveau_ttm.c  | 13 ++-
 drivers/gpu/drm/radeon/radeon_object.c |  5 ++-
 drivers/gpu/drm/savage/savage_bci.c| 42 
 drivers/gpu/drm/savage/savage_drv.h|  5 +--
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c| 10 ++---
 drivers/video/uvesafb.c| 70 +-
 include/drm/drmP.h | 23 +--
 include/video/uvesafb.h|  1 +
 19 files changed, 169 insertions(+), 218 deletions(-)

-- 
1.8.1.4

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

[PATCH 1/7] x86: Add mtrr_{add,del}_wc_if_needed

[Andy Lutomirski]

These MTRR helpers add a WC MTRR if PAT is disabled.  Modern drivers should
be using ioremap_wc, etc. to get WC memory; the MTRR is just a fallback
if the system doesn't have PAT.  So, rather than allocating an unnecessary
MTRR even on PAT systems and having error handling spread out and handled
differently by different drivers, consolidate it all and don't waste the
MTRR on PAT-supporting systems.  (Follow-up changes will update drivers.)

This should be a simple change, a bit of a clean-up, and it will flush
out any drivers that actually depend on the MTRR for write combining.

Signed-off-by: Andy Lutomirski l...@amacapital.net
---
 arch/x86/include/asm/mtrr.h | 21 
 arch/x86/kernel/cpu/mtrr/main.c | 53 +
 2 files changed, 74 insertions(+)

diff --git a/arch/x86/include/asm/mtrr.h b/arch/x86/include/asm/mtrr.h
index e235582..cc96c72 100644
--- a/arch/x86/include/asm/mtrr.h
+++ b/arch/x86/include/asm/mtrr.h
@@ -45,6 +45,18 @@ extern void mtrr_aps_init(void);
 extern void mtrr_bp_restore(void);
 extern int mtrr_trim_uncached_memory(unsigned long end_pfn);
 extern int amd_special_default_mtrr(void);
+
+/*
+ * These are for drivers (mostly video) that want to add WC MTRRs as a
+ * fallback if PAT is unavailable.  There is no need to check for errors.
+ *
+ * The handles used by the _if_needed functions are *not* MTRR indices.
+ * mtrr_del_wc_if_needed(0) and mtrr_del_wc_if_needed(-1) are
+ * guaranteed to have no effect.
+ */
+extern int __must_check mtrr_add_wc_if_needed(unsigned long base,
+ unsigned long size);
+extern void mtrr_del_wc_if_needed(int handle);
 #  else
 static inline u8 mtrr_type_lookup(u64 addr, u64 end)
 {
@@ -86,6 +98,15 @@ static inline void mtrr_centaur_report_mcr(int mcr, u32 lo, 
u32 hi)
 #define set_mtrr_aps_delayed_init() do {} while (0)
 #define mtrr_aps_init() do {} while (0)
 #define mtrr_bp_restore() do {} while (0)
+
+static inline int __must_check mtrr_add_wc_if_needed(unsigned long base,
+unsigned long size)
+{
+   return -ENODEV;
+}
+static inline void mtrr_del_wc_if_needed(int handle)
+{
+}
 #  endif
 
 #ifdef CONFIG_COMPAT
diff --git a/arch/x86/kernel/cpu/mtrr/main.c b/arch/x86/kernel/cpu/mtrr/main.c
index 726bf96..6370238 100644
--- a/arch/x86/kernel/cpu/mtrr/main.c
+++ b/arch/x86/kernel/cpu/mtrr/main.c
@@ -51,6 +51,7 @@
 #include asm/e820.h
 #include asm/mtrr.h
 #include asm/msr.h
+#include asm/pat.h
 
 #include mtrr.h
 
@@ -524,6 +525,58 @@ int mtrr_del(int reg, unsigned long base, unsigned long 
size)
 }
 EXPORT_SYMBOL(mtrr_del);
 
+/**
+ * mtrr_add_wc_if_needed - add a WC MTRR and handle errors if PAT is 
unavailable
+ * @base: Physical base address
+ * @size: Size of region
+ *
+ * If PAT is available, this does nothing.  If PAT is unavailable, it
+ * attempts to add a WC MTRR covering size bytes starting at base and
+ * logs an error if this fails.
+ *
+ * Drivers must store the return value to pass to mtrr_del_wc_if_needed,
+ * but drivers should not try to interpret that return value.
+ */
+int mtrr_add_wc_if_needed(unsigned long base, unsigned long size)
+{
+   int ret;
+
+   if (pat_enabled) {
+   /*
+* Don't bother -- we don't need the MTRR.  Return an error
+* so that no one gets confused.
+*/
+   return -EBUSY;  /* The error doesn't matter. */
+   }
+
+   ret = mtrr_add(base, size, MTRR_TYPE_WRCOMB, true);
+   if (ret  0) {
+ pr_warn(Failed to add WC MTRR for [%p-%p]; performance will suffer.,
+ (void *)base, (void *)(base + size - 1));
+   return ret;
+   }
+   return ret + 1000;
+}
+EXPORT_SYMBOL(mtrr_add_wc_if_needed);
+
+/*
+ * mtrr_del_wc_if_needed - undoes mtrr_add_wc_if_needed
+ * @handle: Return value from mtrr_add_wc_if_needed
+ *
+ * This cleans up after mtrr_add_wc_if_needed.
+ *
+ * The API guarantees that mtrr_del_wc_if_needed(-1) and
+ * mtrr_del_wc_if_needed(0) do nothing.
+ */
+extern void mtrr_del_wc_if_needed(int handle)
+{
+   if (handle = 1) {
+   WARN_ON(handle  1000);
+   mtrr_del(handle - 1000, 0, 0);
+   }
+}
+EXPORT_SYMBOL(mtrr_del_wc_if_needed);
+
 /*
  * HACK ALERT!
  * These should be called implicitly, but we can't yet until all the initcall
-- 
1.8.1.4

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

Re: [git pull] drm for 3.10-rc1

[Josh Boyer]

On Fri, May 03, 2013 at 06:08:52PM +0200, Daniel Vetter wrote:
On Fri, May 3, 2013 at 4:39 PM, Josh Boyer jwbo...@gmail.com wrote:
 On Fri, May 03, 2013 at 02:25:57AM +0100, Dave Airlie wrote:
The following changes since commit b6a9b7f6b1f21735a7456d534dc0e68e61359d2c:

  mm: prevent mmap_cache race in find_vma() (2013-04-04 11:46:28 -0700)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux.git drm-next

for you to fetch changes up to 307b9c022720f9de90d58e51743e01e9a42aec59:

  qxl: update to new idr interfaces. (2013-05-03 10:37:20 +1000)



 So something in this batch of commits breaks a Macbook Pro Retina I have
 sitting here.  If I boot a Fedora kernel based on  Linux
 v3.9-8153-g5a148af, things boot up as they did previously with 3.9.0 and
 are generally working fine.  If I boot with a kernel based on Linux
 v3.9-8933-gce85722, it will boot but as soon as plymouth starts, I get
 nothing but static on the screen (like 1950s TV static).

 This machine is using i915 graphics, so I booted with nomodeset and did
 the 'modprobe drm debug=15; modprobe i915 modeset=1' trick and it
 repeated the failure with that.  I've gathered a bunch of data like
 dmesg, an intel_reg_snapshot, etc.  It's all attached below.

 I'll start bisecting to see if I can narrow down the commit that broke
 things, but I thought I would give a heads up now in case anyone has any
 ideas.

Looked through the log files and didn't see a clue. And usually DP
tends to fail pretty noisily. So I think the bisect result would be
interestin. Meanwhile:

Yeah, working on that.

- do you have drm.debug=0xe dmesg for a working kernel, too?

No, but I can try and get one.

- is the panel completely dead or is just the backlight on (or panel
on but backlight off)?

Backlight is on.  Literally static flickering on the screen.
Occasionally it will flicker from static to black back and forth.  But
the backlight is clearly on and what is trying to render (the GDM screen
normally) is just coming up as static.

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

[PATCH 2/7] drm (ast, cirrus, mgag200, nouveau, savage, vmwgfx): Rework drm_mtrr_{add, del}

[Andy Lutomirski]

This replaces drm_mtrr_{add,del} with drm_mtrr_{add,del}_wc.  The
interface is simplified (because the base and size parameters to
drm_mtrr_del never did anything) and it uses
mtrr_{add,del}_wc_if_needed to avoid allocating MTRRs on systems
that don't need them.

Signed-off-by: Andy Lutomirski l...@amacapital.net
---
 drivers/gpu/drm/ast/ast_ttm.c | 14 
 drivers/gpu/drm/cirrus/cirrus_ttm.c   | 15 -
 drivers/gpu/drm/mgag200/mgag200_ttm.c | 14 
 drivers/gpu/drm/nouveau/nouveau_ttm.c | 13 ---
 drivers/gpu/drm/savage/savage_bci.c   | 42 +--
 drivers/gpu/drm/savage/savage_drv.h   |  5 +
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c   | 10 -
 include/drm/drmP.h| 23 ---
 8 files changed, 45 insertions(+), 91 deletions(-)

diff --git a/drivers/gpu/drm/ast/ast_ttm.c b/drivers/gpu/drm/ast/ast_ttm.c
index 3602731..5286c96 100644
--- a/drivers/gpu/drm/ast/ast_ttm.c
+++ b/drivers/gpu/drm/ast/ast_ttm.c
@@ -271,26 +271,20 @@ int ast_mm_init(struct ast_private *ast)
return ret;
}
 
-   ast-fb_mtrr = drm_mtrr_add(pci_resource_start(dev-pdev, 0),
-   pci_resource_len(dev-pdev, 0),
-   DRM_MTRR_WC);
+   ast-fb_mtrr = drm_mtrr_add_wc(pci_resource_start(dev-pdev, 0),
+  pci_resource_len(dev-pdev, 0));
 
return 0;
 }
 
 void ast_mm_fini(struct ast_private *ast)
 {
-   struct drm_device *dev = ast-dev;
ttm_bo_device_release(ast-ttm.bdev);
 
ast_ttm_global_release(ast);
 
-   if (ast-fb_mtrr = 0) {
-   drm_mtrr_del(ast-fb_mtrr,
-pci_resource_start(dev-pdev, 0),
-pci_resource_len(dev-pdev, 0), DRM_MTRR_WC);
-   ast-fb_mtrr = -1;
-   }
+   drm_mtrr_del_wc(ast-fb_mtrr);
+   ast-fb_mtrr = -1;
 }
 
 void ast_ttm_placement(struct ast_bo *bo, int domain)
diff --git a/drivers/gpu/drm/cirrus/cirrus_ttm.c 
b/drivers/gpu/drm/cirrus/cirrus_ttm.c
index 1413a26..95e87ee 100644
--- a/drivers/gpu/drm/cirrus/cirrus_ttm.c
+++ b/drivers/gpu/drm/cirrus/cirrus_ttm.c
@@ -271,9 +271,8 @@ int cirrus_mm_init(struct cirrus_device *cirrus)
return ret;
}
 
-   cirrus-fb_mtrr = drm_mtrr_add(pci_resource_start(dev-pdev, 0),
-   pci_resource_len(dev-pdev, 0),
-   DRM_MTRR_WC);
+   cirrus-fb_mtrr = drm_mtrr_add_wc(pci_resource_start(dev-pdev, 0),
+ pci_resource_len(dev-pdev, 0));
 
cirrus-mm_inited = true;
return 0;
@@ -281,8 +280,6 @@ int cirrus_mm_init(struct cirrus_device *cirrus)
 
 void cirrus_mm_fini(struct cirrus_device *cirrus)
 {
-   struct drm_device *dev = cirrus-dev;
-
if (!cirrus-mm_inited)
return;
 
@@ -290,12 +287,8 @@ void cirrus_mm_fini(struct cirrus_device *cirrus)
 
cirrus_ttm_global_release(cirrus);
 
-   if (cirrus-fb_mtrr = 0) {
-   drm_mtrr_del(cirrus-fb_mtrr,
-pci_resource_start(dev-pdev, 0),
-pci_resource_len(dev-pdev, 0), DRM_MTRR_WC);
-   cirrus-fb_mtrr = -1;
-   }
+   drm_mtrr_del_wc(cirrus-fb_mtrr);
+   cirrus-fb_mtrr = -1;
 }
 
 void cirrus_ttm_placement(struct cirrus_bo *bo, int domain)
diff --git a/drivers/gpu/drm/mgag200/mgag200_ttm.c 
b/drivers/gpu/drm/mgag200/mgag200_ttm.c
index 8fc9d92..62245b4 100644
--- a/drivers/gpu/drm/mgag200/mgag200_ttm.c
+++ b/drivers/gpu/drm/mgag200/mgag200_ttm.c
@@ -270,26 +270,20 @@ int mgag200_mm_init(struct mga_device *mdev)
return ret;
}
 
-   mdev-fb_mtrr = drm_mtrr_add(pci_resource_start(dev-pdev, 0),
-   pci_resource_len(dev-pdev, 0),
-   DRM_MTRR_WC);
+   mdev-fb_mtrr = drm_mtrr_add_wc(pci_resource_start(dev-pdev, 0),
+   pci_resource_len(dev-pdev, 0));
 
return 0;
 }
 
 void mgag200_mm_fini(struct mga_device *mdev)
 {
-   struct drm_device *dev = mdev-dev;
ttm_bo_device_release(mdev-ttm.bdev);
 
mgag200_ttm_global_release(mdev);
 
-   if (mdev-fb_mtrr = 0) {
-   drm_mtrr_del(mdev-fb_mtrr,
-pci_resource_start(dev-pdev, 0),
-pci_resource_len(dev-pdev, 0), DRM_MTRR_WC);
-   mdev-fb_mtrr = -1;
-   }
+   drm_mtrr_del_wc(mdev-fb_mtrr);
+   mdev-fb_mtrr = -1;
 }
 
 void mgag200_ttm_placement(struct mgag200_bo *bo, int domain)
diff --git a/drivers/gpu/drm/nouveau/nouveau_ttm.c 
b/drivers/gpu/drm/nouveau/nouveau_ttm.c
index 9be9cb5..1506d78 100644
--- a/drivers/gpu/drm/nouveau/nouveau_ttm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_ttm.c
@@ -377,9 +377,8 @@ nouveau_ttm_init(struct nouveau_drm *drm)

[PATCH 3/7] drm: Update drm_addmap and drm_mmap to use PAT WC instead of MTRRs

[Andy Lutomirski]

Signed-off-by: Andy Lutomirski l...@amacapital.net
---

This needs careful review.  I don't really know what this code does, nor
do I have the hardware.  (I don't understand AGP and the associated
caching implications.)

 drivers/gpu/drm/drm_bufs.c | 11 ---
 drivers/gpu/drm/drm_vm.c   | 13 +++--
 2 files changed, 11 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/drm_bufs.c b/drivers/gpu/drm/drm_bufs.c
index 0128147..0ae9cbb 100644
--- a/drivers/gpu/drm/drm_bufs.c
+++ b/drivers/gpu/drm/drm_bufs.c
@@ -210,8 +210,8 @@ static int drm_addmap_core(struct drm_device * dev, 
resource_size_t offset,
if (drm_core_has_MTRR(dev)) {
if (map-type == _DRM_FRAME_BUFFER ||
(map-flags  _DRM_WRITE_COMBINING)) {
-   map-mtrr = mtrr_add(map-offset, map-size,
-MTRR_TYPE_WRCOMB, 1);
+   map-mtrr =
+   drm_mtrr_add_wc(map-offset, map-size);
}
}
if (map-type == _DRM_REGISTERS) {
@@ -451,11 +451,8 @@ int drm_rmmap_locked(struct drm_device *dev, struct 
drm_local_map *map)
iounmap(map-handle);
/* FALLTHROUGH */
case _DRM_FRAME_BUFFER:
-   if (drm_core_has_MTRR(dev)  map-mtrr = 0) {
-   int retcode;
-   retcode = mtrr_del(map-mtrr, map-offset, map-size);
-   DRM_DEBUG(mtrr_del=%d\n, retcode);
-   }
+   if (drm_core_has_MTRR(dev))
+   drm_mtrr_del_wc(map-mtrr);
break;
case _DRM_SHM:
vfree(map-handle);
diff --git a/drivers/gpu/drm/drm_vm.c b/drivers/gpu/drm/drm_vm.c
index db7bd29..b255fd7 100644
--- a/drivers/gpu/drm/drm_vm.c
+++ b/drivers/gpu/drm/drm_vm.c
@@ -43,15 +43,16 @@
 static void drm_vm_open(struct vm_area_struct *vma);
 static void drm_vm_close(struct vm_area_struct *vma);
 
-static pgprot_t drm_io_prot(uint32_t map_type, struct vm_area_struct *vma)
+static pgprot_t drm_io_prot(struct drm_local_map *map,
+   struct vm_area_struct *vma)
 {
pgprot_t tmp = vm_get_page_prot(vma-vm_flags);
 
 #if defined(__i386__) || defined(__x86_64__)
-   if (boot_cpu_data.x86  3  map_type != _DRM_AGP) {
-   pgprot_val(tmp) |= _PAGE_PCD;
-   pgprot_val(tmp) = ~_PAGE_PWT;
-   }
+   if (map-flags  _DRM_WRITE_COMBINING)
+   tmp = pgprot_writecombine(tmp);
+   else if (map-type != _DRM_AGP)
+   tmp = pgprot_noncached(tmp);
 #elif defined(__powerpc__)
pgprot_val(tmp) |= _PAGE_NO_CACHE;
if (map_type == _DRM_REGISTERS)
@@ -617,7 +618,7 @@ int drm_mmap_locked(struct file *filp, struct 
vm_area_struct *vma)
case _DRM_REGISTERS:
offset = drm_core_get_reg_ofs(dev);
vma-vm_flags |= VM_IO; /* not in core dump */
-   vma-vm_page_prot = drm_io_prot(map-type, vma);
+   vma-vm_page_prot = drm_io_prot(map, vma);
if (io_remap_pfn_range(vma, vma-vm_start,
   (map-offset + offset)  PAGE_SHIFT,
   vma-vm_end - vma-vm_start,
-- 
1.8.1.4

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

[PATCH 5/7] i915: Use drm_mtrr_{add,del}_wc

[Andy Lutomirski]

i915 open-coded logic that was essentially equivalent to the new
drm_mtrr_{add,del}_wc.

Signed-off-by: Andy Lutomirski l...@amacapital.net
---
 drivers/gpu/drm/i915/i915_dma.c | 43 ++---
 1 file changed, 6 insertions(+), 37 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 4fa6beb..0fc95ba 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1393,29 +1393,6 @@ void i915_master_destroy(struct drm_device *dev, struct 
drm_master *master)
master-driver_priv = NULL;
 }
 
-static void
-i915_mtrr_setup(struct drm_i915_private *dev_priv, unsigned long base,
-   unsigned long size)
-{
-   dev_priv-mm.gtt_mtrr = -1;
-
-#if defined(CONFIG_X86_PAT)
-   if (cpu_has_pat)
-   return;
-#endif
-
-   /* Set up a WC MTRR for non-PAT systems.  This is more common than
-* one would think, because the kernel disables PAT on first
-* generation Core chips because WC PAT gets overridden by a UC
-* MTRR if present.  Even if a UC MTRR isn't present.
-*/
-   dev_priv-mm.gtt_mtrr = mtrr_add(base, size, MTRR_TYPE_WRCOMB, 1);
-   if (dev_priv-mm.gtt_mtrr  0) {
-   DRM_INFO(MTRR allocation failed.  Graphics 
-performance may suffer.\n);
-   }
-}
-
 static void i915_kick_out_firmware_fb(struct drm_i915_private *dev_priv)
 {
struct apertures_struct *ap;
@@ -1552,8 +1529,8 @@ int i915_driver_load(struct drm_device *dev, unsigned 
long flags)
goto out_rmmap;
}
 
-   i915_mtrr_setup(dev_priv, dev_priv-gtt.mappable_base,
-   aperture_size);
+   dev_priv-mm.gtt_mtrr = drm_mtrr_add_wc(dev_priv-gtt.mappable_base,
+   aperture_size);
 
/* The i915 workqueue is primarily used for batched retirement of
 * requests (and thus managing bo) once the task has been completed
@@ -1656,12 +1633,8 @@ out_gem_unload:
intel_teardown_mchbar(dev);
destroy_workqueue(dev_priv-wq);
 out_mtrrfree:
-   if (dev_priv-mm.gtt_mtrr = 0) {
-   mtrr_del(dev_priv-mm.gtt_mtrr,
-dev_priv-gtt.mappable_base,
-aperture_size);
-   dev_priv-mm.gtt_mtrr = -1;
-   }
+   drm_mtrr_del_wc(dev_priv-mm.gtt_mtrr);
+   dev_priv-mm.gtt_mtrr = -1;
io_mapping_free(dev_priv-gtt.mappable);
 out_rmmap:
pci_iounmap(dev-pdev, dev_priv-regs);
@@ -1697,12 +1670,8 @@ int i915_driver_unload(struct drm_device *dev)
cancel_delayed_work_sync(dev_priv-mm.retire_work);
 
io_mapping_free(dev_priv-gtt.mappable);
-   if (dev_priv-mm.gtt_mtrr = 0) {
-   mtrr_del(dev_priv-mm.gtt_mtrr,
-dev_priv-gtt.mappable_base,
-dev_priv-gtt.mappable_end);
-   dev_priv-mm.gtt_mtrr = -1;
-   }
+   drm_mtrr_del_wc(dev_priv-mm.gtt_mtrr);
+   dev_priv-mm.gtt_mtrr = -1;
 
acpi_video_unregister();
 
-- 
1.8.1.4

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

[PATCH 7/7] uvesafb: Clean up MTRR code

[Andy Lutomirski]

The old code allowed very strange memory types.  Now it works like
all the other video drivers: ioremap_wc is used unconditionally,
and MTRRs are set if PAT is unavailable (unless MTRR is disabled
by a module parameter).

UC, WB, and WT support is gone.  If there are MTRR conflicts that prevent
addition of a WC MTRR, adding a non-conflicting MTRR is pointless; it's
better to just turn off MTRR support entirely.

As an added bonus, any MTRR added is freed on unload.

Signed-off-by: Andy Lutomirski l...@amacapital.net
---

I can't test this -- the link to v86d in Documentation/fb/uvesafb.txt
seems to be broken, and Fedora doesn't seem to package it.

 Documentation/fb/uvesafb.txt | 16 --
 drivers/video/uvesafb.c  | 70 
 include/video/uvesafb.h  |  1 +
 3 files changed, 24 insertions(+), 63 deletions(-)

diff --git a/Documentation/fb/uvesafb.txt b/Documentation/fb/uvesafb.txt
index eefdd91..f6362d8 100644
--- a/Documentation/fb/uvesafb.txt
+++ b/Documentation/fb/uvesafb.txt
@@ -81,17 +81,11 @@ pmipal  Use the protected mode interface for palette 
changes.
 
 mtrr:n  Setup memory type range registers for the framebuffer
 where n:
-  0 - disabled (equivalent to nomtrr) (default)
-  1 - uncachable
-  2 - write-back
-  3 - write-combining
-  4 - write-through
-
-If you see the following in dmesg, choose the type that matches
-the old one.  In this example, use mtrr:2.
-...
-mtrr: type mismatch for e000,800 old: write-back new: write-combining
-...
+  0 - disabled (equivalent to nomtrr)
+  3 - write-combining (default)
+
+   Values other than 0 and 3 will result in a warning and will be
+   treated just like 3.
 
 nomtrr  Do not use memory type range registers.
 
diff --git a/drivers/video/uvesafb.c b/drivers/video/uvesafb.c
index d428445..4f447ad 100644
--- a/drivers/video/uvesafb.c
+++ b/drivers/video/uvesafb.c
@@ -24,9 +24,7 @@
 #ifdef CONFIG_X86
 #include video/vga.h
 #endif
-#ifdef CONFIG_MTRR
 #include asm/mtrr.h
-#endif
 #include edid.h
 
 static struct cb_id uvesafb_cn_id = {
@@ -1540,67 +1538,31 @@ static void uvesafb_init_info(struct fb_info *info, 
struct vbe_mode_ib *mode)
 
 static void uvesafb_init_mtrr(struct fb_info *info)
 {
-#ifdef CONFIG_MTRR
+   struct uvesafb_par *par = info-par;
+
if (mtrr  !(info-fix.smem_start  (PAGE_SIZE - 1))) {
int temp_size = info-fix.smem_len;
-   unsigned int type = 0;
 
-   switch (mtrr) {
-   case 1:
-   type = MTRR_TYPE_UNCACHABLE;
-   break;
-   case 2:
-   type = MTRR_TYPE_WRBACK;
-   break;
-   case 3:
-   type = MTRR_TYPE_WRCOMB;
-   break;
-   case 4:
-   type = MTRR_TYPE_WRTHROUGH;
-   break;
-   default:
-   type = 0;
-   break;
-   }
+   int rc;
 
-   if (type) {
-   int rc;
+   /* Find the largest power-of-two */
+   temp_size = roundup_pow_of_two(temp_size);
 
-   /* Find the largest power-of-two */
-   temp_size = roundup_pow_of_two(temp_size);
+   /* Try and find a power of two to add */
+   do {
+   rc = mtrr_add_wc_if_needed(info-fix.smem_start,
+  temp_size);
+   temp_size = 1;
+   } while (temp_size = PAGE_SIZE  rc == -EINVAL);
 
-   /* Try and find a power of two to add */
-   do {
-   rc = mtrr_add(info-fix.smem_start,
- temp_size, type, 1);
-   temp_size = 1;
-   } while (temp_size = PAGE_SIZE  rc == -EINVAL);
-   }
+   if (rc = 0)
+   par-mtrr_handle = rc;
}
-#endif /* CONFIG_MTRR */
 }
 
 static void uvesafb_ioremap(struct fb_info *info)
 {
-#ifdef CONFIG_X86
-   switch (mtrr) {
-   case 1: /* uncachable */
-   info-screen_base = ioremap_nocache(info-fix.smem_start, 
info-fix.smem_len);
-   break;
-   case 2: /* write-back */
-   info-screen_base = ioremap_cache(info-fix.smem_start, 
info-fix.smem_len);
-   break;
-   case 3: /* write-combining */
-   info-screen_base = ioremap_wc(info-fix.smem_start, 
info-fix.smem_len);
-   break;
-   case 4: /* write-through */
-   default:
-   info-screen_base = ioremap(info-fix.smem_start, 
info-fix.smem_len);
-   break;
-   }
-#else
-   

Re: [git pull] drm for 3.10-rc1

[Josh Boyer]

On Fri, May 03, 2013 at 10:40:17PM +0200, Daniel Vetter wrote:
On Fri, May 3, 2013 at 10:31 PM, Josh Boyer jwbo...@gmail.com wrote:
 OK.  Git bisect tells me this:

 57c219633275c7e7413f8bc7be250dc092887458 is the first bad commit
 commit 57c219633275c7e7413f8bc7be250dc092887458
 Author: Daniel Vetter daniel.vet...@ffwll.ch
 Date:   Thu Apr 4 17:19:37 2013 +0200

 drm/i915: revert eDP bpp clamping code changes

Yeah, that commit is a bit dubios and for 3.11 we've already planned
to kick it out. It tries to work around an issue on a funky
pre-release hw. Does reverting this commit fix your issue?

Yes, seems so.  I reverted it on top of Linus tree as of commit
ce857229e0c3adc2 and things boot normally on the machine after that.

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

Re: [Intel-gfx] [PATCH] [TRIVIAL] Fix declaration of intel_gmbus_{is_forced_bit/is_port_falid} in i915 driver.

[PaX Team]

On 3 May 2013 at 15:03, Jani Nikula wrote:

  This fixes a compilation issue with clang. An initial version of this patch
  was developed by PaX Team pageexec at freemail.hu.
  This is respin of this patch.
  
  Signed-off-by: Jan-Simon Möller dl...@gmx.de
  CC: pagee...@freemail.hu
  CC: daniel.vet...@ffwll.ch
  CC: airl...@linux.ie
  CC: intel-...@lists.freedesktop.org
  CC: dri-devel@lists.freedesktop.org
  CC: linux-ker...@vger.kernel.org
  Picked up for -fixes, thanks for the patch.
 
 Please drop it.
 
 The patch removes the inline keyword, creating dozens of copies of the
 functions, and consequently loads of warnings:

in my original patch they were both static inline, not sure where the
inline got lost...

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

[Bug 64193] LLVM RV670 regression since R600: Packetize instructions

[bugzilla-daemon]

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

--- Comment #4 from vincent v...@ovi.com ---
Can you cherry pick this patch :
https://bugs.freedesktop.org/attachment.cgi?id=78786 (from bugid 64096) on top
of 25f259cde28860ea76c2f5628010968945a28edb and post the output of
R600_DEBUG=vs,ps,fs again please ?

-- 
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 2/7] drm (ast, cirrus, mgag200, nouveau, savage, vmwgfx): Rework drm_mtrr_{add, del}

[Daniel Vetter]

On Fri, May 03, 2013 at 04:00:30PM -0700, Andy Lutomirski wrote:
 This replaces drm_mtrr_{add,del} with drm_mtrr_{add,del}_wc.  The
 interface is simplified (because the base and size parameters to
 drm_mtrr_del never did anything) and it uses
 mtrr_{add,del}_wc_if_needed to avoid allocating MTRRs on systems
 that don't need them.
 
 Signed-off-by: Andy Lutomirski l...@amacapital.net
 ---

[snip]

 diff --git a/include/drm/drmP.h b/include/drm/drmP.h
 index 2d94d74..2a3e1fd 100644
 --- a/include/drm/drmP.h
 +++ b/include/drm/drmP.h
 @@ -1250,18 +1250,15 @@ static inline int drm_core_has_MTRR(struct drm_device 
 *dev)
   return drm_core_check_feature(dev, DRIVER_USE_MTRR);
  }
  
 -#define DRM_MTRR_WC  MTRR_TYPE_WRCOMB
 -
 -static inline int drm_mtrr_add(unsigned long offset, unsigned long size,
 -unsigned int flags)
 +static inline int __must_check drm_mtrr_add_wc(unsigned long offset,
 +unsigned long size)
  {
 - return mtrr_add(offset, size, flags, 1);
 + return mtrr_add_wc_if_needed(offset, size);
  }
  
 -static inline int drm_mtrr_del(int handle, unsigned long offset,
 -unsigned long size, unsigned int flags)
 +static inline void drm_mtrr_del_wc(int handle)
  {
 - return mtrr_del(handle, offset, size);
 + mtrr_del_wc_if_needed(handle);
  }
  
  #else
 @@ -1269,16 +1266,14 @@ static inline int drm_mtrr_del(int handle, unsigned 
 long offset,
  
  #define DRM_MTRR_WC  0
  
 -static inline int drm_mtrr_add(unsigned long offset, unsigned long size,
 -unsigned int flags)
 +static inline int __must_check drm_mtrr_add_wc(unsigned long offset,
 +unsigned long size)
  {
 - return 0;
 + return -1;
  }
  
 -static inline int drm_mtrr_del(int handle, unsigned long offset,
 -unsigned long size, unsigned int flags)
 +static inline void drm_mtrr_del_wc(int handle)
  {
 - return 0;
  }

Tbh I'm not a big fan of the drm_ indirection. Historically that was
useful as an OS abstraction layer so that the same drivers could be used
unchanged on Linux and the *BSD. But those days are long gone and drm
drivers are now proper Linux drivers, and generally OS HALs seem to be
frowned upon.

Is there another reason than just being consistent with the historic stuff
here? If we need dummy functions for !CONFIG_MTRR I think those should
simply be in the core.

And if the inconsistency bugs you I'd volunteer myself to ditch the old
drm_ mtrr helpers.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 63730] UVD broken on HD5470 by drm/radeon: raise UVD clocks only on demand

[bugzilla-daemon]

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

Parag parag.warud...@gmail.com changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #18 from Parag parag.warud...@gmail.com ---
I am getting the same error on HD6750M - I verified the kernel (Linus git from
today) I am running has the raise clocks patch. I've also replaced everything
in /lib/firmware/radeon from
http://people.freedesktop.org/~agd5f/radeon_ucode/. 

lspci | grep -i radeon
--
01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI
Whistler [Radeon HD 6600M/6700M/7600M Series]
01:00.1 Audio device: Advanced Micro Devices [AMD] nee ATI Turks/Whistler HDMI
Audio [Radeon HD 6000 Series]

dmesg
-
dmesg |grep -i uvd
[   17.676387] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset
the VCPU!!!
[   18.697587] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset
the VCPU!!!
[   19.718765] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset
the VCPU!!!
[   20.739957] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset
the VCPU!!!
[   21.761139] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset
the VCPU!!!
[   22.782347] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset
the VCPU!!!
[   23.803569] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset
the VCPU!!!
[   24.824728] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset
the VCPU!!!
[   25.845904] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset
the VCPU!!!
[   26.867070] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset
the VCPU!!!
[   26.887096] [drm:r600_uvd_init] *ERROR* UVD not responding, giving up!!!
[   26.887102] [drm:evergreen_startup] *ERROR* radeon: error initializing UVD
(-1).

-- 
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 63730] UVD broken on HD5470 by drm/radeon: raise UVD clocks only on demand

[bugzilla-daemon]

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

Parag parag.warud...@gmail.com changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #19 from Parag parag.warud...@gmail.com ---
Ugh, wrong status and wrong bug looks like. I will leave this closed and
comment on 63935 which seems more appropriate. Sorry about the noise.

-- 
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 63935] TURKS [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset the VCPU!!!

[bugzilla-daemon]

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

--- Comment #7 from Parag parag.warud...@gmail.com ---
I am getting the same error on HD6750M - I verified the kernel (Linus git from
today) I am running has the raise clocks patch. I've also replaced everything
in /lib/firmware/radeon from
http://people.freedesktop.org/~agd5f/radeon_ucode/. 

lspci | grep -i radeon
--
01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI
Whistler [Radeon HD 6600M/6700M/7600M Series]
01:00.1 Audio device: Advanced Micro Devices [AMD] nee ATI Turks/Whistler HDMI
Audio [Radeon HD 6000 Series]

dmesg
-
dmesg |grep -i uvd
[   17.676387] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset
the VCPU!!!
[   18.697587] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset
the VCPU!!!
[   19.718765] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset
the VCPU!!!
[   20.739957] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset
the VCPU!!!
[   21.761139] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset
the VCPU!!!
[   22.782347] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset
the VCPU!!!
[   23.803569] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset
the VCPU!!!
[   24.824728] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset
the VCPU!!!
[   25.845904] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset
the VCPU!!!
[   26.867070] [drm:r600_uvd_init] *ERROR* UVD not responding, trying to reset
the VCPU!!!
[   26.887096] [drm:r600_uvd_init] *ERROR* UVD not responding, giving up!!!
[   26.887102] [drm:evergreen_startup] *ERROR* radeon: error initializing UVD
(-1).

-- 
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

[PULL] drm-intel-fixes

[Daniel Vetter]

Hi Dave,

A few intel fixes for smaller issues and one revert for an sdv hack which
we've wanted to kill anyway. Plus two drm patches included for your
convenience, both regression fixers for mine own screw-ups.

Cheers, Daniel

The following changes since commit 43b27290dd42b40f3f23f49677a7faa5a4eb1eff:

  drm/i915: correct the calculation of first_pd_entry_in_global_pt (2013-04-27 
14:07:16 +0200)

are available in the git repository at:

  git://people.freedesktop.org/~danvet/drm-intel drm-intel-fixes

for you to fetch changes up to 3ab9c63705cb7b1b9f83ddce725d8bd9ef7c66a9:

  drm/i915: hsw: fix link training for eDP on port-A (2013-05-04 10:24:56 +0200)


Chris Wilson (1):
  drm/i915: Always normalize return timeout for wait_timeout_ioctl

Daniel Vetter (3):
  drm/mm: fix dump table BUG
  drm: don't check modeset locks in panic handler
  Revert drm/i915: revert eDP bpp clamping code changes

Imre Deak (1):
  drm/i915: hsw: fix link training for eDP on port-A

Ville Syrjälä (1):
  drm/i915: Fix pipe enabled mask for pipe C in WM calculations

 drivers/gpu/drm/drm_crtc.c   |4 ++
 drivers/gpu/drm/drm_mm.c |   34 +
 drivers/gpu/drm/i915/i915_gem.c  |8 ++--
 drivers/gpu/drm/i915/intel_ddi.c |5 +++
 drivers/gpu/drm/i915/intel_dp.c  |   77 --
 drivers/gpu/drm/i915/intel_drv.h |1 +
 drivers/gpu/drm/i915/intel_pm.c  |   44 +++---
 7 files changed, 101 insertions(+), 72 deletions(-)
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 64193] LLVM RV670 regression since R600: Packetize instructions

[bugzilla-daemon]

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

--- Comment #5 from Andy Furniss adf.li...@gmail.com ---
(In reply to comment #4)
 Can you cherry pick this patch :
 https://bugs.freedesktop.org/attachment.cgi?id=78786 (from bugid 64096) on
 top of 25f259cde28860ea76c2f5628010968945a28edb and post the output of
 R600_DEBUG=vs,ps,fs again please ?

glxgears looks normal with the patch, though it doesn't fix other demos/games
eg.
nexuiz just hung and gloss renders almost OK but the sides are matt with no
reflection.

I'll attach the debug as requested and one from heads I did this morning as
well where it is rendering dark.

FWIW when llvm is on packetize mesa doesn't build on head so for these it's
been (random choice) set on 

e2b985dc0f93a195d984aa7c88669ab67160c6c4

-- 
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 64193] LLVM RV670 regression since R600: Packetize instructions

[bugzilla-daemon]

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

--- Comment #6 from Andy Furniss adf.li...@gmail.com ---
Created attachment 78854
  -- https://bugs.freedesktop.org/attachment.cgi?id=78854action=edit
R600_DEBUG=vs,ps,fs glxgears rendering OK on packetize with patch

-- 
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 64193] LLVM RV670 regression since R600: Packetize instructions

[bugzilla-daemon]

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

--- Comment #7 from Andy Furniss adf.li...@gmail.com ---
Created attachment 78855
  -- https://bugs.freedesktop.org/attachment.cgi?id=78855action=edit
R600_DEBUG=vs,ps,fs glxgears rendering dark on heads

-- 
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

DMA mapping API abuse in exynos-drm

[Tomasz Figa]

Hi,

Recently I've been working a bit on a DRM driver for the GPU of Samsung 
S3C6410 SoCs, which required me to familiarize a bit with exynos-drm, as 
it already contains a KMS driver which is compatible with the SoC I'm 
working with, making it a good place to put my driver in.

Reading through exynos_drm_buf.c I stumbled across following (a bit long) 
piece of code:

dma_set_attr(DMA_ATTR_NO_KERNEL_MAPPING, buf-dma_attrs);

nr_pages = buf-size  PAGE_SHIFT;

if (!is_drm_iommu_supported(dev)) {
dma_addr_t start_addr;
unsigned int i = 0;

buf-pages = kzalloc(sizeof(struct page) * nr_pages,
GFP_KERNEL);
if (!buf-pages) {
DRM_ERROR(failed to allocate pages.\n);
return -ENOMEM;
}

buf-kvaddr = dma_alloc_attrs(dev-dev, buf-size,
buf-dma_addr, GFP_KERNEL,
buf-dma_attrs);
if (!buf-kvaddr) {
DRM_ERROR(failed to allocate buffer.\n);
kfree(buf-pages);
return -ENOMEM;
}

start_addr = buf-dma_addr;
while (i  nr_pages) {
buf-pages[i] = phys_to_page(start_addr);
start_addr += PAGE_SIZE;
i++;
}
} else {

buf-pages = dma_alloc_attrs(dev-dev, buf-size,
buf-dma_addr, GFP_KERNEL,
buf-dma_attrs);
if (!buf-pages) {
DRM_ERROR(failed to allocate buffer.\n);
return -ENOMEM;
}
}

buf-sgt = drm_prime_pages_to_sg(buf-pages, nr_pages);
if (!buf-sgt) {
DRM_ERROR(failed to get sg table.\n);
ret = -ENOMEM;
goto err_free_attrs;
}

Notice that the value returned by dma_alloc_attrs() is assumed by this 
code to be either a kernel virtual address (in !is_drm_iommu_supported() 
case) or struct pages ** (in is_drm_iommu_supported() case), which seemed 
a bit worrying to me, making me do a more in depth research on how 
dma_alloc_attrs works.

This, in turn, led me to following excerpt of Documentation/DMA-
attributes.txt :

DMA_ATTR_NO_KERNEL_MAPPING
--

DMA_ATTR_NO_KERNEL_MAPPING lets the platform to avoid creating a kernel
virtual mapping for the allocated buffer. On some architectures creating
such mapping is non-trivial task and consumes very limited resources
(like kernel virtual address space or dma consistent address space).
Buffers allocated with this attribute can be only passed to user space
by calling dma_mmap_attrs(). By using this API, you are guaranteeing
that you won't dereference the pointer returned by dma_alloc_attr(). You
can threat it as a cookie that must be passed to dma_mmap_attrs() and
dma_free_attrs(). Make sure that both of these also get this attribute
set on each call.

of which the following sentence is the most relevant:

By using this API, you are guaranteeing that you won't dereference the 
pointer returned by dma_alloc_attr().

This statement is obviously ignored by buffer allocation code of exynos-
drm.

A simple git blame revealed that this brokenness has been introduced by 
commit:

4744ad2 drm/exynos: use DMA_ATTR_NO_KERNEL_MAPPING attribute


and later fixed a bit by following depending patches (because the original 
patch apparently broke any allocations without IOMMU):

c704f1b drm/exynos: consider no iommu support to console framebuffer
694be45 drm/exynos: consider buffer allocation without iommu


Now, the real question is whether my reasoning is incorrect (sorry for the 
noise then) or this is really a bug which needs to be fixed?

Best regards,
Tomasz

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

[Bug 61747] [r600g] GPU lockup when playing WoW with HD6450 with htile enabled

[bugzilla-daemon]

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

--- Comment #13 from Chris Rankin ranki...@googlemail.com ---
This version of Mesa is a lot more promising!

OpenGL vendor string: X.Org
OpenGL renderer string: Gallium 0.4 on AMD CAICOS
OpenGL core profile version string: 3.1 (Core Profile) Mesa 9.2.0 (git-8c347d4)
OpenGL core profile shading language version string: 1.40
OpenGL core profile context flags: (none)

No lock-ups so far!

-- 
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 64220] GPU lockup in L4D2 on SUMO

[bugzilla-daemon]

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

--- Comment #1 from runetmem...@gmail.com ---
Created attachment 78857
  -- https://bugs.freedesktop.org/attachment.cgi?id=78857action=edit
dmesg

-- 
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 64220] GPU lockup in L4D2 on SUMO

[bugzilla-daemon]

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

--- Comment #2 from runetmem...@gmail.com ---
Created attachment 78858
  -- https://bugs.freedesktop.org/attachment.cgi?id=78858action=edit
Xorg log

-- 
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 56659] DRI_PRIME: triangle, rendering inside of which occurs with a noticeable delay

[bugzilla-daemon]

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

--- Comment #4 from runetmem...@gmail.com ---
Still reproducible with radeon 7.1.0. Tested on native Left 4 Dead 2.

-- 
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 64220] GPU lockup in L4D2 on SUMO and TURKS

[bugzilla-daemon]

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

runetmem...@gmail.com changed:

   What|Removed |Added

Summary|GPU lockup in L4D2 on SUMO  |GPU lockup in L4D2 on SUMO
   ||and TURKS

-- 
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 64220] GPU lockup in L4D2 on SUMO and TURKS

[bugzilla-daemon]

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

--- Comment #3 from runetmem...@gmail.com ---
This GPU lockup is also reproducible on Radeon HD 6650M.

-- 
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 60553] [trine2] wrong colors when executed fullscreen

[bugzilla-daemon]

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

lethar...@gmail.com changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #5 from lethar...@gmail.com ---
Running with mesa as of c4150123aa9c2a71a62fed800d7c4424e9b948f2 I do not see
this fixed.

The problems in the main menu, as shows in the screenshots already attached,
remain. I'll attach images of gameplay as well, as the effect is shown more
clearly there.

-- 
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 60553] [trine2] wrong colors when executed fullscreen

[bugzilla-daemon]

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

--- Comment #6 from lethar...@gmail.com ---
Created attachment 78860
  -- https://bugs.freedesktop.org/attachment.cgi?id=78860action=edit
Trine 2 in fullscreen, heavy miss rendering.

-- 
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 60553] [trine2] wrong colors when executed fullscreen

[bugzilla-daemon]

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

--- Comment #8 from lethar...@gmail.com ---
Created attachment 78862
  -- https://bugs.freedesktop.org/attachment.cgi?id=78862action=edit
Trine 2 windowed. Proper rendering.

-- 
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 64201] OpenCL usage result segmentation fault on r600g with HD6850.

[bugzilla-daemon]

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

--- Comment #7 from Tom Stellard tstel...@gmail.com ---
(In reply to comment #4)
 Hi friends,
 
 @Vincent, I will add output as an attachment.
 
 @Tom Stellard
 
 For pyrit : svn checkout http://pyrit.googlecode.com/svn/trunk/
 pyrit-read-only
 
 I don't patched it. Will report with your patch asap.
 
 Other programs are cgminer : https://github.com/ckolivas/cgminer
 

I would recommend using bfgminer for bitcoin mining.  It auto-detects the mesa
platform, and disabled unsupported features.  All you need to do to get it to
work is pass the -v1 flag.

 And python-opencl package from suse repo that give  pipe_r600.so fault.
 

Can you open a separate bug for this or any other programs you've tried.

 Any other program that I trued doesn't work on my card, yet.



 
 Thanks.

-- 
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 64220] GPU lockup in L4D2 on SUMO and TURKS

[bugzilla-daemon]

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

runetmem...@gmail.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #5 from runetmem...@gmail.com ---
Thanks! That workaround help prevent GPU lockups.

*** This bug has been marked as a duplicate of bug 60969 ***

-- 
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 60969] [r600g] Lockup while playing OpenGL games with HD6450

[bugzilla-daemon]

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

runetmem...@gmail.com changed:

   What|Removed |Added

 CC||runetmem...@gmail.com

--- Comment #9 from runetmem...@gmail.com ---
*** Bug 64220 has been marked as a duplicate of this bug. ***

-- 
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 64201] OpenCL usage result segmentation fault on r600g with HD6850.

[bugzilla-daemon]

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

--- Comment #8 from Erdem U. Altinyurt spamjunkea...@gmail.com ---
(In reply to comment #7)
 I would recommend using bfgminer for bitcoin mining.  It auto-detects the
 mesa platform, and disabled unsupported features.  All you need to do to get
 it to work is pass the -v1 flag.

I just want try openCL programs. Not intended to waste energy with those yet,
until I produce my energy by solar panels...

With bfgminer -v1 --benchmark, I think it start working first. But hey! I got
GPU lockups which is serious bug I think! :-/
I attached the kernel messages.

Anyway I got 1.6M hash/s.


Also bfgminer -v1 --benchmark --scrypt gives segmentation fault.
Attaching the debug output with R600_cs=DEBUG.



  And python-opencl package from suse repo that give  pipe_r600.so fault.
 Can you open a separate bug for this or any other programs you've tried.
ACK

-- 
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 64201] OpenCL usage result segmentation fault on r600g with HD6850.

[bugzilla-daemon]

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

--- Comment #9 from Erdem U. Altinyurt spamjunkea...@gmail.com ---
Created attachment 78868
  -- https://bugs.freedesktop.org/attachment.cgi?id=78868action=edit
GPU Lockup with bfgminer -v1 --benchmark kernel messages

-- 
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 64225] New: bfgminer --scyte generates Segmentation Fault on Northern Island

[bugzilla-daemon]

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

  Priority: medium
Bug ID: 64225
  Assignee: dri-devel@lists.freedesktop.org
   Summary: bfgminer --scyte generates Segmentation Fault on
Northern Island
  Severity: normal
Classification: Unclassified
OS: Linux (All)
  Reporter: spamjunkea...@gmail.com
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: git
 Component: Drivers/DRI/R600
   Product: Mesa

Created attachment 78869
  -- https://bugs.freedesktop.org/attachment.cgi?id=78869action=edit
./bfgminer -v1 --benchmark --scrypt 

OpenSUSE LLVM-trunk (patched version using:
https://bugs.freedesktop.org/attachment.cgi?id=78831) with Mesa trunk 3.9
kernel x86_64


./bfgminer -v1 --benchmark --scrypt
Generated segmentation fault.
Log attached.
Thanks

-- 
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 64226] New: python-opencl package generate segmentation fault at pipe_r600.so

[bugzilla-daemon]

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

  Priority: medium
Bug ID: 64226
  Assignee: dri-devel@lists.freedesktop.org
   Summary: python-opencl package generate segmentation fault at
pipe_r600.so
  Severity: normal
Classification: Unclassified
OS: Linux (All)
  Reporter: spamjunkea...@gmail.com
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: git
 Component: Drivers/Gallium/r600
   Product: Mesa

Using OpenSUSE llvm-trunk  Mesa-trunk 3.9 Kernel x86_64
Using OpenSuSE repo package:
https://build.opensuse.org/package/show?project=home%3A-miska-package=python-opencl

Source included also, packed version of : https://github.com/srossross/oclpb


death@triQuad:/home/compile/svn/cgminer python
Python 2.7.3 (default, Apr 14 2012, 08:58:41) [GCC] on linux2
Type help, copyright, credits or license for more information.
 import opencl
 opencl.test()
[opencl.Device name='AMD BARTS' type=4L]
test_broadcast_0D (test.test_memobj.TestBuffer) ... ok
test_broadcast_2D (test.test_memobj.TestBuffer) ... ok
test_copy_1D (test.test_memobj.TestBuffer) ... FAIL
test_copy_2D (test.test_memobj.TestBuffer) ... FAIL
test_copy_2D_negative_stride (test.test_memobj.TestBuffer) ... expected failure
test_copy_contig (test.test_memobj.TestBuffer) ... Segmentation fault
death@triQuad:/home/compile/svn/cgminer

-- 
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 64225] bfgminer --scyte generates Segmentation Fault on Northern Island

[bugzilla-daemon]

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

Erdem U. Altinyurt spamjunkea...@gmail.com changed:

   What|Removed |Added

  Component|Drivers/DRI/R600|Drivers/Gallium/r600

-- 
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 64201] OpenCL usage result segmentation fault on r600g with HD6850.

[bugzilla-daemon]

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

--- Comment #10 from Erdem U. Altinyurt spamjunkea...@gmail.com ---
Also faced same lockups at GIMP OpenCL, otherwise it looks start working,
sloly. :)
If bfgminer fix doesn't fix GIMP also, I will open bug report for it also.
Thanks.

-- 
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