Hi,
I've just had an oops in i915_driver_irq_handler. It's a NULL pointer
dereference at line 1179 in i915_irq.c (the bit that's about to call
READ_BREADCRUMB().
This is on 2.6.38. It's a dual core GM45 machine running a totally
custom EGL application running directly on KMS with no X.
The system has no local storage so I haven't captured the oops output (I
have a bad photo if you really want it) but it's very clear where it fails.
The code is:
if (dev->primary->master) {
master_priv = dev->primary->master->driver_priv;
if (master_priv->sarea_priv)
master_priv->sarea_priv->last_dispatch =
READ_BREADCRUMB(dev_priv);
}
dev->primary->master is not NULL.
dev->primary->master->driver_priv is NULL.
So reading sarea_priv triggers the oops.
The oops occurred sometime overnight and the owner of the machine is not
entirely sure what state it was left in. However the most likely is that
it was repeatedly restarting the application every 30 seconds so would
have been opening and closing the drm device.
From very briefly looking at the code it seems that the path through
drm_release that sets driver_priv to NULL has no locking against the
irq. Seems to me that the irq handler should also be checking
driver_priv for NULL to cover this case? Or should the ordering be
changed higher up so that master gets set to NULL before freeing the
driver_priv?
I have this same code running on quite a few (20+) identical machines
and haven't seen this before so I doubt I can reproduce it...
Matthew
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
