[Bug 99710] [amdgpu R9 390] GPU hang when playing Hearthstone in Wine

[bugzilla-daemon]

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

--- Comment #7 from Sandeep  ---
I have the same GPU, and have also started experiencing system hangs since the
past 1-2 months. I believe it may be related to this issue, since it only
occurs when using 3D graphics in some form, either while playing Left 4 Dead 2
or when using the Chromium browser with GPU acceleration enabled. In the case
of Left 4 Dead 2, the system always hangs unpredictably at some point.

I am using the AMDGPU driver, with AMDGPU CIK support enabled.

I tried running 4.13 stable today, and the crash still occurred. I will try
older kernels to see if I am still able to reproduce.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/10] drm/amdgpu: Use ARRAY_SIZE macro

[Thomas Meyer]

Use ARRAY_SIZE macro, rather than explicitly coding some variant of it
yourself.
Found with: find -type f -name "*.c" -o -name "*.h" | xargs perl -p -i -e
's/\bsizeof\s*\(\s*(\w+)\s*\)\s*\ /\s*sizeof\s*\(\s*\1\s*\[\s*0\s*\]\s*\)
/ARRAY_SIZE(\1)/g' and manual check/verification.

Signed-off-by: Thomas Meyer 
---

diff --git a/drivers/gpu/drm/amd/amdgpu/mmhub_v1_0.c 
b/drivers/gpu/drm/amd/amdgpu/mmhub_v1_0.c
index 9804318f3488..7ef84d884714 100644
--- a/drivers/gpu/drm/amd/amdgpu/mmhub_v1_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/mmhub_v1_0.c
@@ -20,6 +20,8 @@
  * OTHER DEALINGS IN THE SOFTWARE.
  *
  */
+#include 
+
 #include "amdgpu.h"
 #include "mmhub_v1_0.h"
 
@@ -268,7 +270,7 @@ const struct pctl_data pctl0_data[] = {
 {0x135, 0x12a810},
 {0x149, 0x7a82c}
 };
-#define PCTL0_DATA_LEN (sizeof(pctl0_data)/sizeof(pctl0_data[0]))
+#define PCTL0_DATA_LEN (ARRAY_SIZE(pctl0_data))
 
 #define PCTL0_RENG_EXEC_END_PTR 0x151
 #define PCTL0_STCTRL_REG_SAVE_RANGE0_BASE  0xa640
@@ -297,7 +299,7 @@ const struct pctl_data pctl1_data[] = {
 {0x1be, 0x17a7dd},
 {0x1d7, 0x12a810}
 };
-#define PCTL1_DATA_LEN (sizeof(pctl1_data)/sizeof(pctl1_data[0]))
+#define PCTL1_DATA_LEN (ARRAY_SIZE(pctl1_data))
 
 #define PCTL1_RENG_EXEC_END_PTR 0x1ea
 #define PCTL1_STCTRL_REG_SAVE_RANGE0_BASE  0xa000
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 3/10] drm/i915/gvt: Use ARRAY_SIZE macro

[Thomas Meyer]

Use ARRAY_SIZE macro, rather than explicitly coding some variant of it
yourself.
Found with: find -type f -name "*.c" -o -name "*.h" | xargs perl -p -i -e
's/\bsizeof\s*\(\s*(\w+)\s*\)\s*\ /\s*sizeof\s*\(\s*\1\s*\[\s*0\s*\]\s*\)
/ARRAY_SIZE(\1)/g' and manual check/verification.

Signed-off-by: Thomas Meyer 
---

diff --git a/drivers/gpu/drm/i915/gvt/vgpu.c b/drivers/gpu/drm/i915/gvt/vgpu.c
index 3deadcbd5a24..7d8035093a1e 100644
--- a/drivers/gpu/drm/i915/gvt/vgpu.c
+++ b/drivers/gpu/drm/i915/gvt/vgpu.c
@@ -30,6 +30,7 @@
  *Bing Niu 
  *
  */
+#include 
 
 #include "i915_drv.h"
 #include "gvt.h"
@@ -115,7 +116,7 @@ int intel_gvt_init_vgpu_types(struct intel_gvt *gvt)
 */
low_avail = gvt_aperture_sz(gvt) - HOST_LOW_GM_SIZE;
high_avail = gvt_hidden_sz(gvt) - HOST_HIGH_GM_SIZE;
-   num_types = sizeof(vgpu_types) / sizeof(vgpu_types[0]);
+   num_types = ARRAY_SIZE(vgpu_types);
 
gvt->types = kzalloc(num_types * sizeof(struct intel_vgpu_type),
 GFP_KERNEL);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 4/10] drm/nouveau/bios/init: Use ARRAY_SIZE macro

[Thomas Meyer]

Use ARRAY_SIZE macro, rather than explicitly coding some variant of it
yourself.
Found with: find -type f -name "*.c" -o -name "*.h" | xargs perl -p -i -e
's/\bsizeof\s*\(\s*(\w+)\s*\)\s*\ /\s*sizeof\s*\(\s*\1\s*\[\s*0\s*\]\s*\)
/ARRAY_SIZE(\1)/g' and manual check/verification.

Signed-off-by: Thomas Meyer 
---

diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c 
b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c
index b58ee99f7bfc..440efa333d6c 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c
@@ -21,6 +21,7 @@
  *
  * Authors: Ben Skeggs
  */
+#include 
 #include 
 #include 
 #include 
@@ -2271,7 +2272,7 @@ static struct nvbios_init_opcode {
[0xaa] = { init_reserved },
 };
 
-#define init_opcode_nr (sizeof(init_opcode) / sizeof(init_opcode[0]))
+#define init_opcode_nr (ARRAY_SIZE(init_opcode))
 
 int
 nvbios_exec(struct nvbios_init *init)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 102500] [polaris10][amd-staging-4.12] GPU fault detected, somethimes lockup

[bugzilla-daemon]

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

--- Comment #9 from Vedran Miletić  ---
(In reply to Dieter Nützel from comment #5)
> (In reply to Dieter Nützel from comment #4)
> > (In reply to Alex Deucher from comment #1)
> > > can you bisect?
> > 
> > Hello all,
> > 
> > I get the same on 'amd-staging-drm-next' since 1. of Sep (kernel build time:
> > 1. Sep 02:14 CEST) update, too. Will go to bisect in the evening.
> > 
> > [  262.462941] amdgpu :01:00.0: GPU fault detected: 146 0x0a023d14
> > [  262.462946] amdgpu :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR  
> > 0x00101540
> > [  262.462949] amdgpu :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_STATUS
> > 0x0903D014
> > [  262.462952] amdgpu :01:00.0: VM fault (0x14, vmid 4) at page 1054016,
> > write from 'SDM1' (0x53
> > 444d31) (61)
> 
> Yes,
> 
> git revert fd8bf087dffc
> 
> commit fd8bf087dffc0bce047c5aea2afcb8f821e48db1
> Author: Christian König 
> Date:   Tue Aug 29 16:14:32 2017 +0200
> 
> drm/amdgpu: bump version for support of local BOs
> 
> Signed-off-by: Christian König 
> Reviewed-by: Felix Kuehling 
> Signed-off-by: Alex Deucher 
> 
> Solve it on 'amd-staging-drm-next', too.

Confirmed fixed by reverting on Vega 10.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/1] drm/amd/powerplay: initialize a variable before using it

[Nicolas Iooss]

Function vega10_apply_state_adjust_rules() only initializes
stable_pstate_sclk_dpm_percentage when
data->registry_data.stable_pstate_sclk_dpm_percentage is not between 1
and 100. The variable is then used to compute stable_pstate_sclk, which
therefore uses an uninitialized value.

Fix this by initializing stable_pstate_sclk_dpm_percentage to
data->registry_data.stable_pstate_sclk_dpm_percentage.

This issue has been found while building the kernel with clang. The
compiler reported a -Wsometimes-uninitialized warning.

Fixes: f83a9991648b ("drm/amd/powerplay: add Vega10 powerplay support (v5)")
Signed-off-by: Nicolas Iooss 
---
 drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
index 197174e562d2..c8d28f78cd47 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
@@ -3043,6 +3043,8 @@ static int vega10_apply_state_adjust_rules(struct 
pp_hwmgr *hwmgr,
 
if (phm_cap_enabled(hwmgr->platform_descriptor.platformCaps,
PHM_PlatformCaps_StablePState)) {
+   stable_pstate_sclk_dpm_percentage =
+   data->registry_data.stable_pstate_sclk_dpm_percentage;
PP_ASSERT_WITH_CODE(
data->registry_data.stable_pstate_sclk_dpm_percentage 
>= 1 &&
data->registry_data.stable_pstate_sclk_dpm_percentage 
<= 100,
-- 
2.14.1

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

[Bug 102517] System hang/freeze Helium Rain

[bugzilla-daemon]

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

bferreira9...@gmail.com changed:

   What|Removed |Added

 OS|other   |Linux (All)

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: DRM Format Modifiers in v4l2

[Daniel Vetter]

On Fri, Sep 1, 2017 at 2:43 PM, Rob Clark  wrote:
> On Fri, Sep 1, 2017 at 3:13 AM, Laurent Pinchart
>  wrote:
>> Hi Nicolas,
>>
>> On Thursday, 31 August 2017 19:12:58 EEST Nicolas Dufresne wrote:
>>> Le jeudi 31 août 2017 à 17:28 +0300, Laurent Pinchart a écrit :
>>> >> e.g. if I have two devices which support MODIFIER_FOO, I could attempt
>>> >> to share a buffer between them which uses MODIFIER_FOO without
>>> >> necessarily knowing exactly what it is/does.
>>> >
>>> > Userspace could certainly set modifiers blindly, but the point of
>>> > modifiers is to generate side effects benefitial to the use case at hand
>>> > (for instance by optimizing the memory access pattern). To use them
>>> > meaningfully userspace would need to have at least an idea of the side
>>> > effects they generate.
>>>
>>> Generic userspace will basically pick some random combination.
>>
>> In that case userspace could set no modifier at all by default (except in the
>> case where unmodified formats are not supported by the hardware, but I don't
>> expect that to be the most common case).
>>
>>> To allow generically picking the optimal configuration we could indeed rely
>>> on the application knowledge, but we could also enhance the spec so that
>>> the order in the enumeration becomes meaningful.
>>
>> I'm not sure how far we should go. I could imagine a system where the API
>> would report capabilities for modifiers (e.g. this modifier lowers the
>> bandwidth, this one enhances the quality, ...), but going in that direction,
>> where do we stop ? In practice I expect userspace to know some information
>> about the hardware, so I'd rather avoid over-engineering the API.
>>
>
> I think in the (hopefully not too) long term, something like
> https://github.com/cubanismo/allocator/ is the way forward.  That
> doesn't quite solve how v4l2 kernel part sorts out w/ corresponding
> userspace .so what is preferable, but at least that is
> compartmentalized to v4l2.. on the gl/vk side of things there will ofc
> be a hardware specific userspace part that knows what it prefers.  For
> v4l2, it probably makes sense to sort out what the userspace level API
> is and work backwards from there, rather than risk trying to design a
> kernel uapi that might turn out to be the wrong thing.

I thought for kms the plan is to make the ordering meaningful, because
it doesn't necessarily match the gl/vk one. E.g. on intel gl would
prefer Y compressed, Y, X, untiled. Whereas display would be Y
compressed, X (much easier to scan out, in many cases allows more
planes to be used), Y (is necessary for 90° rotation), untiled. So if
drm_hwc really wants to use all the planes, it could prioritize the
display over rendering and request X instead of Y tiled.

I think the same would go for v4l.
-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
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 100666] amdgpu coolers never stoping linux

[bugzilla-daemon]

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

Denis Denisov  changed:

   What|Removed |Added

   Priority|medium  |high
   Severity|normal  |major

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel