I would rather say that we need to add this to the per context lockup
informations.
Marek had a rather good start for this, but from the VM fault handler it
is actually rather tricky to figure out reliable who caused it.
Because of this we didn't followed this approach to the end.
Christian.
Am 07.11.2016 um 19:42 schrieb StDenis, Tom:
Could we provide fault information through a ring buffer and a debugfs
or drm ioctl interface?
Tom
------------------------------------------------------------------------
*From:* amd-gfx <[email protected]> on behalf of
Alex Deucher <[email protected]>
*Sent:* Monday, November 7, 2016 13:35
*To:* Edward O'Callaghan; Nicolai Hähnle; Marek Olsak
*Cc:* Michel Dänzer; amd-gfx list
*Subject:* Re: amdgpu: ratelimit on vm faults to avoid spaming console
On Sun, Nov 6, 2016 at 11:35 PM, Edward O'Callaghan
<[email protected]> wrote:
> These are rather minor however should help stop some folks
> machines grinding to a halt when a userspace application somehow
> gets the GPU into some horrible state causing the console to fill
> very quickly. Applies on top of master.
I'm generally ok with the idea. My only concern would be if this
would adversely affect the radeon GPUVM debugging options in mesa and
piglit. Nicolai? Marek?
Alex
_______________________________________________
amd-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
amd-gfx Info Page - lists.freedesktop.org
<https://lists.freedesktop.org/mailman/listinfo/amd-gfx>
lists.freedesktop.org
To see the collection of prior postings to the list, visit the amd-gfx
Archives. Using amd-gfx: To post a message to all the list members,
send email ...
_______________________________________________
amd-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
_______________________________________________
amd-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
