[Bug 104806] plasmashell and other KDE binaries start to segfault after updating Mesa to 18.0.0 (radeon)

[bugzilla-daemon]

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

Mike Lothian  changed:

   What|Removed |Added

 CC||m...@fireburn.co.uk

--- Comment #3 from Mike Lothian  ---
I think this might be a duplicate of Bug 104762, which is fixed in master

Does deleting the shader caches work around the issue for you?

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

[Bug 104817] [Raven][GALLIUM_DDEBUG] system crashes/freezes randomly every few minutes/hours

[bugzilla-daemon]

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

--- Comment #3 from Marcus Husar  ---
Created attachment 137003
  --> https://bugs.freedesktop.org/attachment.cgi?id=137003=edit
kernel: amdgpu [gfxhub] VMC page fault (2)

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

[Bug 104817] [Raven][GALLIUM_DDEBUG] system crashes/freezes randomly every few minutes/hours

[bugzilla-daemon]

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

--- Comment #2 from Marcus Husar  ---
Created attachment 137002
  --> https://bugs.freedesktop.org/attachment.cgi?id=137002=edit
kernel: amdgpu [gfxhub] VMC page fault (1)

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

[Bug 104817] [Raven][GALLIUM_DDEBUG] system crashes/freezes randomly every few minutes/hours

[bugzilla-daemon]

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

--- Comment #1 from Marcus Husar  ---
Created attachment 137001
  --> https://bugs.freedesktop.org/attachment.cgi?id=137001=edit
kernel: [drm:amdgpu_job_timedout [amdgpu]]

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

[Bug 104817] [Raven][GALLIUM_DDEBUG] system crashes/freezes randomly every few minutes/hours

[bugzilla-daemon]

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

Bug ID: 104817
   Summary: [Raven][GALLIUM_DDEBUG] system crashes/freezes
randomly every few minutes/hours
   Product: Mesa
   Version: git
  Hardware: All
OS: Linux (All)
Status: NEW
  Severity: critical
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: marcus.hu...@gmail.com
QA Contact: dri-devel@lists.freedesktop.org

Created attachment 137000
  --> https://bugs.freedesktop.org/attachment.cgi?id=137000=edit
GALLIUM_DDEBUG: folder ddebug_dumps with multiple dumps

OpenGL renderer string: AMD RAVEN (DRM 3.23.0 / 4.16.0-2.fc27.x86_64, LLVM
6.0.0)

My system is an Acer SF315-41 (Ryzen Mobile 5 2500U) with Fedora 27, Kernel
4.16-drm-next (based on 4.15-rc8), LLVM 6.0.0-rc1, Mesa 18.0.0-rc2.

I can reproduce these crashes from kernel-4.15-rcX/mesa-17.3/llvm5 to
kernel-4.16-drm-next/mesa-18-rc2/llvm6-rc1 and in between. They mostly appear
while watching videos (firefox/totem), switching tabs in firefox, resizing
windows (gnome-shell) or gaming.

With amdgpu.lockup_timeout=2000 and amdgpu.GALLIUM_DDEBUG=2000 I was able to
gather lots of dumps within a few minutes (see attachment). As you can see in
the dumps the GPU lockup results sometimes in a CPU lockup (kernel bluetooth
deadlock) as a result of gnome shell’s complete freezing. I can reproduce
amdgpu crashes also with an USB mouse and bluetooth disabled.

Not very often I can find some kernel errors in the logfiles that result from a
crash. I’ll attach the few I found in the last two weeks.

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

[Bug 101442] Piglit shaders@ssa@fs-if-def-else-break fails with sb but passes with R600_DEBUG=nosb

[bugzilla-daemon]

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

--- Comment #7 from Gert Wollny  ---
Created attachment 136996
  --> https://bugs.freedesktop.org/attachment.cgi?id=136996=edit
Test that doesn't fail

Here the break is in the if path and other then ELSE the JUMP instruction
doesn't get optimized away. Since the ELSE clause contains an ALU clause it
also doesn't get optimized away.

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

[Bug 101442] Piglit shaders@ssa@fs-if-def-else-break fails with sb but passes with R600_DEBUG=nosb

[bugzilla-daemon]

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

--- Comment #6 from Gert Wollny  ---
Created attachment 136995
  --> https://bugs.freedesktop.org/attachment.cgi?id=136995=edit
Test that fails with r600/sb

Other then in the fs-if-def-else-break piglit here the if path doesn't get
completely optimized away.

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

[Bug 101442] Piglit shaders@ssa@fs-if-def-else-break fails with sb but passes with R600_DEBUG=nosb

[bugzilla-daemon]

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

--- Comment #5 from Gert Wollny  ---
With a bit more digging I found out that the sb optimizer simply drops the ELSE
if no ALU instructions are found in the else branch, i.e. 

   while(cond1)
  if (cond2) {
  a = b + c; 
  } else {
  break; 
  }
   }

becomes 

   while(cond1)
  if (cond2) {
 a = b + c; 
 break; 
   }
}

after the first sb/dce_cleanup pass, and this is obviously wrong. With the
break in the if path this is not a problem. I'll attach two piglits that
illustrate the behaviour.

-- 
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: [RFC v3 1/4] drm/nouveau: Add support for basic clockgating on Kepler1

[Martin Peres]

On 26/01/18 22:59, Lyude Paul wrote:
> This adds support for enabling automatic clockgating on nvidia GPUs for
> Kepler1. While this is not technically a clockgating level, it does
> enable clockgating using the clockgating values initially set by the
> vbios (which should be safe to use).
> 
> This introduces two therm helpers for controlling basic clockgating:
>   nvkm_therm_clkgate_enable() - enables clockgating through
>   CG_CTRL, done after initializing the GPU fully
>   nvkm_therm_clkgate_fini() - prepares clockgating for suspend or
>   driver unload
> 
> As well, we add the nouveau kernel config parameter NvPmEnableGating,
> which can be toggled on or off in order to enable/disable clockgating.
> Since we've only had limited testing on this thus far, we disable this
> by default.
> 
> A lot of this code was originally going to be based off of fermi;
> however it turns out that while Fermi's the first line of GPUs that
> introduced this kind of power saving, Fermi requires more fine tuned
> control of the CG_CTRL registers from the driver while reclocking that
> we don't entirely understand yet.
> 
> For the simple parts we will be sharing with Fermi for certain however,
> we at least add those into a new subdev/therm/gf100.h header.
> 
> Signed-off-by: Lyude Paul 
> ---
>  .../gpu/drm/nouveau/include/nvkm/subdev/therm.h|   5 +
>  drivers/gpu/drm/nouveau/nvkm/engine/device/base.c  |  17 +--
>  drivers/gpu/drm/nouveau/nvkm/subdev/therm/Kbuild   |   1 +
>  drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.c   |  60 +++--
>  drivers/gpu/drm/nouveau/nvkm/subdev/therm/gf100.h  |  35 ++
>  drivers/gpu/drm/nouveau/nvkm/subdev/therm/gf119.c  |   8 +-
>  drivers/gpu/drm/nouveau/nvkm/subdev/therm/gk104.c  | 135 
> +
>  drivers/gpu/drm/nouveau/nvkm/subdev/therm/gk104.h  |  48 
>  drivers/gpu/drm/nouveau/nvkm/subdev/therm/priv.h   |  15 ++-
>  9 files changed, 303 insertions(+), 21 deletions(-)
>  create mode 100644 drivers/gpu/drm/nouveau/nvkm/subdev/therm/gf100.h
>  create mode 100644 drivers/gpu/drm/nouveau/nvkm/subdev/therm/gk104.c
>  create mode 100644 drivers/gpu/drm/nouveau/nvkm/subdev/therm/gk104.h
> 
> diff --git a/drivers/gpu/drm/nouveau/include/nvkm/subdev/therm.h 
> b/drivers/gpu/drm/nouveau/include/nvkm/subdev/therm.h
> index b1ac47eb786e..240b19bb4667 100644
> --- a/drivers/gpu/drm/nouveau/include/nvkm/subdev/therm.h
> +++ b/drivers/gpu/drm/nouveau/include/nvkm/subdev/therm.h
> @@ -85,17 +85,22 @@ struct nvkm_therm {
>  
>   int (*attr_get)(struct nvkm_therm *, enum nvkm_therm_attr_type);
>   int (*attr_set)(struct nvkm_therm *, enum nvkm_therm_attr_type, int);
> +
> + bool clkgating_enabled;
>  };
>  
>  int nvkm_therm_temp_get(struct nvkm_therm *);
>  int nvkm_therm_fan_sense(struct nvkm_therm *);
>  int nvkm_therm_cstate(struct nvkm_therm *, int, int);
> +void nvkm_therm_clkgate_enable(struct nvkm_therm *);
> +void nvkm_therm_clkgate_fini(struct nvkm_therm *, bool);
>  
>  int nv40_therm_new(struct nvkm_device *, int, struct nvkm_therm **);
>  int nv50_therm_new(struct nvkm_device *, int, struct nvkm_therm **);
>  int g84_therm_new(struct nvkm_device *, int, struct nvkm_therm **);
>  int gt215_therm_new(struct nvkm_device *, int, struct nvkm_therm **);
>  int gf119_therm_new(struct nvkm_device *, int, struct nvkm_therm **);
> +int gk104_therm_new(struct nvkm_device *, int, struct nvkm_therm **);
>  int gm107_therm_new(struct nvkm_device *, int, struct nvkm_therm **);
>  int gm200_therm_new(struct nvkm_device *, int, struct nvkm_therm **);
>  int gp100_therm_new(struct nvkm_device *, int, struct nvkm_therm **);
> diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c 
> b/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
> index 08e77cd55e6e..74bd09b1c893 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
> @@ -28,6 +28,7 @@
>  #include 
>  
>  #include 
> +#include 
>  
>  static DEFINE_MUTEX(nv_devices_mutex);
>  static LIST_HEAD(nv_devices);
> @@ -1682,7 +1683,7 @@ nve4_chipset = {
>   .mxm = nv50_mxm_new,
>   .pci = gk104_pci_new,
>   .pmu = gk104_pmu_new,
> - .therm = gf119_therm_new,
> + .therm = gk104_therm_new,
>   .timer = nv41_timer_new,
>   .top = gk104_top_new,
>   .volt = gk104_volt_new,
> @@ -1721,7 +1722,7 @@ nve6_chipset = {
>   .mxm = nv50_mxm_new,
>   .pci = gk104_pci_new,
>   .pmu = gk104_pmu_new,
> - .therm = gf119_therm_new,
> + .therm = gk104_therm_new,
>   .timer = nv41_timer_new,
>   .top = gk104_top_new,
>   .volt = gk104_volt_new,
> @@ -1760,7 +1761,7 @@ nve7_chipset = {
>   .mxm = nv50_mxm_new,
>   .pci = gk104_pci_new,
>   .pmu = gk104_pmu_new,
> - .therm = gf119_therm_new,
> + .therm = gk104_therm_new,
>   .timer = nv41_timer_new,
>   .top = gk104_top_new,
>   .volt = gk104_volt_new,
> @@ -1824,7 +1825,7 @@ 

Re: [RFC v3 2/4] drm/nouveau: Add support for BLCG on Kepler1

[Martin Peres]

On 26/01/18 22:59, Lyude Paul wrote:
> This enables BLCG optimization for kepler1. When using clockgating,
> nvidia's firmware has a set of registers which are initially programmed
> by the vbios with various engine delays and other mysterious settings
> that are safe enough to bring up the GPU. However, the values used by
> the vbios are more power hungry then they need to be, so the nvidia driver

then -> than.

With the comment about not exposing clock gating until patch 2, 3, and 4
have landed addressed, the series is:

Reviewed-by: Martin Peres 

Thanks a lot! I really like how this turned out :)

> writes it's own more optimized set of BLCG settings before enabling
> CG_CTRL. This adds support for programming the optimized BLCG values
> during engine/subdev init, which enables rather significant power
> savings.
> 
> This introduces the nvkm_therm_clkgate_init() helper, which we use to
> program the optimized BLCG settings before enabling clockgating with
> nvkm_therm_clkgate_enable.
> 
> As well, this commit shares a lot more code with Fermi since BLCG is
> mostly the same there as far as we can tell. In the future, it's likely
> we'll reformat the clkgate_packs for kepler1 so that they share a list
> of mmio packs with Fermi.
> 
> Signed-off-by: Lyude Paul 
> ---
>  .../gpu/drm/nouveau/include/nvkm/subdev/therm.h|  12 ++
>  drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.h |   1 +
>  drivers/gpu/drm/nouveau/nvkm/engine/gr/gk104.c | 207 
> +
>  drivers/gpu/drm/nouveau/nvkm/engine/gr/gk104.h |  55 ++
>  drivers/gpu/drm/nouveau/nvkm/subdev/fb/gf100.c |   6 +
>  drivers/gpu/drm/nouveau/nvkm/subdev/fb/gk104.c |  47 +
>  drivers/gpu/drm/nouveau/nvkm/subdev/fb/gk104.h |  35 
>  drivers/gpu/drm/nouveau/nvkm/subdev/fb/priv.h  |   2 +
>  drivers/gpu/drm/nouveau/nvkm/subdev/therm/Kbuild   |   1 +
>  drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.c   |  10 +
>  drivers/gpu/drm/nouveau/nvkm/subdev/therm/gf100.c  |  75 
>  drivers/gpu/drm/nouveau/nvkm/subdev/therm/gk104.c  |   1 +
>  drivers/gpu/drm/nouveau/nvkm/subdev/therm/gt215.c  |   2 +-
>  drivers/gpu/drm/nouveau/nvkm/subdev/therm/priv.h   |   8 +
>  14 files changed, 461 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/gpu/drm/nouveau/nvkm/engine/gr/gk104.h
>  create mode 100644 drivers/gpu/drm/nouveau/nvkm/subdev/fb/gk104.h
>  create mode 100644 drivers/gpu/drm/nouveau/nvkm/subdev/therm/gf100.c
> 
> diff --git a/drivers/gpu/drm/nouveau/include/nvkm/subdev/therm.h 
> b/drivers/gpu/drm/nouveau/include/nvkm/subdev/therm.h
> index 240b19bb4667..9398d9f09339 100644
> --- a/drivers/gpu/drm/nouveau/include/nvkm/subdev/therm.h
> +++ b/drivers/gpu/drm/nouveau/include/nvkm/subdev/therm.h
> @@ -46,6 +46,16 @@ enum nvkm_therm_attr_type {
>   NVKM_THERM_ATTR_THRS_SHUTDOWN_HYST = 17,
>  };
>  
> +struct nvkm_therm_clkgate_init {
> + u32 addr;
> + u8  count;
> + u32 data;
> +};
> +
> +struct nvkm_therm_clkgate_pack {
> + const struct nvkm_therm_clkgate_init *init;
> +};
> +
>  struct nvkm_therm {
>   const struct nvkm_therm_func *func;
>   struct nvkm_subdev subdev;
> @@ -92,6 +102,8 @@ struct nvkm_therm {
>  int nvkm_therm_temp_get(struct nvkm_therm *);
>  int nvkm_therm_fan_sense(struct nvkm_therm *);
>  int nvkm_therm_cstate(struct nvkm_therm *, int, int);
> +void nvkm_therm_clkgate_init(struct nvkm_therm *,
> +  const struct nvkm_therm_clkgate_pack *);
>  void nvkm_therm_clkgate_enable(struct nvkm_therm *);
>  void nvkm_therm_clkgate_fini(struct nvkm_therm *, bool);
>  
> diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.h 
> b/drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.h
> index d7c2adb9b543..c8ec3fd97155 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.h
> +++ b/drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.h
> @@ -137,6 +137,7 @@ struct gf100_gr_func {
>   int (*rops)(struct gf100_gr *);
>   int ppc_nr;
>   const struct gf100_grctx_func *grctx;
> + const struct nvkm_therm_clkgate_pack *clkgate_pack;
>   struct nvkm_sclass sclass[];
>  };
>  
> diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/gr/gk104.c 
> b/drivers/gpu/drm/nouveau/nvkm/engine/gr/gk104.c
> index 5e82f94c2245..17cea9c70f7f 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/engine/gr/gk104.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/engine/gr/gk104.c
> @@ -22,6 +22,7 @@
>   * Authors: Ben Skeggs 
>   */
>  #include "gf100.h"
> +#include "gk104.h"
>  #include "ctxgf100.h"
>  
>  #include 
> @@ -173,6 +174,208 @@ gk104_gr_pack_mmio[] = {
>   {}
>  };
>  
> +const struct nvkm_therm_clkgate_init
> +gk104_clkgate_blcg_init_main_0[] = {
> + { 0x4041f0, 1, 0x4046 },
> + { 0x409890, 1, 0x0045 },
> + { 0x4098b0, 1, 0x007f },
> + {}
> +};
> +
> +const struct nvkm_therm_clkgate_init
> +gk104_clkgate_blcg_init_rstr2d_0[] = {
> + { 0x4078c0, 1, 0x0042 },
> 

[Bug 104806] plasmashell and other KDE binaries start to segfault after updating Mesa to 18.0.0 (radeon)

[bugzilla-daemon]

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

--- Comment #2 from Alexandr Paliy  ---
Also gentoo, also radeon card (r600).

Posting this just to confirm there is an issue. Can't provide additional info
because I needed to restore access to my PC as fast as possible.

dmesg pointed segfaults in plasmashell and sddm-helper processes.
First I thought it is somehow related to updating kernel 4.14.12->4.14.15, but
reverting it did not help.

Then, I saw mentions of r600g_dri.so
Switched from mesa-18.0.0-rc2 to mesa-17.3.3, and issue is gone.

-- 
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] drm/radeon: adjust tested variable

[Julia Lawall]

Check the variable that was most recently initialized.

The semantic match that finds this problem is as follows:
(http://coccinelle.lip6.fr/)

// 
@@
expression x, y, f, g, e, m;
statement S1,S2,S3,S4;
@@

x = f(...);
if (\(<+...x...+>\\)) S1 else S2
(
x = g(...);
|
m = g(...,,...);
|
y = g(...);
*if (e)
 S3 else S4
)
// 

Signed-off-by: Julia Lawall 

---
 drivers/gpu/drm/radeon/radeon_uvd.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/radeon_uvd.c 
b/drivers/gpu/drm/radeon/radeon_uvd.c
index d34d1cf..95f4db7 100644
--- a/drivers/gpu/drm/radeon/radeon_uvd.c
+++ b/drivers/gpu/drm/radeon/radeon_uvd.c
@@ -995,7 +995,7 @@ int radeon_uvd_calc_upll_dividers(struct radeon_device 
*rdev,
/* calc dclk divider with current vco freq */
dclk_div = radeon_uvd_calc_upll_post_div(vco_freq, dclk,
 pd_min, pd_even);
-   if (vclk_div > pd_max)
+   if (dclk_div > pd_max)
break; /* vco is too big, it has to stop */
 
/* calc score with current vco freq */

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

Re: [PATCH] drm/i915: Fix DSI panels with v1 MIPI sequences without a DEASSERT sequence v2

[Hans de Goede]

Hi,

On 26-01-18 17:38, Ville Syrjälä wrote:

On Fri, Jan 26, 2018 at 08:52:07AM +0100, Hans de Goede wrote:

So far models of the Dell Venue 8 Pro, with a panel with MIPI panel
index = 3, one of which has been kindly provided to me by Jan Brummer,
where not working with the i915 driver, giving a black screen on the
first modeset.

The problem with at least these Dells is that their VBT defines a MIPI
ASSERT sequence, but not a DEASSERT sequence. Instead they DEASSERT the
reset in their INIT_OTP sequence, but the deassert must be done before
calling intel_dsi_device_ready(), so that is too late.

Simply doing the INIT_OTP sequence earlier is not enough to fix this,
because the INIT_OTP sequence also sends various MIPI packets to the
panel, which can only happen after calling intel_dsi_device_ready().

This commit fixes this by splitting the INIT_OTP sequence into everything
before the first DSI packet and everything else, including the first DSI
packet. The first part (everything before the first DSI packet) is then
used as deassert sequence.

Changed in v2:
-Split the init OTP sequence into a deassert reset and the actual init
  OTP sequence, instead of calling it earlier and then having the first
  mipi_exec_send_packet() call call intel_dsi_device_ready().

BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=82880
Related: https://bugs.freedesktop.org/show_bug.cgi?id=101205
Cc: Jan-Michael Brummer 
Reported-by: Jan-Michael Brummer 
Tested-by: Hans de Goede 
Signed-off-by: Hans de Goede 
---
  drivers/gpu/drm/i915/intel_dsi.c |  1 +
  drivers/gpu/drm/i915/intel_dsi.h |  2 +
  drivers/gpu/drm/i915/intel_dsi_vbt.c | 82 
  3 files changed, 85 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index f67d321376e4..b59ef34d25f6 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -1642,6 +1642,7 @@ static void intel_dsi_encoder_destroy(struct drm_encoder 
*encoder)
if (intel_dsi->gpio_panel)
gpiod_put(intel_dsi->gpio_panel);
  
+	kfree(intel_dsi->deassert_seq);

intel_encoder_destroy(encoder);
  }
  
diff --git a/drivers/gpu/drm/i915/intel_dsi.h b/drivers/gpu/drm/i915/intel_dsi.h

index 7afeb9580f41..5895588144ad 100644
--- a/drivers/gpu/drm/i915/intel_dsi.h
+++ b/drivers/gpu/drm/i915/intel_dsi.h
@@ -46,6 +46,8 @@ struct intel_dsi {
  
  	struct intel_connector *attached_connector;
  
+	u8 *deassert_seq;

+


Should this perhaps live next to the other DSI VBT stuff? I think that
might make more sense. And should probably also move the
intel_dsi_fixup_dsi_sequences() call to parse_mipi_sequence() as well
since we're actually modifying dev_priv->vbt.data. Doing that from the
encoder init doesn't really feel right to me.


Sure works for me, shall I submit a v3 with this changed, or do you
want to wait a bit for Jani's input on this?


Jani, any thoughts?


/* bit mask of ports being driven */
u16 ports;
  
diff --git a/drivers/gpu/drm/i915/intel_dsi_vbt.c b/drivers/gpu/drm/i915/intel_dsi_vbt.c

index 91c07b0c8db9..84664f79cbef 100644
--- a/drivers/gpu/drm/i915/intel_dsi_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_vbt.c
@@ -499,6 +499,86 @@ int intel_dsi_vbt_get_modes(struct intel_dsi *intel_dsi)
return 1;
  }
  
+/*

+ * Get len of pre-fixed deassert from init OTP, skip all delay + gpio operands
+ * and stop at the first DSI packet op.
+ */
+static int intel_vbi_get_deassert_len(const u8 *data, int total)
+{
+   int index, len;


if (WARN_ON(seq_version != 1))
return 0;

or something might be nice here to document the requirements and
to deter anyone from using this with other seq versions.


Ok, will add for v3.


+
+   /* index = 1 to skip sequence byte */
+   for (index = 1; index < total; index += len) {
+   switch (data[index]) {
+   case MIPI_SEQ_ELEM_SEND_PKT:
+   return index;


What if this is the first element?


Ah good one, I did not think about that.


Hmm. It does seem to work out in the end. We do end up with
an empty deassert sequence, but I guess hat's fine.


Ack, lets keep it as is then.


+   case MIPI_SEQ_ELEM_DELAY:
+   len = 5; /* 1 byte for operand + uint32 */
+   break;
+   case MIPI_SEQ_ELEM_GPIO:
+   len = 3; /* 1 byte for op, 1 for gpio_nr, 1 for value */
+   break;
+   default:
+   return 0;
+   }
+   }
+
+   return 0;
+}
+
+/*
+ * Some v1 VBT MIPI sequences do the deassert in the init OTP sequence.
+ * The deassert must be done before calling intel_dsi_device_ready, so for
+ * these devices we split the init OTP sequence into a deassert sequence and
+ * the actual init OTP part.
+ */
+static void 

[Bug 104808] [mesa 18.0.0-rc2][bisected] Radeonsi doesn’t work correctly in wayland session (gnome-shell)

[bugzilla-daemon]

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

--- Comment #1 from Marcus Husar  ---
Some additional information:
OpenGL renderer string: AMD RAVEN (DRM 3.23.0 / 4.16.0-2.fc27.x86_64, LLVM
6.0.0

My system is an Acer SF315-41 (Ryzen Mobile 5 2500U) with Fedora 27, Kernel
4.16-drm-next (based on 4.15-rc8), LLVM 6.0.0-rc1, Mesa 18.0.0-rc2.

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

[Bug 104808] [mesa 18.0.0-rc2][bisected] Radeonsi doesn’t work correctly in wayland session (gnome-shell)

[bugzilla-daemon]

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

Bug ID: 104808
   Summary: [mesa 18.0.0-rc2][bisected] Radeonsi doesn’t work
correctly in wayland session (gnome-shell)
   Product: Mesa
   Version: git
  Hardware: All
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: marcus.hu...@gmail.com
QA Contact: dri-devel@lists.freedesktop.org

In a gnome-shell wayland session I’m not able to perform a single mouse click.

I bisected this bug to commit e5ff036c6751c39ee008ca7db47b3ce4d7a38a15 (st/dri:
Add support for BGR[A/X]1010102 formats.).

After reverting commits 2d8e1a6a277cb1684d76210351147f5e7858c8b2 (child commit)
and e5ff036c6751c39ee008ca7db47b3ce4d7a38a15 I can perform mouse clicks again.

commit 2d8e1a6a277cb1684d76210351147f5e7858c8b2
st/dri: Add option to control exposure of 10 bpc color configs.
   
https://cgit.freedesktop.org/mesa/mesa/commit/?id=2d8e1a6a277cb1684d76210351147f5e7858c8b2

commit e5ff036c6751c39ee008ca7db47b3ce4d7a38a15
st/dri: Add support for BGR[A/X]1010102 formats.
   
https://cgit.freedesktop.org/mesa/mesa/commit/?id=e5ff036c6751c39ee008ca7db47b3ce4d7a38a15

Range of logs in mesa git:
https://cgit.freedesktop.org/mesa/mesa/log/?qt=range=2d8e1a6a277cb1684d76210351147f5e7858c8b2

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

[Bug 104806] plasmashell and other KDE binaries start to segfault after updating Mesa to 18.0.0 (radeon)

[bugzilla-daemon]

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

Andrei Slavoiu  changed:

   What|Removed |Added

 CC||ansl...@yahoo.com

--- Comment #1 from Andrei Slavoiu  ---
Created attachment 136988
  --> https://bugs.freedesktop.org/attachment.cgi?id=136988=edit
bt-full.txt

I can confirm lots of KDE apps and even QT only crash after upgrading to mesa
18.0.0-rc2. This is a stacktrace from qupzilla, a qt browser. Attached is the
same stacktrace but generated with `bt full` so it also shows local variables.

Core was generated by `/usr/bin/qupzilla -session
10ddca766500015164467650008200015_1516586983_963'.
Program terminated with signal SIGABRT, Aborted.
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
51  }
[Current thread is 1 (Thread 0x7f123d18da00 (LWP 1093))]
(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1  0x7f1244f0f4a6 in __GI_abort () at abort.c:90
#2  0x5624818e5b10 in qupzilla_signal_handler (s=) at
main.cpp:54
#3  
#4  __memcpy_ssse3 () at ../sysdeps/x86_64/multiarch/memcpy-ssse3.S:130
#5  0x7f122f9688a4 in memcpy (__len=18130608, __src=0x56248663d6e0,
__dest=) at /usr/include/bits/string_fortified.h:34
#6  tgsi_dup_tokens (tokens=0x56248663d6e0) at
/usr/src/debug/media-libs/mesa-18.0.0_rc2/mesa-18.0.0-rc2/src/gallium/auxiliary/tgsi/tgsi_parse.c:281
#7  0x7f122f7bd12b in st_create_vp_variant (key=0x7ffd79ff0150,
stvp=0x5624865a7170, st=0x5624861904d0) at
/usr/src/debug/media-libs/mesa-18.0.0_rc2/mesa-18.0.0-rc2/src/mesa/state_tracker/st_program.c:579
#8  st_get_vp_variant (st=0x5624861904d0, stvp=0x5624865a7170,
key=0x7ffd79ff0150) at
/usr/src/debug/media-libs/mesa-18.0.0_rc2/mesa-18.0.0-rc2/src/mesa/state_tracker/st_program.c:629
#9  0x7f122f7be215 in st_precompile_shader_variant
(st=st@entry=0x5624861904d0, prog=prog@entry=0x5624865a7170) at
/usr/src/debug/media-libs/mesa-18.0.0_rc2/mesa-18.0.0-rc2/src/mesa/state_tracker/st_program.c:1915
#10 0x7f122f7bf4d2 in st_deserialise_tgsi_program (ctx=0x562486164910,
shProg=0x5624865fe200, prog=0x5624865a7170) at
/usr/src/debug/media-libs/mesa-18.0.0_rc2/mesa-18.0.0-rc2/src/mesa/state_tracker/st_shader_cache.c:279
#11 0x7f122f6e32e9 in read_program_payload (binary_format=34655,
sh_prog=0x5624865fe200, blob=0x7ffd79ff01f0, ctx=0x562486164910) at
/usr/src/debug/media-libs/mesa-18.0.0_rc2/mesa-18.0.0-rc2/src/mesa/main/program_binary.c:206
#12 _mesa_program_binary (ctx=0x562486164910, sh_prog=0x5624865fe200,
binary_format=, binary=0x7f1208378090, length=4085) at
/usr/src/debug/media-libs/mesa-18.0.0_rc2/mesa-18.0.0-rc2/src/mesa/main/program_binary.c:285
#13 0x7f123e965c80 in QOpenGLExtraFunctions::glProgramBinary (length=4085,
binary=0x7f1208378090, binaryFormat=34655, program=4, this=0x562485ccbf90) at
../../src/gui/opengl/qopenglextrafunctions.h:1175
#14 QOpenGLProgramBinaryCache::setProgramBinary (this=this@entry=0x7f123ea6ba80
,
programId=programId@entry=4, blobFormat=blobFormat@entry=34655,
p=p@entry=0x7f1208378090, blobSize=blobSize@entry=4085) at
opengl/qopenglprogrambinarycache.cpp:163
#15 0x7f123e96659f in QOpenGLProgramBinaryCache::load
(this=this@entry=0x7f123ea6ba80
, cacheKey=...,
programId=4) at opengl/qopenglprogrambinarycache.cpp:296
#16 0x7f123e93bd88 in QOpenGLShaderProgramPrivate::linkBinary
(this=this@entry=0x7f11c8162040) at opengl/qopenglshaderprogram.cpp:3825
#17 0x7f123e93c380 in QOpenGLShaderProgram::link (this=0x562486619688) at
opengl/qopenglshaderprogram.cpp:1286
#18 0x7f123cedf528 in QSGDefaultRenderContext::compileShader
(this=this@entry=0x562485f0cad0, shader=shader@entry=0x562486619680,
material=material@entry=0x562485b37150, vertexCode=,
fragmentCode=fragmentCode@entry=0x0) at
scenegraph/qsgdefaultrendercontext.cpp:267
#19 0x7f123cead317 in QSGBatchRenderer::ShaderManager::prepareMaterial
(this=0x562485adb6e0, material=material@entry=0x562485b37150) at
scenegraph/coreapi/qsgbatchrenderer.cpp:157
#20 0x7f123ceadd65 in QSGBatchRenderer::Renderer::renderMergedBatch
(this=0x562485ad99c0, batch=) at
scenegraph/coreapi/qsgbatchrenderer.cpp:2312
#21 0x7f123ceaf255 in QSGBatchRenderer::Renderer::renderBatches
(this=this@entry=0x562485ad99c0) at
scenegraph/coreapi/qsgbatchrenderer.cpp:2569
#22 0x7f123ceb495b in QSGBatchRenderer::Renderer::render (this=) at scenegraph/coreapi/qsgbatchrenderer.cpp:2763
#23 0x7f123cea5640 in QSGRenderer::renderScene (this=0x562485ad99c0,
bindable=...) at scenegraph/coreapi/qsgrenderer.cpp:243
#24 0x7f123cea5b07 in QSGRenderer::renderScene (this=,
fboId=) at scenegraph/coreapi/qsgrenderer.cpp:189
#25 0x7f123cede968 in QSGDefaultRenderContext::renderNextFrame

[Bug 101442] Piglit shaders@ssa@fs-if-def-else-break fails with sb but passes with R600_DEBUG=nosb

[bugzilla-daemon]

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

--- Comment #4 from Gert Wollny  ---
After reviewing the byte code of fs-if-def-else-break  I found that the problem
is a bit different: 

In the original code BREAK is called in the loop when (KC0[0].x != 0) just like
implemented in the glsl code: 

0002  LOOP_START_DX10 @36
0004   ALU_PUSH_BEFORE 2 @48 KC0[CB0:0-15]
 0048  2  x: MOVR2.x,  1
 0050  3 MP   x: PRED_SETNE_INT R6.x,  KC0[0].x, 0
0006   JUMP @10   << JUMP is called if condition fails 
0008   ALU 2 @52
 0052  4  x: MOVR2.x,  [0x0002 2.8026e-45].x
 0054  0002 
0010   ELSE @16 POP:1
0012   LOOP_BREAK @34
0014   POP @16 POP:1

however, in the optimized code the assignment and its branch is optimized away,
and BREAK is called when (KC0[0].x == 0), i.e. exactly the opposite of the 

 0002 LOOP_START_DX10 @30
0004   PUSH @6
0006   ALU 1 @38 KC0[CB0:0-15]
 0038   2 Mx: PRED_SETNE_INT __.x,  KC0[0].x, 0
0008   JUMP @14 POP:1  << JUMP is called if condition fails 
0010   LOOP_BREAK @28
0012   POP @14 POP:1

i.e. the optimizer removed the if branch, keeps the else branch but acts as if
it were the if branch, hence the failure.

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

[Bug 104806] plasmashell and other KDE binaries start to segfault after updating Mesa to 18.0.0 (radeon)

[bugzilla-daemon]

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

Fireball  changed:

   What|Removed |Added

URL||https://bugs.gentoo.org/645
   ||756

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

[Bug 104806] plasmashell and other KDE binaries start to segfault after updating Mesa to 18.0.0 (radeon)

[bugzilla-daemon]

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

Bug ID: 104806
   Summary: plasmashell and other KDE binaries start to segfault
after updating Mesa to 18.0.0 (radeon)
   Product: Mesa
   Version: unspecified
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/r600
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: a...@thurston.ru
QA Contact: dri-devel@lists.freedesktop.org

With Mesa 18.0.0 'plasmashell', 'ksplashqml' and 'kmail' binaries segfault
right after logging in into Plasma session, leaving coredumps behind.

If I downgrade Mesa package back to 17.3.3, everything works again.

I'm running Gentoo.

Video card:
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI]
Caicos [Radeon HD 6450/7450/8450 / R5 230 OEM]

Kernel driver: nouveau
X.Org driver: radeon

Something happens in r600_dri.so:

Core was generated by `/usr/bin/kmail -session
10dcd7cfcb00014784624820156710141_1483955504_762746'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x7f37f999af50 in raise () from /lib64/libc.so.6
[Current thread is 1 (Thread 0x7f37fc86ea40 (LWP 892))]
(gdb) bt
#0  0x7f37f999af50 in raise () from /lib64/libc.so.6
#1  0x7f37fbb9f727 in KCrash::defaultCrashHandler(int) () from
/usr/lib64/libKF5Crash.so.5
#2  
#3  0x7f37f9a0d4f3 in ?? () from /lib64/libc.so.6
#4  0x7f37bb154094 in ?? () from /usr/lib64/dri/r600_dri.so
#5  0x55c4ec9e5de0 in ?? ()
#6  0x55c4ec9d7fe0 in ?? ()
#7  0x55c4ec9e5de0 in ?? ()
#8  0x7f37bb254e2b in ?? () from /usr/lib64/dri/r600_dri.so
#9  0x0003 in ?? ()
#10 0x7fff107efa90 in ?? ()
#11 0x in ?? ()

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

[Bug 103915] Undertale crashes on startup (compiling shaders?)

[bugzilla-daemon]

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

--- Comment #10 from Martin Jørgensen  ---
I've got the same issue with undertale running on AMD POLARIS10 and latest
Debian Testing + liquorix 4.14 kernel. Tried using both Mesa 17.2 and 17.3 from
Debian repos.

My Undertale game crashes on start with a segfault and produces this dmesg:

[98053.492153] si_shader:2[6898]: segfault at 9 ip eef3da0c sp
ec1fc8dc error 4 in libLLVM-5.0.so.1[ee938000+37f2000]

Also, my Hollow Knight game also produces this line, but seems to work despite
of it:

[98117.334979] hollow_knight.x[6938]: segfault at 7f5e52ff53b0 ip
7f5e411d3850 sp 7ffe6ad4cc28 error 4 in
libLLVM-5.0.so.1[7f5e40978000+3245000]

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