Re: [PATCH 2/2] drm/amdgpu: add AMDGPURESET uevent on AMD GPU reset

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Amarnath,

not a bad idea, but that won't work either because you really need to return to make sure that a potential next reset can run.

What could be done is to have a work item which does that, but then I think it would just be easier to teach the udev function a GFP mask.

Regards,
Christian.


Am 17.01.22 um 15:19 schrieb Somalapuram, Amaranath:
Hi Christian,

if sending udev event during reset is going to create problem, we can move this code from reset sequence to re-int  (after GPU reset succeeded).

Regards,

S.Amarnath

On 1/17/2022 5:27 PM, Christian König wrote:
Am 17.01.22 um 12:43 schrieb Sharma, Shashank:
Hello Christian,

On 1/17/2022 11:37 AM, Christian König wrote:
Am 17.01.22 um 11:34 schrieb Somalapuram, Amaranath:
[SNIP]
Any suggestion how we can notify user space during this situation.

Well trace points should work. They use a ring buffer and are specially made to work in such situations.

We are anyways sending a trace event with data, but can trace event be a wake up source for an application (like a tracer) ? This DRM event is just to indicate that reset happened, so app has to read from trace file.

Yeah, that's a really good question I can't fully answer. As far as I know you can filter in userspace what you get from the tracer, but I don't know if you can block on a specific event.

Christian.



Alternative would be to audit the udev code and allow giving a GFP mask to the function to make sure that we don't run into the deadlock.

Another alternative is a debugfs file which just blocks for the next reset to happen.


- Shashank

Regards,
Christian.

Regards,

S.Amarnath







[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux