| Message ID | 1374212570-7330-1-git-send-email-ben@bwidawsk.net (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Thu, Jul 18, 2013 at 10:42:48PM -0700, Ben Widawsky wrote: > We've recently deferred error handling with a workqueue for a number of > reasons. However, when we're trying to pass the information to > userspace, it's likely more interesting to know when the error was > detected by the kernel, and not when we eventually get around to > handling it in the workqueue. > > This was inspired as a result of the patch to move these events to the > uapi. > > Signed-off-by: Ben Widawsky <ben@bwidawsk.net> > --- > drivers/gpu/drm/i915/i915_irq.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c > index 9910699..9fe430a 100644 > --- a/drivers/gpu/drm/i915/i915_irq.c > +++ b/drivers/gpu/drm/i915/i915_irq.c > @@ -1435,13 +1435,10 @@ static void i915_error_work_func(struct work_struct *work) > gpu_error); > struct drm_device *dev = dev_priv->dev; > struct intel_ring_buffer *ring; > - char *error_event[] = { "ERROR=1", NULL }; > char *reset_event[] = { "RESET=1", NULL }; > char *reset_done_event[] = { "ERROR=0", NULL }; > int i, ret; > > - kobject_uevent_env(&dev->primary->kdev.kobj, KOBJ_CHANGE, error_event); > - > /* > * Note that there's only one work item which does gpu resets, so we > * need not worry about concurrent gpu resets potentially incrementing > @@ -1594,11 +1591,14 @@ void i915_handle_error(struct drm_device *dev, bool wedged) > { > struct drm_i915_private *dev_priv = dev->dev_private; > struct intel_ring_buffer *ring; > + char *error_event[] = { "ERROR=1", NULL }; > int i; > > i915_capture_error_state(dev); > i915_report_and_clear_eir(dev); > > + kobject_uevent_env(&dev->primary->kdev.kobj, KOBJ_CHANGE, error_event); > + > if (wedged) { > atomic_set_mask(I915_RESET_IN_PROGRESS_FLAG, > &dev_priv->gpu_error.reset_counter); This leaves the reset counter unchanged prior to the uevent, if you move the uevent signalling down to just before the queue_work() there would be no userspace visible changes (other than timing, which is a moot point). However, kobject_uevent_env() is not suitable for calling from irq-context. -Chris
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c index 9910699..9fe430a 100644 --- a/drivers/gpu/drm/i915/i915_irq.c +++ b/drivers/gpu/drm/i915/i915_irq.c @@ -1435,13 +1435,10 @@ static void i915_error_work_func(struct work_struct *work) gpu_error); struct drm_device *dev = dev_priv->dev; struct intel_ring_buffer *ring; - char *error_event[] = { "ERROR=1", NULL }; char *reset_event[] = { "RESET=1", NULL }; char *reset_done_event[] = { "ERROR=0", NULL }; int i, ret; - kobject_uevent_env(&dev->primary->kdev.kobj, KOBJ_CHANGE, error_event); - /* * Note that there's only one work item which does gpu resets, so we * need not worry about concurrent gpu resets potentially incrementing @@ -1594,11 +1591,14 @@ void i915_handle_error(struct drm_device *dev, bool wedged) { struct drm_i915_private *dev_priv = dev->dev_private; struct intel_ring_buffer *ring; + char *error_event[] = { "ERROR=1", NULL }; int i; i915_capture_error_state(dev); i915_report_and_clear_eir(dev); + kobject_uevent_env(&dev->primary->kdev.kobj, KOBJ_CHANGE, error_event); + if (wedged) { atomic_set_mask(I915_RESET_IN_PROGRESS_FLAG, &dev_priv->gpu_error.reset_counter);
We've recently deferred error handling with a workqueue for a number of reasons. However, when we're trying to pass the information to userspace, it's likely more interesting to know when the error was detected by the kernel, and not when we eventually get around to handling it in the workqueue. This was inspired as a result of the patch to move these events to the uapi. Signed-off-by: Ben Widawsky <ben@bwidawsk.net> --- drivers/gpu/drm/i915/i915_irq.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)