SDMA out-of-bounds write access of tiled surface

[Nicolai Hähnle]

On 22.06.2016 09:53, Christian König wrote:
> Hi Nocolai,
>
> If we don't already have an option for this try to double the size of
> the VM area allocate for each BO in userspace.
>
> That should give you a nice hole between each BO and so should help to
> catch cases when somebody writes over the end of a BO.

Tried that (+ forcing the buffer cache to re-use BOs only with the exact 
size), but no change in observed behavior.

Cheers,
Nicolai

>
> Regards,
> Christian.
>
> Am 22.06.2016 um 09:50 schrieb Nicolai Hähnle:
>> Hi Mads,
>>
>> setting R600_DEBUG=nodma in the X server should work around your
>> problem for now.
>>
>> Marek, perhaps an out-of-bounds check for tiled texture memory access
>> similar to the linear access check is necessary? I wonder if you've
>> seen something about that in the docs.
>>
>> I've annotated the sDMA IB dump. It's a linear-to-display-tiled copy
>> on Carrizo. I tried to reproduce with the attached patch, but failed
>> to do so even with amdgpu.vm_debug=1. With the patch, I get DMA copies
>> that are identical to the one that causes the VM fault except for a
>> different bank_height and macro_tile_aspect, so the issue is likely
>> related to those.
>>
>> Nicolai
>>
>> On 21.06.2016 19:32, Nicolai Hähnle wrote:
>>> On 21.06.2016 19:16, Mads wrote:
>>>> I sent this for 1.5 hours ago, but since it hasn't arrived to the
>>>> mailing list yet, I try again...
>>>
>>> It arrived, no worries :)
>>>
>>> I'll take a look later.
>>>
>>> Nicolai
>>>
>>>>
>>>> On 2016-06-21 17:48, Mads wrote:
>>>>
>>>>> On 2016-06-21 10:12, Mads wrote:
>>>>>
>>>>> On 2016-06-21 09:39, Nicolai Hähnle wrote:
>>>>>
>>>>> Thanks. However, I still don't think this is going to help. Your
>>>>> earlier trace experiments showed that the problematic SDMA commands
>>>>> came from the X server, _not_ from plasmashell.
>>>>>
>>>>> So what we see here is likely just the first set of GPU commands sent
>>>>> by plasmashell after the VM fault occurred. Since the plasmashell
>>>>> process is unable to tell who caused the VM fault, it takes the blame
>>>>> incorrectly. Are you sure the X server is using your self-compiled
>>>>> radeonsi_dri.so and has the environment variable set? If it creates a
>>>>> ddebug_dump, it might be somewhere else (it's based off the HOME
>>>>> environment variable, which may be different).
>>>>> I'll take a second look to see if there's an X dump there too, but
>>>>> unfortunately it'll be in about ~8 hours before I have the machine at
>>>>> hand again..
>>>>>
>>>>> And yes, I'm sure, everything is built through portage, so there is no
>>>>> "self-compiled" on the system per se. There's always just one lib
>>>>> available at any time :)
>>>>
>>>> You were right! X didn't have R600_DEBUG=check_vm in environment (no
>>>> login shell/sourcing of /etc/profile).
>>>>
>>>> Here's what i ran:
>>>>
>>>>> $ XAUTHORITY=.Xauthority DISPLAY=:0 LIBGL_DEBUG=verbose dolphin
>>>>> libGL: pci id for fd 9: 1002:9874, driver radeonsi
>>>>> libGL: OpenDriver: trying /usr/lib64/dri/tls/radeonsi_dri.so
>>>>> libGL: OpenDriver: trying /usr/lib64/dri/radeonsi_dri.so
>>>>> si_vm_fault_occured: failed to parse line ' Either
>>>>> enable ECC checking or force module loading by setting
>>>>> 'ecc_enable_override'.
>>>>> '
>>>>> libGL: Using DRI3 for screen 0
>>>>> Trying to convert empty KLocalizedString to QString.
>>>>> Cannot creat accessible child interface for object:
>>>>> PlacesView(0x118d670)  index:  5
>>>>> QPixmap::scaled: Pixmap is a null pixmap
>>>>> QPixmap::scaled: Pixmap is a null pixmap
>>>>> (... etc ...)
>>>>> The X11 connection broke (error 1). Did the X11 server die?
>>>>
>>>> Attaching dmesg and ddebug_dump.
>>>>
>>>> - Mads
>>
>>
>>
>> _______________________________________________
>> amd-gfx mailing list
>> amd-gfx at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>