[PATCH] drm/amdgpu: increment queue when iterating on this variable.

[Nicolas Iooss]

gfx_v7_0_print_status contains a for loop on variable queue which does
not update this variable between each iteration.  This is bug is
reported by clang while building allmodconfig LLVMLinux on x86_64:

drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c:5126:19: error: variable
'queue' used in loop condition not modified in loop body
[-Werror,-Wloop-analysis]
for (queue = 0; queue < 8; i++) {
^

Fix this by incrementing variable queue instead of i in this loop.

Signed-off-by: Nicolas Iooss 
---
 drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c 
b/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c
index 2db6ab0a543d..5c03420ca5dc 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c
@@ -5122,7 +5122,7 @@ static void gfx_v7_0_print_status(void *handle)
dev_info(adev->dev, "  CP_HPD_EOP_CONTROL=0x%08X\n",
 RREG32(mmCP_HPD_EOP_CONTROL));

-   for (queue = 0; queue < 8; i++) {
+   for (queue = 0; queue < 8; queue++) {
cik_srbm_select(adev, me, pipe, queue, 0);
dev_info(adev->dev, "  queue: %d\n", queue);
dev_info(adev->dev, "  CP_PQ_WPTR_POLL_CNTL=0x%08X\n",
-- 
2.5.0

[Bug 91084] RadeonSI crash while playing World Of Tanks

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

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

--- Comment #13 from Eduards Bezverhijs  ---
Hi,

I'm glad to report that today I tried playing WOT with latest mesa/radeon and
it didn't crash for at least 3 hrs (wine 1.7.44-nine, gallium nine, oibaf ppa).
Package versions are as follows: all mesa package versions are
10.7~git1507310730.7830e4~gd~t, radeon driver package version is
7.5.99+git1507301931.09c7cd~gd~t.

Not sure if this helped or not, but one thing that I had to change (because I
had to free some space temporarily) was to move radeon card to pcie x8 slot,
after a week or so I'll move radeon back to x16 slot and will test again.

regards
Mjasnik

-- 
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/20150801/6c8e273a/attachment.html>

[Bug 87278] Packet0 not allowed and GPU fault detected errors with Serious Engine games

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

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

Daniel Scharrer  changed:

   What|Removed |Added

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

--- Comment #30 from Daniel Scharrer  ---
I no longer get any GPU faults or Packet0 errors with current LLVM and mesa
(2b83133, even with unsafe math disabled again).

-- 
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/20150801/9fef563a/attachment-0001.html>

[PATCH] scripts/kernel-doc Allow struct arguments documentation in struct body

[Laurent Pinchart]

Hi Jon,

On Saturday 01 August 2015 13:22:10 Jonathan Corbet wrote:
> On Fri, 31 Jul 2015 18:06:45 -0300 Danilo Cesar Lemes de Paula wrote:
> > Describing arguments at top of a struct definition works fine
> > for small/medium size structs, but it definitely doesn't work well
> > for struct with a huge list of elements.
> > 
> > Keeping the arguments list inside the struct body makes it easier
> > to maintain the documentation.
> 
> Interesting approach.  I think it could make sense, but I fear pushback
> from a subset of maintainers refusing to accept this mode.  I wonder what
> it would take to get a consensus on allowing these in-struct comments?
> 
> I'm wondering if we need a kernel summit session on commenting
> conventions, markdown-in-kerneldoc, etc?  Maybe I'll stick a proposal out
> there.

The topic of documentation has been raised in the mail thread of the kernel 
recruitment proposal for the kernel summit. I believe it's an important one, 
and I will be very interested in contributing if it is discussed as a separate 
topic.

-- 
Regards,

Laurent Pinchart

[Bug 91522] Tonga display lock on agd5f drm-next-4.3-wip since drm/amdgpu: fix syncing to VM updates

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

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

Bug ID: 91522
   Summary: Tonga display lock on agd5f  drm-next-4.3-wip since
drm/amdgpu: fix syncing to VM updates
   Product: DRI
   Version: DRI git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: adf.lists at gmail.com

Tried agd5f drm-next-4.3-wip without enabling anything new. agd5f mesa/drm
amdgpu.

I can startx but doing anything 3d/vdpau results in a display lock.

Nothing is logged, there is no gpu reset. SysRq works (and gets logged).

bisecting using glxgears to trigger came up with -

commit 928db3aef53b0e74e26a6815890b6162cff2f4e7
Author: Christian König 
Date:   Mon Jul 27 15:40:35 2015 +0200

drm/amdgpu: fix syncing to VM updates

-- 
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/20150801/9dd66cd7/attachment.html>

[Bug 90378] [LLVM][bisected] GPU lockups in Left 4 Dead 2

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

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

Daniel Scharrer  changed:

   What|Removed |Added

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

--- Comment #10 from Daniel Scharrer  ---
With that patch series merged I can no longer reproduce the GPU lockups.

-- 
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/20150801/6c424a0e/attachment.html>

[PATCH] scripts/kernel-doc Allow struct arguments documentation in struct body

[Jonathan Corbet]

On Fri, 31 Jul 2015 18:06:45 -0300
Danilo Cesar Lemes de Paula  wrote:

> Describing arguments at top of a struct definition works fine
> for small/medium size structs, but it definitely doesn't work well
> for struct with a huge list of elements.
> 
> Keeping the arguments list inside the struct body makes it easier
> to maintain the documentation.

Interesting approach.  I think it could make sense, but I fear pushback
from a subset of maintainers refusing to accept this mode.  I wonder what
it would take to get a consensus on allowing these in-struct comments?

I'm wondering if we need a kernel summit session on commenting
conventions, markdown-in-kerneldoc, etc?  Maybe I'll stick a proposal out
there.

Thanks,

jon

[Bug 79417] r600-cayman: GPU lockup in Planetary Annihilation (PTE 66705) on HD6950

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

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

--- Comment #2 from russianneuromancer at ya.ru ---
This issue is still reproducible with current Mesa?

-- 
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/20150801/e3aed930/attachment.html>

[RFC 20/21] drm/shmobile: Remove FB_KMS_HELPER config option

[Laurent Pinchart]

Hi Archit,

Thank you for the patch.

On Monday 13 July 2015 12:14:07 Archit Taneja wrote:
> The driver internally uses drm_fb_cma helpers to emulate fbdev and
> allocate buffers. It doesn't need to select DRM_FB_KMS_HELPER. This
> will be managed by the config option DRM_KMS_CMA_HELPER.
> 
> Cc: Laurent Pinchart 
> 
> Signed-off-by: Archit Taneja 

Acked-by: Laurent Pinchart 

> ---
>  drivers/gpu/drm/shmobile/Kconfig | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/shmobile/Kconfig
> b/drivers/gpu/drm/shmobile/Kconfig index b9202aa..389b5f9 100644
> --- a/drivers/gpu/drm/shmobile/Kconfig
> +++ b/drivers/gpu/drm/shmobile/Kconfig
> @@ -6,7 +6,6 @@ config DRM_SHMOBILE
>   select BACKLIGHT_CLASS_DEVICE
>   select BACKLIGHT_LCD_SUPPORT
>   select DRM_KMS_HELPER
> - select DRM_KMS_FB_HELPER
>   select DRM_KMS_CMA_HELPER
>   select DRM_GEM_CMA_HELPER
>   help

-- 
Regards,

Laurent Pinchart

[RFC 19/21] drm/rcar-du: Remove FB_KMS_HELPER config option

[Laurent Pinchart]

Hi Archit,

Thank you for the patch.

On Monday 13 July 2015 12:14:06 Archit Taneja wrote:
> The driver internally uses drm_fb_cma helpers to emulate fbdev and
> allocate buffers. It doesn't need to select DRM_FB_KMS_HELPER. This
> will be managed by the config option DRM_KMS_CMA_HELPER.
> 
> Cc: Laurent Pinchart 
> 
> Signed-off-by: Archit Taneja 

Acked-by: Laurent Pinchart 

> ---
>  drivers/gpu/drm/rcar-du/Kconfig | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/rcar-du/Kconfig
> b/drivers/gpu/drm/rcar-du/Kconfig index 11485a4..9de5872 100644
> --- a/drivers/gpu/drm/rcar-du/Kconfig
> +++ b/drivers/gpu/drm/rcar-du/Kconfig
> @@ -5,7 +5,6 @@ config DRM_RCAR_DU
>   select DRM_KMS_HELPER
>   select DRM_KMS_CMA_HELPER
>   select DRM_GEM_CMA_HELPER
> - select DRM_KMS_FB_HELPER
>   select VIDEOMODE_HELPERS
>   help
> Choose this option if you have an R-Car chipset.

-- 
Regards,

Laurent Pinchart

[RFC 05/21] drm/omap: Remove FB_KMS_HELPER and FB related config options

[Laurent Pinchart]

Hi Archit,

Thank you for the patch.

On Monday 13 July 2015 12:13:52 Archit Taneja wrote:
> Remove FB_* config options since the driver doesn't call any fbdev
> functions directly.
> 
> Remove FB_KMS_HELPER as this would now be selected by the top level
> FBDEV_EMULATION config option. If the fbdev emulation isn't selected,
> the drm_fb_helper functions will be stubbed out.
> 
> Cc: Tomi Valkeinen 
> Cc: Laurent Pinchart 
> 
> Signed-off-by: Archit Taneja 

I like that, one step closer to removing fbdev altogether (even if there are 
many steps left) :-)

Acked-by: Laurent Pinchart 

> ---
>  drivers/gpu/drm/omapdrm/Kconfig | 5 -
>  1 file changed, 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/Kconfig
> b/drivers/gpu/drm/omapdrm/Kconfig index 6c220cd..340ece7 100644
> --- a/drivers/gpu/drm/omapdrm/Kconfig
> +++ b/drivers/gpu/drm/omapdrm/Kconfig
> @@ -5,11 +5,6 @@ config DRM_OMAP
>   depends on ARCH_OMAP2PLUS || ARCH_MULTIPLATFORM
>   depends on OMAP2_DSS
>   select DRM_KMS_HELPER
> - select DRM_KMS_FB_HELPER
> - select FB_SYS_FILLRECT
> - select FB_SYS_COPYAREA
> - select FB_SYS_IMAGEBLIT
> - select FB_SYS_FOPS
>   default n
>   help
> DRM display driver for OMAP2/3/4 based boards.

-- 
Regards,

Laurent Pinchart

[PATCH v3 10/24] drm/omap: Use new drm_fb_helper functions

[Laurent Pinchart]

Hi Archit,

Thank you for the patch.

On Friday 31 July 2015 16:21:48 Archit Taneja wrote:
> Use the newly created wrapper drm_fb_helper functions instead of calling
> core fbdev functions directly. They also simplify the fb_info creation.
> 
> v3:
> - Update error handling for new drm_fb_helper funcs. Check using IS_ERR()
>   instead of checking for NULL.
> 
> Reported-by: Dan Carpenter 
> 
> v2:
> - No changes
> 
> Cc: Tomi Valkeinen 
> Cc: Laurent Pinchart 
> 
> Signed-off-by: Archit Taneja 

Acked-by: Laurent Pinchart 

> ---
>  drivers/gpu/drm/omapdrm/omap_fbdev.c | 38  +++-
>  1 file changed, 13 insertions(+), 25 deletions(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/omap_fbdev.c
> b/drivers/gpu/drm/omapdrm/omap_fbdev.c index 23b5a84..4916543 100644
> --- a/drivers/gpu/drm/omapdrm/omap_fbdev.c
> +++ b/drivers/gpu/drm/omapdrm/omap_fbdev.c
> @@ -86,11 +86,11 @@ static struct fb_ops omap_fb_ops = {
>   /* Note: to properly handle manual update displays, we wrap the
>* basic fbdev ops which write to the framebuffer
>*/
> - .fb_read = fb_sys_read,
> - .fb_write = fb_sys_write,
> - .fb_fillrect = sys_fillrect,
> - .fb_copyarea = sys_copyarea,
> - .fb_imageblit = sys_imageblit,
> + .fb_read = drm_fb_helper_sys_read,
> + .fb_write = drm_fb_helper_sys_write,
> + .fb_fillrect = drm_fb_helper_sys_fillrect,
> + .fb_copyarea = drm_fb_helper_sys_copyarea,
> + .fb_imageblit = drm_fb_helper_sys_imageblit,
> 
>   .fb_check_var = drm_fb_helper_check_var,
>   .fb_set_par = drm_fb_helper_set_par,
> @@ -179,10 +179,10 @@ static int omap_fbdev_create(struct drm_fb_helper
> *helper,
> 
>   mutex_lock(>struct_mutex);
> 
> - fbi = framebuffer_alloc(0, dev->dev);
> - if (!fbi) {
> + fbi = drm_fb_helper_alloc_fbi(helper);
> + if (IS_ERR(fbi)) {
>   dev_err(dev->dev, "failed to allocate fb info\n");
> - ret = -ENOMEM;
> + ret = PTR_ERR(fbi);
>   goto fail_unlock;
>   }
> 
> @@ -190,7 +190,6 @@ static int omap_fbdev_create(struct drm_fb_helper
> *helper,
> 
>   fbdev->fb = fb;
>   helper->fb = fb;
> - helper->fbdev = fbi;
> 
>   fbi->par = helper;
>   fbi->flags = FBINFO_DEFAULT;
> @@ -198,12 +197,6 @@ static int omap_fbdev_create(struct drm_fb_helper
> *helper,
> 
>   strcpy(fbi->fix.id, MODULE_NAME);
> 
> - ret = fb_alloc_cmap(>cmap, 256, 0);
> - if (ret) {
> - ret = -ENOMEM;
> - goto fail_unlock;
> - }
> -
>   drm_fb_helper_fill_fix(fbi, fb->pitches[0], fb->depth);
>   drm_fb_helper_fill_var(fbi, helper, sizes->fb_width, sizes->fb_height);
> 
> @@ -236,8 +229,9 @@ fail_unlock:
>  fail:
> 
>   if (ret) {
> - if (fbi)
> - framebuffer_release(fbi);
> +
> + drm_fb_helper_release_fbi(helper);
> +
>   if (fb) {
>   drm_framebuffer_unregister_private(fb);
>   drm_framebuffer_remove(fb);
> @@ -312,17 +306,11 @@ void omap_fbdev_free(struct drm_device *dev)
>   struct omap_drm_private *priv = dev->dev_private;
>   struct drm_fb_helper *helper = priv->fbdev;
>   struct omap_fbdev *fbdev;
> - struct fb_info *fbi;
> 
>   DBG();
> 
> - fbi = helper->fbdev;
> -
> - /* only cleanup framebuffer if it is present */
> - if (fbi) {
> - unregister_framebuffer(fbi);
> - framebuffer_release(fbi);
> - }
> + drm_fb_helper_unregister_fbi(helper);
> + drm_fb_helper_release_fbi(helper);
> 
>   drm_fb_helper_fini(helper);

-- 
Regards,

Laurent Pinchart

[Bug 91520] [radeonsi, PIGLIT, regression] spec@arb_gpu_shader_fp64@execution@fs-indirect-temp-double-{dst, src} triggers SIGSEGV

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

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

Bug ID: 91520
   Summary: [radeonsi, PIGLIT, regression]
spec at arb_gpu_shader_fp64@execution at fs-indirect-temp-do
uble-{dst,src} triggers SIGSEGV
   Product: Mesa
   Version: git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Keywords: regression
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: kai at dev.carbon-project.org
QA Contact: dri-devel at lists.freedesktop.org

Created attachment 117480
  --> https://bugs.freedesktop.org/attachment.cgi?id=117480=edit
GDB: backtraces and register info for crashes

For two builds now I'm seeing the two Piglit tests
spec at arb_gpu_shader_fp64@execution at fs-indirect-temp-double-{src,dst} 
crash in
radeonsi_dri.so.

dmesg shows:
> shader_runner[26631]: segfault at 2017f9ba1 ip 7f16519bd800 sp 
> 7ffc79c82250 error 6 in radeonsi_dri.so[7f165140f000+7d3000]

Attached you'll find the GDB output (full backtrace, full register info) for
the crashes triggered by both tests with my current stack (see below for
details).

The last known good Mesa version was Git:master/bb9d59aed5 (build date
2015-07-26). The first known failing build was Git:master/fdb8487613 (build
date 2015-07-30). The LLVM revision used for the fdb8487613 build was r243627
(LLVM SVN trunk, 3.8-devel). Sadly I can't seem to find the LLVM revision used
by the bb9d59aed5 build anylonger. But it was probably a build of a revision
from that day, since I'm using the snapshot builds from <http://llvm.org/apt>,
which are done twice per day.

My current stack (Debian testing as a base):
GPU: Hawaii PRO [Radeon R9 290] (ChipID = 0x67b1)
Mesa: Git:master/5d29eaef85
libdrm: 2.4.62-1
LLVM: SVN:trunk/r243678 (3.8 devel)
X.Org: 2:1.17.1-2
Linux: 4.1.3
Firmware: <https://secure.freedesktop.org/~agd5f/radeon_ucode/hawaii/>
> 286640da3d90d7b51bdb038b65addc47  hawaii_ce.bin
> 161105a73f7dfb2fca513327491c32d6  hawaii_mc.bin
> d6195059ea724981c9acd3abd6ee5166  hawaii_me.bin
> ad511d31a4fe3147c8d80b8f6770b8d5  hawaii_mec.bin
> 63eae3f33c77aadbc6ed1a09a2aed81e  hawaii_pfp.bin
> 5b72c73acf0cbd0cbb639302f65bc7dc  hawaii_rlc.bin
> f00de91c24b3520197e1ddb85d99c34a  hawaii_sdma1.bin
> 8e16f749d62b150d0d1f580d71bc4348  hawaii_sdma.bin
> 7b6ca5302b56bd35bf52804919d57e63  hawaii_smc.bin
> 9f2ba7e720e2af4d7605a9a4fd903513  hawaii_uvd.bin
> b0f2a043e72fbf265b2f858b8ddbdb09  hawaii_vce.bin
libclc: Git:master/7958b0202b
DDX: Git:master/b6d871bf29

-- 
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/20150801/f5072918/attachment.html>

[Bug 91518] [TAHITI] Crash caused by GPU faults while launching Unigine Heaven 4.0

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

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

--- Comment #4 from Gustaw Smolarczyk  ---
Created attachment 117479
  --> https://bugs.freedesktop.org/attachment.cgi?id=117479=edit
dmesg with GPU lock-up

Commenting the old heaven profiles from ~/.drirc didn't help. Or maybe it did
change the behavior somewhat.

Attached is the relevant fragment of kern.log. The GPU did restart a few times
but eventually the system locked-up.

What's more, when the freeze happened the loading screen was displayed. So the
problem happened even earlier then before. It might have happened that way by
chance though.

-- 
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/20150801/fc5bd9ee/attachment.html>

[Bug 91518] [TAHITI] Crash caused by GPU faults while launching Unigine Heaven 4.0

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

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

--- Comment #3 from Gustaw Smolarczyk  ---
I think it happens automatically when I am using the gentoo ebuild, since the
contents of /etc/drirc match the in the mesa git repository.

But the ~/.drirc contains the old values... Let me check with the local file
deleted (or at least the heaven sections deleted).

-- 
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/20150801/2adce2f7/attachment.html>

[Bug 91518] [TAHITI] Crash caused by GPU faults while launching Unigine Heaven 4.0

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

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

--- Comment #2 from Marek Olšák  ---
Did you install Mesa's drirc in /etc/drirc?

-- 
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/20150801/1e2da53a/attachment-0001.html>

[Bug 90217] Counter Strike Global Offensive: GPU fault after a while

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

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

Christoph Haag  changed:

   What|Removed |Added

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

--- Comment #5 from Christoph Haag  ---
Hasn't happened for a while, will reopen in case it happens again.

-- 
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/20150801/d6a7d8cd/attachment.html>

[Bug 91518] [TAHITI] Crash caused by GPU faults while launching Unigine Heaven 4.0

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

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

--- Comment #1 from Gustaw Smolarczyk  ---
Also, I am using LLVM from git.

-- 
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/20150801/c4d2499e/attachment.html>

[Bug 91518] [TAHITI] Crash caused by GPU faults while launching Unigine Heaven 4.0

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

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

Bug ID: 91518
   Summary: [TAHITI] Crash caused by GPU faults while launching
Unigine Heaven 4.0
   Product: Mesa
   Version: git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: wielkiegie at gmail.com
QA Contact: dri-devel at lists.freedesktop.org

Hello,

While trying to test new tessellation code in radeonsi using Unigine Heaven, I
happened to stumble on this bug.

After first few frames of rendering after the loading screen ends, the system
locks itself up. The rendering is almost always broken too. Sometimes the GPU
does try to restart, but most of the time the lock-up is hard (the kernel
doesn't respond to any keyboard events) and I need to reset.

After the reset, the following messages reside in the kern.log (quite a lot of
them):

[  142.631214] radeon :02:00.0: GPU fault detected: 147 0x0a0d4402
[  142.631217] radeon :02:00.0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR  
0x00130CD0
[  142.631218] radeon :02:00.0:   VM_CONTEXT1_PROTECTION_FAULT_STATUS
0x0D044002
[  142.631220] VM fault (0x02, vmid 6) at page 1248464, write from TC (68)

This could be related to #90266, but the faults don't happen in the background,
they almost immediately take the system down.

I am using kernel 4.1.3, mesa and libdrm from git, xorg 1.17.2, ddx 7.5.0.
The problem also did happen just before the tessellation work was done (with
the tessellation disabled in the benchmark), using mesa from ~2 weeks ago. The
recent Marek's fixes didn't help.

Relevant Heaven settings:
Quality: Ultra
Tessellation: Extreme/Disabled
Anti-Aliasing: 4x/8x
Full Screen: yes

-- 
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/20150801/396a69bf/attachment.html>

[Bug 88978] [bisected] [SI Scheduler] Graphical corruption in Dota 2

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

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

Michel Dänzer  changed:

   What|Removed |Added

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

--- Comment #20 from Michel Dänzer  ---
Resolving per comment 19, thanks for the update.

-- 
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/20150801/9a187769/attachment.html>

[PULL] drm-intel-fixes

[Daniel Vetter]

On Fri, Jul 31, 2015 at 9:07 PM, Linus Torvalds
 wrote:
> On Fri, Jul 31, 2015 at 9:54 AM, Daniel Vetter  
> wrote:
>>
>> I delayed my -fixes pull a bit hoping that I could include a fix for the
>> dp mst stuff but looks a bit more nasty than that. So just 3 other
>> regression fixes, one 4.2 other two cc: stable.
>
> Quick question: you can now reproduce the mst problem that Ted
> reported? You said you found a mst bridge..
>
> This matters mainly because I wonder if I should apply my temporary
> workaround patch, or expect that a real fix is coming soon..

Yeah I have matching fireworks now I think, took a bit of trickery
since I plugged the mst into a desktop which means it'll use pipe A by
default. The fun seems to only happen on the other pipes ...
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH] drm: panel: simple: add QiaoDian qd43003c0-40

[Alexandre Belloni]

From: Josh Wu 

The QiaoDian Xianshi QD43003C0-40 is a 4"3 TFT LCD panel.

Timings from the OTA5180A document, ver 0.9, section
10.1.1:
  http://www.orientdisplay.com/pdf/OTA5180A.pdf

Signed-off-by: Josh Wu 
Signed-off-by: Alexandre Belloni 
---
 .../devicetree/bindings/panel/qd,qd43003c0-40.txt  |  7 ++
 drivers/gpu/drm/panel/panel-simple.c   | 26 ++
 2 files changed, 33 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/panel/qd,qd43003c0-40.txt

diff --git a/Documentation/devicetree/bindings/panel/qd,qd43003c0-40.txt 
b/Documentation/devicetree/bindings/panel/qd,qd43003c0-40.txt
new file mode 100644
index ..900bc6ebeaff
--- /dev/null
+++ b/Documentation/devicetree/bindings/panel/qd,qd43003c0-40.txt
@@ -0,0 +1,7 @@
+QiaoDian XianShi Corporation 4"3 TFT LCD panel
+
+Required properties:
+- compatible: should be "qd,qd43003c0-40"
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index f94201b6e882..e688fa545ae3 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -967,6 +967,29 @@ static const struct panel_desc ortustech_com43h4m85ulc = {
.bus_format = MEDIA_BUS_FMT_RGB888_1X24,
 };

+static const struct drm_display_mode qd43003c0_40_mode = {
+   .clock = 9000,
+   .hdisplay = 480,
+   .hsync_start = 480 + 8,
+   .hsync_end = 480 + 8 + 4,
+   .htotal = 480 + 8 + 4 + 39,
+   .vdisplay = 272,
+   .vsync_start = 272 + 4,
+   .vsync_end = 272 + 4 + 10,
+   .vtotal = 272 + 4 + 10 + 2,
+   .vrefresh = 60,
+};
+
+static const struct panel_desc qd43003c0_40 = {
+   .modes = _40_mode,
+   .num_modes = 1,
+   .size = {
+   .width = 95,
+   .height = 53,
+   },
+   .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
+};
+
 static const struct drm_display_mode samsung_ltn101nt05_mode = {
.clock = 54030,
.hdisplay = 1024,
@@ -1116,6 +1139,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "ortustech,com43h4m85ulc",
.data = _com43h4m85ulc,
}, {
+   .compatible = "qd,qd43003c0-40",
+   .data = _40,
+   }, {
.compatible = "samsung,ltn101nt05",
.data = _ltn101nt05,
}, {
-- 
2.1.4

[Bug 91509] Depth render buffer corruption

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

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

--- Comment #5 from Roland Scheidegger  ---
(In reply to Roland Scheidegger from comment #4)
> As a quick hunch based on your observations and some quick look in the code,
> it seems depth buffers need to be 128 byte aligned on r200 (and 64 byte on
> r100 though that's just based on the tile/untile code), but
> radeon_alloc_renderbuffer_storage() only does it to 64 bytes: (pitch = ((cpp
> * width + 63) & ~63) / cpp;)
> Could you try out if increasing that to 128 byte alignment there would help?
> For the heck of it I can't figure out though from where the window
> depth/colorbuffers get their alignment, so I've no idea how that's
> calculated there...
> Not sure right now on color buffers neither...

Actually if I see that right it looks like the xorg ati driver would align
things to 64 pixels for non-tiled surfaces and 256 / cpp for tiled ones (so
still 64 pixels for z24s8). That would be even twice of what I suggested above.
May not really be required, though. The docs seem to suggest 8 pixels for color
buffers both for r100 and r200 but tile sized if tiling is used (whatever the
tile size is, seems to be small though, clearly this has to be a micro-tile).
Depth buffer though says 8 pixels for r100 (or tile sized if tiling is enabled,
though on some chips you can't even disable it) and 32 pixels for r200 (though
given the tiling code I have some doubts that's enough for z16). In any case
though I stick to my 128byte recommendation for r200 depth buffers...

-- 
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/20150801/009caeec/attachment.html>

[Bug 91516] Hang on Dota 2 Reborn with Unsafe Math

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

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

--- Comment #2 from sarnex  ---
Created attachment 117477
  --> https://bugs.freedesktop.org/attachment.cgi?id=117477=edit
log without commit

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

[Bug 91516] Hang on Dota 2 Reborn with Unsafe Math

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

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

--- Comment #1 from sarnex  ---
Created attachment 117476
  --> https://bugs.freedesktop.org/attachment.cgi?id=117476=edit
log with commit

i had to trim to final 50k lines for both because of fdo file size

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

[Bug 91516] Hang on Dota 2 Reborn with Unsafe Math

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

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

Bug ID: 91516
   Summary: Hang on Dota 2 Reborn with Unsafe Math
   Product: Mesa
   Version: unspecified
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: commendsarnex at gmail.com
QA Contact: dri-devel at lists.freedesktop.org

Hi guys,

I get a hang with commit "gallium/radeon: re-enable unsafe math for graphics
shaders."

I've attached R600_DEBUG=ps,vs with and without this commit.

I'm using llvm git and kernel 4.1.3


Thanks for your help,
sarnex

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

[Bug 91509] Depth render buffer corruption

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

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

--- Comment #4 from Roland Scheidegger  ---
As a quick hunch based on your observations and some quick look in the code, it
seems depth buffers need to be 128 byte aligned on r200 (and 64 byte on r100
though that's just based on the tile/untile code), but
radeon_alloc_renderbuffer_storage() only does it to 64 bytes: (pitch = ((cpp *
width + 63) & ~63) / cpp;)
Could you try out if increasing that to 128 byte alignment there would help?
For the heck of it I can't figure out though from where the window
depth/colorbuffers get their alignment, so I've no idea how that's calculated
there...
Not sure right now on color buffers neither...

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