Re: [PATCH 0/4] drm/atmel-hlcdc: fix plane clipping/rotation issues
On Thu, 10 Jan 2019 15:10:28 + Peter Rosin wrote: > Hi! > > I found an unfortunate issue while recoding plane handling to use > drm_atomic_helper_check_plane_state(). The driver rotates clockwise, > which is not correct. I simply fixed it (patch 1/4), but maybe that > will cause regressions for unsuspecting users who simply assumed > that the clockwise rotation was correct? I don't know what to do > about that? Adding an option to get the old broken behavior seems > useless, wouldn't it be just as easy to just fix whatever app to > rotate the other way instead of adding an option somewhere? > > I have only tested this series on sama5d3, but I did check the docs > for various other chips (sama5d2, sama5d4, sam9n12, sam9g15, sam9g35 > and sam9x35) supported by the driver (relevant to patch 4/4). > > Cheers, > Peter > > Peter Rosin (4): > drm/atmel-hlcdc: rotate planes counterclockwise > drm/atmel-hlcdc: do not swap w/h of the crtc when a plane is rotated > drm/atmel-hlcdc: fix clipping of planes Queued patches 1-3 to drm-misc-next. > drm/atmel-hlcdc: do not immediately disable planes, wait for next > frame Still waiting for Nicolas feedback on this one. Thanks, Boris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108260] [Regression?] [powerplay] Failed to retrieve minimum clocks. 4.19-rc6+
https://bugs.freedesktop.org/show_bug.cgi?id=108260 Martin Jørgensen changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #13 from Martin Jørgensen --- I see -- 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: linux-next: Fixes tag needs some work in the drm-misc-fixes tree
Am Sonntag, 27. Januar 2019, 04:41:26 CET schrieb Stephen Rothwell:
> Hi all,
>
> In commit
>
> 053ff09f1a8f ("drm/rockchip: rgb: update SPDX license identifier")
>
> Fixes tag
>
> Fixes: 1f0f01515172 ("Add support for Rockchip Soc RGB output interface")
looks like I accidentially lost the "drm/rockchip:" prefix from the subject,
sorry about that. I think it should still be recognizable, as the original
was named
"drm/rockchip: Add support for Rockchip Soc RGB output interface"
It's too late to amend now anyway, so hopefully it will not cause too much
trouble.
Heiko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 1/1] drm: drop drm_bus from todo
Hey
On Sat, Jan 26, 2019 at 8:27 PM Sam Ravnborg wrote:
> David Herrmann removed the last bits of drm_bus in:
> c5786fe5f1c50941dbe27fc8b4aa1afee46ae893 ("drm: Goody bye, drm_bus!")
>
> Remove the todo item.
>
> Signed-off-by: Sam Ravnborg
> Cc: David Herrmann
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Sean Paul
> ---
> Documentation/gpu/todo.rst | 19 ---
> 1 file changed, 19 deletions(-)
I miss drm_bus!
Reviewed-by: David Herrmann
Thanks
David
> diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
> index 38360ede1221..d9515b17d36f 100644
> --- a/Documentation/gpu/todo.rst
> +++ b/Documentation/gpu/todo.rst
> @@ -10,25 +10,6 @@ graphics subsystem useful as newbie projects. Or for slow
> rainy days.
> Subsystem-wide refactorings
> ===
>
> -De-midlayer drivers
>
> -
> -With the recent ``drm_bus`` cleanup patches for 3.17 it is no longer required
> -to have a ``drm_bus`` structure set up. Drivers can directly set up the
> -``drm_device`` structure instead of relying on bus methods in ``drm_usb.c``
> -and ``drm_pci.c``. The goal is to get rid of the driver's ``->load`` /
> -``->unload`` callbacks and open-code the load/unload sequence properly, using
> -the new two-stage ``drm_device`` setup/teardown.
> -
> -Once all existing drivers are converted we can also remove those bus support
> -files for USB and platform devices.
> -
> -All you need is a GPU for a non-converted driver (currently almost all of
> -them, but also all the virtual ones used by KVM, so everyone qualifies).
> -
> -Contact: Daniel Vetter, Thierry Reding, respective driver maintainers
> -
> -
> Remove custom dumb_map_offset implementations
> -
>
> --
> 2.12.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 201273] Fatal error during GPU init amdgpu RX560
https://bugzilla.kernel.org/show_bug.cgi?id=201273 --- Comment #32 from quirin.blae...@freenet.de --- Bug is still alive. amd-staging-drm-next 7990e4b7b3b63e417a8a8cb8b33bc732b7e9e32f -- 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
[Bug 99923] HITMAN (2016) having lighting and artefacting, and overly light room.
https://bugs.freedesktop.org/show_bug.cgi?id=99923 Gregor Münch changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #46 from Gregor Münch --- Had no time to figure out the issue lately. Feral Support gave me the advice to downgrade Mesa and LLVM to stable but that wasnt the reason the game did crash for me. I ended up deleting the HITMAN folder under .local/share/feral... and things started magically work for me. So if someone from you have also a game crash upon start this might help. In game I could confirm that the issue went away. So everything looks like to render correct now. Im going forward and close this issue now. This was fixed by game update and LLVM, so this should be really fixed for everyone. -- 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] backlight: pwm_bl: Use gpiod_get_value_cansleep() to get initial state
gpiod_get_value() gives out a warning if access to the underlying gpiochip
requires sleeping, which is common for I2C based chips:
WARNING: CPU: 0 PID: 77 at drivers/gpio/gpiolib.c:2500
gpiod_get_value+0xd0/0x100
Modules linked in:
CPU: 0 PID: 77 Comm: kworker/0:2 Not tainted
4.14.0-rc3-00589-gf32897915d48-dirty #90
Hardware name: Allwinner sun4i/sun5i Families
Workqueue: events deferred_probe_work_func
[] (unwind_backtrace) from [] (show_stack+0x10/0x14)
[] (show_stack) from [] (dump_stack+0x88/0x9c)
[] (dump_stack) from [] (__warn+0xe8/0x100)
[] (__warn) from [] (warn_slowpath_null+0x20/0x28)
[] (warn_slowpath_null) from []
(gpiod_get_value+0xd0/0x100)
[] (gpiod_get_value) from []
(pwm_backlight_probe+0x238/0x508)
[] (pwm_backlight_probe) from []
(platform_drv_probe+0x50/0xac)
[] (platform_drv_probe) from []
(driver_probe_device+0x238/0x2e8)
[] (driver_probe_device) from []
(bus_for_each_drv+0x44/0x94)
[] (bus_for_each_drv) from []
(__device_attach+0xb0/0x114)
[] (__device_attach) from []
(bus_probe_device+0x84/0x8c)
[] (bus_probe_device) from []
(deferred_probe_work_func+0x50/0x14c)
[] (deferred_probe_work_func) from []
(process_one_work+0x1ec/0x414)
[] (process_one_work) from []
(worker_thread+0x2b0/0x5a0)
[] (worker_thread) from [] (kthread+0x14c/0x154)
[] (kthread) from [] (ret_from_fork+0x14/0x24)
This was missed in commit 0c9501f823a4 ("backlight: pwm_bl: Handle gpio
that can sleep"). The code was then moved to a separate function in
commit 7613c922315e ("backlight: pwm_bl: Move the checks for initial power
state to a separate function").
The only usage of gpiod_get_value() is during the probe stage, which is
safe to sleep in. Switch to gpiod_get_value_cansleep().
Fixes: 0c9501f823a4 ("backlight: pwm_bl: Handle gpio that can sleep")
Signed-off-by: Chen-Yu Tsai
---
drivers/video/backlight/pwm_bl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
index feb90764a811..53b8ceea9bde 100644
--- a/drivers/video/backlight/pwm_bl.c
+++ b/drivers/video/backlight/pwm_bl.c
@@ -435,7 +435,7 @@ static int pwm_backlight_initial_power_state(const struct
pwm_bl_data *pb)
*/
/* if the enable GPIO is disabled, do not enable the backlight */
- if (pb->enable_gpio && gpiod_get_value(pb->enable_gpio) == 0)
+ if (pb->enable_gpio && gpiod_get_value_cansleep(pb->enable_gpio) == 0)
return FB_BLANK_POWERDOWN;
/* The regulator is disabled, do not enable the backlight */
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 2/2] drm/panel: Add Feiyang FY07024DI26A30-D MIPI-DSI LCD panel
On Sat, Jan 26, 2019 at 1:22 AM Sam Ravnborg wrote:
>
> Hi Jagan.
>
> Looks good, only very few nits left.
>
> On Sat, Jan 26, 2019 at 12:52:33AM +0530, Jagan Teki wrote:
> > Feiyang FY07024DI26A30-D is 1024x600, 4-lane MIPI-DSI LCD panel.
> >
> > Add panel driver for it.
> >
> > Tested-by: Bhushan Shah
> > Signed-off-by: Jagan Teki
>
> If you consider my inputs (I know you will) then you can add my:
> Reviewed-by: Sam Ravnborg
>
>
> > + msleep(20);
> > +
> > + gpiod_set_value(ctx->reset, 0);
> > + /* T5 + T6 (avdd rise + video & logic signal rise)
> > + * T5 >= 10ms, 0 < T6 <= 10ms
> > + */
> > + msleep(20);
>
> Please use kernel coding style comment, and maybe an empty
> line between gpiod...() and the comment:
>
> gpiod_set_value(ctx->reset, 0);
> /*
> * T5 + T6 (avdd rise + video & logic signal rise)
> * T5 >= 10ms, 0 < T6 <= 10ms
> */
> msleep(20);
>
>
> > +static int feiyang_get_modes(struct drm_panel *panel)
> > +{
> > + struct drm_connector *connector = panel->connector;
> > + struct feiyang *ctx = panel_to_feiyang(panel);
> > + struct drm_display_mode *mode;
> > +
> > + mode = drm_mode_duplicate(panel->drm, &feiyang_default_mode);
> > + if (!mode) {
> > + DRM_DEV_ERROR(&ctx->dsi->dev, "failed to add mode
> > %ux%ux@%u\n",
> > + feiyang_default_mode.hdisplay,
> > + feiyang_default_mode.vdisplay,
> > + feiyang_default_mode.vrefresh);
> Please consider to use DRM_MODE_FMT and DRM_MODE_ARG for printing.
I see DRM_MODE_ARG as mode argument, that print all mode timings but
here we need only 3 timings out of it. do we really need? if yes
please suggest an example.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 21/26] drm/rockchip: Use drm_fb_helper_fill_info
Am Donnerstag, 24. Januar 2019, 17:58:26 CET schrieb Daniel Vetter: > This will set an fb name for the first time! > > Signed-off-by: Daniel Vetter > Cc: Sandy Huang > Cc: "Heiko Stübner" > Cc: linux-arm-ker...@lists.infradead.org > Cc: linux-rockc...@lists.infradead.org After looking up the rest of the series and also realizing that fbi->par seems to be set when a client attaches to the fb, this looks good to me, so Reviewed-by: Heiko Stuebner > --- > drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c > b/drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c > index 7bd3b89022be..d12164878e05 100644 > --- a/drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c > +++ b/drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c > @@ -90,13 +90,11 @@ static int rockchip_drm_fbdev_create(struct drm_fb_helper > *helper, > goto out; > } > > - fbi->par = helper; > fbi->flags = FBINFO_FLAG_DEFAULT; > fbi->fbops = &rockchip_drm_fbdev_ops; > > fb = helper->fb; > - drm_fb_helper_fill_fix(fbi, fb->pitches[0], fb->format->depth); > - drm_fb_helper_fill_var(fbi, helper, sizes->fb_width, sizes->fb_height); > + drm_fb_helper_fill_info(fbi, helper); > > offset = fbi->var.xoffset * bytes_per_pixel; > offset += fbi->var.yoffset * fb->pitches[0]; > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109466] Frozen display with Radeon RX 580 and Open Source Drivers under GNU/Linux Debian Sid
https://bugs.freedesktop.org/show_bug.cgi?id=109466 Bug ID: 109466 Summary: Frozen display with Radeon RX 580 and Open Source Drivers under GNU/Linux Debian Sid Product: Mesa Version: 18.3 Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: critical Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel@lists.freedesktop.org Reporter: yann.kerv...@free.fr QA Contact: dri-devel@lists.freedesktop.org Hello, I experience some troubles with my computer when I try to make 3D : all the display freeze and I can no longer access to any input (keyboard or mouse). >From time to time, I can move the mouse, but can’t do anything with it. I can’t switch to another TTY but can access with SSH. It happens with any 3D software but seems to come quicker with games, with no consistency in the timing or happening conditions: sometimes it takes 1mn, sometimes 10. I have experienced it with Blender (last 2.80 branch) and Super Tux Kart, for instance. Here is below informations about the crash and my computer. I am under Debian Sid, with XFCE desktop. Feel free to ask me for details, with eventually the commands to pass to get the info you need. All the best from snowy France --- dmesg output at the crash : [ 4600.707439] gmc_v8_0_process_interrupt: 5 callbacks suppressed [ 4600.707448] amdgpu :01:00.0: GPU fault detected: 147 0x0c004801 for process supertuxkart pid 3736 thread supertuxka:cs0 pid 3737 [ 4600.707458] amdgpu :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x01105D80 [ 4600.707464] amdgpu :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x04048001 [ 4600.707472] amdgpu :01:00.0: VM fault (0x01, vmid 2, pasid 32770) at page 17849728, read from 'TC4' (0x54433400) (72) [ 5118.249900] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, signaled seq=471393, emitted seq=471395 [ 5118.249909] [drm] GPU recovery disabled. infos about my computer : --- $ uname -a Linux groskoui 4.19.0-2-amd64 #1 SMP Debian 4.19.16-1 (2019-01-17) x86_64 GNU/Linux --- $ glxinfo -B name of display: :0.0 display: :0 screen: 0 direct rendering: Yes Extended renderer info (GLX_MESA_query_renderer): Vendor: X.Org (0x1002) Device: Radeon RX 580 Series (POLARIS10, DRM 3.27.0, 4.19.0-2-amd64, LLVM 7.0.1) (0x67df) Version: 18.3.2 Accelerated: yes Video memory: 8192MB Unified memory: no Preferred profile: core (0x1) Max core profile version: 4.5 Max compat profile version: 4.5 Max GLES1 profile version: 1.1 Max GLES[23] profile version: 3.2 Memory info (GL_ATI_meminfo): VBO free memory - total: 7976 MB, largest block: 7976 MB VBO free aux. memory - total: 8183 MB, largest block: 8183 MB Texture free memory - total: 7976 MB, largest block: 7976 MB Texture free aux. memory - total: 8183 MB, largest block: 8183 MB Renderbuffer free memory - total: 7976 MB, largest block: 7976 MB Renderbuffer free aux. memory - total: 8183 MB, largest block: 8183 MB Memory info (GL_NVX_gpu_memory_info): Dedicated video memory: 8192 MB Total available memory: 16384 MB Currently available dedicated video memory: 7976 MB OpenGL vendor string: X.Org OpenGL renderer string: Radeon RX 580 Series (POLARIS10, DRM 3.27.0, 4.19.0-2-amd64, LLVM 7.0.1) OpenGL core profile version string: 4.5 (Core Profile) Mesa 18.3.2 OpenGL core profile shading language version string: 4.50 OpenGL core profile context flags: (none) OpenGL core profile profile mask: core profile OpenGL version string: 4.5 (Compatibility Profile) Mesa 18.3.2 OpenGL shading language version string: 4.50 OpenGL context flags: (none) OpenGL profile mask: compatibility profile OpenGL ES profile version string: OpenGL ES 3.2 Mesa 18.3.2 OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20 -- 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/rockchip: check yuv2yuv existence before assigning window data
Am Samstag, 26. Januar 2019, 01:24:37 CET schrieb Heiko Stuebner:
> Before assigning window data, we should check if the yuv2yuv vop-data
> is set at all, because it looks like it can otherwise reference something
> wrong, as I saw on my rk3188 today which ended up in a null pointer
> dereference in vop_plane_atomic_update when accessing the yuv2yuv data.
>
> Fixes: 1c21aa8f2b68 ("drm/rockchip: Fix YUV buffers color rendering")
> Signed-off-by: Heiko Stuebner
applied to drm-misc-next where the fixed commit also waits for the
next merge-window.
Heiko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 105072] Texture corruption covering screen
https://bugs.freedesktop.org/show_bug.cgi?id=105072 Timothy Arceri changed: What|Removed |Added Status|NEEDINFO|RESOLVED Resolution|--- |FIXED --- Comment #2 from Timothy Arceri --- No reply. Assuming fixed as per comment 2 and closing. -- 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 0/7] Replace ttm_bo_{unref,reference} with ttm_bo_{get|put}
Also looks for me. Thanks Thomas.
Reviewed-by: Huang Rui
> -Original Message-
> From: Koenig, Christian
> Sent: Friday, January 25, 2019 7:29 PM
> To: Thomas Zimmermann ; Huang, Ray
> ; Zhang, Jerry ;
> airl...@redhat.com; bske...@redhat.com; linux-graphics-
> maintai...@vmware.com; thellst...@vmware.com; dri-
> de...@lists.freedesktop.org
> Subject: Re: [PATCH v2 0/7] Replace ttm_bo_{unref,reference} with
> ttm_bo_{get|put}
>
> Reviewed-by: Christian König
>
> If there are no objections over the weekend I'm going to push that into
> upstream direction on monday.
>
> Thanks for the work,
> Christian.
>
> Am 25.01.19 um 12:02 schrieb Thomas Zimmermann:
> > This patchset cleans up the last remaining callers of ttm_bo_reference
> > and ttm_bo_unref. Calls are replaced with ttm_bo_get and ttm_bo_put,
> > which follow Linux' get/put semantics more closely.
> >
> > The most notable difference is that ttm_bo_get does not clear the
> > supplied pointer's value. This behaviour is now located in the calling
> > code for cases where it might be required.
> >
> > v2:
> > * rebased onto drm-tip
> >
> > Thomas Zimmermann (7):
> >drm/ast: Replace ttm_bo_unref with ttm_bo_put
> >drm/nouveau: Replace ttm_bo_reference with ttm_bo_get
> >drm/nouveau: Replace ttm_bo_unref with ttm_bo_put
> >drm/vmwgfx: Replace ttm_bo_reference with ttm_bo_get
> >drm/vmwgfx: Replace ttm_bo_unref with ttm_bo_put
> >drm/mgag200: Replace ttm_bo_unref with ttm_bo_put
> >drm/ttm: Remove ttm_bo_reference and ttm_bo_unref
> >
> > drivers/gpu/drm/ast/ast_main.c | 6 +
> > drivers/gpu/drm/mgag200/mgag200_main.c | 8 ++-
> > drivers/gpu/drm/nouveau/nouveau_bo.h | 12 ++
> > drivers/gpu/drm/nouveau/nouveau_gem.c | 3 +--
> > drivers/gpu/drm/ttm/ttm_bo.c | 9 ---
> > drivers/gpu/drm/vmwgfx/vmwgfx_bo.c | 11 -
> > drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c | 11 +
> > drivers/gpu/drm/vmwgfx/vmwgfx_drv.h| 9 +++
> > drivers/gpu/drm/vmwgfx/vmwgfx_mob.c| 21 ++--
> > drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 9 ---
> > drivers/gpu/drm/vmwgfx/vmwgfx_validation.c | 6 +++--
> > include/drm/ttm/ttm_bo_api.h | 28 --
> > 12 files changed, 49 insertions(+), 84 deletions(-)
> >
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109229] glLinkProgram locks up for ~30 seconds
https://bugs.freedesktop.org/show_bug.cgi?id=109229 Timothy Arceri changed: What|Removed |Added Status|NEEDINFO|NEW Component|Drivers/Gallium/radeonsi|glsl-compiler Assignee|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop. |.org|org QA Contact|dri-devel@lists.freedesktop |intel-3d-bugs@lists.freedes |.org|ktop.org --- Comment #8 from Timothy Arceri --- Thanks for the extra info and sorry for delay in looking at this. Fix sent to the list: https://patchwork.freedesktop.org/patch/281427/ -- 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/fb-helper: generic: Fix drm_fbdev_client_restore()
> Fix by using drm_fb_helper_lastclose() which checks if fbdev is in use.
> static int drm_fbdev_client_restore(struct drm_client_dev *client)
> {
> - struct drm_fb_helper *fb_helper = drm_fb_helper_from_client(client);
> -
> - drm_fb_helper_restore_fbdev_mode_unlocked(fb_helper);
> + drm_fb_helper_lastclose(client->dev);
>
> return 0;
> }
Hmm, at least the drm_fb_helper_lastclose() version I'm looking at
(branch drm-misc-next) just calls
drm_fb_helper_restore_fbdev_mode_unlocked without any check ...
cheers,
Gerd
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 104520] Intermittent X crashes: GPU HANG: ecode 9:0:0x85dffffb, in Xorg [443], reason: Hang on rcs0, action: reset
https://bugs.freedesktop.org/show_bug.cgi?id=104520 --- Comment #24 from Yoshinori Gento --- I met the similar problem twice. Environment is following. CPU: SkyLake(core i5 6500TE) Distribution: debian(customised) Kernel: 4.14.40 Mesa: 17.3.9 libdrm: 2.4.89 [197410.815921] [drm] GPU HANG: ecode 9:0:0x85db, in drawingproc [2559], reason: Hang on rcs0, action: reset [197410.815927] i915 :00:02.0: Resetting rcs0 after gpu hang [197418.809902] i915 :00:02.0: Resetting rcs0 after gpu hang [197426.809904] i915 :00:02.0: Resetting rcs0 after gpu hang [197434.813910] i915 :00:02.0: Resetting rcs0 after gpu hang i965: Failed to submit batchbuffer: Input/output error [197442.813908] i915 :00:02.0: Resetting rcs0 after gpu hang "i965: Failed to submit batchbuffer: Input/output error" was appeared in stderr by mesa linked by drawingproc. -- 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
