From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Koenig, Christian" Subject: =?GB18030?B?UmU6ILvYuLSjuiBCdWc6IGFtZGdwdSBkcm0gZHJpdmVyIGNhdXNlIHByb2Nl?= =?GB18030?B?c3MgaW50byBEaXNrIHNsZWVwIHN0YXRl?= Date: Tue, 3 Sep 2019 13:07:27 +0000 Message-ID: <2162676e-dbfa-a67d-248c-98e9eb2099c2@amd.com> References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1386558522==" Return-path: In-Reply-To: Content-Language: en-US List-Id: Discussion list for AMD gfx List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: amd-gfx-bounces-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org Sender: "amd-gfx" To: 78666679 <78666679-9uewiaClKEY@public.gmane.org>, amd-gfx Cc: "Deucher, Alexander" --===============1386558522== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_2162676edbfaa67d248c98e9eb2099c2amdcom_" --_000_2162676edbfaa67d248c98e9eb2099c2amdcom_ Content-Type: text/plain; charset="GB18030" Content-Transfer-Encoding: quoted-printable Well that looks like the hardware got stuck. Do you get something in the locks about a timeout on the SDMA ring? Regards, Christian. Am 03.09.19 um 14:50 schrieb 78666679: Hi Christian, Sometimes the thread blocked disk sleeping in call to amdgpu_sa_bo_= new. following is the stack trace. it seems the sa bo is used up , so th= e caller blocked waiting someone to free sa resources. D 206833 227656 [surfaceflinger] Binder:45_5 cat /proc/206833/task/227656/stack [<0>] __switch_to+0x94/0xe8 [<0>] dma_fence_wait_any_timeout+0x234/0x2d0 [<0>] amdgpu_sa_bo_new+0x468/0x540 [amdgpu] [<0>] amdgpu_ib_get+0x60/0xc8 [amdgpu] [<0>] amdgpu_job_alloc_with_ib+0x70/0xb0 [amdgpu] [<0>] amdgpu_vm_bo_update_mapping+0x2e0/0x3d8 [amdgpu] [<0>] amdgpu_vm_bo_update+0x2a0/0x710 [amdgpu] [<0>] amdgpu_gem_va_ioctl+0x46c/0x4c8 [amdgpu] [<0>] drm_ioctl_kernel+0x94/0x118 [drm] [<0>] drm_ioctl+0x1f0/0x438 [drm] [<0>] amdgpu_drm_ioctl+0x58/0x90 [amdgpu] [<0>] do_vfs_ioctl+0xc4/0x8c0 [<0>] ksys_ioctl+0x8c/0xa0 [<0>] __arm64_sys_ioctl+0x28/0x38 [<0>] el0_svc_common+0xa0/0x180 [<0>] el0_svc_handler+0x38/0x78 [<0>] el0_svc+0x8/0xc [<0>] 0xffffffffffffffff -------------------- YanHua ------------------ =D4=AD=CA=BC=D3=CA=BC=FE ------------------ =B7=A2=BC=FE=C8=CB: "Koenig, Christian"; =B7=A2=CB=CD=CA=B1=BC=E4: 2019=C4=EA9=D4=C23=C8=D5(=D0=C7=C6=DA=B6=FE) =CF= =C2=CE=E74:21 =CA=D5=BC=FE=C8=CB: ""<78666679-9uewiaClKEY@public.gmane.org>;"amd-gfx"; =B3=AD=CB=CD: "Deucher, Alexander"; =D6=F7=CC=E2: Re: Bug: amdgpu drm driver cause process into Disk sleep stat= e Hi Yanhua, please update your kernel first, cause that looks like a known issue which was recently fixed by patch "drm/scheduler: use job count instead of peek". Probably best to try the latest bleeding edge kernel and if that doesn't help please open up a bug report on https://bugs.freedesktop.org/. Regards, Christian. Am 03.09.19 um 09:35 schrieb 78666679: > Hi, Sirs: > I have a wx5100 amdgpu card, It randomly come into failure. some= times, it will cause processes into uninterruptible wait state. > > > cps-new-ondemand-0587:~ # ps aux|grep -w D > root 11268 0.0 0.0 260628 3516 ? Ssl 8=D4=C226 0:00 /us= r/sbin/gssproxy -D > root 136482 0.0 0.0 212500 572 pts/0 S+ 15:25 0:00 grep --= color=3Dauto -w D > root 370684 0.0 0.0 17972 7428 ? Ss 9=D4=C202 0:04 /us= r/sbin/sshd -D > 10066 432951 0.0 0.0 0 0 ? D 9=D4=C202 0:00 [Fa= keFinalizerDa] > root 496774 0.0 0.0 0 0 ? D 9=D4=C202 0:17 [kw= orker/8:1+eve] > cps-new-ondemand-0587:~ # cat /proc/496774/stack > [<0>] __switch_to+0x94/0xe8 > [<0>] drm_sched_entity_flush+0xf8/0x248 [gpu_sched] > [<0>] amdgpu_ctx_mgr_entity_flush+0xac/0x148 [amdgpu] > [<0>] amdgpu_flush+0x2c/0x50 [amdgpu] > [<0>] filp_close+0x40/0xa0 > [<0>] put_files_struct+0x118/0x120 > [<0>] put_files_struct+0x30/0x68 [binder_linux] > [<0>] binder_deferred_func+0x4d4/0x658 [binder_linux] > [<0>] process_one_work+0x1b4/0x3f8 > [<0>] worker_thread+0x54/0x470 > [<0>] kthread+0x134/0x138 > [<0>] ret_from_fork+0x10/0x18 > [<0>] 0xffffffffffffffff > > > > This issue troubled me a long time. looking eagerly to get help from you= ! > > > ----- > Yanhua --_000_2162676edbfaa67d248c98e9eb2099c2amdcom_ Content-Type: text/html; charset="GB18030" Content-ID: Content-Transfer-Encoding: quoted-printable
Well that looks like the hardware got stuck.=

Do you get something in the locks about a timeout on the SDMA ring?

Regards,
Christian.

Am 03.09.19 um 14:50 schrieb 78666679:
Hi Christian,
       Sometimes the thread blocked = ; disk sleeping in call to amdgpu_sa_bo_new. following is the stack trace.&= nbsp; it seems the sa bo is used up ,  so  the caller blocked wai= ting someone to free sa resources.

D 206833 227656 [surfaceflinger] <defunct> Binder:45_5
cat /proc/206833/task/227656/stack

[<0>] __switch_to+0x94/0xe8
[<0>] dma_fence_wait_any_timeout+0x234/0x2d0
[<0>] amdgpu_sa_bo_new+0x468/0x540 [amdgpu]
[<0>] amdgpu_ib_get+0x60/0xc8 [amdgpu]
[<0>] amdgpu_job_alloc_with_ib+0x70/0xb0 [amdgpu]
[<0>] amdgpu_vm_bo_update_mapping+0x2e0/0x3d8 [amdgpu]
[<0>] amdgpu_vm_bo_update+0x2a0/0x710 [amdgpu]
[<0>] amdgpu_gem_va_ioctl+0x46c/0x4c8 [amdgpu]
[<0>] drm_ioctl_kernel+0x94/0x118 [drm]
[<0>] drm_ioctl+0x1f0/0x438 [drm]
[<0>] amdgpu_drm_ioctl+0x58/0x90 [amdgpu]
[<0>] do_vfs_ioctl+0xc4/0x8c0
[<0>] ksys_ioctl+0x8c/0xa0
[<0>] __arm64_sys_ioctl+0x28/0x38
[<0>] el0_svc_common+0xa0/0x180
[<0>] el0_svc_handler+0x38/0x78
[<0>] el0_svc+0x8/0xc
[<0>] 0xffffffffffffffff


--------------------
YanHua

------------------ =D4=AD=CA=BC=D3=CA=BC=FE ------------------
=B7=A2=BC=FE=C8=CB: "Koenig, Christian"<Chr= istian.Koenig-5C7GfCeVMHo@public.gmane.org>;
=B7=A2=CB=CD=CA=B1=BC=E4: 2019=C4=EA9=D4=C23=C8=D5(=D0=C7= =C6=DA=B6=FE) =CF=C2=CE=E74:21
=B3=AD=CB=CD: "Deucher, Alexander"<Alexande= r.Deucher-5C7GfCeVMHo@public.gmane.org>;
=D6=F7=CC=E2: Re: Bug: amdgpu drm driver cause process int= o Disk sleep state

Hi Yanhua,

please update your kernel first, cause that looks like a known issue
which was recently fixed by patch "drm/scheduler: use job count instea= d
of peek".

Probably best to try the latest bleeding edge kernel and if that doesn't help please open up a bug report on https://bugs.freedesktop.org/.

Regards,
Christian.

Am 03.09.19 um 09:35 schrieb 78666679:
> Hi, Sirs:
>         I have a wx5100 amdgpu= card, It randomly come into failure.  sometimes, it will cause proces= ses into uninterruptible wait state.
>
>
> cps-new-ondemand-0587:~ # ps aux|grep -w D
> root      11268  0.0  0.0 260628&nb= sp; 3516 ?        Ssl  8=D4=C226&nb= sp;  0:00 /usr/sbin/gssproxy -D
> root     136482  0.0  0.0 212500 &n= bsp; 572 pts/0    S+   15:25   0:00 = grep --color=3Dauto -w D
> root     370684  0.0  0.0  17972&nb= sp; 7428 ?        Ss   9=D4=C2= 02   0:04 /usr/sbin/sshd -D
> 10066    432951  0.0  0.0   &n= bsp;  0     0 ?      = ;  D    9=D4=C202   0:00 [FakeFinalizerDa] > root     496774  0.0  0.0  &nb= sp;   0     0 ?     =    D    9=D4=C202   0:17 [kworker/8:1= 3;eve]
> cps-new-ondemand-0587:~ # cat /proc/496774/stack
> [<0>] __switch_to+0x94/0xe8
> [<0>] drm_sched_entity_flush+0xf8/0x248 [gpu_sched]
> [<0>] amdgpu_ctx_mgr_entity_flush+0xac/0x148 [amdgpu]
> [<0>] amdgpu_flush+0x2c/0x50 [amdgpu]
> [<0>] filp_close+0x40/0xa0
> [<0>] put_files_struct+0x118/0x120
> [<0>] put_files_struct+0x30/0x68 [binder_linux]
> [<0>] binder_deferred_func+0x4d4/0x658 [binder_linux]
> [<0>] process_one_work+0x1b4/0x3f8
> [<0>] worker_thread+0x54/0x470
> [<0>] kthread+0x134/0x138
> [<0>] ret_from_fork+0x10/0x18
> [<0>] 0xffffffffffffffff
>
>
>
> This issue troubled me a long time.  looking eagerly to get help = from you!
>
>
> -----
> Yanhua


--_000_2162676edbfaa67d248c98e9eb2099c2amdcom_-- --===============1386558522== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KYW1kLWdmeCBt YWlsaW5nIGxpc3QKYW1kLWdmeEBsaXN0cy5mcmVlZGVza3RvcC5vcmcKaHR0cHM6Ly9saXN0cy5m cmVlZGVza3RvcC5vcmcvbWFpbG1hbi9saXN0aW5mby9hbWQtZ2Z4 --===============1386558522==--