On Mon, Nov 13, 2017 at 6:24 AM, Julien Isorce wrote:
> Hi Alex,
>
> Thx for your reply, but in all of the cases you mentioned, the user would
> still
> be able to reboot properly ( i.e. typing reboot or a magic keyboard key)
> or to have a trace of a kernel panic if it
*From:* Julien Isorce [mailto:julien.iso...@gmail.com]
> *Sent:* 2017年11月9日 17:35
> *To:* Liu, Monk <monk@amd.com>
> *Cc:* amd-gfx@lists.freedesktop.org
> *Subject:* Re: [PATCH 0/7] *** GPU recover V3 ***
>
>
>
> Hi Monk.
>
>
>
> I am interested on this.
Hi Alex,
Thx for your reply, but in all of the cases you mentioned, the user would
still
be able to reboot properly ( i.e. typing reboot or a magic keyboard key)
or to have a trace of a kernel panic if it happens, is it correct ?
Thx
Julien
On 9 November 2017 at 18:08, Alex Deucher
Please share the dmesg log, and what’s the chip are you using ?
From: Julien Isorce [mailto:julien.iso...@gmail.com]
Sent: 2017年11月9日 17:35
To: Liu, Monk <monk@amd.com>
Cc: amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH 0/7] *** GPU recover V3 ***
Hi Monk.
I am inte
On Thu, Nov 9, 2017 at 4:35 AM, Julien Isorce wrote:
> Hi Monk.
>
> I am interested on this. Currently when a "ring X stalled for more than N
> sec" happens it usually goes into the gpu reset routine.
> Does it always cause the vram to be lost ? Could you explain what
Hi Monk.
I am interested on this. Currently when a "ring X stalled for more than N
sec" happens it usually goes into the gpu reset routine.
Does it always cause the vram to be lost ? Could you explain what happens
if the vram remains lost ?
I am asking this because I experienced some recurrent
*** job skipping logic in scheduler part is re-implemented ***
Monk Liu (7):
amd/scheduler:imple job skip feature(v3)
drm/amdgpu:implement new GPU recover(v3)
drm/amdgpu:cleanup in_sriov_reset and lock_reset
drm/amdgpu:cleanup ucode_init_bo
drm/amdgpu:block kms open during gpu_reset