[Bug 106496] Hung screen at modprobe amdgpu

[bugzilla-daemon]

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

--- Comment #1 from Aaron  ---
Created attachment 139537
  --> https://bugs.freedesktop.org/attachment.cgi?id=139537=edit
kernel config used to build test kernel

-- 
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 106496] Hung screen at modprobe amdgpu

[bugzilla-daemon]

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

Bug ID: 106496
   Summary: Hung screen at modprobe amdgpu
   Product: DRI
   Version: XOrg git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: c...@atamisk.net

Created attachment 139536
  --> https://bugs.freedesktop.org/attachment.cgi?id=139536=edit
dmesg output from a failed attempt to load amdgpu

I currently have an AMD 2400G with Integrated graphics that i am trying to get
to a screen with amdgpu. At the moment, booting up to a VGA console works with
amdgpu blacklisted. When attempting to modprobe amdgpu, the system hangs on the
vga console and the display seems to stop updating. The underlying system seems
unaffected, because blindly typing 'reboot' causes the system to reboot. 

Steps to reproduce: 
1. Use kernel 4.17-rc4, compiled with the attached config. 
2. Blacklist amdgpu in modprobe.conf.d (or else booting to ANY screen will
fail)
3. modprobe amdgpu

Expected result:
-Successful driver load. 

Observed result: 
-See attached dmesg output. 
(It is worth noting that the dmesg attached also shows a nvidia gpu in the pci
bus. This issue is not affected by its presence or absence. This issue has been
tested both ways so far.)

-- 
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 105425] 3D & games produce periodic GPU crashes (Radeon R7 370)

[bugzilla-daemon]

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

--- Comment #70 from MirceaKitsune  ---
(In reply to iive from comment #69)

Just tried mesa_glthread=false RADEON_THREAD=false MESA_DEBUG=flush and got the
same results. The others seem a lot more complex: I might try them later, but
currently I'm very busy and it's difficult to organize myself accordingly. I
wish I had a better way of helping to understand this issue, as I really need
to get it fixed, sadly I feel stuck myself at the moment.

-- 
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 106493] "New game" in stellaris triggers Assertion `rtex->surface.u.legacy.level[level].dcc_fast_clear_size' failed.

[bugzilla-daemon]

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

Mariusz Ceier  changed:

   What|Removed |Added

 Attachment #139529|0   |1
is obsolete||

--- Comment #1 from Mariusz Ceier  ---
Created attachment 139535
  --> https://bugs.freedesktop.org/attachment.cgi?id=139535=edit
Detailed backtrace

Seems like the workaround is to set "Multisample level" option to 0. Any other
value (2,4,8) triggers the assertion.

Attached more detailed backtrace.

-- 
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 106289] mupen64plus segfaults deep inside r300_dri.so

[bugzilla-daemon]

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

--- Comment #1 from Dave Coffin  ---
This bug also crashes "mplayer" but not "mpv".  I compiled mesa 18.0.3 from
source and got a more informative stack trace, though many parameters are still
"optimized out":

r300: DRM version: 2.50.0, Name: ATI RS480, ID: 0x5975, GB: 2, Z: 1
r300: GART size: 509 MB, VRAM size: 128 MB
r300: AA compression RAM: YES, Z compression RAM: YES, HiZ RAM: NO
r300: DRM version: 2.50.0, Name: ATI RS480, ID: 0x5975, GB: 2, Z: 1
r300: GART size: 509 MB, VRAM size: 128 MB
r300: AA compression RAM: YES, Z compression RAM: YES, HiZ RAM: NO
Core: Setting 32-bit video mode: 640x480
r300: DRM version: 2.50.0, Name: ATI RS480, ID: 0x5975, GB: 2, Z: 1
r300: GART size: 509 MB, VRAM size: 128 MB
r300: AA compression RAM: YES, Z compression RAM: YES, HiZ RAM: NO
r300: DRM version: 2.50.0, Name: ATI RS480, ID: 0x5975, GB: 2, Z: 1
r300: GART size: 509 MB, VRAM size: 128 MB
r300: AA compression RAM: YES, Z compression RAM: YES, HiZ RAM: NO
Video Warning: Failed to set GL_SWAP_CONTROL to 0. (it's 24)
Video Warning: Failed to set GL_BUFFER_SIZE to 32. (it's 24)
Video Warning: Failed to set GL_DEPTH_SIZE to 16. (it's 24)
Video: Using OpenGL: X.Org R300 Project - ATI RS480 : 2.1 Mesa 18.0.3

Thread 1 "mupen64plus" received signal SIGSEGV, Segmentation fault.
0xb4c12200 in ?? ()
(gdb) where
#0  0xb4c12200 in ?? ()
#1  0xb35b5bfb in llvm_pipeline_generic (middle=0x6964c0,
middle@entry=0x64aa80, 
fetch_info=fetch_info@entry=0xbffb688c,
in_prim_info=in_prim_info@entry=0xbffb689c)
at draw/draw_pt_fetch_shade_pipeline_llvm.c:400
#2  0xb35b62af in llvm_middle_end_linear_run (middle=0x64aa80, start=0,
count=, 
prim_flags=0) at draw/draw_pt_fetch_shade_pipeline_llvm.c:553
#3  0xb34b04db in vsplit_segment_simple_linear (vsplit=0x648420,
vsplit=0x648420, icount=4, istart=0, 
flags=0) at draw/draw_pt_vsplit_tmp.h:226
#4  vsplit_run_linear (frontend=0x648420, start=0, count=4) at
draw/draw_split_tmp.h:60
#5  0xb34a8140 in draw_pt_arrays (draw=draw@entry=0x552810, prim=6, start=0,
count=4)
at draw/draw_pt.c:149
#6  0xb34a8677 in draw_vbo (draw=, info=) at
draw/draw_pt.c:564
#7  0xb35e41bb in r300_swtcl_draw_vbo (pipe=0x5124f0, info=0xbffb6a70) at
r300_render.c:862
#8  0xb34f3fd6 in util_draw_arrays_instanced (mode=PIPE_PRIM_TRIANGLE_FAN,
start=0, count=4, 
start_instance=0, instance_count=1, pipe=0x5124f0) at ./util/u_draw.h:106
#9  blitter_draw (ctx=, vertex_elements_cso=, 
get_vs=0xb34f3790 , x1=0, y1=0, x2=640, y2=480,
depth=1, num_instances=1)
at util/u_blitter.c:1257
#10 0xb34f4176 in util_blitter_draw_rectangle (blitter=, 
vertex_elements_cso=, get_vs=, x1=, 
y1=, x2=, y2=480, depth=1, num_instances=1, 
type=UTIL_BLITTER_ATTRIB_NONE, attrib=0xbffb6ba4) at util/u_blitter.c:1291
#11 0xb35e63f5 in r300_blitter_draw_rectangle (blitter=0x528760,
vertex_elements_cso=0x682830, 
get_vs=0xb34f3790 , x1=0, y1=0, x2=640, y2=480,
depth=1, num_instances=1, 
type=UTIL_BLITTER_ATTRIB_NONE, attrib=0xbffb6ba4) at r300_render.c:1139
#12 0xb34f6dc7 in util_blitter_clear_custom (blitter=0x528760, width=640,
height=480, num_layers=1, 
clear_buffers=1, color=0x628634, depth=1, stencil=0, custom_dsa=0x0,
custom_blend=0x0)
at util/u_blitter.c:1411
#13 0xb34f6f33 in util_blitter_clear (blitter=, width=, 
height=, num_layers=,
clear_buffers=, 
color=, depth=, stencil=0) at
util/u_blitter.c:1428
#14 0xb35d828e in r300_clear (pipe=0x5124f0, buffers=1, color=0x628634,
depth=1, stencil=0)
at r300_blit.c:368
#15 0xb329d564 in st_Clear (ctx=, mask=)
at state_tracker/st_cb_clear.c:483
#16 0xb30d455c in clear (no_error=false, mask=, ctx=0x627140) at
main/clear.c:221
#17 _mesa_Clear (mask=) at main/clear.c:242
#18 0xb4ca782d in ?? () from
/usr/lib/i386-linux-gnu/mupen64plus/mupen64plus-video-rice.so
#19 0xb4c93574 in ?? () from
/usr/lib/i386-linux-gnu/mupen64plus/mupen64plus-video-rice.so
#20 0xb4c81475 in RomOpen () from
/usr/lib/i386-linux-gnu/mupen64plus/mupen64plus-video-rice.so
#21 0xb6406c0c in ?? () from /usr/lib/i386-linux-gnu/libmupen64plus.so.2
#22 0xb6407618 in CoreDoCommand () from
/usr/lib/i386-linux-gnu/libmupen64plus.so.2
#23 0x00402d50 in main ()

-- 
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 105684] Loading amdgpu hits general protection fault: 0000 [#1] SMP NOPTI

[bugzilla-daemon]

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

--- Comment #29 from Aaron  ---
Created attachment 139530
  --> https://bugs.freedesktop.org/attachment.cgi?id=139530=edit
Arch current default kernel config

-- 
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 105684] Loading amdgpu hits general protection fault: 0000 [#1] SMP NOPTI

[bugzilla-daemon]

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

--- Comment #28 from Aaron  ---
I am getting this issue on the default kernel configuration for Arch Linux as
well as my 4.17 rc build. I'll attach both configs.

-- 
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 106493] "New game" in stellaris triggers Assertion `rtex->surface.u.legacy.level[level].dcc_fast_clear_size' failed.

[bugzilla-daemon]

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

Bug ID: 106493
   Summary: "New game" in stellaris triggers Assertion
`rtex->surface.u.legacy.level[level].dcc_fast_clear_si
ze' failed.
   Product: Mesa
   Version: git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: mceier+freedesk...@gmail.com
QA Contact: dri-devel@lists.freedesktop.org

Created attachment 139529
  --> https://bugs.freedesktop.org/attachment.cgi?id=139529=edit
Backtrace

Stellaris triggers assertion when clicking on "New game" and mesa is built in
debug mode:

stellaris:
/var/tmp/portage/media-libs/mesa-/work/mesa-/src/gallium/drivers/radeonsi/si_clear.c:256:
vi_dcc_clear_level: Assertion
`rtex->surface.u.legacy.level[level].dcc_fast_clear_size' failed.


The comment above the assertion says:

/* If this is 0, fast clear isn't possible. (can occur with MSAA) */



if it can occur with MSAA should it really be an assertion ?

I have Radeon Fury X.

Attaching backtrace.

-- 
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: [PATCH] drm: Fix render node numbering regression from control node removal.

[Daniel Vetter]

On Tue, May 08, 2018 at 05:14:25PM -0700, Eric Anholt wrote:
> drm_minor_alloc() does multiplication on this enum, so the removal
> ended up moving render nodes down from 128 base to 64.  This caused
> Mesa's surfaceless backend to be unable to open the render nodes,
> since it was still looking up at 128.
> 
> Signed-off-by: Eric Anholt 
> Fixes: 0d49f303e8a7 ("drm: remove all control node code")
> Cc: Daniel Vetter 
> Cc: Sean Paul 

Oops.

> ---
>  include/drm/drm_file.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/include/drm/drm_file.h b/include/drm/drm_file.h
> index 99ab50cbab00..69b0a8b57502 100644
> --- a/include/drm/drm_file.h
> +++ b/include/drm/drm_file.h
> @@ -49,6 +49,7 @@ struct device;
>  
>  enum drm_minor_type {
>   DRM_MINOR_PRIMARY,
> + DRM_MINOR_CONTROL,

Maybe add a comment here why we need this? Either way:

Reviewed-by: Daniel Vetter 

>   DRM_MINOR_RENDER,
>  };
>  
> -- 
> 2.17.0
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 106473] Mesa/Gallium segfaults in pipe_resource_reference (dri2_destroy_image) on KDE Plasma screen locker

[bugzilla-daemon]

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

Matt Whitlock  changed:

   What|Removed |Added

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

--- Comment #3 from Matt Whitlock  ---
I have not encountered the crash since applying 6f81e07ecb8c. I think we can
call this one licked for now. I'll reopen this report if I experience the crash
again.

-- 
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: [PATCH v2 26/26] drm/bridge: establish a link between the bridge supplier and consumer

[Peter Rosin]

On 2018-05-10 10:10, Andrzej Hajda wrote:
> On 04.05.2018 15:52, Peter Rosin wrote:
>> If the bridge supplier is unbound, this will bring the bridge consumer
>> down along with the bridge. Thus, there will no longer linger any
>> dangling pointers from the bridge consumer (the drm_device) to some
>> non-existent bridge supplier.
>>
>> Signed-off-by: Peter Rosin 
>> ---
>>  drivers/gpu/drm/drm_bridge.c | 18 ++
>>  include/drm/drm_bridge.h |  2 ++
>>  2 files changed, 20 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
>> index 78d186b6831b..0259f0a3ff27 100644
>> --- a/drivers/gpu/drm/drm_bridge.c
>> +++ b/drivers/gpu/drm/drm_bridge.c
>> @@ -26,6 +26,7 @@
>>  #include 
>>  
>>  #include 
>> +#include 
>>  #include 
>>  
>>  #include "drm_crtc_internal.h"
>> @@ -127,12 +128,25 @@ int drm_bridge_attach(struct drm_encoder *encoder, 
>> struct drm_bridge *bridge,
>>  if (bridge->dev)
>>  return -EBUSY;
>>  
>> +if (encoder->dev->dev != bridge->odev) {
> 
> I wonder why device_link_add does not handle this case (self dependency)
> silently as noop, as it seems to be a correct behavior.

It's kind-of a silly corner-case though, so perfectly understandable
that it isn't handled.

>> +bridge->link = device_link_add(encoder->dev->dev,
>> +   bridge->odev, 0);
>> +if (!bridge->link) {
>> +dev_err(bridge->odev, "failed to link bridge to %s\n",
>> +dev_name(encoder->dev->dev));
>> +return -EINVAL;
>> +}
>> +}
>> +
>>  bridge->dev = encoder->dev;
>>  bridge->encoder = encoder;
>>  
>>  if (bridge->funcs->attach) {
>>  ret = bridge->funcs->attach(bridge);
>>  if (ret < 0) {
>> +if (bridge->link)
>> +device_link_del(bridge->link);
>> +bridge->link = NULL;
>>  bridge->dev = NULL;
>>  bridge->encoder = NULL;
>>  return ret;
>> @@ -159,6 +173,10 @@ void drm_bridge_detach(struct drm_bridge *bridge)
>>  if (bridge->funcs->detach)
>>  bridge->funcs->detach(bridge);
>>  
>> +if (bridge->link)
>> +device_link_del(bridge->link);
>> +bridge->link = NULL;
>> +
>>  bridge->dev = NULL;
>>  }
>>  
>> diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
>> index b656e505d11e..804189c63a4c 100644
>> --- a/include/drm/drm_bridge.h
>> +++ b/include/drm/drm_bridge.h
>> @@ -261,6 +261,7 @@ struct drm_bridge_timings {
>>   * @list: to keep track of all added bridges
>>   * @timings: the timing specification for the bridge, if any (may
>>   * be NULL)
>> + * @link: drm consumer <-> bridge supplier
> 
> Nitpick: "<->" suggests symmetry, maybe "device link from drm consumer
> to the bridge" would be better.

I meant "<->" to indicate that the link is bidirectional, not that the
relationship is in any way symmetric. I wasn't aware of any implication
of a symmetric relationship when using "<->", do you have a reference?
But I guess the different arrow notations in math are somewhat overloaded
and that someone at some point must have used "<->" to indicate a
symmetric relationship...

> Anyway:
> Reviewed-by: Andrzej Hajda 

Thanks!

Cheers,
Peter

>  --
> Regards
> Andrzej
> 
>>   * @funcs: control functions
>>   * @driver_private: pointer to the bridge driver's internal context
>>   */
>> @@ -271,6 +272,7 @@ struct drm_bridge {
>>  struct drm_bridge *next;
>>  struct list_head list;
>>  const struct drm_bridge_timings *timings;
>> +struct device_link *link;
>>  
>>  const struct drm_bridge_funcs *funcs;
>>  void *driver_private;
> 
> 

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

Re: [PATCH v5 2/4] dt-bindings: drm/bridge: Document sn65dsi86 bridge bindings

[spanda]

On 2018-05-08 03:48, Stephen Boyd wrote:

Quoting spa...@codeaurora.org (2018-05-03 02:41:29)

On 2018-05-02 22:31, Stephen Boyd wrote:
> Quoting Sandeep Panda (2018-05-01 21:32:00)
>> diff --git
>> a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt
>> b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt
>> new file mode 100644
>> index 000..0d042ce
>
> Please use the clocks property instead. We may need to turn the clk on
> first before this can work so the driver would use the clk framework
> (at
> least in linux). clock-names could have 'refclk' because that's the pin
> name.
>
> Is there a way in DRM to figure out the frequency of the clock
> frequency
> for DACP/N? It looks like if refclk is grounded, then the DACP/N pins
> from the DSI side should be one of a set of frequencies, so I'm just
> curious how that will work and if the binding would need to be updated
> to indicate what the frequency of the DSI clock lane is, or if DRM can
> tell this driver through the port/graph stuff somehow.
>

Can we do something like below?
1. Add a required dt-property to indicate what is the source of
refclk, ti,sn-refclk-src = <0> ---> means refclk is derived from 
refclk

pin.

   ti,sn-refclk-src = <1> ---> means refclk is derived from DACP/N 
pin.
2. Add a clock property to indicate the refclk frequency for 
refclk

pin.
3. In driver, parse the refclk source dt-property. If the source 
is
refclk pin then get the frquency from clock dt-property and program 
the

i2c register accordingly.
   Else if the source is DACP/N pin then calculate the DSIA 
frequency
based on current display mode (by the time we go for configuring 
refclk,

drm_mode_set is already done and in  diver we can calculate the
frequency) and program the i2c register accordingly.


The presence or non-presence of the refclk should still be indicated 
via

the standard clock property instead of some TI specific property. The
driver can try to clk_get() the refclk and if its there it can call
clk_get_rate() to figure out the reference clk frequency. It should 
also

turn it on with clk_prepare_enable() to make sure the clk is clocking
and turn it off when the driver isn't using it.

If the reference clk is recovered from the DACP/N pin then there won't
be a clocks property, and the driver can do what you describe in #3.



>> +
>> +- gpio-controller: Marks the device has a GPIO controller.
>> +- #gpio-cells: Number of GPIO cells. Refer to binding document
>> "gpio/gpio.txt"
>
> What's the number? 2?
number is 4, i will update this in binding


Really? What do you need 4 cells for? The number of cells doesn't
indicate the number of GPIOs on the device.


It should be 2, got confused with number GPIOs.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

KASAN: use-after-free Write in vgacon_scroll

[Kyungtae Kim]

We report the crash:
"KASAN: use-after-free Write in vgacon_scroll"

This crash was found in v4.17-rc3. Specifically, memory access (write
operation) is invalid, and it is detected by KASAN.

C repro code:
 https://kiwi.cs.purdue.edu/static/alexkkid-fuzzer/repro-bd11a.c
kernel config:
 https://kiwi.cs.purdue.edu/static/alexkkid-fuzzer/kernel-config-v4.17-rc3

Crash log:
==
BUG: KASAN: use-after-free in memcpy include/linux/string.h:345 [inline]
BUG: KASAN: use-after-free in scr_memcpyw include/linux/vt_buffer.h:49
[inline]
BUG: KASAN: use-after-free in vgacon_scrollback_update
drivers/video/console/vgacon.c:249 [inline]
BUG: KASAN: use-after-free in vgacon_scroll+0x684/0x890
drivers/video/console/vgacon.c:1374
Write of size 3758 at addr 88011a8bf98e by task syz-executor1/3226

CPU: 0 PID: 3226 Comm: syz-executor1 Not tainted 4.17.0-rc3 #2
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0xc7/0x138 lib/dump_stack.c:113
 print_address_description+0x6a/0x280 mm/kasan/report.c:256
 kasan_report_error mm/kasan/report.c:354 [inline]
 kasan_report+0x22f/0x350 mm/kasan/report.c:412
 check_memory_region_inline mm/kasan/kasan.c:260 [inline]
 check_memory_region+0x13b/0x1a0 mm/kasan/kasan.c:267
 memcpy+0x37/0x50 mm/kasan/kasan.c:303
 memcpy include/linux/string.h:345 [inline]
 scr_memcpyw include/linux/vt_buffer.h:49 [inline]
 vgacon_scrollback_update drivers/video/console/vgacon.c:249 [inline]
 vgacon_scroll+0x684/0x890 drivers/video/console/vgacon.c:1374
 con_scroll+0x2cc/0x330 drivers/tty/vt/vt.c:329
 lf+0x247/0x290 drivers/tty/vt/vt.c:1122
 do_con_trol+0x14f/0x5310 drivers/tty/vt/vt.c:1785
 do_con_write.part.20+0x597/0x1b70 drivers/tty/vt/vt.c:2433
 do_con_write drivers/tty/vt/vt.c:2790 [inline]
 con_write+0xb2/0xc0 drivers/tty/vt/vt.c:2786
 n_tty_write+0x763/0xea0 drivers/tty/n_tty.c:2331
 do_tty_write drivers/tty/tty_io.c:958 [inline]
 tty_write+0x48c/0x870 drivers/tty/tty_io.c:1042
 redirected_tty_write+0xaf/0xc0 drivers/tty/tty_io.c:1063
 __vfs_write+0x10d/0x610 fs/read_write.c:485
 vfs_write+0x187/0x500 fs/read_write.c:549
 ksys_write+0xd4/0x1a0 fs/read_write.c:598
 __do_sys_write fs/read_write.c:610 [inline]
 __se_sys_write fs/read_write.c:607 [inline]
 __x64_sys_write+0x73/0xb0 fs/read_write.c:607
 do_syscall_64+0xa4/0x460 arch/x86/entry/common.c:287
 entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x4497b9
RSP: 002b:7fc0af9acc68 EFLAGS: 0246 ORIG_RAX: 0001
RAX: ffda RBX: 7fc0af9ad6cc RCX: 004497b9
RDX: 1000 RSI: 2080 RDI: 0013
RBP: 0071bf58 R08:  R09: 
R10:  R11: 0246 R12: 
R13: 9ee8 R14: 006f0f88 R15: 7fc0af9ad700

The buggy address belongs to the page:
page:ea00046a2c00 count:1 mapcount:0 mapping: index:0x0
compound_mapcount: 0
flags: 0x2008000(head)
raw: 02008000   0001
raw: dead0100 dead0200  
page dumped because: kasan: bad access detected

Memory state around the buggy address:
 88011a8bff00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 88011a8bff80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>88011a8c: fb fb fb fc fc fb fb fb fc fc 00 00 00 fc fc fc
   ^
 88011a8c0080: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
 88011a8c0100: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
==

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

Re: [PATCH] gpu: drm: tegra: Adding new typedef vm_fault_t

[Souptick Joarder]

On Mon, Apr 23, 2018 at 4:24 PM, Matthew Wilcox  wrote:
> On Wed, Apr 18, 2018 at 10:24:39AM +0200, Thierry Reding wrote:
>> > @@ -437,20 +436,7 @@ static int tegra_bo_fault(struct vm_fault *vmf)
>> > offset = (vmf->address - vma->vm_start) >> PAGE_SHIFT;
>> > page = bo->pages[offset];
>> >
>> > -   err = vm_insert_page(vma, vmf->address, page);
>> > -   switch (err) {
>> > -   case -EAGAIN:
>> > -   case 0:
>> > -   case -ERESTARTSYS:
>> > -   case -EINTR:
>> > -   case -EBUSY:
>> > -   return VM_FAULT_NOPAGE;
>> > -
>> > -   case -ENOMEM:
>> > -   return VM_FAULT_OOM;
>> > -   }
>> > -
>> > -   return VM_FAULT_SIGBUS;
>> > +   return vmf_insert_page(vma, vmf->address, page);
>> >  }
>>
>> This new function returns VM_FAULT_NOPAGE only for 0 and -EBUSY, whereas
>> we used to return VM_FAULT_NOPAGE for -EAGAIN, -ERESTARTSYS and -EINTR
>> as well. Was this previously wrong?
>
> Not so much wrong as unnecessary.  vm_insert_page() can't return -EAGAIN,
> -ERESTARTSYS or -EINTR.

If no further comment on this patch, We would like to get this patch
queued for 4.18.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] display: panel: Add KOE tx14d24vm1bpa display support (320x240)

[Lukasz Majewski]

Hi Rob, Thierry

> On Fri, May 4, 2018 at 5:28 AM, Lukasz Majewski  wrote:
> > Hi Rob,
> >  
> >> On Thu, Apr 12, 2018 at 04:37:15PM +0200, Lukasz Majewski wrote:  
> >> > This commit adds support for KOE's 5.7" display.
> >> >
> >> > Signed-off-by: Lukasz Majewski 
> >> > ---
> >> >  .../bindings/display/panel/koe,tx14d24vm1bpa.txt   | 42
> >> > ++
> >> > drivers/gpu/drm/panel/panel-simple.c   | 26
> >> > ++ 2 files changed, 68 insertions(+) create mode
> >> > 100644
> >> > Documentation/devicetree/bindings/display/panel/koe,tx14d24vm1bpa.txt  
> >>
> >> Reviewed-by: Rob Herring 
> >>  
> >
> > Gentle ping on this - as I don't know if this patch been applied.  
> 
> This should go thru DRM tree via Thierry.

Would it be possible to pull this patch along with:
[PATCH v3] display: panel: Add AUO g070vvn01 display support (800x480)

To your -next tree (as we are now with -rc4) ?

> 
> Rob


Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de


pgp56SSc9RikS.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2] gpu: drm: armada: Adding new typedef vm_fault_t

[Russell King - ARM Linux]

On Thu, May 10, 2018 at 08:34:48PM +0530, Souptick Joarder wrote:
> Use new return type vm_fault_t for fault handler in
> struct vm_operations_struct. For now, this is just
> documenting that the function returns a VM_FAULT
> value rather than an errno. Once all instances are
> converted, vm_fault_t will become a distinct type.
> 
> commit 1c8f422059ae ("mm: change return type to vm_fault_t")
> 
> Previously vm_insert_pfn() returns err which driver
> mapped into VM_FAULT_* type. The new function
> vmf_insert_pfn() will replace this inefficiency by
> returning VM_FAULT_* type.
> 
> Signed-off-by: Souptick Joarder 
> Reviewed-by: Matthew Wilcox 

Acked-by: Russell King 

Thanks.

> ---
> v2: Updated the change log
> 
>  drivers/gpu/drm/armada/armada_gem.c | 15 ++-
>  1 file changed, 2 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/gpu/drm/armada/armada_gem.c 
> b/drivers/gpu/drm/armada/armada_gem.c
> index a97f509..81a55b7 100644
> --- a/drivers/gpu/drm/armada/armada_gem.c
> +++ b/drivers/gpu/drm/armada/armada_gem.c
> @@ -13,25 +13,14 @@
>  #include 
>  #include "armada_ioctlP.h"
> 
> -static int armada_gem_vm_fault(struct vm_fault *vmf)
> +static vm_fault_t armada_gem_vm_fault(struct vm_fault *vmf)
>  {
>   struct drm_gem_object *gobj = vmf->vma->vm_private_data;
>   struct armada_gem_object *obj = drm_to_armada_gem(gobj);
>   unsigned long pfn = obj->phys_addr >> PAGE_SHIFT;
> - int ret;
> 
>   pfn += (vmf->address - vmf->vma->vm_start) >> PAGE_SHIFT;
> - ret = vm_insert_pfn(vmf->vma, vmf->address, pfn);
> -
> - switch (ret) {
> - case 0:
> - case -EBUSY:
> - return VM_FAULT_NOPAGE;
> - case -ENOMEM:
> - return VM_FAULT_OOM;
> - default:
> - return VM_FAULT_SIGBUS;
> - }
> + return vmf_insert_pfn(vmf->vma, vmf->address, pfn);
>  }
> 
>  const struct vm_operations_struct armada_gem_vm_ops = {
> --
> 1.9.1
> 

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 1/4] drm/bridge: add support for sn65dsi86 bridge driver

[spanda]

On 2018-05-08 03:50, Stephen Boyd wrote:

Quoting Sean Paul (2018-05-02 12:03:16)

On Wed, May 02, 2018 at 10:01:59AM +0530, Sandeep Panda wrote:

> + struct drm_display_mode curr_mode;
> + struct mutex lock;
> + unsigned int ctrl_ref_count;
> +};
> +
> +static const struct regmap_range ti_sn_bridge_volatile_ranges[] = {
> + { .range_min = 0, .range_max = 0xff },
> +};
> +
> +static const struct regmap_access_table ti_sn_bridge_volatile_table = {
> + .yes_ranges = ti_sn_bridge_volatile_ranges,
> + .n_yes_ranges = ARRAY_SIZE(ti_sn_bridge_volatile_ranges),
> +};
> +
> +static const struct regmap_config ti_sn_bridge_regmap_config = {
> + .reg_bits = 8,
> + .val_bits = 8,
> + .volatile_table = _sn_bridge_volatile_table,
> + .cache_type = REGCACHE_NONE,
> +};
> +
> +static int ti_sn_bridge_power_ctrl(struct ti_sn_bridge *pdata, bool enable)
> +{
> + int ret = 0;
> +
> + mutex_lock(>lock);
> + if (enable)
> + pdata->ctrl_ref_count++;
> + else
> + pdata->ctrl_ref_count--;

I think you should use a kref instead of rolling your own ref_count. 
You can
handle release by calling kref_put_mutex(), which will handle the 
reference and
the lock. On the acquire side, you can use kref_get_unless_zero which 
will be

fast if the reference is already active.


Why not use runtime PM?


I think PM runtime will be a better approach since we are trying to 
protect bridge power source related resources here.

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

Re: [PATCH] gpu: drm: exynos: Change return type to vm_fault_t

[Souptick Joarder]

On Fri, May 11, 2018 at 1:24 PM, Inki Dae  wrote:
>
> 2018년 05월 10일 23:27에 Souptick Joarder 이(가) 쓴 글:
>> On Sat, Apr 14, 2018 at 9:34 PM, Souptick Joarder  
>> wrote:
>>> Use new return type vm_fault_t for fault handler
>>> in struct vm_operations_struct.
>>>
>>> Signed-off-by: Souptick Joarder 
>>> Reviewed-by: Matthew Wilcox 
>>> ---
>>>  drivers/gpu/drm/exynos/exynos_drm_gem.c | 21 -
>>>  drivers/gpu/drm/exynos/exynos_drm_gem.h |  3 ++-
>>>  2 files changed, 6 insertions(+), 18 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c 
>>> b/drivers/gpu/drm/exynos/exynos_drm_gem.c
>>> index 11cc01b..6e1494f 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
>>> @@ -431,37 +431,24 @@ int exynos_drm_gem_dumb_create(struct drm_file 
>>> *file_priv,
>>> return 0;
>>>  }
>>>
>>> -int exynos_drm_gem_fault(struct vm_fault *vmf)
>>> +vm_fault_t exynos_drm_gem_fault(struct vm_fault *vmf)
>>>  {
>>> struct vm_area_struct *vma = vmf->vma;
>>> struct drm_gem_object *obj = vma->vm_private_data;
>>> struct exynos_drm_gem *exynos_gem = to_exynos_gem(obj);
>>> unsigned long pfn;
>>> pgoff_t page_offset;
>>> -   int ret;
>>>
>>> page_offset = (vmf->address - vma->vm_start) >> PAGE_SHIFT;
>>>
>>> if (page_offset >= (exynos_gem->size >> PAGE_SHIFT)) {
>>> DRM_ERROR("invalid page offset\n");
>>> -   ret = -EINVAL;
>>> -   goto out;
>>> +   return VM_FAULT_SIGBUS;
>>> }
>>>
>>> pfn = page_to_pfn(exynos_gem->pages[page_offset]);
>>> -   ret = vm_insert_mixed(vma, vmf->address, __pfn_to_pfn_t(pfn, 
>>> PFN_DEV));
>>> -
>>> -out:
>>> -   switch (ret) {
>>> -   case 0:
>>> -   case -ERESTARTSYS:
>>> -   case -EINTR:
>>> -   return VM_FAULT_NOPAGE;
>>> -   case -ENOMEM:
>>> -   return VM_FAULT_OOM;
>>> -   default:
>>> -   return VM_FAULT_SIGBUS;
>>> -   }
>>> +   return vmf_insert_mixed(vma, vmf->address,
>>> +   __pfn_to_pfn_t(pfn, PFN_DEV));
>>>  }
>>>
>>>  static int exynos_drm_gem_mmap_obj(struct drm_gem_object *obj,
>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.h 
>>> b/drivers/gpu/drm/exynos/exynos_drm_gem.h
>>> index 5a4c7de..9057d7f 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_drm_gem.h
>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.h
>>> @@ -13,6 +13,7 @@
>>>  #define _EXYNOS_DRM_GEM_H_
>>>
>>>  #include 
>>> +#include 
>>>
>>>  #define to_exynos_gem(x)   container_of(x, struct exynos_drm_gem, base)
>>>
>>> @@ -111,7 +112,7 @@ int exynos_drm_gem_dumb_create(struct drm_file 
>>> *file_priv,
>>>struct drm_mode_create_dumb *args);
>>>
>>>  /* page fault handler and mmap fault address(virtual) to physical memory. 
>>> */
>>> -int exynos_drm_gem_fault(struct vm_fault *vmf);
>>> +vm_fault_t exynos_drm_gem_fault(struct vm_fault *vmf);
>>>
>>>  /* set vm_flags and we can change the vm attribute to other one at here. */
>>>  int exynos_drm_gem_mmap(struct file *filp, struct vm_area_struct *vma);
>>> --
>>> 1.9.1
>>>
>>
>> Any comment on this patch ?
>>
>
> Cleanup one so merged it already to -next.
>
> Thanks,
> Inki Dae

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

[Bug 106490] VA-API video deconding broken for Chromium on Mesa 18.0.3

[bugzilla-daemon]

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

Bug ID: 106490
   Summary: VA-API video deconding broken for Chromium on Mesa
18.0.3
   Product: Mesa
   Version: 18.0
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: leonm...@gmail.com
QA Contact: dri-devel@lists.freedesktop.org

VA-API video decoding doesn't work for Chromium browser with VA-API support
patches.

It works perfectly fine with Mesa 17.3.9: https://imgur.com/tMSKtsb
But totally broken with Mesa 18.0.3: https://imgur.com/xVGQDhB

My system is CentOS 7.5, custom built kernel 4.14.32 (longterm).
Video adapter is ASUS Radeon R9 Fury 4GB.

Mesa packages is also built by me.
libdrm version 2.4.91.
LLVM version 6.0.0.
libva version 0.40.

There isn't any errors reported by Chromium or libva or in dmesg.

Also I found in discussion of chromium-vaapi (for Arch) a user with AMD Radeon
have very same problem with Mesa 18.
Link to discussion:
https://aur.archlinux.org/packages/chromium-vaapi-bin/?comments=all
User name is digitalone.
Link to his screenshot: https://imgur.com/a/vYDJ9

Chromium built with VA-API patches is available in Ubuntu PPA or Arch Linux
AUR.

If it'll be needed I can upload my build of Chromium with VA-API patches for
CentOS 7 somewhere.

Chromium flags to enable VA-API acceleration: https://imgur.com/IHkOvlt

Ubuntu PPA: https://launchpad.net/~saiarcot895/+archive/ubuntu/chromium-dev
Arch Linux AUR: https://aur.archlinux.org/packages/chromium-vaapi-bin

Ask for any information that You may need.

-- 
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 102709] War Thunder crashes after logging in to the game. (GL_INVALID_ENUM)

[bugzilla-daemon]

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

--- Comment #3 from Vitalii  ---
(In reply to Vitalii from comment #2)
> (In reply to Samuel Pitoiset from comment #1)
> > Well, War Thunder doesn't check that GL_EXT_texture_compression_s3tc is
> > exposed before using those compressed formats.
> > 
> > Though, if you have libtxc_dxtn installed on your system the extension
> > should be enabled, can you check?
> 
> I have the same problem with war thunder, but my driver crashes and only
> hard reboots help. I can not find the logs and I do not know how to inspect
> it. driver r600 padeon HD7600

if you run the version from windows, it also hangs but only with gallium nine
it starts with some artifacts

-- 
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 102709] War Thunder crashes after logging in to the game. (GL_INVALID_ENUM)

[bugzilla-daemon]

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

--- Comment #2 from Vitalii  ---
(In reply to Samuel Pitoiset from comment #1)
> Well, War Thunder doesn't check that GL_EXT_texture_compression_s3tc is
> exposed before using those compressed formats.
> 
> Though, if you have libtxc_dxtn installed on your system the extension
> should be enabled, can you check?

I have the same problem with war thunder, but my driver crashes and only hard
reboots help. I can not find the logs and I do not know how to inspect it.
driver r600 padeon HD7600

-- 
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 104300] Kernel 4.15-rc2 on Polaris RX 480 with amdgpu.dc=1 has trouble waking up displays after suspend

[bugzilla-daemon]

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

Bug ID: 104300
   Summary: Kernel 4.15-rc2 on Polaris RX 480 with amdgpu.dc=1 has
trouble waking up displays after suspend
   Product: DRI
   Version: unspecified
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: toni.sp...@iki.fi
CC: mariusz.g.ma...@gmail.com
CC: mariusz.g.ma...@gmail.com

When resuming from suspend on 4.15-rc2 the DC stack *usually* wakes up displays
after some waiting on this Polaris card compared to non-DC code which flips
them on instantly.

I've encountered the following issues with my dual head setup (native DVI and
HDMI->DVI adapter):

 - it takes long (2-5 seconds) for the outputs to come up
 - Xfce thinks both of the display were hotplugged causing all kinds of
desktop/windowing related issues
 - sometimes corrupted image on both outputs and the outputs are reset after
waiting for 20 seconds or so, sometimes they come up, sometimes the corruption
stays, the system is unresponsive to input while that's going on

I have zero issues without DC. Waking up works 100% of the time and Xfce never
thinks the displays were hotplugged.

Currently I have no logs from kernel from that time. Hope this description is
enough.

--- Comment #1 from Mariusz Mazur  ---
I'm reliably getting monitors waking up be treated as hotplugged on ubuntu
18.04's 4.15 kernels and a build of 4.16.7. More info:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1770836

-- 
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 106456] [regression][bisected] Mutex deadlock in nouveau (nv50_display.c)

[bugzilla-daemon]

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

Ilia Mirkin  changed:

   What|Removed |Added

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

--- Comment #4 from Ilia Mirkin  ---
This is now in mainline:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=352672db857290ab5b0e2b6a99c414f92bee024c

-- 
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 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-daemon]

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

--- Comment #198 from Jon Doane  ---
I would like to add that the problem appears to be resolved on my installation
of Ubuntu 18.04 with the MSI R9 390 8GB GAMING GPU using the current mainline
kernel (4.17-rc4,) with the kernel flags of "amdgpu.dc=1" and "amdgpu.dpm=1".
Clock scaling appears to be working as expected and I haven't had any visual
artifacts or crashes to speak of yet. Using "amdgpu.dc=1" alone didn't make a
difference but, "amdgpu.dpm=1" made all the difference.

Good work to everyone involved!

-- 
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 99403] Graphical glitches in witcher-1 with wine nine and r600g (rv740).

[bugzilla-daemon]

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

--- Comment #11 from i...@yahoo.com ---
(In reply to Roman Elshin from comment #10)
> so it may be closed?
> p.s. thanks a lot to all participated

If it works OK for you, you are free to close it.
You may also mark it as duplicate of
https://bugs.freedesktop.org/show_bug.cgi?id=91808
Since both issues seems to be fixed by same change.

About the problem still existing on Tahiti, the issue might be some other
(similar) bug. I've been told that you can't just port that fix to radeonsi/gcn
as they work differently.

But it is not problem to open a new issue for it.

-- 
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 104347] AMD RX 580: Hide/Show Chromium sometimes corrupts screen (see screenshot)

[bugzilla-daemon]

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

--- Comment #14 from Norbert Klar  ---
And looks like this bug not only happening with Chrome. Just installed Discord,
and getting the same 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: [PATCHv3] drm/amdkfd: Remove vla

[Oded Gabbay]

On Thu, May 3, 2018 at 12:49 AM, Kees Cook  wrote:
> On Fri, Apr 13, 2018 at 2:24 PM, Laura Abbott  wrote:
>>
>> There's an ongoing effort to remove VLAs[1] from the kernel to eventually
>> turn on -Wvla. Switch to a constant value that covers all hardware.
>>
>> [1] https://lkml.org/lkml/2018/3/7/621
>>
>> Reviewed-by: Felix Kuehling 
>> Acked-by: Christian König 
>> Signed-off-by: Laura Abbott 
>
> Friendly ping -- I don't see this in -next yet. Oded, does this look
> okay to apply?
>
> Thanks!
>
> -Kees

Thanks!
Applied to amdkfd-next

Oded

>
>> ---
>> v3: Introduced a #define for the max value, switched to pr_err_once to
>> avoid log flood, switched to sizeof(array) per private suggestion.
>> ---
>>  drivers/gpu/drm/amd/amdkfd/kfd_interrupt.c | 8 +---
>>  drivers/gpu/drm/amd/amdkfd/kfd_priv.h  | 2 ++
>>  2 files changed, 7 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_interrupt.c 
>> b/drivers/gpu/drm/amd/amdkfd/kfd_interrupt.c
>> index 035c351f47c5..db6d9336b80d 100644
>> --- a/drivers/gpu/drm/amd/amdkfd/kfd_interrupt.c
>> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_interrupt.c
>> @@ -139,10 +139,12 @@ static void interrupt_wq(struct work_struct *work)
>>  {
>> struct kfd_dev *dev = container_of(work, struct kfd_dev,
>> interrupt_work);
>> +   uint32_t ih_ring_entry[KFD_MAX_RING_ENTRY_SIZE];
>>
>> -   uint32_t ih_ring_entry[DIV_ROUND_UP(
>> -   dev->device_info->ih_ring_entry_size,
>> -   sizeof(uint32_t))];
>> +   if (dev->device_info->ih_ring_entry_size > sizeof(ih_ring_entry)) {
>> +   dev_err_once(kfd_chardev(), "Ring entry too small\n");
>> +   return;
>> +   }
>>
>> while (dequeue_ih_ring_entry(dev, ih_ring_entry))
>> dev->device_info->event_interrupt_class->interrupt_wq(dev,
>> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_priv.h 
>> b/drivers/gpu/drm/amd/amdkfd/kfd_priv.h
>> index 96a9cc0f02c9..a90db05dfe61 100644
>> --- a/drivers/gpu/drm/amd/amdkfd/kfd_priv.h
>> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_priv.h
>> @@ -39,6 +39,8 @@
>>
>>  #include "amd_shared.h"
>>
>> +#define KFD_MAX_RING_ENTRY_SIZE8
>> +
>>  #define KFD_SYSFS_FILE_MODE 0444
>>
>>  #define KFD_MMAP_DOORBELL_MASK 0x8ull
>> --
>> 2.14.3
>>
>
>
>
> --
> Kees Cook
> Pixel Security
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 106427] RX560, 5k@60Hz, Xorg: Black screen, “soft” kernel lockup

[bugzilla-daemon]

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

--- Comment #5 from txtoxtox...@googlemail.com ---
Created attachment 139515
  --> https://bugs.freedesktop.org/attachment.cgi?id=139515=edit
Xorg.log 4k@60

-- 
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 106427] RX560, 5k@60Hz, Xorg: Black screen, “soft” kernel lockup

[bugzilla-daemon]

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

--- Comment #4 from txtoxtox...@googlemail.com ---
Created attachment 139514
  --> https://bugs.freedesktop.org/attachment.cgi?id=139514=edit
dmesg-4.16.7 4K@60

-- 
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 106427] RX560, 5k@60Hz, Xorg: Black screen, “soft” kernel lockup

[bugzilla-daemon]

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

txtoxtox...@googlemail.com changed:

   What|Removed |Added

 Attachment #139402|dmesg-4.16.7|dmesg-4.16.7 5K@60
description||

-- 
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 106427] RX560, 5k@60Hz, Xorg: Black screen, “soft” kernel lockup

[bugzilla-daemon]

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

txtoxtox...@googlemail.com changed:

   What|Removed |Added

 Attachment #139403|Xorg.log|Xorg.log 5k@60
description||

-- 
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 106427] RX560, 5k@60Hz, Xorg: Black screen, “soft” kernel lockup

[bugzilla-daemon]

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

--- Comment #3 from txtoxtox...@googlemail.com ---
I would like to mention that “cvt 4096 2304 -r” is a mode that works under X so
it may not be the 60 Hz as such but rather the increased bandwidth, which needs
DisplayPort 1.3 instead of just 1.2.

(However, when X is terminated the Linux console goes black because it seems
that the driver cannot switch back to 5k@60Hz.)

-- 
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 97025] flip queue failed: Device or resource busy

[bugzilla-daemon]

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

--- Comment #27 from Bernd Steinhauser  ---
Thanks, I'm testing it right now on linux 4.16.8.

Although I'm not sure if it works as expected, since the display does still
seem to disconnect when I turn the screen off.

At least the messages in dmesg are gone, so it's definitely different compared
to previous tests.
Can't say anything about the freezes without extensive testing, though.

-- 
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 199619] screen stays dark for long on bootup since kernel 4.17.0-rc2+

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=199619

--- Comment #3 from Elmar Stellnberger (estel...@elstel.org) ---
persists with 4.17.0-rc4+

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