On 14/08/24 19:54, Lucas De Marchi wrote: > On Wed, Aug 14, 2024 at 12:16:41PM GMT, Aravind Iddamsetty wrote: >>>>> i see that this is even called from xe_guc_exec_queue_lr_cleanup which is for long running queue >>>>> from various call paths need to check in what scenarios those happen. >>>> Should we add a reason for long running queue? >>> Both of your questions would probably be answered if this was getting developed >>> at the same time of the user space usage of these uevents. >> >> Can't we consider the generic Linux user as a consumer, via udevadm. > > No, udevadm just confirms that there is an event being sent. Main thing > to understand here is "what is this event useful for? what can be done > as outcome of receiving this event?". From your other reply it seems > this is about "device is wedged/toast, and driver can't recover without > userspace intervention since userspace may have different policies" > > What would be some examples of actions for userspace to take? > > - Unbind driver, kill clients, rebind? > - FLR? > - Something else? The expectation from userspace on receiving this event is to do a reset most probably SBR(unbind->sbr->rebind). The other requirement of this event is for L0 Sysman https://spec.oneapi.io/level-zero/latest/sysman/api.html#_CPPv4N21zes_event_type_flag_t41ZES_EVENT_TYPE_FLAG_DEVICE_RESET_REQUIREDE https://spec.oneapi.io/level-zero/latest/sysman/api.html#_CPPv4N18zes_device_state_t5resetE So we expect the admin do the above actions > > Is this currently implemented somewhere? Do you mean by some other driver or subsystem? > > Also, is it possible to make is a generic drm event handling so distros > don't have to setup udev rules for each vendor? I think doing via drm event mandates the observability applications(L0) to have open connection to the device to process these which is not desired. Thanks, Aravind. > > > > Lucas De Marchi > >> >> Thanks, >> Aravind. >>> >>>> Raag
