[Mesa-dev] [PATCH 1/2] radeonsi: set a per-buffer flag that disables inter-process sharing (v4)

Christian König deathsimple at vodafone.de
Thu Sep 7 10:24:42 UTC 2017


Am 07.09.2017 um 12:14 schrieb Marek Olšák:
>
>
> On Sep 7, 2017 12:08 PM, "Christian König" <deathsimple at vodafone.de 
> <mailto:deathsimple at vodafone.de>> wrote:
>
>     Am 07.09.2017 um 11:23 schrieb Michel Dänzer:
>
>         On 01/09/17 07:40 PM, Christian König wrote:
>
>             Am 01.09.2017 um 12:28 schrieb Michel Dänzer:
>
>                 On 01/09/17 07:23 PM, Nicolai Hähnle wrote:
>
>                     On 01.09.2017 11:58, Michel Dänzer wrote:
>
>                         On 29/08/17 11:47 PM, Christian König wrote:
>
>                             From: Marek Olšák <marek.olsak at amd.com
>                             <mailto:marek.olsak at amd.com>>
>
>                             For lower overhead in the CS ioctl.
>                             Winsys allocators are not used with
>                             interprocess-sharable resources.
>
>                             v2: It shouldn't crash anymore, but the
>                             kernel will reject the new
>                             flag.
>                             v3 (christian): Rename the flag, avoid
>                             sending those buffers in the
>                             BO list.
>                             v4 (christian): Remove setting the kernel
>                             flag for now
>
>                         This change seems to have caused a GPU hang
>                         when running piglit on my
>                         Kaveri with the radeon kernel driver.
>
>         I think we can remove "seems to have". I'm still reliably
>         getting the
>         GPUVM fault and hang with current master, but not if I revert this
>         commit (and the one after it).
>
>                         Haven't been able to isolate it to a specific
>                         test, seems to only
>                         happen when running multiple tests concurrently.
>
>         I reproduced the problem with piglit process separation
>         enabled as well,
>         and all four tests running when it hung were textureGather tests.
>         Before, reproducing the problem twice with piglit process
>         separation
>         disabled, three textureGather tests were running when it hung
>         both times
>         as well. I've been unable to reproduce the problem by manually
>         running
>         the same textureGather tests in parallel though.
>
>
>                         There's a GPUVM fault before the hang, I
>                         suspect it's related:
>
>                         radeon 0000:00:01.0: GPU fault detected: 146
>                         0x0ae6760c
>                         radeon 0000:00:01.0:
>                          VM_CONTEXT1_PROTECTION_FAULT_ADDR  0x000001D7
>                         radeon 0000:00:01.0:
>                          VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x0607600C
>                         VM fault (0x0c, vmid 3) at page 471, read from
>                         'CPF' (0x43504600) (118)
>
>
>                         Any ideas?
>
>             Not the slightest, but I'm still investigating problems
>             with that on
>             amdgpu.
>
>             If we can't find the root cause till Monday it might be a
>             good idea to
>             revert the patches for now.
>
>         What's the status on that?
>
>
>
>     I've found and fixed the remaining kernel bugs over the last
>     weekend/beginning of this week.
>
>     Still need to commit the fix for UVD/VCE, but that one shouldn't
>     affect GFX at all.
>
>
> Michel is seeing hangs on the radeon KMD, which should be unaffected 
> by you kernel work I think.
>
> We could revert this to unbreak Michel's Kaveri, but I think it 
> shouldn't be so difficult to find the culprit in this patch if there 
> is one.

The only crux is that the userspace patch shouldn't affect radeon at 
all. So the real question is what the heck is going on here?

Christian.

>
> Marek
>
>
>
>     Christian.
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20170907/757db538/attachment-0001.html>


More information about the mesa-dev mailing list