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
