<div class="gmail_extra"><div class="gmail_quote">On Wed, Apr 25, 2012 at 08:57, Daniel Vetter <span dir="ltr"><<a href="mailto:daniel.vetter@ffwll.ch" target="_blank">daniel.vetter@ffwll.ch</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
gpu reset is a very important piece of our infrastructure.<br>
Unfortunately we only really it test by actually hanging the gpu,<br>
which often has bad side-effects for the entire system. And the gpu<br>
hang handling code is one of the rather complicated pieces of code we<br>
have, consisting of<br>
- hang detection<br>
- error capture<br>
- actual gpu reset<br>
- reset of all the gem bookkeeping<br>
- reinitialition of the entire gpu<br>
<br>
This patch adds a debugfs to selectively stopping rings by ceasing to<br>
update the hw tail pointer, which will result in the gpu no longer<br>
updating it's head pointer and eventually to the hangcheck firing.<br>
This way we can exercise the gpu hang code under controlled conditions<br>
without a dying gpu taking down the entire systems.<br>
<br>
Patch motivated by me forgetting to properly reinitialize ppgtt after<br>
a gpu reset.<br>
<br>
Usage:<br>
<br>
echo $((1 << $ringnum)) > i915_ring_stop # stops one ring<br>
<br>
echo 0xffffffff > i915_ring_stop # stops all, future-proof version<br>
<br>
then run whatever testload is desired. i915_ring_stop automatically<br>
resets after a gpu hang is detected to avoid hanging the gpu to fast<br>
and declaring it wedged.<br>
<br>
v2: Incorporate feedback from Chris Wilson.<br>
<br>
v3: Add the missing cleanup.<br>
<br>
Signed-Off-by: Daniel Vetter <<a href="mailto:daniel.vetter@ffwll.ch">daniel.vetter@ffwll.ch</a>><br>
Reviewed-by: Chris Wilson <<a href="mailto:chris@chris-wilson.co.uk">chris@chris-wilson.co.uk</a>><br></blockquote><div><br></div><div>I think I sent my R-b for the previous series, but just in case, for the new one:</div>
<div>Reviewed-By: Eugeni Dodonov <<a href="mailto:eugeni.dodonov@intel.com">eugeni.dodonov@intel.com</a>></div><div><br></div><div>With small bikeshed below:</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
static ssize_t<br>
+i915_ring_stop_read(struct file *filp,<br>
+ char __user *ubuf,<br>
+ size_t max,<br>
+ loff_t *ppos)<br>
+{<br>
+ struct drm_device *dev = filp->private_data;<br>
+ drm_i915_private_t *dev_priv = dev->dev_private;<br>
+ char buf[80];<br></blockquote><div><br></div><div>buf is 80 characters here, but</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">+static ssize_t<br>
+i915_ring_stop_write(struct file *filp,<br>
+ const char __user *ubuf,<br>
+ size_t cnt,<br>
+ loff_t *ppos)<br>
+{<br>
+ struct drm_device *dev = filp->private_data;<br>
+ struct drm_i915_private *dev_priv = dev->dev_private;<br>
+ char buf[20];<br></blockquote><div><br></div><div>here it is 20.. I don't think we'll need more than 20 the way it is supposed to work, so maybe standardize it to 80 above as well for consistency?</div><div>
<br></div></div>-- <br>Eugeni Dodonov<a href="http://eugeni.dodonov.net/" target="_blank"><br></a><br>
</div>